Return to BSD News archive
#! rnews 3091 sserve.cc.adfa.oz.au
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!simtel!swidir.switch.ch!newsfeed.ACO.net!Austria.EU.net!EU.net!howland.reston.ans.net!news-e1a.megaweb.com!newstf01.news.aol.com!news-le0.UU.NET!in2.uu.net!dziuxsolim.rutgers.edu!er6.rutgers.edu!not-for-mail
From: kenn@er6.rutgers.edu (Ken Nakata)
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: The Future of FreeBSD...
Date: 22 Jul 1995 19:06:48 -0400
Organization: Rutgers University
Lines: 50
Distribution: world
Message-ID: <3us0a8$l9m@er6.rutgers.edu>
References: <3uktse$d9c@hal.nt.tuwien.ac.at> <3ulsro$ssl@agate.berkeley.edu> <Ek3eKzC00ggL1EveAS@cs.cmu.edu> <3uo4fk$gjm@er6.rutgers.edu> <ck3xcVu00YUxABg5gY@andrew.cmu.edu>
NNTP-Posting-Host: er6.rutgers.edu
Matthew Jason White <mwhite+@CMU.EDU> writes:
>No, there have always been those who port each new version of a software
>to multiple systems. The fun thing about microkernels is that this
>becomes no longer necessary.
Why and how is it so with microkernel and it is not with other OS's
such as NetBSD?
Parhaps you don't know this; With NetBSD, we already have very
portable environment across many platforms. If I can compile one
program on i386 port, I'll be able to just re-compile the source on
Mac68k port and use it in most cases. Amiga, Atari, Mac68k and Sun3
ports can even share the same binary executables (No, I don't hate
FreeBSD or anything. It's just that I'm a NetBSD user, rather happy
one).
Why is it a microkernel thing? Please explain.
>The cut in development time will eventually justify the lessened
>performance in the same way that C replaced assembly
I don't see the cut *intrinsic* to the microkernel architecture,
"intrinsic" meaning the cut can only be achieved by the architecture.
It can be achieved by other means. BTW, I haven't object to the
lesser performance at all. Like you say, someday that'll be justfied.
>That's a management problem. The fact is, one version of a piece of
>software is less time consuming to maintain than twelve. For many
>corporations today, it simply is not an option to pay extra for the
>really topnotch programmers because they need extra people to do ports.
>If you aren't porting significantly, then you can shell out for better
>programmers in few numbers.
>How do you insure excellent programmers? If they suck, fire them. Or
>better yet, do a good job checking references.
You totally missed the point. He stated that *with microkernel
architecture* you have fewer excellent programmers instead of many
mediocre programmers. Probably his point was instead that
microkernelized OS can be maintained by fewer programmers than
conventional monolithic OS. But it has nothing to do with
programmers' quality and I don't believe it is true, either.
If you don't bother to read posts carefully, why do you bother to
respond?
/kenn
--
Ken Nakata <kenn@{eden,remus}.rutgers.edu> | "http://remus.rutgers.edu/~kenn/"
Rutgers, The State University of New Jersey | for Logitech TrackMan/MouseMan
New Brunswick, New Jersey | support for NetBSD/mac68k