Intel Buys Embedded Software Vendor Wind River

SlashDotDotDot writes "The New York Times reports that Intel will purchase Wind River, the embedded OS and software vendor, for $884 million. 'Wind River makes operating systems for platforms as diverse as autos and mobile phones, serving customers like Sony and Boeing. Intel, whose processors run about 80 percent of the world's personal computers, is expanding into new markets, including chips for televisions and mobile devices. Wind River's software and customer list will pave the way for Intel to win more chip contracts.'"

Comments

Yuck

[Red Flayer]

Uh-oh...

I'm not a big fan of one of the largest chipmakers venturing into embedded systems. Given Intel's track record, something tells me that things are going to get fugly for companies that sell embedded systems as a component of larger products.

I sure hope someone will be playing close attention to Intel's pricing... if they use Wind River's systems as a loss leader for their chips, that would suck for a competitive chip market.

Re:Yuck

[korbin_dallas]

Why? Just ignore them.
Hear that? Its the Wind River guys LAUGHING all the way to the bank!

Embedded devices use Arm chips, the design is open. The toolkits are free. Only idiotic, big organizations like Boeing use Wind River stuff. I have talked to people who are going to linux just to ditch Wind River and VxWorks.

How does Intel plan to compete against $6 Arm chips? A smart meter has no need for a 64bit, fat, power hungry, hot 3Ghz pc type chip with no peripherals builtin.

Methinks they just wasted a lot of cash.

Re:Yuck

[phantomfive]

I'm not sure that it's all that great of a move. Wind River generally targets projects with small chips (mainly ARM, these days) for embedded projects. Intel doesn't actually make chips like that, the smallest they have is ATOM, which is still pretty hefty. If you're running an ATOM chip, why not use linux embedded or WinCE? It's a lot easier to use and find developers for.

In my mind this either signals that Intel is going to try to make smaller chips (and probably fail, since x86 is a beast), or have a nonexistent target market, but they should have realized this. The only thing I can think of really is that Intel realized that they have no clue what kind of chips embedded software developers need, and they thought the easiest way to get that expertise would be to buy an embedded software company.

Maybe there's another motive, but I can't see it. And given the number of weird ideas I've seen from analysts, I don't think many other people understand either.

Maybe the CEO of Intel has a brother in law at Wind River who needs some financial help? Who knows.

Re:Yuck

[Amazing Quantum Man]

Those of us who have hard real-time requirements need something like VxWorks. Or if you have ARINC 653 requirements, etc....

Re:Yuck

[jd]

VxWorks is not a bad embedded OS. In fact, I'd call it quite good. Not great, but definitely good. There's very very little support out there for such architectures as VME, and VME is definitely an important architecture. There's next-to-no support in any of the F/L/OSS BSDs or Linux for this important bus, for example.

Wind River has also contributed a fair bit to Linux and the *BSDs over time, a fact we shouldn't forget. Will Intel keep up that investment? Intel already invests a fair bit into Linux, but I just don't see them increasing that to cover the loss of investment from Wind River.

Could Intel be aiming at the OS market? They no longer get the kind of support from Microsoft that they once enjoyed. I don't think so - embedded OS' just don't sell in the kind of numbers you'd need.

Then what is it that Wind River has that Intel wants? Hmmm. I don't know, but I'm going to guess that it's more of a defensive move than an offensive one. Microsoft has been buying up biotech software companies, recently. Biotech companies use embedded OS'.

Re:Yuck

[jonbryce]

I thought WinCE ran on ARM? You would need NT Embedded if you want a MS Operating System for Atom.

Re:Yuck

[Anonymous Coward]

Those of us who have hard real-time requirements need something like VxWorks. Or if you have ARINC 653 requirements, etc....

That is what OSs like Green Hills or Precise are for. VxWorks is a total waste. Last time I touched VxWorks (2004) they still weren't even using the MMU on the processor and forced you to run your apps with process separation.

Re:Yuck

[nxtw]

I thought WinCE ran on ARM? You would need NT Embedded if you want a MS Operating System for Atom.

No, and a quick visit to Wikipedia would have cleared things up for you. Windows CE targets x86 as well.

Re:Yuck

[Chris Burke]

How does Intel plan to compete against $6 Arm chips? A smart meter has no need for a 64bit, fat, power hungry, hot 3Ghz pc type chip with no peripherals builtin.

The tie-in to Intel hardware would obviously be through Atom. Though at ~2W, it's not positioned to take over the majority of segments Wind River went into I don't think (if Atom was an atom, most embedded processors/microcontrollers would be electrons or quarks). However it may get embedded customers used to dealing with Intel, could easily get them some significant Atom design wins, and overall help pave the way for future Intel incursions into the embedded space.

Why they want to expand into such a low-margin market I'm not exactly sure, but I won't question their wisdom. I'm assuming they've run numbers that make it look like a good use of fab space. Not like that always has worked out for them (to put it mildly) and I doubt they can push out Arm by any means, but it could still work out profitably for them in the end.

Re:Yuck

[Tycho]

In my mind this either signals that Intel is going to try to make smaller chips (and probably fail, since x86 is a beast), or have a nonexistent target market, but they should have realized this. The only thing I can think of really is that Intel realized that they have no clue what kind of chips embedded software developers need, and they thought the easiest way to get that expertise would be to buy an embedded software company.

Intel could also try to dictate to embedded customers what Intel wants the customers to want. Hey it worked for Intel in the PC market, but seems to be failing in the HPC market with both the Xeon and Itanic. Since neither governments nor the market seems to have contained Intel, lets allow Intel to make Pentium 4 and Rambus sized mistakes in the embedded and HPC markets, then let the government(most likely) or the market(doubtful) tear them to pieces. An open source replacement for VxWorks might show up. Also, without access to many of the patented ruggedization and hardening techniques other manufacturers have that might be unavailable to Intel, maybe VwWon'tWork for Intel.

Re:Yuck

[LordNimon]

If Intel just wanted better VxWorks support for their chips, they could have done that for a lot less than $900 million, and they wouldn't need to buy the whole company. For less than a million per year, they could have had a few of their own employees work on-site at Wind River exclusively on improving VxWorks support for Intel products.

Re:Yuck

[Anonymous Coward]

Intel make chips other than x86, for example PXA.

Re:Yuck

[jd]

Exactly. On the other hand, if Microsoft is buying up companies that are involved in the Embedded market, then Microsoft would have to pay Intel whatever Intel asked in order to get Windows to interoperate better with such system (or replace the OS entirely).

This would give Intel some small degree of leverage that it simply wouldn't have otherwise, and would prevent Microsoft from buying those embedded OS makers themselves (which would give Microsoft even more power over Intel - something I doubt Intel desires).

This is why I can see a defensive reason for Intel wanting Wind River, but no offensive reason. I can see nothing Wind River can give Intel that Intel couldn't have obtained for less, as you note, OTHER than protection from the consequences of Microsoft owning Wind River.

Re:Yuck

[Darinbob]

Just wondering if Wind River's support for PowerPC or ARM chips will start to degrade...

If Intel wants into the embedded market, as a hardware vendor they should provide hardware rather than purchasing a predominantly software oriented company. Or am I too much of an old-school guy to assume that companies should stick to their main competency rather than trying to do everything?

WindRiver itself has some problems (Ie, try to sell diab in a gcc world), but at least they're sticking to their expertise of mid-range embedded systems.

Re:Yuck

[Darinbob]

They seem to have MMU support now. And MMU support does add a lot of overhead. The shared address space with multiple threads is still the most common embedded design I think.

Re:Yuck

[GrahamCox]

Only idiotic, big organizations like Boeing use Wind River stuff

Just FYI, my PVR runs on VxWorks. It's made by a small Korean company called Topfield.

Re:Yuck

[LordNimon]

Microsoft buying Wind River would probably run afoul of anti-trust laws, so I don't think Intel was afraid of that.

Re:Yuck

[Epistax]

You think they weren't already doing this?

Re:Yuck

[Anonymous Coward]

I don't think so - embedded OS' just don't sell in the kind of numbers you'd need.

This site might provide some insight as to why.

Re:Yuck

[Anonymous Coward]

