Re: [9fans] More 'Sam I am'

Re: [9fans] More 'Sam I am'

[quanstro]

i don't miss the vaxen i used to work on with h29 2400 baud "stonet"
terminals and often a 1+ minute login time. 2400 baud is slow enough
that i used to use ^s/^q as a pager

mt xinu 4.3bvd (sic).

- erik

On Fri Feb 10 21:03:01 CST 2006, jmk@plan9.bell-labs.com wrote:
> Many years ago now, a good friend of mine remarked that
> if we actually made all those whining about the state of things
> now compared to the "good old days" go back to using v7 Unix,
> they would quickly realise that times had actually moved
> forward and there were things they were used to that it didn't
> have and that they really needed. I used v[567] and I've
> ported v7, and I wouldn't go back. From what I understand,
> Plan 9 was an attempt to build on that by saying "this got
> us so far, but times are changing and it won't cut it with
> networks, bitmapped displays, SMP etc, we need a better base".
> That was a long time ago and no one has, to my limited
> non- computer science knowledge, attempted anything similar,
> they're all still working on copying 30 year old technology.
> 
> I don't have an iPod, my mobile phone is 5 years old and I
> turn it on about 4 hours a week and there are many things
> about the 21st century that make me grumpy. But you can't go
> back. You should, however, be careful about how how you
> go forward.
> 
> --jim

[9fans] Mt. Xinu

[Lyndon Nerenberg]

On Feb 10, 2006, at 7:40 PM, quanstro@quanstro.net wrote:

> mt xinu 4.3bvd (sic).

Whatever was the magic of the Mt. Xinu releases?  I've worked on  
generic 4.2 as well as Ultrix 1.*, but nobody was ever able to  
explain the difference ...

Re: [9fans] Mt. Xinu

[plan9]

On Fri, Feb 10, 2006 at 07:46:19PM -0800, Lyndon Nerenberg wrote:
> 
> On Feb 10, 2006, at 7:40 PM, quanstro@quanstro.net wrote:
> 
> >mt xinu 4.3bvd (sic).
> 
> Whatever was the magic of the Mt. Xinu releases?  I've worked on  
> generic 4.2 as well as Ultrix 1.*, but nobody was ever able to  
> explain the difference ...

AFAICT, it's just BSD with NFS bolted on.  We're still running it on a
MicroVAX, though we're now down to only one working Eagle:

Feb 14 13:05:33 merlin vmunix: 4.3 BSD + NFS UNIX #19: Thu Oct  6 14:48:43 EST
+2005
Feb 14 13:05:33 merlin vmunix: real mem  = 8355840
Feb 14 13:05:33 merlin vmunix: avail mem = 7001088
Feb 14 13:05:33 merlin vmunix: using 255 buffers containing 522240 bytes of
+memory
Feb 14 13:05:33 merlin vmunix: uba0 at tr0
Feb 14 13:05:33 merlin vmunix: uda0 at uba0 csr 172150 vec 774, ipl 17
Feb 14 13:05:33 merlin vmunix: ra0 at uda0 slave 0
Feb 14 13:05:33 merlin vmunix: ra0: raeagle
Feb 14 13:05:33 merlin vmunix: dhu0 at uba0 csr 160020 vec 300, ipl 17
Feb 14 13:05:33 merlin vmunix: dhu1 at uba0 csr 160040 vec 310, ipl 17
Feb 14 13:05:33 merlin vmunix: qe0 at uba0 csr 174440 vec 770, ipl 17
Feb 14 13:05:33 merlin vmunix: qe0: hardware address 08:00:2b:0d:44:a7
Feb 14 13:05:33 merlin vmunix: root fstype ufs
Feb 14 13:05:37 merlin savecore: reboot after panic: Segmentation fault

Old CS profs. never die-- they just make you maintain their old stuff
forever. :)

ObPlan9:  someone should port Plan 9 to the MicroVAX!

Re: [9fans] Mt. Xinu

[Brantley Coile]

> ObPlan9:  someone should port Plan 9 to the MicroVAX!

Ask Norman.  He still runs MicroVAXen with Research Unix on them.

Re: [9fans] Mt. Xinu

[Bruce Ellis]

probably not enough memory for a workable plan9.
my MicroVAX is fully stocked (i think) - a full 9 MB
of memory.  this is fine for Research Unix (V10) but
a cheap PC is better for plan9.

brucee

