The LOL was aimed at the boldface text. The C++ preprocessor is an underdesigned relic of C which integrates very poorly with the C++ feature set. To describe it as "best" is laughable.

(C++ is also a piece of shit for writing functional-style code, but I'll give that one a pass.)

Objective, generic, functional -- its all there and accompained with the best preprocessor, macros and code generators

LOL

I don't agree that this is a hatchet job. I am concerned by the volume of highly-rated applications on the Android Market which require permissions that should be unnecessary. As you point out, the Android platform enumerates the requested permissions in a very visible way, which is great. The problem is cultural: users do not question these permission requests as much as they should.

I would really like to be able to selectively deny certain permissions to applications.

People who have performance drives *already* use eSATA (seriously, firewire? Is this 2002? Worse, you then go on to talk about CPU usage, where again the answer is "use eSATA")

eSATA is a nice technology in general, and certainly looks like the future of commodity high-speed external storage, but I expect that it will take a couple of years before the OS/driver support matures. As evidence: take a random sampling of eSATA host controllers and you'll find a disturbingly small percentage that provide driver hooks to safely unmount the drive. You'll find an even smaller percentage that does this *reliably*.

1394 drivers are pretty mature these days, so one doesn't tend to run into those sorts of issues. 1394b also gets close to 80MB/s in practice (not just in theory); it takes a pretty fast HDD to saturate that kind of bandwidth. I would argue that 1394 is still a pretty good choice in 2009, although it's clearly on the way out.

Not sure how serious you are, but you've got it backwards. A future FSF could create a GPL with more liberal terms of distribution. Suppose the license permitted binary-only distribution in exchange for a generous donation to the FSF--probably most developers would have a problem with that.

It's difficult to imagine such a scenario today, but I'm sufficiently paranoid to expect that the FSF may not always be trustworthy. All it takes is a gradual shift in the voting membership.

If the FSF continues to release reasonable licenses, a developer can retroactively relicense old software releases under the new versions of the GPL. No risk to the developer, just a little more bookkeeping work.

if GPL then GPL v3 *and higher* (don't forget).

Or not. The "...or higher" language implies a great deal of trust in the FSF. There is risk in making that decision: the FSF could one day release a GPL which offers terms that the developer disagrees with.

It is entirely reasonable for a risk-averse developer to distribute software under a single well-defined license rather than an unlimited number of undefined licenses.

I've helped to guide a bunch of SATA boards from prototype to product. From personal experience, I can tell you that a switch put together "half-decently" is very likely to result in unreliable SATA communication.

Well, if you include a few more pins, then you should be able to merely extend the current design to include the data cables...

Only if you want to deal with a bunch of CRC failures. You can't really expect to be able to mess around with signal lines when you're switching at 1.5 or 3.0 Gbps.

By convention, "lock-free" is sort of an ill-defined term that roughly means "no software-based locking operations, except maybe we'll ignore spin-locking, provided the algorithm always makes global progress while spinning occurs." In any case, there is no common definition for "lock-free" which implies the absence of hardware locking.

I'm not sure there is anything radically new in this project. However, given the exceptional difficulty of writing correct lock-free algorithms, just about any project exploring this area is noteworthy.