Those of you with hard real-time requirements who think VxWorks and Arinc 653 is the answer need to get with the times.
I use VxWorks and Arinc at work and I just bought a $150 armadeus board online (which runs linux BTW) to mess around with at home. I can do more with that board and free software than I can with 20k worth of equipment at work.

The fact of the matter is anything without an FPGA should never be called "real time". 4 microseconds of jitter is laughable when you have an FPGA. I can do 10 nanosecond precision timing on Spartan 3's without batting an eye.

And while linux isn't 'man-rated' software, VxWorks shouldn't be either. If you want REAL reliability you need something like an L4 microkernel. At least people have tried to do formally prove that the L4 is correct. VxWorks can make no such claim.

Re:Yuck

[schwaang]

This is why I can see a defensive reason for Intel wanting Wind River, but no offensive reason.

What about the possibility/perception of weakening support in VxWorks for non-Intel (mainly ARM right now) embedded processors?

Obviously, Wind River's VxWorks OS running on ARM is *the* main competitor to running on Intel in the embedded space. And there are non-ARM up-and-comers (nvidia?) in the embedded space that will require good VxWorks support to really make it. Now they will have to kowtow to their biggest competitor (Intel) or live by Linux and water alone.

Re:Yuck

[korbin_dallas]

Wrong, Wind River bought all Walnut Creek assets, then kicked Slackware to the curb. Patrick had to fire his 2 employees, and go back to a one man show.

All they wanted was BSD, cause they could keep that closed.

No, Wind River was no friend to Linux.

Re:Yuck

[jd]

I'm not sure on that. Microsoft entering the antivirus market by buying up an antivirus vendor, rebranding it as its own product, then leveraging its monopoly to make said product the de-facto antivirus product SHOULD have run afoul of many anti-trust laws. It's a new market for Microsoft that they are working to eliminate competitors in in much the same way as they did in the browser wars against Netscape.

On the other hand, Microsoft is already in the embedded market, via Windows CE. It's not a new market and unless they planned on making VxWorks a plug-in interface to CE, their monopoly elsewhere would not be useful. If Microsoft wasn't busted wide open on the first, I can't see them being given any grief on the second.

Re:Yuck

[larytet]

may be better hardware threads support ? better support of the Atom chip sets ? may be INTC wants it's own Android with 1000s existing clients ? and may be INTC wants to get rid of WinCE ?

Re:Yuck

[jd]

Possibly. Intel has given up making its ARM processor (for now, though they could always return to it), and although Linux has several hard real-time variants for the embedded marker, and although there are other embedded OS' out there, VxWorks is by far the best-known and the most prestigious.

It is also one of the very few that is ratified for military and aerospace work. As much as I like Linux, and as much as I'm impressed by the fact that Lynx (a cut-down Linux) is FAA-approved for non-critical systems, and that there are even carrier-grade 5N-rated Linux distros, Linux simply isn't rated high enough (yet) to compete in the mission-critical arenas.

Re:Yuck

[symbolset]

I'm going to fix that for you.

Microsoft entering the X market by buying up an X vendor, rebranding it as its own product, then leveraging its monopoly to make said product the de-facto X product SHOULD have run afoul of many anti-trust laws.

Now permute X across all markets including OS, office software, programming languages, databases, antivirus, full disk compression, full disk encryption, folder compression, and every other darned thing they sell. They didn't invent any of it. They buy the pot of soup, pee in the pot, then sell the soup. That's their business model and it always has been. They used to be really good at selling that watered down soup, and that's why they're where they're where they're at. Now, I'm not so sure everybody wants their soup.

Oh, and the above is not entirely correct. Sometimes they promise the pot to a chef who prepares the soup, and then kill him for the recipe before the batch is done. They even coined a name for that strategy: "Knife the baby". When people find out about that, they're less likely to be interested in working in their kitchen.

Re:Yuck

[symbolset]

Holy crap! Talk about throwing out the baby and keeping the bathwater. I had missed this bit and hope some mod recognizes how informative this is.

Hopefully Intel is bright enough to reorganize the rocket scientists who launched that one into a corner where they can do no more harm. Maybe they have an antarctic thermal development lab, for space products.

Re:Yuck

[symbolset]

WindRiver has their hand in a lot of stuff. It's incredible that they were available for so cheap. No doubt Intel will spin off the parts they don't want like non-Intel product support, and yield a good profit on the deal just from that. Which makes the software and engineering teams they keep, the patent library and technology sharing deals just a free bonus. That really is brilliant. It's like technology arbitrage, where you realize that the price for something in one place is far less than the price in another place plus shipping so you execute a deal where you keep the difference.

Now that Intel has realized that if they want to get further into your back pocket, they have to get their products into your front pocket phone and media player, your car, your refrigerator and your TV, they're going to be doing more plays like this. They're out of their customary box and suddenly all the world's their oyster. I'm glad for them that their finance arm was late to the party and didn't get to play more than they did in the meltdown of dumbness. Intel is not a finance company. It's a technology company. In this sense, "technology" means building people the tools to do cool and fun new stuff, and letting them do whatever they want with those tools - because people are clever and just because you built them a tool doesn't mean you know every purpose to which they could put it.

This one buy is a master stroke for them - it means they've scanned the markets they're looking at getting into who have not only the most market penetration, but also the best products, and then bought the single one that was the most oversold. Somebody in their executive suite is due a large bonus. I actually expect more of this from them now but the fruit that hangs the lowest is plucked first so I expect they'll get diminishing returns unless they're very lucky or extremely smart. Seeing this, my money's on smart.

/Gotta get me some stock.

//No, I don't work for them and I don't own stock or have options. Yet.

Re:Yuck

[Anonymous Coward]

Only idiotic, big organizations like Boeing use Wind River stuff.

Or NASA, iit's only the most deployed embedded RTOS on the market., and it's not as if the lander, rovers, and recon are running VxWorks.

Embedded devices use Arm chips

There's more to embedded devices than consumer electronics a and portables, you know. ARM Holdings wishes it moved a tenth as many units as Zilog does.

What, you thought all those eindustyrial electronics, microcontrollers, aerospace, traffic flights, thermostats, t etc were Running Linux on ARM?

Hear that? It's you being laughed at.

Re:Yuck

[Anonymous Coward]

ARM really? I've been doing embedded systems for 20 yrs. We use PPC.

Re:Yuck

[c]

> How does Intel plan to compete against $6 Arm chips?

The way they used to compete with them was by manufacturing (StrongARM, XScale). Wouldn't surprise me if they're still manufacturing some ARM processors for someone in one of their fabs, and it also wouldn't surprise me if they're still collecting royalties on some of the ARM stuff they've spun off over the years.

c.

Re:Yuck

[tuxicle]

Mod parent up. I find it funny, too, that so many struggle so hard to get "real time" interrupt handling when very simple application of FPGAs would solve their problems neatly and with a lot less work. This doesn't even mean you need to go the Microblaze/NIOS route, use an ARM/PPC/whatever, couple it to the FPGA with some simple bus (SPI?) for control functions, and you're all set.

Re:Yuck

[Anonymous Coward]

On the other hand a smart meter CPU don't have the on chip resources to run Linux either.

Linux/uclinux needs a lot more memory than what those newer Linksys router boxes has. Which OS do you think they ship these boxes with that fits into a much lower foot print? Might want to slim down the kernel a bit before complaining?

Re:Yuck

[mzs]

Oh yes it does. It eats something like 1/4 of your physical memory by default if you want processes instead of tasks. It also adds latency and removes some determinism (no longer can you get away with a flat memory model, in PPC in particular you could often easily use the BAT registers and not have any TLB misses and in some cases treat 1MB of your L2 cache as really fast memory).

Re:Yuck

[mzs]

A great mix in practice is to use a gate array in a PMC, PCI, IP, or VME card/board for that stuff but still have the beefy processor for less predicable 10s of us (ISR) and 10s of ms (realtime tasks) stuff.

Re:Yuck

[Anonymous Coward]

With Intel's ties to Microsoft we're one step closer to the Microsoft powered car.

Re:Yuck

[Thomas Charron]

The toolkits are free?

When exactly WAS the last time you tried to price a copy of IAR?

Re:Yuck

[Thomas Charron]

Intel spawned them off to a seperate company, Marvell.

Re:Yuck

