[9fans] First-timer help

[John Floren]

Hi.
I just installed Plan 9 on an old machine, and I'm having a bit of
trouble. I am used to Linux, so any comparisons you might make to Linux
should make sense to me.
First, I installed Plan 9 from CD with the fossil file system. It
installed just fine; when I rebooted, I chose to login as "glenda" and
came up with a nice screen. Now I want to add some other users, but I
haven't had much luck. I tried "con /srv/fscons" and then typing "uname
john john", then quitting. I then ran "auth/changeuser john" and tried
to set my password, but I got a "permission denied" error. Help?
I am also a bit confused about how to login/logout. Do you have to
reboot every time you want to change users?
Thanks

John F.
--
http://nuwen.net/~digi/cluster
Be sure to evaluate the bird-hand/bush ratio.

[andrey mirtchovski]

start with this one:

http://cm.bell-labs.com/wiki/plan9/plan_9_wiki/index.html

yes, you do have to reboot when you want to change users. make sure you log
in as the new user when you run auth/changeuser.

[andrey mirtchovski]

> yes, you do have to reboot when you want to change users. make sure you log
> in as the new user when you run auth/changeuser.

make that '/sys/lib/newuser', my bad

[John Floren]

Gorka guardiola wrote:
> http://www.cs.bell-labs.com/wiki/plan9/Adding_a_new_user/
>
> After, when you log in for the first time run
> /sys/lib/newuser
>
> look at the wiki (url above) for this kind of information.
I've already read through the wiki. I did run newuser after I manager
to login as my new user. However, I still cannot set any passwords, so
logging in is kinda insecure.
And why do you have to reboot in order to change users? UNIX has had
that from the beginning, and I don't see any reason to drop it.
Thanks

> On 7/17/05, John Floren <***@moseslake-wa.com> wrote:
>
>>Hi.
>>I just installed Plan 9 on an old machine, and I'm having a bit of
>>trouble. I am used to Linux, so any comparisons you might make to Linux
>>should make sense to me.
>>First, I installed Plan 9 from CD with the fossil file system. It
>>installed just fine; when I rebooted, I chose to login as "glenda" and
>>came up with a nice screen. Now I want to add some other users, but I
>>haven't had much luck. I tried "con /srv/fscons" and then typing "uname
>>john john", then quitting. I then ran "auth/changeuser john" and tried
>>to set my password, but I got a "permission denied" error. Help?
>>I am also a bit confused about how to login/logout. Do you have to
>>reboot every time you want to change users?
>>Thanks
>>
>>John F.
>>--
>>http://nuwen.net/~digi/cluster
>>Be sure to evaluate the bird-hand/bush ratio.
>>
>
>
>


--
http://nuwen.net/~digi/cluster
<knghtbrd> He's a about half the size of the others.
<knghtbrd> But he's got a chainsaw.

[andrey mirtchovski]

> And why do you have to reboot in order to change users? UNIX has had
> that from the beginning, and I don't see any reason to drop it.

this isn't unix :)

the single most-important reason to switch users (do something as
root) does not exist here, hence nobody bothered. when you set up a
proper file/cpu/auth server on which you're going to have more than
one users then you can always log in as the administrative user
(bootes, in most cases) remotely or on the console of the server and
administer. if you only have a standalone, single-user machine you're
considered its owner.

in short, you'll need to set-up a standalone cpu/auth server to get
passwords. the instructions are on the wiki.

have you read "plan 9 from bell-labs" and "security in plan9"? they
contain some of the rationale for this setup.

[John Floren]

andrey mirtchovski wrote:
>>And why do you have to reboot in order to change users? UNIX has had
>>that from the beginning, and I don't see any reason to drop it.
>
>
> this isn't unix :)
>
> the single most-important reason to switch users (do something as
> root) does not exist here, hence nobody bothered. when you set up a
> proper file/cpu/auth server on which you're going to have more than
> one users then you can always log in as the administrative user
> (bootes, in most cases) remotely or on the console of the server and
> administer. if you only have a standalone, single-user machine you're
> considered its owner.
So when I'm not around and somebody decides to boot the computer and
delete all my files, that's just okay then?
> in short, you'll need to set-up a standalone cpu/auth server to get
> passwords. the instructions are on the wiki.
>
> have you read "plan 9 from bell-labs" and "security in plan9"? they
> contain some of the rationale for this setup.
>
> .
>


--
http://nuwen.net/~digi/cluster
<knghtbrd> He's a about half the size of the others.
<knghtbrd> But he's got a chainsaw.

[andrey mirtchovski]

> So when I'm not around and somebody decides to boot the computer and
> delete all my files, that's just okay then?

sure, it happens to me all the time :)

would you like an account on one of the open-to-everybody Plan 9
installations to see how it looks and feels in a real environment?
if yes, check http://www.9grid.de or http://www.tip9ug.jp

[John Floren]

andrey mirtchovski wrote:
>>So when I'm not around and somebody decides to boot the computer and
>>delete all my files, that's just okay then?
>
>
> sure, it happens to me all the time :)
>
> would you like an account on one of the open-to-everybody Plan 9
> installations to see how it looks and feels in a real environment?
> if yes, check http://www.9grid.de or http://www.tip9ug.jp
>
> .
>
I've already sent an account request to the Japanese grid; I'll check
out the German one as well. So, on one of these big installations, the
files are better protected, yes?
Thanks

Digi
--
http://nuwen.net/~digi/cluster
<knghtbrd> He's a about half the size of the others.
<knghtbrd> But he's got a chainsaw.

[andrey mirtchovski]

> I've already sent an account request to the Japanese grid; I'll check
> out the German one as well.

there's a US "free-for-al"l Plan 9 installation too, which may be closer
to you: http://www.9grid.us

> So, on one of these big installations, the
> files are better protected, yes?

generally -- yes. only its owner (the user who started the file
server) can access the administrative "area" on a file server, i.e.
/srv/fscons. there's only a single point of entry to allow one to
modify files belonging to other users and that is the rather
complicated dance of connecting to /srv/fscons, changing permissions
of a file, disconnecting and then modifying it.

if you feel adventurous you can set up an old-style (ken fs, as they're
called) file server which completely disallows the running of any user
processes. on such machine there's no way to modify another user's
files unless you're behind the keyboard/console of the machine or the
user changes permissions to allow you to do so.

if you add your user to the group 'sys' you will be able to handle
most daily administrative tasks such as updating the system or
recompiling binaries from sources. that's why most directories are
group-writable and those bits are extended recursively when creating
new files.

andrey

[Charles Forsyth]

>>So when I'm not around and somebody decides to boot the computer and
>>delete all my files, that's just okay then?

they could anyway, at least with Linux. (boot the installation/recovery
CD and get a root shell. even without the shell, at the very least all
the ones i've used recently allow me to wipe an existing installation
and replace it with a new one. i enjoy that.)

[Dave Lukes]

On 18 Jul 2005, at 00:17, Charles Forsyth wrote:

>>> So when I'm not around and somebody decides to boot the computer and
>>> delete all my files, that's just okay then?
>
> they could anyway, at least with Linux. (boot the
> installation/recovery
> CD and get a root shell. even without the shell, at the very least all
> the ones i've used recently allow me to wipe an existing installation
> and replace it with a new one. i enjoy that.)

This is all interesting but pretty much irrelevant.

If you store data on a machine to which other people have physical
access,
there are many simple ways for them to remove or tamper with it.

Many of these methods (powerful magnet, hammer, open the case and steal
the drive(s))
are pretty much hardware- and OS-independent.

