Ridge A is around 81.5 degrees South latitude and 73.5 degrees East longitude.

But the top of the Antarctic Plateau is extremely flat. From the 4093-meter "summit" at Dome A, where PLATO is currently operating (note: 233 days unattended in 2009 and still counting), you only lose about 40 meters of elevation going to the Ridge A site at around 4050 meters -- 90 miles or 150 km away. That's only a bit over one hundred feet or so in elevation loss over that distance!

The excellent conditions would extend for many many miles in each direction, so it's not like you have to hit it spot-on.

The difficulties with Antarctic instrumentation are surmountable. Even the slightest breeze, say 1 m/s (2 mph) is enough to take the exhaust away from the instrumentation. You can also run your generators at a distance from the instruments, which is what PLATO does. And during the summer, use of solar panels (which are more efficient in the cold) reduce the need for generators. Icing is an issue in Antarctica, but if you keep ambient temperature air flowing over surfaces, they don't freeze over.

Those problems are very solvable. The PLATO experiment at Dome A has already done it. The really amazing aspect of the high Antarctic Plateau is that the air has almost no water vapor (for infrared and submillimeter/terahertz observations), and the atmospheric turbulence is almost completely confined to the surface layer (for infrared and optical observations). Put your telescope on a tall platform, and you have near-space-like image quality. That's gold right there.

In contrast, at temperate sites, the jet stream keeps a lot of (very fast) turbulence thousands of feet high, where it's hard to correct adequately, and you can't get above it while still keeping your telescope's feet on the ground.

This site eliminates all those issues -- giving you space-like observations at a teeny fraction of the cost of a space mission.

You might give this NetBSD Live CD a try:

http://www.jibbed.org/

It would be a fairly painless way to see how NetBSD 5 behaves on your system.

Folks with mod points should bump this (AC) parent up; it's pretty much spot-on.

Here are a few extra data points...

I've been following the NetBSD 5.0 branch since it turned -RC on sparc, i386 and ARM. It's a significant step forward in a lot of ways. For example, on my EEE PC 900, everything works... something not every Linux distro has managed to do.

In NetBSD, there seems to be a stronger realization that developer time is precious. For example, NetBSD suffers a lot less from 'superfluous redesign' than Linux. Many years ago, I wrote a few Linux 2.0 device drivers for a few ISA and PCI data acquisition boards I was using. I had to make fairly significant changes for kernel 2.2, then 2.4, then 2.6. And since then... don't get me started. I've had to fix inane code breakages in the 2.6 series several times. In NetBSD, my driver code didn't need to evolve a tenth as much. Code interfaces are just more stable.

Just the build system alone is a huge time saver on embedded systems. You don't have to go searching around for cross-compilers, toolchains and all the other things that can be painful in Linux (unless your vendor spent a lot of time to assemble them for you). In NetBSD, this stuff is all built right into the base system to begin with.

Admittedly, on the desktop, NetBSD is still more work than it should be, even compared to typical Linux distros. It's about like the other BSDs, and not so different from a basic Debian install, for example. There's a growing realization in the NetBSD community that 'making it easier' to get a functional modern desktop environment running is worthwhile. Hopefully this gains traction.

NetBSD is a really nice system, which undeservedly gets overlooked a lot. It's definitely worth a look.

No no -- not further into the visible than Hubble. The Hubble spectral range from that figure was for the NICMOS (infrared) camera only. It ignored all other Hubble instruments from far-ultraviolet through visible light!

By and large, the original assertion was correct -- Hubble's emphasis was on UV, visible and near-infrared wavelengths. Most of the "pretty pictures" came from the visible light cameras. James Webb will be a large telescope optimized for near/mid infrared observations, with some capability at the red end of the visible spectrum. Herschel is optimized for far-infrared and submillimeter wavelengths.

All three observatories are hugely significant and will give us very different views of the Universe.

Yes. I found this old-ish article handy for actually using it. But there are also articles that discuss how to reduce the libc size as well.

Or just simply NetBSD [....] IMHO, build.sh is just the way to go.

Finally! I think it's amazing that we're discussing embedded systems, Linux, BSD... yet ignoring NetBSD, which is the flavor that most caters to embedded systems!

build.sh is a great example of one of those unheralded "little things". If I'm on my Mac OS X laptop and want to build a NetBSD ARM kernel or distribution for my embedded single board computer, I don't have to go fussing around with finding and downloading cross-compiling toolchains and figuring out how to make them go, etc. I just add a single flag to the normal build script that's part of the OS source code:

./build.sh -m evbarm kernel=MYKERNELCONFIG

And that's it. It will build the toolchain and then the kernel. It's so simple, it's brilliant.

NetBSD tends to get ignored a lot, but IMHO undeservedly. It is on a par with Linux 2.6 and FreeBSD in terms of speed, is flexible and feature-rich, has a nice ports/packages system and doesn't suffer from a lot of "superfluous redesign" (Linux, I'm looking at you). It's a really nice clean system and it's easy to get the basics done. It deserves more attention than it gets.

That said, the original question was "Linux 2.4 or 2.6?" If you can strip 2.6 down to fit within the confines of your embedded system, by all means go for it. This is especially true for new small x86 devices, where 2.6 is typically the baselined kernel anyway. On other architectures, it varies. On many ARM flavors, 2.6 is getting shaken out and 2.4 is still often the default. I suspect that the transition will complete this year.