Slashdot Log In
QNX: When an OS Really, Really Has to Work
Posted by
michael
on Sun Jun 15, 2003 07:20 PM
from the abnormal-termination dept.
from the abnormal-termination dept.
An anonymous reader writes "Fortune has this article about how QNX's OS has found a niche and is doing well. Especially after 1996 when Microsoft executives said they would crush them in 2 years. When your software absolutely positively needs to work!"
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
QNX rules (Score:5, Informative)
QNX is designed like a modern os should be. It's straigt out of an Operating Systems 101 textbook.
If only Linux had more of QNX's design niceties and robustness.
Too bad the Amiga/QNX desktop thing never became a big hit.
Re:QNX rules (Score:5, Insightful)
Microkernels have gotten a bad reputation because Mach/Hurd, for one reason or another didn't deliver. But that doesn't mean the approach itself is flawed.
Traditional monolithic kernels like Linux (and UNIX and NT/XP--and don't try pretending that NT/XP is a "microkernel") are appealing for budding operating system projects because it's easy to hack something together quickly. But those architectures don't hold up in the long run. You can see the same in ecology: fast growing, non-native plants often displace native plants quickly, but in the end, they die because they aren't well adapted to the long-term conditions.
Well, maybe if SCO wins, we can look on the bright side: it will finally get Linux out of its rut and create more opportunities for other kernels. Don't get me wrong: like everybody else, I'd much rather not change from the Linux kernel, but if I do have to change, I don't view it as all bad. (Of course, I don't think SCO has any legal grounds at all, but that is probably not related to whether they can win.)
Parent
Re:QNX rules (Score:5, Insightful)
A lot of the decision depends on the architecture involved. I hope someone more knowledgable than myself will comment on this, but as far as I know, the reason BeOS started to implement networking into the main kernel instead of making it a microkernel "server" was because the x86 architecture is much slower in switching between sub-functions than the PowerPC was (I've read 10 times slower but can't remember the source).
The two monolithic operating systems you criticize are both i386-centric, so a true microkernel probably wouldn't be such a hot idea.
QNX's design is great for certain applications but not all. I looked into it for an intel based SMP homebrewed but critical (as in the systems behind it cost over $1 million) firewall and decided a more traditional i386 operating system would be better.
I know you're not a culprit here, but being a fanboy for one design approach or another is just bad engineering sense. It's something I see all the time and I'd wish they'd teach a lot more critical thinking skills at the high school level because of it.
Parent
Re:QNX rules (Score:5, Insightful)
10 different ones passing messages to each other are clearly cleaner and often more efficient as well. It's the UNIX way. I mean, do you run one command line interface that has all programs linked into it, or do you run a command line shell that invokes programs as separate processes?
The detailed Mach approach itself is broken--far too complex and messy. But you can view Plan 9 as a kind of "microkernel"; that would be a UNIX-style "microkernel". And, of course, QNX is successful as well. The original Amiga OS was a kind of microkernel and worked like a charm.
Note that you can't compare Linux to the original UNIX design. The original UNIX design was kept religiously simple: one file system, a few machine types, etc. Linux, on the other hand, has zillions of modules and features.
So far, it didn't work for any real systems.
It has worked in plenty of real systems. But kludgy monolithic kernels simply have an easier time to attract developers initially--that's why systems like Linux and Windows have managed to grab a lot of market share in the OS area.
Parent
Re:QNX rules (Score:5, Insightful)
Well, first of all, a microkernel architecture doesn't require any address translation or additional overhead at all; there have been microkernels that run without any MMU at all. And QNX seems competitively fast.
But let's say, just for the sake of argument, there were overhead associated with it. I would rather have a reliable if slower 2.6 or 3.0 kernel now with the features I need than see the 2.4 kernel limp along from bug regression to bug regression.
Even QNX has faculties for 'lightweight processes' that have independant stacks and a common global data sandbox.
Which only goes to show what I was saying: a microkernel architecture does not require that every single little OS process runs in a separate address space. In fact, a good design would let you decide on the fly whether to isolate a process (and pay the overhead) or run the process in a global address space.
Parent
Re:QNX rules (Score:5, Insightful)
I agree with you that address translation is a problem, however, this is mostly a problem with the x86 architecture. The x86 flushes the TLB on every address space switch. If we had a decent tagged TLB, this wouldn't be a problem. Indeed, it isn't a problem on most architectures that QNX is asked to run on. Repeat until enlightened: Context switching is only expensive on the x86 architecture.
The "additional costs" for IPC are mostly an illusion, since we're talking about IPC which is tightly integrated with the kernel, not SysV IPC. Yes, it costs to copy memory, but the cost is there in Linux too; it's just a user space -> kernel space copy rather than a user space -> user space copy.
Having said that, it may be possible to write an OS for which the context switching is much cheaper. L4 uses a neat scheme where a small part of everyone's address space is allocated to other small processes, so context switching only requires a change of segment, rather than a change of address space mapping. IPC is very fast under L4 if you're doing it with a small address space task.
I've wondered that myself. I can only conclude that these projects are either experiments which accidentally escaped the lab, or the hackers who wrote them have no sense of sound software engineering principles.
Parent
Pronouciation? (Score:4, Interesting)
Re:Pronouciation? (Score:5, Informative)
QNX pronounced like "queue nicks" is a commercial operating system that runs on intel processors, mainly the 386, 486, and Pentium, and their clones, such as MD, Nat Semiconductor, Cyrix, and SGS Thompson.
The simple answer is that QNX is a realtime, microkernel, preemptive, prioritized, message passing, network distributed, multitasking, multiuser, fault tolerant operating system. This is a "true" microkernel, with the largest QNX kernel to date being less than 10K.
The QNX/Neutrino microkernel is about 32K, but can run standalone, something the QNX4 microkernel cannot. The QNX/Neutrino microkernel + process manager is about 64K, which is half the size of the QNX4 microkernel + process manager, and it does more.
Parent
QNX NC (Score:5, Informative)
The QNX floppy demo was for QNX4, while the CD is QNX 6, a vastly improved OS. The floppy can still be found but its not half the OS that QNX 6 is.
QNX is POSIX compliant and can run all Unix utilities, Besides the Photon GUI, you can run various window managers. You can run X Windows apps seemlessly rootless using XPhoton. Already Gimp, AbiWord and others have been ported. There are many native apps as well, irc clients, a mozilla and opera port. Worth a try, at least!
QNX isn't the easiest OS to use (try getting a USB printer to work and you'll find a new definition of pain and suffering) but it is rock solid and fun to geek with.
Speaking of live CDs (Score:4, Informative)
Parent
QNX is a nice RT OS (Score:4, Informative)
I remember using qnx in a Canadian Highschool (Score:5, Interesting)
Anyway I took 2 programming courses in basic and pascal. The labs used some strange Unisys dumb terminals connected to a builky black looking box. Very XT-ish and looked like it was from the early to mid 80's. Anyway it ran a no name OS called QNX. I believe it was powered by a 286 or 6800 with about 4 megs of ram for all 20 students. It had no display but a teletype printer where we would print out our programs. It handled quite well for such a limited server.
Its Very old and I remember a 1984 copyright that showed up whenever I booted. I had no idea it was a unixlike system.
It seemed just as fast as a standalone 286 and it had a "$" as the prompt sign with a strange scripting system. I considered it underpowered and old but was supprised by the included gcc, sed, gmake, and other utilities and powerfull scripting. It had some nice api's for 2d graphics displays.
Anyway 2 years later I wanted to try Unix after playing with NT 4 when after it just came out. I tried Caldera (shudder )Linux and I was supprised that I have been running gnu and unix all long. The shell scripts and everything were identical and I have been using Unix without even knowing it.
Linux felt quite old without X in the old days( before kde was stable and gnome was around). But I have qnx running on that horribly ancient system to thank.
Re:I remember using qnx in a Canadian Highschool (Score:5, Informative)
The systems used to be popular in Canadian schools because the OS was developed in Canada, as were most of the tools and applications (which were primarily by Watcom). Plus students generally weren't going to be able to install whatever gunk they brought from their DOS machines at home, nor were DOS based virii any sort of threat to these systems. They were easy to manage and maintain, and were good for teaching programming basics.
Do you prefer todays alternative of brainwashing students in The Microsoft Way(tm)?
Yaz.
Parent
I read slashdot using QNX (Score:5, Funny)
Wait until... (Score:5, Funny)
Bullet Proof (Score:4, Informative)
As a delighted user has put it, "The only way to make this software malfunction is to fire a bullet into the computer running it."
Didn't Tandem actually run an ad claiming that if you shot a bullet into their servers they would keep running?
Re:Bullet Proof (Score:5, Funny)
About a year ago, I was called out to do field service. When I got to the lady's house and was let in, the first thing I noticed was the smell of gunpowder. The second, the double barreled 12-gauge shotgun lying on the couch. Third, the big gaping hole in the side of her computer. (It was one of those Macs where the CPU and monitor are in the same housing.)
I looked at her. She was a little grey haired woman, around 60 or so. Had she? Not possible. Still, I had to ask.
I mumbled something about not being a Mac tech and told her I would send one out as soon as I could. Then I burned rubber out of there.
About a month later, my boss called me in; he had the woman on hold. She had apparently complained that I was not competent and that I had lied when I said I would send out a competent Mac tech -- or perhaps I just hadn't been able to find anyone competent working for us. I filled him in. He paused for a second, picked up the phone, and said, "Ma'am? Did you put a shotshell into your computer? ... Uh huh...I'm sorry, ma'am, we really can't...well, no.... I'll try to send one out.... Nice doing business with you...." He hung up, looked at me, and said, "You think any of our Mac techs will go?" I shook my head. "Me neither."
We heard from her again last week, when my boss told me that the woman had called up to cuss me out, saying not only was I a "young whippersnapper" but also a liar, since one of our competitors had fixed her computer just fine, even fixing the little scratches and stuff on the monitor glass. That sounded fishy, so I went over and talked with the techs. After a case of canned drinks and a few bags of junk food, I wormed the whole story out of them. Apparently, about the only salvagable part was the hard drive (which the buckshot had missed), so they took it out, went out and bought a whole new computer, slapped the hard drive in, and presented it to the lady as her repaired computer -- of course charging her an arm and a leg.
Parent
A fire-and-forget controller... (Score:5, Interesting)
People in white lab coats are the primary cause of cancer in rats.
Qnx: Microkernel, real-time, small, and fast (Score:5, Interesting)
Later, the BBS was upgraded to an 8 MHz AT clone and 2400 baud modems. Still, smooth as silk, even at capacity.
The BBS never crashed once and always ran smooth.
I can't say much about today's Qnx, because I haven't used it. But yesterday's Qnx displayed a level of quality I've never seen in another OS. If I ever find myself needing medical attention, I usre as hell hope the OS running under the hood is Qnx. There is nothing more reliable.
-Teckla
QNX reliability (Score:5, Interesting)
One November a customer called and complained that they were not getting their log files. These log files were written to a ftp shared directory. One of my coworkers logged into the robot via modem and started looking around. When he tried to get a directory listing he got an Input/Output error instead. After a little digging around in the logs in ram he determined the hard drive had died. The most interesting thjing is that the hard drive had apparently died in August. The robot had run continually from August to November and the only trace of any problems was the lack of log files. There was no other permament storage in the system. The OS, UI and all the robot applications were running in RAM for 3 months without problems.
I Love QNX
Imagine........ (Score:4, Funny)
Doh! Wait! QNX doesn't do that.
Never mind.
Re:Imagine........ (Score:5, Informative)
QNX's architecture is very much oriented towards message passing, and every piece of hardware is abstracted, even processors. This means you can have a lot of CPUs or machines working on a network running your applications and the load will be evenly distributed, without you having to specifically code your applications. Your only limit is your network performance and latency.
Hell, you'd need to code your application with special system calls for it to know it's not running locally!
I had a wonderful experience with QNX4 a couple of years ago. QNX4 back then didn't have SMP support, but I called QNX Support and they told me how to run one kernel on each CPU of my server and Voila! I had the equivalent of a cluster in one box. Performance was very good, too, context switching was not even worth to measure.
QNX Neutrino is even more powerful, and now it supports SMP... Beowulf clusters are sooo 1999...
Parent
If the Air-Control Syetems ran MS software... (Score:5, Funny)
Air Traffic Boss: How's it going?
Air Traffic Controller: Fine.
Boss: What's That? (Points to blue screen)
Controller: Oh, that happens when we try to track more than three planes.
Boss: Why does it do that?
Controller: We only purchased a 3-plane license. If we try to track 4, Palladium kicks in, and the whole thing locks up.
Boss: Doesn't that sound, you know, dangerous?
Controller: Not as dangerous as this! (plays an illegal mp3, sirens blow, and all machines are shut down, power is cut off, forcing runway lights to turn off, while planes crash like crazy.)
Message passing is basic (Score:5, Informative)
The key idea behind QNX is that it does interprocess message passing between protected-mode processes really, really well. Everything else is built on top of that. In most other OSs, interprocess communication was an afterthought, and it shows. Typically, message passing is built on top of the I/O system. In QNX, the I/O system is built on top of message passing.
The QNX kernel is very stable because it only does a few basic things, and those few things are heavily exercised and well debugged. New system calls are very rarely added. New features go in new user processes.
Development on QNX is straightforward. The whole GNU command-line toolset is available. The API is Posix-compatible. The QNX calls are well integrated with the Posix calls; there aren't separate "Posix threads", like some other OSs.
QNX is the last OS vendor that competes commercially with Microsoft on x86 desktop machines. The fact that they're still alive says something.
You can run QNX as a desktop OS, and I have a machine on my desk that does so. But there's not much desktop-type software. Mozila, AbiWord, and Eclipse have been ported, but that's about it for graphical desktop applications. OpenOffice has not been ported, and it would be a huge win if somebody did that.
QNX has its own windowing system, Photon, which is like nothing else out there. It's quite good, and much cleaner than most windowing systems. But it's different.
Hardware support is spotty. Graphics support is mostly for obsolete boards, although anything that supports VGA or VESA modes will work. (NVidia refuses to release enough information to allow development of QNX drivers.) USB 1 is supported, but only for a few peripherals. USB 2 is not, nor is FireWire. (I've been writing FireWire camera support.)
QNX runs our robot vehicle for the DARPA Grand Challenge. [overbot.com] It has to work.
Alternative sources (Score:5, Informative)
Planet Mirror [planetmirror.com.au].
A couple of different ISOs are offered - one with all the packages, and a basic ISO. It's able to install within a Windows partition, apparently.
Re:um (Score:4, Insightful)
QNX is a great operating system, but it's a much different market. It's not made for PCs, it's made for embedded, real time applications. You'll find QNX in routers, you'll find it in medical devices, and you'll find it in nuclear power plants.
What you won't find in QNX is USB support, drivers for a Sound Blaster 16, or Accelerated 3D drivers.
It's a great operating system, but comparing it to things like Windows, Mac OS, Linux, FreeBSD, or even Solaris and AIX are silly. QNX isn't designed to have any frills: it manages resources, incredibly well, and that's it. It doens't do complex scheduling, it doesn't do advanced 3d tricks, and it's not going to do much with the latest firewire hard drives. It will, however, guide a laser over someone's eye for Lasik and other such procedures a thousand times a year without a glitch.
Parent
Re:um (Score:5, Informative)
The QNX Momentics Development Suite Non-Commercial (NC) edition gives you a full self-hosted development environment with the QNX Neutrino RTOS, plus tools, device driver kits, a desktop class browser, and more.
QNX Neutrino RTOS v 6.2.1
* Symmetric Multiprocessing (SMP)
* QNX Photon microGUI
* Hundreds of POSIX, UNIX, and QNX utilities
* Distributed processing
Self-hosted C/C++ development environment for x86 & ARM development only. Reference Platform:
* iPAQ (ARM development target)
Driver Development Kits (DDKs)
Libraries and Tools:
* ANSI C, GCC v2.95x optimizing compiler, GDB 5.x, Binutils 2.10.x
Parent
Re:um (Score:5, Informative)
Sorry, wrong. QNX USB support [qnx.com].
Parent
ehm? (Score:5, Informative)
Parent
Re:um (Score:5, Informative)
It's not made for PCs
You are mistaken, I'm afraid. See below.
What you won't find in QNX is USB support
QNX most defiantly has USB support, as I have a Audrey that has it sitting in front of me.
As for the "not meant for PCs", QNX runs extremely well on a PC, with just about everything you need.
QNX also has 3d support, as evidenced in the FAQ here [qnx.com].
To quote:
Photon supports rapid animation, 3D graphics, and realtime trending
through off-screen memory, bypass mode, video overlay, and other
advanced features.
QNX also supports the following:
* XScale processors and boards
* >4G address spaces on PowerPC boards
* more video hardware
* UDMA 66 chipset (high-speed disk interface)
* Enhanced TCP/IP stack - includes IPv4, Unix domain sockets, multicast support
* NFS v3
* Resource database for better device mapping
* Bi-directional pipes
* Block driver DMA
* Enhanced support for shared memory, with full support for creation mode and ownership information
And SMP, which OpenBSD still hasn't included, for instance.
I recommend that anyone who is interested download the free ISO and install it on
a spare computer you may have laying around and see for yourself. Get it here [qnx.com].
Don't rely on
SealBeater
Parent
Re:you are using it? (Score:4, Interesting)
Or you have tried it as a "normal" desktop type OS? Have any thoughts on it if
so?
Yea, I tried it for a while, couple of weeks or so, just playing around with it. I
thought it was pretty cool, it had a ports like software installation program,
you clicked on what you wanted to install, and it took care of dependancies and
the like, very nice browser, supported everything my test box had (Dell GX110)
with an i810 video card. No problems, Solaris x86 gave me much more. I
thought it was pretty cool. Felt *nixy, gui-wise, all in all, not bad at all.
I have it running on a Audrey, as I said earlier, and I like it.
SealBeater
Parent
Re:QNX is still around? (Score:4, Informative)
Parent
QNX Floppy Challenge (Score:5, Informative)
Parent
Re:QNX is still around? (Score:5, Informative)
But their floppy was phenomenally useful - on a site of several thousand people, I used to use it in preference to windows to troubleshoot network equipment - until the company stopped to buy floppy drives for their workstations by default...
Parent
Re:A couple things (Score:5, Insightful)
Ummm...it is the operating system that matters -- the O.S. is the software that controls the hardware. Just like software on a PC can make the hardware do things it ought not do, software can make a precision laser be off by 1/100 of a millimeter, destroying someone's retina in the process.
Parent
Re:A couple things (Score:5, Informative)
That's why LASIK systems don't run on WinCE.
Parent
Re:A couple things (Score:5, Informative)
BZZZZZT! Wrong answer. Evidence shows that testing cannot be trusted to reveal all defects. No matter how much you test a system, there is still a very significant risk that it will contain a defect. That's why practically all critical systems use a PROCESS to prevent errors from getting in. That's why the military forces Ada for all systems, why off-the-shelf components aren't used for life-support systems, and why MIL specs are not just based on reliability tests. Since neither Linux nor WinCE underwent any type of certification, code audit, or specialized quality-control processes, they cannot be trusted despite what tests might indicate.
Parent
Re:A couple things (Score:5, Funny)
Parent
Interesting? (Score:5, Informative)
QNX is for those times when "Good enough" isn't good enough. An associate of mine used to run the network for a major medical responce company. They used to count downtime in the number of people dead due directly to the lack of a network. If you accidentally pulled a plug on the way to lunch, 4 people would be dead because of you.
Their uptime target was 24-7-365-20. There was no such thing as "Good Enough."
Ideally, any OS should do. It should be a flawlessly written middleman layer between flawlessly written hardware and flawlessly written software. But we all know that software is flawed, hardware drivers are flawed, and OS's are flawed. When WinCE comes across a problem in the kernel, it panics and comes crashing down. When Linux comes across a problem in the kernel, it panics and comes down. According to this article, when QNX comes across a problem in the kernel, it cuts off, shuts down, and reboots just the offending section, cutting downtime from 30 seconds to microseconds. That's pretty darned cool.
Sure, the foundation of your house is just the interface between the ground and your software creation. But if your foundation is bad, no matter how much support the system integrator can provide, your house won't stay up for long. If you're building apartments, that might not matter. If you're building a hospital, your negligence could cost lives.
And by the way, it's the software that controls the grinding of the lens. If the hardware knew how to grind a lens already, it wouldn't have electronics. The software controls the OS, the OS controls the hardware. Your Software->OS->Hardware diagram should have proven to you how important it is to have a reliable OS in the middle.
Parent
Re:A couple things (Score:5, Interesting)
Only partly true.
The operating system provides the framework within which the software works. For things like a desktop where things like the occasional 1/2 second ~ 3second delay isn't fatal, and blue-screening a couple of times a week (or day, as the case may be) is mostly just an annoyance, then yes -- the two are pretty much equal.
For things like nuclear reactor control, precision robotics and medical instruments, where a 1 miliseond (much less 1 second) hickup can result in death and destruction. they are most definitely not equal. The hard realtime in Windows is, well, not that hard. It's pretty easy to get Windows to lock up for the better part of a second. Linus is only slightly better -- but only when you install the realtime patches.
As far as reliability, Microsoft is still proud of being able to (sometimes) run for 3 months at a shot without rebooting. Linux has a much better history, but it's still far from bulletproof. As far as I know, neither one is certified to run things like nuclear reactors and medical equipment.
The Navy's decicision to use Windows to run their battleships has been the source of some amusement -- having managed to bluescreen one ship and leaving it 'dead in the water'. As to whether this could happen during a battle, converting 'dead in the water' to 'dead and in the water' is a matter of conjecture. All I can say with certainty is that I'm glad I'm not a US sailor.
Parent
Re:Inaccurate microkernel claims? (Score:5, Informative)
Parent
Re:Inaccurate microkernel claims? (Score:4, Interesting)
Sorta like Linux isn't really monolithic, since you can load kernel modules.
The NT kernel is extremely stable. Typically, drivers are what bring a 2K/XP/server system down. In fact, that is all I've ever seen bring a system down. QNX is unique in that it can restart any system component that has failed, and it isolates everything a lot more. Make no mistake - that is slower than having drivers run in kernel space, but it has its benefits. The microkernel can axe drivers and restart them in realtime, something that cannot be done for NT's kernel mode drivers (although programs and other drivers can be dynamically loaded and unloaded.)
And yes, the display driver was also moved into kernel land for NT4 and higher. Trust me - you would NOT be happy with 3d game performance or GUI performance if it were not (although some may argue for the server version that would be a better idea, but honestly my servers run headless so I don't care.)
Parent
Re:We Will Crush You? (Score:5, Funny)
Parent
Re:We Will Crush You? (Score:4, Informative)
>Waiting for the inevitable joke comparing Bill Gates to
>Khrushchev...
who actually said "my was pokhoronim", which means "we will bury you". Which was not a threat. It's better translated as somthing like "we will dance on your grave" - he was saying that the soviet system was so superior that it would outlast the american one, and thus the USSR would be presant at the funeral of american capitalism, and help bury it.
Parent
Re:OS crashes. (Score:5, Insightful)
Parent
Re:OS crashes. (Score:5, Funny)
I think it is reaching to call WinCE's interface familiar. My first reaction upon using a PocketPC was, "wtf is going on?!"
I guess it is more familiar than, I dunno, cattle prod torture, but that isn't saying much.
I love my iPAQ anyway though.
Zzzzot!
Parent
Re:QNX? ICK! (Score:5, Insightful)
That can depend a great deal on which version of QNX you are looking at. It you really have an older project that is running on say, QNX 4, then it would be painful. I've worked quite a bit with it. The most painful thing about it is that I remember when Linux looked and felt like that years ago. That's because QNX 6 is current. Most of the things that you've come to expect under Linux are available under QNX.
Where QNX really shines, is in faster context switches, and a predictable real time scheduler. Of course, if you invert the priority of your processes, good luck. The QNX folks have also provided a nice message passing library. Okay, there are other ways to handle interprocess communication. But their stuff just keeps on working.
The only reason that I would recommend porting away from QNX to Linux is if there was a specific need driving the port. If all of your other code is under Linux, or you need to save the licensing costs, or there are specific tools or libraries that haven't been ported. QNX has a pretty familiar feel to anyone familiar with multiple Unices.
Now the GUI libraries (I'm talking QNX 4 here, not the newer Photon stuff), are a bit of a pain. They harken back to darker days. The effort to port QNX 4 GUI code to anything else would be bigger than it is worth in a lot of cases.
QNX gets the embedded, real time stuff right. Don't underrate that.
Parent
Re:QNX? ICK! (Score:4, Funny)
you really want microsoft code in BSD?
Parent
Re:QNX? ICK! (Score:5, Informative)
What security problems did you have?
There are 2 that I know of offhand. First, they used a reversible hash for passwords, or they used one that was trival to brute force. It's my understanding that breaking a password on QNX is relatively simple. Second, if you are user X on a given machine, you are user X on all of the machines when you are using the QNX networking.
QNX isn't meant to be an on the public Internet OS. It's meant to be used in a closed loop networking environment when in production use. Don't configure anyone else as on your QNX network, and the problem is solved.
2. Networking was trivial. The damn network just worked, the biggest trick was coordinating who had what node number. It worked all the time once you got is correctly configured. It always worked. Other then getting the TCP/IP stack installed which took the sacrifice of a small fury animal, and asking my co-worker Bob how to do it. Once it was configured and running, it was trivial, it always worked without fail on the machines I used.
IPC, was cake. It was stock off the shelf redevous style message passing. About the trickest thing there was calling returning a negative value from a inside of a interrupt service routine (not the real ISR, because you should never reprogram the ISR's, but the function you registered to be called when an interrupt happened), that would call issue a Trigger. That was a little weird. The networking itself was simple. Here's the buffer with the message, here's who I want it passed to, call the send message API. Done.
Now, the style you had to use was a little awkward, because you blocked on a receive message call. However, that was a function on the hard real time requirement of processing a message. You could use stock TCP/IP functionality if you wanted to. They had the standard UNIX sockets as I recall. The had shared memory (in fact shared memory was how they implemented all of the Dev Server functionality). I can't remember if it did stock UNIX signals (I'm pretty sure it did). However, you never needed to use those, you could send real QNX messages, which was orders of magnitude easier.
Now, if you want to bitch about the structure of the Photon programs I understand. If you want to bitch about the lack of a number of highly useful utilities, and that all things are freeze/PAX encoded instead of TAR'ed, I'd agree. Networking isn't a problem. IPC is the core of the entire OS, that's literally how it implements everything. Everytime you call open/read/write, a message gets sent to the process that is registered to handle calls to that. I know this because I write a RAM disk buffer as a proof of concept that we could re-implement chunks of the OS if we needed to. Message passing and IPC are what QNX excels at. It's security model is that, don't use it when it's connected to something that isn't trustworthy.
Kirby
Parent
Re:Some interesting points to note (Score:5, Insightful)
Well this is somewhat of a generalization. Yes some errors can cause the whole system to crash in both Linux, Windows, and Unix. The difference is that it the way Unix and Linux are designed, it is far less likely.
What particular Windows design flaw are you thinking of here? (In other words, I'm far from a Microsoft apologist, but it's nice to back up your statements. :3 )
Protected memory space for the kernel or microkernel: Even Windows has that. The only problem is that "protected" is a very loose term for Windows. Unlike Windows, Unix and Linux doesn't allow any ordinary application to write to the kernel.
That's funny, I don't seem to remember being able to write to addresses above 0x80000000 on NT4, although I haven't tried loading a pointer with such an address and dereferencing it in purpose. Somebody with immediate access to a Win32 system could try this and tell us what happens:
The expected outcome and possible outcomes should be clear.(Win32 userland/kernel split is 2:2, unlike Linux's default 3:1. 2:2 seems a bit excessive to me, but ah well; i haven't thought that much about it. I know there are issues in 3:1 for stuff like page tables on large memory machines). If you're thinking of the bad old days of 16-bit Windows, please say so; it's important to know that you're comparing a broken OS implementation.
Parent