"This system is secure until removed from the hermetically sealed
Faraday caged concrete box".

That is one of the reasons why plan9 regards "your computer" as being
a network terminal with some computing capability rather than a
mainframe on your desktop.

DaveL.

[l***@proxima.alt.za]

> "This system is secure until removed from the hermetically sealed
> Faraday caged concrete box".

>From the "I can't resist a jab" department: Windows NT (3.51, if
memory serves) was C2-certified, on condition it wasn't networked. I
wonder if anything in that area has changed?

No need for me to emphasise the futility of the certification.

++L

[Ronald G. Minnich]

On Sun, 17 Jul 2005, John Floren wrote:

> So when I'm not around and somebody decides to boot the computer and delete
> all my files, that's just okay then?

this is not unix. It is really not unix. The question you are posing makes
no real sense.

By now, somebody has answered better than this, but I thought I would
reinforce the message.

ron

[a***@ar.aichi-u.ac.jp]

On Sun, 17 Jul 2005, John Floren wrote:

> So when I'm not around and somebody decides to boot the computer and
> delete
> all my files, that's just okay then?

this remind me that I forgot win2000 password.
I decided to reboot the computer and reinstalled the OS.
I didn't know how to rescue my data.

Yes, that should be OK.

Kenji Arisawa

[Tim Wiess]

> I've already read through the wiki. I did run newuser after I manager
> to login as my new user. However, I still cannot set any passwords, so
> logging in is kinda insecure.

The user authentication methods used in P9 are a little different than
unix. Read up on keyfs(4) and factotum(4). Basically P9 was designed
to have terminals authenticate themselves to a separate CPU or
authentication server.


> And why do you have to reboot in order to change users? UNIX has had
> that from the beginning, and I don't see any reason to drop it.

Again P9's an entirly different system. There are many
similarities with Unix, but there are far more differences. And
thinking in terms of Unix when dealing with P9 will most likely
just lead to frustration and confusion.

It may take a little time to get over the hurdle of adapting to a
new environment, but your paitence and efforts will be rewarded
many times over.

If you haven't already, start reading the docs in /sys/doc or
http://www.cs.bell-labs.com/sys/doc/

[a***@ar.aichi-u.ac.jp]

> Gorka guardiola wrote:
>> http://www.cs.bell-labs.com/wiki/plan9/Adding_a_new_user/
>> After, when you log in for the first time run
>> /sys/lib/newuser
>> look at the wiki (url above) for this kind of information.
> I've already read through the wiki. I did run newuser after I manager
> to login as my new user. However, I still cannot set any passwords,
> so logging in is kinda insecure.
> And why do you have to reboot in order to change users? UNIX has had
> that from the beginning, and I don't see any reason to drop it.
> Thanks
>

If you do want something like UNIX su command,
try
http://plan9.aichi-u.ac.jp/netlib/cmd/su-1.4/

su is useful if you want instantaneously your user ID.

Kenji Arisawa

[a***@ar.aichi-u.ac.jp]

sorry

> su is useful if you want instantaneously your user ID.
>

change to:
su is useful if you want instantaneously change your user ID.

Kenji Arisawa

[davide+ (Dave Eckhardt)]

> I then ran "auth/changeuser john" and tried to set my password,
> but I got a "permission denied" error. Help?

My apologies for the vague answer, but: every time I've run
auth/changeuser (running as bootes on my auth/fossil/venti file
server) I've got a "permission denied" error which appears to be
harmless, since the accounts are created and people can log in.
I haven't chased it down beyond that.

> And why do you have to reboot in order to change users?
> UNIX has had that from the beginning, and I don't see any
> reason to drop it.

Plan 9 was designed around a particular distributed system
architecture (see the "Plan 9 From Bell Labs" paper at
http://cm.bell-labs.com/sys/doc/index.html). There are
basically three kinds of machine:

* critical infrastructure, such as authorization and reliable file
storage, which define identity and trust for the multi-user
computing environment--these are typically accessible by only
trusted system administrators and located in physically secure
environmentally-controlled locations,

* shared "CPU servers", whose configuration, policies, and hardware
are owned by the system administrators, but which can be used
in a restricted fashion by multiple users simultaneously,

* public-access "terminals", which will allow any user to boot
them running any code--think of a standard PC, where whoever
sticks a floppy into the drive can do anything they wish.

Other models are possible. For example, Amoeba was designed
for "processor pools", racks of CPU servers each one of which
was used by one user at a time.

In order to have multiple users running on a public-access
terminal, you have to define what you would mean by that,
which isn't easy. Who should own a particular serial line
or USB port? If Alice boots a kernel she just wrote, should
Bob trust it to keep his password secret? Should Bob be able
to reboot the machine to use a different kernel if Alice is
running some long computation?

These questions are architecturally answered for Plan 9 file
servers (nobody logs in), and CPU servers (people can log in,
but not reboot, modify configuration, or control hardware).
The answer for terminals is "one person owns the machine at
a time and can do anything to it". Rebooting is a simple
way to ensure that *everything* on the machine belongs to
one user at a time.

Dave Eckhardt

[Charles Forsyth]

>>Rebooting has been easy enough, so we haven't bothered to put
>>more complexity into the system to make changing users easier.

also if you are certain you've rebooted (eg, little reset button
or perhaps power cycle) there's much less chance that preceding
person using the same terminal has left something lurking
(such as a fake login screen for instance, which UNIX has had
almost from the beginning)

[Martin C. Atkins]

On Mon, 18 Jul 2005 00:12:44 +0100 Charles Forsyth <***@terzarima.net> wrote:
> >>Rebooting has been easy enough, so we haven't bothered to put
> >>more complexity into the system to make changing users easier.
>
> also if you are certain you've rebooted (eg, little reset button
> or perhaps power cycle) there's much less chance that preceding
> person using the same terminal has left something lurking
> (such as a fake login screen for instance, which UNIX has had
> almost from the beginning)

I understand, and in many situations agree with, all the
arguments for re-booting to change users.

Nevertheless, I must add that this is one reason why I haven't
installed Plan9 on my systems at home - there are more people than
computers here, and I can't lose all my context (of active windows,
etc), when my wife needs to check her email, or my daughter wants to
paint a picture....

There are environments where you can be reasonably sure that a trojan
hasn't been installed (and security amoungst the people with physical
access isn't that important either), but where you really do want to
be able to change your identity/context without re-booting. Linux
virtual consoles are a great solution (although not 100% reliable, in
my experience).

Martin

--
Martin C. Atkins ***@parvat.com
Parvat Infotech Private Limited http://www.parvat.com{/,/martin}

[Steve Simon]

> ...I can't lose all my context (of active windows,
> etc), when my wife needs to check her email, ...

If you have a cpu server then you can always cpu to it as a different
user using the -u option. If you have just a single standalone machine
you can do the same by running keyfs and listen in /bin/termrc.local

This does not give the new user ownership of your terminal's devices
so some some more fiddling is needed - E.G. you will need to start another
factotum and upas/fs. It does give you somthing like unix's su(1) command
but that is what you would use under *nix isn't it?

-Steve

[Tim Newsham]

> This does not give the new user ownership of your terminal's devices
> so some some more fiddling is needed - E.G. you will need to start another
> factotum and upas/fs. It does give you somthing like unix's su(1) command
> but that is what you would use under *nix isn't it?

There's already an su-like tool: auth/login (excercise for the reader:
alter auth/login to allow the host owner to switch without providing a
password). You can also switch users more violently with the cons
filesystem (/dev/hostowner).

