I wasn't aware at the time it had been deferred but we came to the conclusion (myself and others preent) that it would not be written into law as that assumption of guilt would set a legal precedent which all judges from then on would be forced to consider. Reversing the Burden of Proof isn't unknown - for example, you are forced to PROVE you have car insurance / a licence if stopped by a policeman, or are liable for not doing so (the crimes you are guilty until proven innocent for here are driving without a licence, and driving without insurance) That isn't the problem. what IS the problem is that it is impossible to prove that you don't have a key - or, worse yet, that you HAD the key, but have forgotten the secret password you used to access it. Normally, reversing the Burden of Proof is reserved for cases where producing such proof is easy for the accused (if you HAVE a driving licence and / or insurance, even if you have lost your original documents you can obtain at least a letter proving you had them) and awkward / impossible for the government (imagine if the Police had to contact every insurance company in the uk after a road accident, to ask "is person xxx insured to drive with you, or covered by anyone you DO insure?" - now imagine what hoops the insurance company would have to go through to handle several dozen calls per office per day of this nature, and who would end up paying for it). --
2. If you can't hand over a key (because you don't have it, or the file isn't encrypted) then you are liable to a jail sentence There are express articles that exempt you from this sentence if you can prove or make clear that you, at the time of the question to produce the key, could not do that, as long as you do the moment you can provide it. Yes, that's a wonderful option. I think a recent open letter to Jack Straw put the best slant on this (I don't have the URL to hand, but I am sure someone here on/. will provide:+)
Basically, a group of hackers did the following:
Created a key in the name of Jack Straw
Uploaded that key to the keyservers
had a criminal make a signed confession of a currently unsolved crime
Scanned and encrypted that with the JackStraw key
Destroyed all intermediate work - the key, the original (paper document) and the unencrypted disk file)
posted the encrypted file to a website, along with a description of what they had done
So, here is the situation - any police officer can find a file that blatently contains information useful to clear up a crime. According to the file, the key is held by one Jack Straw, Home Secretary. How is Mr Straw to PROVE he does't have that key, and in fact has never had it? it has his name on it, after all..... BTW, can you point out the clause that allows you merely to "make clear" that you don't have the key, not prove the negative?
And that's what scares me the most: apparently a lot of thought hs gone into this bill, to try and be "fair", but those people doing the "thinking" still overlooked the basic unfairness of it all. I mean, there's even a provision to allow you to invalidate the key (which otherwise would be an offence, as well). They think that far, but think not close up, or something. Hmm. it has obviously been "tweeked" a little more since the last draft I saw (which does't have that provision, and indeed, now even allows you to chose to decode the document yourself (the previous draft didn't even allow you to see the document claimed to be encrypted by your key) I must admit though, in a quick scan, I couldn't find a option to revoke; any chance of a section number? I am not doubting you, just trying to locate these loopholes without having to re-read the entire thing again.... --
This has been on the table for a while - The Government here in.uk were trying to slip it through by making it a component of a more sweeping "eCommerce enabling" act. After a lot of complaints from pro-liberty and pro-cryptography groups (CyberLiberties, for example) it was finally removed from that bill and slotted into the RoIP bill - unchanged. The official slant was that the RoIP bill was a "better vehicle" for this. The basic problems with it are these:
You do not need to be even SUSPECTED of a crime - you just need a police officer to be OF THE OPINION that a given file is encrypted.
If you can't hand over a key (because you don't have it, or the file isn't encrypted) then you are liable to a jail sentence
If you tell anyone about having been served the warrant, you are liable to a larger jail sentence
if you tell your solicitor about the warrant for purposes of your defence (and the only defence is to PROVE you don't have the key - an impossible task) HE is also bound by the clause not to tell anyone
There is only one appeal to the warrant - not to a criminal court, but to a closed panel, not accountable to any judicial body and not required to give an explaination of their decision.
You are not entitled to compensation unless the warrant was signed personally by the head of the Home Office (a government department). A warrant signed by a police inspector is just as legal, but doesn't carry any compensation.
If anyone has looked at my homepage in the last few months, now they know what my profile means:+) --
Doesn't this amount to a ban on advertising other branches of the same shop? I would be surprised if America's rules allow this, and can't see the difference between banning display of website URLs and banning mention of that store's outlet in $COMPETING_MALL..... --
Once we get beyond our current, Micky Mouse qubit limitations, adding one more bit will be trivial. I must admit to having trouble discovering where this massive breakthrough will come from - you are claiming that you can increase the number of parallel universe "ops" practically without limit and at very low cost, which even to my limited understanding seems unlikely. --
Hmmm. I doubt we will see a major advance in quantum code-breaking in the next (say) twenty years. It has taken years of research just to build a two or three bit machine, and increasing a RSA or DH key by just a few bits would require doubling the number of "parallel universe computing cells" that are required to crack it. I can't see massive, secret research on this being funded well enough - particularly as it is "cheaper" in most senses to use other methods to defeat keys (most of which require physical intrusion to the machine in question or subversion of trusted personnel, but that has always been a standard operating procedure).
At worst, I think we will see the minimum key sizes considered secure increase, maybe by an order of magnitude, but without a change to the fundamental schemes in use - after all, with QC we are talking faster application of existing techniques, not a entirely new field. --
Hmm. I keep mine on a Scramdisk (a free virtual disk encryptor available from Here. I also encrypt the data with PGP every so often and email it home, so I have a backup if I lose the scramdisk or forget IT's password -- -=DaveHowe=-
Re:now we should have new NT vs. Linux Benchmarks
on
Samba 2.06 Released
·
· Score: 1
even *I* could speed up Samba drastically - just take out all the checks for password and username, and give everyone full access to the entire tree:+) That wouldn't speed up samba drasticly, since that is not where the bottlenecks are. I imagine filename searching (case insensitive), name mangling, and oplocks are where the worse bottlenecks are. Yes, I know - it was meant as a humourous statement, giving a patch everyone could see as being a *bad thing*. If I had any/good/ ideas to speed up Samba, I would either have tried them or suggested them (depending on if my coding was up to the trial)...... Password authentication is rarely ever a bottleneck --
Re:now we should have new NT vs. Linux Benchmarks
on
Samba 2.06 Released
·
· Score: 1
even *I* could speed up Samba drastically - just take out all the checks for password and username, and give everyone full access to the entire tree:+) That wouldn't speed up samba drasticly, since that is not where the bottlenecks are. I imagine filename searching (case insensitive), name mangling, and oplocks are where the worse bottlenecks are. Yes, I know - it was meant as a humourous statement, giving a patch everyone could see as being a *bad thing*. If I had any/good/ ideas to speed up Samba, I would either have tried them or suggested them (depending on if my coding was up to the trial)...... Password authentication is rarely ever a bottleneck --
Re:now we should have new NT vs. Linux Benchmarks
on
Samba 2.06 Released
·
· Score: 1
They have fixed quite a few bugs, niggles and security issues, but I don't see much if anything that would make it faster. As it should be. One of the reasons I like Open Source Software is that the programmers generally concentrate on real improvements, not arbitrary benchmarks. Hmm. I/semi/ agree with that one - Improving speed is as good an upgrade as improving functionality, provided you don't go for speed either
Purely to match a benchmark that has no relationship to reality and
that you don't sacrifice functionality, security or reliability just to eke out that extra half-milisec.
even *I* could speed up Samba drastically - just take out all the checks for password and username, and give everyone full access to the entire tree:+) --
I'm not sure whether this is the best forum to address this.. but I'm always alittle miffed about how the initial release of most software is in the form of a tarball. This is fine - I know how to use them. My problem is that alot of stuff under RH6 and other distros use RPM, or dpkg, or other such utilities. That makes life difficult for me, because then I need to uninstall the old package (making sure to backup the config files) and then install the tar. Hmm. RPMs are wonderful things - precompiled, ready-to-run executables in a container that allows the end-user to install it simply. Tarballs, by contrast, are just compressed blocks of source with a make script and are much harder to use That said, tarballs were around long before RPMS, and there are still some distros out there that can't support RPM - but there aren't any that can't do tarball, plus the commercial Unixen (like HP) use a different system again. It is much easier to do it ONCE as a tarball, than five or six different ways for five or six different systems.
If I later get the packaged release (usually a few weeks later), then I gotta do that all over again! Man... it's times like these I wish linux was a little more standardized for some things. Packaging should not be this difficult. I suspect at some point RPM will become the default - but for the moment, tarball is easier for the writers (if not the users). But that said, why are you installing the RPM over the top? once you get the tarball up and running, it must be easier to leave it than to de-install and re-install just so to have the pretty packet version rather than the homespun.... although I agree it makes life easier in the long run if you upgrade with another RH CD. --
Re:now we should have new NT vs. Linux Benchmarks
on
Samba 2.06 Released
·
· Score: 3
Now that there is an new version of Samba we should have those mindspring tests again. Wasn't a big part of that benchmark serving win98 clients through samba? Not entirely sure about that - they have fixed quite a few bugs, niggles and security issues, but I don't see much if anything that would make it faster. In any case, if the test showed that NT was still faster than Samba, it would be dismissed by the linux community as biased, due to NT being optimised for Win95 and not NT workstation, or just wrong. If it showed NT slower than Samba, then Microsoft would dismiss it for almost the same reasons:+) --
While I am glad to see China embracing Linux as it's official OS (and if I recall correctly, France now has a government policy of preferring OSS to closed-source) I seem to recall that the main Chinese-language Distro had some problems with The GPL Licence, in particular not redistributing the altered source code. Does anyone know if this has been resolved? --
I don't think anyone really expected M$oft to win this one - not given how many times they shot themselves in the foot. the real questions are going to be
What will the penalty be?
Will M$oft actually stick to it this time?
Will M$oft manage to wiggle out on appeal, or at least get a stay until that appeal is heard
But not all the companies who make DVD players are american. As a fact, very few. So this wouldn't have been much of a problem... nbsp; Possibly not - but a lot of the recordings seem to be from the US, so I suspect they had a big say in the definition of the standard. Non-US members could have defined a standard without them, of course, but would then run the risk of being the Betamax players in a VHS market.... --
I wouldn't be surprised if the lousy, five byte encryption on these things came down to making them US Export-Legal.... Even with the "new, improved" fast-track licencing, I believe each individual export has to be at least notified, and the paperwork overhead of tracking each batch of DVD players to the end user would have been astronomical. And there, you thought the US government's export ban had no positive aspects;+) --
ZDNet have rushed off a piece on Online Privacy In response to the RealNetworks thing - it mentions a new "privacy statement" by RN, that they intend to release a patch to prevent the sending of the data, and bring up the MS GUID and Intel chip-id stories that have dropped out of sight lately... --
ZDNet have rushed off a piece on Online Privacy In response to the RealNetworks thing - it mentions a new "privacy statement" by RN, that they intend to release a patch to prevent the sending of the data, and bring up the MS GUID and Intel chip-id stories that have dropped out of sight lately... --
Except RealJukebox doesn't download things from websites. That's RealAudio you're thinking of. RealJukebox plays audio files and CDs on your computer, and therefore has no business sending any kind of data over the Internet. Hmm. well, according to the website it has downloading capabilities, but you are correct - It is primarily a flatfile player/recorder. This makes things even worse - it is *not* a public-player, as the name "jukebox" implies, but a personal "walkman" player:+) /me makes mental note to check on products next time.... --
I'd investigate, certainly, but I'd hold short of trying to beat the crap out of him or call my local legislature and ask them to pass laws that forbids people from taking photographs of me in public. If I asked him and he said he was a photographer for the Daily News, and was just out checking how popular the new restaurant that just opened was, I'd believe him, certainly. I probably wouldn't be THAT trusting, but then I wouldn't go to either of those extremes either; Assuming the above case, I would probably just ask to see some ID, write a letter to his editor suggesting his people would be better *out* of the bushes, and let the matter drop. we have something at the same level as MS's "UID" namestamp from Office97, and most people agree that that was beyond the allowable. I guess this is just a difference of opinion here. I agree that this is somewhat similar to the Office GUID thing, but I disagree that either issue merits the attention. A lot depends on how terrible you think us getting together to bitch about it on/. really is. I'm not suggesting that we should be sending hate-mail and dead cats to RN over this.<grin>
From an unbiased point of view, it could be any one of a dozen things - down to a "debug" switch left on in the full release that shouldn't have been. As you say, it is a PR disaster for them, all the less needed as they could have gathered the same information from the server ends, and not had this monkey on their backs. --
but you don't normally expect him to ask you questions about who you are and where you have just come from, and you definitely don't expect the manufacturer of the jukebox to have the right to do so.... Everyone is making the dangerous assumption here that RealNetworks is *combining* this information for their evil spying practices. No, I am not even assuming they are storing this information - but the mere fact they have built into the client an unannounced "feature" of delivering all this information to them is as worrying as the possible usage of it would be. If if you spotted a total stranger taking photographs of you from concealment, but they said "It's ok, I don't have any film in the camera, it's just for practice" would you A)Automatically trust him to be telling the truth and B)Say "ah, that's all right then" and wander away without even wondering WHY they were practicing, and more importantly, why on you?
Most all major products I download from the Internet ask me for my name, and bits of other information. Most (if not all) give me the option to decline sending this information in. Indeed - and as this is open and aboveboard I tend to fill in such pre-download sheets honestly. I am a lot more tolerant when they ask politely, and give an option to refuse.
SEPARATELY, RealNetworks is allegedly collecting information about your listening habits (tied to a userID not necessarily tied to your contact information). I'm not going to try and defend this, since I lack information one way or the other, but it seems like a great many of you are just assuming that RealNetworks uses this information together somehow. I can't speak for all of/., but I am not assuming this...
Further extending the music store analogy, let's say you get one of those Frequent Listener discount cards there. You give them your name, address, phone number, etc., and shop there every week or so. Now, the clerks know you by face, but that does NOT mean remotely that they automatically know your name and are linking every purchase in their head with your address and phone number. Yes, they collect the information, but that doesn't mean they're using it together. Odds are good that they do - somewhere, your purchasing habits (as represented by purchases you have used your card to make) are matched against each other, to make decisions about the sort of products that store will stock next week, and possibly (unless you have said otherwise) what sort of "special offer" targetted mail you will get the week after that. That said, I know quite a few of these schemes are purely loyalty schemes - the ones where you have to save "points" tend to be, anyhow - where they don't really care about tracking the information, just in getting you to visit their store preferentially.
Again, I'm not trying to defend RealNetworks here, but I do think many of you are taking this to an unfair level... Quite possibly - I notice a trend of/.ers jumping on the accused with both feet, without even considering that a mistake may have been made somewhere down the line (the recent Corel and Chinese Linux stories for example). I don't think this is the case here though - we have something at the same level as MS's "UID" namestamp from Office97, and most people agree that that was beyond the allowable. --
you mean you've never noticed the option to play "the most popular song" (the most played song of that day/week/whatever) on a jukebox? Indeed, I have - but it would be unusual for more than one track in six of those played to be directly selected by you; A lot of time will be spent listening to other people's choices, some of which you will disagree with, but none of which stem from your deliberate choice. To match your analogy, you would have to have the WEBSITE report back to RealNetworks what audio streams are being played, not the user agent.
There's plenty of information to keep track of in a jukebox. The artists get paid royalties when their music gets played on a jukebox. The people running the jukebox naturally want to put music in it that people will listen to (more money for them if they do), so wouldn't they want to know what the most played songs/artists/music types are? Indeed - the website owner is more than entitled to know exactly which streams are most popular, which least; the problem is that RealNetworks aren't really providing these channels, but they are gathering the information anyhow. They state that they aren't vaulting or forwarding the information, but obviously the possibility is there, or why do it? --
really, so what? i wish slashdot would stop banging on about this. IMO if you have a "right" to view information on someones web page,the owners have a "right" to maintain a profile of visitors and visitors habits. Interesting opinion - so tell me, when you go into shops to look around, do you expect to fill in a card with your name, address, and the names of the last five shops you visited? You don't have a "right" to view people's websites - they have chosen to display them publicly. If they didn't, then they would be password-protected. Most of the arguments about tracking and cookies revolve this idea.
anyone who visits a "jukebox" site and thinks that his/her listening habits is being not being monitored is naive. i mean, what happens when you listen to a real jukebox? Normally, you walk in, sit down, maybe by $PRODUCT the place sells, and listen. You might expect the owner to recognise you if you have been there before - but you don't normally expect him to ask you questions about who you are and where you have just come from, and you definitely don't expect the manufacturer of the jukebox to have the right to do so....
if you dont want your privacy "violated" then dont browse the net, shop, venture outside your house or pretty much anything. Why? why should my life be restricted to sitting in a shuttered room just to prevent a private company from gathering Valuable, Resellable market data from me? If they sent someone to folloy you from shop to shop, noting which shops you visited, what you looked at, and what you actually bought, I imagine you would get paranoid in pretty short order. why should this be any different if you are on the internet? --
I have a pretty basic question. My version of netscape encrypts with 128-bit RC4 enccryption. According to Fortify's website (https://www.fortify.net/sslcheck.html), such encryption is "a high-grade encryption connection, regarded by most experts as being suitable for sending or receiving even the most sensitive or valuable information across a network." While this encryption is for web transactions, and not for e-mail, I'm wondering if a 128-bit key can really be this secure. As far as we can tell, yes. With today's technology, a 128bit Symmetric key is unbreakable, provided the underlying crypto algorithm isn't flawed. No flaws are known in SSL at the moment - but it is a field where you can't prove the negative:+) --
Can't believe they'd ever ship without an OS - the average consumer would never buy it. (sorry for the typo - reposted) It depends a LOT on what you consider an "Average Consumer". I suspect a fair few business users could manage quite nicely with Ghost installs of $OS_OF_CHOICE (We do this already; rather than install many-many company-standard packages, we install ONE machine, take a Ghost of it, and then impress that image onto the remaining machines in the batch. To be honest, I can see this simplifying the job of $HELLDESK_PHONE_GUY - ship a single, bootable disk (possibly even a floppy!) that tests all the hardware shipped as standard and/or as options - all the user has to do is reboot+disk, and click a "test item xxx" button when told to. Any or all OS problems would then be the users', not the support guys - other than to ship out patches if needed. --
Slashdot Mirror
I wasn't aware at the time it had been deferred but we came to the conclusion (myself and others preent) that it would not be written into law as that assumption of guilt would set a legal precedent which all judges from then on would be forced to consider.
Reversing the Burden of Proof isn't unknown - for example, you are forced to PROVE you have car insurance / a licence if stopped by a policeman, or are liable for not doing so (the crimes you are guilty until proven innocent for here are driving without a licence, and driving without insurance)
That isn't the problem. what IS the problem is that it is impossible to prove that you don't have a key - or, worse yet, that you HAD the key, but have forgotten the secret password you used to access it. Normally, reversing the Burden of Proof is reserved for cases where producing such proof is easy for the accused (if you HAVE a driving licence and / or insurance, even if you have lost your original documents you can obtain at least a letter proving you had them) and awkward / impossible for the government (imagine if the Police had to contact every insurance company in the uk after a road accident, to ask "is person xxx insured to drive with you, or covered by anyone you DO insure?" - now imagine what hoops the insurance company would have to go through to handle several dozen calls per office per day of this nature, and who would end up paying for it).
--
There are express articles that exempt you from this sentence if you can prove or make clear that you, at the time of the question to produce the key, could not do that, as long as you do the moment you can provide it.
Yes, that's a wonderful option. I think a recent open letter to Jack Straw put the best slant on this (I don't have the URL to hand, but I am sure someone here on
- Basically, a group of hackers did the following:
- Created a key in the name of Jack Straw
- Uploaded that key to the keyservers
- had a criminal make a signed confession of a currently unsolved crime
- Scanned and encrypted that with the JackStraw key
- Destroyed all intermediate work - the key, the original (paper document) and the unencrypted disk file)
- posted the encrypted file to a website, along with a description of what they had done
So, here is the situation - any police officer can find a file that blatently contains information useful to clear up a crime. According to the file, the key is held by one Jack Straw, Home Secretary. How is Mr Straw to PROVE he does't have that key, and in fact has never had it? it has his name on it, after all.....BTW, can you point out the clause that allows you merely to "make clear" that you don't have the key, not prove the negative?
And that's what scares me the most: apparently a lot of thought hs gone into this bill, to try and be "fair", but those people doing the "thinking" still overlooked the basic unfairness of it all. I mean, there's even a provision to allow you to invalidate the key (which otherwise would be an offence, as well). They think that far, but think not close up, or something.
Hmm. it has obviously been "tweeked" a little more since the last draft I saw (which does't have that provision, and indeed, now even allows you to chose to decode the document yourself (the previous draft didn't even allow you to see the document claimed to be encrypted by your key)
I must admit though, in a quick scan, I couldn't find a option to revoke; any chance of a section number? I am not doubting you, just trying to locate these loopholes without having to re-read the entire thing again....
--
After a lot of complaints from pro-liberty and pro-cryptography groups (CyberLiberties, for example) it was finally removed from that bill and slotted into the RoIP bill - unchanged. The official slant was that the RoIP bill was a "better vehicle" for this.
The basic problems with it are these:
- You do not need to be even SUSPECTED of a crime - you just need a police officer to be OF THE OPINION that a given file is encrypted.
- If you can't hand over a key (because you don't have it, or the file isn't encrypted) then you are liable to a jail sentence
- If you tell anyone about having been served the warrant, you are liable to a larger jail sentence
- if you tell your solicitor about the warrant for purposes of your defence (and the only defence is to PROVE you don't have the key - an impossible task) HE is also bound by the clause not to tell anyone
- There is only one appeal to the warrant - not to a criminal court, but to a closed panel, not accountable to any judicial body and not required to give an explaination of their decision.
- You are not entitled to compensation unless the warrant was signed personally by the head of the Home Office (a government department). A warrant signed by a police inspector is just as legal, but doesn't carry any compensation.
If anyone has looked at my homepage in the last few months, now they know what my profile means--
Doesn't this amount to a ban on advertising other branches of the same shop? I would be surprised if America's rules allow this, and can't see the difference between banning display of website URLs and banning mention of that store's outlet in $COMPETING_MALL.....
--
Once we get beyond our current, Micky Mouse qubit limitations, adding one more bit will be trivial.
I must admit to having trouble discovering where this massive breakthrough will come from - you are claiming that you can increase the number of parallel universe "ops" practically without limit and at very low cost, which even to my limited understanding seems unlikely.
--
It has taken years of research just to build a two or three bit machine, and increasing a RSA or DH key by just a few bits would require doubling the number of "parallel universe computing cells" that are required to crack it. I can't see massive, secret research on this being funded well enough - particularly as it is "cheaper" in most senses to use other methods to defeat keys (most of which require physical intrusion to the machine in question or subversion of trusted personnel, but that has always been a standard operating procedure).
At worst, I think we will see the minimum key sizes considered secure increase, maybe by an order of magnitude, but without a change to the fundamental schemes in use - after all, with QC we are talking faster application of existing techniques, not a entirely new field.
--
Hmm. I keep mine on a Scramdisk (a free virtual disk encryptor available from Here. I also encrypt the data with PGP every so often and email it home, so I have a backup if I lose the scramdisk or forget IT's password
--
-=DaveHowe=-
even *I* could speed up Samba drastically - just take out all the checks for password and username, and give everyone full access to the entire tree :+) /good/ ideas to speed up Samba, I would either have tried them or suggested them (depending on if my coding was up to the trial)...... Password authentication is rarely ever a bottleneck
That wouldn't speed up samba drasticly, since that is not where the bottlenecks are. I imagine filename searching (case insensitive), name mangling, and oplocks are where the worse bottlenecks are.
Yes, I know - it was meant as a humourous statement, giving a patch everyone could see as being a *bad thing*. If I had any
--
even *I* could speed up Samba drastically - just take out all the checks for password and username, and give everyone full access to the entire tree :+) /good/ ideas to speed up Samba, I would either have tried them or suggested them (depending on if my coding was up to the trial)...... Password authentication is rarely ever a bottleneck
That wouldn't speed up samba drasticly, since that is not where the bottlenecks are. I imagine filename searching (case insensitive), name mangling, and oplocks are where the worse bottlenecks are.
Yes, I know - it was meant as a humourous statement, giving a patch everyone could see as being a *bad thing*. If I had any
--
As it should be. One of the reasons I like Open Source Software is that the programmers generally concentrate on real improvements, not arbitrary benchmarks.
Hmm. I
- Purely to match a benchmark that has no relationship to reality and
- that you don't sacrifice functionality, security or reliability just to eke out that extra half-milisec.
even *I* could speed up Samba drastically - just take out all the checks for password and username, and give everyone full access to the entire tree--
Hmm. RPMs are wonderful things - precompiled, ready-to-run executables in a container that allows the end-user to install it simply. Tarballs, by contrast, are just compressed blocks of source with a make script and are much harder to use
That said, tarballs were around long before RPMS, and there are still some distros out there that can't support RPM - but there aren't any that can't do tarball, plus the commercial Unixen (like HP) use a different system again. It is much easier to do it ONCE as a tarball, than five or six different ways for five or six different systems.
If I later get the packaged release (usually a few weeks later), then I gotta do that all over again! Man... it's times like these I wish linux was a little more standardized for some things. Packaging should not be this difficult.
I suspect at some point RPM will become the default - but for the moment, tarball is easier for the writers (if not the users). But that said, why are you installing the RPM over the top? once you get the tarball up and running, it must be easier to leave it than to de-install and re-install just so to have the pretty packet version rather than the homespun.... although I agree it makes life easier in the long run if you upgrade with another RH CD.
--
Now that there is an new version of Samba we should have those mindspring tests again. Wasn't a big part of that benchmark serving win98 clients through samba? :+)
Not entirely sure about that - they have fixed quite a few bugs, niggles and security issues, but I don't see much if anything that would make it faster. In any case, if the test showed that NT was still faster than Samba, it would be dismissed by the linux community as biased, due to NT being optimised for Win95 and not NT workstation, or just wrong. If it showed NT slower than Samba, then Microsoft would dismiss it for almost the same reasons
--
While I am glad to see China embracing Linux as it's official OS (and if I recall correctly, France now has a government policy of preferring OSS to closed-source) I seem to recall that the main Chinese-language Distro had some problems with The GPL Licence, in particular not redistributing the altered source code. Does anyone know if this has been resolved?
--
--
But not all the companies who make DVD players are american. As a fact, very few.
So this wouldn't have been much of a problem...
nbsp; Possibly not - but a lot of the recordings seem to be from the US, so I suspect they had a big say in the definition of the standard.
Non-US members could have defined a standard without them, of course, but would then run the risk of being the Betamax players in a VHS market....
--
I wouldn't be surprised if the lousy, five byte encryption on these things came down to making them US Export-Legal.... Even with the "new, improved" fast-track licencing, I believe each individual export has to be at least notified, and the paperwork overhead of tracking each batch of DVD players to the end user would have been astronomical. ;+)
And there, you thought the US government's export ban had no positive aspects
--
ZDNet have rushed off a piece on Online Privacy In response to the RealNetworks thing - it mentions a new "privacy statement" by RN, that they intend to release a patch to prevent the sending of the data, and bring up the MS GUID and Intel chip-id stories that have dropped out of sight lately...
--
ZDNet have rushed off a piece on Online Privacy In response to the RealNetworks thing - it mentions a new "privacy statement" by RN, that they intend to release a patch to prevent the sending of the data, and bring up the MS GUID and Intel chip-id stories that have dropped out of sight lately...
--
Except RealJukebox doesn't download things from websites. That's RealAudio you're thinking of. RealJukebox plays audio files and CDs on your computer, and therefore has no business sending any kind of data over the Internet. :+)
Hmm. well, according to the website it has downloading capabilities, but you are correct - It is primarily a flatfile player/recorder. This makes things even worse - it is *not* a public-player, as the name "jukebox" implies, but a personal "walkman" player
/me makes mental note to check on products next time....
--
I probably wouldn't be THAT trusting, but then I wouldn't go to either of those extremes either; Assuming the above case, I would probably just ask to see some ID, write a letter to his editor suggesting his people would be better *out* of the bushes, and let the matter drop. we have something at the same level as MS's "UID" namestamp from Office97, and most people agree that that was beyond the allowable.
I guess this is just a difference of opinion here. I agree that this is somewhat similar to the Office GUID thing, but I disagree that either issue merits the attention.
A lot depends on how terrible you think us getting together to bitch about it on
From an unbiased point of view, it could be any one of a dozen things - down to a "debug" switch left on in the full release that shouldn't have been. As you say, it is a PR disaster for them, all the less needed as they could have gathered the same information from the server ends, and not had this monkey on their backs.
--
Everyone is making the dangerous assumption here that RealNetworks is *combining* this information for their evil spying practices.
No, I am not even assuming they are storing this information - but the mere fact they have built into the client an unannounced "feature" of delivering all this information to them is as worrying as the possible usage of it would be. If if you spotted a total stranger taking photographs of you from concealment, but they said "It's ok, I don't have any film in the camera, it's just for practice" would you
A)Automatically trust him to be telling the truth and
B)Say "ah, that's all right then" and wander away without even wondering WHY they were practicing, and more importantly, why on you?
Most all major products I download from the Internet ask me for my name, and bits of other information. Most (if not all) give me the option to decline sending this information in.
Indeed - and as this is open and aboveboard I tend to fill in such pre-download sheets honestly. I am a lot more tolerant when they ask politely, and give an option to refuse.
SEPARATELY, RealNetworks is allegedly collecting information about your listening habits (tied to a userID not necessarily tied to your contact information). I'm not going to try and defend this, since I lack information one way or the other, but it seems like a great many of you are just assuming that RealNetworks uses this information together somehow. /., but I am not assuming this...
I can't speak for all of
Further extending the music store analogy, let's say you get one of those Frequent Listener discount cards there. You give them your name, address, phone number, etc., and shop there every week or so. Now, the clerks know you by face, but that does NOT mean remotely that they automatically know your name and are linking every purchase in their head with your address and phone number. Yes, they collect the information, but that doesn't mean they're using it together.
Odds are good that they do - somewhere, your purchasing habits (as represented by purchases you have used your card to make) are matched against each other, to make decisions about the sort of products that store will stock next week, and possibly (unless you have said otherwise) what sort of "special offer" targetted mail you will get the week after that. That said, I know quite a few of these schemes are purely loyalty schemes - the ones where you have to save "points" tend to be, anyhow - where they don't really care about tracking the information, just in getting you to visit their store preferentially.
Again, I'm not trying to defend RealNetworks here, but I do think many of you are taking this to an unfair level... /.ers jumping on the accused with both feet, without even considering that a mistake may have been made somewhere down the line (the recent Corel and Chinese Linux stories for example). I don't think this is the case here though - we have something at the same level as MS's "UID" namestamp from Office97, and most people agree that that was beyond the allowable.
Quite possibly - I notice a trend of
--
Indeed, I have - but it would be unusual for more than one track in six of those played to be directly selected by you; A lot of time will be spent listening to other people's choices, some of which you will disagree with, but none of which stem from your deliberate choice. To match your analogy, you would have to have the WEBSITE report back to RealNetworks what audio streams are being played, not the user agent.
There's plenty of information to keep track of in a jukebox. The artists get paid royalties when their music gets played on a jukebox. The people running the jukebox naturally want to put music in it that people will listen to (more money for them if they do), so wouldn't they want to know what the most played songs/artists/music types are?
Indeed - the website owner is more than entitled to know exactly which streams are most popular, which least; the problem is that RealNetworks aren't really providing these channels, but they are gathering the information anyhow. They state that they aren't vaulting or forwarding the information, but obviously the possibility is there, or why do it?
--
Interesting opinion - so tell me, when you go into shops to look around, do you expect to fill in a card with your name, address, and the names of the last five shops you visited? You don't have a "right" to view people's websites - they have chosen to display them publicly. If they didn't, then they would be password-protected. Most of the arguments about tracking and cookies revolve this idea.
anyone who visits a "jukebox" site and thinks that his/her listening habits is being not being monitored is naive. i mean, what happens when you listen to a real jukebox?
Normally, you walk in, sit down, maybe by $PRODUCT the place sells, and listen. You might expect the owner to recognise you if you have been there before - but you don't normally expect him to ask you questions about who you are and where you have just come from, and you definitely don't expect the manufacturer of the jukebox to have the right to do so....
if you dont want your privacy "violated" then dont browse the net, shop, venture outside your house or pretty much anything.
Why? why should my life be restricted to sitting in a shuttered room just to prevent a private company from gathering Valuable, Resellable market data from me? If they sent someone to folloy you from shop to shop, noting which shops you visited, what you looked at, and what you actually bought, I imagine you would get paranoid in pretty short order. why should this be any different if you are on the internet?
--
I have a pretty basic question. My version of netscape encrypts with 128-bit RC4 enccryption. According to Fortify's website (https://www.fortify.net/sslcheck.html), such encryption is "a high-grade encryption connection, regarded by most experts as being suitable for sending or receiving even the most sensitive or valuable information across a network." While this encryption is for web transactions, and not for e-mail, I'm wondering if a 128-bit key can really be this secure. :+)
As far as we can tell, yes. With today's technology, a 128bit Symmetric key is unbreakable, provided the underlying crypto algorithm isn't flawed. No flaws are known in SSL at the moment - but it is a field where you can't prove the negative
--
Can't believe they'd ever ship without an OS - the average consumer would never buy it.
(sorry for the typo - reposted)
It depends a LOT on what you consider an "Average Consumer". I suspect a fair few business users could manage quite nicely with Ghost installs of $OS_OF_CHOICE (We do this already; rather than install many-many company-standard packages, we install ONE machine, take a Ghost of it, and then impress that image onto the remaining machines in the batch.
To be honest, I can see this simplifying the job of $HELLDESK_PHONE_GUY - ship a single, bootable disk (possibly even a floppy!) that tests all the hardware shipped as standard and/or as options - all the user has to do is reboot+disk, and click a "test item xxx" button when told to. Any or all OS problems would then be the users', not the support guys - other than to ship out patches if needed.
--