Re: My Vintage Dream PC

This is s specious argument. Since no OS is perfect, therefore all are equally buggy. Obviously some are more buggy than others which were designed for reliability, not for flash.

What is desired is an OS that tends to be robust even in the face of bugs.

The way NT let the nose of the display-system-and-UI camel in under the flap of the OS kernel is a good example -- indeed, by now a textbook example -- of how _not_ to achieve this.

The advantage of a small kernal OS is that a small number of very good people - as few as one - can write the core of the OS. Once you move stuff like GUIs into the kernal space, you have hundreds of programmers dumping thousands of modules into the part that can crash and take the whole system down.

The ultimate OS should maybe be hardware, fpga probably, or an entirely separate processor that runs nothing but the os.

John

You just described OS4000, running on the GEC 4000 series minicomputers. The only code you can run on the system runs in processes. The Kernel is all hardware and firmware, and you can't change or modify it. The later models in the range were fpga instead.

GEC did experiment with such a system too, but it never turned into a product.

CDC-6600.

In a few years, when most any decent CPU has 64 or so cores, I suspect we'll have one of them run just the OS. But Microsoft will f*** that up, too.

John

Not very efficient, it would be a return to the bad old days of master-slave or asymmetric multiprocessing. The problem usually isn't the CPU anyhow, it's memory corruption, and multiple cores don't solve this problem.

I've been hearing about their next release. Not good at all.

/BAH

Which will cause every system to grind to a halt. think about networking.

Which will still require one CPU to be "boss".

The problem is scheduling. Memory corruption would be isolated to an app address space, not the monitor's.

/BAH

Based on what I've just heard, 1000 for the file system arranger.

/BAH

Efficiency wouldn't be hurt much if 1/64 of your immense compute power goes to management.

Of course, it would only help reliability if the cores were truly hardware-protected from one another. But Intel will f*** that up, too.

John

Why only one? Surely the kernel will be multithreaded.

Why should it be? All it would do is set up memory management and schedule tasks, so it wouldn't be very busy. Things like file systems and device drivers and network ports could have their own CPUs. If every task in turn has its own CPU, there would be no context switching in the entire system, so there's even less for the supervisor CPU to do.

The simpler it is, the less likely that it can crash. In fact, the OS core should never crash and viruses should be flat impossible.

Windows has become a major threat to national security. We need a new approach.

John

You seem to be assuming a microkernel, with the other functions in other programs. But at this level of description, that's really a variation on the "multithreaded OS" theme.

I'm not sure we need a "new" approach, but we certainly need an approach other than Windows. Coincidentally, I'm typing this on a Linux box.

Wheee it's MP/M all over again.

-- Steve O'Hara-Smith | Directable Mirror Arrays C:>WIN | A better way to focus the sun The computer obeys and wins. | licences available see You lose and Bill collects. |

The other way 'round. If you dedicated a core to the OS, it would have to single-thread. If any core can execute any thread the OS can get whatever it needs. It's tempting to just dedicate something, but OS developers decided years ago that the more scheduling flexibility you have, the better.

But having hundreds of very fast cores might suggest revisiting issues decided years ago. We aren't hurting for performance these days as much as we're hurting for reliability and security.

John

Sigh! Now consider that the core containing the OS has a cosmic ray hit it.

/BAH