Re: [9fans] micro vs monolithic kernels

Re: [9fans] micro vs monolithic kernels

[jmk]

On Mon Apr  9 17:55:42 EDT 2001, ravage@ssz.com wrote:
>
> I have to disagree here as well. You wouldn't if you were out there all
> along with your willies swinging in the wind.
>
> I don't and wouldn't do that to my people.
>
> I can take a newbie and have them walk through my teams script (it's
> mostly automated) and they can do it almost as fast. It takes us about 2
> weeks to get somebody up to speed and regularly, reliably hitting our
> standard performance markers.
>
> Plan 9 has a ways to go, that is without a doubt...;)

Ah, a room full of monkeys (or would that be armadillos in texas).

Re: [9fans] micro vs monolithic kernels

[Jim Choate]

On Mon, 9 Apr 2001 jmk@plan9.bell-labs.com wrote:

> Ah, a room full of monkeys (or would that be armadillos in texas).

I say that everytime I walk into a room full of people, what's amazing is
it only took one monkey, less time than the lifetime of the cosmos, and no
typewriter to write Shakespeare...

Armadillo's don't type - in Texas or elsewhere for that matter.

    ____________________________________________________________________

       To speak algebraically, Mr. M. is execrable, but Mr. G. is
       (x+1)-ecrable.
                                         Edgar Allan Poe

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] micro vs monolithic kernels

[nemo]

