Slashdot Mirror

I imagine you will see a similar stance by WindRiver maker of the popular Realtime Embedded OS VXWorks.

Actually from what I have seen, quite the opposite. WindRiver seem to be actively working on an embedded Linux Distribution and development environment of their own as an alternative to VXWorks. They seem to have strategically partnered themselves, with Redhat according to their webpage.

There is a really big difference between embedded processors and mainstream CPUs.

The biggest is that power consumption is really important in the embedded world. Sometimes you can only get so much current to a board, or you can't run fans.

Typically, embedded processors can run without support chips. Many have built in memory controllers and I/O.

Another thing is the MMU. A lot of embedded processors have MMUs (I think most of the PPC ones do), but OS support for them is a bit lacking (or it was until recently). But at times, the MMU can get in the way

IMHO, I would never run linux in an embedded product, other than simple internet appliances or where realtime isn't required. Commerical RTOSs like VxWorks really are worth it for most embedded applications.

I hope they run FreeBSD in lieu of Windows NT. We've only had about four stalled destroyers due to that operating system. They'll probably end up running something like QNX or VxWorks, though, which are realtime operating systems. Still much better choices than Windows NT/2K/XP.

I have been running FreeBSD since the 3.x days. Right around this time Linux became popular but I stuck with FreeBSD for several academic reasons. At that point one was as good as the other, but as time went on this changed. Linux started gathering a huge following and it really hit its stride. The developers made leaps in bounds in hardware support. Meanwhile, FreeBSD crawled from 3.x to 4.x, which was a great improvement to be sure, but not as rapid or large as what Linux had been offering.

Being locked into FreeBSD by familiarity and investment at that point I wistfully watched the GNU community race ahead. I wish something would start a similar firestorm of FreeBSD development. I thought nothing of it when Apple bought NeXT in 1996. The Rhapsody project, which was basically just adding some Apple technology to OpenStep, didn't interest me. When Steve Jobs announced Mac OS X in 1999, however, my ears perked up at the mention of my favorite Unix. Apple was going to update the very cores of OpenStep into something new FreeBSD was going to be a huge part of that.

Since Mac OS X v10.0 was released in 2001, Apple has been filtering BSD code in and out of their kernel, userland, and libraries. This code then makes its way back to FreeBSD. Apple's pattern is to sync every major Mac OS X release with the latest major FreeBSD release. For example, Mac OS X v10.1 corresponded to FreeBSD 4.4 and Mac OS X v10.2 matched up with FreeBSD 4.7. By the time Apple released Panther, their contributions back into FreeBSD had amassed into a new FreeBSD milestone, the 5.x branch. Mac OS X v10.3 contained bits of both FreeBSD 4.9 and FreeBSD 5.1.

Look at it this way, only after Apple started modifying FreeBSD 4.x and submitting their modifications did FreeBSD progress to the 5.x branch. The advanced VM and SMP code that allows Mac OS X to run so efficiently is the very same code that finally put FreeBSD on the level with Linux. I run FreeBSD 5.2 on a four-way Xeon box at work and thank Apple every day. If it weren't for the Mach micokernel from Apple we wouldn't be able to do these nice things with FreeBSD now or probably ever.

It's also kind of ironic how such a big deal was made by Wind River Systems buying out both BSDI and Walnut Creek Software. (Does anyone remember this?) The plan was to merge BSD/OS into FreeBSD and sell a special enterprise edition of the operating system while still maintaining the Open Source project. Sadly this fizzled out. No one ever predicted that Apple, of all companies, would ride in with the cavalry and pick up the pieces. Apple has done much more than Wind River ever managed to.

After such a long and precarious history FreeBSD is finally going somewhere and we no longer have to worry about the latest hardware support of when the next release will be. We're firing on all cylinders now, and within a couple more years there will be more FreeBSD installs than Linux or Solaris! I'm not so proud that I can't see what is behind this. Apple saved FreeBSD and I have no problem admitting or accepting that. I doubt many others who use FreeBSD do, but I just wanted to point it out.

Thank you, Apple, for saving FreeBSD.

