Slashdot Mirror
Wind River Completes Embedded Linux Metamorphosis
An anonymous reader writes "Embedded software powerhouse Wind River's metamorphosis into an embedded Linux vendor appears to be complete. The company will announce today that it is shipping a pre-release version of its first embedded Linux distribution, and that it has already delivered 1,000 "developer seats" for the Carrier Grade Linux 2.0 compliant software."
NASA uses VXWorks, it is one of thir best customers. They are very conservative, wont switch to linux.
The Market thinks they are turning it around.
Less geeky Stock Talk chat here.
They DID dig their heels in and raged against the Linux tide. I remember some of their public statements being fairly barbed too! I have to admit I had just switched from VxWorks to NetBSD so maybe I was paying attention a little more closely
Nothing in the world is more dangerous than sincere ignorance and conscientious stupidity.
Wind River DID NOT do the Mars Rover software. JPL did. JPL only used Vxworks as the OS. Any mature real time OS would have worked. JPL did the hard part.
http://www.fsmlabs.com/m /
s te ms/Realtime/Linux/
http://www.lynuxworks.co
http://dmoz.org/Computers/Software/Operating_Sy
More on Carrier Grade Linux Spec.
No, it's not. I used to think Linux would be all that and a bag of chips for embedded systems, but working with it dissuaded me of that fantasy.
It doesn't have a nanosecond clock, and there aren't any patches available for the 2.6 kernel.
There's no real-time support without patching the living hell out of your kernel, and then possibly running a mini-kernel underneath.
And, while not strictly relevant, it also doesn't have PPS API support built-in, which means you're also in for a wonderful round of patching to get something even remotely workable for synchronized systems. There's still no hardpps() support, so even that's just a maybe.
If you want something suitable for critical, real-time embedded systems, you'd have to patch the kernel so much that it'd barely look like Linux at the end.
-Erwos
Plausible conjecture should not be misrepresented as proof positive.
Couple points here that I think need to be made:
1. Historically, Wind River's success in the embedded market was based on the strength of its tool chain rather than the strength of its embedded OS. I suspect that the company's decision to broad the number of OS's that it is supporting is a reflection that the management team has figured this out.
2. As networking becoming more and more important, the requirement for a hard real-time operating systems decreases. You can't get deterministic performance out of a TCP/IP, which means that you can't get it out of a networked application. As a result, a number of designs are going in a different direction, combining a hard real-time hardware component coupled with an embedded Linux control/management plane...
That was the old regime. I worked at Wind River in 2002, when they were in dire straits, and met the then-CEO, Tom St. Denis, who was firmly anti-Linux--to the point that, if someone in a meeting mentioned Linux, he would just ignore you, as if you hadn't spoken. (Wasn't just me--other people told me the same thing happened to them.) A while after that, St Denis got fired (okay, "left the company to pursue other opportunities") and the new CEO (Ken Klein) is very pro-Linux. I was at a meeting in December where he spoke enthusiastically about open source, and reminded us that the company wants to maintain a "good neighbor policy" (i.e., let developers devote company time to open source projects.) I think this attitude is the single biggest difference between the struggling Wind River of 2002 and the stable Wind River of 2005.
People rag on M$FT architectures to no end, but WinCE does surprisingly well in real world tests, and Linux does surprisingly poorly:
Standard Linux doesn't do hard real-time, but it is good for parts of the system which don't require hard real-time. If you write a hard real-time system suitably, also, you can use large and valuable portions of Linux with it. The point is really that you can get a programmer familiar with Linux to do all the relatively easy parts of the embedded system, instead of taking up your real-time specialist's time or needing to train someone on special-purpose APIs.
There's also a substantial market for non-real-time embedded systems. Just last week, a SuSE engineer released support for a number of different touchscreens, useful for stores and restaurants. Obviously, you don't need real-time on a cash register, but you have very limited resources and unusual peripherals (e.g., a computer with two touchscreens, a magnetic card reader, a barcode scanner, a lock, a cash drawer, and a line printer; no keyboard or mouse). And you want a pretty simple program, and you want it to be easy to write, easy to customize, and easy to test.
They could have easily dug their heels in and raged against the Linux tide.
this is in fact what they did do. they used to be one of the most vocal anti-linux vendors around, next to microsoft.
Same here.
...
I joined a team working on functionality running on an embedded Linux distribution about a year ago. After doing major cleanup in the sources, including an upgrade to the newest release of the embedded distribution; I started looking under the hood.
Several portions of the distributions were replaced by busybox, uclibc and a gcc-3.4 based toolchain. In the process, we built our own Perl based build system (with CVS): we check in/out only the modified files (basically only platform files) and use the original tarballs (tar xkfj).
As a result, we were able to decrease the embedded compressed filesystem to less than 33%, our code is much closer to the upstream developments (e.g. for network drivers, this can be an issue) and our system is modular and flexible. (btw, size does matter in production and for field upgrades): smaller, faster and cleaner...
I am currently in the process of cleaning up the platform dependent files for release and inclusion into the upstream projects (hopefully they get accepted).
We moved away and have not looked back and saved over 25,000 Euros per year (and rising) in the process. Yes, the embedded distributions are terribly expensive. If you have money to spare, consider hiring teams from the companies selling expertise and releasing the code like http://www.denx.de/, http://www.codepoet.org/, http://www.pengutronix.de/, http://www.mind.be/,
Genius doesn't work on an assembly line basis. You can't simply say, "Today I will be brilliant."