[c]

They did. They also kept manufacturing them under that contract until Marvell spun up manufacturing. I'd be very surprised if Intel doesn't have the expertise and manufacturing capabilities to start building ARM processors ASAP, if they aren't already. Whether they can legally do so after selling of the business... who knows.

c.

Re:Yuck

[petermgreen]

The fact of the matter is anything without an FPGA should never be called "real time". 4 microseconds of jitter is laughable when you have an FPGA. I can do 10 nanosecond precision timing on Spartan 3's without batting an eye.
But it's not going to make much difference when your "plant" has time constants of seconds or more anyway.

Real time system design is about knowing what your deadlines are and then designing a system in a way that ensures it will always meet those deadlines. Sometimes programmable logic (whether PAL, CPLD or FPGA) is the way to go (simpler stuff or stuff with very short deadlines), sometimes a CPU is a better choice (more complex stuff with longer deadlines), sometimes a hybrid approach of more than one device may be your best bet.

Industrial little boxes.

[0100010001010011]

Finally an obscure company I've heard of. We have quite a few Windriver AC-104 boxes running around. Bullet proof and with nothing but Deutsch connectors. Most people in this building prefer Mathworks/SpeedGoat's little blue boxes but they always seem to break pins.

AC-104s were originally for Matrix-X, but we run Matlab's RTT on them for embedded control of engines.

Whacked...

[Anonymous Coward]

I can't see this being great for windriver, unless it's primary owners were planning on retiring. Really, will VxWorks only support Atom now? Will other platforms diminish in support?

Whacked I say, and I can't imagine this doing overly much for Intel either... Whacked!

Non-Intel support

[AaronW]

Given that Wind River supports a wide variety of embedded chips from many vendors other than Intel I wonder what sort of impact this will have, especially since Wind River also supports VxWorks which is used on many embedded devices.

Re:Non-Intel support

[NoodleSlayer]

I'm not sure what the value would be to Intel if VxWorks only supported Intel CPUs, I would think that would drive device manufacturers to use other companies embedded OSs/tools instead.

Re:Non-Intel support

[exley]

VxWorks is a real-time OS made and sold by Wind River. So while yes they do *support* VxWorks, it goes a bit beyond that.

Re:Non-Intel support

[Skapare]

Or drive them to Intel CPUs.

Re:Non-Intel support

[Amazing Quantum Man]

Because a Pentium class processor is so much more power efficient than the equivalent PPC.

Re:Non-Intel support

[dgatwood]

Depends on the market. Anybody using VxWorks at solely the POSIX layer is almost guaranteed to just dump it and switch to Linux. The only ones who I think might be likely to change their hardware rather than rewriting their software would be hard RT customers, and I doubt that makes up a large enough percentage of their installed base for VxWorks to remain profitable in the absence of their other customers. Just a gut feeling.

Re:Non-Intel support

[Anonymous Coward]

Given that Wind River supports a wide variety of embedded chips from many vendors other than Intel I wonder what sort of impact this will have, especially since Wind River also supports VxWorks which is used on many embedded devices.

Urm, probably a progressive but noticeable end of decent support for non-Intel devices?

Re:Non-Intel support

[samkass]

But why would those other companies give WindRiver advance copies of hardware or unannounced chip plans now? It seems like they'd just give the stuff to MontaVista and encourage their customers to go there instead of tipping Intel off to all their plans. If you want these OSes to work with the hardware on announcement day there has to be a lot of pre-release information being passed around.

Re:Non-Intel support

[Rogerborg]

Because a Pentium class processor is so much more power efficient than the equivalent PPC.

What is this, Soviet Xanaduistan? If an x86 is a more cost effective purchase than a PPC, then the ongoing maintenance costs are some other schmuck's problem.

Re:Non-Intel support

[Darinbob]

Depends on the market. Anybody using VxWorks at solely the POSIX layer is almost guaranteed to just dump it and switch to Linux.

Not so sure. You still need a major porting effort all over again. Linux does not just plop into place on an unfamiliar board with unfamiliar devices and memory maps. There is a lot more to the system than just the application; plus the applications that only need POSIX capable services (plus Berkeley sockets) may not be that common. It's far far easier to change operating systems at the start of a project than to do it later on.

Re:Non-Intel support

[dgatwood]

Very true, but if your alternative is redesigning your hardware for different core silicon, I know which one I'd choose every time. I've ported Linux to unsupported hardware from pretty crude specs, and even with custom interrupt controller logic and lots of other really awful hardware, it only took a couple of weeks for me to do a mostly functional basic bring-up (with no custom drivers). That was doing it as a spare time project, BTW.

Yes, board bring-up takes time, particularly if you have a headless embedded device (or worse, are having to debug by blitting bursts of garbage to the screen because the kernel is crashing before it gets the video or serial ports initialized), but JTAG is your friend. Alternatively, there are plenty of good companies out there who will do that for you if you want. (Full disclosure: I worked for MontaVista around the turn of the century.)

And yes, rewriting drivers for a different kernel takes time. That said, if you have a stable piece of hardware that works, the porting time pales in comparison with having to design new hardware, have it built, do a new bring-up of completely different hardware, find a dozen bugs in the new hardware, do reworks and/or have a new rev build, repeating until you have something that can POST....

And if you're just using reference hardware designs, sure, a hardware change is a minor inconvenience, but then again, odds are other OSes will already support that reference hardware out of the box, so an OS change is also a relatively minor inconvenience. At that point, it's a toss-up. Most embedded vendors don't stick with a stock reference board very much past the first rev, though, at least if they want to make a profit.... :-) Too much extra unnecessary hardware.

Either way, so much stuff is done with PCI/PCIe, USB, FireWire, and other industry-standard, easily probed busses these days that bring-up isn't nearly as bad as it would be with truly custom hardware.

Re:Non-Intel support

[Amazing Quantum Man]

In many embedded situations, the power budget rules everything.

Re:Non-Intel support

[symbolset]

The support of non-Intel architectures is a facility that's worth money. Since Intel has no interest, either in favor or against in this instance (because spinning it off wouldn't prevent the support of non-Intel architectures), it stands to reason that when economic times are better they'll spin this off without handicap, and at a profit. Because they're not dumb and that's how they play this game. Intel is not Microsoft.

Re:Non-Intel support

[seebs]

What we've been told so far (and this was stated in press releases, so I can repeat it) is that we will continue to support all the architectures we currently target.

(/me is the guy who does compiler bundling for wrlinux across several architectures.)

Not only autos and mobile phones

[mmustapic]

Their OS, VxWorks, was/is used on many spacecrafts: http://en.wikipedia.org/wiki/VxWorks#Spacecraft_using_VxWorks

Re:Not only autos and mobile phones

[jd]

It's also used heavily by CERN and other nuclear research groups, and is also used heavily by the US military.

Re:Not only autos and mobile phones

[npsimons]

Their OS, VxWorks, was/is used on many spacecrafts

It's also one of the very, very few OSes certified for aircraft. Wind River paid a good amount of money to get it certified, and as a customer you will pay an arm and a leg through your nose to get that certified software. It's one of the reasons on a (very) short list that we use it instead of Linux for a lot of software that goes on aircraft. Personally, I'm not too impressed with vxWorks, but I am a little disturbed by Intel picking them up; most embedded systems I've ever worked with are non-Intel (mostly PowerPC). How will this affect their support of non-Intel platforms? Of course, I was mildly annoyed when one of my former employers sold Wind River RTLinux, but they still seem to be going strong.

Re:Not only autos and mobile phones

[ehovland]

I was in a class the other day and a technologist asked the question, "Why do we always pick VxWorks for our flight s/w OS?" The answer was, because once something flies, it basically always flies. If Linux, ecos, qnx or any other embedded OS flew once - it can then always fly. It is a strange problem. VxWorks should not be picked just because it flew. That is unless you need an OS for a flight system.

VxWorks PC support

[nicholasjay]

I wonder how this is going to affect VxWorks' PPC support. The PPC architecture is used on a lot of spacecraft. If WindRiver slowly gets 'nudged' to drop PPC support/updates/new versions of VxWorks and boost x86 support, then that may be enough to get us off the VxWorks teat and on to something more open, like RTEMS.

Re:VxWorks PC support

