OSNews

Hell, even on a desktop: I'd rather the disk driver crash and silently restart itself than wait around for a full reboot.

Exactly, and this lies at the base of why I like the muK design; contrary to many, I think the muK is suited much better for desktops than a monolithic design. The overhead problems of yesteryear are nullified by today's powerful computers. We have processors wich are acting as expensive dust collectors most of the time anyway-- why not live with a 1% performance decrease if it gives back a much more robust system, a system where bugs in drivers will actually not cause the system to crash?

There's a reason why I like QNX so much. One of these days, I want to interview people at QSS (I got the important email addresses collected already, so step 1 is taken, and they know me after a short email convo) and ask them if they ever thought about QNX' opportunities as a desktop operating system. Their PhotonUI graphical user interface (which does not use X) is modelled after the muK principle (highly modular) and has its own 3D framework and 3D drivers.

It's a business opportunity for which QNX needs to do little. The entire OS is there, a lot of apps are as well (thanks to QNX' high POSIX compliance, much higher than Linux's), and they have an advanced package manager as well. A little more promotion is all they need.

http://www.osnews.com/story.php?news_id=8911

There.

Edited 2006-05-11 21:17

Yeah, but what really is the feasiblity of QNX on the desktop? Wouldn't one have to say that the stability of QNX is due largely to its limited uses? If it had to do as many things as Linux or BSD and run on as many different types of hardware, would it still be as stable?

The overhead problems of yesteryear are nullified by today's powerful computers.

Actually it's opposite. As computers become more powerful the overhead gets bigger, so to speak. The difference in performance between a pure muK and a monolithic design increases as cpu performance increases.

QNX is not a pure muK. There is no such thing today. BeOS is not a pure muK either, yet it still has a poor performance. The fact it does yield a nice desktop experience is more due to the modularity in user space than the kernel itself, and _can_ be achieved with monolithic systems. On the other hand, the performance of monolithic systems _can_ be achieved with muK-like designs, if and _only_ if some elements in a pure muK-design is abandoned.

Linux and the Windows kernel are not monolithic kernels, nor muK. The same goes for BeOS, AmigaOS, Syllable and QNX.

dylansmrjones,

"QNX is not a pure muK."

Says what reliable source? The QNX kernel only has CPU scheduling, interprocess communication, interrupt redirection and timers built into it. If you reduced the number of tasks the kernel has any more, it wouldn't be a kernel.

Thom,

Here's hoping QNX management can see an opportunity for widespread use on general purpose machines. I think QNX would be very suitable for use in robotics and control automation running on generic personal computers.

Edited 2006-05-11 23:00

"Hell, even on a desktop: I'd rather the disk driver crash and silently restart itself than wait around for a full reboot."

Exactly, and this lies at the base of why I like the muK design; contrary to many, I think the muK is suited much better for desktops than a monolithic design.

This, once again, confuses two separate implementation issues as if they were one. I routinely restart crashed device drivers on monolithic systems, most notably USB devices on Linux.

You may want a disk driver to crash and restart silenetly, but I do not, because I understand both the fault model of disk devices and the fault containment issues with disk drivers.

You are assuming that when a disk driver fails it'll do so in an obvious way with almost no side effects. This is called "fail fast, fail silent" in the literature. But it's not typically the way drivers fail. Disk drivers fail because the hardware did something unexpected by the designer, as often as not, and I, for one, want to know what that was. (Real disk devices fail in intermitten ways, and the damage can be long done before the driver falls over.)

>> thought about QNX' opportunities as a desktop operating system.

desktop operating systems. there's a market with a lot of growth.

home users shut their computers off once a day

business users just reboot

people wants apps and compatibility. got skype for qnx?

pissing away capital trying to muscle into a settled market would be an elaborate way for qnx to commit suicide.

