Slashdot Mirror

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.

<fanboi mode on>

When you use the word "platform" I'm assuming we're talking about the OS itself, i.e. excluding the applications. I'm not very familiar with MS Windows but I think Linux is doing excellent qua performance and stability, witness that it can be used for embedded applications (thanks a lot to FSF's gcc and binutils, methinks), can be used for real-time (with modifications, but I thought they are going to be folded into the mainline kernel), is quite secure (selinux) and most of all is usable for serious computing: how many of the top-500 supercomputers run a kind of Linux (on at least some of the nodes)? At first glance I'd say about 70%. How many run *any* special edition of MS Windows, or other non-unix-like OS? At first glance I'd say 0%. Can you imagine what a boost this is for e.g. HIV and cancer research (paragraph 3 on the page)? Now imagine the real-life effects on society, if research centers were forced to use Microsoft software. To how many CPUs does that scale? Let's not even get started on "Windows for Warships" (for brits and maybe argentinos: listen to their sci-fi radio show -- but I digress).

<fanboi mode off/>

Of course that doesn't imply Linux is also a good desktop platform but I can't at the moment think of any OS feature that is specific for desktop use and that Linux can't provide. I may be a fanboi but yes, I'd say "Linux is better than MS Windows" (njaa njaa njaa etc.; penile length etc.).

