An alternate suggestion if you want to keep the existing System Preferences: right-click ('ctrl-click') on the binary to bring up the context menu, then select 'Open". This will invoke the same warning, but will also allow you to authenticate -- allowing this binary to run (here and thereafter) without complaining.
I have an Asus EEE PC (900A) with NetBSD 5 that runs the stock X.org and uses the kernel Intel DRI driver (i915drm) for accelerated 3D performance -- pretty good given the hardware. There are DRI drivers for Radeon that I've also used, haven't looked into Nouveau. So the 3D support foundation is there, but the hardware pickings are still kinda slim.
Besides basic 3D acceleration, the continual 'catchup game' with desktop BSD is the explicit coding for Linux on the part of the big open source desktop environments, example: https://live.gnome.org/PortabilityMatrix
Thanks for a very thoughtful and informative post!
Where I started in this thread was posting a 1.2 MB kernel RAM footprint in vanilla NetBSD/ARM. This is with UFS/ext2/msdos filesystems, tcp/ip networking, NIC, USB standard devices (bulk storage, audio, etc.) loaded. It doesn't sound terribly far off at all. Outside of the XIP and nommu advantages, which are very significant, I'm actually curious whether it would boot in 2 MB with a minimal userland. The SoC hardware has 32 MB, so I've never bothered editing the memory map. I'll trim it further as your reference did and see what it'll do...
On the Linux side, I'm really impressed at how nommu and many other patches have integrated into mainline. I always expected the bulk of uClinux to be forever a separate patchset. It's great to see.
SMS's aren't particularly cheap. Also note that the message will travel over wireless 802.11 when available. It's cost effective, since I can sign up for a fairly minimal SMS plan and know that most of my messages are being carried by my devices' Internet access. It also means that I can receive messages even when I don't have cellular service but do have wireless Internet access.
Thanks, appreciate the link. But it sorta makes my point: - An allusion to a vapor product with a 3 MB RAM goal is far from showing a dmesg.:) - The linked "TLK" project reads nicely but has more aspirations than code, AFAICT - The included 'web browser' was a misstatement, clarified in a subsequent post.
I'm aware of (uc)Linux's lovely support for MMU-less systems. It was a considerable kernel fork; what I'm impressed with is how much of it has been integrated back into mainline. It's a pity that someone long ago didn't do for NetBSD what the ucLinux project did for Linux 2.6.x.
But the context here is Minix3 on vanilla x86, not microcontrollers. So as I said before, I'm looking for configurations of x86 or ARM running a modern Linux kernel (2.6.x or 3.x) w/ 2 MB RAM or 4 MB with busybox. I sound dubious but am genuinely interested if this is possible (and how far you have to go down the rabbit hole to get there).
Linux can be configured to run in 2MB of RAM and 2MB of flash or less. It can run in 4MB RAM with a full network stack, busybox, and several hundred K remaining for apps.
There is no other full featured free unix like kernel which can do that. Certainly none of the free BSDs.
I'll take the bait. Care to show a reference to running a modern Linux kernel w/ 2 MB RAM, or 4 MB RAM with busybox, on i386 or ARM? Busybox can do wonders for storage requirements (e.g. for NAND FLASH), but it doesn't help with RAM at all! I found 8 MB to be difficult enough (!), last I tried ulibc and busybox on i386.
Just as a point of discussion, generic NetBSD is smaller than generic Linux (e.g. Debian) on the ARM platforms I've been using. A line from top shows the latest (NetBSD 5.1.2) kernel RAM footprint on ARM9: about 1.2 MB, with numerous filesystems, NFS, networking, USB support, etc. built in. This includes all kernel modules.
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
0 root 125 0 0K 1240K schedule 0:00 0.00% 0.00% [system]
Running 1 instance of httpd, sshd, and two user processes, minus 1.5 MB of buffers/cache, it's using 5.5 MB of RAM right now. Tightened up, it might boot in 4 MB but I haven't tried. Do note that this is with the standard (Net)BSD libc, all completely generic, 'out-of-the-box'.
Amazing work has been done to cram Linux into small places, but I think it's somewhat disingenuous to say that no BSD is close. I'd say NetBSD provides a rather interesting starting point.
Sure, you can. But UUIDs are the default behavior in many distributions (fortunately, 'blkid' will tell you the mapping between/dev entry and UUID). I'm not saying it's a bad system. My point is that the parent's complaint about naming conventions in/dev is silly -- there are generally good reasons for each system's behavior. The complaint distracts the discussion from what's actually important.
Coming from a user of both Linux and both FreeBSD and NetBSD, I can't agree with the absolutes of your post.
BSDs are never easier than Linux. Linux is more modern, while BSDs stick to "tradition" and take pride in keeping things complicated. Just read their manuals/handbooks and you will have a pretty good idea.
An alternate wording: "Linux engages in constant superfluous redesign, while BSDs stick to conventional but consistent, stable interfaces that are well documented". The fact that up-to-date man pages and well-written manuals/guides exist says a lot by itself. Linux's myriad of ever-obsolete HOW-TOs is a poor substitute.
One good example of a painful process in Linux that is easy in (Net)BSD is developing for embedded architectures. I can be typing away on, say, a (PPC) Mac or a (Intel) Linux or a (Sparc) BSD box, and can cross-compile a NetBSD distribution for an ARM single-board-computer with one line:./build.sh -u -m evbarm release. I could replace 'evbarm' with 'alpha' or 'sparc64' or 'i386' or even 'vax' (!) and I would magically get a system built for these very different architectures, constructed from whatever system I want, all built from the very same code! I didn't have to rely on some vendor to package the cross-compiler or (very painfully) do it myself -- it's just a part of the basic NetBSD system. They got a lot of stuff right!
While I do agree -- "Desktop BSD" is still not where it should be for the traditional BSDs, Linux has a long way to go here too. However, PC-BSD has done a pretty good job of doing the basic grunt work that is otherwise sorely lacking. "PC-BSD is to FreeBSD, what Ubuntu is to Debian".
Your third partition on Linux will be/dev/sda3, but on BSD it will be/dev/ad0s3e (note that it numbers disks from 0 but slices from 1, and there is still the letter "e" for the partition inside the slice - isn't that simple?)
This is a red herring. (1) On my NetBSD system, the first disk is/dev/wd0a. That's not any different than Linux's/dev/sda0. (2) Who cares? Mac OS X shows my root file system as/dev/disk0s2, and you don't see everyone complaining that OS X isn't ready for the desktop! And sometimes the extra information can save your butt. Example: I have an old Sun workstation with 3 SCSI disks that has run Linux, BSD and Solaris at different points in its life. One of the more painful moments I experienced w/ this box was under Linux, when I removed a nonessential disk (mounted as/data) after removing its entry in/etc/fstab and unplugging it. I restarted the system -- and it would no longer boot -- because the/dev entries (/dev/sda, sdb, sdc, etc.) are enumerated in ad-hoc fashion, had reordered themselves, and the root drive was no longer where init thought it should be. In BSD and Solaris, the verbose naming corresponded to their physical locations on the SCSI bus, so you could pull a nonessential disk and it would still 'just work'. That prevented a ton of headaches.
These issues have been solved in Linux with unique UUID's, but now your entry for/dev/sda3 might instead say something like "UUID=1924d0d6-496d-4bbf-8fd1-aaaac6764bc5" in/etc/fstab. Good luck parsing the UUID to mean "3rd partition" unless your fstab file is well-commented! That makes BSD look positively friendly by comparison.
FreeBSD advocates spent a good portion of their time claiming that FreeBSD is faster than Linux. Maybe on servers under very heavy load. In all the tests I have made on a simple desktop, FreeBSD always felt a little bit slow, jerky, worse than Linux with a lightweight window manager such as LXDE (but not worse than Linux with KDE 4, for example).
While the average thermal velocity is lower than the escape velocity, the high velocity tail of the Maxwell-Boltzmann distribution is what's significant on long time scales.
It's important to state that room temperature isn't the most important number here. As you pointed out, the equilibrium point is high up in the atmosphere, where the gas is very dilute and can heat to a thousand degrees or more (solar UV heating and some contribution from solar wind). When you plug that temperature into the M-B thermal distribution, the fraction of atoms exceeding the escape velocity of Earth is much larger! In absolute terms, it's still a small number but enough to leak the helium out of the atmosphere over many millions of years.
Ultimately, it is the high thermal velocity that causes the loss of helium.
while i don't launch balloons - if that is the way you wanted to do it.. would it not make it easier and safer to secure it to a flatbed truck and drive it under the balloon then release then having a crane hold it??
The "crane" is needed to hold the payload still until the balloon ascends to pull the flight train and the gondola payload vertical. The tension in the flight train at balloon release pulls the payload horizontally, fairly hard. The flight train is typically 1000 feet long! While you could secure the payload to a truck, gondolas aren't generally designed to handle transverse loads at the load point. You really don't want them to, either; there's often (comparatively delicate) momentum transfer units at the load point that allow accurate pointing of telescopes once at float altitude (~125,000 feet, or ~35 km). And once you build a structure to take the pressure off the gondola load point, you're generally back to a crane design again.
You can see pictures and movies of our experiment's launch last year from Fort Sumner, NM. The StratoCat site has some additional details about this flight and many others, including ours.
Catastrophic launches like this are really rare -- the CSBF team really do a fantastic job. It's really had to tell exactly what happened here, though fairly high winds were a complicating factor. It's very lucky for everyone involved that no one got hurt.
Condolences to the science team, and best wishes that they can pick up the pieces and fly again...
I think you miss the point. Even a small 0.5-meter telescope in space is a SMEX-class NASA mission and costs well over 100 million bucks. If you can do some of the same science with a *comparably small* ground-based telescope, you win. By a lot.
Similarly, your 5-meter (or larger) telescope on the ground would be competing with SOFIA and Herschel and JWST for many applications. Those are all billion dollar class projects.
If you really want to compare a 10-meter telescope on the ground to a half-meter telescope in space, feel free... the costs start to get pretty similar. But the comparison in terms of scientific capability is not usually valid.
And by *usually*, I mean that there are some capabilities that can only be done in space. Ground facilities will never compete in those genres. But when you *can* do something from the ground, by all means you should do so.
BTW, these folks would be bemused by your comment that a half-meter telescope would be "uselessly small".
- The cost of doing almost anything, anywhere in Antarctica is not far short of a space mission.
Nonsense. Sure, it's more expensive than putting a telescope on Kitt Peak, Mauna Kea, or Chile. But you're still orders of magnitude away from a space mission. A half-meter telescope on a "small explorer" (SMEX) NASA mission is over 105 million dollars, and that doesn't include the launch costs. Getting that 250 kg into space costs on the order of $20,000 USD per kg, still a fairly conservative estimate.
Based on the overland traverses that the Italians and French undertake to Dome C per year, getting to a site like Ridge A would be more like $10/kg (naturally assuming that you're making good use of the traverse and taking lots of stuff up there in one go).
So the costs aren't even in the same ball park.
- It's "daytime" for at least half the year.
And infrared and submillimeter astronomers can observe during the day. Incidentally, most of the big outstanding questions about the assembly of galaxies and star formation will be solved at these wavelengths -- which is where the Antarctic atmosphere is most advantageous.
- You can see barely half the sky - probably less.
You get the Southern sky only, true. But most of the Milky Way is in the South, and you can observe it without interruption -- 24/7. Time domain astronomy is something we've only scratched the surface of -- and there are major new projects devoted to it such as LSST. Antarctica could play a significant role here.
All things considered, Hawaii and Chile are far superior in most respects which matter.
As long as you ignore the poorer image quality, unstable atmosphere with large diurnal variations, comparatively soggy atmospheric water content, 100x higher infrared background -- yeah, Chile and Hawaii are far better.:)
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.
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.
The article linked to showed the size comparison for the James Webb Space Telescope, and its spectral range vs. Hubble (further into IR, but also further into the visible spectrum)
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.
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.
Yes, that would have been nicer. In a hallway in the Steward Observatory office building, there was once a poster illustrating the proposed Super Huge Interferometric Telescope I think the poster was done by bored grad students.
FTA: "HST will be about 60% more powerful than it was right after the third servicing mission, before ACS and STIS failed."
The 1993 servicing mission generally restored the designed capabilities of the Hubble, the so-called "factor of 90" that the article mentions. Major new improvements and capabilities came with each servicing mission, culminating in the March 2002 servicing mission that installed the Advanced Camera for Surveys (ACS).
The upcoming installation of the new Wide Field Camera 3 (WFC3) and the Cosmic Origins Spectrograph (COS) will improve the combined sensitivity and field of view by 60% over the Hubble as it was after March 2002 (and before ACS died).
To be fair... by the same metric, modern ground-based telescopes with large format CCD and infrared arrays are on the order of 100 times more powerful than they were in 1990 as well. In the near infrared, the gains are closer to a factor of 1000!
It certainly is a bit of a misnomer, but the idea is to give researchers in both the Arctic and Antarctic two full summer/winter cycles to conduct their research under the blanket of the IPY. A single annual cycle is a bit restrictive for a lot of programs.
A lot of researchers are using the International Polar Year to springboard new projects that will begin, or continue, long past 2009. In fact, we hope to be one of those three groups launching an Antarctic balloon... in 2010. Our gondola will have a 0.8-meter far-infrared telescope that will try to understand how material in space cycles between stars and gas -- the "life cycle of interstellar matter". It's a part of our own story, since we are born from that material! (cue Carl Sagan here)
So a few IPY research programs won't be studying Polar regions specifically, but rather using them as unique platforms from which to study the Universe.
To clarify the "types" of infrared light we're talking about in terms of wavelength (a synonym for both energy and color):
0.4 - 0.7 microns: visible light. A wavelength of 0.4 um is deep violet, 0.55 is yellow, and 0.7 is deep red.
0.7 - 5 microns: "near" infrared
5 - 50 microns: "mid" infrared
50 - 200 microns: "far" infrared
Note that CCD's respond to light that has a wavelength shorter than ~1.0 microns. At longer ("redder") wavelengths, there isn't sufficient photon energy to free an electron from the silicon substrate into a valence band and be collected/counted by the CCD readout electronics.
Thus, the original poster is right that CCD's can "see IR", but it is only the very tip of the iceberg. Good enough for MIRT maybe, if the transmitters emit at least a little light shortward of ~1 micron.
Anyone know what wavelengths MIRT operates around? It is very unlikely to be mid or far infrared, since air itself (i.e. oxygen, water and nitrogen molecules) is pretty opaque at these wavelengths.
Slashdot Mirror
That is surprising, I agree.
An alternate suggestion if you want to keep the existing System Preferences: right-click ('ctrl-click') on the binary to bring up the context menu, then select 'Open". This will invoke the same warning, but will also allow you to authenticate -- allowing this binary to run (here and thereafter) without complaining.
I have an Asus EEE PC (900A) with NetBSD 5 that runs the stock X.org and uses the kernel Intel DRI driver (i915drm) for accelerated 3D performance -- pretty good given the hardware. There are DRI drivers for Radeon that I've also used, haven't looked into Nouveau. So the 3D support foundation is there, but the hardware pickings are still kinda slim.
Besides basic 3D acceleration, the continual 'catchup game' with desktop BSD is the explicit coding for Linux on the part of the big open source desktop environments, example: https://live.gnome.org/PortabilityMatrix
Thanks for a very thoughtful and informative post!
Where I started in this thread was posting a 1.2 MB kernel RAM footprint in vanilla NetBSD/ARM. This is with UFS/ext2/msdos filesystems, tcp/ip networking, NIC, USB standard devices (bulk storage, audio, etc.) loaded. It doesn't sound terribly far off at all. Outside of the XIP and nommu advantages, which are very significant, I'm actually curious whether it would boot in 2 MB with a minimal userland. The SoC hardware has 32 MB, so I've never bothered editing the memory map. I'll trim it further as your reference did and see what it'll do...
On the Linux side, I'm really impressed at how nommu and many other patches have integrated into mainline. I always expected the bulk of uClinux to be forever a separate patchset. It's great to see.
SMS's aren't particularly cheap. Also note that the message will travel over wireless 802.11 when available. It's cost effective, since I can sign up for a fairly minimal SMS plan and know that most of my messages are being carried by my devices' Internet access. It also means that I can receive messages even when I don't have cellular service but do have wireless Internet access.
Thanks, appreciate the link. But it sorta makes my point: :)
- An allusion to a vapor product with a 3 MB RAM goal is far from showing a dmesg.
- The linked "TLK" project reads nicely but has more aspirations than code, AFAICT
- The included 'web browser' was a misstatement, clarified in a subsequent post.
I'm aware of (uc)Linux's lovely support for MMU-less systems. It was a considerable kernel fork; what I'm impressed with is how much of it has been integrated back into mainline. It's a pity that someone long ago didn't do for NetBSD what the ucLinux project did for Linux 2.6.x.
But the context here is Minix3 on vanilla x86, not microcontrollers. So as I said before, I'm looking for configurations of x86 or ARM running a modern Linux kernel (2.6.x or 3.x) w/ 2 MB RAM or 4 MB with busybox. I sound dubious but am genuinely interested if this is possible (and how far you have to go down the rabbit hole to get there).
Linux can be configured to run in 2MB of RAM and 2MB of flash or less. It can run in 4MB RAM with a full network stack, busybox, and several hundred K remaining for apps.
There is no other full featured free unix like kernel which can do that. Certainly none of the free BSDs.
I'll take the bait. Care to show a reference to running a modern Linux kernel w/ 2 MB RAM, or 4 MB RAM with busybox, on i386 or ARM? Busybox can do wonders for storage requirements (e.g. for NAND FLASH), but it doesn't help with RAM at all! I found 8 MB to be difficult enough (!), last I tried ulibc and busybox on i386.
Just as a point of discussion, generic NetBSD is smaller than generic Linux (e.g. Debian) on the ARM platforms I've been using. A line from top shows the latest (NetBSD 5.1.2) kernel RAM footprint on ARM9: about 1.2 MB, with numerous filesystems, NFS, networking, USB support, etc. built in. This includes all kernel modules.
PID USERNAME PRI NICE SIZE RES STATE TIME WCPU CPU COMMAND
0 root 125 0 0K 1240K schedule 0:00 0.00% 0.00% [system]
Running 1 instance of httpd, sshd, and two user processes, minus 1.5 MB of buffers/cache, it's using 5.5 MB of RAM right now. Tightened up, it might boot in 4 MB but I haven't tried. Do note that this is with the standard (Net)BSD libc, all completely generic, 'out-of-the-box'.
Amazing work has been done to cram Linux into small places, but I think it's somewhat disingenuous to say that no BSD is close. I'd say NetBSD provides a rather interesting starting point.
Sure, you can. But UUIDs are the default behavior in many distributions (fortunately, 'blkid' will tell you the mapping between /dev entry and UUID). I'm not saying it's a bad system. My point is that the parent's complaint about naming conventions in /dev is silly -- there are generally good reasons for each system's behavior. The complaint distracts the discussion from what's actually important.
Coming from a user of both Linux and both FreeBSD and NetBSD, I can't agree with the absolutes of your post.
BSDs are never easier than Linux. Linux is more modern, while BSDs stick to "tradition" and take pride in keeping things complicated. Just read their manuals/handbooks and you will have a pretty good idea.
An alternate wording: "Linux engages in constant superfluous redesign, while BSDs stick to conventional but consistent, stable interfaces that are well documented". The fact that up-to-date man pages and well-written manuals/guides exist says a lot by itself. Linux's myriad of ever-obsolete HOW-TOs is a poor substitute.
One good example of a painful process in Linux that is easy in (Net)BSD is developing for embedded architectures. I can be typing away on, say, a (PPC) Mac or a (Intel) Linux or a (Sparc) BSD box, and can cross-compile a NetBSD distribution for an ARM single-board-computer with one line: ./build.sh -u -m evbarm release. I could replace 'evbarm' with 'alpha' or 'sparc64' or 'i386' or even 'vax' (!) and I would magically get a system built for these very different architectures, constructed from whatever system I want, all built from the very same code! I didn't have to rely on some vendor to package the cross-compiler or (very painfully) do it myself -- it's just a part of the basic NetBSD system. They got a lot of stuff right!
While I do agree -- "Desktop BSD" is still not where it should be for the traditional BSDs, Linux has a long way to go here too. However, PC-BSD has done a pretty good job of doing the basic grunt work that is otherwise sorely lacking. "PC-BSD is to FreeBSD, what Ubuntu is to Debian".
Your third partition on Linux will be /dev/sda3, but on BSD it will be /dev/ad0s3e (note that it numbers disks from 0 but slices from 1, and there is still the letter "e" for the partition inside the slice - isn't that simple?)
This is a red herring. (1) On my NetBSD system, the first disk is /dev/wd0a. That's not any different than Linux's /dev/sda0. (2) Who cares? Mac OS X shows my root file system as /dev/disk0s2, and you don't see everyone complaining that OS X isn't ready for the desktop! And sometimes the extra information can save your butt. Example: I have an old Sun workstation with 3 SCSI disks that has run Linux, BSD and Solaris at different points in its life. One of the more painful moments I experienced w/ this box was under Linux, when I removed a nonessential disk (mounted as /data) after removing its entry in /etc/fstab and unplugging it. I restarted the system -- and it would no longer boot -- because the /dev entries (/dev/sda, sdb, sdc, etc.) are enumerated in ad-hoc fashion, had reordered themselves, and the root drive was no longer where init thought it should be. In BSD and Solaris, the verbose naming corresponded to their physical locations on the SCSI bus, so you could pull a nonessential disk and it would still 'just work'. That prevented a ton of headaches.
These issues have been solved in Linux with unique UUID's, but now your entry for /dev/sda3 might instead say something like "UUID=1924d0d6-496d-4bbf-8fd1-aaaac6764bc5" in /etc/fstab. Good luck parsing the UUID to mean "3rd partition" unless your fstab file is well-commented! That makes BSD look positively friendly by comparison.
FreeBSD advocates spent a good portion of their time claiming that FreeBSD is faster than Linux. Maybe on servers under very heavy load. In all the tests I have made on a simple desktop, FreeBSD always felt a little bit slow, jerky, worse than Linux with a lightweight window manager such as LXDE (but not worse than Linux with KDE 4, for example).
While the average thermal velocity is lower than the escape velocity, the high velocity tail of the Maxwell-Boltzmann distribution is what's significant on long time scales.
It's important to state that room temperature isn't the most important number here. As you pointed out, the equilibrium point is high up in the atmosphere, where the gas is very dilute and can heat to a thousand degrees or more (solar UV heating and some contribution from solar wind). When you plug that temperature into the M-B thermal distribution, the fraction of atoms exceeding the escape velocity of Earth is much larger! In absolute terms, it's still a small number but enough to leak the helium out of the atmosphere over many millions of years.
Ultimately, it is the high thermal velocity that causes the loss of helium.
(They may change their design after watching the video...)
Indeed -- and I thought we had a hard landing on the test flight!
while i don't launch balloons - if that is the way you wanted to do it.. would it not make it easier and safer to secure it to a flatbed truck and drive it under the balloon then release then having a crane hold it??
The "crane" is needed to hold the payload still until the balloon ascends to pull the flight train and the gondola payload vertical. The tension in the flight train at balloon release pulls the payload horizontally, fairly hard. The flight train is typically 1000 feet long! While you could secure the payload to a truck, gondolas aren't generally designed to handle transverse loads at the load point. You really don't want them to, either; there's often (comparatively delicate) momentum transfer units at the load point that allow accurate pointing of telescopes once at float altitude (~125,000 feet, or ~35 km). And once you build a structure to take the pressure off the gondola load point, you're generally back to a crane design again.
You can see pictures and movies of our experiment's launch last year from Fort Sumner, NM. The StratoCat site has some additional details about this flight and many others, including ours.
Catastrophic launches like this are really rare -- the CSBF team really do a fantastic job. It's really had to tell exactly what happened here, though fairly high winds were a complicating factor. It's very lucky for everyone involved that no one got hurt.
Condolences to the science team, and best wishes that they can pick up the pieces and fly again...
I think you miss the point. Even a small 0.5-meter telescope in space is a SMEX-class NASA mission and costs well over 100 million bucks. If you can do some of the same science with a *comparably small* ground-based telescope, you win. By a lot.
Similarly, your 5-meter (or larger) telescope on the ground would be competing with SOFIA and Herschel and JWST for many applications. Those are all billion dollar class projects.
If you really want to compare a 10-meter telescope on the ground to a half-meter telescope in space, feel free... the costs start to get pretty similar. But the comparison in terms of scientific capability is not usually valid.
And by *usually*, I mean that there are some capabilities that can only be done in space. Ground facilities will never compete in those genres. But when you *can* do something from the ground, by all means you should do so.
BTW, these folks would be bemused by your comment that a half-meter telescope would be "uselessly small".
How about some balance?
- The cost of doing almost anything, anywhere in Antarctica is not far short of a space mission.
Nonsense. Sure, it's more expensive than putting a telescope on Kitt Peak, Mauna Kea, or Chile. But you're still orders of magnitude away from a space mission. A half-meter telescope on a "small explorer" (SMEX) NASA mission is over 105 million dollars, and that doesn't include the launch costs. Getting that 250 kg into space costs on the order of $20,000 USD per kg, still a fairly conservative estimate.
Based on the overland traverses that the Italians and French undertake to Dome C per year, getting to a site like Ridge A would be more like $10/kg (naturally assuming that you're making good use of the traverse and taking lots of stuff up there in one go).
So the costs aren't even in the same ball park.
- It's "daytime" for at least half the year.
And infrared and submillimeter astronomers can observe during the day. Incidentally, most of the big outstanding questions about the assembly of galaxies and star formation will be solved at these wavelengths -- which is where the Antarctic atmosphere is most advantageous.
- You can see barely half the sky - probably less.
You get the Southern sky only, true. But most of the Milky Way is in the South, and you can observe it without interruption -- 24/7. Time domain astronomy is something we've only scratched the surface of -- and there are major new projects devoted to it such as LSST. Antarctica could play a significant role here.
All things considered, Hawaii and Chile are far superior in most respects which matter.
As long as you ignore the poorer image quality, unstable atmosphere with large diurnal variations, comparatively soggy atmospheric water content, 100x higher infrared background -- yeah, Chile and Hawaii are far better. :)
Exactly right. It turns out that Ridge A is almost exactly the point where the katabatic winds originate.
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.
The article linked to showed the size comparison for the James Webb Space Telescope, and its spectral range vs. Hubble (further into IR, but also further into the visible spectrum)
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.
OK, found out that the tool is called crunchgen, [....]
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.
./build.sh -m evbarm kernel=MYKERNELCONFIG
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:
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.
We were NOT bored! Saved for posterity:
Hmmm. Actually... I guess we were bored...http://loke.as.arizona.edu/~ckulesa/superhuge/poster-halfsize.gif
and there was a BLT too:
http://daffy.as.arizona.edu/gradplays/play2k/blt.jpg
The summary is a bit misleading about the 60%.
FTA: "HST will be about 60% more powerful than it was right after the third servicing mission, before ACS and STIS failed."
The 1993 servicing mission generally restored the designed capabilities of the Hubble, the so-called "factor of 90" that the article mentions. Major new improvements and capabilities came with each servicing mission, culminating in the March 2002 servicing mission that installed the Advanced Camera for Surveys (ACS).
The upcoming installation of the new Wide Field Camera 3 (WFC3) and the Cosmic Origins Spectrograph (COS) will improve the combined sensitivity and field of view by 60% over the Hubble as it was after March 2002 (and before ACS died).
To be fair... by the same metric, modern ground-based telescopes with large format CCD and infrared arrays are on the order of 100 times more powerful than they were in 1990 as well. In the near infrared, the gains are closer to a factor of 1000!
It certainly is a bit of a misnomer, but the idea is to give researchers in both the Arctic and Antarctic two full summer/winter cycles to conduct their research under the blanket of the IPY. A single annual cycle is a bit restrictive for a lot of programs.
You can read more about the IPY here: http://www.ipy.org/
A lot of researchers are using the International Polar Year to springboard new projects that will begin, or continue, long past 2009. In fact, we hope to be one of those three groups launching an Antarctic balloon... in 2010. Our gondola will have a 0.8-meter far-infrared telescope that will try to understand how material in space cycles between stars and gas -- the "life cycle of interstellar matter". It's a part of our own story, since we are born from that material! (cue Carl Sagan here)
So a few IPY research programs won't be studying Polar regions specifically, but rather using them as unique platforms from which to study the Universe.
- 0.4 - 0.7 microns: visible light. A wavelength of 0.4 um is deep violet, 0.55 is yellow, and 0.7 is deep red.
- 0.7 - 5 microns: "near" infrared
- 5 - 50 microns: "mid" infrared
- 50 - 200 microns: "far" infrared
Note that CCD's respond to light that has a wavelength shorter than ~1.0 microns. At longer ("redder") wavelengths, there isn't sufficient photon energy to free an electron from the silicon substrate into a valence band and be collected/counted by the CCD readout electronics.Thus, the original poster is right that CCD's can "see IR", but it is only the very tip of the iceberg. Good enough for MIRT maybe, if the transmitters emit at least a little light shortward of ~1 micron.
Anyone know what wavelengths MIRT operates around? It is very unlikely to be mid or far infrared, since air itself (i.e. oxygen, water and nitrogen molecules) is pretty opaque at these wavelengths.