Thursday, February 26, 2004

I have been running FreeBSD since the 3.x days. Right around this time Linux became popular but I stuck with FreeBSD for several academic reasons. At that point one was as good as the other, but as time went on this changed. Linux started gathering a huge following and it really hit its stride. The developers made leaps in bounds in hardware support. Meanwhile, FreeBSD crawled from 3.x to 4.x, which was a great improvement to be sure, but not as rapid or large as what Linux had been offering.

Being locked into FreeBSD by familiarity and investment at that point I wistfully watched the GNU community race ahead. I wish something would start a similar firestorm of FreeBSD development. I thought nothing of it when Apple bought NeXT in 1996. The Rhapsody project, which was basically just adding some Apple technology to OpenStep, didn't interest me. When Steve Jobs announced Mac OS X in 1999, however, my ears perked up at the mention of my favorite Unix. Apple was going to update the very cores of OpenStep into something new FreeBSD was going to be a huge part of that.

Since Mac OS X v10.0 was released in 2001, Apple has been filtering BSD code in and out of their kernel, userland, and libraries. This code then makes its way back to FreeBSD. Apple's pattern is to sync every major Mac OS X release with the latest major FreeBSD release. For example, Mac OS X v10.1 corresponded to FreeBSD 4.4 and Mac OS X v10.2 matched up with FreeBSD 4.7. By the time Apple released Panther, their contributions back into FreeBSD had amassed into a new FreeBSD milestone, the 5.x branch. Mac OS X v10.3 contained bits of both FreeBSD 4.9 and FreeBSD 5.1.

Look at it this way, only after Apple started modifying FreeBSD 4.x and submitting their modifications did FreeBSD progress to the 5.x branch. The advanced VM and SMP code that allows Mac OS X to run so efficiently is the very same code that finally put FreeBSD on the level with Linux. I run FreeBSD 5.2 on a four-way Xeon box at work and thank Apple every day. If it weren't for the Mach micokernel from Apple we wouldn't be able to do these nice things with FreeBSD now or probably ever.

It's also kind of ironic how such a big deal was made by Wind River Systems buying out both BSDI and Walnut Creek Software. (Does anyone remember this?) The plan was to merge BSD/OS into FreeBSD and sell a special enterprise edition of the operating system while still maintaining the Open Source project. Sadly this fizzled out. No one ever predicted that Apple, of all companies, would ride in with the cavalry and pick up the pieces. Apple has done much more than Wind River ever managed to.

After such a long and precarious history FreeBSD is finally going somewhere and we no longer have to worry about the latest hardware support of when the next release will be. We're firing on all cylinders now, and within a couple more years there will be more FreeBSD installs than Linux or Solaris! I'm not so proud that I can't see what is behind this. Apple saved FreeBSD and I have no problem admitting or accepting that. I doubt many others who use FreeBSD do, but I just wanted to point it out.

Thank you, Apple, for saving FreeBSD.

I have been running FreeBSD since the 3.x days. Right around this time Linux became popular but I stuck with FreeBSD for several academic reasons. At that point one was as good as the other, but as time went on this changed. Linux started gathering a huge following and it really hit its stride. The developers made leaps in bounds in hardware support. Meanwhile, FreeBSD crawled from 3.x to 4.x, which was a great improvement to be sure, but not as rapid or large as what Linux had been offering.

Being locked into FreeBSD by familiarity and investment at that point I wistfully watched the GNU community race ahead. I wish something would start a similar firestorm of FreeBSD development. I thought nothing of it when Apple bought NeXT in 1996. The Rhapsody project, which was basically just adding some Apple technology to OpenStep, didn't interest me. When Steve Jobs announced Mac OS X in 1999, however, my ears perked up at the mention of my favorite Unix. Apple was going to update the very cores of OpenStep into something new FreeBSD was going to be a huge part of that.

