According to Jukka Marin:
> 
> Maybe that too, but how about having two schedulers simultaneously: One
> simple scheduler to run the real-time stuff (or semi-real-time, whatever)
> and when there are no such processes ready to run (or they have used up
> too much time recently), the normal scheduler would run normal processes.
> Something like creating a new level of things between interrupts and
> processes.
> 
I think we're falling into a fallacy here (my opinion), in that we 
expect a general purpose OS to be all things to all people.

I liked Charles Hannum's suggestion (I have actually let it slip out of 
my mind, but the idea of running NetBSD in my telephone sounded quite 
promising), but in particular I think we should be looking at divergent 
offsprings of NetBSD to handle distinct requirements.

For example, NetBSD as it stands now (I'm at 1.3.2) is a better than 
adequate multiuser OS.  Suggestions have been made about that a 
workstation implementation should be more responsive to the single 
user, and I have no doubt that many of us also use NetBSD in this role, 
so they should be accommodated.

Similarly, there is scope for NetBSD (or somesuch) as a dedicated file 
server (the idea is Plan 9's and I heartily support it), as well as 
NetBSD (or perhaps FreeBSD is more appropriate, but I prefer NetBSD's 
IP filtering and NAT style) as the platform for network firewalling.

Lastly, we have Charles wrestling with multiprocessing issues.  I think 
the latter is the place where real-time responsiveness can be 
considered, even if it entails building on a MACH-like microkernel that 
switches from real-time demands to scheduled tasks.

Just a few thoughts; to me a map of future developements in NetBSD may 
make it easier to differentiate between immediate issues and long-term 
objectives, as well as lay down some expected delivery dates.

++L