Slashdot Mirror

Yes, clearly it would be complete lunacy to write video games in garbage-collected LISP, like Jak and Daxter, Ratchet and Clank and so on.

It is a misrepresentation to claim that those games were "written in LISP".

One can say that the "behavioral and game logic" processing was written in LISP, but that's a minor part of the overall software work- especially if you count it in terms of percentage of CPU usage. (Which, since you're talking about performance, is what actually matters)

Games have used LISP to control higher-level flow since the 80s, but to claim that they're written in LISP is no more accurate than saying Mozilla was written in XUL.

And those massive overheads ensure that we'll never see NASA using LISP to control space probes.

Another misrepresentation. Actually reading that article plainly says that the performance-critical elements of the space-probe were written in C.

Furthermore, you cannot use LISP as an example to defend all GC. LISP programs naturally give the compiler more information, allowing it to make better optimizations. Frequently it can eliminate the need to actually execute much of the GC at runtime (converting it into logically static or stack allocations). But with an imperative language like Java, the overall code is less analyzable, so the GC can't reach the same heights of performance.

So, no, we won't (realistically) be able to turn off the garbage collector, which means that we won't be able to write real-time programs, and it'll even be touchy writing programs, such as, oh, audio or video players, that require near real-time performance

Ah, the eternal anti-GC FUD of the ignorant.

Yes, clearly it would be complete lunacy to write video games in garbage-collected LISP, like Jak and Daxter, Ratchet and Clank and so on.

Obviously AT&T were insane to write their telephone exchange control software in garbage collected LISP.

And those massive overheads ensure that we'll never see NASA using LISP to control space probes.

... if laws were ever passed - by any government, anywhere - against Linux/OSS following a security breach or some such shit. And the thing is, it really wouldn't surprise me if it happenned.

On another note, this guy is a fool:

Now that foreign intelligence agencies and terrorists know that Linux is going to control our most advanced defense systems, they can use fake identities to contribute subversive software ... If Linux is compromised, our defenses could be disabled, spied upon or commandeered ... Everyday new code is added to Linux in Russia, China and elsewhere throughout the world. Everyday that code is incorporated into our command, control, communications and weapons systems. This must stop.

Well, honestly, what's to stop somebody terroristish from getting a job at Microsoft, hmm?

This is actually a lot more offensive than a stab at Linux. This is a stab at ALL Free/Open Source software. You really don't think he's just talking about the Kernel do you?

Calling it "Linux" is just a way for him to side-step the obvious positive connotations of the words "Free" and "Open". He's intentionally seeking to damage Linux. Why? He's a soul leeching asshole, that's why.

And if the U.S. Navy are in all honesty swayed by his words, then I really do worry about the future of Linux. At least, for you poor bastards in America.

When you buy a RTOS, you usually aren't getting compiled executable code. You usually get source code that you need to port to the hardware you are building.

Data sheets like this implies that Green Hills adheres to this common practice. So all the open source is more trustworthy than a black box arguments don't apply. Anyone who wishes to deploy a system based on Green Hills' RTOS can audit the code, it isn't hidden from them. Also, this PDF linked says:

INTEGRITY178B has been audited and approved by the FAA for DO178B Level A use.

One final argument is that an RTOS is usually very small. Their Velocity RTOS can run in 3KB of RAM. When the OS is stripped down to something that small, a full audit seems like a much less daunting task.

This implies that he isn't arguing security through obscurity. He is arguing for the cathedral approach vs. the bazaar. Don't get me wrong, he still is spreading FUD. Its just a different FUD than you think. He is ignoring the role that Linus Torvalds and some of his trusted lieutenants like Alan Cox play in planning a direction, vetting ideas, and protecting the stability of the code base. Patches don't just come out of the blue from anonymous sources and applied without any examination, no matter what Dan O'Dowd may think.

When you buy a RTOS, you usually aren't getting compiled executable code. You usually get source code that you need to port to the hardware you are building.

Data sheets like this implies that Green Hills adheres to this common practice. So all the open source is more trustworthy than a black box arguments don't apply. Anyone who wishes to deploy a system based on Green Hills' RTOS can audit the code, it isn't hidden from them. Also, this PDF linked says:

INTEGRITY178B has been audited and approved by the FAA for DO178B Level A use.

One final argument is that an RTOS is usually very small. Their Velocity RTOS can run in 3KB of RAM. When the OS is stripped down to something that small, a full audit seems like a much less daunting task.