On 2/15/06, Brantley Coile <brantley@coraid.com> wrote:
> > ObPlan9:  someone should port Plan 9 to the MicroVAX!
>
> Ask Norman.  He still runs MicroVAXen with Research Unix on them.

Re: [9fans] Mt. Xinu

[Jim McKie]

> On Fri, Feb 10, 2006 at 07:46:19PM -0800, Lyndon Nerenberg wrote:
> ...
> ObPlan9:  someone should port Plan 9 to the MicroVAX!
> ...

a few months ago i found a binary of the plan9 vax compiler when
looking for something in the dump, but no source. there was one because
the original fileserver was a vax750 with a worm drive and connections
to gnots (terminals) were serial. there's a microvax in the storage cage
still.

--jim

Re: [9fans] Mt. Xinu

[Bruce Ellis]

maybe a good console server - it as a bucket of serial ports.

brucee

On 2/15/06, Jim McKie <jmk@plan9.bell-labs.com> wrote:
>
> > On Fri, Feb 10, 2006 at 07:46:19PM -0800, Lyndon Nerenberg wrote:
> > ...
> > ObPlan9:  someone should port Plan 9 to the MicroVAX!
> > ...
>
> a few months ago i found a binary of the plan9 vax compiler when
> looking for something in the dump, but no source. there was one because
> the original fileserver was a vax750 with a worm drive and connections
> to gnots (terminals) were serial. there's a microvax in the storage cage
> still.
>
> --jim
>
>

namec (was Re: [9fans] Strange date/time on some created files)

[rog]

this conversation reminded me of a little piece of
annoying behaviour under plan9. [please accept my apologies if
you've seen this before - it didn't seem to get through last time]

here's a demonstration:

cpu% pwd
/usr/rog/c
cpu% > /tmp/tst
cpu% cp /bin/echo 8.out
cpu% bind 8.out /tmp/tst
cpu% /tmp/tst -z
-z
cpu% cp /bin/sed 8.out
cpu% /tmp/tst -z
tst 424799: suicide: sys: trap: fault write addr=0x24fffbde pc=0x00017e7c

the problem seems to be that attachimage() relies on sysexec()
giving it a Chan with a currently valid qid.version, but when
the last component of the path is translated by a mount
point, namec returns the qid in the mount table's Chan,
which holds a stale version number, hence the old
shared text segment incorrectly used.

i can think of several ways of fixing it, but all of them
either slow things down slightly, or increase complexity.
(for instance, one doesn't really want to do a stat when the
version returned from namec *is* current, which is almost
all the time).

Re: namec (was Re: [9fans] Strange date/time on some created files)

[rog]

oops - i got that wrong; i had expected the list
software to put a [9fans] in front of "namec". sorry.

namec (was Re: [9fans] Strange date/time on some created files)

[rog]

this conversation reminds me of a little piece of
annoying behaviour under plan9.

here's a demonstration:

cpu% pwd
/usr/rog/c
cpu% > /tmp/tst
cpu% cp /bin/echo 8.out
cpu% bind 8.out /tmp/tst
cpu% /tmp/tst -z
-z
cpu% cp /bin/sed 8.out
cpu% /tmp/tst -z
tst 424799: suicide: sys: trap: fault write addr=0x24fffbde pc=0x00017e7c

the problem seems to be that attachimage() relies on sysexec()
giving it a Chan with a currently valid qid.version, but when
the last component of the path is translated by a mount
point, namec returns the qid in the mount table's Chan,
which holds a stale version number, hence the old
shared text segment incorrectly used.

i can think of several ways of fixing it, but all of them
either slow things down slightly, or increase complexity.
(for instance, one doesn't really want to do a stat when the
version returned from namec *is* current, which is almost
all the time).

Re: namec (was Re: [9fans] Strange date/time on some created files)

[Russ Cox]

> the problem seems to be that attachimage() relies on sysexec()
> giving it a Chan with a currently valid qid.version, but when
> the last component of the path is translated by a mount
> point, namec returns the qid in the mount table's Chan,
> which holds a stale version number, hence the old
> shared text segment incorrectly used.

actually, namec returns an open chan, and when the chan
is opened, the Ropen includes a qid which is dutifully copied
into c->qid.  so if you run your example from, say, ramfs, 
then it just works.

the bug is in fossil, which fails to update fid->qid.vers in an
Ropen response.  most of the time this is harmless, since the qid that is
there was computed for the immediately preceding Rwalk.
only when mount points get involved do walk and open messages
get separated significantly.

the bug is fixed on sources (/sys/src/cmd/fossil/9p.c).
new binary later.

russ