Now how this translates to "has the best applications" is a completely different matter, for which technical excellence is much less important than inertia, portability of existing software, existing market share, and marketing (Microsoft marketing budget for Windows XP was $ 1 000 000 000 BTW; I'd say that compensates a lot).

Yeah, you would never use linux. Instead, you would use a hard real time OS that are used heavily in jets or rockets.

"You are wrong. Linux is a hard realtime OS..."

"...RTLinuxPro is a tested and validated, hard real-time, POSIX operating system that runs embedded Linux as an application platform."

First off, you can go back to sleep in peace, for I am neither hurt nor feel inadequate (and if I did after reading your vomit-like prose, *that* would be definitely inadequate). And Linux is definitely not "my OS". I wonder what "owning an OS" would mean anyway...

Lol, yet another big troll like I love them, who doesn't know any better than insulting people and does not care to do some basic research on the topic... I should not even reply to this, but what the heck, this could at least help readers decide for themselves before giving the benefit of the doubt to the ruder one.

Just to name one company, which, by the way, is implanted worldwide: FSMLabs. Its activity revolves around RTLinux and RT-BSD. And you'd have found its name very quickly if you had cared to look at the site I mentioned a little bit. It even has the news about RTLinux the original author of this Slashdot article talks about... Anyway, even though RTLinux seems to be used most in research projects, it does have practical industrial and medical applications as well. Just take a look there, for instance: http://www.fsmlabs.com/case-studies.html

Of course, you may not feel the need to check this out, nor check out your own sources. Heck, you don't even feel compelled to post as anything else than an anonymous coward...

Doesn't RTLabs, claim to hold a "patent" on running the Linux Kernel as a 'task' under a 'real time' kernel?
http://www.fsmlabs.com/openpatentlicense.html
http://www.aero.polimi.it/~rtai/documentation/arti cles/moglen.html

To me the numbers announced are on par with hard real-time constraints

One would hope so, from a hard real-time OS.

In any case, hard real-time does not mean "really low latency." It means "failure to meet latency guarantee is fatal." You can't necessarily make a soft real-time system hard real-time just by speeding it up, particularly if there are unbounded waits involved.

A better and more thorough explanation.

http://www.fsmlabs.com/rtlinux-is-unfair-by-design .html

RTLinuxPro is used to control the laser beam positions, as well as to sample the output of measuring devices. At the core of the software is a kernel-side module that interrupts every 50 microsecond, samples new data, and timeshares the laser beam position. "If the computer failed to respond, for even a millisecond, then we would 'drop' the balls," explained Warshaw, "but RTLinuxPro is rock solid."

At the risk of sounding redundant, how is MontaVista's implementation significantly better or different from pre-existing real-time Linux interfaces, such as FSMLabs' RT Linux or DIAPM's RTAI?

Uhm, no. He has given an irrevocable, royalty-free licence for it's use in GPL'd software. Montavista RT Linux is GPL'd. Besides if you read the patent you will see that it is for something that has nothing to do with Montavista's code. Yodaiken's approach was to run the linux kernal as a process of a smaller realtime kernal, and it is that technique that he patented. Montavista is modifying the Linux kernal itself to be run-time, which is a much more difficult task, and would not infringe on this patent whatsoever.

I wish they'd use a different name for this. The product "RTLinux" already exists, and it's not related at all to what Montevista is doing. It's the microkernel based "run Linux as a thread" approach taken by Victor Yodaiken at FSMLabs. According to this article it was first released in 1995, predating the existence RTAI and Montavista by many years.

I suspect your Windows RT provider is in violation of the RT Linux patent.

FSMLabs, Inc owns the RT Linux patent. Timesys has unrelated technology based on patching the stock kernel, similar to what Montevista does but not as good.

Sorry to say but, you don't really understand the concept of real time.

First of all, an OS being RT has nothing to do with its size. It could be 18 terabytes, or 4 kilobytes and still qualify as real time, as long as it did a few things within certain thresholds.

To be a simplistic about it as possible, the only thing a real time operating system needs to do is to emphatically guarantee that it will respond to interrupts within a pre-determined amount of time. Even this time isn't exactly important, obviously it should be small, but as long as the time constant is known and guaranteed it qualifies as a real time operating system.

Real time linux is NOT "a true RTOS running linux as its lowest priority thread." That doesn't even make sense! You've obviously never done any kernel programming, or bothered to do any basic knowledge gathering on operating system design at all.

Note that several companies/vendors/instutions have provided incarnations of real time linux in the past (and currently). They do this by modifying the kernel source to make sure program ISR's get called within a set threshold. For example FSMLab's RTLinux has a worst case response rate of 12 microseconds.

Real time operating systems are not for everyone. Your system will be slower, but will feel more responsive. Strict server operating systems such as FreeBSD, and the Windows Server class OS's have a much higher ISR response rate. Windows Server is as high as 120 ms. This is done on purpose! They do it to get every bit of performance out of the server they can. Remember, more ISR calls means more interruptions in the CPU pipeline, and more instructions executed per second. On a pentium 4 with its huge pipeline, interrupts are disasterous to execution speed.

Personally I welcome a real time freely available linux kernel. I wouldn't mind sacrificing a little speed for real time operation. If you've ever used a real time operating system, you know what I mean. It's a great experience. But having said that, most people probably won't want that. And that's fine... but having the option is great.

Anyway... before you spout your mouth off and try to sound like you know what you're talking about... learn something first!

• Open Mosix Transparent process migration, intended for clustering.
• UML Self hosted virtual machines.
• Adeos Nanokernel.
• RTLinux Realtime microkernel/macrokernel work. Hell, it _is_ patented.
• ReiserFS Filesystem based on dancing trees, with a plugin archtecture.
• ZisoFS Transparant handling of compressed ISO9660 filesystems.
• Seperate LLC stack. Logical Link Control is handled by a single stack, rather than embeded into underlying protocols.
• InterMezzo Distributed filesystem, with network interrupt transparacy.

• Open Mosix Transparent process migration, intended for clustering.
• UML Self hosted virtual machines.
• Adeos Nanokernel.
• RTLinux Realtime microkernel/macrokernel work. Hell, it _is_ patented.
• ReiserFS Filesystem based on dancing trees, with a plugin archtecture.
• ZisoFS Transparant handling of compressed ISO9660 filesystems.
• Seperate LLC stack. Logical Link Control is handled by a single stack, rather than embeded into underlying protocols.
• InterMezzo Distributed filesystem, with network interrupt transparacy.

I think you will find that linux can be real time.

For that matter, it can also be a dog, or a salad. :)

As a regular EETimes reader, I have to agree with your post.