This implies that he isn't arguing security through obscurity. He is arguing for the cathedral approach vs. the bazaar. Don't get me wrong, he still is spreading FUD. Its just a different FUD than you think. He is ignoring the role that Linus Torvalds and some of his trusted lieutenants like Alan Cox play in planning a direction, vetting ideas, and protecting the stability of the code base. Patches don't just come out of the blue from anonymous sources and applied without any examination, no matter what Dan O'Dowd may think.

When you buy a RTOS, you usually aren't getting compiled executable code. You usually get source code that you need to port to the hardware you are building.

Data sheets like this implies that Green Hills adheres to this common practice. So all the open source is more trustworthy than a black box arguments don't apply. Anyone who wishes to deploy a system based on Green Hills' RTOS can audit the code, it isn't hidden from them. Also, this PDF linked says:

INTEGRITY178B has been audited and approved by the FAA for DO178B Level A use.

One final argument is that an RTOS is usually very small. Their Velocity RTOS can run in 3KB of RAM. When the OS is stripped down to something that small, a full audit seems like a much less daunting task.

This implies that he isn't arguing security through obscurity. He is arguing for the cathedral approach vs. the bazaar. Don't get me wrong, he still is spreading FUD. Its just a different FUD than you think. He is ignoring the role that Linus Torvalds and some of his trusted lieutenants like Alan Cox play in planning a direction, vetting ideas, and protecting the stability of the code base. Patches don't just come out of the blue from anonymous sources and applied without any examination, no matter what Dan O'Dowd may think.

Actually, this is somewhat misleading. The top players listed are Microsoft (Windows CE), Wind River, Symbian, Palm. QNX, OSE, and Green Hills. But Microsoft, Symbian, and Palm are really selling into handheld devices, not hard real-time control. (The phone and PDA markets are much bigger than real time control, though.) Wind River's VRTX is the dominant player by a big margin, especially in low-end embedded control. QNX is next, and is usable on a broad range of platforms. Wind River is more of a specialist maker catering to the military Ada market.

Following these seven come LinuxWorks and MonteVista, who are moving up. These are the main Linux-based offerings.

Also confusing the issue is Windows XP Embedded, which is basically a Windows XP from which you can delete stuff you don't need. This sells more into point-of-sale applications than hard real time control.

Yeah but he's spewing this crap.. "Everyday new code is added to Linux in Russia, China and elsewhere throughout the world. Everyday that code is incorporated into our command, control, communications and weapons systems. This must stop." ... Cmon he has a vested interest... His own company puts out it's own RTOS Go to that link. Now. Read the TOP of the middle column "Real-Time Operating Systems Must be Highly Reliable"
Microsoft Windows, MacOS, Unix, and Linux often crash, lock up, or go crazy. They indicate this condition by displaying a sad face, an exploding bomb, a red X, a blue screen of death, or by simply refusing to respond to mouse-clicks or keyboard input.

This is FUD and he does have a vested interest.

You would have to look on ebay for 68k VxWorks board. Nobody has had a new design on 68k for a half a decade now. You are going to need a PowerPC running well over 200 MHz for that kind of response time.

If you really have 1 microsecond response time requirements, you're going to have to either find:

a) An RTOS that doesn't disable interrupts, or
b) Queue it up in hardware.

If you go A, that rules out QNX, and all other Linuxes, real-time or not.

Most companies go B, and then still use an RTOS with a good response time, since the RTOS still has to suck it out of the hardware before the queue fills up.

One RTOS, similar in architecture to QNX, that doesn't disable interrupts, is INTEGRITY

Sorry, thanks for the correction.

The systems I was thinking of were using WindRiver VxWorks and GreenHill Systems AdaMulti. The comments about support apply more-or-less to both.

This article is stupid...

Why? Because the author has HIS OWN operating system products and services at:

http://www.ghs.com/

In fact, this guy claims to be the authority on operating systems... Read on to learn just why you should choose their "INTEGRITY" product over Microsoft Windows, MacOS, Unix, and Linux, etc.

http://www.ghs.com/RTOSLeader.html

It's Andrew Tanenbaum all over again.

Glad we have an author here that can back his article up with facts, and not just crap.

This article is stupid...

Why? Because the author has HIS OWN operating system products and services at:

http://www.ghs.com/

In fact, this guy claims to be the authority on operating systems... Read on to learn just why you should choose their "INTEGRITY" product over Microsoft Windows, MacOS, Unix, and Linux, etc.

