I think this refers to binary liquid-liquid explosives. There are lots of simple explosive mixtures which involve a relatively inert powder such as ammonium nitrate, plus a liquid sensitizer such as nitromethane (used in race car fuel). All of them that I know of require a blasting cap, which will show up on an x-ray and might trigger a magnetometer.

Yeah, it's not right to kill captured terrorists, but I don't see anything wrong in ripping their eyes out with the silverware from First Class.

From the vague and incompetent description by the news media, the explosive device sounds like Kinepak or something similar. This is a little tube filled with ammonium nitrate, aluminum powder, plus proprietary stuff; to which you take a tube of red liquid (nitromethane and dye) and pour in the top. Eventually when the liquid soaks all the way through, you have a cap-sensitive blasting agent that's about as strong as dynamite when in a confined place. There's plenty of room for "operator error", though, as this material has to be handled properly if you want it to work. And it needs the right type of blasting cap. But even if he did everything right, I don't think it's powerful enought to bring down a jet unless it hit something critical.

I bet EMC is happy they just out-bid NetApp to the tune of $2.4 billion, for basically the same technology that Jeff Bonwick is giving away for free.

Since the Google 10^100 contest has descended into obvious bullshit and has turned out to be a waste of time (silly us, thinking they were serious about this effort), I hereby propose that we use up Slashdot's storage and bandwidth by posting our rejected ideas here. My idea isn't anything special, but the rules were that it had to be done with a modest grant (I loved the ones about using VTOL aircraft and passenger airships, yeah, that sounds cheap). Anyway here is my idea:

After a severe or prolonged disaster most people will not have access to phones or internet, especially in poor areas, so re-connecting with loved ones is nearly impossible (think about all the missing persons posters after 9/11 and Katrina!) I therefore propose that we develop free software for use by NGO's, the Red Cross, and other volunteers which will quickly scan handwritten information forms, and upload them to an OCR back-end index and portal, hosted by Google. The blank forms will have a bar code -- the refugee returns to any connected terminal and scans or types the code to receive any information the indexing technology can find about loved ones. Any form that cannot be OCR'd will be posted on the internet in a "Mechanical Turk" arrangement so that volunteers can help index the data. A single laptop and inexpensive scanner connected via HAM radio, SatPhone, or CellPhone can easily process thousands of requests per day, which would be impossible if each refugee had to use the keyboard and navigate through a search site.

Blank forms will have language-selection tick boxes which match the country, plus a few major languages like English. If forms are not available, the software should accept regular paper and issue a unique serial number to the refugee which can be written down. There can also be a few "standard responses" like the Red Cross "Safe and Well List" website has (note that this website is useless unless each refugee has unfettered access to the Internet which is why my idea will re-unite families much more effectively). We could also establish a phone bank connected to volunteers.

I think the first stage should be to create an extensible communications spec, then write the code for PC's, then perhaps later design a solar-powered ruggedized appliance.

After reading the thread on a mirror, it's important to note that after the argument, Alan and Linus continued to debate the technical merits of how to patch the bugs. The ongoing conversation was civilized and concise. Of course Linus is too much of a pompous ass to apologize to Alan for completely misunderstanding the problem and proposing dangerous and useless ways of fixing it, then arguing about it ad nauseum. Oddly, this doesn't seem to bother Alan or maybe he's just used to it. I don't personally care what happens to the linux kernel but let me suggest that any of you who depend on a stable USB stack need to take special note of whatever decision Linus finally makes.

I wonder if Linus visits Hans Reiser in prison... they seem to have compatible personalities.

That's not a very helpful calculation. The OP is concerned with the possibility of data loss due to drive failure, which is a function of MTBF of the drive and his MTTR of replacing a defective drive (MTTR includes the rebuild time for simplicity). In other words, he won't lose data unless the second drive fails during the vulnerable window of time before the first defective drive is replaced and rebuilt. A better question to ask perhaps is what is the MTBF of Windows (and/or the application software and/or the user and/or malware...) not destroying the data partition (and it's mirror). Probably happens 1000 times as often as a dual-drive RAID-1 disk failure. My suggestion would be to have good backups, and for really critical stuff store a copy in a USB drive at some other location.

Wow, that's an incredibly stupid thing for Lenovo to do. I was about to order a Lenovo for my next laptop and if it worked out I was going to ask our IT department to change from the current incumbents (Dell and Sony) to Lenovo for our sales and executive staff. I'm going to wait to see that this issue is fully resolved before making a move, and if they don't fix it, they can forget about 20 to 30 laptop orders a year from my company. I don't think my emotion would be unique -- I'm sure 90% of IT managers would disqualify Lenovo if they knew about this spam pop-up problem and didn't have an easy way to disable it enterprise-wide. Billions of dollars are at risk for something that probably only brings them a few hundred K$ per year. Bone-headed.

The only reason I use tabbed browsing is because the BACK button is slow/unreliable/unpredictable. As far as I am concerned, the BACK button should instantaneously take me to the rendering of the most recent web page unless the page has some kind of meta tag which indicates that BACK requires either a refresh or is totally prohibited (e-commerce, banking, etc). But for ordinary surfing, the links on the previous BACK buffer are still valid and if only the browser remembered the previous page's contents we could have instant BACK functionality.

Why is it that Google doesn't have to worry about FCC, CE, or UL safety and EMC regulations? And why are they using a RoHS prohibited battery which uses lead???

Not implying anything, but has anyone checked to see where Dick Cheney was this morning?

My company makes long term disk-based archiving products, so I'll give you my elevator pitch about how we approach this concept: First, yes indeed you need to spin up the drives periodically but not because of lubrication. Rather, it's because the components in the HDA "outgas" and particles condense on the media. Running the drive and scanning all cylinders breaks these particles loose before they can accumulate to dangerous levels and the rotation of the media causes the flow of air through the filtration system. In our system, every two months we read every file on the disk and verify its cryptographic hash. If there are any errors we repair using either the RAID parity drives (and then re-check the hash) or we use a second copy we keep on a different RAID shelf. Asynchrounous to this process, we have a raw media scan every two weeks on the RAID shelves which verifies that each drive thinks its data is readable (and if not we re-construct it and map out the newly bad blocks). Error stats are sent to the end user and to our tech support center so that if numbers start to climb we can start looking at a forklift upgrade of the hardware and automatic data migration of the user data. Protecting the data is also what you might call a "disk firewall", which means we have a modified disk driver which won't write to the repository unless the data is coming from a cryptographically signed process, and likewise, the RAID controller won't respond to drivers other than the modified driver. These last steps help guard against hostile administrators or rogue processes running at admin privilege levels (not claiming this is foolproof but it means that only a specifically targeted attack on our system has any hope of corrupting the disk data).