OT: Can We Make OSes Reliable and Secure

Robert Brockway rbrockway-wgAaPJgzrDxH4x6Dk/4f9A at public.gmane.org
Fri Jun 2 23:14:34 UTC 2006


On Fri, 2 Jun 2006, Christopher Browne wrote:

> Unfortunately, casting the IPC interfaces in stone introduces a new
> set of restrictions and a new set of problems.

I was thinking about this.  I don't think it has to be set in stone.

It should not be terribly difficult to make an extensible protocol.  I was 
thinking that pairs of services could even be allowed to have sub 
protocols specific only to their interaction.  I won't go too much into 
this as I know OS researchers have been over this many times.

Certainly designing a system which will not shackle you down the track is 
absolutely essential to the design of the microkernel.

> More vital, the move to a microkernel design means that you have a
> "broken system" for a substantial period of time.

There is nothing stopping us continuing to use existing OSes as the 
microkernel develops.

> What we saw happen with Hurd was that:
>
> "Of course 5  years from now that will be different,  but 5 years from
> now  everyone  will  be  running  free  GNU on  their  200  MIPS,  64M
> SPARCstation-5."  -- Andrew Tanenbaum, 1992

GNU/Mach/HURD are often citied as counter examples as to why we should not 
move to a microkernel. I don't think it is a good one.  All it proves is 
that that particular project has not worked out, not that the ideas behind 
the project are flawed.  There are many reasons why that project has not 
worked out yet and many of them have to do with humans.

> became
>
> "I am aware of the benefits  of a micro kernel approach.  However, the
> fact remains  that Linux is  here, and GNU  isn't --- and  people have
> been working on Hurd for a lot longer than Linus has been working on
> Linux." -- Ted T'so, 1992.

IMHO the increasing complexity of monolithic kernels will force a move to 
microkernels in the end.  How much large is a Unix kernel than it was 20 
years ago?  100 times, 1000 times.  The complexity of the kernel goes up 
at a superlinear rate.  As such I predict a case of deminishing returns 
unless order is brought to the chaos.  Ie, eventually a spagetti code 
kernel will become so complex the effort required to add new features will 
outweigh the benefit.

> And it is worth considering that it is now 2006, some twelve years
> hence, and Hurd /"free GNU" (as Tanembaum termed it) is still pretty

My argument to this is that we've only had computer for 50 or 60 years.
Right now we are still in the early experimental stages of development. 
It may be that eventually nothing like the operating system exists at all. 
In the mean time I am convinced that within the next 10-15 years we'll see 
microkernels become mainstream.

> Some of that could have turned out differently.  But it's worth
> pointing out that in order to head towards a New World Order of
> _Linux, The MicroKernel_, we'd have to assortedly see:

Oh I'm not prodicting Linux, the MicroKernel.  Oh no.  Excuse me if 
anything I said lead you to believe this.  No way.  Linux is a monolithic 
kernel and that way it will stay (IMHO).

I'm saying viable microkernels will arrive.  They will run all the same 
apps (POSIX subsystem that looks just like Linux from userspace, among 
others), they will acquire features and flexibility rapidly and they will 
become popular.  That's my prediction anyway.

>> I absolutely am.  I am convinced we'll see much more rapid system
>> development under a well planned microkernel system.
>
> Perhaps, but you need to have an "as big as designing X11 or BSD"
> superproject involving hundreds of millions of dollars of funding at
> academic and professional levels along with several years of work and
> waiting time as predecessors to actually seeing the glimmerings of a
> system smart enough to display "Hello, world!"

I don't think it'll need to be that big.  Big yes, but not that big.

> There are plenty of good things about Linux being free; one of those
> things *isn't* "Because it encourages vendors to spend more on
> developing competing OSes."

Yes a good point.

Well I may dip out of the thread.  I'll have to see how much time I have.
But I'll be reading :)

Rob

-- 
Robert Brockway B.Sc.        Phone:          +1-905-821-2327
Senior Technical Consultant  Urgent Support: +1-416-669-3073
OpenTrend Solutions Ltd      Email:          support-wgAaPJgzrDxH4x6Dk/4f9A at public.gmane.org
                              Web:            www.opentrend.net
We are open 24x365 for technical support.  Call us in a crisis.
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml





More information about the Legacy mailing list