Since Mac OS X v10.0 was released in 2001, Apple has been filtering BSD code in and out of their kernel, userland, and libraries. This code then makes its way back to FreeBSD. Apple's pattern is to sync every major Mac OS X release with the latest major FreeBSD release. For example, Mac OS X v10.1 corresponded to FreeBSD 4.4 and Mac OS X v10.2 matched up with FreeBSD 4.7. By the time Apple released Panther, their contributions back into FreeBSD had amassed into a new FreeBSD milestone, the 5.x branch. Mac OS X v10.3 contained bits of both FreeBSD 4.9 and FreeBSD 5.1.

Look at it this way, only after Apple started modifying FreeBSD 4.x and submitting their modifications did FreeBSD progress to the 5.x branch. The advanced VM and SMP code that allows Mac OS X to run so efficiently is the very same code that finally put FreeBSD on the level with Linux. I run FreeBSD 5.2 on a four-way Xeon box at work and thank Apple every day. If it weren't for the Mach micokernel from Apple we wouldn't be able to do these nice things with FreeBSD now or probably ever.

It's also kind of ironic how such a big deal was made by Wind River Systems buying out both BSDI and Walnut Creek Software. (Does anyone remember this?) The plan was to merge BSD/OS into FreeBSD and sell a special enterprise edition of the operating system while still maintaining the Open Source project. Sadly this fizzled out. No one ever predicted that Apple, of all companies, would ride in with the cavalry and pick up the pieces. Apple has done much more than Wind River ever managed to.

After such a long and precarious history FreeBSD is finally going somewhere and we no longer have to worry about the latest hardware support of when the next release will be. We're firing on all cylinders now, and within a couple more years there will be more FreeBSD installs than Linux or Solaris! I'm not so proud that I can't see what is behind this. Apple saved FreeBSD and I have no problem admitting or accepting that. I doubt many others who use FreeBSD do, but I just wanted to point it out.

Thank you, Apple, for saving FreeBSD.

I have been running FreeBSD since the 3.x days. Right around this time Linux became popular but I stuck with FreeBSD for several academic reasons. At that point one was as good as the other, but as time went on this changed. Linux started gathering a huge following and it really hit its stride. The developers made leaps in bounds in hardware support. Meanwhile, FreeBSD crawled from 3.x to 4.x, which was a great improvement to be sure, but not as rapid or large as what Linux had been offering.

Being locked into FreeBSD by familiarity and investment at that point I wistfully watched the GNU community race ahead. I wish something would start a similar firestorm of FreeBSD development. I thought nothing of it when Apple bought NeXT in 1996. The Rhapsody project, which was basically just adding some Apple technology to OpenStep, didn't interest me. When Steve Jobs announced Mac OS X in 1999, however, my ears perked up at the mention of my favorite Unix. Apple was going to update the very cores of OpenStep into something new FreeBSD was going to be a huge part of that.

Since Mac OS X v10.0 was released in 2001, Apple has been filtering BSD code in and out of their kernel, userland, and libraries. This code then makes its way back to FreeBSD. Apple's pattern is to sync every major Mac OS X release with the latest major FreeBSD release. For example, Mac OS X v10.1 corresponded to FreeBSD 4.4 and Mac OS X v10.2 matched up with FreeBSD 4.7. By the time Apple released Panther, their contributions back into FreeBSD had amassed into a new FreeBSD milestone, the 5.x branch. Mac OS X v10.3 contained bits of both FreeBSD 4.9 and FreeBSD 5.1.

Look at it this way, only after Apple started modifying FreeBSD 4.x and submitting their modifications did FreeBSD progress to the 5.x branch. The advanced VM and SMP code that allows Mac OS X to run so efficiently is the very same code that finally put FreeBSD on the level with Linux. I run FreeBSD 5.2 on a four-way Xeon box at work and thank Apple every day. If it weren't for the Mach micokernel from Apple we wouldn't be able to do these nice things with FreeBSD now or probably ever.

It's also kind of ironic how such a big deal was made by Wind River Systems buying out both BSDI and Walnut Creek Software. (Does anyone remember this?) The plan was to merge BSD/OS into FreeBSD and sell a special enterprise edition of the operating system while still maintaining the Open Source project. Sadly this fizzled out. No one ever predicted that Apple, of all companies, would ride in with the cavalry and pick up the pieces. Apple has done much more than Wind River ever managed to.

