I disagree with your list of reasons why the OS should do it:

1. "idleness" should refer ONLY to the SSD not being used, not the OS being idle, in which case they both have approximately the same information.
2. The OS should NOT hold unimportant writes for very long, and doing GC during this time does not change the possibility for important writes to be necessary
3. I agree here. However, on battery power, I would expect an SSD would be sent to standby very quickly as if it were physically spinning, in which case the SSD firmware should know better than to do GC during standby, and with a definition of idle being 5+ minutes of zero-usage, it could be effectively the same as the OS not doing it on battery power. But I am only speculating

On my list of AGAINST the OS doing GC i have:

1. EVERY OS would have to support it in their next update to be as effective as having GC done in the firmware.
2. OS software engineers are not likely to know the best way to design a GC for SSDs, leave it to the manufacturers who build the thing.

There are some pros to letting the OS manage it, but I think it's riskier. I would suggest the firmware do the GC but have an interface for the OS to override the GC for flexibilities sake.

I don't know about the word honest there, I would say it helps keep the government less dishonest, at least here in America.

I would feel better if they were making an AFFORDABLE economical vehicle that would benefit the majority of Americans (and the environment). Making 10,000 unaffordable "green" cars over 10 years has very little environmental impact and not worth my tax dollars in my opinion.

How does a company that makes $1,000,000 in profit over 1 full year, get 465 Million dollars in loans from our government?? How will they pay that back in a reasonable time?

search for "beta" on bing, google, and yahoo. Notice who's software shows up on the first page of results. If you don't want to look for yourself:

Bing: 2 results for MSN messenger
Google: 1 result for safari, 2 results for google chrome
Yahoo: 1 result for AOL, 1 for yahoo IM

Now, I admit that google users are probably more likely to be looking for google software (the same goes for bing and yahoo), and if everyone tracks their users, that could easily account for the bias. However, it is also possible certain key words are tweaked. It's not hard to add a bias to good results for one's company in their own search engine (by making use of key words and popular search queries).

From the article:

At that age, I'm amazed they look so much like the spider I killed on my driveway the other day.

Now that I've actually read the article, I discover the information was NOT classified, though considered so sensitive "it would not have been available even with a Freedom of Information Act request." Even so, information is leaked by people, not P2P software.

Even if it was encrypted or password protected (implies some form of encryption), this kind of information is obviously classified and should not be on computers with external internet access. I didn't read the article yet, but i doubt P2P networking is why it got leaked, just the medium used.

I don't think he's thought this bookshelf application through... a cell phone camera won't be able to take a picture with enough resolution to read more than a few bokodes at once. If you watch the video it fills up 1/10th of the video frame before a simple computer would be able to understand it. Also, bokodes on books close together would undoubtedly overlap if you could see several books in one photo, let alone 20 shelves worth. Not to mention, first you'd have to tell your cell phone what you want, or read the results of every bokode. I think Dewey's system will be much faster to those who know their alphabet.

One final note, I want to see a working example on a cell phone camera. Cell cameras can't change their focus... soooo.. you'd have to be at the exact same distance from the bokode every time you want to read one, right? Am I missing something?

Anyone notice the "average" windows machine selling for $515 sucks? If you compare equally powerful machines, you will get _similar_ costs. I would say a mac would still be slightly more expensive, but that's just a guess.

I haven't tested it, but moblin seems to be close to what you want already, you just need a netbook...

http://moblin.org/

I agree with you, web applications are overrated, and overused. Certain things should be left to native code, or at least a decent virtual machine. Anyone else notice that our processors get faster, our internet access gets faster, and even still, web applications get slower and slower?

That reminds me, who is going to sue Google for distributing their OS without choice of browser... United States vs Microsoft

they already are part autonomous:
http://marsrovers.nasa.gov/technology/is_autonomous_mobility.html

At least when it comes to driving. The NASA guys are pretty smart, and I'm sure other tasks are as autonomous as they could make them with the technology they had when they built them.

What a comparison. It's almost as fast, but not quite as fast, as a much earlier and slower version of the fastest browser.

I can't say I've reverse engineered a compression algorithm, but I have used many compression algorithms in my programs. I would say it's unlikely you will be able to reverse engineer it unless you are a very solid programmer and/or have experience with reverse engineering. Nevertheless, I'm sure there are some tools that could help.

I see two approaches:
1. Actual reverse engineering. If you know enough assembly, you can use an assembly debugger, and various other hacking tools to decompile the dll and step through the code used to compress the text file (i suggest using a very small file for testing). If you carefully follow the execution path, you may recognize the compression algorithm used (if you know enough about compression algorithms), or with even more time you can decipher their custom compression algorithm. This can take a lot of time and patience even if you are experienced.
2. You could try some standard text compression libraries that are freely available to the language the software was written in, like zlib for C++ or a set of LZW libraries, with default settings and manually or programmatically compare the output to the compressed file. It's highly unlikely you will get a perfect match, but you might find the beginning of zlib headers matches part of your compressed file, which would suggest that it was compressed with zlib. If so, you can use zlib to decode the file with the right settings. You also need to consider custom headers in the compressed file. Most compression software will place headers/footers in the file with information like the compressed size, decompressed size, compression settings, and version information. If it's a simple program, it's probably at the beginning of the file, followed immediately by the compressed data.

Of course, this all requires luck. If it's obfuscated in anyway, encrypted even with the most basic encryption, you will need some serious experience with #1. There are tons and tons of text compression algorithms. If it's designed specifically for text, you know to look at those rather than just generic compression algorithms. You can also look at the compression ratio of various files to get a feel for what algorithms could have been used.

All in all, it's possible, but don't get your hopes up.