What those 77% of people fail to realize is that we can no longer organize ourselves well enough to accomplish this sort of task. NASA, as an institution, long ago stopped being about technical successes and exploration. During my years working with NASA, I discovered that a NASA manager's career success is measured solely by the number of people they manage and the size of the budget they control. Not by how many successful missions they achieved, not by the technology breakthroughs they fostered, and not by any other rational measure beyond their org chart success.

So we have no government agency capable of focusing on such a complicated goal as landing humans on Mars. They immediately get distracted with project management issues and politics. If private industry were to try and undertake this effort, there would have to be some financial incentive for our largest private spacefaring corporations to try and cooperate, since none have the resources alone to achieve the goal within 20 years. And the only model they have for organizing themselves is NASA today. No one still working in the industry knows how NASA of the 1960's worked, and society has changed to the point that the technical people required for such an effort are no longer motivated to make the selfless sacrifices needed to achieve such a goal. All the good engineers left aerospace for the Dot.Com world in the '90s. Those remaining few are motivated by commercial and personal financial success, and that requires a much shorter planning and gratification cycle than 20 years.

Sorry, we won't be going to Mars. We're a bunch of greedy, self-absorbed, small-minded apes that have reached the pinnacle of our organizational skills at the bottom of our gravity well.

Many ARM-based chips include the "Jazelle DBX" (Direct Bytecode eXecution) hardware CPU extension, which lets "95% of [JVM] bytecode" be executed directly by the CPU -- without need for recompilation to 'native' ARM/Thumb instructions. (See http://en.wikipedia.org/wiki/Jazelle )

However, unlike most of the ARM universe which is fairly open, Jazelle DBX's specs, implementation, and operating details are apparently a closely held secret, shared by ARM only with select JVM implementors. I'll be interesting to see if ARM decides to help out the OpenJDK people. Googling around, it looks like so far the answer has been "No."

That is a GREAT question, and the full answer is complicated and partially proprietary. But basically, you've touched on the problem of indirect control flow, which exists in C (call through a function pointer), C++ (virtual function calls), and in Java, .NET, ObjC, etc. The general approach is that at each indirect call site, you "solve for" what the actual targets of the call could possibly be, and take it from there. The specific example you gave is actually trivially solved, since there's only one possible answer in the program; in large scale applications it is what we call "hard." And yes, in some cases we (necessarily) lose the trail; see "halting problem" as noted. But we do a remarkably good job on most real world application code. I've been working with this team on this static binary analysis business for eight or nine years, and we still haven't run out of interesting problems to work on, and this is definitely one of them.

Oops, I wasn't logged in. The above comment is from me, Mark Kriegsman, Director of Engineering at Veracode.

Nevertheless, White Flame, you should be proud. The SWEET16 implemention is pretty damn tight. If you can even squeeze out one byte, or one cycle, from a Wozterpiece like that, I say Congratulations, and Well done.

Assuming that he'd filed for his patents before the USPTO went insane, odds are low that they would have survived the prior art test. As others have mentioned, Gopher, FTP, and even several BBS systems would have been able to cover the prior art for the HTTP component. HTML was really just a bastardized version of SGML. And the entire concept of a hypertext page was predated by HyperCard and a bunch of work at Xerox PARC.

Why are we even having this discussion?

As it turns out, the real problem on these platforms is power generation. With synthetic aperture radars, flight control systems, on-board mission management systems, laser designators, EO sensors, and LOS and BLOS/satellite comms gear on board, the problem of supplying electricity for all the systems becomes critical.

I worked on the original J-UCAS program which transitioned from DARPA to the Navy, and designing the autonomous flight and mission management systems was the easier part of the problem. Creating the comm infrastructure (software defined radios), the operational procedures, the peer-to-peer cooperation, and mundane stuff like dealing with air traffic control turn out to be much harder in practice.

Definitely one of the coolest projects I have ever worked on and I'm glad to see one of the J-UCAS derived UAVs finally getting into the air.

It's just as shallow to compare a desktop software application's success to the much more transient, ephemeral, and difficult to quantify success of Facebook. Better to look at the Internet as a whole and ask a couple of simple questions.

First, name one network-wide, user-oriented application level service that was present when the commercial Internet opened for business in 1991 that is still in operation and use today.

Discounting UseNet and Email as infrastructure, the answer is likely "nothing." It's instructive to consider why. Early community plays on the Internet (The Well, The Globe, AOL, WebTV, and even MySpace) fell in succession, not because there weren't plenty of users and not because they weren't good services. They fell because, by definition, something newer and better comes along. It's the same reason we don't drive horse-drawn wagons to work. Supporting the infrastructure and feature set of an existing system means, by definition, that you will never be able to change and adopt new technologies as fast as someone else starting with a clean slate.

Second, what is so special about Facebook that it will avoid being obsolesced by the next cool fad? Answer again, "nothing".

Facebook's only advantage is the depth of its social graph. And as many posters have noted, the average Facebook user has a pretty static social graph and no need to add to it in any significant way now. Once you are fully connected, it becomes trivial to notify your graph that you are moving elsewhere, and then Metcalfe's Law kicks in. Once the infrastructure becomes distributed and you are no longer locked into a single service, people will be free to move their social graph and associated applications wherever they'd like.

Extrapolating the past lifecycles of similar, successful social sites to Facebook, it seems logical to conclude (as the author did) that Facebook's days are numbered. Maybe in the thousands, but numbered nonetheless.

The developer is at fault, not Apple. Apple is not party to the GPL terms just because a developer with a political agenda chooses to upload an application to the App Store. The developer is at fault for choosing a distribution medium for his software that is incompatible with GPL terms. It's not any more complicated than that.

The fallacy in this article is that designers are the ultimate arbiters of how a web site gets built. It's just not the case. If I am paying the bills and I want to reach the largest possible audience, my first instruction to the designer working for *me* is going to be to avoid Flash, Java, and anything else that is plug-in dependent like the plague. Flash sites are inaccessible to the vision impaired, they are not generally searchable, they are prone to breakage when plug-ins are out of date or non-existent, and they are generally not maintainable by the organization they were created for once they are delivered.

Sorry, but sticking with standards based solutions and tools that manipulate open formats is the way to go if you, Mr. Designer-boy, are working for me. In a market-driven economy, designers are a commodity, not an industry force. They're gonna do what they are paid to do.

Actually the real reason is the pyrotechnics that are used to deploy the landing gear and the drogue chute as well. They both have to be armed and deployed manually by a series of buttons on the glare shield. It has been a long standing rule in manned space flight that anything that can explode on command like that is always operated manually unless it is impossible for some reason. The fact that neither system can be re-stowed after deployment is problematic.

I gave a couple of these for the holidays this year thinking that this would be a great way for family to share pictures but we had an unbelievably difficult time getting them to share what we wanted when we wanted.

Thank goodness that's all solved now!

HTTP-NG ( http://www.w3.org/Protocols/HTTP-NG/ ) was researched, designed, and even, yes, implemented to solve the same problems that Google's "new" SPDY is attacking -- in 1999, ten years ago.

The good news is that SPDY seems to build on the SMUX ( http://www.w3.org/TR/WD-mux ) and MUX protocols that were designed as part of the HTTP-NG effort, so at least we're not reinventing the wheel. Now we have to decide what color to paint it.

Next up: immediate support in FireFox, WebKit, and Apache -- and deafening silence from IE and IIS.

For an Mac OS X volume (HFS, HFS+), I've had lots of luck with Data Rescue II ($99) for recovering from serious drive failures. For drives that are still operational but have become borked at the filesystem level, Disk Warrior does a great job of rebuilding a healthy new directory structure. I make it a point to always have a copy of Disk Warrior within 100 yards of my PowerBook.

Also, a couple of times I've had dying drives that work OK for a few minutes after a cold boot, and then they (heat up and) die. I've had good luck throwing the drive in the freezer (in a ziplock bag) for a day, then powering up it, recovering as much as I can until the drive chokes again, lather, rinse, repeat, until all recoverable data has been copies off to a good drive.

He WASN'T throttled to 48Kbps -- slower than a 56Kbps dialup modem.
He WAS throttled to 480Kbps, and was getting download speeds of about 50K (that's kiloBYTES) per second (per connection).

TFA:"Bringing up the Status window I noticed my download performance was a far cry from my 7 mbps speed, but rather a measly 0.48 mbps...:"

0.48Mbps = 480Kbps (kiloBITS/sec) = roughly about 48KBps (kiloBYTES/sec)

So the /. story summary makes things sound an order of magnitude worse than they are. But you know, what's just ONE order of magnitude of error between friends, right?