After such a long and precarious history FreeBSD is finally going somewhere and we no longer have to worry about the latest hardware support of when the next release will be. We're firing on all cylinders now, and within a couple more years there will be more FreeBSD installs than Linux or Solaris! I'm not so proud that I can't see what is behind this. Apple saved FreeBSD and I have no problem admitting or accepting that. I doubt many others who use FreeBSD do, but I just wanted to point it out.

Thank you, Apple, for saving FreeBSD.

I have been running FreeBSD since the 3.x days. Right around this time Linux became popular but I stuck with FreeBSD for several academic reasons. At that point one was as good as the other, but as time went on this changed. Linux started gathering a huge following and it really hit its stride. The developers made leaps in bounds in hardware support. Meanwhile, FreeBSD crawled from 3.x to 4.x, which was a great improvement to be sure, but not as rapid or large as what Linux had been offering.

Being locked into FreeBSD by familiarity and investment at that point I wistfully watched the GNU community race ahead. I wish something would start a similar firestorm of FreeBSD development. I thought nothing of it when Apple bought NeXT in 1996. The Rhapsody project, which was basically just adding some Apple technology to OpenStep, didn't interest me. When Steve Jobs announced Mac OS X in 1999, however, my ears perked up at the mention of my favorite Unix. Apple was going to update the very cores of OpenStep into something new FreeBSD was going to be a huge part of that.

Since Mac OS X v10.0 was released in 2001, Apple has been filtering BSD code in and out of their kernel, userland, and libraries. This code then makes its way back to FreeBSD. Apple's pattern is to sync every major Mac OS X release with the latest major FreeBSD release. For example, Mac OS X v10.1 corresponded to FreeBSD 4.4 and Mac OS X v10.2 matched up with FreeBSD 4.7. By the time Apple released Panther, their contributions back into FreeBSD had amassed into a new FreeBSD milestone, the 5.x branch. Mac OS X v10.3 contained bits of both FreeBSD 4.9 and FreeBSD 5.1.

Look at it this way, only after Apple started modifying FreeBSD 4.x and submitting their modifications did FreeBSD progress to the 5.x branch. The advanced VM and SMP code that allows Mac OS X to run so efficiently is the very same code that finally put FreeBSD on the level with Linux. I run FreeBSD 5.2 on a four-way Xeon box at work and thank Apple every day. If it weren't for the Mach micokernel from Apple we wouldn't be able to do these nice things with FreeBSD now or probably ever.

It's also kind of ironic how such a big deal was made by Wind River Systems buying out both BSDI and Walnut Creek Software. (Does anyone remember this?) The plan was to merge BSD/OS into FreeBSD and sell a special enterprise edition of the operating system while still maintaining the Open Source project. Sadly this fizzled out. No one ever predicted that Apple, of all companies, would ride in with the cavalry and pick up the pieces. Apple has done much more than Wind River ever managed to.

After such a long and precarious history FreeBSD is finally going somewhere and we no longer have to worry about the latest hardware support of when the next release will be. We're firing on all pistons now, and within a couple more years there will be more FreeBSD installs than Linux or Solaris! I'm not so proud that I can't see what is behind this. Apple saved FreeBSD and I have no problem admitting or accepting that. I doubt many others who use FreeBSD do, but I just wanted to point it out.

Thank you, Apple, for saving FreeBSD.

Wind is doing more than thinking about Eclipse. One of their three major announcements today was for a new Eclipse-based IDE, named WindPower IDE 2. And it supports both Linux and VxWorks, so you're right. VxWorks 6.0 (with process-level memory protection, among other things) was also announced.

Wind is doing more than thinking about Eclipse. One of their three major announcements today was for a new Eclipse-based IDE, named WindPower IDE 2. And it supports both Linux and VxWorks, so you're right. VxWorks 6.0 (with process-level memory protection, among other things) was also announced.

