Re: ::scr Cesium

[simon wistow <simon@xxxxxxxxxxxxxx>]

On Tue, Oct 30, 2001 at 06:34:37PM +0000, David Cantrell said:

> > o Network transparent 
> Plan 9.

Also QNX. From rants passim :

"As an example of its flexibility; you could have a game running on
one computer in a network, while it is being controlled by a joystick on
another computer within the network, and its graphical output being
displayed on amonitor of another machine again! One demonstration was of
Doom running on two connected machines to begin with; it was running on
one machine, then the window it was running in was dragged onto the
display of the second machine, then it was partially dragged back, so the
game was running synchronic and seamlessly with half a window on each
screen"

But yeah, I keep meaning to play around with Plan 9. The GUI sucks though.

Some of the papers at http://www.cs.bell-labs.com/sys/doc/ are really
interesting though (for values of interesting). 


> > o I shouldn't ever need to reboot
> > *Ever* not even when upgrading the kernel or addin, removinf device drivers
> 
> Riiiight.  Without a multi processor box with some deep DEEP voodoo that
> won't be possible.  

Not convinced by that (I'm presuming that you mean kernel swapping - device
drivers isn't so hard) ... it's been a long time since I did any OS hacking
(last thing I did was write a Kernel Level Debugger for Minix. In a night.
Which was fun. /me starts rocking back and forth) and i don't have my copy of
Tannebaum lying around but the way I envisage it happening is either ....

Strategem #1 - The "switcheroo"
1. recompile kernel
2. fire up mini-kernel
3. switch from existing kernel to mini-kernel (here in lies the problem)
4. crank up new kernel and switch over
5. shutdown mini-kernel

or

Strategem #2 - The "if you change every part of a car is it still the same car?" 
1. have the kernel as a highly modular peice of software
2. swap pieces out individually until it's all replaced 

which kind of just hand waves over the problem by not defining the bit where
the kernel relinquishes control over the processor

or, finally 

Strategem #3 - The "replace from the top"

1. have a thin layer with control over the processor
2. replace everything above that which is the 'real kernel'

This may have to have a mini kernel running to do the swapping, so it's a kind
of combination of the two with a sort of VM concept. It may not work, it may
produce horrific bottle necks, I may be on crack.

OH for an OS designer! Where are they when you need them? 


> No, Unix got it very wrong by trying *and failing* to make everything be
> a file.  

Hmm, yes. 

I agree

me, easily swayed, nah.

On the other hand it provides a uniform interface to everything. I like being
able to cat /proc/* and cat stuff to devices and being able to mount anywhere.

On problem I 

> gracefully degrade.  You're talking throwing objects around with gay
> abandon.  I take it that memory bandwidth* isn't an issue then :-)

Pah, memory bandwidth schmandwidth :) Anyway, that's what Gnome and KDE are
doing and they're not slow. Oh, wait. 

Seriously though memory bandwidth isn' that much of a problem and it's only
going to get better.  (he, handwaves vaguely)



> it.  There's also a danger of monopoly control of the data API.  Read "He
> Who Controls The Bootloader" and imagine the same applied to Data objects.

Yeah. I remember having this conversation when I first started talking about
OS futures on a sunny day 5 years ago in Kensington.

Basically, the problem, as I see it is, that for a document centric, object
slinging OS API you want to try and have a standard so that you can plug and
replace the spell checker or the text widget or the HTML renderer from any
number of vendors. You also wanted standardised APIs. 

This could potentially be done with a standards body (ISO/IEEE(?)/3rd party
one) but standards bodies are arses (c.f ICANN, WAP forum, ISO, IEEE, W3C etc
etc ad infinitum ad nauseum).

I'm going to waft my hands again and claim a benevolent dictatorship as the
answer to all problems. Ever.

I know some of these features are available elsewhere but not all of them
together or tightly integrated.

Also all I've done is pull together other people's ideas - and I know what I
want - these ideas have been kicking round my head for years now.

What I want to know is what other people think.

Basing future OSs on 30 year old *nix technology is a mistake IMO. Although
you could claim that it aint broke, it'sbeen extensivley tested, don't fix
it.

Is dumping something like POSIX a good idea?

What do people want out of the OS they'll be using in 20 years time?


And just as a hidden treat at the bottom of the post - a fairly good article
on why Linux is shite on desktops.

http://www.wired.com/wired/archive/9.10/linux.html?pg=1


-- 
: "Don't worry," she said, seriously. "Most of the blood was someone else's."