[Anonymous Coward]

Yeah, goes for airplanes too, Intel has a very bad rep for avionics (DO-178) applications, PowerPC is king. VxWorks or Integrity are you main options there for generic OS currently, with VxWorks being a lot more popular.

Re:VxWorks PC support

[Mulder3]

If WindRiver slowly gets 'nudged' to drop PPC support/updates/new versions of VxWorks and boost x86 support, then that may be enough to get us off the VxWorks teat and on to something more open, like RTEMS.

Why RTEMS? why not use embedded Linux like uclinux, Timesys, Montavista,etc?

Re:VxWorks PC support

[K. S. Kyosuke]

Yeah, but the VxWorks branch that NASA uses was AFAIK a co-development of VxWorks and NASA (or JPL or someone else, I am not sure). I got the impression that the Wind River folks were quite proud of this. Surely they don't want this trophy to go to someone else.

Re:VxWorks PC support

[nicholasjay]

JPL uses VxWorks on a lot of projects and almost has WindRiver people constantly on site. Even with this JPL developed their own file system to address the inadequacies of the filesystems VxWorks comes with (dosFS, HRFS, etc). Beyond that there are a lot of other NASA centers that use VxWorks that don't have as nearly a good relationship with WindRiver as JPL. There has been a lot of time spent mucking with the source code of VxWorks to enhance performance to acceptable levels.

Re:VxWorks PC support

[nicholasjay]

To tell you the truth, I just have more experience with RTEMS. Back before the real time extension were available, Linux of any variant wasn't truly a real-time OS, and that pushed it from consideration from projects. Now there are a lot of real time Linux variants out there, but the ball got rolling with RTEMS before Linux ocould be considered seriously. Now whether or not a specific mission needs 'real-time' as in 'hard real time' or as in 'really fast' is a totally different topic.

Re:VxWorks PC support

[joelsherrill]

Well as the maintainer of RTEMS (http://www.rtems.org)>, I am biased but there are a number of technical reasons. Deterministic (e.g. predictable or O(constant)) performance independent of the number of OS object instances in the system is a big reason. Support for priority ceiling and priority inheritance. Very low resource requirements with a minimal configuration on some CPUs starting at 16K. All software running on the target hardware appropriately licensed for use in embedded systems -- no pure GPL code. RPMs or Windows tool binaries for over a dozen CPU architectures. A project that is used to supporting software long term. RTEMS aims to be compliant with POSIX Profiles .51 and .52 as well as providing an API based upon the same standard as pSOS+ with a feature set tuned to make it easy to transition VxWorks applications. We even do automated code coverage analysis to ensure that our test suites execute as much of the OS as possible. We are currently over 97% of the binary and have a Summer of Code project working to improve that. And RTEMS is has been on many spacecraft also from NASA, ESA and others around the world. Herschel, Planck, Electra, Venus Express, Dawn, Fermi, and THEMIS come to mind quickly. And that ignores many national laboratories around the world including Argonne,Stanford Linear Accelerator, Oak Ridge, Canadian Light Source, and Brookhaven. RTEMS is a unique free software project that balances the needs of embedded projects that need stability and longevity with the release early and often approach of the FOSS community. We support student and hobby projects in parallel with some of the most serious projects out there. We are an open project that is 20 years old with 15 of those years captures in the CVS repository. That's why RTEMS is a valid and very competitive FOSS alternative to VxWorks for a deeply embedded real-time operating system.

Re:VxWorks PC support

[Darinbob]

Also, even a real-time Linux kernel is likely to be bulkier and a bit slower than RTEMs or VxWorks or many other RTOSs. Linux was designed to be a general purpose operating system, and the embedded and real-time variants have to deal with that history. Linux does have a lot of advantages though to balance off the disadvantages, so whether it is appropriate to use or not depends upon the system in question.

Re:VxWorks PC support

[phantomfive]

Bulkier, yes, but probably not faster. RTOSes are not usually optimized for speed, but rather for precision timing. Thus they often have things like naive scheduling algorithms (but purposely so, because they are highly predictable!). The Linux authors have spent a lot of time making sure network throughput is optimal, and I would be surprised if there is any RTOS that can pipe more data onto the line faster. Also, linux threads are pretty amazing, you can get 30,000 of them going pretty good. In my experience the thread situation on RTOSes has been pretty depressing. They mostly work, but.....they aren't necessarily optimized. On the other hand, it's hard to get Linux to run on a system without a TLB (or some kind of modern memory management).

So, obviously there is more to performance than just code size; in fact, a lot of times you can make a tradeoff between code size and algorithmic efficiency (bubble sort VS quicksort, for example).

Thankyou for your comment.

Re:VxWorks PC support

[Darinbob]

The big thing I notice on Linux is the MMU stuff. The context switch there has to flush caches and TLBs. Threads are similar, though on Linux they're in the kernel which means a switch from user to kernel space; I'm not sure if Linux still uses system call interrupts for this, but if so that's a lot of extra overhead. This is all from PPC perspective w/o multiple cache levels, I don't remember how this gets done on intel.

Re:VxWorks PC support

[TheRaven64]

Not sure about PPC, but with SPARC and ARMv6 or later the TLB and cache are tagged. This means you don't need to flush either for a context switch, you just need to update the process ID register (8-bit on ARM, I think it's bigger on SPARC but my memory is a bit fuzzy there). You only need to do a flush when you are reassigning a hardware PID. Even with an 8-bit tag, this doesn't happen very often. My laptop currently only has 109 processes, and of these over half are in a blocked-waiting-for-IO state and have not been granted any CPU time for at least several seconds.

Recent Intel chips also have this kind of tagging arrangement, but with only a 6-bit tag and only exposed via the VT extensions (meaning, somewhat strangely, that a context switch between two processes in different VMs can be faster than between two processes in the same VM). Without this, every context switch on x86 needs a cache and TLB flush, which is why they are so expensive. Note that a privilege switch, as in a transition from user to kernel mode, is not a context switch on most x86 operating systems. The kernel's memory is mapped into every process's address space but is marked as needing ring 0 privilege to access. When you enter ring 0 (via syscall/sysenter, an interrupt, or a call gate) the kernel's address space becomes visible and so does the userspace process's in-core memory. This is what people mean when they talk about things like a 1GB-3GB memory split; the kernel reserves 1GB of the 32-bit address space and each userspace process gets 3GB. Linux also supports a 4GB-4GB split, where the kernel has a completely disjoint address space, but almost no one uses this because it makes system calls more expensive and if you need more than 3GB of address space for userspace processes then you are better off getting a 64-bit CPU.

Actually...

[Anonymous Coward]

My philosophy on embedded chipmakers is two-fold. First, they are on a financially insecure base as are the flash memory manufacturers. Second, There are too many embedded chipmakers out there at the moment.
 
Now where this comes into play is the chaos effect generated by a chipmaker purchasing an embedded software company. This is a strong move in the wrong direction as evidenced by Intel's previous software company purchases. It is interesting to notice how well Intel's proprietary hardware software works, but when Intel begins developing OSes and applications, things will become a little too "black box" and will be hard to support in the future. In this way, it is highly probable that everyone will lose, Intel will shed off Wind River, a lot of people will lose their jobs, and we will be back to exactly where we started!!

Re:Actually...

[phantomfive]

Intel has a common design strategy of making two different teams work on the exact same project, without even knowing about the existence of the other. It is somewhat demoralizing to give your sweat and time to a project and realize that no one will ever see it because someone else in your company did the exact same thing.

My theory is it works really well for their manufacturing process, because you can experiment with different manufacturing ideas, and take whatever is best. It works horribly for software/chip design and creative type processes, because if you know its happening (and they've been doing it for decades, so you know it's happening), you have no morale to begin with.

Thus frequently AMD ends up with better chip designs, and Intel with better manufacturing processes.

Re:Actually...

[NovaX]

As an outsider, that isn't what I see. AMD has bought most of its core technology rather than designing it from scratch. The K6 was from NexGen, the bus from DEC (Socket A, HyperTransport), the Athlon was a great traditional design (P6/Alpha/PowerPC-like in ideas), the memory controller experience came from Alpha hires, their embedded chip is based on Cyrix's, etc. AMD has been quite good at taking proven ideas and implementing them for the mass market with a lot of success. The primary innovations they are given credit for is the memory controller on x86 (first done Transmetta Crusoe), HyperTransport (DEC), and multi-core (IBM Power).