Indeed, Wind River had bought BSDi, which had earlier bought Walnut Creek and acquired close ties with FreeBSD; thus quite a few FreeBSD developers ended up working with Wind River. But the honeymoon didn't last long... I have no idea what went wrong. But even now they claim ownership of the BSD, BSD/OS and FreeBSD trademarks... There has been a long-term plan for the FreeBSD Foundation to get control of the trademark, but I don't know where that's at.

Microsoft
Founded: 1975, Albuquerque, New Mexico
Incorporated: June 25, 1981
IPO: March 13, 1986

Wind River Systems (2)
Founded: 1981
Incorporated: 1983, California
IPO: April 15, 1993

Microsoft
Founded: 1975, Albuquerque, New Mexico
Incorporated: June 25, 1981
IPO: March 13, 1986

Wind River Systems (2)
Founded: 1981
Incorporated: 1983, California
IPO: April 15, 1993

The issue here is whether the x86 platform's issues, like excessive heat and power consumption and the requirement for a separate memory controller, outweigh its advantages, like the large variety of hardware already available to interface to everything under the sun and the fact that it's a well-understood architecture.

Now that's out of the way, here's my two cents: the x86 architecture, or at least the implementations currently available, simply isn't cut out for most embedded applications. While x86's limitations have been addressed with lots of extensions (MMX, SSE, 3dNow, etc.), those end up adding complexity and drawing more power than a chip designed without those limitations. Also, the x86's pitiful lack of registers compared to architectures like the PowerPC (another choice for embedded applications that require a good deal of power) means that almost any complex operations mean lots of going in and out of cache, or, worse, main memory. While x86 is acceptable in an environment with a 300W+ power supply and user tolerance for a good deal of noise, it won't cut it in your VCR. x86 might see some use in applications which require rapid development and lots of power, but in most cases there is already a good solution available.

Before making such a bold statement, name two companies that have succeeded selling an operating system.

Microsoft
Wind River
TRON - article on ITRON

That's three.. what were you saying now?

The rovers run vxWorks, a commercial OS, as reported on Slashdot two weeks ago.

Check out VxWorks from Wind River.

They're using RAD6000 processors which are modified chips used to run old Macs from the early nineties. Each rover has 384 megabytes of RAM, the extra 256 is for images.
The operating system is VxWorks.

Apparently, they run VxWorks

They run on Vxworks, a real-time operating system (RTOS) which has been used by NASA for several years now. You have to remember that these aren't run of the mill systems, but ones that need military grade radiation hardened components, and it's amazing what can be done even with a simple embedded system (I wrote a minimal TCP/IP stack and ethernet driver for an 8-bit processor once, the 8052, and while complex). It's mostly technology that has proven to be reliable time and time again, but not all codepaths can be explored even in a simple system. The problem with spirit was apparently in the flash filesystem implementation (sounded like they ran out of inodes, but I haven't seen a detailed analysis).

History has a way of teaching us lessons. However, all too often people ignore the early warning signs of a troubling trend, and in many cases take corrective action only after problems occur repeatedly, with serious consequences. The world of digital electronics is not immune to this phenomenon.

History has a way of teaching us lessons. However, all too often people ignore the early warning signs of a troubling trend, and in many cases take corrective action only after problems occur repeatedly, with serious consequences. The world of digital electronics is not immune to this phenomenon.

One thing's for sure. The won't be any software flame wars over which crappy OS is running the Mars show. Hint: it's from neither Washington (state) nor Finland.

Wind River its a real time embedded OS its actually used on a surprisely many things..

their site is http://www.windriver.com/

Maybe Wind River will not be so quick to brag now :)

You might want to check your facts before you spew. While the ground system is heavy on Linux according to the article you referenced, the actual OS on the rover itself is VxWorks from Wind River.
http://www.windriver.com/news/press/20040105.html

ReplayTV does not run on linux. It runs on an OS called VxWorks. See this review from PC World from a while back or here.

Sorry, but ReplayTV uses VxWorks 5.4.2 from WindRiver Systems.

Sorry, but ReplayTV uses VxWorks 5.4.2 from WindRiver Systems.

