I am an Oracle Certified DBA, and I do not consider this a great loss.
For several reasons:
Not entirely true. They are no more centralised than email servers. Each domain gets to nominate their own XMPP servers via DNS - which can be shared across cooperating domains.
Megablocks are not LEGOs. They are made by a different company, and "happen to" be sort-of compatible with proper LEGOs. If you have ever tried comparing them, you'd be sure to find that Megablocks do not stick together as well as LEGOs - I believe that LEGOs are produced to much finer tolerances than Megablocks.
Disclaimer: I am Danish, and (naturally?) a LEGO fan. To me, Megablocks and LEGOs are completely different. Just like water and Carlsberg are different (yes: I was bottle fed as a baby. Live with it)
Don't be lazy. By being lazy you reducing the quality of the language, which (obviously!) is bad. Perhaps you should be liable for damages for unauthorized copying of the judgement text? With "reduction of quality" making it even worse!??
I read and speak Swedish, and the google translation is not bad at all. Basically, the damage to the reputation of the movie(s) was valued at 300K SEK. The reasoning for this does not appear to be explained futher in the judgement, but I suspect the judge is not familiar with torrent download sites and believes that all torrent users expect perfect quality.
And it smacks of being punished for the same thing twice.... If I have a bad viewing of a movie because my TV set is wonky and add my review accordingly, I'm damaging the reputation too, right? ANYBODY who submits a bad review are in the same boat.
But this is only ~7% of the total judgement...
Surely you know the Golden Rule?
The Golden Rule: The ones with the Gold make the Rules.
So: This assumes that something, somewhere knows which transistors are unreliable. This data needs to be stored somewhere - on the "good" transistors. How is this data obtained? is there a trustworthy "map" of "unreliable transistors" ? And the code that determines the probability has to run on the "good" transistors too. Will those transistors stay good?
I cannot see any way of allowing *any* transistor being unreliable... And based on my (admittedly incomplete) understanding of chip production, *any one* of the transistors on the sillicon can be faulty, so there still is a chicken-and-egg problem in here somewhere.
Surely, such "suspect" transistors can only be used for storing the final end result of a calculation: If you were to use it for intermediate values on which you base "if" statements (or any sort of branch), your code will end up unreliable as a result. Unfortunately, 99% of the time the "end result" of one calculation is used as input to another calculation, so the problem spreads like rings in the water.
What if humans want to rely on the output of the computer? Does that pixel on the screen matter? If you are playing Angry Birds, fine. But the pixels may be important if you're a doctor looking at a scan. Or you're a flight controller scanning the screen for planes. The graphics routines do not know the context in which they run. So the actual usability of this ends up being radically diminished....
What use is a computer where you cannot trust the result? We already have logic bugs, race conditions, usability issues etc confusing everybody - I don't think we need to make the computers even more unreliable...
That's no good! Terrorists will just disguise their emails as spam by sending it out to millions, and things will go unnoticed by the NSA: Too many dots to connect, which will (as usual) only be discovered by hindsight.
Obviously the intended terrorist agent on the receiving end will have a similar problem... Which means that the NSA can recognise the terrorists, because they're the ones reading everything in their Junk folder!
Oooh - the arms race will never end
Nice to see that spammers are useful for something though: Keeping both the NSA and (some) terrorists busy at the same time!
Development race conditions. Ever done svn up on the production server, just to find that someone had committed broken code between your test run and the deployment
If this happens, then you are doing things wrong.
You should know that YourApp version X is what QA tested. Because the developers tagged it before giving it to the QA guys.
You should know that upgrading your live environment to YouApp version X is not the same as "Upgrade live to latest commit". This race condition is easily solved by proper understanding of how people use your version control system.
In other words: Use the tags, Luke!
Arguably, using "svn update" (or whatver equivalent in your chosen VCS is) is only useful for projects that require no compilation or installation other than "just copy files about". Most are more complex than that.
Agreements with Verisign (or other CAs) would not help here: Verisign will NOT get the website's private key when somebody ask for a certificate.
It is possible (but unlikely) that the CSR (Certficate Signing Request) may be of use to NSA though. It does NOT contain the private key.
It is MUCH easier to strong-arm a CA to sign NSAs newly-generated key for e.g. "facebook.com" and play man-in-the-middle on whatever traffic they're listening in on - isn't that what Iran did with google traffic? (My memory is vague here...)
Computers are useless. They can only give you answers. -- Pablo Picasso