Posted
by
ScuttleMonkey
on Friday June 05, 2009 @05:02PM
from the controlling-your-supply-lines dept.

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.'"

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.

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!!

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 softw

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

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.

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.

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).

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 nanosec

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.

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

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'.

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.

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.

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

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.

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 bigge

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,

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

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

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.

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.

...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 [hnn.us]. Worked for Microsoft.

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

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

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.

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

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 [speedgoat.ch] 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.

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.

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.

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.

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 em

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.

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 embed

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.

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.

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.

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.

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.

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 ex

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.

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 a

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

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.

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.

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 [wikimedia.org] 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 [gnuarm.com] 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.

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?

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.

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.

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...

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 vari

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.

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 anticompetit

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):

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 pro

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 signif

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 compel

Microsoft has started buying up biotech software companies (most recently Rosetta Biosoftware [genomeweb.com]). 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.

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.

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

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 [...] 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?

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' pri

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.

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.

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.

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...

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.

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.

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.