Re: [9fans] one reason ideas from Plan 9 didn't catch on

Re: [9fans] one reason ideas from Plan 9 didn't catch on

[presotto]

In the very recent past, I've installed Windows 98, Red Hat, and Plan 9.  I haven't
tried Debian yet so I can't say anything about it.

I must say, the hardest was Plan 9 although procedurally it was the easiest (less
questions, more ability to screw around if things did go wrong) although that
only helps if you have a basic familiarity with Plan 9.

The main problem was that the pre-patch system that's out there just doesn't go with
any hardware I could find at Avaya.  Everything I had was supported but only after
patches.  I ended up building a new kernel and 9load at bell labs, sticking them
onto the install floppy, along with an edited vgadb and going around the cycle
3 or 4 times till I got it right.  I couldn't build a kernel or 9load that would
work more generally because one with all the drivers is too big (to fit in 64k, to
fit compressed on a 1.4meg floppy, ...).  I know that precious few people could
have done the same.

The startup kernel for next release isn't going to fit on a floppy if we
don't change things.  We're (jmk and I mostly) considering suggestions
for what to do.
- One possibility is to build a kernel on the fly for people
downloading and have it contain the right drivers.  We get enough info from
the little question and answer session to set up plan9.ini.  That could keep
us going for a number of generations since it considerably reduces kernel size.
- Another is to have dynamicly linked drivers though that too would require
a prebuild since not all the drivers would fit on the floppy and drivers
with linkage info are larger.
- We could just give everyone login access to
a machine on the net and have them do their builds there and copy stuff
out as they see fit.
- We could also just start releasing CDROM's again where size wouldn't matter
as much.  We'ld need someone willing to make them.
- ???

Once I got a kernel/9load that worked, things went well till I wanted
to connect out.  Plan 9 is really crappy to customize once you've got a
stand-alone system up and running.  If noone else has done it, I'm about to start
on a GUI based configuration tool, sort of a collision between X86Config,
winipcnfig, and Wavelanconfig, ...  It needs to switch on something
(I'm assuming $menuitem) to pick a configuration; my laptop normally
wakes up tio find itself in any of 2 corporate networks and 3 ISP's.
DHCP/ppp/v6-resource-discovery doesn't provide enough info and often
has to be overriden so just depending on that isn't enough, you have
to be able to override/supplement.

Setting up plan 9 authentication is like giving birth through your eye ball.
That's all my fault.  Rsc, ehg, and I have been working on a new security architecture that
makes ssh, ssl, private passwords, etc. easier to keep track of and use,
sort of sshagent++, in addition to fixing the plan9 authentication.  I want
to get that out but it depends on getting the new system out which depends
on figuring out how to do a release better...

Finally, we just can't get releases put together fast enough.  We're now
a whole protocol behind so that we can't even send diffs out.  Part of that
is that this is a sideline for all of us.  We either need people as decicated
at putting releases together as linus and friends or we need a better way.  Perhaps
we should keep a machine on the internet with our more or less current
sources.  It wouldn't be as consistent as a release (man pages slightly out of
date, some things that might not build) but would be someplace to grab new
stuff from to try out.  I'ld prefer that to CVS since the bulk of the stuff
is still done at the labs without CVS.

All suggestions welcome.  Sorry for the long message.

Re: [9fans] one reason ideas from Plan 9 didn't catch on

[William Josephson]

On Tue, Nov 13, 2001 at 02:58:16PM -0500, presotto@closedmind.org wrote:

> - One possibility is to build a kernel on the fly for people
>downloading and have it contain the right drivers.  We get enough info from
>the little question and answer session to set up plan9.ini.  That could keep
>us going for a number of generations since it considerably reduces kernel size

> - We could also just start releasing CDROM's again where size wouldn't matter
> as much.  We'ld need someone willing to make them.

One of the big advantages of the current system is that I can make a
boot floppy off the net and then install the whole system over the
network, too.  Building a kernel on the fly has the advantage of
preserving this ability.  On the other hand, distributing a bootable
ISO image seems to have worked reasonably well with things like
FreeBSD and Linux.  Having a source of burned CDs is nice, too, of
course, but CD-R drives are pretty cheap anymore, so making people
burn their own (or maybe buy a copy from Vita Nuova) doesn't strike me
as too unreasonable.

I have yet to see anyone get installation "right" -- it never just
works in every case.  I have had by far the worst time with Windows on
the one or two occasions I made the mistake of trying to install it
myself.  Ugh.

 -WJ

Re: [9fans] one reason ideas from Plan 9 didn't catch on

[Mike Haertel]

>The startup kernel for next release isn't going to fit on a floppy if we
>don't change things.  We're (jmk and I mostly) considering suggestions
>for what to do.
>[possibilities elided]
>- ???

Why not split it into two floppies: one containing the kernel proper,
that prompts you to insert the 2nd floppy containing the file system
and all the user level programs.

[9fans] Installation mechanism

[Jim Choate]

I vote for a boot floppy with a CD. It's reasonably easy to get a 1G or
less image (not to mention network installs). It's be nice if the CD were
bootable itself.