http://www.ghs.com/RTOSLeader.html

It's Andrew Tanenbaum all over again.

Glad we have an author here that can back his article up with facts, and not just crap.

Actually, Dan's company sells a Linux-hosted debugger and compiler for your Coldfire 5407 board, so you can pitch VisionClick and erase your Windows partition.

MULTI Debugger

Dan O'Dowd is President and chief executive officer of Green Hills Software,Inc. (Santa Barbara, Calif.)

So I Googled for Green Hills Software and found that Green Hills Software is "The Leader In
Real-Time Operating Systems". Their Products page lists several RTOS, development platforms, debuggers, compilers, etc.

So much for disclosure at EETimes...

The author of this "article" is the president and CEO of a company that sells a proprietary embedded Real-Time Operating System.

The guy that wrote the article...

Dan O'Dowd is President and chief executive officer of Green Hills Software,Inc. (Santa Barbara, Calif.)

Green Hills Software

Green Hills Software are a large RTOS manufacturer, so of course he is going to say that. Whether or not his statements are true or not I find it difficult to believe someone whose business relies on their own Proprietary OS.

They also have a not dissimilar marketing bumpf on their website

our product is so much better than everyone elses!

nick ...

The guy that wrote the article...

Dan O'Dowd is President and chief executive officer of Green Hills Software,Inc. (Santa Barbara, Calif.)

Green Hills Software

Green Hills Software are a large RTOS manufacturer, so of course he is going to say that. Whether or not his statements are true or not I find it difficult to believe someone whose business relies on their own Proprietary OS.

They also have a not dissimilar marketing bumpf on their website

our product is so much better than everyone elses!

nick ...

psst, embedded tools hosted on linux

and also develop for linux

Yes, I work for GHS. They didn't tell me to do this. I'm just out astroturfing of my own volition.

psst, embedded tools hosted on linux

and also develop for linux

Yes, I work for GHS. They didn't tell me to do this. I'm just out astroturfing of my own volition.

The company I work for sells a royalty-free RTOS. Pay, and you get the source. But I'm just a code monkey, talk to the sales guys.

The company I work for sells a royalty-free RTOS. Pay, and you get the source. But I'm just a code monkey, talk to the sales guys.

Green Hills has proposed an Embedded C++ standard which is essentially ANSI C++ without exception handling, mutiple inheritance, namespaces, run time type identification, templates, or virtual base classes. It does support the C++ inline keyword. So the compiler will, when possible, expand functions as macros. This results in faster performance at the expense of larger code space, but smaller stack space.

There are few problems porting code from C to C++. It's actually more difficult to port from pre- to post-ANSI C++, e.g. because of changes to the definition of the for statement. A C++ compiler is more type strict then a C compiler, meaning that more operations between different fundamental data types will be flagged as errors.

EC++ won't result in tremendous code bloat, either. About the same order of ANSI C. Plus if this system continues to evolve, one can take advantage of easier memory allocation with new and delete as opposed to malloc and free.

Granted the original post asked about inlining C functions. But moving to C++ gives one portability, since the inline keyword is part of the ANSI C++ standard.

Green Hills has proposed an Embedded C++ standard which is essentially ANSI C++ without exception handling, mutiple inheritance, namespaces, run time type identification, templates, or virtual base classes. It does support the C++ inline keyword. So the compiler will, when possible, expand functions as macros. This results in faster performance at the expense of larger code space, but smaller stack space.

There are few problems porting code from C to C++. It's actually more difficult to port from pre- to post-ANSI C++, e.g. because of changes to the definition of the for statement. A C++ compiler is more type strict then a C compiler, meaning that more operations between different fundamental data types will be flagged as errors.

EC++ won't result in tremendous code bloat, either. About the same order of ANSI C. Plus if this system continues to evolve, one can take advantage of easier memory allocation with new and delete as opposed to malloc and free.

Granted the original post asked about inlining C functions. But moving to C++ gives one portability, since the inline keyword is part of the ANSI C++ standard.

• The hardware supports carts up to 256 megabit (32mb) in size. There are flash carts which have more space, however, through software bank switching. No commercial ROM currently even hits the hardware size limit (manufactureing costs, it is widely believed, are to blame; it may be the case that Big N limits the available size of carts to both themselves and third parties)
  
• Yes, a linux distro would fit. No, it wouldn't be any fun without a keyboard. Yes, TCP/IP has already been done (a working webserver, which IIRC was even on SlashDot already. That's what caused me to try to post the homebrew dev scene the first time.)
  