The funny thing is that services like drivers, file systems, et al.
are out of the kernel in Plan 9 since they come mostly from the network.
Certainly, you get your drivers in the kernel, but I'm used to import
many of them from the network. So, you can replace, develop and debug much
`kernel software' in user space, which IMHO was the original aim of the
uKernel camp. What I like most is that the system design is not pushed too far
just to get more stuff out of the kernel.

I'd say that Plan 9 has a well-engineered kernel: Not micro, not macro. ☺


:  Andrey A Mirtchovski <aam396@mail.usask.ca> wrote:
:  >i seem to remember reading somewhere a reasoning on why it was chosen to
:  >implement p9 with a monolithic kernel, instead of a micro one..
:
:  Charles Forsyth <forsyth@vitanuova.com> replied:
:  >the implied comparison is false.  to start with, the plan 9 kernel
:  >is not  `monolithic'.  it is highly modular.
:
:  I've heard people use the term `monolithic' to describe an operating
:  system that may or may not have been modular, but was a `monolithic
:  monitor'. Years ago, I was a junior on a project developing such a

Re: [9fans] micro vs monolithic kernels

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 269 bytes --]

it's possible to do this with plan 9.  in fact, it's usually quicker, because
once the configuration is set up on the file server (even if that's on a kfs
partition of a cpu server), all the terminals share the same configuration,
and you just have to boot them.


[-- Attachment #2: Type: message/rfc822, Size: 3530 bytes --]

To: cse.psu.edu!9fans
Cc: einstein.ssz.com!hangar18
Subject: Re: [9fans] micro vs monolithic kernels
Date: Mon, 9 Apr 2001 16:52:23 -0500 (CDT)
Message-ID: <Pine.LNX.3.96.1010409164128.14587X-100000@einstein.ssz.com>


On Mon, 9 Apr 2001, Russ Cox wrote:

> you wouldn't expect to set up a full-blown windows nt
> file server in a few hours and have it work.  you wouldn't
> (or at least shouldn't) expect to sit down with the red hat
> box and have a linux system completely ready to go in a
> few hours.

I'll have to disagree. My day job is taking GA code for a very large
software/hardware company and testing it on new OS'es as they come out
the door. I manage a group of 5 engineers who spend their week doing about
25-50 OS loads a week and then running the resultant through an automated
testsuite.

On average a MS or Linux box takes between 2-3 hours to config once the
binaries are installed and the system rebooted. I can have a linux box up
and running (sendmail, bind, majordomo, etc.) up and running in under two
hours myself (and have been hitting that target for several years now).
This doesn't include kernel compile time.

So, trying to set the 'base line' standard to install and config a box
outside of 8 hours (a regular work day) is being unreasonable. It should
take x number of hours to setup networking, name resolution, MTA, etc. The
process should be scripted as none of these apps should have ANY hardware
dependency at all.

Saying that your OS won't allow one to configure these base services in a
reasonable and repeatable amount of time is a cop-out.

You guys should work in a 'production' environment, you're getting flabby
around your pre-frontals...

    ____________________________________________________________________

       To speak algebraically, Mr. M. is execrable, but Mr. G. is
       (x+1)-ecrable.
                                         Edgar Allan Poe

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] micro vs monolithic kernels

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 194 bytes --]

i think that's misleading:  we use plan 9 for production work, generally quite happily
(much happier than we would be using most other systems), and it works well.
and that's a Good Thing.


[-- Attachment #2: Type: message/rfc822, Size: 1906 bytes --]

To: cse.psu.edu!9fans
Subject: Re: [9fans] micro vs monolithic kernels
Date: Mon, 09 Apr 2001 15:36:52 -0600
Message-ID: <200104092136.f39Laqi05988@orthanc.ab.ca>

>>>>> "Jim" == Jim Choate <ravage@ssz.com> writes:

    Jim> You guys should work in a 'production' environment, you're
    Jim> getting flabby around your pre-frontals...

No, you should run 'production' software in your 'production' environment.
We aren't running a 'production' environment here. And that's a Good Thing.

--lyndon

Re: [9fans] micro vs monolithic kernels

[Matt]

>The best-configured Windows system is still inadequate
>(without a lot of third-party software)

it'a got Solitaire what more do you need?

Matt

Re: [9fans] micro vs monolithic kernels

[forsyth]

>>n particular have been getting worse with each release.  Even Windows
>>installations aren't much better -- you are completely out of luck if
>>anything goes wrong.

not completely out of luck.  after a few hours of a promised 30 minute installation for
windows/me, it refused to proceed until i told it where to find bits of itself on its own cd
but with that information (``you're asking me??'') it shuffled off and completed
a few hours later.

it wasn't worth it.

Re: [9fans] micro vs monolithic kernels

[Boyd Roberts]

"Jim Choate" <ravage@einstein.ssz.com> a crit dans le message news:
Pine.LNX.3.96.1010409171241.14587c-100000@einstein.ssz.com...
>
> Plan 9 has a ways to go, that is without a doubt...;)


What, a team of 6 or so people vs an _army_ Sloth and Linsux?

--
Boyd Roberts        http://www.insultant.net        boyd@insultant.net

What do you know about surfing, Major?  You're from goddamn New Jersey.

    -- Lt. Colonel Kilgore

Re: [9fans] micro vs monolithic kernels

[Boyd Roberts]

"Jim Choate" <ravage@einstein.ssz.com> a crit dans le message news:
Pine.LNX.3.96.1010409171052.14587b-100000@einstein.ssz.com...
>
> Fuck your t-shirts.


t-shirts?  nope, bowling shirts:

    http://www.planete.net/~boyd/9qab.jpg

with your login name above the left pocket.

--
Boyd Roberts        http://www.insultant.net        boyd@insultant.net

What do you know about surfing, Major?  You're from goddamn New Jersey.

    -- Lt. Colonel Kilgore

Re: [9fans] micro vs monolithic kernels

[Douglas A. Gwyn]

Jim Choate wrote:
> I can take a newbie and have them walk through my teams script
> (it's mostly automated) and they can do it almost as fast.

Well, yeah, if you have a procedure already worked out then
of course it's a lot faster.  The same would apply for Plan
9.  You're still comparing apples and oranges (work needed
the first time you encounter the system vs. work needed
after you've created streamlined procedures).

You should also consider what it is that you end up with.
The best-configured Windows system is still inadequate
(without a lot of third-party software) for anyone who
wants the kind of flexibility found in UNIXy environments.
This reflects a difference in customer base for Windows
vs. research platforms; Microsoft always favors appearance
over substance because that is what their users respond to.

Re: [9fans] micro vs monolithic kernels

[Douglas A. Gwyn]

Jim Choate wrote:
> Computers are SUPPOSED to take the drudgery out of ones life...

The guy has a point, but what he misses is that Plan 9
doesn't have a product development staff the size of
Windows'.  They're doing pretty well considering the
limited resources.

Re: [9fans] micro vs monolithic kernels

[Steve Kilbane]

> It's damn hard to 'use' a system if it isn't 'installed'.

True. But in general, a system is installed by a single individual over
a handful of hours, and then used by from one to thousands of individuals,
over periods that may last for years. Plan 9 isn't impossible to install,
and evidently many people have reached the end of the installation process,
and are using it. Therefore, evidently, it's worth paying attention to this
ratio.

 From your other posts, it sounds like you're working on solving the
installation problems, though. Very nice, but it would have been nicer still
if you could have just said so, without attacking. The Bell folks are always
open and forthcoming about where their efforts fall short, be it because of
lack of resources, or lack of vision.

> Talk about specious distinctions.

About as specious as writing code that's coherent enough to be read by
someone else, or as putting coder/decoder complexities into the coder so
that the decoder just needs to stream. "Done once" versus "done lots" is
a pretty damn important difference.

When resources are limited, choices have to be made about where one
puts the effort. Indulge my curiosity, for a moment: if you'd being doing
it, Jim, which part of Plan 9 would you have dropped (i.e. not designed or
implemented) so that the time could be spent on the installation process?

steve

Re: [9fans] micro vs monolithic kernels

[Steve Kilbane]

Being on UK time, I'm going to be somewhat disappointed if tomorrow morning,
I find 9fans full of "well, I've installed on a weirder system than you"
posturing.

Jim wrote:
> An OS is meant to be used. Any environment is a 'production' environment
> from a OS system admin perspective. Making a OS a chinese puzzle to solve
> isn't doing anyone a service. It's just hard-headed self-congragulatory
> mental mastrubation.

I don't understand the problem, here. Jim, you *know* what Plan 9's
history is. Yes, it was supposed to be used, but to find out how well
the ideas behind it work. More specifically, use != install, so if the
effort goes into the day-to-day use at the expense of a bumpy install,
well, that's the trade-off for a research group.

steve

Re: [9fans] micro vs monolithic kernels

[Dan Cross]

In article <Pine.LNX.3.96.1010409181024.14587r-100000@einstein.ssz.com> you write:
>
>On Mon, 9 Apr 2001, Dan Cross wrote:
>
>> Well, the point of Plan 9 is to be a research OS, not a system for
>> production.
>
>You mean ...was...

No, I mean is.  I believe that Bell Labs is still using it for
research, and that's their bread and butter.  Just because they
let other people have it doesn't mean they stop using it for
their own purposes and go into support mode.  Nor should they.

	- Dan C.

Re: [9fans] micro vs monolithic kernels

[Jim Choate]

On Tue, 10 Apr 2001, Steve Kilbane wrote:

> Jim wrote:
> > An OS is meant to be used. Any environment is a 'production' environment
> > from a OS system admin perspective. Making a OS a chinese puzzle to solve
> > isn't doing anyone a service. It's just hard-headed self-congragulatory
> > mental mastrubation.
>
> I don't understand the problem, here. Jim, you *know* what Plan 9's
> history is. Yes, it was supposed to be used, but to find out how well
> the ideas behind it work. More specifically, use != install, so if the
> effort goes into the day-to-day use at the expense of a bumpy install,
> well, that's the trade-off for a research group.

Silly goose. !install == !use.

It's damn hard to 'use' a system if it isn't 'installed'.

Talk about specious distinctions.

    ____________________________________________________________________

       To speak algebraically, Mr. M. is execrable, but Mr. G. is
       (x+1)-ecrable.
                                         Edgar Allan Poe

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] micro vs monolithic kernels

[Steve Kilbane]

The impression I've had is that the architecture of the system was
what was interesting: 9P, namespaces and union directories. The manner
of implementation seemed to be of far less interest.

"The presentation centers on the data structures, because that is how the
program was designed, and because the algorithms are easy to provide, given
the right data structures."
	-rob, from the Sam paper.

steve

Re: [9fans] micro vs monolithic kernels

[Jim Choate]

On Mon, 9 Apr 2001, Dan Cross wrote:

> Well, the point of Plan 9 is to be a research OS, not a system for
> production.

You mean ...was...

    ____________________________________________________________________

       To speak algebraically, Mr. M. is execrable, but Mr. G. is
       (x+1)-ecrable.
                                         Edgar Allan Poe

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] micro vs monolithic kernels

[Dan Cross]

In article <Pine.LNX.3.96.1010409164128.14587X-100000@einstein.ssz.com> you write:
>You guys should work in a 'production' environment, you're getting flabby
>around your pre-frontals...

Well, the point of Plan 9 is to be a research OS, not a system for
production.

If the Plan 9 folks at Bell Labs started to spend a lot of time
polishing up distributions and writing installation documentation, then
they'd have little time to push the state of the art.  *That* would be
a real shame....

Just a speculation, but I'd guess that someone like Russ can, given the
correct hardware components, set up a fileserver/CPU server combo plus
a few terminals in a known and repeatable amount of time.

	- Dan C.

(ps- I find the Plan 9 documentation refreshingly good.  Indeed,
sometimes amazingly good.)

Re: [9fans] micro vs monolithic kernels

[Lyndon Nerenberg]

>>>>> "Jim" == Jim Choate <ravage@einstein.ssz.com> writes:

    Jim> Computers are SUPPOSED to take the drudgery out of ones
    Jim> life...

Doing 15/30/whatever_speed_thats_faster_than_the_other_guy minute
installations of NT/Linux/Solaris/* by rote pretty much _is_ the
definition of drudgery, in my books. Having to engage my brain to get
Plan9 installed isn't drudgery, it's stimulating.

Catering to the clueless merely attracts them. Why would we want
to do that? (I should probably point out that the preceeding
question was rhetorical ...)

--lyndon

Re: [9fans] micro vs monolithic kernels

[William Josephson]

On Mon, Apr 09, 2001 at 05:10:04PM -0500, Jim Choate wrote:

> > It is amusing to hear Microsoft Windows and Linux labeled
> > 'production' quality software.
>
> I don't believe I used the term 'production quality' once. I said they
> were used in a 'production environment' and they are.
>
> Find somebody else to mis-quote to use to grind your personal issues.

A worthy attempt at a flame.  In any event, the point remains that you
are comparing apples and oranges: of course a Linux install is trivial
if you've done it many times over, but to claim that, for instance,
Red Hat installations are trouble-free is completely bogus.  Red Hat's
in particular have been getting worse with each release.  Even Windows
installations aren't much better -- you are completely out of luck if
anything goes wrong.  I'd love to see your reaction to the
installation process for some other research systems I've worked on.

 -WJ

Re: [9fans] micro vs monolithic kernels

[Jim Choate]

I have to disagree here as well. You wouldn't if you were out there all
along with your willies swinging in the wind.

I don't and wouldn't do that to my people.

I can take a newbie and have them walk through my teams script (it's
mostly automated) and they can do it almost as fast. It takes us about 2
weeks to get somebody up to speed and regularly, reliably hitting our
standard performance markers.

Plan 9 has a ways to go, that is without a doubt...;)

On Mon, 9 Apr 2001, Russ Cox wrote:

> sorry, i didn't qualify that properly.
> you wouldn't expect, having just been exposed to
> windows for the first time, to set up an nt file
> server properly in a few hours.  ditto for linux.
>
> once you've done it a few times, and once you know
> your way around the system, sure, all of them become
> much quicker to install.  for the last six years, i've
> run a linux internet gateway at my old high school.
> the first time i set it up it took me hundreds (!) of
> hours, despite familiarity with linux.  (the computing
> environment there was quite peculiar and inserting linux
> required much tailoring.)  the last time i set it up
> it took three hours.
>
> i agree that it'd be great to have the plan 9 cpu and
> file servers be easier to install.  doing a cpu
> install program wouldn't be too hard.  doing a file
> server install program will require waiting for the
> new file server, since the current one doesn't allow
> arbitrary processes to run on it: what you see is
> all you get.

    ____________________________________________________________________

       To speak algebraically, Mr. M. is execrable, but Mr. G. is
       (x+1)-ecrable.
                                         Edgar Allan Poe

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] micro vs monolithic kernels

[Jim Choate]

I am actively working on it through Hangar 18, feel free to come play.

My primary goal right now is a remailer (to be called igor). Then I'm
going to look at that god damned hard headed SVGA probing...

Fuck your t-shirts.

On Mon, 9 Apr 2001 presotto@plan9.bell-labs.com wrote:

> Sounds like we have a volunteer with the manpower
> and correct expertise to make our system install
> process better.
>
> Thank you for volunteering Jim!  Your whole
> group will indeed get free t-shirts when its
> done.

    ____________________________________________________________________

       To speak algebraically, Mr. M. is execrable, but Mr. G. is
       (x+1)-ecrable.
                                         Edgar Allan Poe

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] micro vs monolithic kernels

[Mike Haertel]

>you wouldn't expect to set up a full-blown windows nt
>file server in a few hours and have it work.  you wouldn't
>(or at least shouldn't) expect to sit down with the red hat
>box and have a linux system completely ready to go in a
>few hours.  because plan 9 is a research system while those
>are commercial systems, you should expect even less in terms
>of `works right out of the box'.