1.) But if you can write crappy disk drivers, how often is this going to start happening?
2.) This one's easier, NIC's aren't as damageable as disks.
3.) Yes they have, they're child processes of the WM which is a child of the server. This is really unfortunate, but I think Microsoft has actually worked around this in Windows; but they have a different architecture.
4.) Definitely, that makes sense.


My concern is that this ideology makes it OK to write shitty drivers. Monolithic kernels seem to provide a nice idiot proof layer where idiots have a hard time getting a driver to work at all.

1.) But if you can write crappy disk drivers, how often is this going to start happening?

That's a facetious argument. There is no reason disk drivers for microkernels should be any less reliable than one for macrokernels. Indeed, there is reason to believe it should be the other way around --- microkernels tend to enforce very simple kernel-driver interfaces (because everything must go through IPC), and maker the resulting driver less complex.

3.) Yes they have, they're child processes of the WM which is a child of the server. This is really unfortunate, but I think Microsoft has actually worked around this in Windows; but they have a different architecture.

The WM is not a child process of the server, and apps are not child processes of the WM. The reason your apps die when the X server does is because they have a pipe open to the server, and don't handle the signal

My concern is that this ideology makes it OK to write shitty drivers.

It's not an ideology that makes it "OK to write shitty drivers". It's an ideology that says "bugs are inevitable, shit happens, so let's try to minimize the damage when it does."

There are practical ramifications to this that go beyond ideology. Linux, as a monolithic kernel, cannot handle a network stack crash without crashing the system. Even BeOS, a hybrid-microkernel that wasn't particularly designed for robustness, can do that. In QNX, you can take out drivers left and right without crashing the system. That is not true of almost any monolithic kernel. Linux is also not an OS that has any hope of achieving EAL7 certification (or something along those lines). Verifying all that kernel-level code would be impossible. Systems like EROS and CoyoteOS, with their tiny kernels, have at least some hope of achieving something like an EAL7 certification.

Considering that one of the express purpose of the microkernel implementation strategy besides increasing runtime flexibility is to increase the reliability of the system, why would its adherents feel that buggy software was more acceptable because the system could recover? The idea is simply to mitigate the damage done in the event that a simplistic error occurs. You might as well argue that languages that raise exceptions when an array index is out of bounds promotes the development of buggy software.

You could more easily say that it doesn't do enough to develop correct software, and because that is your intended goal, that it is largely unimportant when compared to approaches that do.

One problem is that moving a device driver into a separate process doesn't mean that it will recover gracefully from executing erroneous code. That erroneous code can leave the system in an unrecoverable state in a number of ways without ever causing a "crash" that will be prevented by the MMU of a PC.

You are right for most part but not all. Think of what happens when a disk driver does access violation? It is important to crash the whole system rather than let it continue and damage the disk. In fact it is advisable to not let that driver run again because it can cause further disk corruption and destroy even remaining data on disk.

Network drivers, yeah they should be restartable. Who gives a damn if your network connections die. design your socket libraries to have sufficient resiliency.

I think except disk driver, there are hardly any other drivers that can't be restarted easily. Windows is doing this now by moving many drivers to user mode like Audio n stuff with UMDF.

"On BeOS, the net_server was buggy as hell"
- Heck, I can top that one...

I actually physically 'jiggled' the sound card (truly catastrophic for most OSes), and after the audio barfed I restarted the media_server - and the friggin' thing worked!. Now I don't know many specific details as to what exactly happens, but after I did this, my curiosity (and pluckiness) was piqued - so I tried it ten more times. Seven out of the ten times, I could restart the audio without any problems and without rebooting. I have some serious doubts that Windows or possibly even Linux could survive such a flagrant type of physical system abuse. Maybe the muK has some part to play in this stability, or maybe I'm just lucky. If someone else has also experienced this phenomenon, let me know.

PS. Seriously, don't try this yourself on Windows or anything else (or at least don't blame me for anything). After presenting this to a friend, he stupidly tried something similar while burning a CD in XP, and trashed his filesystem. He got mad at me, so I told him to get mad at himself instead. What a dummy.