transputers again was: The dissolution of Commodore 2936

Its pretty common, and widely disliked both for WindRiver's licensing policies and reports of poor quality control in the kernel & drivers, and frequently nonexistent (or hideously expensive) support for bug fixes. Its not going to be much longer before embedded Linux eats WindRiver's lunch and dinner to a loud chorus of applause & cheering by users everywhere.

The big problem with Linux on spacecraft is the comparatively large memory footprint. OTOH, the ability to put the entire source tree of kernel, compilers and applications software into configuration management is a huge win- which is often not apparent until its a couple years after code is delivered and a subtle bug shows up. If source is available, then debugging is much faster and easier. I've seen this situation play out with vxWorks requiring programmers to disbuttemble the instruction stream with a logic analyzer to trace and patch to fix kernel bugs- with WindRiver offering no help at all because the target is "no longer supported".

Just last summer I went thru this very exercise with RTEMS- another open source RTOS. Problem was unexpected reset behavior on the spacecraft boards themselves. Since the OS & toolchain is open, I was able sequence the entire bootload & OS startup into pseudocode for the test engineers to check end against. Took a weekend of work with a laptop and no exotic setups. With the quick production of a test script, the test engineers took only a few days to find the bug- a time constant on the power bus and a boot loader fix provided the workaround. Heaven only knows how long it would have taken if we were using vxWorks. The spacecraft launched recently, very satisfying.

Greg