• Emulators: there are about a dozen good ones around; many stick to VisualBoy Advance and Mappy Virtual Machine for development. VBA is often regarded as the best and fastest emulation, and Mappy is usually seen as having the best debugging tools (source-level breakpoints, register viewing, disassembly, viewers for most of the important chunks of RAM, etc). VBA interfaces with GNU debuggers, but I'm lazy, and haven't tried it.
  
• How good is the processor? Good enough to emulate an NES? Yes. In fact, there's a port of an emulator which runs NES binaries which were stapled onto the end of the emu binary out there already (it uses scaling and rotation to fit the otherwise too-large pictures; some detail is lost, so text often looks funny, etc). I have no linkage; sorry.
  
• To be specific, the processor is an ARM7 TDMI running at approx 16 mhz. Also, the screen does 60hz refreshes, is 240x160, and has a bitmapped 15bpp color mode (among other modes, including z-buffered modes). The programmer is afforded extreme memory mapping flexability by the hardware; it's more fun than a Rubix' Cube.
  
• Sorry - should have clarified - the ones I listed are all emulators for the GBA. Sorry, but not even remotely close. You didn't even get the popular ones. There's a pretty decent list here, at Zophar's Domain (a pretty good dev site)
  
• Descent is probably beyond the GBA's capabilities, since it uses arbitrarily-angled perspective-correct textured polygons, which are a fair bit harder to render on a low-end CPU (the GBA has a 16MHz ARM7 CPU).You should see some of the stuff that's going on. There are a number of fully textured 3D engines out there, one of which actually uses Descent levels as its examples! (I linked to another in my previous post which uses the quake level 1) A good example is the Raylight engine, though there are probably a dozen that I've seen (and a few proprietary, one of which I'm about halfway done writing :) )
  
• Hey, maybe we'll see Tux Racer for the GBA? That'd be tight. Quite possible. A racer wouldn't be difficult - the floor is a mode 7 S/R background, the sprites are prerendered, and there's enough VRAM that they don't need to be DMAed into place or anything (though people do that anyway, often enough [grins])
  
  Actually, how low-level is the API? Any chance someone could get Linux running on one of these babies?"The API" isn't. HAM has an engine, SGADE has an engine, there are others (I don't use them), and there are some commercial ones. But, here's the thing: the hardware does a lot of stuff. Sprites and backgrounds are supported in hardware, and do scaling and blending stuff, etc. It's just register tweakage. You don't really need an API.
  
  Big N does send an API of some sort, but I'm not a licensed developer, so I know dick about it. I'm told it's not that much of a difference - mostly just wrapper functions.
• well if you realyl want to consider assembler an API, that is your answer. ARM flavored assmebler. We're not stuck to Assembly. Though there are about six assemblers in common use (the one that gets most use as not just part of a toolchain seems to be GoldRoad, but because I don't use assembly except in-line, I have a biased perspective), there are also a buttload of C and C++ and so forth compilers. Because Gnu's Compiler Collection (GCC does not mean gnu's c compiler) works and is the common compiler for the homebrew platform, you also have access to *compiled* java, pascal, and I think Objective C and Forth, or Fortran, or something that starts with an F. Too lazy to go check. :)
  
  There are other compilers which can target the platform. Commercial people often use the ARM ADS or SDT. Other tools, like the Metaware toolchain and the Green Hills Optimizing Compiler (it's part of the name, not a parroted description, settle down) are commonly used because of their purported performance. Far from being an expert myself, I'll just point you at the Dhrystone that David Welch graciously presented to the community.
  
• I was planning on trying to develop something on my friends PS2 when he got the Linux kit. But since I actually own a GBA, this is a much more worthy project. More worthy, but more difficult. You'll want a flash cart and linker - the hardware is still the only perfect binary executor, though VBA is pretty impressive. All told, the PS2 Linux kit isn't more expensive, and it's hella more fun in the long run (Tux Racer on a console anyway, doncha know!)
  
• At about $70 (Game Boy Advanced, Amazon price [amazon.com]), you can create custom games, ports of other things, etc. This sounds to me like a much more practical thing to purchase to play around with the the PS2, which is in at least the $500 range to start hacking your own stuff for. You're counting just the hardware in one, but the hardware and the mod stuff in the other. $200 (ps2) + $200 (Linux kit) is $400. There was a recent price drop. $70 (AGB) + $40 (USB Flasher) + $15 (Power cable for flasher) + $10 (Parallel cord) + ~$100 (Average flash cart - price varies by size) = $235. Granted, a $175 price difference, but not what you implied. Also, a lot of us already have both. Then, the price of a homebrew kit actually weighs in the other direction, and the AGB is small and limiting enough that unless you really want to, it's a pain of a challenge.
  
• It would be interesting to know how many people will create practical, non-game applications. I know there are many non-game attachments, like a TV tuner and digital camera available for the unit. There are already music sequencers, methods of connecting it (realtime!) to a PC for chatter, MIDI sequencers, connections to serve as visualizers for various kinds of data collectors (think forest service), and a host of weird homebrew things that aren't exactly games. I expect quite a few more over time; I'm working on one in a half-assed way right now. Moreover, over time I expect level editors for at least homebrew games, and possibly for commercial games; would you call those applications?
  
• This would totally rule.. I'd love to see Nethack for the GB. I'm currently working on a Palm version, and of course, it'll work on Windows CE, but honestly, wouldn't Nethack be an awesome alternative to bejeweled on the bus?Shhh... Shen Mansell already has Moshpit put together, and there are three or four people already rumbling about alternatives on the list. Also, note that I'm on alt.games.roguelike.development making an ass of myself all the time... (For those who may be Ccurious, a BooFly is a creature which looks like Will Riker and which doesn't meet me for coffee at E3. Thpppbbt.)
  