And... as a developer of and for embedded systems since 1986, I have a little insight on the issue. For the record, we use a proprietary OS in our (1) deeply embedded systems, ROM-DOS on some (2) lightweight PC platform embedded systems and Windows 2000+ on (3) MMI (Man Machine Interface) systems.

We have investigated using RTLinux in the first 2 cases and found the footprint/overhead to be far too great for item (1).

For item (2), we're not sure. The overhead and learning curve have kept us away for the time being, though we're interested in the capability advantage over ROM-DOS. Two very nice things about ROM-DOS: It can have a _very_ small footprint (as little as about 4K to 6K in ROM IIRC) and it's only $25 per runtime license (at least at our negotiated quantities).

For item 3 (yeah I know, it's not really an embedded system) we would love to use Linux (not necessarily RTLinux), but our customers demand Windows workability (desktop apps, Excel, Access, Oracle databases, etc).

So, in our outfit, we only use Linux (Red Hat) for a file server with Samba (to avoid a Windows Server license).

Name one truly new useful idea that has been created by the "open sourcers" that wasn't just a lame copy of some pre-existing proprietary product.

How about RTLinux, whose invention resulted in a U.S. patent? (The patent is licensed for use in any GPL program.)

FSMLabs RTLinuxPro building block is a tested and validated, hard real-time, POSIX operating system that runs Embedded Linux as an application platform. The RTCore real-time kernel at the heart of RTLinuxPro provides rock-solid, low microsecond worst case interrupt latency and scheduling jitter plus seamless access to Linux.

FSMLabs RTLinuxPro building block is a tested and validated, hard real-time, POSIX operating system that runs Embedded Linux as an application platform. The RTCore real-time kernel at the heart of RTLinuxPro provides rock-solid, low microsecond worst case interrupt latency and scheduling jitter plus seamless access to Linux.

I can't say much about LabView and CE.NET, but I do work with VxWorks and it is easy to develop for and has a reliable performance. On the other hand, you pay alot for the licenses. We're doing R&D stuff and we just can't keep VxWorks in our budget (we just want to upgrade our processor board and it would run us something like $7k-$10k). We're considering other OS options and I would be interested in any other observations you have. If I am correct, one of the things that is appealing about QNX is that for our R&D work the license would essentially be very cheap or free (I think you don't pay until you want to use it commercially, if I recall correctly).

A real time operating system is of great use in robotics.

I am actively working toward the completion of several autonomous systems.

RTEMS (by OAR) is available as well as RTLinux (by FSMLabs) for those interested in developing robotics software using GPL. Big boys buy vxWorks or something from WindRiver (Asimo by Honda).

Real time Linux does exactly this.

The real time kernel runs, and then runs the normal linux kernel under it.

To get access to the real time bits, you write kernel modules.

To communicate with your real time module, you use real time pipes (FIFOs)

I used this in my final year University Project, and it worked pretty well. We were doing AD/DA and fuzzy logic processing. All the fuzzy stuff was done in user land and the real time module did the AD/DA stuff as well as some other basic functions. (Like setting the output to all 0 if the input stream from the fuzzy logic failed)

Pretty neat stuff. Pity it seems that the above link wants money.

• WinCE .NET/WinXP Embedded XP Embedded is not practical for many applications, not the least of reasons for this being that it has no real time support and only runs on x86 processors. So if you want to go Windows and RT, you have to use WinCE
• Pricing Finding information about the price for WinCE is mildly difficult. I couldn't find any rates published on the web, but instead a list of suppliers. A called one and asked. About $2,663 for the original license and developer software wuth about $14 per copy of WinCE. I honestly doubt this would significantly impact the cost of any development.
• Development Code for WinCE generally has to be specially developed for WinCE; it can not be recycled from other Windows apps. Non-real time linux applications can normally be used directly in a linux RT environment.
• Worst-case latency WinCE apparently had a worst case latency of 30.8 microseconds on an x86 according to a somewhat dense report listed on Microsoft's website. Granted, an x86 is a somewhat unfair platform on which to test anything's latency. According to one maker of a real time linux system, latency is about 15 microseconds. The article for this story, however, finds a worst-case latency on a PowerPC to be on the order of .48 milliseconds or 480 microseconds. Ouch. That's pretty bad.

I mean, really, what was the last 'innovation' that occured in the *nix /world?

Jeez... are you serious? Come on, Unix is one of the more important platforms for research, if not the most important. It is flexible, it is reliable, most of the scientific community is familiar with it. And these days it is also free!

Just talking about Linux I could point you to Berlin, some guys with rather interesting ideas for building user interfaces. Or the Beowulf Project, for massive distributed computing. Or RTLinux (and KURT), for full featured real-time operating systems. How about ReiserFS, that takes database-like balanced trees to the filesystem level. Or SELinux, a research prototype of a high-security operating system.

And the list goes on and on (forgive me for not looking up links, go Google for these ones): SPIN (a dynamically extensible operating system written in Modula-3, runs on Linux), all the research stuff at Mosix (including distributed shared memory, grid management, network RAM and more), the Hello Project (an operating system in Standard ML atop Linux), all the emulation stuff which hardly needs to be introduced, and all the kernel work for supporting different processor architectures.

Also note BDS's Kame Project, an advanced implementation of IPV6 and IPSec; the evolutionary scheduler for Linux; the networking kernel stuff, including the QoS work; OpenBIOS; the User-mode Linux kernel. Look up also the "C10K problem" for an interesting paper on server performance, (and while you're on that, khttpd and TUX kernel webservers).

Unix gave you the Internet, for root's sake. How much more "innovative" does it needs to get?

Why not port it to the L4 microkernel? Then you can put it on pretty much any hardware to which L4 has been ported. (And L4 is not inefficient! I've seen a bloody quick Linux kernel built on top of it.)

. . . then you'll love this. It basically takes a few weblogs (aka blogs, journals, diaries, etc) and blends them together, albeit a little less randomly. Enjoy.

My company recently went down the path of evaluating several embedded linux suppliers, including Hard Hat Linux, LynuxWorks, RTLinux, and others. This evaluation was for an embedded communications platform.

There are many "real-world" issues that will arise when considering Linux instead of some of the more established embedded OS players (WindRiver/pSOS, Green Hills, Keil, QNX, et al -- see Embedded Systems Programming magazine for a pdf summary of embedded OS providers). These real-world issues, which will vary in importance among organizations for various reasons, include:

• Existing non-linux OS usage (e.g., WindRiver)
• Staff familiarity with Unix-like programming (most embedded developers know traditional RTOS-like architectures, not unix IPC methods or socket programming)
• Ease/difficulty with which already-written application software can migrate to a new OS
• OS support for preferred hardware devices (processor, communications peripherals, flash, etc. -- writing drivers from scratch isn't desirable)
• Internal corporate or organizational resistance to change (don't underestimate this one, folks!)
• Product life cycle phase
• Existing customer experience(s) with any previous OS-related behavior that may change under linux (customers like seeing behaviors they've seen before, not something new)
• Hard real-time versus soft real-time requirement(s)
• Communications stack and protocol requirements

In short, development in the embedded world tends to have many more complications associated with it. That's not necessarily bad -- in fact it often makes it more technically challenging and thus professionally satisfying -- it's just something that ought to be recognized, acknowledged, and taken into account when OS decisions are being made.

Andy

The license is here.

Bruce

P.S. This useless text added to pass the slashcode "postercomment compression filter", which seems to penalize brief replies.

2) Vast majority of companies needing something better than Windoze servers will find the current linux adequate.

3) IBM's goal in AIX was stability, not speed. And with all the bugs I've seen, they haven't done a very good job at that either.

Fact is, linux would outperform AIX on powerpc upto 8 cpus. Check this out for example. Indeed, open your eyes!, this is but one of dozens of demonstrations of the superiority of open-source software (linux/freebsd to commercial unix) I have come across. Linux outperforms solaris on sparc boxes, outperforms OSX on mac's, outperforms dgux on alphas, on and on.

--

--