What we have now with OSS is pretty much existance proof that it can work and a fuckload of anecdotes. We have exactly the same thing for closed source. The relative merits are going to take decades if not centuries to work out.
It must be SUN behind it! They're one of the only other companies that still make big iron. Plus, they take out two of their biggest problems in one fell swoop.
(I posted this because it's funny. I don't think it's remotely true.)
Multics was very secure. I'm not sure how you could possibly compare the two, since they faced completely different threats in completely different worlds.
It can't be the most secure by long way when there are other OSes that are at least comperable. Other contemporary OS's aren't all that far behind. I think use of OpenBSD is as much an indicator of commitment to security as it is tool a to aquire more security.
Most UNIXes meant for server use (ie: Solaris, AIX, Linux) can be secured to nearly the degree that OpenBSD can be, well enough that they would be statistically indistinguishable. Of course, OpenBSD takes the paranoia to a new level, and with security as the priority it's a lot easier and less error prone.
I went the laptop route (iBook), and the U of Calgary has reasonably good wireless access, so I'm pretty happy with the results.
What I like about a laptop in general: -tunez wherever I go. -wireless access in class keeps me awake when I'm bored to tears. -My writing is slow and messy, but with a laptop I have enough spare time to actually try some of the stuff being discussed. -The lab is crowded and noisy, but there are plenty of areas with wireless that are not.
What I like about an iBook in particular: -good battery life -small (12 inch) -MacOS is pretty stable (usually reboot with every OS upgrade) -The school's comp sci servers are Solaris, I have a Linux box at home... Moving between these is pretty much effortless, whether I'm sitting at the console, SSHing to them, or compiling code on them.
Starting with a HLL, however, prevents students from learning the concepts that the language was designed to deliberately hide.
Someone learning to program for the first time can become caught up in those very concepts when they should be getting things like how to conceptualize an algorithm. If you can't plan algorithms effectively, you're boned no matter what.
First of all, yes there's a lot of Java there, but I don't think there's a whole lot of Microsoft... out of 9 comp sci courses I've taken there, one so far even presented Windows as an option.
Second... Your information is wrong, period. C is first taught in CPSC233 (intro II), and used in the required courses CPSC355 (assembly), CPSC441 (networks), CPSC455 (low level arch), CPSC457 (operating systems), and probably others I don't remember. Most of the later courses are language agnostic.
Knowning how to think about/plan algorithms and good coding practices are more important than which language you use. A new language can be learned very quickly with these skills.
After being taught Java and getting some experience programming in general, learning C was easy.
Your proposed method would be slightly skewed, as the half-life of the material would give you an "expected" number of events in your sampling period, which would cause the result to lean towards either even or odd. The effect would be small, but present.
I can think of many solutions...
-Use an isotope with a really long half life, like Uranium. The change over the life of the device would be trivial. There are problems, like other atoms becoming radioactive, and isotopes in the decay chain having different half lives, but I think the bias could be kept small, like one bit in millions.
-Constantly recalibrate by keeping a history of the last N decays, where N is large enough to converge on the actual number sufficiently well, but small enough that if the device was captured it will not reveal what numbers you've generated. Adjust your interval accordingly. The calibration may be biased, but the bias itself will be random and changed with each decay.
-Count the time between decays, and generate bits by comparing the length of the intervals. If the second is greater, the random bit is a 1. If it's less, it's a 0. I think you could safely alternate between 0 and 1 on equal times, but don't take my word for it. This method would be the best, but half as fast.
Doesn't urandom need to wait to collect entropy before it produces output?
Also... who told you random data can't be compressed? That's completely wrong.
Consider a binary string X of length 1000000, where the contents of X are set randomly. It is possible for the contents of X to be all 0's.
I can describe the contents of X in fewer bits than the string itself. I shall do so now. "A binary string of length 1000000 where the contents are 0's.".
Since I can describe the string with another binary string of length less than 1000000, I can compress it. Since it's possible for that string to result if it's been randomly chosen, some random strings can be compressed.
-Apple will NOT switch to a chip that's not 64-bit. That's simply not an option. The costs of switching to a new platform will not be justifiable if they have to switch again in a few years.
-Apple will not abandon PowerPC until IBM's PowerPC 970 sinks or swims. It's a very mutually beneficial relationship, and while it may not keep up with x86's power, it won't be that far behind, and it *will* fit in the form factors that Apple needs. The really fast x86's put out way too much heat.
It'll be 5 or more years before they switch processor architechtures, maybe even longer, maybe never. x86 does not offer sufficient advantages to put up with the heat of the fast x86 processors. Apple is very strong with laptops, and they're only going to get stronger there. Even their desktop offerings are compact. Small is important, quiet is important, batteries are important, and x86 can not beat PPC in with these.
Linux: You would be foolish to not consider it, you would be foolish to pick it automatically.
I hate it when zealots yell at me for saying that. We are best served by a large number of choices. You can't be good at everything, and specialization usually decreases suitability for other tasks. That's just the way the universe works, and all the kernel patches in the world won't make Linux the best choice for everything.
BSA represents that the information in this notification is accurate and states, under penalty of perjury, that it is authorized to act in this matter on behalf of the copyright owners listed above.
Does the BSA represent OpenOffice.org? Perjury it is then...
I don't think so because the RIAA's goal isn't to simply "kill file sharing" -- it's to kill the file sharing of works by artists signed to RIAA member labels.
I think they would be opposed to it if artists started jumping ship and distributing their (new, and self owned) works online, even if there was no piracy of RIAA owned material. No matter what, their death grip on music has been vastly reduced, and will never become as strong as it has been in the past, even if they win every battle.
So combine a down economy with a public increasingly turned off by by the major labels and there you go. If the RIAA spent half as much turning people ON to new music as they do trying to turn people OFF to file sharing, they'd probably be better off.
Plus, all their efforts to shut down file sharing networks have generated more publicity than any advertising blitz ever could have, and it's resulted in penetration into markets that would have taken much longer to start using it.
No, I can't, and I'm seriously entertaining the possibility that I'm dead wrong about that. My recollections must be of the fuss that people made when it almost snuck in as a rider.
Couldn't artists who use online file sharing as a form of advertisement sue the RIAA for curtailing their activities?
I know the law in the US allows them to disable file sharing computers without worrying about damages, but would it protect them from damage it causes other people with secondary effects such as that?
Who wants your data (or signature) so bad that they're prepared to mount a ridiculously expensive, time-consuming cryptanalytic attack (that gets the data maybe a year later?) but not prepared to date your secretary, clean your building, root your machines, break in and steal it, or kidnap your children?
I think the idea, my idea anyway, is to make large scale monitoring of communications almost impossible by way of routine use of strong encryption.
If I have information "they" really want, they can of course date my secretary, clean my building, root my machines, break in and steal it, or kidnap my children, but if millions of people are using strong encryption, then large scale monitoring and data mining becomes impractical. "They" are back to where they were before, since the other methods typically require actual people to be involved.
With enough people encrypting their communications with strong encryption, even magical quantum computers would be hard pressed to monitor all communications. As I understand it, even though quantum computers might decrypt a message or find a private key with a linear-or-better time complexity, they will not have a very high number of operations per second, so a high volume of messages may be able to simply overwhelm such computers, or at the very least increase the scale of the operation to such an extent that it becomes public knowledge.
that makes me a little paranoid. I think the better solution would be to increase the amount of encrypted traffic as opposed to just key length, thereby making the data that much harder to sift through.
If there was a mechanism to automatically create and distribute really huge single use keys, and e-mail (or whatever) clients were to be designed to take advantage of such a mechanism, it would become impractical to keep up. The keys would have to be as big as CPU and bandwidth limitations allow, not as big as we think they have to be to stay safe for X years. Some completely random traffic might be nice too.
I wouldn't mind waiting a tenth of a second for an e-mail to be decrypted.
We would also have to collectively take more interest in the security of our own systems, as with the above mechanism in place, it would become easier to compromise the computers themselves. Kind of an anti-TCPA.
So at this moment in time they *may* have the ability to crack a few hundred keys in one person's lifetime.
I'd be surprised if the US gov't were spending less than a billion dollars anually on computer equipment meant exclusively for cryptanalysis. They undoubtedly have the ability to deal with many times that number of keys.
No-one is going to break a 4096/4096 RSA new-style PGP key using SHA-512 as the hash anytime soon, unless someone is hiding a magic quantum computer.
I'd hate to be accused of joining the tinfoil hat crowd, but it's not completely outside the realm of the possible, especially if you need to plan for the future.
file swapping will continue to be the RIAA's excuse because it's easier than the truth.
Quite right. It's easier to blame pirates and terrorists than it is to figure out a way of doing things that's viable in the long term.
In Canada, we recently had a significant increase in the levy on recordable media. This is allowed under part 8 of the Copyright Act. Most people that know about it see it as granting them the moral justification as well as the legal right (also allowed under certain conditions in part 8 of the Copyright Act) to copy as much music as want. I would never go on record admitting to do that myself, but I am aware of many people that see it that way.
I think that exactly the same thing would happen if ISP's had to increase fees in the US, but to a greater extent because a great many more people need/want Internet access. People might even have to stop buying CD's to balance the books...
Slashdot Mirror
Am I the only one that was scared for his battery?
What we have now with OSS is pretty much existance proof that it can work and a fuckload of anecdotes. We have exactly the same thing for closed source. The relative merits are going to take decades if not centuries to work out.
aha!
It must be SUN behind it! They're one of the only other companies that still make big iron. Plus, they take out two of their biggest problems in one fell swoop.
(I posted this because it's funny. I don't think it's remotely true.)
Multics was very secure. I'm not sure how you could possibly compare the two, since they faced completely different threats in completely different worlds.
It can't be the most secure by long way when there are other OSes that are at least comperable. Other contemporary OS's aren't all that far behind. I think use of OpenBSD is as much an indicator of commitment to security as it is tool a to aquire more security.
Most UNIXes meant for server use (ie: Solaris, AIX, Linux) can be secured to nearly the degree that OpenBSD can be, well enough that they would be statistically indistinguishable. Of course, OpenBSD takes the paranoia to a new level, and with security as the priority it's a lot easier and less error prone.
I went the laptop route (iBook), and the U of Calgary has reasonably good wireless access, so I'm pretty happy with the results.
What I like about a laptop in general:
-tunez wherever I go.
-wireless access in class keeps me awake when I'm bored to tears.
-My writing is slow and messy, but with a laptop I have enough spare time to actually try some of the stuff being discussed.
-The lab is crowded and noisy, but there are plenty of areas with wireless that are not.
What I like about an iBook in particular:
-good battery life
-small (12 inch)
-MacOS is pretty stable (usually reboot with every OS upgrade)
-The school's comp sci servers are Solaris, I have a Linux box at home... Moving between these is pretty much effortless, whether I'm sitting at the console, SSHing to them, or compiling code on them.
Touche.
SPARC assembly is a bit easier because of the way the registers and the stack are set up, but that's not that much extra to learn.
Starting with a HLL, however, prevents students from learning the concepts that the language was designed to deliberately hide.
Someone learning to program for the first time can become caught up in those very concepts when they should be getting things like how to conceptualize an algorithm. If you can't plan algorithms effectively, you're boned no matter what.
First of all, yes there's a lot of Java there, but I don't think there's a whole lot of Microsoft... out of 9 comp sci courses I've taken there, one so far even presented Windows as an option.
Second... Your information is wrong, period. C is first taught in CPSC233 (intro II), and used in the required courses CPSC355 (assembly), CPSC441 (networks), CPSC455 (low level arch), CPSC457 (operating systems), and probably others I don't remember. Most of the later courses are language agnostic.
Knowning how to think about/plan algorithms and good coding practices are more important than which language you use. A new language can be learned very quickly with these skills.
After being taught Java and getting some experience programming in general, learning C was easy.
The worst virus/worms these days aren't written in assembly... Besides, the U of C assembly courses are SPARC, and most viruses are for x86.
I'm in comp sci at the UoC... Becker mentioned this to me, but I had no idea it was out of the ordinary.
Your proposed method would be slightly skewed, as the half-life of the material would give you an "expected" number of events in your sampling period, which would cause the result to lean towards either even or odd. The effect would be small, but present.
I can think of many solutions...
-Use an isotope with a really long half life, like Uranium. The change over the life of the device would be trivial. There are problems, like other atoms becoming radioactive, and isotopes in the decay chain having different half lives, but I think the bias could be kept small, like one bit in millions.
-Constantly recalibrate by keeping a history of the last N decays, where N is large enough to converge on the actual number sufficiently well, but small enough that if the device was captured it will not reveal what numbers you've generated. Adjust your interval accordingly. The calibration may be biased, but the bias itself will be random and changed with each decay.
-Count the time between decays, and generate bits by comparing the length of the intervals. If the second is greater, the random bit is a 1. If it's less, it's a 0. I think you could safely alternate between 0 and 1 on equal times, but don't take my word for it. This method would be the best, but half as fast.
Doesn't urandom need to wait to collect entropy before it produces output?
Also... who told you random data can't be compressed? That's completely wrong.
Consider a binary string X of length 1000000, where the contents of X are set randomly. It is possible for the contents of X to be all 0's.
I can describe the contents of X in fewer bits than the string itself. I shall do so now. "A binary string of length 1000000 where the contents are 0's.".
Since I can describe the string with another binary string of length less than 1000000, I can compress it. Since it's possible for that string to result if it's been randomly chosen, some random strings can be compressed.
I think we can make a few assumptions...
-Apple will NOT switch to a chip that's not 64-bit. That's simply not an option. The costs of switching to a new platform will not be justifiable if they have to switch again in a few years.
-Apple will not abandon PowerPC until IBM's PowerPC 970 sinks or swims. It's a very mutually beneficial relationship, and while it may not keep up with x86's power, it won't be that far behind, and it *will* fit in the form factors that Apple needs. The really fast x86's put out way too much heat.
It'll be 5 or more years before they switch processor architechtures, maybe even longer, maybe never. x86 does not offer sufficient advantages to put up with the heat of the fast x86 processors. Apple is very strong with laptops, and they're only going to get stronger there. Even their desktop offerings are compact. Small is important, quiet is important, batteries are important, and x86 can not beat PPC in with these.
Linux: You would be foolish to not consider it, you would be foolish to pick it automatically.
I hate it when zealots yell at me for saying that. We are best served by a large number of choices. You can't be good at everything, and specialization usually decreases suitability for other tasks. That's just the way the universe works, and all the kernel patches in the world won't make Linux the best choice for everything.
What I find funny is this...
BSA represents that the information in this notification is accurate and states, under penalty of perjury, that it is authorized to act in this matter on behalf of the copyright owners listed above.
Does the BSA represent OpenOffice.org? Perjury it is then...
I don't think so because the RIAA's goal isn't to simply "kill file sharing" -- it's to kill the file sharing of works by artists signed to RIAA member labels.
I think they would be opposed to it if artists started jumping ship and distributing their (new, and self owned) works online, even if there was no piracy of RIAA owned material. No matter what, their death grip on music has been vastly reduced, and will never become as strong as it has been in the past, even if they win every battle.
So combine a down economy with a public increasingly turned off by by the major labels and there you go. If the RIAA spent half as much turning people ON to new music as they do trying to turn people OFF to file sharing, they'd probably be better off.
Plus, all their efforts to shut down file sharing networks have generated more publicity than any advertising blitz ever could have, and it's resulted in penetration into markets that would have taken much longer to start using it.
No, I can't, and I'm seriously entertaining the possibility that I'm dead wrong about that. My recollections must be of the fuss that people made when it almost snuck in as a rider.
:)
Thanks for pointing out my mistake.
I was under the impression that it did, since I seem to remember a lot of bitching and moaning when the law that allowed this was passed.
If I'm wrong, then thank you for the correction.
Couldn't artists who use online file sharing as a form of advertisement sue the RIAA for curtailing their activities?
I know the law in the US allows them to disable file sharing computers without worrying about damages, but would it protect them from damage it causes other people with secondary effects such as that?
Who wants your data (or signature) so bad that they're prepared to mount a ridiculously expensive, time-consuming cryptanalytic attack (that gets the data maybe a year later?) but not prepared to date your secretary, clean your building, root your machines, break in and steal it, or kidnap your children?
I think the idea, my idea anyway, is to make large scale monitoring of communications almost impossible by way of routine use of strong encryption. If I have information "they" really want, they can of course date my secretary, clean my building, root my machines, break in and steal it, or kidnap my children, but if millions of people are using strong encryption, then large scale monitoring and data mining becomes impractical. "They" are back to where they were before, since the other methods typically require actual people to be involved.
With enough people encrypting their communications with strong encryption, even magical quantum computers would be hard pressed to monitor all communications. As I understand it, even though quantum computers might decrypt a message or find a private key with a linear-or-better time complexity, they will not have a very high number of operations per second, so a high volume of messages may be able to simply overwhelm such computers, or at the very least increase the scale of the operation to such an extent that it becomes public knowledge.
that makes me a little paranoid. I think the better solution would be to increase the amount of encrypted traffic as opposed to just key length, thereby making the data that much harder to sift through.
If there was a mechanism to automatically create and distribute really huge single use keys, and e-mail (or whatever) clients were to be designed to take advantage of such a mechanism, it would become impractical to keep up. The keys would have to be as big as CPU and bandwidth limitations allow, not as big as we think they have to be to stay safe for X years. Some completely random traffic might be nice too.
I wouldn't mind waiting a tenth of a second for an e-mail to be decrypted.
We would also have to collectively take more interest in the security of our own systems, as with the above mechanism in place, it would become easier to compromise the computers themselves. Kind of an anti-TCPA.
So at this moment in time they *may* have the ability to crack a few hundred keys in one person's lifetime.
I'd be surprised if the US gov't were spending less than a billion dollars anually on computer equipment meant exclusively for cryptanalysis. They undoubtedly have the ability to deal with many times that number of keys.
No-one is going to break a 4096/4096 RSA new-style PGP key using SHA-512 as the hash anytime soon, unless someone is hiding a magic quantum computer.
I'd hate to be accused of joining the tinfoil hat crowd, but it's not completely outside the realm of the possible, especially if you need to plan for the future.
Call me crazy, but wouldn't it be relatively easy to create a signal (RF, microwave, etc) powerful enough to destroy such chips?
file swapping will continue to be the RIAA's excuse because it's easier than the truth.
Quite right. It's easier to blame pirates and terrorists than it is to figure out a way of doing things that's viable in the long term.
In Canada, we recently had a significant increase in the levy on recordable media. This is allowed under part 8 of the Copyright Act. Most people that know about it see it as granting them the moral justification as well as the legal right (also allowed under certain conditions in part 8 of the Copyright Act) to copy as much music as want. I would never go on record admitting to do that myself, but I am aware of many people that see it that way.
I think that exactly the same thing would happen if ISP's had to increase fees in the US, but to a greater extent because a great many more people need/want Internet access. People might even have to stop buying CD's to balance the books...