I read your post, specifically the bit that said most home used don't have a need for RAID. To my mind it was written in such a way as to suggest that there was no common case for RAID being useful to a home user, something which I considered incorrect.
My use of the word "actually" was intended to imlpy a mater-of-fact voice, not a ner-ner-ne-ner-ner voice. So don't SHOUT like I've just shat in your rice pudding.
Actually, there is one place where many home users will see the performance benefit of RAID: game/level load times.
I have my games installed on a RAID0 set over two disks and the difference is quite noticeable for some of them. Of course nothing I truly care about is kept on the RAID0 volume, and I keep copies of save files and other user content backed up elsewhere in case one of the drives dies taking the array with it.
While it is true that the OS can never know for sure what layout the disk has, it is fairly safe to assume that data which is sequential according to the filesystem is also sequential on disk much more often than it is not. So unless you are spending a lot of CPU time computing your read ordering method it would theoretically make a noticeable positive difference on average.
Of course when we are all using some form of solid state drive instead spinning disks, were the difference in read latency between a next-block read and a the-other-side-of-the-disk-from-last-time read is zero (or as close to as makes no odds) the point will be moot. But it will be a while before the price differential comes down (and end-user confidence in the reliability and performance related properties goes up) to the point where SSDs are more common than spinning disk based drives.
I think this is a relatively recent addition. In the kernel as provided as the official one in both Debian/Etch and Debian/EtchAndHalf RAID1 arrays read at the speed of one drive. The change to make it try balance the reads was made a minor version or two after the version those distros use as their base so it is present in the newer Lenny (though I have not yet got round to doing any performance tests on the one Lenny box I have with a RAID1 array to see how much difference this makes).
So for better RAID1 read performance with software RAID in Linux, make sure that your kernel is new enough (or has had that particular update back-ported and patched in.
Unfortunately that doesn't cover instances where OEMs who have purchases the license implement the file system with a bug that doesn't surface until it hits a directory written to by this new driver. Bugs like that can hide for a long time, even in code that is otherwise good.
This sounds dangerous to me. What if someone uses this to write to an SSD card that they plug into some cheap portable device (a media player for example) that doesn't implement the "standard" properly and gets confused by the data in the short filename when a long one is present? Or refuses to read half the files because it only likes short names (some cheap Chinese import MP3 players just use the short filename in displays) and half the files have names too long? The user won't blame their crap cheap little portable device they paid $3 for on eBay, they'll blame that there Linux thing because their copy of Windows can write things so the player understands.
Also the code that they have written may be dual-licensed - GPL and , with the ToS mainly declaring the terms for and letting it be known there is a choice.
Spending hours or more coming up with something that will handle all the different jacked up versions of javascript just to get a few more addresses doesn't make much sense.
Yes, but it works both ways. Once one person has gone to a bit of extra effort for shits and giggles (or because they were paid to?) and the code gets out (is deliberately released, is sold an leaked, or just leaked) it becomes so easy to copy the technique in some cases that is a no brainer to do so to catch that extra 1%.
I'm sure that some address farming bots have been passing script blocks containing little more than document.write calls through one of the several freely available javascript engines for ages. It is not as if they have to write even a partial interpreter themselves. The address having been interpreted by Google and therefore existing in their cache makes little difference at this point.
I don't think that this qualifies as a criteria for "winner" or not. However, it certainly speaks volumes about the society she's part of.
Either that or it just says they wanted to do something different and couldn't think of anything else that hadn't already been done yet the church would not object to...
"and get off my lawn!" he continued in a raised voice, waving a stick in what was presumably intended as a threatening manner
He is entitled to his opinion, of course. But I think he is missing the point by a few lightyears on this matter. And wrong as he may be on this matter, that doesn't invalidate anything he said/wrote previously.
Is this really a completely new idea, or just an extension of what Valve games have done for ages?
In all the HL2 series (and maybe before that) you've been able to change the general difficulty between the three levels mid-game. I normally do fairly well on "normal" settings in games, but I did once find this feature useful (in HL2, the prison complex, I forget exactly where on the level) for getting past a frustrating point so I could stop banging my head against it and get on with enjoying the rest of the game. I imagine that people looking for a more-casual-but-not-always-set-to-too-easy experience would use the feature quite a bit.
What Nintendo are talking about here seems to me to just be going one step beyond this, changing the available levels from Hard/Normal/Easy to Hard/Normal/Easy/Autopilot. Nothing revolutionary.
That's the part I'm talking about. Seems like that heat could be put to good use somehow.
There are projects in that direction, though they dont tend to be big news except getting a mention when New Scientist run a "green issue". The problem though is that the energy involved is often not enough to be particularly significant once you consider how much is left after the conversion and transportation processes needed to make use of it elsewhere.
There are various ways the energy can be used if you get beyond the "not enough to be genuinely useful once you've transported and processed it" problem. In cold areas it can be used as part of the heating system for offices in the building or near by (straying off-topic a little: energy sapped from the cooling towers of power stations is sometimes used this way), for heating water, if you have a *lot* of waste heat you can try convert it to electrical energy and feed it into the air con systems of the server rooms themselves, and so on.
The trouble is that the investment in technology needed to reuse the "waste" heat is currently often more expensive than the savings it provides through reduced energy use elsewhere, so most companies will only do it if they want to show off some green credentials for publicity reasons. This will change over time, as the technologies are refined and become cheaper and as energy prices rise.
Unless the email looked a lot like gobbeldygook because they emailed it to someone for whom english was a (distant) second language, or they emailed it to 'support' and there wasn't anything in the flip book to cover that. It's a bit hard to tell from the timeline if the contact attempt was anything more than cursory.
The rundown on that site says the second response was "Sorry for the delay. I am currently looking into this, and will reply in a couple of hours time" which implies that the messages was understood.
Of course we only have one person's word for that, and we don't get to review the initial emails to see if they were written well enough...
But *all* they needed to do in those two weeks was download the provided vulnerability details and acknowledge that they were intending to investigate?
As I said above I agree that two weeks was an unprofessionally short timeframe for full disclosure of issues this serious, but not even attempting to access the provided information in two weeks shows shows a severe due diligence failing on the part of the vendor too.
Reading through the information on Milw0rm's own site, it appears they had an email exchange with someone at LXLabs for two weeks, then decided on their own to release the information. Two weeks is not nearly enough time to even decide if something like this is worth looking at, let alone find a fix, develop it, test it, implement it, and push it to all clients.
Fair enough, I would agree that in most cases two weeks is not nearly enough time. Even if you can, by some superhuman feat of organisation, create+QA+publish a fix/workaround that day it'll take time for the users to test and make the update available on their services (you can't just chuck a patch on a large production system without some oversight).
But I would certainly not go as far as to suggest that two weeks is not enough time to decide if something like this is even worth looking at. To have not even accessed the resource containing further exploit information (I assume this was available on a service that would log access, an unadvertised and unlinked location on a web server for instance) in two weeks seems wrong to me. Would you not at least download it, virus-/other-check it, and attach anything relevant to your internal record for the issue so the team/person who reviews these things has access to the info?
Having read the released information I would agree that Milw0rm's premature release was at least unprofessional if not down right irresponsible, but (assuming Milw0rm's report is true and accurate) I think that the vendor's response was similarly lacking in due diligence.
But that is not much less dangerous than just announcing the details. Letting the world know that an exploit exists is tantamount to challenging any black-hats out there to go look for it. Look for it some will, find it some might, and if some find it before fix is released and commonly installed you can bet your bottom dollar there is a chance at least one will use it for personal gain or just plain old vandalism. By announcing an exploit without details you just delay the inevitable (or, perhaps, speed its arrival almost as much as a detailed announcement would).
Why is it not an option? It isn't the best option, which is to announce that an exploit exists, but not release the details.
I would agree that this is the best way to proceed initially, but what if no body takes the report seriously? Also, without releasing any details how does anyone verify that your attack is valid and not just you trying to defame the supplier?
Announcing that there is a problem but not releasing the details is not as much less dangerous as your post suggests you believe. As soon as such an announcement is made I'm pretty sure a number of black-hats out there will immediately start scanning for the issue and there is a fair chance one will find it in time to make use of it.
My suggestion would be:
Notify the supplier ASAP with full details
After some time (a month perhaps, though this may be shorter or longer depending no the potential seriousness of the exploit), if there is no public update from the supplier, contact them to see what the status is
If they are not taking action, publicly announce that the exploit exists and that details will follow in, say, 28 days. Delay this step if it seems the supplier is taking action but is suffering legitimate delays (such as the problem being deep in the codebase and therefor requiring much QA testing for an update - though in such events I would expect a workaround to be available and announced in most cases).
After the deadline above release general details - just the result of the exploit such as "will result in denial of service for all on the host" or "may result in giving unauthenticated access to all user data" or "allows an authenticated user to escalate their privileges". Announce a further deadline after which more information will be made available.
After the deadline above publicly release full details.
Of course one problem with this, and any other vulnerability announcement, is that the company involved may try to silence you with litigation (or threats there-of) as well as or instead of taking action to fix the issue. That could get very thorny. But any decent software supplier should be grateful of the initial heads-up and would be quite forthcoming if asked for progress (like saying "we've reproduced the issue and expect to have a patch available in X days" or "a full update may be delayed because of X, but a workaround is being tested and we expect to announce it in Y days"). I would be, as I believe would my employer.
Of course the problem will not always be down to the software supplier - it could be a local configuration issue in which case they should tell you and perhaps add extra warnings to relevant documentation to reduce repeat occurrences.
I have very mixed feelings on security firms releasing exploits to the public just to try and get results. In my (admittedly limited) experience, more bad has come from releasing exploits publicly than good.
-JJS
But once you've informed the supplier, and allowed enough time for a fix to be created, tested, rolled into a patch, QAed, released to clients and tested+installed by clients, what other alternative is there? Quietly forgetting about it and just hoping that you are the only people who know about the issue and no black-hats out there will find it is simply not an option.
Maybe it's because Japan has one of the lowest rape per capita countries.
They have the lowest reported and recorded rape rate. In many places there is a lot of stigma attached to being the victim in these cases so victims are unwilling to come forward if they do they get little support, and from what little I know of modern Japanese culture I would guess that Japan is somewhere where this is a significant problem.
You can only state that the existence of the games reduces rapes if you can show that their rise has been responsible for a reduction in rapes. Can you point to any research that shows this to be that case?
Excellent though some are (my AA1 goes everywhere with me), the current crop of netbooks don't come close the in-use battery life of devices like the N8x0s. Extra life between charges without buying a chunkier battery would be very nice on my A1, and I wouldn't mind losing a chunk of processing power to get it as what I use the machine for is never CPU intensive.
Of course while the CPU and related chipset are a significant factor they are not the only reason Atom (or celeron) based machines drink more juice then something like the N8x0s. They have bigger screens running at higher resolution which eats power, they have more RAM (keeping 512Mb+ of DRAM live is more costly then 128Mb and the refresh cycle is needed even when suspended), they have a chunky SSD drive or spinning disk to give power to, and so an and so forth.
The obvious question is were there any Muslims on board. That would make the chance of a bomb much more likely than a meteor strike. I am not saying that it is very likely that an individual Muslim is a bomber, just that the probability of a lightning strike is minuscule.
You might be looking at a flaimbait mod there... If al qaeda or a similar group where to try the bomb+plane thing again, I'm sure they are bright enough not to use an obvious attacker for the job so "counting muslims" is not a statisticly valid risk assessment procedure. And anyway, they woud have claimed responsibility by now - there is no point commiting an act of terror to just let people think it was a natural disaster afterwards.
You are, in my untrained opinion, wrong about the lightning strike given the weather conditions reported for the time in that location. OK, so a strike powerful enough (or otherwise somehow affecting equipment sensitive enough) to down an airbus might be very unlikely but as they where flying through a hefty storm system I'd guess more likely than one of the passengers happening to be a very naughty boy.
I'd say a meteor strike is far far less likely too, but without some analysis you can't completely rule it out. "Very very unlikely" is not the same as "impossible".
I read somewhere that statistically, airplanes are safer than cars, you're more likely to die in a car accident.
I also read a quote somewhere else of somebody saying "Airplanes might be safer than cars, but I'd rather arrive at my destination with a false sense of security than feel like I've narrowly escaped death."
Then the person in the second quote needs to adjust their attitude to the relevant risks to better match reality!
Though it isn't really their fault - we all do the same thing. The automatic risk assessment abilities of the human brain were simply not designed for this sort of thing so we have to consciously calculate the odds and then beat our sub-concious into agreeing with what it sees as an unintuitive result.
Media attention has a part to play to. While more people die in road incidents in total (per mile travelled, amongst other measures) more die in one go with an air incident, and air incidents are more rare, so such incidents are more "news worthy" which means the average air related death gets a lot more media attention than the average road related death. This means that we (the media consumers) think about them more so the incorrect impression (air is less safe) is further reinforced.
Most Eee PCs have two SSDs: a large, slow one and a small fast one. Firefox became a lot snappier once I moved my profile directory to the fast SSD. Obvious in retrospect, I know...
If you have >512Mb in your netbook you could do what I've done: I keep the entire profile in RAM (on a tmpfs filesystem). On bok the profile is copied in to the ram drive and on shutdown it is rsynced back to the SSD (using --inplace to reduce copy+write operations on the urlclassifier db).
OK so it lengthens boot time a little, but it isn't often the machine is properly shutdown anyway (it tends to be suspended when not in used instead) so doesn't do a full boot often.
The urlclassifier db appears to be the main culprit for the "unexpected" IO in firefox. and even with all the relevant features turned off it seems to keep updating the file. If you don't want to put your whole profile in RAM (there is the risk of losing important bookmarks and cookies and such if the machine unexpectidly loses all power including battery or if normal shutdown scripts otherwise fail to be callde) you could probably just copy this file in and replace it with a symlink.
Your mistake here is thinking that these "middle class" Chinese people are not aware of Tiananmen/June 04. Indeed they all know about it, and are still supportive of the government's action.
A lot of the people who know about it only know a sanitised version of events ("a bunch of students tried to incite a violent dangerous and unjust revolution and the army valiantly stopped their attempt to damage society" or some such), not the whole truth. Many will guess that there was more to it, many will know there is (through information sources not controlled by the government), but many more will not or will not let themselves be interested enough to enquire in case such an enquiry gets them marked as a troublesome individual.
Slashdot Mirror
Calm down lad.
I read your post, specifically the bit that said most home used don't have a need for RAID. To my mind it was written in such a way as to suggest that there was no common case for RAID being useful to a home user, something which I considered incorrect.
My use of the word "actually" was intended to imlpy a mater-of-fact voice, not a ner-ner-ne-ner-ner voice. So don't SHOUT like I've just shat in your rice pudding.
Actually, there is one place where many home users will see the performance benefit of RAID: game/level load times.
I have my games installed on a RAID0 set over two disks and the difference is quite noticeable for some of them. Of course nothing I truly care about is kept on the RAID0 volume, and I keep copies of save files and other user content backed up elsewhere in case one of the drives dies taking the array with it.
While it is true that the OS can never know for sure what layout the disk has, it is fairly safe to assume that data which is sequential according to the filesystem is also sequential on disk much more often than it is not. So unless you are spending a lot of CPU time computing your read ordering method it would theoretically make a noticeable positive difference on average.
Of course when we are all using some form of solid state drive instead spinning disks, were the difference in read latency between a next-block read and a the-other-side-of-the-disk-from-last-time read is zero (or as close to as makes no odds) the point will be moot. But it will be a while before the price differential comes down (and end-user confidence in the reliability and performance related properties goes up) to the point where SSDs are more common than spinning disk based drives.
I think this is a relatively recent addition. In the kernel as provided as the official one in both Debian/Etch and Debian/EtchAndHalf RAID1 arrays read at the speed of one drive. The change to make it try balance the reads was made a minor version or two after the version those distros use as their base so it is present in the newer Lenny (though I have not yet got round to doing any performance tests on the one Lenny box I have with a RAID1 array to see how much difference this makes).
See http://kernelnewbies.org/KernelProjects/Raid1ReadBalancing and the patch it refers to that updates the feature, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=06386bbfd2441416875d0403d405c56822f6ebac
So for better RAID1 read performance with software RAID in Linux, make sure that your kernel is new enough (or has had that particular update back-ported and patched in.
Unfortunately that doesn't cover instances where OEMs who have purchases the license implement the file system with a bug that doesn't surface until it hits a directory written to by this new driver. Bugs like that can hide for a long time, even in code that is otherwise good.
This sounds dangerous to me. What if someone uses this to write to an SSD card that they plug into some cheap portable device (a media player for example) that doesn't implement the "standard" properly and gets confused by the data in the short filename when a long one is present? Or refuses to read half the files because it only likes short names (some cheap Chinese import MP3 players just use the short filename in displays) and half the files have names too long? The user won't blame their crap cheap little portable device they paid $3 for on eBay, they'll blame that there Linux thing because their copy of Windows can write things so the player understands.
Just goes to show you shouldn't be the first to buy any new gadget.
Early adopters always get burnt in some way. It is just more literal in this case.
Also the code that they have written may be dual-licensed - GPL and , with the ToS mainly declaring the terms for and letting it be known there is a choice.
Spending hours or more coming up with something that will handle all the different jacked up versions of javascript just to get a few more addresses doesn't make much sense.
Yes, but it works both ways. Once one person has gone to a bit of extra effort for shits and giggles (or because they were paid to?) and the code gets out (is deliberately released, is sold an leaked, or just leaked) it becomes so easy to copy the technique in some cases that is a no brainer to do so to catch that extra 1%.
I'm sure that some address farming bots have been passing script blocks containing little more than document.write calls through one of the several freely available javascript engines for ages. It is not as if they have to write even a partial interpreter themselves. The address having been interpreted by Google and therefore existing in their cache makes little difference at this point.
I don't think that this qualifies as a criteria for "winner" or not. However, it certainly speaks volumes about the society she's part of.
Either that or it just says they wanted to do something different and couldn't think of anything else that hadn't already been done yet the church would not object to...
The summary missed a bit:
"and get off my lawn!" he continued in a raised voice, waving a stick in what was presumably intended as a threatening manner
He is entitled to his opinion, of course. But I think he is missing the point by a few lightyears on this matter. And wrong as he may be on this matter, that doesn't invalidate anything he said/wrote previously.
Is this really a completely new idea, or just an extension of what Valve games have done for ages?
In all the HL2 series (and maybe before that) you've been able to change the general difficulty between the three levels mid-game. I normally do fairly well on "normal" settings in games, but I did once find this feature useful (in HL2, the prison complex, I forget exactly where on the level) for getting past a frustrating point so I could stop banging my head against it and get on with enjoying the rest of the game. I imagine that people looking for a more-casual-but-not-always-set-to-too-easy experience would use the feature quite a bit.
What Nintendo are talking about here seems to me to just be going one step beyond this, changing the available levels from Hard/Normal/Easy to Hard/Normal/Easy/Autopilot. Nothing revolutionary.
waste heat is dumped to the outside world
That's the part I'm talking about. Seems like that heat could be put to good use somehow.
There are projects in that direction, though they dont tend to be big news except getting a mention when New Scientist run a "green issue". The problem though is that the energy involved is often not enough to be particularly significant once you consider how much is left after the conversion and transportation processes needed to make use of it elsewhere.
There are various ways the energy can be used if you get beyond the "not enough to be genuinely useful once you've transported and processed it" problem. In cold areas it can be used as part of the heating system for offices in the building or near by (straying off-topic a little: energy sapped from the cooling towers of power stations is sometimes used this way), for heating water, if you have a *lot* of waste heat you can try convert it to electrical energy and feed it into the air con systems of the server rooms themselves, and so on.
The trouble is that the investment in technology needed to reuse the "waste" heat is currently often more expensive than the savings it provides through reduced energy use elsewhere, so most companies will only do it if they want to show off some green credentials for publicity reasons. This will change over time, as the technologies are refined and become cheaper and as energy prices rise.
Unless the email looked a lot like gobbeldygook because they emailed it to someone for whom english was a (distant) second language, or they emailed it to 'support' and there wasn't anything in the flip book to cover that. It's a bit hard to tell from the timeline if the contact attempt was anything more than cursory.
The rundown on that site says the second response was "Sorry for the delay. I am currently looking into this, and will reply in a couple of hours time" which implies that the messages was understood.
Of course we only have one person's word for that, and we don't get to review the initial emails to see if they were written well enough...
Two WHOLE WEEKS! Yeah, right.
But *all* they needed to do in those two weeks was download the provided vulnerability details and acknowledge that they were intending to investigate?
As I said above I agree that two weeks was an unprofessionally short timeframe for full disclosure of issues this serious, but not even attempting to access the provided information in two weeks shows shows a severe due diligence failing on the part of the vendor too.
Reading through the information on Milw0rm's own site, it appears they had an email exchange with someone at LXLabs for two weeks, then decided on their own to release the information. Two weeks is not nearly enough time to even decide if something like this is worth looking at, let alone find a fix, develop it, test it, implement it, and push it to all clients.
Fair enough, I would agree that in most cases two weeks is not nearly enough time. Even if you can, by some superhuman feat of organisation, create+QA+publish a fix/workaround that day it'll take time for the users to test and make the update available on their services (you can't just chuck a patch on a large production system without some oversight).
But I would certainly not go as far as to suggest that two weeks is not enough time to decide if something like this is even worth looking at. To have not even accessed the resource containing further exploit information (I assume this was available on a service that would log access, an unadvertised and unlinked location on a web server for instance) in two weeks seems wrong to me. Would you not at least download it, virus-/other-check it, and attach anything relevant to your internal record for the issue so the team/person who reviews these things has access to the info?
Having read the released information I would agree that Milw0rm's premature release was at least unprofessional if not down right irresponsible, but (assuming Milw0rm's report is true and accurate) I think that the vendor's response was similarly lacking in due diligence.
But that is not much less dangerous than just announcing the details. Letting the world know that an exploit exists is tantamount to challenging any black-hats out there to go look for it. Look for it some will, find it some might, and if some find it before fix is released and commonly installed you can bet your bottom dollar there is a chance at least one will use it for personal gain or just plain old vandalism. By announcing an exploit without details you just delay the inevitable (or, perhaps, speed its arrival almost as much as a detailed announcement would).
Why is it not an option? It isn't the best option, which is to announce that an exploit exists, but not release the details.
I would agree that this is the best way to proceed initially, but what if no body takes the report seriously? Also, without releasing any details how does anyone verify that your attack is valid and not just you trying to defame the supplier?
Announcing that there is a problem but not releasing the details is not as much less dangerous as your post suggests you believe. As soon as such an announcement is made I'm pretty sure a number of black-hats out there will immediately start scanning for the issue and there is a fair chance one will find it in time to make use of it.
My suggestion would be:
Of course one problem with this, and any other vulnerability announcement, is that the company involved may try to silence you with litigation (or threats there-of) as well as or instead of taking action to fix the issue. That could get very thorny. But any decent software supplier should be grateful of the initial heads-up and would be quite forthcoming if asked for progress (like saying "we've reproduced the issue and expect to have a patch available in X days" or "a full update may be delayed because of X, but a workaround is being tested and we expect to announce it in Y days"). I would be, as I believe would my employer.
Of course the problem will not always be down to the software supplier - it could be a local configuration issue in which case they should tell you and perhaps add extra warnings to relevant documentation to reduce repeat occurrences.
I have very mixed feelings on security firms releasing exploits to the public just to try and get results. In my (admittedly limited) experience, more bad has come from releasing exploits publicly than good.
-JJS
But once you've informed the supplier, and allowed enough time for a fix to be created, tested, rolled into a patch, QAed, released to clients and tested+installed by clients, what other alternative is there? Quietly forgetting about it and just hoping that you are the only people who know about the issue and no black-hats out there will find it is simply not an option.
Maybe it's because Japan has one of the lowest rape per capita countries.
They have the lowest reported and recorded rape rate. In many places there is a lot of stigma attached to being the victim in these cases so victims are unwilling to come forward if they do they get little support, and from what little I know of modern Japanese culture I would guess that Japan is somewhere where this is a significant problem.
You can only state that the existence of the games reduces rapes if you can show that their rise has been responsible for a reduction in rapes. Can you point to any research that shows this to be that case?
Excellent though some are (my AA1 goes everywhere with me), the current crop of netbooks don't come close the in-use battery life of devices like the N8x0s. Extra life between charges without buying a chunkier battery would be very nice on my A1, and I wouldn't mind losing a chunk of processing power to get it as what I use the machine for is never CPU intensive.
Of course while the CPU and related chipset are a significant factor they are not the only reason Atom (or celeron) based machines drink more juice then something like the N8x0s. They have bigger screens running at higher resolution which eats power, they have more RAM (keeping 512Mb+ of DRAM live is more costly then 128Mb and the refresh cycle is needed even when suspended), they have a chunky SSD drive or spinning disk to give power to, and so an and so forth.
The obvious question is were there any Muslims on board. That would make the chance of a bomb much more likely than a meteor strike. I am not saying that it is very likely that an individual Muslim is a bomber, just that the probability of a lightning strike is minuscule.
You might be looking at a flaimbait mod there... If al qaeda or a similar group where to try the bomb+plane thing again, I'm sure they are bright enough not to use an obvious attacker for the job so "counting muslims" is not a statisticly valid risk assessment procedure. And anyway, they woud have claimed responsibility by now - there is no point commiting an act of terror to just let people think it was a natural disaster afterwards.
You are, in my untrained opinion, wrong about the lightning strike given the weather conditions reported for the time in that location. OK, so a strike powerful enough (or otherwise somehow affecting equipment sensitive enough) to down an airbus might be very unlikely but as they where flying through a hefty storm system I'd guess more likely than one of the passengers happening to be a very naughty boy.
I'd say a meteor strike is far far less likely too, but without some analysis you can't completely rule it out. "Very very unlikely" is not the same as "impossible".
I read somewhere that statistically, airplanes are safer than cars, you're more likely to die in a car accident. I also read a quote somewhere else of somebody saying "Airplanes might be safer than cars, but I'd rather arrive at my destination with a false sense of security than feel like I've narrowly escaped death."
Then the person in the second quote needs to adjust their attitude to the relevant risks to better match reality!
Though it isn't really their fault - we all do the same thing. The automatic risk assessment abilities of the human brain were simply not designed for this sort of thing so we have to consciously calculate the odds and then beat our sub-concious into agreeing with what it sees as an unintuitive result.
Media attention has a part to play to. While more people die in road incidents in total (per mile travelled, amongst other measures) more die in one go with an air incident, and air incidents are more rare, so such incidents are more "news worthy" which means the average air related death gets a lot more media attention than the average road related death. This means that we (the media consumers) think about them more so the incorrect impression (air is less safe) is further reinforced.
Most Eee PCs have two SSDs: a large, slow one and a small fast one. Firefox became a lot snappier once I moved my profile directory to the fast SSD. Obvious in retrospect, I know...
If you have >512Mb in your netbook you could do what I've done: I keep the entire profile in RAM (on a tmpfs filesystem). On bok the profile is copied in to the ram drive and on shutdown it is rsynced back to the SSD (using --inplace to reduce copy+write operations on the urlclassifier db).
OK so it lengthens boot time a little, but it isn't often the machine is properly shutdown anyway (it tends to be suspended when not in used instead) so doesn't do a full boot often.
The urlclassifier db appears to be the main culprit for the "unexpected" IO in firefox. and even with all the relevant features turned off it seems to keep updating the file. If you don't want to put your whole profile in RAM (there is the risk of losing important bookmarks and cookies and such if the machine unexpectidly loses all power including battery or if normal shutdown scripts otherwise fail to be callde) you could probably just copy this file in and replace it with a symlink.
Your mistake here is thinking that these "middle class" Chinese people are not aware of Tiananmen/June 04. Indeed they all know about it, and are still supportive of the government's action.
A lot of the people who know about it only know a sanitised version of events ("a bunch of students tried to incite a violent dangerous and unjust revolution and the army valiantly stopped their attempt to damage society" or some such), not the whole truth. Many will guess that there was more to it, many will know there is (through information sources not controlled by the government), but many more will not or will not let themselves be interested enough to enquire in case such an enquiry gets them marked as a troublesome individual.