> -Steve

Tim Newsham
http://www.lava.net/~newsham/

[a***@ar.aichi-u.ac.jp]

> There's already an su-like tool: auth/login (excercise for the reader:
> alter auth/login to allow the host owner to switch without providing a
> password). You can also switch users more violently with the cons
> filesystem (/dev/hostowner).
>

su is already exist that allow the host owner to switch without
providing a password.
I wrote:
> If you do want something like UNIX su command,
> try
> http://plan9.aichi-u.ac.jp/netlib/cmd/su-1.4/
>
> su is useful if you want instantaneously change your user ID.
>

Kenji Arisawa

[l***@proxima.alt.za]

> Nevertheless, I must add that this is one reason why I haven't
> installed Plan9 on my systems at home - there are more people than
> computers here, and I can't lose all my context (of active windows,
> etc), when my wife needs to check her email, or my daughter wants to
> paint a picture....

I was thinking, when Russ suggested that the infrastructure for
changing ID without rebooting was a possibility, that we'd lose the
extreme reliability of the current approach. That need not be true,
either, as the reboot option is unlikely to go away.

That said, a stand-alone Plan 9 device seems to need better
specification, I'm sure a CPU server is perfectly capable of sharing
its console to different users at different times. But different
logins on different windows (as Martin seems to suggest) would be more
complicated. I guess somebody ought to give the idea some careful
thought and suggest an implementation. Specially where we actually
want the stand-alone device to be more of a workstation than a CPU
server, yet we need local authentication and device management.

++L

[Martin C. Atkins]

On Mon, 18 Jul 2005 12:45:32 +0200 ***@proxima.alt.za wrote:
> > Nevertheless, I must add that this is one reason why I haven't
> > installed Plan9 on my systems at home - there are more people than
> > computers here, and I can't lose all my context (of active windows,
> > etc), when my wife needs to check her email, or my daughter wants to
> > paint a picture....
>
> I was thinking, when Russ suggested that the infrastructure for
> changing ID without rebooting was a possibility, that we'd lose the
> extreme reliability of the current approach. That need not be true,
> either, as the reboot option is unlikely to go away.

The other approach, that might "just happen" without specific
development effort in Plan 9, is that if/when Xen provides graphical
screens for virtual machines, then it should be possible to run a
cpu/file server, and a terminal for each user, each on their own
virtual screen, switching between them somewhat like virtual
consoles. (Of course, in principle, I could do that today with
Vmware, if I had enough memory, etc.)

[Of course, this would mean that everything would have to be running
on top of Linux/whatever...]

> That said, a stand-alone Plan 9 device seems to need better
> specification, I'm sure a CPU server is perfectly capable of sharing
> its console to different users at different times. But different
> logins on different windows (as Martin seems to suggest) would be more
> complicated. I guess somebody ought to give the idea some careful
> thought and suggest an implementation. Specially where we actually
> want the stand-alone device to be more of a workstation than a CPU
> server, yet we need local authentication and device management.

Agreed.

Allowing some form of su (as was suggested elsewhere) is very useful,
but isn't really an answer to my problem. Also the
drawterm-on-top-of-a screensaver idea (while a nice bit of lateral
thinking!) also wouldn't be very satisfactory, because the reverse
problem then occurs: we lose the context in the drawterm when going
back to the underneath "original" session (and how would it nest
further?).

Again (I'm sorry to say): Linux virtual consoles work very well,
since all the logins are "at the same level". One can also screenlock
a session, and let someone use another virtual console, reasonably
sure that they can't fiddle with your session. (assuming the other
security mechanisms are working 'correctly')

BTW: This problem is even more acute when travelling, and we only want
to carry one laptop as a family, and carry it around with all our
personal sessions suspended.

This is the counter example for Bill Gates' infamous "your computer
should be as personal as your underwear" gaff - unfortunately, this
seems to be the philosophy for Plan 9 terminals, currently. big :-)

[Although I should reiterate that I think the situation can be quite
different in other environments - such as offices and terminal
classrooms - where rebooting makes lots of sense.]

Moving to solutions, rather than problem statements: wouldn't the
"Plan 9 way" of dealing with this be to run a multiplexer process
pre-login, that multiplexes access to /dev/draw(etc) across several
virtual consoles, and puts a login process in each one? Could that be
done with the current mechanisms? I guess it would have worked with 8
1/2, but maybe it is more difficult with the rio approach (I don't
know)? I also don't know if this is consistent with the way /dev/user
(etc) work. Comments anyone?

Martin
--
Martin C. Atkins ***@parvat.com
Parvat Infotech Private Limited http://www.parvat.com{/,/martin}

[Axel Belinfante]

> Allowing some form of su (as was suggested elsewhere) is very useful,
> but isn't really an answer to my problem. Also the
> drawterm-on-top-of-a screensaver idea (while a nice bit of lateral
> thinking!) also wouldn't be very satisfactory, because the reverse
> problem then occurs: we lose the context in the drawterm when going
> back to the underneath "original" session (and how would it nest
> further?).

not a plan 9 way, but could using vnc make a difference here?
(or something similar)
I tend to have a long-running 'persistent' vnc session on a server
at work, and pick up (connect to) the session whereever I am.

Axel.

[Ronald G. Minnich]

On Tue, 19 Jul 2005, Martin C. Atkins wrote:

> [Of course, this would mean that everything would have to be running
> on top of Linux/whatever...]

unless/until we do a Xen dom0 for plan 9, which in fact would not be that
hard.

ron

[Martin C. Atkins]

On Tue, 19 Jul 2005 07:57:17 -0600 (MDT) "Ronald G. Minnich" <***@lanl.gov> wrote:
> On Tue, 19 Jul 2005, Martin C. Atkins wrote:
> > [Of course, this would mean that everything would have to be running
> > on top of Linux/whatever...]
>
> unless/until we do a Xen dom0 for plan 9, which in fact would not be that
> hard.
>
> ron

Now *that* would be very interesting - not just for this discussion,
but also for completely unrelated reasons (are you reading this Wes?).

Martin

--
Martin C. Atkins ***@parvat.com
Parvat Infotech Private Limited http://www.parvat.com{/,/martin}

[Charles Forsyth]

using VM/386 to multiplex window sessions is rather like virtualising the
Unix system call layer to allow several IP stacks. it seems just
a little heavy-handed. there is actually little difference between
multi-user cpu servers and single-user terminals as far as the plan 9 kernel is concerned:
mainly configuration and a few small policy differences.

if each user is given a rio session, much as martin suggested,
and it has its own name space (as with newns)
it will use its own attach to the file server, and
thus run with the desired file permissions.

/dev/user can be set using cap(3).

the host owner (/dev/hostowner) owns all devices, including cap(3),
which works well in existing use `as intended', but for non-overlapping shared
use of a single-user terminal would probably require something
to set hostowner when it switches to a given user's session.

the draw devices would all change ownership too, but if that makes
things too open (because the current user can see all window contents),
then it probably isn't hard to record ownership on draw directories
(as for /net/tcp directories and a few other devices).

the more serious problem is that there isn't a good paint program.

[Skip Tavakkolian]

would aan + drawterm be a solution?

> using VM/386 to multiplex window sessions is rather like virtualising the
> Unix system call layer to allow several IP stacks. it seems just
> a little heavy-handed. there is actually little difference between
> multi-user cpu servers and single-user terminals as far as the plan 9 kernel is concerned:
> mainly configuration and a few small policy differences.
>
> if each user is given a rio session, much as martin suggested,
> and it has its own name space (as with newns)
> it will use its own attach to the file server, and
> thus run with the desired file permissions.
>
> /dev/user can be set using cap(3).
>
> the host owner (/dev/hostowner) owns all devices, including cap(3),
> which works well in existing use `as intended', but for non-overlapping shared
> use of a single-user terminal would probably require something
> to set hostowner when it switches to a given user's session.
>
> the draw devices would all change ownership too, but if that makes
> things too open (because the current user can see all window contents),
> then it probably isn't hard to record ownership on draw directories
> (as for /net/tcp directories and a few other devices).
>
> the more serious problem is that there isn't a good paint program.