• But a few days into the mission, not long after Pathfinder started gathering meteorological data, the spacecraft began experiencing total system resets, each resulting in losses of data.

Pathfinder in it's 1997 landing (04JUL1997) suffered a series of unexplained system failures. David Wilner CTO of WindRiver Systems, the creators of WxWorks the realtime embedded system kernel talked to IEEE Real-Time Systems Symposium at a later date explaining how they solved software bugs in the system.

• leaving the "debugging" facilities in the system saved the day

this article explains how they solved the problem - by including the debug code with the os. I remember reading about this on /. some time ago. A detailed account can be read here by Glenn Reeves (JPL Mars Flight SE).

Windriver systems is supplying the OS for the current mission. Lets see how long it takes them to work this one out :)

links:
www.kohala.com/start/papers.others/pathfinder.html
research.microsoft.com/~mbj/Mars_Pathfinder/Author itative_Account.html

• But a few days into the mission, not long after Pathfinder started gathering meteorological data, the spacecraft began experiencing total system resets, each resulting in losses of data.

Pathfinder in it's 1997 landing (04JUL1997) suffered a series of unexplained system failures. David Wilner CTO of WindRiver Systems, the creators of WxWorks the realtime embedded system kernel talked to IEEE Real-Time Systems Symposium at a later date explaining how they solved software bugs in the system.

• leaving the "debugging" facilities in the system saved the day

this article explains how they solved the problem - by including the debug code with the os. I remember reading about this on /. some time ago. A detailed account can be read here by Glenn Reeves (JPL Mars Flight SE).

Windriver systems is supplying the OS for the current mission. Lets see how long it takes them to work this one out :)

links:
www.kohala.com/start/papers.others/pathfinder.html
research.microsoft.com/~mbj/Mars_Pathfinder/Author itative_Account.html

The OS on the Spirit lander was created by Wind River - details are here. As with any OS designed for deep-space uses there are multiple redundancies on virtually every aspect of the system.

The images will never be perfect. The page you reference on the space.com article was not the exact image stored on the rover. When the images are transmitted from the Rover back to JPL, there is a transmission loss in the retro-bias diagonal frequency bass carrier that causes the image to be distorted. The fuzzy look we receive is then dithered and poly-metrophased with the dark "shadows" you see. This brings the image back to what we could theoretically predict it would be if the image was proper.

Somewhat offtopic, though much software ON THE GROUND at the Jet Propulsion Laboratory is written in Java, but not software on the spacecraft. This doesn't have any problem, but due to Java's slow execution rate on the Rover's computer we actualy lose tetra-physical carbonic exposure rate because the camera simply can't be operated as quickly in Java as if the comman protocol were operated through a more iffecient lower-level language such as C.

Needless to say, I wrote some of the software used for the mission in Java, and it worked very well for our purposes, namely due to platform independence and quick development time. We had a heck of a time with some of the GUI code, however.

The rover runs VxWorks from Wind River. Very solid. Cheers,

Jim Cobgrobbler
Science Activation Planning Developer
Mars Exploration Rovers

Is it true that spirit makes use of Java? Or does only the "client" software used to control it,use Java.

Much software ON THE GROUND at the Jet Propulsion Laboratory is written in Java, but not software on the spacecraft.

I wrote some of the software used for the mission in Java, and it worked very well for our purposes, namely due to platform independence and quick development time. We had a heck of a time with some of the GUI code, however.

The rover runs VxWorks from Wind River. Very solid. Cheers,
Justin Wick
Science Activity Planner Developer
Mars Exploration Rovers

Is it true that spirit makes use of Java? Or does only the "client" software used to control it,use Java.

Much software ON THE GROUND at the Jet Propulsion Laboratory is written in Java, but not software on the spacecraft.

I wrote some of the software used for the mission in Java, and it worked very well for our purposes, namely due to platform independence and quick development time. We had a heck of a time with some of the GUI code, however.

The rover runs VxWorks from Wind River. Very solid. Cheers,
Justin Wick
Science Activity Planner Developer
Mars Exploration Rovers

Anybody know what OS the rover uses?

