There is no need to distinguish between users and developers, when it comes to the GPL or other free software licenses. The distinction is solely between users and distributors. If all you do is use the software -- whether that use involves clicking on buttons in the default GUI or breaking out gdb -- the GPL places no obligations on you. If, however, you distribute the software, then it does -- regardless of whether you've done any development at all.
Note that halon gas is also on the list of things not to be used in a metal fire -- it acts as an oxidizer. It sounds like they know what they're doing, though.
For equal mass, He is better than N2 -- much higher heat capacity. But the stuff is so fluffy (0.125 g/cc) and so expensive compared to LN2 that there's no good reason to use it. If LN2 works, but not well enough, the solution is to add more LN2 -- even if helium is somewhat better, more LN2 is cheaper and easier. (I don't actually know that LN2 works; my assumption would be that it does, but that you'd still rather have the fire hazard burn itself out if that's a viable option. Reignition is a very real danger.)
I don't know anything about the OS specifics, so this is a general comment. Things like that are a very good idea. OS support means that one group can get it right (assuming you trust them) and others can use it. The OS is in a good position to collect entropy, and gather it from whatever sources are available (hardware RNGs, keypress timings, mic input noise, wherever) and make it available appropriately.
Of course, if you're paranoid enough to be writing your own crypto, or living in a world where non-backdoored crypto is outlawed, you probably can't or won't use such a tool. For those without the full tinfoil regalia, though, it's an excellent thing to see.
There are more potential hidden speed trap spots than there are cars. If everyone slows down at every *possible* speed trap, that's far more efficient use of cars. Of course, they have to have enough cars out there to give the threat teeth.
There's good logic for it. On the other hand, I think most of the officers do it because they want to write tickets. I hate it, and would welcome a law requiring more openness in their operation. Bastards getting off on a power trip, most of the time.
Many number theory textbooks cover RSA these days. My computer security class (and its textbook) covered some of the modern symmetric key ciphers (DES, AES, etc) at least briefly, but that wasn't an entry-level class. I don't think I've seen strong crypto discussed in detail in an entry level course, aside from OTPs and RSA.
High bandwidth hardware RNGs aren't that hard. I could design a circuit that ran at a multi-kilobit output rate (plenty for text messaging), occupied under a square cm of board area, and a parts cost under $3 in qty 1k -- with provable minimums for the amount of quantum mechanically generated entropy. And the price would drop dramatically in large quantity. Or you could take VIA's approach of noisy ring oscillators that's very fast, almost certainly good enough, but not quite guaranteed -- and can be integrated on a modest sized piece of digital logic at very very low cost. So why don't more people use high quality random number generators? No one cares.
The hard part isn't generating the pads; it's managing them securely (or generating them on hardware not intended for the task). But, if you happen to want a good hardware RNG designed, it's quite doable (though not trivial; it requires attention to detail, as always).
While all the knowledge is out there, and you *can* do it yourself, getting every single detail right is not even close to easy. Are you sure you didn't leave some piece of the key swapped out to disk? Are you certain your random number generator was of sufficient quality and well seeded? Modern cryptosystems fail thanks to details, and the only way to get every detail right is many eyes and lots of work. Amateur efforts can certainly do it, but it's not easy for either them or the pros. Just remember, "I used RSA" isn't good enough. Witness the Netscape SSL problem, and the recent Debian SSH problems for examples of where the support infrastructure around the cryptosystem failed.
As you say, I'm sure price is the primary reason. But mercury? You have to be kidding. The toxicity and environmental issues make the sodium look easy to handle. It also costs ~10x the price of sodium per kg, and is 14 times as dense -- so it's 140x as expensive if they care about volume rather than mass (I'm guessing they do, but I don't know). And yes, I know metallic mercury is the least problematic form -- but that doesn't make it harmless, especially in the eyes of safety inspectors and insurance agents. And rightly so; the issues of long-term contamination from a spill on that scale are huge.
For many types of fires, including reactive metal fires, best procedure is to just let it burn if possible. In this case, I imagine you'd build the setup so that that *was* possible, and then focus your efforts on making sure you could get everyone out of the way efficiently. A huge pool of burning sodium is certainly dramatic, but if there's no person or property in danger then there's no necessarily anything wrong with it. The caustic lye dust should fall out of the air rapidly; don't stand down wind.
When it comes to exotic fires, there are techniques to fight them -- but by far the preferred one is to not fight it at all. Besides, suppose you did put it out -- you now have a damaged sphere of molten sodium that already caught fire once. Are you planning to approach it? I'd rather stand back and wait for it to go out if at all possible.
I'm sure they've informed the fire department, and I'm sure the fire department intends to get involved only if there's an immediate danger to life, or a risk of the fire spreading -- in which case they'll likely try to contain it without putting it out.
If you read the page, the fan is on the northbridge, not the CPU. Which makes me wonder: how much power does the northbridge draw, anyway? And what's the point of a 4 watt CPU if the northbridge draws more than that?
They're saying that dual boot (as opposed to windows-only or linux-only) requires more hardware. Since obviously only one OS would be using RAM, I conclude that they can't be talking about RAM, but that more storage requirements makes sense. $7/GB is a little high for wholesale flash prices, but it's in the right ballpark. Assuming that's the change, it should have no impact on battery life.
They may also want to add eg a hardware switch to choose which OS to boot; that would account for some of the cost.
That's insufficient. The danger from scipts comes from sites you *do* trust that get hacked. And if you grant permission per script, how many people are competent to read a script and judge it to be non-malicious? Of those, how many will feel like taking the time for every single script?
NoScript is good, and I use it, but it's far from sufficient to secure the browser against script-based attacks.
The cat looks up at you and, noticing a certain hungry gleam in your eye that it doesn't like one bit, jumps from the divan and hides in a box under the coffee-table. Just before the lid clicks shut, you see a tiny pendulum inside, and wonder if the cat's going to be alive for much longer. You reason that, since the cat could be either alive or dead, and you can't know which without opening the box, then therefore the cat must be both alive and dead -- or in other words, undead. That must be what funerals are for -- so that everyone knows for certain that the person going into the coffin is definitely dead, and you don't have to worry about quantum uncertainty causing zombies to burst out of the ground.
Yes... which this does not have. That was kinda my point. It doesn't matter what some other thing that hasn't been built could do; what matters is what the currently available stuff can do. And decrypt AES at 80Gbps isn't on the list.
Freenet runs over UDP with fully randomized ports. It acknowledges messages, but even the ACKs are encrypted. Window sizes are hidden behind the crypto as well. Except for the initial connection, handshaking is done by routing through previously established connections.
I'd like to see them DPI that. The best they can do is traffic analysis and decide it looks like P2P and throttle on that.
Slashdot Mirror
There is no need to distinguish between users and developers, when it comes to the GPL or other free software licenses. The distinction is solely between users and distributors. If all you do is use the software -- whether that use involves clicking on buttons in the default GUI or breaking out gdb -- the GPL places no obligations on you. If, however, you distribute the software, then it does -- regardless of whether you've done any development at all.
You mean like how you can't make ceramic or glass that's flexible?
Note that halon gas is also on the list of things not to be used in a metal fire -- it acts as an oxidizer. It sounds like they know what they're doing, though.
For equal mass, He is better than N2 -- much higher heat capacity. But the stuff is so fluffy (0.125 g/cc) and so expensive compared to LN2 that there's no good reason to use it. If LN2 works, but not well enough, the solution is to add more LN2 -- even if helium is somewhat better, more LN2 is cheaper and easier. (I don't actually know that LN2 works; my assumption would be that it does, but that you'd still rather have the fire hazard burn itself out if that's a viable option. Reignition is a very real danger.)
I don't know anything about the OS specifics, so this is a general comment. Things like that are a very good idea. OS support means that one group can get it right (assuming you trust them) and others can use it. The OS is in a good position to collect entropy, and gather it from whatever sources are available (hardware RNGs, keypress timings, mic input noise, wherever) and make it available appropriately.
Of course, if you're paranoid enough to be writing your own crypto, or living in a world where non-backdoored crypto is outlawed, you probably can't or won't use such a tool. For those without the full tinfoil regalia, though, it's an excellent thing to see.
There are more potential hidden speed trap spots than there are cars. If everyone slows down at every *possible* speed trap, that's far more efficient use of cars. Of course, they have to have enough cars out there to give the threat teeth.
There's good logic for it. On the other hand, I think most of the officers do it because they want to write tickets. I hate it, and would welcome a law requiring more openness in their operation. Bastards getting off on a power trip, most of the time.
Many number theory textbooks cover RSA these days. My computer security class (and its textbook) covered some of the modern symmetric key ciphers (DES, AES, etc) at least briefly, but that wasn't an entry-level class. I don't think I've seen strong crypto discussed in detail in an entry level course, aside from OTPs and RSA.
High bandwidth hardware RNGs aren't that hard. I could design a circuit that ran at a multi-kilobit output rate (plenty for text messaging), occupied under a square cm of board area, and a parts cost under $3 in qty 1k -- with provable minimums for the amount of quantum mechanically generated entropy. And the price would drop dramatically in large quantity. Or you could take VIA's approach of noisy ring oscillators that's very fast, almost certainly good enough, but not quite guaranteed -- and can be integrated on a modest sized piece of digital logic at very very low cost. So why don't more people use high quality random number generators? No one cares.
The hard part isn't generating the pads; it's managing them securely (or generating them on hardware not intended for the task). But, if you happen to want a good hardware RNG designed, it's quite doable (though not trivial; it requires attention to detail, as always).
While all the knowledge is out there, and you *can* do it yourself, getting every single detail right is not even close to easy. Are you sure you didn't leave some piece of the key swapped out to disk? Are you certain your random number generator was of sufficient quality and well seeded? Modern cryptosystems fail thanks to details, and the only way to get every detail right is many eyes and lots of work. Amateur efforts can certainly do it, but it's not easy for either them or the pros. Just remember, "I used RSA" isn't good enough. Witness the Netscape SSL problem, and the recent Debian SSH problems for examples of where the support infrastructure around the cryptosystem failed.
As you say, I'm sure price is the primary reason. But mercury? You have to be kidding. The toxicity and environmental issues make the sodium look easy to handle. It also costs ~10x the price of sodium per kg, and is 14 times as dense -- so it's 140x as expensive if they care about volume rather than mass (I'm guessing they do, but I don't know). And yes, I know metallic mercury is the least problematic form -- but that doesn't make it harmless, especially in the eyes of safety inspectors and insurance agents. And rightly so; the issues of long-term contamination from a spill on that scale are huge.
For many types of fires, including reactive metal fires, best procedure is to just let it burn if possible. In this case, I imagine you'd build the setup so that that *was* possible, and then focus your efforts on making sure you could get everyone out of the way efficiently. A huge pool of burning sodium is certainly dramatic, but if there's no person or property in danger then there's no necessarily anything wrong with it. The caustic lye dust should fall out of the air rapidly; don't stand down wind.
When it comes to exotic fires, there are techniques to fight them -- but by far the preferred one is to not fight it at all. Besides, suppose you did put it out -- you now have a damaged sphere of molten sodium that already caught fire once. Are you planning to approach it? I'd rather stand back and wait for it to go out if at all possible.
I'm sure they've informed the fire department, and I'm sure the fire department intends to get involved only if there's an immediate danger to life, or a risk of the fire spreading -- in which case they'll likely try to contain it without putting it out.
I'll take the 423 million mile warranty over the gas price lock-in any day...
If you read the page, the fan is on the northbridge, not the CPU. Which makes me wonder: how much power does the northbridge draw, anyway? And what's the point of a 4 watt CPU if the northbridge draws more than that?
Seriously. Here on /. we have standards to keep up.
They're saying that dual boot (as opposed to windows-only or linux-only) requires more hardware. Since obviously only one OS would be using RAM, I conclude that they can't be talking about RAM, but that more storage requirements makes sense. $7/GB is a little high for wholesale flash prices, but it's in the right ballpark. Assuming that's the change, it should have no impact on battery life.
They may also want to add eg a hardware switch to choose which OS to boot; that would account for some of the cost.
Just be glad it wasn't a bobcat.
That's insufficient. The danger from scipts comes from sites you *do* trust that get hacked. And if you grant permission per script, how many people are competent to read a script and judge it to be non-malicious? Of those, how many will feel like taking the time for every single script?
NoScript is good, and I use it, but it's far from sufficient to secure the browser against script-based attacks.
I always thought Vista was a two-bit OS, not four...
Storage = flash. Flash doesn't use power in the off state. That's how it manages to not have batteries in those memory cards...
Huh. Here I was thinking that the point was education, and that software with the source available was an important part of that.
The Mars Scorecard.
Mars currently leads, 20:19, though Earth is making a strong showing this decade.
As long as people have a need to exchange messages with people they can't actually send photons to directly, there will be a need for cryptography.
To quote one of my favorite games:
The cat looks up at you and, noticing a certain hungry gleam in your eye that it doesn't like one bit, jumps from the divan and hides in a box under the coffee-table. Just before the lid clicks shut, you see a tiny pendulum inside, and wonder if the cat's going to be alive for much longer. You reason that, since the cat could be either alive or dead, and you can't know which without opening the box, then therefore the cat must be both alive and dead -- or in other words, undead. That must be what funerals are for -- so that everyone knows for certain that the person going into the coffin is definitely dead, and you don't have to worry about quantum uncertainty causing zombies to burst out of the ground.Yes... which this does not have. That was kinda my point. It doesn't matter what some other thing that hasn't been built could do; what matters is what the currently available stuff can do. And decrypt AES at 80Gbps isn't on the list.
Freenet runs over UDP with fully randomized ports. It acknowledges messages, but even the ACKs are encrypted. Window sizes are hidden behind the crypto as well. Except for the initial connection, handshaking is done by routing through previously established connections.
I'd like to see them DPI that. The best they can do is traffic analysis and decide it looks like P2P and throttle on that.