[Martin C. Atkins]

On Tue, 19 Jul 2005 16:38:40 +0100 Charles Forsyth <***@terzarima.net> wrote:
> using VM/386 to multiplex window sessions is rather like virtualising the
> Unix system call layer to allow several IP stacks. it seems just

I completely agree that it would be a sledge hammer to crack a nut in
this case. VM/x86 does give you somewhat more than just solving the
current tread topic, though...

> a little heavy-handed. there is actually little difference between
> multi-user cpu servers and single-user terminals as far as the plan 9 kernel is concerned:
> mainly configuration and a few small policy differences.
etc

That is nice to hear. I seem to understand more than I realised :-)!

> the more serious problem is that there isn't a good paint program.

My daughter would agree with that!

Martin

--
Martin C. Atkins ***@parvat.com
Parvat Infotech Private Limited http://www.parvat.com{/,/martin}

[Tim Newsham]

> using VM/386 to multiplex window sessions is rather like virtualising the
> Unix system call layer to allow several IP stacks. it seems just
> a little heavy-handed. there is actually little difference between
> multi-user cpu servers and single-user terminals as far as the plan 9 kernel is concerned:
> mainly configuration and a few small policy differences.

I don't think he was suggesting a seperate DomU per user, but
rather a seperate (virtual) graphics device per user. I
think the xen approach will be to use the VNC protocol to provide
access to DomU graphics. I don't see why multiple VNC's couldnt
be supported.