• I think that companies like Nintendo and Sony and such should sell stipped down dev kits for like, say $50... including software you'd need and maybe a transfer cable. This gets kicked around a lot in the chatrooms and on the dev lists. The consensus seems to be that yeah, it'd be nice, but though a lot of people would really use it for what it was for, a whole lot of people would use it to pirate games, and besides, Big N's licensing fees per cart and hegemony on software support their business model, so they'd be hurting themselves anyway. In conclusion: not bloody likely.
  
• No disrespect to the great underground game hackers out there, but I don't think there is much of a risk of an uber fantastic game like Gran Tourismo 3 getting put out. Whereas art and sound resources usually make this true, with time, they actually often do. Take a look into the very mature NES or 2600 development scenes; you'll see things you'd never imagine possible (for instance, someone ported the Z-Machine interpreter Frotz to the GameBoy Advance as GBA Frotz, which seems impressive until you realize that the no$gmb guy, who I think is Martin Korth or something, and who really needs to put his damn name in his bio page, did it for the gameboy(!) in *8* *K* of RAM (far smaller than the real Z-Machine was supposed to be), and it works fine! Linkage
  
  Homebrew developers thrive on being told it can't be done. The more you tell them they can't do commercial stuff, the more you're going to see commercial stuff done. That's what got me started. :)
  
• Yes, Craig Rothwell is reliable (someone else's post). Also, though Lik-Sang is reliable (that's where I got mine), right now cyustoms is banning the import of these, and so you won't get one even if lik-sang mails it to you. Craig Rothwell currently goes under their radar, but don't try him if you're seeing this post a month or so old - things may have changed (they often do, unfortunately). The best thing to do is to go to the Yahoo! Group and ask; you'll get a lot of replies in 48 hours.
  
• I know that the Game Cube can use GBA as controllers. I am not sure what the interface protocol is like, though. Do you think that it might be possible to make custom GBA carts for Cube games, that provide enhancements (cheats, etc) to a game playing on the Cube? No. The GC uses half-size DVD discs which are difficult to burn and which have not yet had their protections cracked or circumvented. Things may change later.
  
• So does this mean that with the ROMS that are for the SNES, we could somehow make our own port of say "Secret of Mana" (or some other SNES title) for the GBA? That would be awesome! Though probably not awesome enough for me to spare time to learn this. If you're dedicated. you need to scale a lot of graphics down; the sound hardware is completely different, so the audio stuff will need to be wholly rewritten. There are odd considerations due to the different CPUs. But, yeah, many people have been porting SNES and Genesis games commercially; I don't see why a team of amateurs with lots of time and skill couldn't do the same. It's not easy, though, mind you.
  
  This is our world now...the world of the electron and the switch, the beauty of the baud. Pre-chewed pieces of pap! And shouldn't be teaching anyway!!@!3T1!! r00l!
  
  cough Sorry. Old habits die hard.
  

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

DS1's AI ran on more than "just" Suns. The probe itself runs VxWorks on a rad-hardened RS6000 (PowerPC) at the awesome speed of 25 MHz (see here).