On Tue, 13 Nov 2001, Mike Haertel wrote:

> >The startup kernel for next release isn't going to fit on a floppy if we
> >don't change things.  We're (jmk and I mostly) considering suggestions
> >for what to do.
> >[possibilities elided]
> >- ???
>
> Why not split it into two floppies: one containing the kernel proper,
> that prompts you to insert the 2nd floppy containing the file system
> and all the user level programs.


 --
    ____________________________________________________________________

             Day by day the Penguins are making me lose my mind.

                                             Bumper Sticker

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

Re: [9fans] Installation mechanism

[Mike Fletcher]

While we're talking installation procedures, has anyone
considered a 'partitionless' install similar to what
RedHat and Mandrake linux4win do?

It might attract some users who just can't be bothered to
re-partition their disks.  They'd just end up with a
regular FAT directory called plan9 containing 9fat and two
large disk image files called fs and swap.

Then bootfile=sdC0!plan9!9fat!9pcdisk
 and bootdisk=local!#S/sdC0/plan9/fs
and away you go.

Just a thought.  I'd work on it if I had a clue of where
to start...

-Mike Fletcher
 EECS Dept.
 Tulane University

Re: [9fans] one reason ideas from Plan 9 didn't catch on

[George Michaelson]

> Setting up plan 9 authentication is like giving birth through your eye ball.

This wins my grossest analogy of the year award. EUGHHHHH!

> That's all my fault.  Rsc, ehg, and I have been working on a new security
> architecture that makes ssh, ssl, private passwords, etc. easier to keep
> track of and use, sort of sshagent++, in addition to fixing the plan9
> authentication.

This both intrigues and worries me. I use ssh-agent a lot, but I have huge
lingering worries that the chain of open FD back through process history
and the IPC mechanisms is a gaping yaw of risk.

Wouldn't a kerberos tkt like mechanism pose less risks? Isn't the pain of
occaisional re-authentication purposeful? I exclude systems like the SUNray
where a physical token can be removed and moved to carry the auth info.

Having said which, if Plan9 has a clean abstraction for this (and the little
I understand about the mechanisms suggest this strongly) then its a wonderful
idea.

Doesn't it also pose risks for loss of that parent ssh-agent-like thing?

cheers
	-george
--
George Michaelson       |  APNIC
Email: ggm@apnic.net    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490  |  Australia
  Fax: +61 7 3367 0482  |  http://www.apnic.net

[9fans] Startup kernel thoughts

[Chris Hollis-Locke]

----- Original Message -----
From: <presotto@closedmind.org>
To: <9fans@cse.psu.edu>
Sent: Tuesday, November 13, 2001 7:58 PM
Subject: Re: [9fans] one reason ideas from Plan 9 didn't catch on


>
> The startup kernel for next release isn't going to fit on a floppy if we
> don't change things.  We're (jmk and I mostly) considering suggestions
> for what to do.

Given load-time driver linkage (I'm not sure of the value of completely
'dynamic' loading) a first step could be a probe that details a manifest
of files to download and put on the install floppy.

In true Plan 9 style, the manifest could be a list of rc commands for
constructing the floppy
(not sure how you'd get them from the target h/w to a p9 box though -
probably write them back to the floppy you ran the probe from)
The probe could be kept up-to-date with the available kernels/drivers, so could
also be used as a "can this hardware run Plan 9?" test program.

The obvious downsides are
* it adds several steps to the install procedure
* individual drivers are fatter, though only the required drivers
  are on the floppy.
* god-knows who would have the time to implement/maintain it!

Re: [9fans] one reason ideas from Plan 9 didn't catch on

[William Josephson]

On Wed, Nov 14, 2001 at 08:54:53AM +1000, George Michaelson wrote:

> > That's all my fault.  Rsc, ehg, and I have been working on a new security
> > architecture that makes ssh, ssl, private passwords, etc. easier to keep
> > track of and use, sort of sshagent++, in addition to fixing the plan9
> > authentication.
>
> This both intrigues and worries me. I use ssh-agent a lot, but I have huge
> lingering worries that the chain of open FD back through process history
> and the IPC mechanisms is a gaping yaw of risk.

I personally refuse to use ssh-agent and avoid ssh X11 forwarding
because I don't trust either to get this sort of thing right.  I'll
leave it to Presotto to discuss the system in detail, but they've done
a lot of thinking about this sort of problem.

> Wouldn't a kerberos tkt like mechanism pose less risks? Isn't the pain of
> occaisional re-authentication purposeful? I exclude systems like the SUNray
> where a physical token can be removed and moved to carry the auth info.

It isn't tied to a particular protocol.

> Having said which, if Plan9 has a clean abstraction for this (and the little
> I understand about the mechanisms suggest this strongly) then its a wonderful
> idea.

> Doesn't it also pose risks for loss of that parent ssh-agent-like thing?

It serves a similar purpose and ssh-agent is probably the closest
thing under Unix.  Unlike Unix, Plan 9 has per-process namespaces (and
single-user terminals).  You end up having to trust the kernel either
way, of course.

 -WJ