> the host owner (/dev/hostowner) owns all devices, including cap(3),
> which works well in existing use `as intended', but for non-overlapping shared
> use of a single-user terminal would probably require something
> to set hostowner when it switches to a given user's session.

Why not just change permissions on the various devices that
a user would want to access (ie. mouse, video and audio). Or
probably better -- just multiplex these and provide a virtual
device. How hard would it be to make a generic multiplexer
that took in a filesystem prototype file and then virtualized
access to each of the devices for a number of children processes?

> the more serious problem is that there isn't a good paint program.

Nor internet chess client ;-)

Tim Newsham
http://www.lava.net/~newsham/

[Brian L. Stuart]

In message <***@localhost.localdomain>, "Martin C. Atkins"
writes:
>On Mon, 18 Jul 2005 12:45:32 +0200 ***@proxima.alt.za wrote:
>"Plan 9 way" of dealing with this be to run a multiplexer process
>pre-login, that multiplexes access to /dev/draw(etc) across several
>virtual consoles, and puts a login process in each one? Could that be
>done with the current mechanisms? I guess it would have worked with 8

I've avoided chiming in on this one because the whole thing
seemed a very non-Plan 9 thing and because I've never worked
that way or needed that behavior. But this suggestion has
piqued my interest.

>From the user's perspective I'm picturing something along the
lines of a new menu entry in rio that is, say, Suspend. When
that is selected, the current set of windows all "go away"
(really hidden but no longer accessible from the menu) and
are replaced by a dialog that lets you select a suspended
session or to start a new one. Both options would require
a password. As other's have mentioned, this password doesn't
provide any real security. It's just there to make it hard
for your daughter to save her latest artistic masterpiece
on top of your latest coding masterpiece.

As to implementation, I'm thinking that on boot the multiplexer
starts up running as the machine owner. As has also been
mentioned, it has a capability to change /dev/user which
it does each time it brings up a new or suspended session.
On creating a new session, it creates a new child process
running as the new user and serves the usual /dev stuff to
the child process. The only change to rio would be the new
menu entry that would result in a note to the multiplexer
or a message to some other file it serves. The behavior
could either be controlled by a command line switch or
rio could look for the multiplexer process and do the right
thing when it's found.

I know from experience how dangerous it can be to throw
out ideas as I think them up. But it's up the flagpole
now. Anybody interested in saluting or is this one that
would be better off burried?

BLS

[Tim Newsham]

> also if you are certain you've rebooted (eg, little reset button
> or perhaps power cycle) there's much less chance that preceding
> person using the same terminal has left something lurking
> (such as a fake login screen for instance, which UNIX has had
> almost from the beginning)

Yah, now you're just trusting the bios, the local disk (if any)
and the network. Much more secure ;-)

Tim Newsham
http://www.lava.net/~newsham/

[Ronald G. Minnich]

On Wed, 20 Jul 2005, Tim Newsham wrote:

> Yah, now you're just trusting the bios, the local disk (if any)
> and the network. Much more secure ;-)

it will be even more fun with the newer BIOSes (e.g. EFI) that support
arbitrary driver modules, tasks, and can even run programs. All stored on
a flash file system on the mainboard.

This will make life interesting.

ron

[Richard Miller]

> it will be even more fun with the newer BIOSes (e.g. EFI) that support
> arbitrary driver modules, tasks, and can even run programs. All stored on
> a flash file system on the mainboard.

Didn't HP (many years ago) make a desktop machine with Unix in ROM?

-- Richard

[Charles Forsyth]

>>Didn't HP (many years ago) make a desktop machine with Unix in ROM?

i believe it was the inspiration for subsequent clones: nothing ever really can change.

[Wes Kussmaul]

Richard Miller wrote:

> Didn't HP (many years ago) make a desktop machine with Unix in ROM?

Wasn't someone who's very familiar to us involved in LinuxBIOS?

--
Wes Kussmaul
CIO
The Village Group
738 Main Street
Waltham, MA 02451

781-647-7178


The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s)
and may contain confidential or privileged information. If you are not
the intended recipient, please notify attorney Mort Hapless at Vulner,
Exposed & Wideopen LLP immediately at either [phone], or at
***@vulex.com, and destroy all copies of this message and any
attachments. No, really. Really. Listen, we mean it! Hey, if you don’t
stop reading that confidential stuff about our client you’re in big
trouble. OK, we’re the ones in trouble but we’ll find a way to go after
you, or at least we think we may be able to. Look, we’re begging you.
Just click the delete button and move on to a message that concerns you,
OK? Please?? We'll buy you lunch...

Identity is the Foundation of Security™. Let The Village Group
(village.com) ensure that only intended recipients receive your
confidential messages.

[davide+ (Dave Eckhardt)]

>> also if you are certain you've rebooted (eg, little reset button
>> or perhaps power cycle) there's much less chance that preceding
>> person using the same terminal has left something lurking

> Yah, now you're just trusting the bios, the local disk (if any)
> and the network. Much more secure ;-)

If you can't trust the BIOS, you can't trust *anything* about
the machine. There are business-card-sized CD-R's, so if you
do trust the BIOS you can have a read-only bootable system in
your wallet at all times. If you use the disk only for a
"cfs -r", you don't need to trust its contents.

What's the nature of the interaction between factotum and the
auth server? If somebody who owns the network can interpose
themselves between you and the auth server, can they end up
with your password, or at least authenticate once as you?

Dave Eckhardt

[Wes Kussmaul]

Dave Eckhardt wrote:

> If you can't trust the BIOS, you can't trust *anything* about
> the machine.

I want a bios that is digitally signed by multiple properly-enrolled
professionally licensed individuals, with those licenses being signed by
city hall. The licenses should include:

code developer
code auditor
building inspector

None of these should be the usual worthless organizational code signing
signatures. (Right after the serpent said "try this fruit" he added, "by
the way, it's ok if the 'Arthur Andersen' signature means 'a bunch of
people collectively calling themselves Arthur Andersen.") The biometrics
of the signers should be on file, signed by the enrollment officer, who
is a Latin Notary.

The bios should be able to do only one thing: hand over control to a
similarly code-signed hypervisor, and only if everything is kosher.

> There are business-card-sized CD-R's, so if you
> do trust the BIOS you can have a read-only bootable system in
> your wallet at all times.

LNX-BBC is a good one:

http://www.lnx-bbc.org/

However: a cd will last about a month in your wallet before it's no
good. Unless you have a rigid wallet.

--
Wes Kussmaul
CIO
The Village Group
738 Main Street
Waltham, MA 02451

781-647-7178


The information contained in this electronic message and any attachments
to this message are intended for the exclusive use of the addressee(s)
and may contain confidential or privileged information. If you are not
the intended recipient, please notify attorney Mort Hapless at Vulner,
Exposed & Wideopen LLP immediately at either [phone], or at
***@vulex.com, and destroy all copies of this message and any
attachments. No, really. Really. Listen, we mean it! Hey, if you don’t
stop reading that confidential stuff about our client you’re in big
trouble. OK, we’re the ones in trouble but we’ll find a way to go after
you, or at least we think we may be able to. Look, we’re begging you.
Just click the delete button and move on to a message that concerns you,
OK? Please?? We'll buy you lunch...

Identity is the Foundation of Security™. Let The Village Group
(village.com) ensure that only intended recipients receive your
confidential messages.

[Tim Newsham]

>> Yah, now you're just trusting the bios, the local disk (if any)
>> and the network. Much more secure ;-)
>
> If you can't trust the BIOS, you can't trust *anything* about
> the machine.

The original thread mentioned false login screens that people
can leave running in unix. What I meant to imply (perhaps too
subtly) was that you can configure the BIOS to boot a malicious
plan9 kernel (by adjusting bios parameters, by leaving a
boot block on the disk, or by interposing on the network boot
process). Rebooting the machine does not necessarily give you
strong assurances against trojan login screens. (Of course
it can, if configured properly -- ie trusted booting of signed
binaries).

Sure you can put a tiny cdr into the drive, but what if the
bios doesn't even boot the cdr (or refuses to, and has a password).
What if it boots the hard drive while making it look like its
booting the CDR?

> Dave Eckhardt

Tim Newsham
http://www.lava.net/~newsham/

[davide+ (Dave Eckhardt)]

> Sure you can put a tiny cdr into the drive, but what if the bios
> doesn't even boot the cdr (or refuses to, and has a password).
> What if it boots the hard drive while making it look like its
> booting the CDR?

But my hypothetical CD-R kernels all print "Say farewell to Nova
Scotia" on the screen just before entering user space for the first
time. Or maybe it's only the kernels I boot on Mondays which use
that particular message.

Of course, *any* trust placed in a computing device other people
have control over is risky (much fun could be had by storing away
compressed snapshots of video memory every 5 minutes...all you
need is a way to convince my kernel to call into the BIOS
periodically...hmmm...how about that APM entry point?).

You always need to draw a line somewhere.

Dave Eckhardt

[Charles Forsyth]

looking at it the other way, i'm quite grateful that the
bios will still let me boot something other than windows (or linux)

[Ronald G. Minnich]

On Thu, 21 Jul 2005, Dave Eckhardt wrote:

> If you can't trust the BIOS, you can't trust *anything* about the
> machine. There are business-card-sized CD-R's, so if you do trust the
> BIOS you can have a read-only bootable system in your wallet at all
> times. If you use the disk only for a "cfs -r", you don't need to trust
> its contents.

it's almost always assumed by people on this list that all computers have
an orifice of some sort or another into which bootable media can be poked.
I don't know why.

ron

[David Leimbach]

On Jul 18, 2005, at 8:24 AM, Jack Johnson wrote:

> On 7/17/05, Dave Lukes <***@anvil.com> wrote:
>
>> If you store data on a machine to which other people have physical
>> access, there are many simple ways for them to remove or tamper
>> with it.
>>
>
> I remember seeing USB fingerprint scanners in some random store a few
> years back and laughed hysterically when I saw that particular brand
> was compatible with Windows 98 only.
>
> Sure, pretty much any physical access will let you in, but some
> portals are easier to squeeze through than others (pun intended).


Our "first timer" doesnt' realize that Plan 9 defaults to "terminal
mode" on install.

The reasoning behind this "easy access to files" is that you
shouldn't be keeping your
files on a local machine. Plan 9 was designed for grids with I/O
nodes that have some
physical security. While you "can" run most anything you want in
terminal mode it's not
the originally intended configuration for the OS.

I still like this model better, there is no root user, though there
is a filesystem owner
which I guess is similar.

Personally, the first thing I do when I install plan 9 is to compile
a cpu/fs/auth kernel
and switch to that after a bit of testing. Then I drawterm in. I
can have many users but there
is still only one "owner" for those files on the system.

What I wonder about is how to make it so not just anyone can do "con /
srv/fscons" and get full
access to the files :).

I'm still pretty new to all of this too, mainly due to sporadic spare
time to play around with it.

Dave

>
> -Jack
>

[Ben Huntsman]

>this remind me that I forgot win2000 password.
>I decided to reboot the computer and reinstalled the OS.
>I didn't know how to rescue my data.

I had a similar situation once... I found this great "Windows NT Offline password recovery tool" or something like that. It was a Linux boot CD that could read NTFS and modify registry hives. It deletes the Administrator password, and sets it to null. Reboot under Windows, log in, and you're good to go. First time up, it'll complain about inconsistencies, but will correct them itself, after which all's good. I didn't lose any data at all... not even configurations...

But the fact that it works so well gives testament to why controlling physical access to a machine is of paramount importance.

-Ben

[Ben Huntsman]

>unless/until we do a Xen dom0 for plan 9, which in fact would not be that
>hard.

Anything like that in the works? I'm not generally a Linux fan, and would be much more inclined to set up Xen if I could control it through Plan 9...

Speaking of which, though, I know this is nearly flame bait for sure,(but that's not my intent, and this list keeps things pretty professional) but since I respect your opinion and am sure you've a justifiable reason, what Linux do you use? Thanks!

-Ben

[Ronald G. Minnich]

On Tue, 19 Jul 2005, Ben Huntsman wrote:

> Anything like that in the works? I'm not generally a Linux fan, and
> would be much more inclined to set up Xen if I could control it through
> Plan 9...

need volunteers.

> Speaking of which, though, I know this is nearly flame bait for
> sure,(but that's not my intent, and this list keeps things pretty
> professional) but since I respect your opinion and am sure you've a
> justifiable reason, what Linux do you use? Thanks!

I have no good reasons, but currently use suse 9.something. I mainly use
that because Erik hendriks used it, and I needed his kernel patches etc.
to work, so decided to stay bug-compatible (not that suse is more or less
buggy than anything else -- it's pretty good).

Ollie Lo, whom I respect very highly, is pretty happy with FC3 and now
FC4, in spite of some problems with udev.

I keep thinking about gentoo, since I really still like freebsd better and
gentoo reminds me of the freebsd ports collection. There are days I miss
from my old job which involved a lot of FreeBSD work ...

ron

[Brian L. Stuart]

In message <***@enigma.lanl.gov>, "Ronald G. Minn
ich" writes:
>I keep thinking about gentoo, since I really still like freebsd better and
>gentoo reminds me of the freebsd ports collection. There are days I miss
>from my old job which involved a lot of FreeBSD work ...

It just so happens that I'm using a laptop with gentoo and
I'm running Plan 9 with xen on it. The reason I tried
gentoo was much like your motivation.

I do agree somewhat with the other comments about it. It
just seems to be less unplesant than the other distributions.
The recompile pain on update isn't as bad as one would
expect. One of the things I do on Friday mornings at work
is to start an update in one window. While it's running,
I do other stuff and it rarely takes longer than some of
my other tasks. Even when something like mozilla gets updated,
it's generally done before I get back from lunch.

One thing I've seen with the Linux-xen-Plan 9 combo is
the laptop running a bit hot. For reasons I haven't
figured out, the Plan 9 domain gets constant CPU time
even when it's idle. Even the load monitor in Plan 9
says that the load average is about 0.5. I kind of
hoped that this was just an artifact of the first cut
and that it might disappear with the xen v3 port. Is
that a vain hope?

Thanks,
BLS

[Ronald G. Minnich]

On Tue, 19 Jul 2005, Brian L. Stuart wrote:

> One thing I've seen with the Linux-xen-Plan 9 combo is the laptop
> running a bit hot. For reasons I haven't figured out, the Plan 9 domain
> gets constant CPU time even when it's idle.

and here I thought I fixed that. Hmm, I think I did. How old is your xen
lashup?


anyway, let me know if you are on an old version -- I had a bug in the
idle code, or a misunderstanding really -- and I did fix that. Fix is on
sources.

That said, Xen does NOT do ACPI. Xen 2.0 laptops run hot. This is fixed in
3.0, I think.

ron

[Brian L. Stuart]

In message <***@enigma.lanl.gov>, "Ronald G. Minn
ich" writes:
>On Tue, 19 Jul 2005, Brian L. Stuart wrote:
>
>> One thing I've seen with the Linux-xen-Plan 9 combo is the laptop
>> running a bit hot. For reasons I haven't figured out, the Plan 9 domain
>> gets constant CPU time even when it's idle.
>
>and here I thought I fixed that. Hmm, I think I did. How old is your xen
>lashup?

Actually, the xen patches are several months old. The
Plan 9 kernel is from June. Is it dependent on the version
of xen I use? I think the one that I'm running is 2.0.4.

>anyway, let me know if you are on an old version -- I had a bug in the
>idle code, or a misunderstanding really -- and I did fix that. Fix is on
>sources.

The kernel images appear to be the same ones I have and the
source files seem to be at least as old as what I have.
This is the stuff in /n/sources/xen, right?

>That said, Xen does NOT do ACPI. Xen 2.0 laptops run hot. This is fixed in
>3.0, I think.

I'm looking forward to that. At that point, I'll probably be
able to justify booting into xen/Linux/Plan9 all the time.
Do you have any inside knowledge on when 3.0 is likely to
see the light of day?

Thanks,
BLS

[Tim Newsham]

> Do you have any inside knowledge on when 3.0 is likely to
> see the light of day?

If I took a wild guess I would say its probably about 3 full-time
weeks of work. I may be able to get most of it done in august.
This guess could be way off base. Of course if others are interested
in contributing it could go faster.

> BLS

Tim Newsham
http://www.lava.net/~newsham/

[Ronald G. Minnich]

On Wed, 20 Jul 2005, Brian L. Stuart wrote:

> Actually, the xen patches are several months old. The Plan 9 kernel is
> from June. Is it dependent on the version of xen I use? I think the
> one that I'm running is 2.0.4.

no, the problem was only in the Plan 9 kernel. My bad. by June, I am
pretty sure "the fix was in".

I can't get to sources right now, but will try later and get you a copy of
the "right" code so you can check.

> I'm looking forward to that. At that point, I'll probably be
> able to justify booting into xen/Linux/Plan9 all the time.

it's nice, it's how I run my laptop all the time now. I'm always Xen'ed
up. I only let Linux have 256MB, and it works, as my window manager is now
rio.

> Do you have any inside knowledge on when 3.0 is likely to see the light
> of day?

it's out in -test form. It is still shaking quite a bit from aftershock.
The Plan 9 port is still quite undone, however.

ron

[Brian L. Stuart]

In message <***@enigma.lanl.gov>, "Ronald G. Minn
ich" writes:
>no, the problem was only in the Plan 9 kernel. My bad. by June, I am
>pretty sure "the fix was in".

While I pulled it in June, the date of the image on sources is
April 27.

>I can't get to sources right now, but will try later and get you a copy of
>the "right" code so you can check.

So far I've only used the binary kernel image in 9xenf,
but of course, I'll be glad to build another kernel if
you find some patchs that fell through the cracks.

Thanks,
BLS

[William K. Josephson]

On Tue, Jul 19, 2005 at 12:10:40PM -0400, Russ Cox wrote:
> > I keep thinking about gentoo, since I really still like freebsd better and
> > gentoo reminds me of the freebsd ports collection. There are days I miss
> > from my old job which involved a lot of FreeBSD work ...
>
> Gentoo and FreeBSD ports are both getting to be a little ridiculous.
> I mean, really, why should I have to compile Firefox in order to install
> it on my laptop? Let someone else waste the hours of cpu time to
> compile it and the libraries it rides in on. All I want is a binary.

> A minute vs. an hour is significant.

Then why not take the binary packages from the package build cluster?

[Tim Newsham]

>> unless/until we do a Xen dom0 for plan 9, which in fact would not be that
>> hard.
>
> Anything like that in the works? I'm not generally a Linux fan, and
> would be much more inclined to set up Xen if I could control it through
> Plan 9...

If linux is the main thing keeping you away from xen, consider
netbsd. Hopefully there will be a FreeBSD dom0 in the not
too distant future.

> -Ben

Tim Newsham
http://www.lava.net/~newsham/

[Ronald G. Minnich]

On Tue, 19 Jul 2005, Russ Cox wrote:

> Gentoo and FreeBSD ports are both getting to be a little ridiculous.

yep, that's the downside, and why I haven't booted gentoo. I really don't
need to recompile X11 for that matter. There's almost a point of religion
in some places about recompiling your whole box from scratch. It makes no
sense to me.

The upside is not having to fool with RPM dependencies when I want a
packet. emerge whatever. It can be nice.

So, at least part of the appeal is being able to say 'install that there
thing" and not worry about where that thing and all the stuff it depends
on might be. Which is where apt-get can be nice. The suse interface
(YaST2) to this type of thing is not bad.

ron

[Martin C. Atkins]

On Tue, 19 Jul 2005 10:23:16 -0600 (MDT) "Ronald G. Minnich" <***@lanl.gov> wrote:
>..
> The upside is not having to fool with RPM dependencies when I want a
> packet. emerge whatever. It can be nice.

Sorry folks, but I can't resist:

But that is exactly what a better-designed binary package system,
such as Debian's apt, gives you. I've never had to "fool with deb
dependencies" in >3 years use (and I install a lot of packages :-).

OK - that's enough advocacy.

Martin

--
Martin C. Atkins ***@parvat.com
Parvat Infotech Private Limited http://www.parvat.com{/,/martin}

[bakul+ (Bakul Shah)]

> > I keep thinking about gentoo, since I really still like freebsd better and
> > gentoo reminds me of the freebsd ports collection. There are days I miss
> > from my old job which involved a lot of FreeBSD work ...
>
> Gentoo and FreeBSD ports are both getting to be a little ridiculous.
> I mean, really, why should I have to compile Firefox in order to install
> it on my laptop? Let someone else waste the hours of cpu time to
> compile it and the libraries it rides in on. All I want is a binary.

You don't have to compile any port locally. You can do, e.g.,

pkg_add -r gaim

[andrey mirtchovski]

> Gentoo and FreeBSD ports are both getting to be a little ridiculous.
> I mean, really, why should I have to compile Firefox in order to install
> it on my laptop?

not that it matters much in the context of 9fans, but one can install
binary packages from compiled ports without much difficulty in
freebsd, just the command is different than 'make'.

i run Fedora on my home computers, the university machines are slowly
being switched to suse just because it's slightly more gui-sh to
administer. not that it matters much -- nobody really cares about
what's running underneath, as long as it doesn't require reboots every
week. almost everyone here operates their desktop machines as
glorified xterms (read: xterms that can play music and browse the web)
to the cluster nodes.

my desktop at ucalgary is a big drawterm to the plan9 server. the
current incarnation of the drawterm i'm typing this email in was
started on July 7th.

[Ben Huntsman]

>> Anything like that in the works? I'm not generally a Linux fan, and
>> would be much more inclined to set up Xen if I could control it through
>> Plan 9...
>
>need volunteers.

Anyone else think this might be a bit important to the future of computing or something?
Don't know how useful I'd be, but I'll do what I can.

-Ben

[Ronald G. Minnich]

On Tue, 19 Jul 2005, Ben Huntsman wrote:

> Anyone else think this might be a bit important to the future of computing or something?
> Don't know how useful I'd be, but I'll do what I can.

if you're really interested, download xen 2.0.6 and install. THen follow
instructions on wiki for how to use plan 9 on xen.

Then, repeat for xen 3.0, and then start looking at where we are with the
port.

Any help gratefully accepted.

ron

[Devon H. O'Dell]

On Tue, 2005-07-19 at 09:10, Russ Cox wrote:
> > I keep thinking about gentoo, since I really still like freebsd better and
> > gentoo reminds me of the freebsd ports collection. There are days I miss
> > from my old job which involved a lot of FreeBSD work ...
>
> Gentoo and FreeBSD ports are both getting to be a little ridiculous.
> I mean, really, why should I have to compile Firefox in order to install
> it on my laptop? Let someone else waste the hours of cpu time to
> compile it and the libraries it rides in on. All I want is a binary.
>
> I watched a FreeBSD user install the latest gaim from ports.
> It was funny. It took at least an hour. Compare with the equivalent
> on a binary package system like Debian:

Not to be coy, but:

pkg_add -rv gaim?

I don't think the FreeBSD user in question was very experienced. Also, as long as the ABI hasn't changed, one can also usually download packages from the -CURRENT port snapshot, if the ones snapshotted at -RELEASE are outdated.

-Devon

[Devon H. O'Dell]

On Tue, 2005-07-19 at 13:08, David Leimbach wrote:
> Not to mention FreeBSD now has binary updates for security patches. I
> think this is a huge step forward for sysadmins of FreeBSD systems
> everywhere.

Yes, Colin Percival did a great job at making this. BSdiff was actually invented for his thesis.

> Not to mention the fact that I installed what was supposed to be a
> "demo box" for a bugtracker at work over 2 years ago and I almost
> forgot about it cuz the sucker never dies!
>
> I've yet to have such an experience with ANY version of linux due to
> weird kernel mishaps. Many of my linux zealot buddies really think
> "the last great linux kernel" was 2.0.36 :). I have to admit though,
> that when it comes to hardware driver support, linux is currently the
> winner.

I still have to disagree with this (for PC hardware). We see here that Linux frequently has poor support / broken support for much of the PC server hardware we sell here. FreeBSD tends to work better / faster / more reliably on the same hardware than Linux does. If Linux even works at all (and I mean in general: we get installation requests for RHEL, FCn, SuSE, Debian, and others).

> Dave

--Devon

[Colin Percival]

Devon H. O'Dell <***@offmyserver.com> wrote:
> On Tue, 2005-07-19 at 13:08, David Leimbach wrote:
>> Not to mention FreeBSD now has binary updates for security patches. I
>> think this is a huge step forward for sysadmins of FreeBSD systems
>> everywhere.
>
> Yes, Colin Percival did a great job at making this. BSdiff was
> actually invented for his thesis.

Wrong way around. I was working on my doctorate (doing parallel
computing, in fact), and wrote FreeBSD Update as a diversion; I then
wrote bsdiff because FreeBSD Update needed it.

Only about five months later did I go to my supervisor and say "hey, I've
got this method for delta compression of executable code... and this new
algorithm for matching with mismatches... and this really cool way of
producing 'universal' patches..." -- at which point he said "that sounds
like a thesis". My original project then got rather forgotten --
although I'd still like to go back to it at some point.

I often tell undergraduate students that they shouldn't think about what
degree they want to end up with, but should instead just take interesting
courses -- it's hard to spend four years at university (or at my
university at least) taking interesting courses without meeting the
requirements for _some_ degree at the end. I think I'll have to start
saying much the same thing to graduate students: Just do interesting
research, and you'll end up with a thesis.

Colin Percival.

[Ronald G. Minnich]

On Tue, 19 Jul 2005, David Leimbach wrote:

> I guess it's difficult to speculate, but do you foresee any problems
> with paravirtualization performance running with Plan 9 as Dom0? I know
> with "regular virtualization" I've seen awfully bad performance of
> Inferno, at least in the handling of mouse interrupts and graphics.

it's really hard to speculate. I note that ia64 now runs under xen and
guest OSes run with no mods, and do have graphics/mouse/etc. I have no
ia64 boxes any more, so have no idea how well this works.

> Also, due to momentum in the market, I have to devote most of my life to
> working on Linux related software and stuff. My only real break from it
> is Mac OS X which I also support at work for our MPI implementations.

Actually the 'binary package' discussion of the last few days got me to
thinking about an interesting thing I have noticed in recent year or two.
>From what I have seen, software is getting less portable and harder to
compile. For a few years in the 90s, I had a mixed linux/freebsd cluster,
and the observation was that before the monoculture hit, a lot of tools
would compile fairly well on both systems with no mods.

Then, a while back, things started getting to the point where they compile
well on linux, but maybe not quite so well on xyzbsd. "Oh, you means
there's an OS other than Linux?". Little linux-specific bits started to
creep in -- usually include file stuff, sometimes network related stuff.

Nowadays, I see things that won't compile on "this Linux" but will compile
on "that Linux". 2 days ago I had something that would not compile because
my autoconf was 2.57, not 2.59.

So, is it a proper use of the word ironic if autoconf, designed to make
code location-independent, is itself failing because autoconf itself has
become very version-sensitive? Inquiring non-english-majors want to know!

ron

[andrey mirtchovski]

> So, is it a proper use of the word ironic if autoconf, designed to make
> code location-independent, is itself failing because autoconf itself has
> become very version-sensitive? Inquiring non-english-majors want to know!

yes, in the sense that it's "poignantly contrary to what was expected
or intended" :)

then again, some may expect all linux (or indeed all software) tools
to fail.

/non-english-major

[Charles Forsyth]

>>So, is it a proper use of the word ironic if autoconf, designed to make
>>code location-independent, is itself failing because autoconf itself has
>>become very version-sensitive? Inquiring non-english-majors want to know!

it might be `ironic' if `autoconf' had ever met its notional specification.
`autoconf' is not even an `oxymoron', just a `moron'. actually, i suppose `idiot savant' might
be most accurate: it's really a collection of all the recipes they've met so far, but give
it something new or a revision of something old, and it is completely lost.
it has far too many peculiar details built in to it.

admittedly, it's not helped by programmers who, for instance, conditionally
use either gettimeofday or time when they only want time to the second,
thus requiring a configuration choice between them.

perhaps `moron' was right, too:
1
Mo"ron (?), n. (Pedagogy) A person whose intellectual development
proceeds normally up to about the eighth year of age and is then
arrested so that there is little or no further development.