Intel always seemed to be an innovative company that heavily funds R&D, but can have utter flops by not being pragmatic enough to drop a bad design. While they fail badly, the ideas are usually quite unique and I'm sure educational. The fact that they recover rather than repeatedly making bad calls (e.g. Sun) shows that they are resilliant. Having the different design teams probably helps to both recover from a flop and not corrupt creativity by allowing groups to go into different directions. As you indicate, though, there are only so many good ideas and the duplication has to be extremely frustrating.

So I'm not sure if Intel's approach is bad and they tend to be more innovative than AMD. Its costly, though, and as a consumer I've happily gone with AMD/Cyrix/etc when Intel pushes a flop chip.

Re:Actually...

[msince]

Intel has a common design strategy of making two different teams work on the exact same project, without even knowing about the existence of the other.

That's just BS. I have worked at Intel, and while there were projects that wind up with significant overlap and do get canceled, it is NOT the case that the projects don't know about each other. I saw projects get canceled because there was only so many people to work on projects, and with projects A, B, C, and D all in various stages, project B needed to be canceled and people moved to C and D because there was no way to do all of them with the budget constraints - and if B got canceled, C would be coming soon enough afterward (within 6-9 months) and cover most of the target market that B was going after.

Bad for morale - but a necessary business decision.

It definitely wasn't the case though that they were on the exact same project, nor that they didn't know about the other team. (Working on the exact same project would be just plain wasteful - and management at Intel is not very tolerant of that kind of waste in my experience.)

(Speaking for myself and not for Intel obviously)

MODERATORS!!!

[Anonymous Coward]

Mod Parent Up!
 
I used to work with Intel and while (s)he is not exactly specific on details, this is worth +5

The future is ARM and Linux

[bzzfzz]

Unless Intel decides to get as serious about the embedded world as they have been historically about the desktop, this amounts to last rites for Wind River. Starting with the 80186 in 1982, Intel's embedded processor offerings have been adaptations of desktop technology that have failed to stimulate the imagination of anyone building anything more sexy than a cash register. The needs of the embedded device market differ considerably and Intel does not understand them. Intel's idea of having a more highly integrated northbridge/southbridge/CPU package is just wrong. The embedded market needs products that don't have architectures that complicated rather than band-aids.

At this point, I'll take Linux with a GCC toolchain over VxWorks for any embedded project just to avoid the single-company support choke point and the costs and hassles with licensing. The nominally higher levels of integration and sophistication of commercial products aren't worth it.

Re:The future is ARM and Linux

[PCM2]

Unless Intel decides to get as serious about the embedded world as they have been historically about the desktop, this amounts to last rites for Wind River ... At this point, I'll take Linux with a GCC toolchain over VxWorks for any embedded project just to avoid the single-company support choke point and the costs and hassles with licensing.

You're aware that Wind River has offered its own optimized Linux distro for embedded systems for years now, including extensions for real-time systems? And that it runs on ARM and XScale?

Re:The future is ARM and Linux

[highways]

After Intel sold of its ARM errr... arm, it's in its best interest to stifle it's development.

