if (a), then it's inevitable that the DRM-restricted computer can be manipulated into running a virtualization of a DRM-free computer. Except the goal of the RIAA is not "no freedom shall exist anywhere," but that "RIAA music must not be free." If your DRM-free virtual computer gets its sound I/O filtered for copyrighted content (even assuming that it has sound I/O), then the RIAA win. If its video output is filtered for copyrighted content, or can't even output video that isn't severely degraded, then the MPAA win. If it's implemented in Javascript, and therefore too slow to use fancy codecs, they both win.
I'm not saying that this is possible given the realities of engineering, but it is possible in theory.
Alan Turing has explained why their goals are impossible on a Turing machine. Computers aren't Turing machines. Turing machines don't have tamper-resistant hardware.
Yeah, I was comparing to shot put, which is also 16lb, but the record is more like 70ft. Not sure if it's more like a shot or more like a hammer... depends if a human can use a sling effectively on something so heavy.
No kidding. A (very strong) human could probably throw a bowling ball half that far. A trebuchet could probably throw objects 10x heavier 10x the distance, and with better incendiaries to boot.
I'd rather the infinitesimally higher risk of pulling my laptop off the desk with the very real (as in it's happened) risk of the stupid MagSafe cable falling out without my noticing it, and my battery going dead. I've had the power connector fall out, although I don't think I've actually deadened a battery that way (they go to sleep when it reaches 10% or something). But yes, it's annoying. I've also nearly pulled about 3 different laptops off of desks by tripping over their cables. I've also seen laptop power cables damaged by people tripping over them, and I've seen power supplies damaged because power cables broke off in them.
I currently use an laptop well under 3 pounds, the IBM/lenovo X61. It has very similar specs, with a core 2 duo and GMA X3100 (which is the best *embedded* card on the market). I have an x61s. It's a nice line. Like the x61, they're about 3lbs (not "well under 3lbs", like maybe 2.9?) with a 3/4-hour battery, or 3.5 with the extended 6/8 battery. The s gets more battery life than the non-s, and is maybe slightly lighter (?), but slower.
The differences that I note are this: 1. The air is a lot thinner and less sturdy than the X61 for the same weight. This may be a stylistic plus, but it also makes the hardware a lot less breakable, and I think they made the wrong choice here. Maybe, maybe not. It does have a metal shell, unlike the x61, and MagSafe, so you're less likely to pull it off a desk. Though I wonder what the metal shell will do to wireless reception. Also, I hate to say it, but the x61 shell is kind of shoddy for a ThinkPad. Mine is already cracked around the CPU fan vent, and I've been pretty nice to it.
2. The Air is only 1.6 Ghz for a core 2 duo. My X61 came in at 2.2 Ghz. It uses a low-voltage processor, like the x61s. It gets more battery life than the x61 (even the s), at least in the 3lb configuration, unless Apple is lying more than Lenovo. Anyway, many ultraportables use 1.2GHz ULV processors, so Apple is taking the middle of the road here.
3. The Air costs a lot more. My X61 came in at about $1400, whereas the air starts out at $1800! That's $400 for a brand identity on slightly inferior hardware. Expensive, yes, but inferior isn't clear yet. It has a lot of features that the X61 doesn't. 802.11n, keyboard backlight (that LED on the ThinkPad is not a substitute), 13.3" higher-res display, magsafe, magnetic latch, multitouch trackpad (conspicuously missing from the x), camera, microphone. Also, let's admit it, ThinkPads are ugly. Not as bad as Dells, but nothing compared to the shiny of a high-end Mac.
Also, it ships with Leopard instead of Vista.
4. The Air has a tiny by current standards harddrive (80 gigs) probably to make the solid state version not look so bad. It has a 1.8" HDD. Smaller and uses less power, but more expensive and less capacity.
5. The Air's one strong point is that it has DVI out, whereas the X61 only has VGA out. Since there are DVI to s-video adapters, this means the Air can play movies on the tv, whereas the X61 cannot. Yup. And you can connect it to a nicer LCD. On the other hand, the other ports are pretty limited. No ethernet (not "airy" enough?), no mic-in (of course, it has an internal mic), no firewire (oh, the irony), no sd reader, no express slot. And only one USB port. This isn't as bad as it sounds, because you probably have a hub on your desk anyway, and you're not going to need more than one port on the road. Probably.
Still, it seems silly not to include Ethernet. I suppose there's an adapter, but blah.
6. The air has an optional (it's in the $3000 dollar model) solid state drive. I'm not sure what real benefits you get by paying for this. Faster (especially for random reads), lower power consumption, lighter weight, no moving parts, more rugged, geek cred.
I, for one, welcome our new computer-generated overlords. I'd like to remind them that as a trusted TV personality, I can be helpful in rounding up others to toil on their underwater limpet mines.
Disclaimer: I am not a lawyer, but I did talk about this with a lawyer a few years ago.
Say for example, I take a digital representation of a copyrighted work, say an mp3 file, and then I proceed to use RAID6 algorithm where I split the file up into 6 chunks, any 4 of which someone can re-create the file. Distribution of 3 of those chunks by me is not a copyright violation since the original work cannot be reproduced. All the chunks are derivative works of the original file. Distributing them is a copyright violation.
Similarly, if I produce a one time pad, the length of the mp3 file and I publish it as "Best of Santana", I have in theory not provided anything other than an unintelligible stream of random bits. Probably true, since the length of the file isn't generally copyrightable.
However, if someone publishes "the key" that once xor'd with the file I originally published, generates the original file, who is in violation? The other guy is in violation. When he made that "key" (which is really the ciphertext, not the key), he prepared a derivative work of your pad (which is probably not copyrightable) and of the original song.
With a one-time pad, an outsider can't tell which is the key and which is the ciphertext. That means that without some sort of external evidence, a court "shouldn't" find either of you liable. Of course, if you and the other guy worked together to do this, you're both liable.
Handling a strongly-encrypted file probably infringes the artist's copyright, even if the key was destroyed. But you have an ironclad defense if you honestly thought it was just a random collection of bits (while ignorance of the law is not a defense, ignorance of the facts can be). Also, if the key was destroyed, the artist has no actual damages; while he could try to sue you for statutory damages, it would probably get thrown out of court.
"Not completely connected" is a very strange phrase... either there's a connection between the two networks or there isn't. I don't know what it means to be connected at some points and not at others. There could be a data diode between them. That would allow the passengers to see flight path and sensor statistics and hear the cabin radio, and allow the cabin lights and indicators to be controlled from the cockpit side without being physically isolated, but nothing on the cabin side could influence the cockpit side. They might also want to electrically isolate the two sides to block power surges from reaching the avionics (although they should already be hardened enough to handle that, because lightning strikes airplanes sometimes).
It's kind of scarry to see this attitude (IP = imaginary) coming from american students. Forget right and wrong for a moment and think about survival and self-interest. Apparently these students don't realize that the country they live in has no other real 'industry' anymore. It could be that those college students think IP is a stupid thing to base one's economy on. Because, you know, it's imaginary.
There is no such thing as too much RAM. If you have it, you'll use it. I'm not sure about Windows, but on a Linux laptop, this isn't true. I have a laptop with 4 gigs (for VMWare, compiling, and other potentially memory-intensive tasks), and I usually don't leave it on long enough to max that out with disk caches. For instance, right now it's been on an hour or so, and it's using less than 900 MiB. By running a bunch of find/s, thereby insuring that almost all filesystem metadata is cached, it still doesn't go higher than 1.5GiB.
Of course, for large compile jobs, VMWare, model checking, etc the 4GiB is wonderful.
Okay, have you actually studied cryptography at even a basic level? Have you? Because I have.
It's basically impossible (read, an NP-hard problem at least) to *prove* that a particular cryptosystem is unbreakable. It's not NP-hard, it's much worse. It (almost always) requires proving that P != NP. There's a million-dollar bounty on that problem.
For block ciphers and hashes, you instead prove that the algorithm is resistant to large, known families of attacks. You justify its design. You get rid of "magic constants" which could be back doors. Then you and a hundred of your cryptographer friends try to break it for a long time. If they can't break it, you hope it's secure.
For other systems, you prove that your system is secure assuming that a certain problem is hard. For instance, you can prove that a certain block-cipher-based PRNG is secure if the underlying block cipher is secure. This is practically a requirement these days: people generally won't use your algorithm unless you "prove" that it's secure when correctly implemented. ("Prove" is in quotes because the hard problem might turn out not to be hard, or the "proof" might be wrong, or your key might be too small, or P might equal NP, etc.)
The problem with Dual_EC_DRBG is that it's (mostly) secure, under the assumption that the (well-respected) "Elliptic Curve Decision Diffie-Hellman Problem" is hard, for randomly-chosen parameters. For any set of parameters (P,Q), there's a back door, but the back door is hard to find. This is built in to the design of the system. Now, NIST claims that they generated their parameters randomly, and that nobody has the key to the back door. But they can't prove it. They (or the NSA, or someone else) might have generated the parameters maliciously, so that they know the back-door key. There's pretty much no way to know.
The reality is, cryptography requires years of research and peer review to be reasonably sure that it's right. Look at all of the cyphers in the past that have suddenly been broken after N years of production use. Now also consider that government standards cost hundreds of thousands of dollars to create, and probably as much again to update. This is a relatively new spec. Nobody's using it, because of the threat of a back door, because of a different minor flaw, because it's slow, and because there are older specs that don't have these problems. It would be relatively easy to change the parameters to something where NIST can "prove" (as above) that they don't have the back-door key. But they haven't, which makes people suspicious.
I'm pretty sure you can find this particular random number generator in other places, if you really try. I'm pretty sure you can't. It's very slow. It's not something a non-cryptographer would think of. And if you came up with it anyway, you'd generate the parameters yourself, rather than trusting some other person to generate them for you.
As for backdoors, anybody who is paranoid about this issue will ignore or disbelieve me when I say that there is no backdoor that I am aware of. The Common Criterial evaluators look for such issues and submit issues for fixing if and when they find them. I don't think you understand the issue here. Nobody is claiming that this represents a backdoor in Microsoft's code. The issue is that the approved parameters for the algorithm Dual_EC_DRBG could be a back door.
Essentially, Dual_EC_DRBG is a public-key encryption algorithm* disguised as a random number generator. The NIST parameters are a public key. The generator has some painfully-generated random internal state. It steps by encrypting* using the internal state as a parameter. It outputs the ciphertext*. It sets the plaintext* as the next state. To recover the next state, or even to distinguish the next state from random*, is equivalent to breaking the encryption algorithm. EC-DH is a pretty well-respected algorithm, so probably nobody is going to break it. This would imply that the DRBG is secure, i.e. nobody else can distinguish it from actual random numbers.
*Not quite accurate, but a full explanation would be an automatic TL;DR.
Unless, of course, the government (or someone else) has the private key (the "back door") corresponding to that public key. They probably don't, but they almost certainly can't prove it. Since Dual_EC_DRBG is slow, only paranoid people would recommend it anyway. Because of the potential back door, no cryptographer thinks you should use it, but Microsoft has included it anyway. This is probably to say they meet some government standard, but it's causing a tempest in a teapot, possibly because it reminds people of the whole _NSAKEY mess.
The difference between parallel programming and multithreaded programming is this... with a parallel algorithm, different parts of one task/thread are done on separate CPUs, whereas with multithreaded programming each one thread/task is done entirely on one processor. It's not a semantic difference. My concurrency prof explained it like so: concurrent programs are semantically multithreaded, and the different threads interact with each other. That is, they logically have more than one operation going on at a time. Parallel programs are physically multithreaded. That is, they do operations one more than one hardware core. Concurrency is about semantics, whereas parallelism is about performance.
These two concepts are somewhat orthogonal: a program might have one thread of control, but its compiler or libraries farm out operations to more than one core, or to a large vector unit. More commonly, it might have many logical threads (to repaint the GUI and contact the network, for instance), even if these all run on the same physical core. Some programming languages' concurrency packages don't even support multiple cores (eg, Concurrent ML); these often scale to more threads than those which do support multiple cores, because they have fewer issues with context switches and synchronization.
Yup. A simple name change would go really far. In fact, I think that's the biggest thing fusion power has going for it. We're always told "Nonono, it's not Nuclear [fission] power, it's [nuclear] Fusion power!" Nevermind that fusion generates significant quantities of radioactive waste that needs to be quarantined, and in quantities comparable to fission power. Yes and no. Fusion has a lot of other advantages, or would if we could make it economical. For one thing, the fuel is many orders of magnitude cheaper and more plentiful, and what's more it's safer to transport. For another, fusion power would be harder to weaponize, and so could be used in countries which are not currently nuclear states (for instance, Iran). Some fusion reactions do not produce radioactive waste (eg, hydrogen-boron fusion). The others irradiate the reactor vessel, but don't produce any other long-lived radioisotopes, so there's no liquid waste sitting in storage tanks.
So while I agree that the risks of nukular power are overhyped, fusion goes a long way toward avoiding them.
Disclaimer: I think that a limited form of copyright is a good idea, but that the current copyright goes way too far. I am not a lawyer. This is not legal advice.
See, one of the lovely things about copyright law is that the author of the work gets to decide what to do with it. If they feel like their work should be distributed to whomever, whenever, however, they can certainly decide that. There are other people who do not want that. By obliterating copyright, you remove their rights. Copyright isn't a God-given right, and there's nothing inherently wrong with removing it. It's not guaranteed in the US constitution, so the US could remove it too (but this would require withdrawing from treaties).
Furthermore, you can still limit redistribution of your work. When you distribute it, require that the recipients sign an appropriate contract.
Nobody is forced against their will to charge money for people to view or redistribute their work. No, but they are forced to copyright their work (it's automatic). This means that unless the author explicitly says otherwise, nobody can redistribute their work at all (except when this would constitute fair use) until 70 years after their death. Since many publications are anonymous or pseudonymous, obtaining a redistribution license is often unduly difficult. In cases like this, copyright inhibits cultural development, and doesn't give anyone anything in return.
In addition, trivial and incidental use of a work is still infringement, and often isn't covered by fair use (because it's not transformative/criticism/parody/research/teaching). This turns audio and video projects into a copyright minefield. Your documentary catches a single frame of The Simpsons on some random TV in the background? Copyright violation. $15,000 per copy you made, or maybe (if we're feeling nice) we'll just enjoin you from distributing your documentary. Your song's melody sounds vaguely like some other song? Violation. Heck, if you tell to a co-worker a joke that some guy cracked on the subway, that's also a violation. Even if you attribute it.
There is an argument to be made that copyright is too long. On the other hand, there's the opposite argument that copyright should be eternal and instead the definition for derivative works should be loosened slightly. Those arguments, at least the ones I've heard, are garbage. They revolve around the idea that "intellectual property" is the same as physical property, in that copying it is the same as stealing. In this case, it shouldn't expire: physical property rights sure don't. But then they assert that intellectual property is different from physical property, in that you can sell it to me and I still won't own it. (Or rather that when you say you're "selling" it, you mean something which is totally different from the sale of physical property.)
Or perhaps you had a different argument in mind. In which case, please elaborate.
[W]hy should you decide what I may or may not do with my writings? Why should you be able to restrict the freedom of those who purchase your writings, and who have not signed any sort of contract with you?
However, I cannot in any respect see how copyright law is evil. It may be unenforceable; it may be unreasonable, even. Neither of those equates with evil. There's a $15,000 maximum fine for humming a tune as you walk down the street. Do this repeatedly, and you could be thrown in jail. I can see how that would qualify as evil, even though it's never enforced.
My sister got caught by this, and she is definitely not using Boot Camp. Her hard drive was almost full, though. I think the updater ran out of hard drive space and failed, leaving the system unbootable. This also, of course, meant that archive and install was not an option, so I ended up using target mode to get the files off. Took a darn long time, and in the end, it didn't quite work right (because the Linux machine I copied to didn't keep multi-fork files intact, I think; this can corrupt universal binaries).
This is a common encryption technique, called Hybrid Encryption. Off the top of my head, I know that SSH and TLS use this scheme. This isn't hybrid encryption. In hybrid encryption, you encrypt temporary, symmetric session keys with a fixed public key. If the public key is later compromised, the session keys can generally be recovered. In forward-secure encryption, a simple and common method is to make a temporary public/private key pair, sign the public key with your fixed key and send it over. You exchange the session key using this pair, then throw away the temporary key pair. That way even if your fixed key is compromised, the temporary key is still secure (it was only signed by the fixed key), and so is the session key.
Huh. I hear "good game" said insincerely pretty often (cuz it's "what you're supposed to say"), but almost never sarcastically. I've also heard/seen it used (most frequently in Starcraft, and on either the winning or losing side) before a game is actually over to indicate that the outcome has been decided. This can sound cocky if you're winning ("it's in the bag"), but isn't usually condescending like you're describing.
To me, the "Good Game" line has always been a PC way to be an ass. I don't understand. Are compliments now considered redundant? Is it still appropriate to tell people that they look nice, or to have a nice day?
If you thought the game was "good" (fairly played, evenly matched, enjoyable, etc), tell your opponent so. If you luck out, admit it. If he played well, tell him so. It's the polite thing to do.
If you are the looser, telling the winner that they played a good game seems kind of stupid. Why? You can win without playing well. Your opponent could have gotten lucky, or you both could have played like crap, with your opponent making one fewer mistake. Or both at the same time.
If you are the winner, it always comes across as condescending. Only if you're arrogant about it. If you mean it, it usually doesn't come across that way.
Additionally to encryption, hardware can help too. I have a paranoid friend who has his storage disks in a little cabinet with an electromagnet, where the HDs are electromagnetized when the door is opened without pushing the hidden button first. You can't erase a hard drive with a magnet. That worked years ago, but drives today are too magnetically "hard" for that. You can bend the heads, fry the electronics and blow the motor, but you can't erase the platter. The data probably isn't coming back if you break it this badly, but it's still there.
The wikileaks site has documentary evidence that the US violates the chemical weapons convention in Iraq.
Wow. They went in there, and either duplicated every violation they were sent in to suppress - or created it wholesale where it did not before exist. CS gas isn't sarin. We're occupying Iraq as a military police force, and we're using agents which are only permitted to domestic police forces. This is a violation, but claiming that we're doing exactly what we went in to prevent is stretching it. CS gas doesn't indiscriminately kill hundreds of thousands of civilians; it's illegal for military use only to avoid escalation to deadly gas weapons.
This isn't to say that I agree with the war, or even with the use of CS gas.
How about the rest of your story? Did you hire on with that company? Join another? Did you start your own company? What happened to your intern cohort? I'm a student, and this was only a year or so ago. I didn't enjoy the internship, so I'm not going to hire on. I don't think any of my cohort. I'm currently in grad school, as are most of them. One of them tried to start a company, but it didn't get past the "two or three guys in a garage" stage. He's also in grad school now. My side project has developed further. There's an outside chance that I'll start a company based on it, and a much higher chance that I'll incorporate it into my grad school or research.
These documents are next to meaningless and that is why you just don't read stories about companies successfully suing on this basis. Once you are no longer taking pay from a company, their only recourse is the civil courts, and anything goes in that venue. Not so. That's what binding arbitration is for. But even if there weren't a binding arbitration clause, there's no way I can afford to defend myself in civil court.
First of all, consult a lawyer. This isn't legal advice, and my strategy probably wouldn't work at your company.
I was interning at a company which will remain nameless. Halfway through the internship, they asked me to sign one of these ridiculous no-competes. The contract had the usual litany of "all your base" clauses: no-compete, tricks of the trade, insane damages, binding arbitration, etc. What really got me was that the company would own my side projects, and that I wouldn't be allowed to start a business with current or recent employees for two years after working there, regardless of the field (nor could I hire them, nor recruit them, nor suggest that anyone else hire or recruit them). This was stupid to apply to interns, and especially problematic because some of the interns were my friends and classmates in the computer science program. The prospect of starting a business together or recruiting/suggesting them for a tech company job was (and still is) pretty reasonable. I talked to a lawyer, who advised me not to sign.
I talked to my co-workers, who were also having this pushed on them, and we requested a meeting with legal and HR. Legal basically said "it's not too different from what you'll have to sign anywhere else, we only intend to enforce it to prevent such and so." I asked if they would change the wording to reflect their intent, but they refused, because changing the wording of legal documents is a mess. I asked them to strike the relevant clauses, and they refused, but instead said that I could list side projects to be exempt. Since that was only a fraction of my objection to the document, this compromise wasn't good enough for me.
So, I didn't sign. I didn't outright refuse to sign the document, but instead came up with excuses to push the deadline further and further back. Eventually, they either forgot about it, or realized that threatening to fire me with two weeks left in the internship would be pointless. (This probably wouldn't fly at your company. They'd almost certainly be better organized than mine, and unless you're an intern, there would be more serious consequences if you up and quit.)
My favorite part of the no-compete (approximate, from memory):
Any Ideas, Products, Methods, Works or Developments which you design, create, conceive, improve upon, [...] or reduce to practice during your employment at [Companyname] will be considered works for hire, and will be the sole property of [Companyname]. I don't really understand legalese, but do firstborn children count as Developments?
A colleague of mine once pointed out that the ability of most humans to sing (speak for yourself!), play music, and even distinguish different tunes implies an intrinsic hard-wired affinity for numbers since music depends on very specific ratios of frequencies to be gauged and produced accurately real time. You are in effect doing a Fourier transform of the music, finding the strongest peaks, and reproducing them and/or scaling them by fairly exact amounts (in spite of a broad spectrum of other frequencies present creating timbre). The Fourier transform is done in hardware. That's just how hearing works. Specific intervals are pleasing largely because of the way their overtones line up; that's why pretty much every music system has a third, a fifth and an octave. I'd bet that producing music is done based on memory and calibration, the same way many other actions are done; no math involved.
On top of that, one is usually doing this accurately in the context of much, much lower frequencies (i.e. rhythms/tempos on the scale of Hertz rather than "tones" on the scale of 100s of Hertz) as well. People are good at things involving periodic events on the order of a second. Not sure that math enters into it. I'd guess that the math/music connection is more about the abstract structure of music than the physical structure.
Slashdot Mirror
I'm not saying that this is possible given the realities of engineering, but it is possible in theory.
Alan Turing has explained why their goals are impossible on a Turing machine. Computers aren't Turing machines. Turing machines don't have tamper-resistant hardware.
Yeah, I was comparing to shot put, which is also 16lb, but the record is more like 70ft. Not sure if it's more like a shot or more like a hammer... depends if a human can use a sling effectively on something so heavy.
No kidding. A (very strong) human could probably throw a bowling ball half that far. A trebuchet could probably throw objects 10x heavier 10x the distance, and with better incendiaries to boot.
Still, kudos on innovative use of tech.
I prefer the MagSafe risk.
1. The air is a lot thinner and less sturdy than the X61 for the same weight. This may be a stylistic plus, but it also makes the hardware a lot less breakable, and I think they made the wrong choice here. Maybe, maybe not. It does have a metal shell, unlike the x61, and MagSafe, so you're less likely to pull it off a desk. Though I wonder what the metal shell will do to wireless reception. Also, I hate to say it, but the x61 shell is kind of shoddy for a ThinkPad. Mine is already cracked around the CPU fan vent, and I've been pretty nice to it. 2. The Air is only 1.6 Ghz for a core 2 duo. My X61 came in at 2.2 Ghz. It uses a low-voltage processor, like the x61s. It gets more battery life than the x61 (even the s), at least in the 3lb configuration, unless Apple is lying more than Lenovo. Anyway, many ultraportables use 1.2GHz ULV processors, so Apple is taking the middle of the road here. 3. The Air costs a lot more. My X61 came in at about $1400, whereas the air starts out at $1800! That's $400 for a brand identity on slightly inferior hardware. Expensive, yes, but inferior isn't clear yet. It has a lot of features that the X61 doesn't. 802.11n, keyboard backlight (that LED on the ThinkPad is not a substitute), 13.3" higher-res display, magsafe, magnetic latch, multitouch trackpad (conspicuously missing from the x), camera, microphone. Also, let's admit it, ThinkPads are ugly. Not as bad as Dells, but nothing compared to the shiny of a high-end Mac.
Also, it ships with Leopard instead of Vista. 4. The Air has a tiny by current standards harddrive (80 gigs) probably to make the solid state version not look so bad. It has a 1.8" HDD. Smaller and uses less power, but more expensive and less capacity. 5. The Air's one strong point is that it has DVI out, whereas the X61 only has VGA out. Since there are DVI to s-video adapters, this means the Air can play movies on the tv, whereas the X61 cannot. Yup. And you can connect it to a nicer LCD. On the other hand, the other ports are pretty limited. No ethernet (not "airy" enough?), no mic-in (of course, it has an internal mic), no firewire (oh, the irony), no sd reader, no express slot. And only one USB port. This isn't as bad as it sounds, because you probably have a hub on your desk anyway, and you're not going to need more than one port on the road. Probably.
Still, it seems silly not to include Ethernet. I suppose there's an adapter, but blah. 6. The air has an optional (it's in the $3000 dollar model) solid state drive. I'm not sure what real benefits you get by paying for this. Faster (especially for random reads), lower power consumption, lighter weight, no moving parts, more rugged, geek cred.
I, for one, welcome our new computer-generated overlords. I'd like to remind them that as a trusted TV personality, I can be helpful in rounding up others to toil on their underwater limpet mines.
With a one-time pad, an outsider can't tell which is the key and which is the ciphertext. That means that without some sort of external evidence, a court "shouldn't" find either of you liable. Of course, if you and the other guy worked together to do this, you're both liable.
Handling a strongly-encrypted file probably infringes the artist's copyright, even if the key was destroyed. But you have an ironclad defense if you honestly thought it was just a random collection of bits (while ignorance of the law is not a defense, ignorance of the facts can be). Also, if the key was destroyed, the artist has no actual damages; while he could try to sue you for statutory damages, it would probably get thrown out of court.
Of course, for large compile jobs, VMWare, model checking, etc the 4GiB is wonderful.
For block ciphers and hashes, you instead prove that the algorithm is resistant to large, known families of attacks. You justify its design. You get rid of "magic constants" which could be back doors. Then you and a hundred of your cryptographer friends try to break it for a long time. If they can't break it, you hope it's secure.
For other systems, you prove that your system is secure assuming that a certain problem is hard. For instance, you can prove that a certain block-cipher-based PRNG is secure if the underlying block cipher is secure. This is practically a requirement these days: people generally won't use your algorithm unless you "prove" that it's secure when correctly implemented. ("Prove" is in quotes because the hard problem might turn out not to be hard, or the "proof" might be wrong, or your key might be too small, or P might equal NP, etc.)
The problem with Dual_EC_DRBG is that it's (mostly) secure, under the assumption that the (well-respected) "Elliptic Curve Decision Diffie-Hellman Problem" is hard, for randomly-chosen parameters. For any set of parameters (P,Q), there's a back door, but the back door is hard to find. This is built in to the design of the system. Now, NIST claims that they generated their parameters randomly, and that nobody has the key to the back door. But they can't prove it. They (or the NSA, or someone else) might have generated the parameters maliciously, so that they know the back-door key. There's pretty much no way to know. The reality is, cryptography requires years of research and peer review to be reasonably sure that it's right. Look at all of the cyphers in the past that have suddenly been broken after N years of production use. Now also consider that government standards cost hundreds of thousands of dollars to create, and probably as much again to update. This is a relatively new spec. Nobody's using it, because of the threat of a back door, because of a different minor flaw, because it's slow, and because there are older specs that don't have these problems. It would be relatively easy to change the parameters to something where NIST can "prove" (as above) that they don't have the back-door key. But they haven't, which makes people suspicious. I'm pretty sure you can find this particular random number generator in other places, if you really try. I'm pretty sure you can't. It's very slow. It's not something a non-cryptographer would think of. And if you came up with it anyway, you'd generate the parameters yourself, rather than trusting some other person to generate them for you.
Essentially, Dual_EC_DRBG is a public-key encryption algorithm* disguised as a random number generator. The NIST parameters are a public key. The generator has some painfully-generated random internal state. It steps by encrypting* using the internal state as a parameter. It outputs the ciphertext*. It sets the plaintext* as the next state. To recover the next state, or even to distinguish the next state from random*, is equivalent to breaking the encryption algorithm. EC-DH is a pretty well-respected algorithm, so probably nobody is going to break it. This would imply that the DRBG is secure, i.e. nobody else can distinguish it from actual random numbers.
*Not quite accurate, but a full explanation would be an automatic TL;DR.
Unless, of course, the government (or someone else) has the private key (the "back door") corresponding to that public key. They probably don't, but they almost certainly can't prove it. Since Dual_EC_DRBG is slow, only paranoid people would recommend it anyway. Because of the potential back door, no cryptographer thinks you should use it, but Microsoft has included it anyway. This is probably to say they meet some government standard, but it's causing a tempest in a teapot, possibly because it reminds people of the whole _NSAKEY mess.
And yes, I am a cryptographer.
These two concepts are somewhat orthogonal: a program might have one thread of control, but its compiler or libraries farm out operations to more than one core, or to a large vector unit. More commonly, it might have many logical threads (to repaint the GUI and contact the network, for instance), even if these all run on the same physical core. Some programming languages' concurrency packages don't even support multiple cores (eg, Concurrent ML); these often scale to more threads than those which do support multiple cores, because they have fewer issues with context switches and synchronization.
So while I agree that the risks of nukular power are overhyped, fusion goes a long way toward avoiding them.
Furthermore, you can still limit redistribution of your work. When you distribute it, require that the recipients sign an appropriate contract. Nobody is forced against their will to charge money for people to view or redistribute their work. No, but they are forced to copyright their work (it's automatic). This means that unless the author explicitly says otherwise, nobody can redistribute their work at all (except when this would constitute fair use) until 70 years after their death. Since many publications are anonymous or pseudonymous, obtaining a redistribution license is often unduly difficult. In cases like this, copyright inhibits cultural development, and doesn't give anyone anything in return.
In addition, trivial and incidental use of a work is still infringement, and often isn't covered by fair use (because it's not transformative/criticism/parody/research/teaching). This turns audio and video projects into a copyright minefield. Your documentary catches a single frame of The Simpsons on some random TV in the background? Copyright violation. $15,000 per copy you made, or maybe (if we're feeling nice) we'll just enjoin you from distributing your documentary. Your song's melody sounds vaguely like some other song? Violation. Heck, if you tell to a co-worker a joke that some guy cracked on the subway, that's also a violation. Even if you attribute it. There is an argument to be made that copyright is too long. On the other hand, there's the opposite argument that copyright should be eternal and instead the definition for derivative works should be loosened slightly. Those arguments, at least the ones I've heard, are garbage. They revolve around the idea that "intellectual property" is the same as physical property, in that copying it is the same as stealing. In this case, it shouldn't expire: physical property rights sure don't. But then they assert that intellectual property is different from physical property, in that you can sell it to me and I still won't own it. (Or rather that when you say you're "selling" it, you mean something which is totally different from the sale of physical property.)
Or perhaps you had a different argument in mind. In which case, please elaborate. [W]hy should you decide what I may or may not do with my writings? Why should you be able to restrict the freedom of those who purchase your writings, and who have not signed any sort of contract with you? However, I cannot in any respect see how copyright law is evil. It may be unenforceable; it may be unreasonable, even. Neither of those equates with evil. There's a $15,000 maximum fine for humming a tune as you walk down the street. Do this repeatedly, and you could be thrown in jail. I can see how that would qualify as evil, even though it's never enforced.
My sister got caught by this, and she is definitely not using Boot Camp. Her hard drive was almost full, though. I think the updater ran out of hard drive space and failed, leaving the system unbootable. This also, of course, meant that archive and install was not an option, so I ended up using target mode to get the files off. Took a darn long time, and in the end, it didn't quite work right (because the Linux machine I copied to didn't keep multi-fork files intact, I think; this can corrupt universal binaries).
Huh. I hear "good game" said insincerely pretty often (cuz it's "what you're supposed to say"), but almost never sarcastically. I've also heard/seen it used (most frequently in Starcraft, and on either the winning or losing side) before a game is actually over to indicate that the outcome has been decided. This can sound cocky if you're winning ("it's in the bag"), but isn't usually condescending like you're describing.
We must hang out in different circles.
If you thought the game was "good" (fairly played, evenly matched, enjoyable, etc), tell your opponent so. If you luck out, admit it. If he played well, tell him so. It's the polite thing to do. If you are the looser, telling the winner that they played a good game seems kind of stupid. Why? You can win without playing well. Your opponent could have gotten lucky, or you both could have played like crap, with your opponent making one fewer mistake. Or both at the same time. If you are the winner, it always comes across as condescending. Only if you're arrogant about it. If you mean it, it usually doesn't come across that way.
Wow. They went in there, and either duplicated every violation they were sent in to suppress - or created it wholesale where it did not before exist. CS gas isn't sarin. We're occupying Iraq as a military police force, and we're using agents which are only permitted to domestic police forces. This is a violation, but claiming that we're doing exactly what we went in to prevent is stretching it. CS gas doesn't indiscriminately kill hundreds of thousands of civilians; it's illegal for military use only to avoid escalation to deadly gas weapons.
This isn't to say that I agree with the war, or even with the use of CS gas.
I was interning at a company which will remain nameless. Halfway through the internship, they asked me to sign one of these ridiculous no-competes. The contract had the usual litany of "all your base" clauses: no-compete, tricks of the trade, insane damages, binding arbitration, etc. What really got me was that the company would own my side projects, and that I wouldn't be allowed to start a business with current or recent employees for two years after working there, regardless of the field (nor could I hire them, nor recruit them, nor suggest that anyone else hire or recruit them). This was stupid to apply to interns, and especially problematic because some of the interns were my friends and classmates in the computer science program. The prospect of starting a business together or recruiting/suggesting them for a tech company job was (and still is) pretty reasonable. I talked to a lawyer, who advised me not to sign.
I talked to my co-workers, who were also having this pushed on them, and we requested a meeting with legal and HR. Legal basically said "it's not too different from what you'll have to sign anywhere else, we only intend to enforce it to prevent such and so." I asked if they would change the wording to reflect their intent, but they refused, because changing the wording of legal documents is a mess. I asked them to strike the relevant clauses, and they refused, but instead said that I could list side projects to be exempt. Since that was only a fraction of my objection to the document, this compromise wasn't good enough for me.
So, I didn't sign. I didn't outright refuse to sign the document, but instead came up with excuses to push the deadline further and further back. Eventually, they either forgot about it, or realized that threatening to fire me with two weeks left in the internship would be pointless. (This probably wouldn't fly at your company. They'd almost certainly be better organized than mine, and unless you're an intern, there would be more serious consequences if you up and quit.)
My favorite part of the no-compete (approximate, from memory): Any Ideas, Products, Methods, Works or Developments which you design, create, conceive, improve upon, [...] or reduce to practice during your employment at [Companyname] will be considered works for hire, and will be the sole property of [Companyname]. I don't really understand legalese, but do firstborn children count as Developments?