[David Leimbach]

On Jul 20, 2005, at 1:46 AM, Charles Forsyth wrote:

>>> So, is it a proper use of the word ironic if autoconf, designed
>>> to make
>>> code location-independent, is itself failing because autoconf
>>> itself has
>>> become very version-sensitive? Inquiring non-english-majors want
>>> to know!
>>>
>
> it might be `ironic' if `autoconf' had ever met its notional
> specification.
> `autoconf' is not even an `oxymoron', just a `moron'. actually, i
> suppose `idiot savant' might
> be most accurate: it's really a collection of all the recipes
> they've met so far, but give
> it something new or a revision of something old, and it is
> completely lost.
> it has far too many peculiar details built in to it.

Yep, and getting new OSes supported "upstream" is way more of a
hassle than it should be
for such a tool.

I doubt DragonflyBSD ever gets its stuff detected or installed
properly without patching.

Dave

[davide+ (Dave Eckhardt)]

> it might be `ironic' if `autoconf' had ever met
> its notional specification. `autoconf' is not
> even an `oxymoron', just a `moron'.

The old (pre-autoconf) idea was that each package would
try to encapsulate platform dependencies into a couple
of files, maybe SysV.c, BSD.c, etc. When a new release
of one of those came out, somebody on that platform would
have to hack that file. Often the code for SysV.c and
BSD.c would have lots of similar chunks in it. If you
had N platforms some chunks might appear in N/3 of the
platform files. More likely, *almost*-identical chunks
would be gratuitously different just because they were
maintained by different people. And while the package
would build on M releases of N platforms, it would build
on *only* them--anything new was guaranteed to break
something.

