I take issue with your assumption that 5% of the market share should mean 5% of the attacks/exploits. that makes the assumption that the relationship is linear, something I strongly suspect is inaccurate and certainly wouldn't rely on for preditions of any sort.
Especially since the Linux desktop use base (as opposed to market share) could be anywhere in a very large range. It's rather hard to tell when purchasing stats are only one small part of the matter.
Also, I'd like to note as the admin of a Linux co-located server that it's all too easy to get cracked, though most breaches I've heard about locally seem to have been installs of old distros, combined with a failure to patch the machine before exposing it to the 'net.
My colo hasn't been cracked yet (well, I sure as hell hope not - one can never, sadly, be 100% certain w/o just reformatting it daily) and it's been on the 'net 24/7 with a static IP and a large pipe, running public services that might be attractive to crackers (SSL web server, etc). Paranoia and prompt patching is necessary though.
When it comes to rootkits, one doesn't need a virus for that. A manual or script-kiddie tool exploit can install a rootkit just as easily. My totally unsupported suspicion is that the vast majority of rooted Linux systems are cracked by script-kiddies' scannning and automated exploit tools, not viri or manual attacks.
I certainly do. That's why I mentioned BSD, then the "other UNIXes and UNIX-like OSes". Perhaps not as clearly worded as it could have been, but I didn't really expect anybody to care.
That said, I'm increasingly of the view that Linux is more of a "real" UNIX system than MacOS X, not in code heritage but in functionality and behaviour. Yes, MacOS X is based on a "true UNIX" codebase... but what I've seen working with it and what I've read suggests it's really a whole new OS that has a POSIX subsystem based on a UNIX. A nice system, sure, but not really UNIX. This is probably a good thing for most users;-)
As far as I know, rootkits like that have been the norm rather than the exception on Linux and, I think, the BSDs for some time. I don't know about the other UNIXes and UNIX-like OSes (like MacOS/X), but I'd be surprised if it wasn't the case to some extent there too.
It's been widely recognised for a while that if your system is cracked, the only way to be fairly sure you've cleaned it is to reformat it and start again then *carefully* restore data from backups. I don't see how this is news.
Many here have happily pointed out the 'apples/oranges' comparison between a large Linux distro and Windows. The differing nature of most of the holes - largely theoretical local exploits vs largely gaping remote holes - has also been pointed out.
One thing that nobody seems to realize is that the fact that Windows is small and that other functionality is in separate products may, from a security point of view, be a good thing. It certainly makes it easier to keep track of what you're using (though it'd be nice if the "other products" would integrate with the OS's security update mechanism - grr).
In a large outfit, I could see real advantages to having a cut-down desktop-only build of a distro for exactly this reason.
Similarly, a server distro where the "tasks" were packaged separately might be useful. This server "isn't a database server" so you don't have to worry about the DB related stuff, etc.
Taking a Debian-like install-less-by-default idea is probably also wise.
That said, half the security advisories I get from Debian are for tiny utilities I've never even heard of, and for games. Usually they're local exploits for things like race conditions and temporary file issues. Yes, they should be patched. Yes, they probably merit a security notice. No, they're not the same as (another) remote root hole in sendmail.
Perhaps distributors could start making it easier to evaluate security issues by sorting them based on whether the package is installed by default or not, whether it's widely used or not and whether the exploit is remote or local. It wouldn't hurt to clearly show whether the hole may lead to a root compromise, normal user account compromise, data leak, etc. This information is usually all there already... but providing it in a computer readable, standardized form wouldn't hurt when compiling statistics, and might reduce the use of "blah patches".
Thanks. I noted in my post that I was oversimplifying the description of RAID 5 as if the error correction data was all on one disk. I realise that in reality it's striped across all disks. In terms of the data recovery logic that doesn't matter, since for any one set of sectors across all disks there is still an error correction set.
I was, however, unaware that RAID 5 used ECC not simple parity checks. How does it do this when only a single disk is dedicated to error detection? I would expect ECC data to take up more space than that (in fact, twice the space). If you have details I'd be interested to find out.
Any remotely decent PSU should cope fine with being set to 110V and powered on when plugged into 240. It should simply refuse to power on - and at the *very* worst the PSU its self should fail.
What's a real killer is switching them from 110 to 240 while they're *on*. I've seen this done ("uh... where's the power switch... <continues fumbling> *BANG*") and it's *loud*. Astonishingly, even with this abuse the only damaged components of the system were the PSU (duh!), motherboard, and video card.
Remember that most PSUs can take a 6000V spike for a very short period, and many times that for even shorter times. Most decent PSUs will just power off when the line is hit by lightning, for example (most lightning damage to PCs is via modems and sometimes ethernet).
A large computer icon is often 64x64 pixels. You can extract considerable information from that. If you could adjust your grid to view "between" the pixels (squinting, moving your focus slightly, etc) to build a better idea of what was there, you could do even better.
It's should be enough to avoid walking into walls, pick things up more easily, identify colour and light, etc. A heck of a lot better than nothing.
By the way, this has been done for sound for a while now - in fact, I think such hearing aids may be in or near normal clinical use. Visual stimulation like this has been done before too, but I didn't know of anything this self contained or high detail. Wow.
Personally, I find the syntax of AppleScript so godawful that I can barely use it. I guess that's because I'm experienced with more conventional languages, and tend to think in terms of scopes and operator precedence. I often find it very difficult to figure out what parts of an AppleScript command apply to what, when.
On the other hand, the power of the tool is just incredible. It's the consistent, simple and flexible out-of-process scripting system every other OS would kill for. Yes, I know about Windows Scripting Host (and DCOP, but it's very limited and hardly system-wide).
If I find myself doing more mac work again, I'll be looking at the Python AppleScript interface *very* closely.
A firewall is impractical. The network needs to be extremely high performance, and currently goes though a gigabit switch. Replacing that with a router smart and fast enough to do rule-based filtering like that... ouch.
Host firewall might be viable, but we're stuck on MacOS9. Anyway, I wouldn't put it past Quark to refuse to run when there's a host firewall, or to mangle core system files to bypass it.
As for open source alternatives - there are none. Sorry. I'm a contributor to the closest thing yet but right now it's barely fit to replace MS publisher, let alone Quark. In many ways it's a very good app even at this stage, but it has a number of issues that make it impractical to use in something like newspaper DTP. Of course, I'm currently helping to fix that;-)
Alas, to do that I'd need to replace the switch the macs are plugged into with a rather clever router. Don't think I didn't look into it;-) but it doesn't look practical.
As for a host based firewall... sure, if I could run our systems on a real OS. Alas, our DTP workstations stil run MacOS 9.
Quark is a classic for that. The app *scans* *the* *network* for other instances with the same license key. I bought 6 licenses, why the heck can't I deploy with disk images?
In Quark's case, the answer is "you can if you buy a site license and run a license server". Of course, in exchange for the ability to use your software more practically, what do you get? The same prices, and a new requirement to upgrade all licenses to a new version at once. That's right - less flexibility! Arrggh!
Qt3/X11 and Qt3/Aqua have been dual-licenced with the GPL for a while. There's really no issue. If you can use it under the rules of the GPL, fine. If you want to use it outside the rules of the GPL, get a commercial license from TrollTech.
So yes, my understanding is that your scenarios would be OK.
I'd be happy to be corrected, but my understanding is that RAID 5 is no more capable of telling you which drive is "right" about a block than RAID 1, at least its most common default configuration.
RAID 5 with one parity disk essentially stores the XOR of all the other disks' data on the partity disk. (It's not that simple because it stripes it across disks, but in terms of the logic that doesn't matter).
If I have three values, a, b, and p where:
p = a XOR b
and I find out that *one* of them is wrong because at a later stage I check and find out that now:
p != a XOR b
all I know is that either a, p, or b are wrong. Not which one. As I understand it, the purpose of RAID 5 is that if I lose any one of a, b, or p I can reconstruct it from the two remaining values, and I can extend this scheme up to any number of values ("disks").
For this reason, I'm pretty certain most decent RAID controllers reserve a small percentage of your disk's capacity to store checksum (probably CRC) information. This lets them checksum blocks and determine *which* block is wrong, so they can go from "one of these values is wrong" to "this value is wrong, let's reconstruct it from the others".
My understanding is that RAID 1 frequently doesn't use this, because it's not doing any logical disk remapping like RAID 5 does anyway, and also typically wants to retain the option of using any one disk stand-alone in an none-RAID system.
It should also be noted that IIRC high-end RAID systems permit you to dedicate two disks (or even more?) to parity. Much like the difference between a CRC value and an ECC value, this lets you recover one wrong value (without extra CRCs etc) and detect two wrong values.
I think you have to care about the quality of your work... but don't necessarily have to find software interesting. I would say it helps a lot, though.
As for the competition side of things... ideally, the person best suited to the job (and hopefully the person who *cares* about doing a good job) gets it. In reality, the person whose political and ass-kissing skills have been improved in preference to their job skills frequently gets it. It's true in many areas beyond software.
I just don't see software as special in this regard.
I'm very confused as to how bringing the relevant options for something to that thing is bad UI design. Especially since it's optional.
I do agree that *mandatory* context menus are poor UI design, but so long as the functionality also exists elsewhere I think they're a fantastic time and effort saver that let people perform common tasks quickly and efficiently.
I'd pay extra for a properly tested and debugged game. If it was online, for working and reliable servers too. Mostly just a debugged game though.
I think that's why Deus Ex was one of my favourite games - the darn thing worked. Ditto Master of Orion II (though that wasn't entirely bug free), Star Control II (awesome game - check out the now-open-sourced builds), Half Life, etc. OTOH, some games are so awesome it's even worth putting up with bugs - eg System Shock II.
Alas, I doubt it's not going to be a US$10 difference, not if you want the game developer to make that reliability guarantee a legally binding one. Check out prices for SLA service plans at your local ISP and compare them to similar no-gurantee plans and you may get some idea.
I do think that it'd be more viable to offer a "light" guarantee - you know, game will be largely bug free (what a thought!), servers will work at 99% or better if online, etc.
The issue would be how to enforce it. For MMORPGs etc you could use essentially an SLA, probably with free service time as a "payment" for downtime. For other types of game it'd be a lot harder - having the publisher pay out to buyers would IMO just never work.
Hmm. I hadn't thought of that, but you do make a good point regarding teaching Valve - and the industry - a lesson.
Copy protection pisses me off a *lot*, because it only punishes legal customers. Anything that cuts down on that would make me a happy man. Alas, a lawsuit would probably just make them do a better job of the same thing next time, rather than drop the idea entirely.
BTW, I play some games under Linux, and it's bought home to me just how annoying copy protection is. My copy of neverwinter nights, unmodified, has been migrated with my home directory across three OS installs. It doesn't care. It's never asked for the CD, and not only that, but it doesn't even force me to watch splash screens. I suspect that's because they just couldn't be stuffed implementing said "features", but... the contrast is amazing.
I'd pay extra for a game with less offensive copy protection. On the flip side, well, there's a reason I don't own HL2.
Anyway, enough with that little tangent. I'd be interested to see how a gaming class action would work... but it might take more than this to make one practical.
This is an outage. The same thing happens at ISPs sometimes, and people may get pissed but they rarely demand their money back unless it's a *massive* outage (many days or weeks). Unless they have an SLA, they rarely get their money back even if they do ask for it.
I never said it didn't suck, I just said I think it'd a pretty stupid thing to sue over.
The software works. It may have problems, and I personally object to the whole way they've done it, but this is an outage, not fraud. Big difference.
If your ISP told you that while you were paying for service from them, they weren't ever planning on delivering it, that'd be a *major* issue. Well worth small claims, at least.
If they went down for two days, you'd be pissed, but you'd deal with it. Well, unless you had some sort of SLA guaranteeing that outages wouldn't happen "or else". I don't see what the difference is.
Um... Sure, I can see it'd be frustrating, but dude it's a *game*. The fact that there can even be an outage is stupid, but rather unlikely to be lawsuit material.
"Will the compensation payouts as a result of deaths and injuries caused by our car's tendency to exploade outweigh the cost of the recall and design changes required to fix the problem?"
I don't doubt it'd cost more to fix the problem than ignore it and deal with the consequences. I just don't think "the consequences" are something we'll *want* to live with.
That said, like you I want to see a few more people playing devil's advocate on both sides - especially global warming advocates attempting to find evidence *against* their theories (as they should do anyway).
As for the threat level, I think the issue is not so much how major a threat it as as its potential for *extremely* long term and widespread effects that could be essentially permanent, or at least last for *many* generations.
I, for one, am unwilling to write off the potential issues of coastline change and the resulting squabbles (probably wars) over terriory, starvation due to lost productive growing area, population displacement, oceanic ecology changes (and potential for displacement/loss of fish stocks), economic damage, etc. *if* sea level change happens as some think it may, it might make the recent tsunami look like a splash in a pond.
Slashdot Mirror
I take issue with your assumption that 5% of the market share should mean 5% of the attacks/exploits. that makes the assumption that the relationship is linear, something I strongly suspect is inaccurate and certainly wouldn't rely on for preditions of any sort.
Especially since the Linux desktop use base (as opposed to market share) could be anywhere in a very large range. It's rather hard to tell when purchasing stats are only one small part of the matter.
Also, I'd like to note as the admin of a Linux co-located server that it's all too easy to get cracked, though most breaches I've heard about locally seem to have been installs of old distros, combined with a failure to patch the machine before exposing it to the 'net.
My colo hasn't been cracked yet (well, I sure as hell hope not - one can never, sadly, be 100% certain w/o just reformatting it daily) and it's been on the 'net 24/7 with a static IP and a large pipe, running public services that might be attractive to crackers (SSL web server, etc). Paranoia and prompt patching is necessary though.
When it comes to rootkits, one doesn't need a virus for that. A manual or script-kiddie tool exploit can install a rootkit just as easily. My totally unsupported suspicion is that the vast majority of rooted Linux systems are cracked by script-kiddies' scannning and automated exploit tools, not viri or manual attacks.
I certainly do. That's why I mentioned BSD, then the "other UNIXes and UNIX-like OSes". Perhaps not as clearly worded as it could have been, but I didn't really expect anybody to care.
... but what I've seen working with it and what I've read suggests it's really a whole new OS that has a POSIX subsystem based on a UNIX. A nice system, sure, but not really UNIX. This is probably a good thing for most users ;-)
That said, I'm increasingly of the view that Linux is more of a "real" UNIX system than MacOS X, not in code heritage but in functionality and behaviour. Yes, MacOS X is based on a "true UNIX" codebase
As far as I know, rootkits like that have been the norm rather than the exception on Linux and, I think, the BSDs for some time. I don't know about the other UNIXes and UNIX-like OSes (like MacOS/X), but I'd be surprised if it wasn't the case to some extent there too.
It's been widely recognised for a while that if your system is cracked, the only way to be fairly sure you've cleaned it is to reformat it and start again then *carefully* restore data from backups. I don't see how this is news.
Many here have happily pointed out the 'apples/oranges' comparison between a large Linux distro and Windows. The differing nature of most of the holes - largely theoretical local exploits vs largely gaping remote holes - has also been pointed out.
... but providing it in a computer readable, standardized form wouldn't hurt when compiling statistics, and might reduce the use of "blah patches".
One thing that nobody seems to realize is that the fact that Windows is small and that other functionality is in separate products may, from a security point of view, be a good thing. It certainly makes it easier to keep track of what you're using (though it'd be nice if the "other products" would integrate with the OS's security update mechanism - grr).
In a large outfit, I could see real advantages to having a cut-down desktop-only build of a distro for exactly this reason.
Similarly, a server distro where the "tasks" were packaged separately might be useful. This server "isn't a database server" so you don't have to worry about the DB related stuff, etc.
Taking a Debian-like install-less-by-default idea is probably also wise.
That said, half the security advisories I get from Debian are for tiny utilities I've never even heard of, and for games. Usually they're local exploits for things like race conditions and temporary file issues. Yes, they should be patched. Yes, they probably merit a security notice. No, they're not the same as (another) remote root hole in sendmail.
Perhaps distributors could start making it easier to evaluate security issues by sorting them based on whether the package is installed by default or not, whether it's widely used or not and whether the exploit is remote or local. It wouldn't hurt to clearly show whether the hole may lead to a root compromise, normal user account compromise, data leak, etc. This information is usually all there already
Particularly painful given that I've been spending all day with my head immersed in C++.
Definitely well past sleep time.
Thanks. I noted in my post that I was oversimplifying the description of RAID 5 as if the error correction data was all on one disk. I realise that in reality it's striped across all disks. In terms of the data recovery logic that doesn't matter, since for any one set of sectors across all disks there is still an error correction set.
I was, however, unaware that RAID 5 used ECC not simple parity checks. How does it do this when only a single disk is dedicated to error detection? I would expect ECC data to take up more space than that (in fact, twice the space). If you have details I'd be interested to find out.
Any remotely decent PSU should cope fine with being set to 110V and powered on when plugged into 240. It should simply refuse to power on - and at the *very* worst the PSU its self should fail.
... where's the power switch... <continues fumbling> *BANG*") and it's *loud*. Astonishingly, even with this abuse the only damaged components of the system were the PSU (duh!), motherboard, and video card.
What's a real killer is switching them from 110 to 240 while they're *on*. I've seen this done ("uh
Remember that most PSUs can take a 6000V spike for a very short period, and many times that for even shorter times. Most decent PSUs will just power off when the line is hit by lightning, for example (most lightning damage to PCs is via modems and sometimes ethernet).
A large computer icon is often 64x64 pixels. You can extract considerable information from that. If you could adjust your grid to view "between" the pixels (squinting, moving your focus slightly, etc) to build a better idea of what was there, you could do even better.
It's should be enough to avoid walking into walls, pick things up more easily, identify colour and light, etc. A heck of a lot better than nothing.
By the way, this has been done for sound for a while now - in fact, I think such hearing aids may be in or near normal clinical use. Visual stimulation like this has been done before too, but I didn't know of anything this self contained or high detail. Wow.
Personally, I find the syntax of AppleScript so godawful that I can barely use it. I guess that's because I'm experienced with more conventional languages, and tend to think in terms of scopes and operator precedence. I often find it very difficult to figure out what parts of an AppleScript command apply to what, when.
On the other hand, the power of the tool is just incredible. It's the consistent, simple and flexible out-of-process scripting system every other OS would kill for. Yes, I know about Windows Scripting Host (and DCOP, but it's very limited and hardly system-wide).
If I find myself doing more mac work again, I'll be looking at the Python AppleScript interface *very* closely.
A firewall is impractical. The network needs to be extremely high performance, and currently goes though a gigabit switch. Replacing that with a router smart and fast enough to do rule-based filtering like that ... ouch.
;-)
Host firewall might be viable, but we're stuck on MacOS9. Anyway, I wouldn't put it past Quark to refuse to run when there's a host firewall, or to mangle core system files to bypass it.
As for open source alternatives - there are none. Sorry. I'm a contributor to the closest thing yet but right now it's barely fit to replace MS publisher, let alone Quark. In many ways it's a very good app even at this stage, but it has a number of issues that make it impractical to use in something like newspaper DTP. Of course, I'm currently helping to fix that
Alas, to do that I'd need to replace the switch the macs are plugged into with a rather clever router. Don't think I didn't look into it ;-) but it doesn't look practical.
... sure, if I could run our systems on a real OS. Alas, our DTP workstations stil run MacOS 9.
As for a host based firewall
That's pretty common, sadly.
Quark is a classic for that. The app *scans* *the* *network* for other instances with the same license key. I bought 6 licenses, why the heck can't I deploy with disk images?
In Quark's case, the answer is "you can if you buy a site license and run a license server". Of course, in exchange for the ability to use your software more practically, what do you get? The same prices, and a new requirement to upgrade all licenses to a new version at once. That's right - less flexibility! Arrggh!
Your pain is far from unique, I'm afraid.
Qt3/X11 and Qt3/Aqua have been dual-licenced with the GPL for a while. There's really no issue. If you can use it under the rules of the GPL, fine. If you want to use it outside the rules of the GPL, get a commercial license from TrollTech.
So yes, my understanding is that your scenarios would be OK.
Thanks for pointing that out - it's something I should've realised.
I'd be happy to be corrected, but my understanding is that RAID 5 is no more capable of telling you which drive is "right" about a block than RAID 1, at least its most common default configuration.
RAID 5 with one parity disk essentially stores the XOR of all the other disks' data on the partity disk. (It's not that simple because it stripes it across disks, but in terms of the logic that doesn't matter).
If I have three values, a, b, and p where:
p = a XOR b
and I find out that *one* of them is wrong because at a later stage I check and find out that now:
p != a XOR b
all I know is that either a, p, or b are wrong. Not which one. As I understand it, the purpose of RAID 5 is that if I lose any one of a, b, or p I can reconstruct it from the two remaining values, and I can extend this scheme up to any number of values ("disks").
For this reason, I'm pretty certain most decent RAID controllers reserve a small percentage of your disk's capacity to store checksum (probably CRC) information. This lets them checksum blocks and determine *which* block is wrong, so they can go from "one of these values is wrong" to "this value is wrong, let's reconstruct it from the others".
My understanding is that RAID 1 frequently doesn't use this, because it's not doing any logical disk remapping like RAID 5 does anyway, and also typically wants to retain the option of using any one disk stand-alone in an none-RAID system.
It should also be noted that IIRC high-end RAID systems permit you to dedicate two disks (or even more?) to parity. Much like the difference between a CRC value and an ECC value, this lets you recover one wrong value (without extra CRCs etc) and detect two wrong values.
I think you have to care about the quality of your work ... but don't necessarily have to find software interesting. I would say it helps a lot, though.
... ideally, the person best suited to the job (and hopefully the person who *cares* about doing a good job) gets it. In reality, the person whose political and ass-kissing skills have been improved in preference to their job skills frequently gets it. It's true in many areas beyond software.
As for the competition side of things
I just don't see software as special in this regard.
I'm very confused as to how bringing the relevant options for something to that thing is bad UI design. Especially since it's optional.
I do agree that *mandatory* context menus are poor UI design, but so long as the functionality also exists elsewhere I think they're a fantastic time and effort saver that let people perform common tasks quickly and efficiently.
I'd pay extra for a properly tested and debugged game. If it was online, for working and reliable servers too. Mostly just a debugged game though.
I think that's why Deus Ex was one of my favourite games - the darn thing worked. Ditto Master of Orion II (though that wasn't entirely bug free), Star Control II (awesome game - check out the now-open-sourced builds), Half Life, etc. OTOH, some games are so awesome it's even worth putting up with bugs - eg System Shock II.
Alas, I doubt it's not going to be a US$10 difference, not if you want the game developer to make that reliability guarantee a legally binding one. Check out prices for SLA service plans at your local ISP and compare them to similar no-gurantee plans and you may get some idea.
I do think that it'd be more viable to offer a "light" guarantee - you know, game will be largely bug free (what a thought!), servers will work at 99% or better if online, etc.
The issue would be how to enforce it. For MMORPGs etc you could use essentially an SLA, probably with free service time as a "payment" for downtime. For other types of game it'd be a lot harder - having the publisher pay out to buyers would IMO just never work.
Hmm. I hadn't thought of that, but you do make a good point regarding teaching Valve - and the industry - a lesson.
... the contrast is amazing.
... but it might take more than this to make one practical.
Copy protection pisses me off a *lot*, because it only punishes legal customers. Anything that cuts down on that would make me a happy man. Alas, a lawsuit would probably just make them do a better job of the same thing next time, rather than drop the idea entirely.
BTW, I play some games under Linux, and it's bought home to me just how annoying copy protection is. My copy of neverwinter nights, unmodified, has been migrated with my home directory across three OS installs. It doesn't care. It's never asked for the CD, and not only that, but it doesn't even force me to watch splash screens. I suspect that's because they just couldn't be stuffed implementing said "features", but
I'd pay extra for a game with less offensive copy protection. On the flip side, well, there's a reason I don't own HL2.
Anyway, enough with that little tangent. I'd be interested to see how a gaming class action would work
This is an outage. The same thing happens at ISPs sometimes, and people may get pissed but they rarely demand their money back unless it's a *massive* outage (many days or weeks). Unless they have an SLA, they rarely get their money back even if they do ask for it.
I never said it didn't suck, I just said I think it'd a pretty stupid thing to sue over.
... but that's not what happened.
The software works. It may have problems, and I personally object to the whole way they've done it, but this is an outage, not fraud. Big difference.
If your ISP told you that while you were paying for service from them, they weren't ever planning on delivering it, that'd be a *major* issue. Well worth small claims, at least.
If they went down for two days, you'd be pissed, but you'd deal with it. Well, unless you had some sort of SLA guaranteeing that outages wouldn't happen "or else". I don't see what the difference is.
My point is that, stupid and frustrating as it may be, it's probably a a bit overblown to suggest a lawsuit as a likely outcome.
If you're going to sue over games, there are lots of other options - especially games so buggy as to be almost unplayable.
Um... Sure, I can see it'd be frustrating, but dude it's a *game*. The fact that there can even be an outage is stupid, but rather unlikely to be lawsuit material.
... paid, not payed.
Also
This reminds me of something...
"Will the compensation payouts as a result of deaths and injuries caused by our car's tendency to exploade outweigh the cost of the recall and design changes required to fix the problem?"
I don't doubt it'd cost more to fix the problem than ignore it and deal with the consequences. I just don't think "the consequences" are something we'll *want* to live with.
That said, like you I want to see a few more people playing devil's advocate on both sides - especially global warming advocates attempting to find evidence *against* their theories (as they should do anyway).
As for the threat level, I think the issue is not so much how major a threat it as as its potential for *extremely* long term and widespread effects that could be essentially permanent, or at least last for *many* generations.
I, for one, am unwilling to write off the potential issues of coastline change and the resulting squabbles (probably wars) over terriory, starvation due to lost productive growing area, population displacement, oceanic ecology changes (and potential for displacement/loss of fish stocks), economic damage, etc. *if* sea level change happens as some think it may, it might make the recent tsunami look like a splash in a pond.