Development of the planning/scheduling was done on Suns and Power Macs, using two different vendors' Common Lisp implementations (see here for a message from one of the implementors). During development, NASA management decided there were too many programming languages flying in DS1, so they decided to drop one of C, C++, or Lisp. C++ lost, but is being wedged back in for political reasons.

The planner was only given 10% of the CPU, which meant DS1 was doing real-world AI at 2 MHz (!).

#incldue
#include <rants.h>
#incldue <clues.h>

Just to be absolutely clear about what I'm saying, in my opinion the "big three" embedded OSes are, at the moment: (1) VxWorks, (2) Embedded Linux, (3) Embedded Windows -- or (1) VxWorks, (2) Embedded Windows, (3) Embedded Linux -- depending on how you count.

I guess he's never heard of/used QNX, ChorusOS Nucleus, or ThreadX. I did however like the gadgets, but taking a look at the last week, with all the Linux related companies going to the dogs, and 4 distributions going "kaput" within less than 6 months time, I would be looking at other alternatives to Linux, especially if my business were going to depend on them.

© Gbonics changing the futurismisms of vocabularities worldomwide

After using assorted Linux distributions, FreeBSD, OpenBSD, NetBSD, Solaris, and other operating systems for the past few years, I've started tinkering with RTOS' (Real Time Operating Systems) such as QNX, dabbled with ChorusOS for a month or two, and have looked into a few others (Nucleus, ThreadX).

Some RTOS' can be used, for a typical production server running http, mail, etc, often faster and more productive than most other OS', and I'm sure there has to be advocates of RTOS' with a comment or two. There are benefits to making a switch or are RTOS' a high tech OS solely geared for companies needing higher computing standards, but I can see many here trying to advocate Linux, Linux, and oh yea Linux, and I'm sure there are those who will mod unfairly. whatever

Don't get them confused, a lot of THESE OS's are not free to download, and they're not the same as using redcrap, or dumbian progeny. The article itself though didn't mention that some of these are pricey OS' it seems like they just jumped on another "Oh ... OpenSource" for attention.

Is our soldiers forthcoming homecoming?

As far as I understand vxWorks is basically the industry leader in RTOS's,

Operating systems such as z/OS fall in place where others aren't neccessarily useful. The OS is geared mainly (or it seems) for high powered computing, something along the lines like a huge mainframe, which OS' like Linux, or the BSD's cannot be trusted to support.

Not to start a flamewar of any kind but there isn't a company I can think of who would dish out cash for some huge mainframe-like computer solely to let one of their geeks toy with, and install anything other than something proven (or semi-proven via marketing.)

Sure it may be biased on the geek level to discriminate against other Unixes but the fact remains money talks, and the companies using this OS and the servers they run on would be insane to let it happen at this point especially when Linux in my opinion is in such a disarray of distro's. there are no standards on many things, etc.

Take a look at Motorola, they're power computing comes in the form of QNX, ChorusOS, Onea OSE, Integrity, ThreadX, for many high powered stuff. Are these less of an OS than Linux or any other open source based OS out there because its not "geek chic?" Hell no.

AntiSpam Info

Operating systems such as z/OS fall in place where others aren't neccessarily useful. The OS is geared mainly (or it seems) for high powered computing, something along the lines like a huge mainframe, which OS' like Linux, or the BSD's cannot be trusted to support.

Not to start a flamewar of any kind but there isn't a company I can think of who would dish out cash for some huge mainframe-like computer solely to let one of their geeks toy with, and install anything other than something proven (or semi-proven via marketing.)

Sure it may be biased on the geek level to discriminate against other Unixes but the fact remains money talks, and the companies using this OS and the servers they run on would be insane to let it happen at this point especially when Linux in my opinion is in such a disarray of distro's. there are no standards on many things, etc.

Take a look at Motorola, they're power computing comes in the form of QNX, ChorusOS, Onea OSE, Integrity, ThreadX, for many high powered stuff. Are these less of an OS than Linux or any other open source based OS out there because its not "geek chic?" Hell no.

AntiSpam Info

The article states "The real-time portions of a system run in kernel space in real-time Linux. Therefore, no memory protection can be offered. ... (Note: this disadvantage also exists for all other real-time OSes as well...)

Is this really true? I'm no expert on real time operating systems, but I do know that several claim to have some memory protection, including QNX (highly recommended, btw) and Integrity, which I haven't tried. Perhaps I'm missing something, or is this report over-generalizing?
---