Given the prevalence of VxWorks in hard real-time embedded systems (a space that Linux does not yet occupy, because it's by no means hard real-time), and that x86 is barely used in such applications, one does not need to think very hard as to what is going to happen.

QNX and Green Hills must be watching this very closely.

Re:The future is ARM and Linux

[guenz]

If linux sometime supports the functionality that is required by realtime applications, maybe, but not now. We have used a powerpc/vxworks based system for nearly a decade, and some people thought that vxWorks has some rather strange features, but at least the realtime part really worked. We switched to a linux based system, and all the realtime stuff blew up. We tried several rt extensions for linux, but they all caused more problems than they solved. Linux kernel is simply not designed for realtime conditions, e.g. just use a some standard posix functions in your code, some global kernel locks get entered and your realtime is dead and gone. After all, vxWorks may be proprietary, but it simply worked well, and I think we spent far more money in tweaking linux and the application code than for vxWorks licenses.

Re:The future is ARM and Linux

[Anonymous Coward]

Linux is not a swiss army knife you know?

Re:The future is ARM and Linux

[kamochan]

And it is a very effective single-company support choke point, with the costs and hassles, for those customers who have chosen "the RT linux from a well-known provider".

Yes, I speak of experience.

New Slogan?

[Anonymous Coward]

Does this mean Intel's new slogan is: Wind River Inside?

Wind River Implosion

[Lead Butthead]

A friend that used to work on software inside of intel indicated that rank and file other than chip designers gets no respect whatsoever inside that company. If true, I think we can expect Wind River numbers to dwindle to nothing in months.

Re:Wind River Implosion

[Anonymous Coward]

If he's a friend of yours he likely doesn't merit anyone's respect - as demonstrated by your insightful business commentary.

Party like it's 1989...

[argent]

Intel used to have its own real-time controls division, with the iRMX operating system written in PL/M and PL/M-86, Multibus and Multibus-II hardware, and a development system that ran on Xenix and MS-DOS. They systematically dumped the whole thing in the '90s, finally handing RMX over to TenAsys in 2000.

Guess it's time for that old second marriage.

Re:Party like it's 1989...

[TheRaven64]

Ah, iRMX. PL/M was one of the first language I learned and I still miss it whenever I program in C. The PL/M designers really knew what a low-level language should do. There are times when I'd really love to force everyone in WG-14 to spend a few weeks learning PL/M...

Re:Party like it's 1989...

[mzs]

One of my office mates drew the short straw and had to maintain that old stuff. Man I felt sorry for him.

Re:Party like it's 1989...

[argent]

I'd rather maintain that old stuff than the kind of spaghetti APIs you get these days. :(

Yes... having a regular, consistent, and portable API really does matter.

How is this not "anti-competitive"?

[macraig]

With continued antics like this, is it so surprising that the EU, at least, perceives Intel demonstrating monopolistic behavior?

Re:How is this not "anti-competitive"?

[nxtw]

What exactly makes buying another company (which is not a competitor) anticompetitive?

What exactly does Intel's perceived monopoly in one market (desktop PC CPU) have to do with an acquisition in the unrelated embedded operating system market?

Re:How is this not "anti-competitive"?

[macraig]

You need to read up on the history of Microsoft and monopolies in general. This goes precisely to the point, and Microsoft found itself in court for exactly the same behaviors (using an achieved monopoly in one product or market to bully their way into dominance in another). In the instance of but the acquisition itself is irrelevant. It's why Intel is doing it and what they intend to do with it that makes it anti-competitive.

Re:How is this not "anti-competitive"?

[nxtw]

You need to read up on the history of Microsoft and monopolies in general. This goes precisely to the point, and Microsoft found itself in court for exactly the same behaviors (using an achieved monopoly in one product or market to bully their way into dominance in another). In the instance of but the acquisition itself is irrelevant. It's why Intel is doing it and what they intend to do with it that makes it anti-competitive.

But they have not done anything yet; the acquisition in itself is not anticompetitive. Unless you have some other information, this is simply speculation in your part.

Re:How is this not "anti-competitive"?

[gwait]

If (as some here suspect, myself included) you suddenly see VxWorks become an Intel only platform, you may have your answer. VxWorks probably has the lions share of hard real time OS market..

Re:How is this not "anti-competitive"?

[macraig]

You must be newly hatched, huh? WE'RE not in court and I'm not on trial. This is Slashdot, where speculation is not only allowed, it's encouraged, nay mandatory! We all know what Intel plans to do with it, we just don't have a Minority Report with which to convict them... yet.

Save the proof for court and mathematics class.

BTW, I already said that the acquisition itself wasn't anti-competitive (even though I munged the sentence and cut out the middle):

"...but the acquisition itself is irrelevant."

(That sentence was supposed to have read: "In the instance of Microsoft there were no acquisitions involved AFAIK, but the acquisition itself is irrelevant.")

Re:How is this not "anti-competitive"?

[zzatz]

Wind River sells products that run on non-Intel processors, which helps sell those processors. If Wind River support for ARM or MIPS, for example, stagnates and falls behind its support for Atom, then the effect is to reduce competition against Intel.

Competition means making your own products more attractive: lower price, better performance, etc. Interfering in the market to make competing products less attractive is not competing, it is an attempt to reduce or eliminate competition. Competition is what provides the good aspects of markets or democracy, not the market or elections themselves. A market without competition is like an election with only one party. In both cases, it is the presence of viable alternatives the makes those systems work, and anything that reduces the competition is evil.

Can you have a free election if one party controls the newspaper and radio station? Can you have a free market for processors if one processor vendor controls the tools needed to use those processors? Is Intel trying to make it easier to use Intel processors, or make it harder to use non-Intel processors?

Does Intel's purchase of Wind River increase or decrease the competition for sales of processors?

Re:How is this not "anti-competitive"?

[nxtw]

On its own, Intel's purchase of Wind River on its own does nothing to increase or decrease the competition for sales of its processors. Anyone saying otherwise is speculating.

Re:How is this not "anti-competitive"?

[zzatz]

Antitrust law is about interaction between companies and markets. If you put on blinders and only at each action "on its own", there can never be any violations of antitrust law. If you look at each transaction "on its own", you aren't looking at a market. A market is made of all of the transactions, and the power of the free market is that each transaction influences every other transaction.

Looking at Intel's purchase of Wind River as an isolated event divorced from the context of markets denies the significance of free markets.

Does Wind River's support for various processors influence the sale of those processors?

Could Intel use control over Wind River to suppress competition for embedded processors?

Has Intel engaged in anti-competitive practices in the past?

If you want to argue that Intel could use Wind River to suppress competition, but hasn't done so yet, then I'll agree. But at a minimum, that means that Intel should be watched closely. At the most, this potential for abuse, coupled with a history of abuse, is grounds for the government to prevent this sale. Reasonable people can argue which of those positions is appropriate. But to claim that Intel's purchase of Wind River has no impact on the sale of processors is just plain silly.

Re:How is this not "anti-competitive"?

[nxtw]

Once again: Intel's purchase of Wind River on its own does nothing to increase or decrease the competition for sales of its processors. Anyone saying otherwise is speculating.

Re:How is this not "anti-competitive"?

[zzatz]

Once again: Intel's purchase of Wind River could decrease the competition for sales of its processors. Anyone saying otherwise is willfully ignoring the operation of markets, not to mention the history of Intel.

The market for processors does not exist "on its own". If it did, Intel would be much, much smaller. Intel did not rise because its processors were better on their own, in isolation, regardless of other factors. Intel is what it is because IBM chose the 8088 for the PC, and Microsoft created a compelling market for sales of software in x86 binary form. Intel rose to that opportunity and deserves credit for it. But Intel's success depended on Microsoft, who does not make processors. Sales of processors do not happen in isolation. They depend on other factors, and Wind River is a market leader in one of those factors. What Wind River does will effect sales of processors. Why else would Intel buy them?

In other news...

[jd]

Microsoft has started buying up biotech software companies (most recently Rosetta Biosoftware). There almost has to be some link, but all of Rosetta's software runs on Linux, with only a handful of clients on Windows, and no direct usage of VxWorks - although I'd be surprised if the actual hardware doing the data collection was running a server OS rather than an embedded OS.

Speculation on a possible connection?

Thank goodness

[MobyDisk]

I work for an embedded systems manufacturer that switched to Windows Embedded as a result of Wind River's horrible support. Fortunately for them, they used VxWorks on Intel, so things are probably going to look good moving forward. For this company, USB support was the last straw. Wind River knew that lots of USB flash devices didn't work on their OS, and they wanted to charge for the development time to fix their bug AND then the OS upgrade once it was fixed. It eventually got to the point where the company was stockpiling the USB flash drives that worked on VxWorks, since they were getting hard to find. Finally Wind River they fixed it, but after this company switched OSs. It would have cost over a million dollars for licenses for the new version of the OS that contained the bug fix. Since Intel was on the USB development committees, I expect this problem (and other hardware-related issues) will vanish quickly. I just feel sorry for all the people who used VxWorks on Motorola chips, etc.

Re:Thank goodness

[larytet]

One answer - go for Linux if you want to avoid single vendor point of failure. Go for commercial Linux like TimeSys if you insist to pay money.

Re:Thank goodness

[Zoxed]

> I work for an embedded systems manufacturer that switched to Windows Embedded...

Does your employer by any chance make aircraft control systems for Airbus ?

Re:Thank goodness

[mzs]

This rings true, we have had similar experiences, but one thing to note is that often what WRS did is that they took a lot of code provided by the likes of Moto who used code from the likes of Marvell and Intel to make a BSP. That's often why early on things were not great across the board. It was so bad initially that there were at least three different ways of doing PCI! Then someone would pay to get things improved and then in a later version it all got integrated and everyone got to use it. For example the networking code went through a few versions. First there was one, then there were two offered early on in vxWorks 5.x but you had to pay extra, then only the better one got rolled in. Then around 5.5 you could buy a better (but slower) stack from another vendor. Then WRS bought them and offered it at extra cost, then around 6.4 it became the only option.

There was also all the AE extensions that you had to pay for extra and became part of the base in 6.0. But the problem was like you state you had to pay all over again to go from 5.x to 6.x under a completely different model. For example in our case it was more economical to do per board (target) for a few BSPs with 2 hosts (dev boxes), but under 6.0 it became more economical to do all BSPs, unlimited targets, but a small fixed number of concurrent developers on an unlimited number of hosts. Of course we had to pay all over again and still pay for continuing 5.x support separately.

Also all that I described was for vxWorks and support, where was also the debugging and dev stuff you needed to pay for. Again as vxWorks went from 5.x to 6.x that went from 2.x to 3.x. The 2.x stuff was wxWidgets and tcl/tk based, the 3.x stuff is Eclipse based. Also you have also had in most cases at least the options of a gcc or diab tool chain. You used to have to pay extra for diab, now you pretty much always have to buy it, even if you don't use it.

With regards to the support, yeah it got pretty crappy, it used to be great, and the newsgroup was good too. Then we got a guy that worked with WRS and he was able to get them to send us source code with typically agreements like 3 people could see the code. Eventually WRS hired that guy we had but in 6.x it got a lot more simple as you can get access to a whole lot more of the source code for not much extra money.

I'm a guy that does vxWorks on Moto VME boards and now is a pretty scary time. Those boards are now made by Emerson who really have not done anything new with them and now with WRS bought by Intel, that could possibly be even worse. VME is a place the after pSOS was always the best. There were a few particular boards that had decent RTEMS, Linux, or BSD but they were always few and far between. The other thing is that except for networking vxWorks was always faster than RTEMS (across the board) and Linux (when you looked at what were the worst 5%) with respects to latency.

aargh

[amb5l]

VxWorks seems to have been around forever in the high performance embedded computing scene, with solid VME support. (Amazing how VME keeps going, it was "on the way out" when I started life as a junior hardware engineer 20 years ago.) The software engineers I work with hate it, though. Extremely late "proper" support for PCI and likewise for SMP are a couple of issues I recall causing much annoyance. Unfortunately our customers keep using and re-using it, so we accept it as a necessary evil.

The problem for my business is that we (like many embedded folks) are still doing good business with the PowerPC architecture, despite the frustrations of PA Semi's disappearance, and something of standstill on high end devices at Freescale and IBM. Surely the perception will develop that yet another roadblock to using PowerPC in embedded systems is going to develop.

So I guess we high end embedded folks will have to jump on the Intel bandwagon. I just hope something positive happens on the BIOS front - that's one area where PowerPC is really great (U-Boot, CFE etc.) Having looked at Intel for ATCA products in the past, the BIOS issue was IIRC an outrageously expensive nightmare if you wanted source code, and plain expensive if not...

I would be very tempted by Atom and Tolapai if I could get U-Boot (or something as good) for Intel. How helpful are Intel to open source BIOS efforts?

Re:aargh

[highways]

Atom, IIRC is 0-70degC temperature rated.

-40 to +85degC is much preferred if a device is to have outdoor (or worse, automotive) exposure.

Until such time, may embedded designs will not touch Atom. Let this be a warning to Intel if they try to force VxWorks customers onto their silicon.

Maybe their recent licensing agreement to TSMC may start to address this...

Re:aargh

[amb5l]

You're right about extended temperature support for embedded systems, but an Atom variant with it is either here or coming soon. You can also get Tolopai at 600MHz with industrial operating temp.

Re:aargh

[gwythaint]

EFI is every bit as good as U-Boot

Re:aargh

[amb5l]

Heard about EFI in the context of Apple Intel h/w. My extensive research (Wikipedia) suggests that it is substantially closed source, with a small portion available with a BSD license - and rhe FSF don't seem to like it. I like U-Boot because it's open source, with lively community based support. Low cost of entry and all that.

Anyway, am I missing something? Is EFI opening up?

Of course I've failed to mention in all this that in my line of work VGA BIOSes are often as much of an issue as the primary boot firmware...

This is a monopolistic move

[wirehead_rick]

Intel will limit the market for VXWorks which is all Wind River has that anyone would want (Yes. Wind River has a real nice integration tool for Wind River Linux and that could be a wild card factor in the future but today it's all about VXWorks). How? Give VXWorks away for free or very low prices when buying an Atom Processor, for example.

Intel: "You want VXWorks support for your Arm (Mips, etc.)? Ok yeah we'll do that but since you aren't buying our silicon we're gonna have to charge you the 'regular' price, OK?" Geez? Should I pay $200k for annual support/royalties for VXWorks or just switch to an Atom and get it for free? Tough choice.

Don't know if the deal is big enough to pop up on the radar for federal regulators but if you are using VXWorks today, it's time to look at alternatives or look at Intel processors like the Atom (and I wouldn't look to M$ either). VXWorks support for third party processors is doomed. Maybe this is good news for obscure embedded OS's like UCOS/II or ThreadX.

The good news is the embedded market has _never_ bowed to monopolistic moves because most embedded systems are highly specialized (and 95% of them don't need graphics, hard drives, web servers, etc) and can easily be created as "roll your own" systems.

On a long time scale this will simply be the end of VXWorks as Intel struggles to force companies to use it on their silicon.

Re:This is a monopolistic move

[Epistax]

If Intel in any way restricts VxWorks for other architectures compared to any of Intel's, I think real time Linux work will surge. Right now (for us) VxWorks really is the only solution. The current real time-ish Linuxes available are not deterministic enough (we took probe measurements), but if that changes, we might gladly switch, if only because of the extreme cost of VxWorks. It'll also be interesting to see what happens to the support department behind VxWorks, as it has waned recently.

Re:This is a monopolistic move

[Glock27]

You might also want to look at other proprietary systems like Integrity and QNX. With high-end embedded "free" versus "not free" is a very muddy area (meaning that fixing a problem might be prohibitively expensive with the "free" solution). As far as I know, none of the free solutions have true deterministic resource management.

Certifications might also be an issue, as in DO-178B.

Re:This is a monopolistic move

[Anonymous Coward]

As far as I know, CxWorks and Linux are not the only OSs that are RTOS.

Will you not consider QNX nor LynxOS?

The WRS perspective...

[Anonymous Coward]

Hello dear /.ers,

Intel has made it very clear to WRS that WRS will be maintained [semi] autonomously - WRS has lots of deals with Intel's competitors, and Intel has lots of deals with WRS' competitors. However, WRS was already working very closely with Intel on products supporting the Intel architecture, and WRS has embedded/os knowledge and strategic connections that could prove extremely useful to Intel.

Intel has also made it extremely clear to all involved (WRS employees & customers) that it's not desirable (to anyone!) to drop non-Intel architecture support. Bubbling through the ranks, that message is affecting priorities - WRS very much does not want to scare non-Intel customers away.

So, from the WRS perspective, we may get a little bit more help/tools from Intel (yay), we may be able to stop taking mandatory vacation time (yeesh), and they may even bring some of our other benefits back. So far a good thing. I wouldn't expect any major changes to products in the near future.

disclaimer: I am not a WRS marketing guy. I am an engineer working on architectural code for many architectures, Intel included. I am also an avid /. reader.

There you go - horse's mouth, so to speak.

Re:The WRS perspective...

[Anonymous Coward]

I also work at Wind River. I was at the meeting where "Intel made it very clear to WRS that WRS will be maintained [semi] autonomously" and I don't believe it for a second. Ten years ago Wind River made the same promise when we took over ISI. We didn't keep that promise; why should we expect Intel to keep theirs?
 

It's true that "WRS very much does not want to scare non-Intel customers away", but the sale has already done that. Freescale isn't going to be giving us detailed advance information on its new chips any more!

 

Actually what I expect to happen in the next couple years is that Intel will break Wind River up into discrete units, absorb the parts they want, and sell off or shitcan the rest.

Re:The WRS perspective...

[Eil]

Intel has made it very clear to WRS that WRS will be maintained [semi] autonomously

It's not that I don't believe the AC, nor do I wish to be overly cynical here, but doesn't the big company always say this to the management of the little company after an acquisition? Then later on they all get sacked and replaced with promoted managers from the big company?

I'm not predicting it will happen in this case, but I've seen it happen so many times...

Re:The WRS perspective...

[ehovland]

I will believe Intel's promises 2 or 3 years down the road when they have cleared the merger and they can do whatever they want with the company. Same thing goes for Oracle w/ the Sun merger. What they say today cannot be taken as fact because they are currently saying whatever they think they have to to get the SEC and stock holders to approve of the merger. But let's be hopeful. It would be good if Intel only improved WRS's real-time Linux stake and kept helping VxWorks get better.

Re:The WRS perspective...

[seebs]

I don't know which coworker that was, but I'll go so far as to say, non-anonymously, that this matches what I've been told. So I can say, yeah, that's what they tell us.

Do we believe them? I do provisionally -- my experience with management over the last couple of years has been such that I am inclined to trust that this is what was represented to them, and that they wouldn't have agreed to the deal if they didn't feel they had genuine reason to believe it.

Atom is too near term

[symbolset]

Think Moorestown and Larrabee more likely.

Intel has finally realized that they own their whole box and they need to get out of that box in order to get growth, especially in a down market.

Re:Atom is too near term

[Chris Burke]

Intel has finally realized that they own their whole box and they need to get out of that box in order to get growth, especially in a down market.

Yeah, that was the motivation behind a lot of their ill-fated adventures, though some, like graphics, weren't as ill-fated as they first appeared.

I see the need to expand, but that's why embedded systems seems like an odd choice. For a company the size of Intel, there's just not a lot of (profit margin-wise) room for expansion. As a back-up source of income when their main microprocessor markets are down it seems rather paltry. They'll never be able to dominate the market and enjoy monopoly advantages like they have on desktops, it's too wide a field.

But on the other hand, maybe that's all fine as far as they're concerned because it means instead of just having expensive wasted fab capacity, they can make some money off it instead. More money is better than less, obviously. :)

BSDI?

[Anonymous Coward]

Wind River owns the BSDI code. What is Intel going to do with it now? Leave it dead? Give it to the FreeBSD guys? GPL it? Does Apple want it?

Re:BSDI?

[Anonymous Coward]

Wind River owns the BSDI code. What is Intel going to do with it now? Leave it dead? Give it to the FreeBSD guys? GPL it? Does Apple want it?

according to http://en.wikipedia.org/wiki/BSD/OS Wind River stopped doing anything with it in 2003. Who knows if there is anything in there worth having now.

Re:BSDI?

[Just Some Guy]

Who knows if there is anything in there worth having now.

I'll go out on a limb and say "not likely". It wasn't a major OS with a huge dev team to begin with, and I never remember envying any of its features. Seeing how far FreeBSD has come in the last 6 years, I can't imagine that a less-developed variant from back then would still have much to offer.

At least third marriage

[GGardner]

Remember how three years ago Intel sold off the XScale division, to get out of the embedded space, and focus on servers and desktops? (Look it up) I bet some new vice president decided that they needed to get back into this business, knowing nothing about the reasons they sold off XScale. This reminds me of GM dumping the EV1 electric car, and ten years later, starting from scratch on the Volt.

New market

[symbolset]

If they make good stuff and sell it cheap, do we not get cool new stuff for cheap? I fail to see the problem.

What happens when an economic contraction bottoms out is that the smart people who squirrelled away their cash in good times get to buy up neat stuff at fire sale prices. I think that's all that's happening here. It's a sign that we've turned the corner and the wise guys are buying up the stuff that's oversold.

Please don't read into the above that I approve of the purchase price for DataDomain. A proprietary implementation of lessfs is not worth two billion dollars. I could write that code myself and so could many of you. Whichever company gets it is going to gut it for the customer list and that's even more dumb because after you've killed their incumbent product, they don't want to buy from you. I can't wait 'till the a FOSS alternatives to that mature.

Interesting dynamics at play here

[benjamindees]

If Intel in any way restricts VxWorks for other architectures compared to any of Intel's, I think real time Linux work will surge.

I think so too. And since this seems to be the only card that Intel can play, I wonder what they're really up to. Because I don't think they will actually do that, since I don't think it really helps them.

It's in Intel's interest to support free operating systems, since the OS is a complementary good to the microprocessor. The availability of a functional free OS makes chips more valuable.

But it's not in Intel's interest to support a free OS that runs on other (cheaper) chipsets such as MIPS & ARM. So far they've done a good job of keeping Microsoft from supporting cheaper, lower-power chipsets, even as the low-power market has exploded. Linux on MIPS/ARM netbooks, on the other hand, might not be so easy to control.

So, WRT Wind River, what do you do if you're Intel? Do you support VxWorks since it doesn't compete with your desktop/laptop market, and hope that this will keep embedded Linux from making more headway on MIPS/ARM and scavenging your netbook profits? Do you support embedded Linux on x86 and hope that this will keep Linux pidgeon-holed in the embedded/geek/low-power market it currently occupies? Or do you do both, push VxWorks on MIPS/ARM and Linux on x86?

the pipes

[Joseph_Daniel_Zukige]

It ought to be clear by now.

INTEL wants to own your pipes.

The monopoly Microsoft has is trivial, compared to what INTEL is after.

Re:the pipes

[Anonymous Coward]

Mod parent up.

I don't know how people realize that Intel wants to control all your processors. At the high end, they have in practice killed Sparc and are in the process of kiling Power (Power7 will come out, I'm not sure about the follow-ups).

At the low end and embedded systems, Intel recently claimed they they were after MIPS, PowerPC and ARM. ARM will be the last to fall, it sells in too large volumes and a minimal ARM core (no FPU) has 1/10 the transistor count of a 386 and such a ridiculously better performance/Watt that the only way to kill it is by cutting the air (software) supply. In the space/radiation resistant application domain, a very good chip is the RAD750 (it is a G3 in Apple parlance, with larger geometries than the original G3), which has no x86 competitor (the G3 is a damned fine chip in that place).

After this but later, Intel's plan will be to go after AMD. They could do it now, but they need to give the impression that there is still some competition in the server/desktop market to avoid frightening customers who don't want to have all their eggs in Intel's basket.

After that, Intel will have to find a new angle of attack to protect their monopoly. Probably buying a few congress members to make it illegal to use non x86 processors for some unfathomable reason (saying that they more secure while they actually allow the government to spy on you).

Really, these days I'm more afraid of Intel's power than of Microsoft's. They have been pulling dirty tricks for a loooong time; for example Centrino was a way for them to enter the wireless market.

Of course, for PPC one serious problem was that Apple bought PASemi while IBM's plan was to let PASemi provide chips for Apple laptops (IBM wanted to have several PPC processors providers, each specialized in an area). Apple decided instead to become just another resale channel for Wintel clone hardware, making desktop/laptop market an effective monoculture. I used to buy Apple gear, only because it was a different platform; the strongest argument against buying it for me was that I had to pay for an OS that I would not use (of course I was not the typical Apple customer, neither do I think that Steve Jobs is god). PASemi's PA6T was (is?) a fantastic chip, with integrated chipset, give CoreDuo (not Core2) performance at Atom power level (at least with awful first generation Atom's chipset) when using 65nm design rules.

global warming

[Joseph_Daniel_Zukige]

is reminding us that we are that some other schmuck.

What comes around goes around. These are not the times for more power hungry chips, and the economic climate is not going to be forgiving of attempts to put x86-magnitude-or-greater-power chips in embedded stuff.

(Not to say that INTEL won't try.)

But, no, INTEL just wants to own your pipes.

proof of intent, mod parent up!

[Joseph_Daniel_Zukige]

But we should already know from recent history that INTEL wants to own your pipes.

certified, but on INTEL CPUs?

[Joseph_Daniel_Zukige]

I wonder, can they keep that certification on an x86?

von Neumann equivalence only works when you know that marketing can generate enough of that green fertilizer called funding to push the timing and memory limits back on the next generation.

speculating?

[Joseph_Daniel_Zukige]

Anyone who says that INTEL is not going to keep doing what it has been doing for the last ten+ years is just speculating.

We're not talking about punishment for things that haven't yet been done, Shill.

This sale should not go through unless INTEL signs some sort of hands-off agreement to allow Wind River to maintain equivalent support for all makers.

Or Wind Rivers should be required to sacrifice its certification.

Android

[aurasdoom]

They developed it. And some of the work was done in my hometown.

Wind River's horrible support?

[viralMeme]

"I work for an embedded systems manufacturer that switched to Windows Embedded as a result of Wind River's horrible support"

What was the name of the company and thank you for that free advert for 'Windows Embedded', the OS that brought viruses to the embedded sector.

"Wind River knew that lots of USB flash devices didn't work on their OS, and they wanted to charge for the development time to fix their bug AND then the OS upgrade once it was fixed"

I don't suppose you could produce any actual citations here, apart from some personal anecdotes.

ARM Cortex not high end?

[tepples]

The problem for my business is that we (like many embedded folks) are still doing good business with the PowerPC architecture [...] So I guess we high end embedded folks will have to jump on the Intel bandwagon.

Have you looked into ARM Cortex cores? Or do you mean something different by "high end" than I guessed?

How helpful are Intel to open source BIOS efforts?

AMD and VIA are listed on coreboot's vendor list. Intel is not.

Re:ARM Cortex not high end?

[amb5l]

By "high end" I mean 400MHz+, double precision floating point in hardware, AltiVec or equivalent SIMD unit. For example, something like the PA Semi dual core 2GHz 25W masterpiece that Apple has IMO treated the same way that the Taliban treated the statues of the Buddha.

The G2, G3, G4 and higher PowerPCs were always good in terms of performance from compiled C code, much better in terms of TDP than equivalents. You can buy industrial temp parts and cool them with a low profile heatsink. Their manufacturing lifetimes are good - 5-7 years (from Freescale).

You are right to mention AMD. I am getting more interested in them by the day - looking at the SB600 South Bridge for a new project right now. Not sure how well they will match Atom and/or Tolopai but their docs and Linux support are absolutely excellent.

GM+Firestone

[SgtChaireBourne]

...How does Intel plan to compete against $6 Arm chips? A smart meter has no need for a 64bit, fat, power hungry, hot 3Ghz pc type chip with no peripherals builtin...

By buying up the main player in that market and either shutting them down or shoehorning 64bit, fat, power hungry, hot 3Ghz pc type chips with no built-in peripherals into the market niche formerly occupied by $6 Arm chips. Worked for Firestone and General Motors. Worked for Microsoft.

A treacherous and base villain, indeed...

[argent]

The PL/M designers really knew what a low-level language should do.

If it wasn't for those meddling BASED variables, and their stupid dog.

You couldn't win. It made debugging other people's code a nightmare. I can't recall the number of times I discovered two based structures weren't QUITE identical, or alternatively they tried to avoid the problem by switching one base variable between two addresses and forgot to switch it at a critical point. And of course you could never depend on people calling their variables "something" and "something_base" so some apparently innocent assignment... AUGH... the memories.

Doesn't Wind River still own the FreeBSD assets

[Anonymous Coward]

after they bought out BSDi (who got 'em from walnut creek)

Maybe Intel will make them better.....

[jgeorger]

When I used VxWorks in 2007-08 I thought the licensing was horribly convoluted compared to when I used it back in 2000-01. I also think their documentation is relatively poor - at least finding relevant results in the Workbench search was a frustrating task.