Slashdot Mirror
Wind River CEO Unexpectedly Resigns
The Finn writes "According to Electronics Weekly Wind River CEO Tom St. Dennis resigned today and left Wind River. For those who forgot, Wind River assumed stewardship of FreeBSD as part of the BSDi acquisition in May 2001, and subsequently Cut it loose in January 2002, and it still sells BSD /OS 5.0. I'll avoid the speculation of BSD dying, but Wind River may not be looking so good."
I was forcefull migrated off BSD/OS to FreeBSD a week ago. Perhaps things at Windriver aren't so great and the word is out?
When I worked at Applied Materials many years back, he ran the division I was working in. Although I never directly interacted with him, I found his management style well balanced and his speeches inspiring. Looking back, I would have no qualms about working under him again.
Good to know that I'm not the only person who had problems with WindRiver support from time to time.
One thing to keep in mind though (and many of my colleagues share this view) is that the actual RTOS is very good, but the other things aren't. Unfortunately (for the company I worked for), WindRiver bundled things in such a way that it was seen to be more convenient to use their built-in IP stack (for example) than buying a third-party one. Some developers spent months trying to debug WindRiver's routing stack, versus buying a working solution, since it "just made sense to be a complete WindRiver shop". Let's just say that management's decisions have almost driven the company out of business (parts of it are being acquired, what's left is expected to be around for no more than two months).
Yes, their BSP support is somewhat lacking, but, at least for us, they were one of the few companies that could get us a BSP that supported the Broadcom 3350 CPU (MIPS3K based).
When I talked to a QNX tech at the Embedded Systems Conference, he explained their support for the Broadcom 1250 (the core we were using at the time), it made WindRiver's RTOS seem absolutely laughable.
-- Joe
I was introduced to VxWorks when my previous employer asked me to port some drivers (ISA, PC-104 and PCI) for it. My overall impression was that it provided some nice libraries (multi-processes, semaphores, sockets, pipes, networking, as well as low-level IO) and was a piece of cake to get set up. It was Tornado, the IDE for VxWorks, that sucked. At best I was able to ignore it... at worst I actually had to use it.
I really don't know what the dev team was thinking when the released it. Its a total visual studio 6 rip off, but most of the useful features don't work, and the others are buggy or illogical at best. The debugger could never remember what radix to display data in, anytime a file was saved with the editor you lost your undo buffer, and every now and then it woud do strange things to the build rules (the makefiles were generated every time you built a module) that would generally screw everything up and leave you with an error message like 'not found' or 'error'.
So, I gave up using it and did my work in MSVC: it was far quicker to write custom build rules for VC than to fight with Tornado. When I left that job I spent an entire day writing a report on the bugs and strange things that Tornado would do.
The one thing that Tornado did do right was its remote connection. I was able to boot VxWorks off of a floppy on a test machine, and control it via Tornado's debugging terminal on my dev computer. It took some getting used to (the frame pointer wasn't always in thre right spot, and nested function calls could confuse things), but it worked well enough to finish the project on time.
"Dying tickles!" -- Ralph Wiggum