I routinely set up fully configured FreeBSD boxes (using the
distributed 4.2 cdrom, and manually editing local configuration
into /etc) in about 25 minutes: 15 minutes to boot off the CD,
partition the disk, make a file system, and extract a pretty complete
set of distribution binaries and sources, and 10 minutes to edit
files in /etc.  It almost takes longer to set up the boxes and hook
up all the cables and the network, than to install the OS.

Plan 9 PC terminals are about as easy, but somewhat slower because
of pathetic file system performance when extracting large bunches
of files.  I haven't tried to set up a full Plan 9 environment with
auth, cpu, and file servers yet.

When I was at Intel, I made a custom FreeBSD boot floppy that Unix-clueless
coworkers could use to set up a full configured system in a completely
automated fashion.  It made intelligent decisions that allowed it to
tolerate a variety of hardware configurations, and installed the bits
over the network.  It typically took 10 minutes from booting the
floppy on an empty machine, to rebooting the fully configured system.

The IT guys were amazed.  My friends and I were amazed that they
were amazed.  For about two years the network of FreeBSD boxes that
we ran ourselves was our favorite software development platform.
A lot of Pentium 4 architecture work was done on that homebrew setup.
Eventually the IT guys moved from NT to Linux and we stopped maintaining
our own environment.

Re: [9fans] micro vs monolithic kernels