The vision of autoconf was to focus on the chunks, not
the platforms, with probe code (in "portable /bin/sh")
choosing which chunks to use on each release of each
platform. This way when a package finds itself on a new
platform it can automatically choose a locking method
from column A, a networking API from column B, etc., thus
*theoretically* working with zero porting effort by
anybody.

But this approach has a fatal flaw. It turns out that
the *probe* code is non-portable. Just one example: I
saw a piece of code designed to check whether to link
against Heimdal or MIT Kerberos libraries. It "worked"
by testing for the existence of a particular function,
which at one moment in history was present in MIT Kerberos
but not Heimdal. Six months later, of course, the Heimdal
guys caught up and the probe code broke.

The result of auto* is that a package will build on
M releases of N platforms, but will build on *only*
them--anything new is guaranteed to break something.
In other words, pretty much the same as before.

The bad news is that a large complex infrastructure
has been deployed against a problem and the problem
is still there. The *awful* news is that now when
something goes wrong it isn't a matter of fixing a
snippet of C code inside BSD.c, but of finding,
decoding, and increasing the brittleness of some
probe code written in a punitively complex mixture
of sh and m4.

For example, maybe
AC_MUMBLE(foo,[bletch blobble])
works on Linux but on Solaris it has to be
AC_MUMBLE(foo,[[bletch blobble]])
Good luck figuring that out when the error you get is
sh: configure.sh: 7225: syntax error
(yes, that's a seven thousand line shell script, and of
course it's machine-generated code for maximal readability).
Maybe the problem was gnu m4 versus m4, maybe it was bash
versus sh, more likely you'll never know.

Dave Eckhardt

[Francisco J. Ballesteros]

Never understimate a screwdriver.

----- Mensaje original -----
De: "Ronald G. Minnich"<***@lanl.gov>
Env.: 22/07/05 1:00:21
Para: "Fans of the OS Plan 9 from Bell Labs"<***@cse.psu.edu>
Asunto: Re: [9fans] First-timer help


On Thu, 21 Jul 2005, Dave Eckhardt wrote:

> If you can't trust the BIOS, you can't trust *anything* about the
> machine. There are business-card-sized CD-R's, so if you do trust the
> BIOS you can have a read-only bootable system in your wallet at all
> times. If you use the disk only for a "cfs -r", you don't need to trust
> its contents.

it's almost always assumed by people on this list that all computers have
an orifice of some sort or another into which bootable media can be poked.
I don't know why.

ron


[Mensaje truncado. Para ver la parte restante, puntee en Edición->Marcar para descarga.]

[Devon H. O'Dell]

On Thu, 2005-07-21 at 16:25, Francisco J. Ballesteros wrote:
> Never understimate a screwdriver.

Well, never overestimate a board that doesn't have connectors for off-board media is Ron's point, I think.

--Devon

[Frederic Bonfanti]

> Never understimate a screwdriver.

Some Telcos `hot' departments simply use [a combination of] all this

1/ ``key locked" pizza box
2/ Password protected BIOS
3/ PXE boot disactivated
4/ Floppy drive removed
5/ CD-ROM boot disabled
6/ USB ports disabled
... + no access to MBR / system files / registry

So basicaly what you need is a hamer or a serious taste for arbitrary
code... Personnaly I prefer having my own laptop.

[Ronald G. Minnich]

On Thu, 21 Jul 2005, Russ Cox wrote:

> because that's the case everyone except you is familiar with. ;-)

ha! Well, boot this:
http://www.nasa.gov/images/content/122980main_05pd1616.jpg

:-)

ron

[l***@proxima.alt.za]

> ha! Well, boot this:
> http://www.nasa.gov/images/content/122980main_05pd1616.jpg

What?! No illuminated console toggle-switches?!

++L

[j***@plan9.bell-labs.com]

The firmware we used in the Hobbit boards we built a few years ago
was a Plan 9 Hobbit kernel with a different address mapping, a segment
mapping physical memory available to segattach and a different /boot
programme. You could attach to a fileserver to get programmes to boot.
You could also execute programmes from the fileserver, like rc...

--jim

On Fri Jul 22 11:37:04 EDT 2005, ***@gmail.com wrote:
> On 7/22/05, Richard Miller <***@hamnavoe.com> wrote:
> > > it will be even more fun with the newer BIOSes (e.g. EFI) that support
> > > arbitrary driver modules, tasks, and can even run programs. All stored on
> > > a flash file system on the mainboard.
> >
> > Didn't HP (many years ago) make a desktop machine with Unix in ROM?
> >
> > -- Richard
> >
>
> SRM firmware was almost unixy enough on DEC Alphas... But it could be
> "interesting" at times
>
> >

[Ronald G. Minnich]

On Fri, 22 Jul 2005, LiteStar numnums wrote:

> If by 'interesting' you mean 'a rather odd conglomerate of Unix and
> OpenVMS smashed into a small space', then I would agree. It was even

clear sign that SRM was over the top: it had a 'ps' command.

could play yellow rose of texas if you typed the right command

to format disks, you used a command and a ps and a grep to see when it was
done (IIRC)

Nuts.

ron