MER2004 Mars Rovers use an OS by Wind River. Read about it at that link (press release).

--
For news, status, updates, scientific info, images, video, and more, check out:
(AXCH) 2004 Mars Exploration Rovers - News, Status, Technical Info, History.

Sorry, thanks for the correction.

The systems I was thinking of were using WindRiver VxWorks and GreenHill Systems AdaMulti. The comments about support apply more-or-less to both.

Please remember: RT means NOT to be fast, but to guarantee certain worst-case-latencies under all circumstances, load and IRQ-storms.
If you look for an open-source RT-system, here you go:

1) my favourite, eCos from RedHat/ex-Cygnus.
It has a very, very sophisticated configuration tool (almost everything(!) you don't need is rippable from the kernel), has even a Linux-Compatibility-Module and so on

2) RTEMS is also free, configurable and so on. IIRC it was used to steer the cruise-missles. The configuration is a bit more complicated.

3) number three ... i forgot about it just this moment, sorry

If you want to pay, there is always:
QNX and VxWorks.

There are probably other OS's that they would be more willing to use for this as well - more known reliable ones for embedded applications, like VxWorks (which I've heard but not confirmed that the government uses for these sorts of things).

SCO bills NASA! (suspects Linux installed on Mars Rover)

The Mars Rovers run VxWorks, though there is heavy use of Linux elsewhere at NASA. There have been a couple of very preliminary studies of the possible use of real-time Java on Linux for future rovers and other spacecraft.

What to buy...what to buy...hmmm...hmmm...just can't decide how much I'd like to spend! I need to get my hands on a copy of BSD to host my site! Stat!

I wonder how this will affect Sidewinder. It's tightly integrated around BSD/OS for it's type-enforcement technology. They're even quoted in a Wind River press release from last year. I guess people should just migrate to FreeBSD and be done with it. It's not going anywhere.

Perhaps the most well-known machine to run VxWorks was the Pathfinder probe.

Prices for support from BSDI: here.

A real time operating system is of great use in robotics.

I am actively working toward the completion of several autonomous systems.

RTEMS (by OAR) is available as well as RTLinux (by FSMLabs) for those interested in developing robotics software using GPL. Big boys buy vxWorks or something from WindRiver (Asimo by Honda).

They still sell BSD/OS, a commercial version of FreeBSD, which they got from BSDi.

It is probrably 1% of their business, so - as you said - troubles at Wind River, if any, do not reflect on FreeBSD.

I thought it was common knowledge that Airports ran Wind River's BSD distribution for embedded systems.

I'm looking at a 500k kernel (compressed) and a crunchgen'd set of binaries taht fit onto an 8MB flash with networking, a shell and far too many other things to really be considered embedded (stuff I need for other reasons). With trimming, I'm sure we could get it down to 4MB for truly embedded use.

Of course, these guys do embedded systems and own a respectable BSD when they bought BSDI. Of course, we can't figure out why they bought BSDi since their first year appeared to focus on pissing off existing customers when FreeBSD, NetBSD and OpenBSD were as good as or better than BSDi in many respects. At least if I want mediocre support, I can get it for free :)

And there are other folks in the free world doing embedded work too.

The bonus is that we don't have to put up with RMS yammering all the time. I watched and waited for HURD forever and just presumed that Emacs would get boot code. He can call that GNU/HURD all he wants. I still wish Linus has made the arbitrary choice of using the BSD-lite userland utils instead. At least the CSRG aren't as strident.

BSDI is dead, dude.

:-)

There are a very few CA systems. Moto have their own, nearly every one else uses one of two other vendors. This is the Smart Card stuff. It's 'standard', but they are very paranoid about revealing how it works, as if it is broken it costs tens of millions of $ to fix.

The other bit is middleware. Rather than write for every processor in every model of every STB, most manufacturers now use one of two or three middleware systems. At least one of these is Java based, but most are not (although they will run Java). MS tried to own this space with WinCE but so far has been laughed at.

So, what you want is what is already in place, but the target system isn't quite what you expect maybe. BTW, the OS on most of these STBs is VxWorks from Wind River.