[Jim Choate]

On Mon, 9 Apr 2001, William Josephson wrote:

> On Mon, Apr 09, 2001 at 04:52:23PM -0500, Jim Choate wrote:
> > On average a MS or Linux box takes between 2-3 hours to config once the
>
> > You guys should work in a 'production' environment, you're getting flabby
> > around your pre-frontals...
>
> It is amusing to hear Microsoft Windows and Linux labeled
> 'production' quality software.

I don't believe I used the term 'production quality' once. I said they
were used in a 'production environment' and they are.

Find somebody else to mis-quote to use to grind your personal issues.

    ____________________________________________________________________

       To speak algebraically, Mr. M. is execrable, but Mr. G. is
       (x+1)-ecrable.
                                         Edgar Allan Poe

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] micro vs monolithic kernels

[Jim Choate]

On Mon, 9 Apr 2001, Lyndon Nerenberg wrote:

> >>>>> "Jim" == Jim Choate <ravage@ssz.com> writes:
>
>     Jim> You guys should work in a 'production' environment, you're
>     Jim> getting flabby around your pre-frontals...
>
> No, you should run 'production' software in your 'production' environment.
> We aren't running a 'production' environment here. And that's a Good Thing.

I do. I use one of my companies GA products as the test harness of my
automated system (the only team in the entire company to do so I might
add). We use a 'customer like' environment and to make sure it is we
actively work on resolving Crit-Sit's and Sev 1's the rest of the company
has failed to resolve.

In the two years I've managed the group we've hit every time target, come
in under budget, increased the volume of work executed each year (with a 2
person decrease in staff mind you) by a full order of magnitude. If you
look at my groups total performance in the last 24 months we've hit 1000%
improvement (and we ain't done yet).

An OS is meant to be used. Any environment is a 'production' environment
from a OS system admin perspective. Making a OS a chinese puzzle to solve
isn't doing anyone a service. It's just hard-headed self-congragulatory
mental mastrubation.

Computers are SUPPOSED to take the drudgery out of ones life...

    ____________________________________________________________________

       To speak algebraically, Mr. M. is execrable, but Mr. G. is
       (x+1)-ecrable.
                                         Edgar Allan Poe

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] micro vs monolithic kernels

[Jim Choate]

On Mon, 9 Apr 2001, Russ Cox wrote:

> you wouldn't expect to set up a full-blown windows nt
> file server in a few hours and have it work.  you wouldn't
> (or at least shouldn't) expect to sit down with the red hat
> box and have a linux system completely ready to go in a
> few hours.

I'll have to disagree. My day job is taking GA code for a very large
software/hardware company and testing it on new OS'es as they come out
the door. I manage a group of 5 engineers who spend their week doing about
25-50 OS loads a week and then running the resultant through an automated
testsuite.

On average a MS or Linux box takes between 2-3 hours to config once the
binaries are installed and the system rebooted. I can have a linux box up
and running (sendmail, bind, majordomo, etc.) up and running in under two
hours myself (and have been hitting that target for several years now).
This doesn't include kernel compile time.

So, trying to set the 'base line' standard to install and config a box
outside of 8 hours (a regular work day) is being unreasonable. It should
take x number of hours to setup networking, name resolution, MTA, etc. The
process should be scripted as none of these apps should have ANY hardware
dependency at all.

Saying that your OS won't allow one to configure these base services in a
reasonable and repeatable amount of time is a cop-out.

You guys should work in a 'production' environment, you're getting flabby
around your pre-frontals...

    ____________________________________________________________________

       To speak algebraically, Mr. M. is execrable, but Mr. G. is
       (x+1)-ecrable.
                                         Edgar Allan Poe

       The Armadillo Group       ,::////;::-.          James Choate
       Austin, Tx               /:'///// ``::>/|/      ravage@ssz.com
       www.ssz.com            .',  ||||    `/( e\      512-451-7087
                           -====~~mm-'`-```-mm --'-
    --------------------------------------------------------------------

Re: [9fans] micro vs monolithic kernels

[presotto]

Sounds like we have a volunteer with the manpower
and correct expertise to make our system install
process better.

Thank you for volunteering Jim!  Your whole
group will indeed get free t-shirts when its
done.

Re: [9fans] micro vs monolithic kernels

[Russ Cox]

sorry, i didn't qualify that properly.
you wouldn't expect, having just been exposed to
windows for the first time, to set up an nt file
server properly in a few hours.  ditto for linux.

once you've done it a few times, and once you know
your way around the system, sure, all of them become
much quicker to install.  for the last six years, i've
run a linux internet gateway at my old high school.
the first time i set it up it took me hundreds (!) of
hours, despite familiarity with linux.  (the computing
environment there was quite peculiar and inserting linux
required much tailoring.)  the last time i set it up
it took three hours.

i agree that it'd be great to have the plan 9 cpu and
file servers be easier to install.  doing a cpu
install program wouldn't be too hard.  doing a file
server install program will require waiting for the
new file server, since the current one doesn't allow
arbitrary processes to run on it: what you see is
all you get.

russ

Re: [9fans] micro vs monolithic kernels

[William Josephson]

On Mon, Apr 09, 2001 at 04:52:23PM -0500, Jim Choate wrote:
> On average a MS or Linux box takes between 2-3 hours to config once the

> You guys should work in a 'production' environment, you're getting flabby
> around your pre-frontals...

It is amusing to hear Microsoft Windows and Linux labeled
'production' quality software.

 -WJ

Re: [9fans] micro vs monolithic kernels

[Lyndon Nerenberg]

>>>>> "Jim" == Jim Choate <ravage@ssz.com> writes:

    Jim> You guys should work in a 'production' environment, you're
    Jim> getting flabby around your pre-frontals...

No, you should run 'production' software in your 'production' environment.
We aren't running a 'production' environment here. And that's a Good Thing.

--lyndon

Re: [9fans] micro vs monolithic kernels

[Russ Cox]

 	one question does anyone find bell labs' documentation a poor disgrace to
	software engineering's design process.

if we knew what it was going to look like when
we finished, what would be the point of building it?

more seriously, we're all happy to help you get going,
but setting up a plan 9 file or cpu server is not like
setting up a toaster.  it's not just going to work.
you need to get used to the way the system works so you
can figure out what went wrong when things do go wrong.

you wouldn't expect to set up a full-blown windows nt
file server in a few hours and have it work.  you wouldn't
(or at least shouldn't) expect to sit down with the red hat
box and have a linux system completely ready to go in a
few hours.  because plan 9 is a research system while those
are commercial systems, you should expect even less in terms
of `works right out of the box'.

that's not to say that it actually is harder to install than
windows or linux.  i think installing a terminal is actually
much easier in plan 9 than in the various linux distributions
i've used.  there's no similar program to lead you through
installing a cpu server, and certainly not one to lead you
through installing a file server.

if you go at it with the right frame of mind, plan 9
is a lot of fun and quite pleasant to use.
it _will_ be frustrating at times (especially when
setting up a file server), but in general those
times are few and far between, and it's more
rewarding than frustrating.

russ

Re: [9fans] micro vs monolithic kernels

[Douglas A. Gwyn]

Dave Iafrate - CSCI/F1997 wrote:
> one question does anyone find bell labs' documentation a poor disgrace to
> software engineering's design process.

Compared to what?

Re: [9fans] micro vs monolithic kernels

[John A. Murdie]

Andrey A Mirtchovski <aam396@mail.usask.ca> wrote:
>i seem to remember reading somewhere a reasoning on why it was chosen to
>implement p9 with a monolithic kernel, instead of a micro one..

Charles Forsyth <forsyth@vitanuova.com> replied:
>the implied comparison is false.  to start with, the plan 9 kernel
>is not  `monolithic'.  it is highly modular.

I've heard people use the term `monolithic' to describe an operating
system that may or may not have been modular, but was a `monolithic
monitor'. Years ago, I was a junior on a project developing such a
operating system for business; it turned off device interrupts at the
start of execution of a system call and on again when the system call
was finished. Of course, this led to extremely large interrupt latency,
which was noticed when the time of day clock was observed to run slow!
The senior people on the project solved this by opening up ad hoc
interrupt windows in the code. This led to many disasters.

(No comparison with the Plan 9 kernel is intended, of course.)

John A. Murdie
Department of Computer Science
University of York
England

Re: [9fans] micro vs monolithic kernels

[forsyth]

the nvram isn't important.  it will prompt for the values if necessary
and that's the easiest way to check that it is correctly booting the cpu server
kernel not the terminal kernel.  once that's going you can worry about setting
up the nvram.

i set a cpu/auth system up recently (without a separate file server).
i think this is what i did:

0. build /lib/ndb/local correctly; in many ways, the hard part.  you need to get
    the ipmask= and ipsubmask= and ip-net= set up to describe your network correctly.
    include proto=il in the entry for each plan 9 machine.
    include default auth= and fs= entries in the network or subnet entries.
1. cd /sys/src/9/pc; mk 'CONF=pccpudisk' install
2. 9fat: ; cp /386/9pccpudisk /n/9fat/9pccpudisk
3. change /n/9fat/plan9.ini, bootfile=sdC0!9fat!9pccpudisk  (replacing sdC0 by your disc name)
4. make sure /lib/ndb/auth contains

hostid=bootes
	uid=!sys uid=!adm uid=*

  this lets the cpu server believe that the auth server can vouch for others as described

5. cd /rc/bin/service; mv il566 _il566; mv tcp567 _tcp567
6. cd /rc/bin/service.auth; ensure the following contents
	tcp567:
		#!/bin/rc
		/bin/auth/auth.srv -d $3
	il566:
		#!/bin/rc
		/bin/auth/auth.srv -d $3
	chmod a+rx tcp567 il566
7. modify /rc/bin/cpurc to uncomment the lines that are commented-out:

	# uncomment the following for booting other systems
	ip/dhcpd
	ip/tftpd

	# services available to networks (remove -t /rc/bin/service.auth
	# if this isn't an auth server)
	auth/keyfs -m /mnt/keys /adm/keys
	aux/listen -q -d /rc/bin/service -t /rc/bin/service.auth il
	aux/listen -q -d /rc/bin/service -t /rc/bin/service.auth tcp
	auth/cron

   you can add a switch($sysname){ ... } to select different cpu server services
   if you've got more than one and only one is acting as auth server and file server.

8. if you're not setting up a separate file server (using the /sys/src/fs kernel) but are
   serving files from a kfs partition on the cpu/auth server, then further do
	8a.  cd /rc/bin/service; mv il17008 _il17008
	8b.  in /rc/bin/cpurc above, after starting auth/keyfs and before aux/listen do
		disk/kfscmd listen

Re: [9fans] micro vs monolithic kernels

[Dave Iafrate - CSCI/F1997]

Ok, I STILL NEED HELP installing this GREAT system!

one question does anyone find bell labs' documentation a poor disgrace to
software engineering's design process.
thats a better topic to consider...

Re: [9fans] micro vs monolithic kernels

[forsyth]

>>i seem to remember reading somewhere a reasoning on why it was chosen to
>>implement p9 with a monolithic kernel, instead of a micro one..

the implied comparison is false.  to start with, the plan 9 kernel
is not  `monolithic'.  it is highly modular.
in particular, the interfaces between the kernel and device drivers,
and between the IP device driver and its protocol and media drivers,
are all narrow, well-structured interfaces.  indeed, some things that
are implemented by `system calls' in other systems are just separable,
configurable device drivers in this one.

modularity is not in an `iff' relationship with structuring using message passing and processes.

another answer is possibly that they wanted it to do something useful.
perhaps there is a connection with cray's comment:

	If you were plowing a field what would you rather use, 2 strong oxen or 1024 chickens? -Seymour Cray

Re: [9fans] micro vs monolithic kernels

[presotto]

[-- Attachment #1: Type: text/plain, Size: 117 bytes --]

Because you need a brain the size of a planet to design a
microkernel based system and we only have egos that big.

[-- Attachment #2: Type: message/rfc822, Size: 2214 bytes --]

From: Andrey A Mirtchovski <aam396@mail.usask.ca>
To: 9fans@cse.psu.edu
Subject: [9fans] micro vs monolithic kernels
Date: Sun, 8 Apr 2001 11:55:22 -0600 (CST)
Message-ID: <Pine.GSO.4.10.10104081148380.17278-100000@ultra5d.usask.ca>

hello all,

i seem to remember reading somewhere a reasoning on why it was chosen to
implement p9 with a monolithic kernel, instead of a micro one..

i can't find the link anymore, so i'd like to ask for, either pointers to any
documents discussing this, or a brief explanation in an email from anyone,
who feels they can give me one..

let me state the question clearly: why did the bell-labs team chose to
implement plan9 using a monolithic kernel?


i realize that a comparative analysis of the two architectures can lead to a
flamefest, so i ask only for facts :)


andrey

[9fans] micro vs monolithic kernels

[Andrey A Mirtchovski]

hello all,

i seem to remember reading somewhere a reasoning on why it was chosen to
implement p9 with a monolithic kernel, instead of a micro one..

i can't find the link anymore, so i'd like to ask for, either pointers to any
documents discussing this, or a brief explanation in an email from anyone,
who feels they can give me one..

let me state the question clearly: why did the bell-labs team chose to
implement plan9 using a monolithic kernel?


i realize that a comparative analysis of the two architectures can lead to a
flamefest, so i ask only for facts :)


andrey