Re: [9fans] 4th edition file server available

Re: [9fans] 4th edition file server available

[Richard Miller]

> One advantage (as I understood it) of using a specialized kernel
> was a form of security -- there were *no* user mode programs
> whose bugs could be exploited.

It went further than that: you couldn't even exploit a buffer overflow
to exec a shell, because there was no shell and no exec.

Would it be feasible, as part of bootstrapping a minimal fossil
server, to remove or otherwise disable the exec system call
once everything was running?

-- Richard

Re: [9fans] 4th edition file server available

[Russ Cox]

> Would it be feasible, as part of bootstrapping a minimal fossil
> server, to remove or otherwise disable the exec system call
> once everything was running?

Of course.  Go ahead if you really want.  I don't want to live
in that environment.  There are no buffer overflows anyway.  ;-)
I _really_ like the fact that I can run other programs on
the file server now, like flchk.  I'm not going back.

I think it's reasonable not to run any services on the
machine other than fossil, and to connect with a serial
console to run other things.  Disabling exec strikes me
as extreme.

Re: [9fans] 4th edition file server available

[andrey mirtchovski]

On Mon, 13 Jan 2003, Russ Cox wrote:

> There are no buffer overflows anyway.  ;-)


I see the smiley, but have to reply anyway. this is not a nasty jab
at Russ, just a fix (I hope :)

there's a buffer overflow in cpu.c (strcpy):

% cpu -h `{perl -e '{print "A"x100;}'}
cpu 116986: suicide: sys: trap: fault read addr=0x19000 pc=0x00005b8b
plan9% acid 116986
/proc/116986/text:386 plan 9 executable

/sys/lib/acid/port
/sys/lib/acid/386
acid: stk()
At pc:0x00005b8b:fmtfmt+0x1f /sys/src/libc/fmt/fmt.c:63
fmtfmt(c=0x00000073) /sys/src/libc/fmt/fmt.c:57
        called from _fmtdispatch+0x83 /sys/src/libc/fmt/fmt.c:175
_fmtdispatch(isrunes=0x00000000,f=0x7fffeb48,fmt=0x000168b6) /sys/src/libc/fmt/fmt.c:113
        called from dofmt+0x75 /sys/src/libc/fmt/dofmt.c:62
dofmt(fmt=0x000168b4,f=0x7fffeb48) /sys/src/libc/fmt/dofmt.c:7
        called from vsnprint+0x62 /sys/src/libc/fmt/vsnprint.c:20
vsnprint(len=0x00000100,buf=0x00018734,args=0x7fffebac,fmt=0x000168b0) /sys/src/libc/fmt/vsnprint.c:5
        called from snprint+0x2b /sys/src/libc/fmt/snprint.c:13
snprint(fmt=0x000168b0,buf=0x00018734,len=0x00000100) /sys/src/libc/fmt/snprint.c:5
        called from netmkaddr+0x5e /sys/src/libc/port/netmkaddr.c:34
netmkaddr(linear=0x00017e0c,defnet=0x00000000,defsrv=0x00016978) /sys/src/libc/port/netmkaddr.c:10
        called from rexcall+0x28 /sys/src/cmd/cpu.c:347
rexcall(host=0x00017e0c,service=0x00016978,fd=0x7fffed98) /sys/src/cmd/cpu.c:339
        called from main+0x132 /sys/src/cmd/cpu.c:147
main(argv=0x7fffef84,argc=0x00000000) /sys/src/cmd/cpu.c:77
        called from _main+0x31 /sys/src/libc/386/main9.s:16
acid:


----------------------

here's the fix:

plan9% diff cpu.c /sys/src/cmd/cpu.c
121c121
<               strncpy(system, p, sizeof system);
---
>               strcpy(system, p);
plan9% 8c cpu.c; 8l cpu.8
plan9% 8.out -h `{perl -e '{print "A"x100}'}
cpu: can't dial: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA: cs: can't translate address
plan9%

Re: [9fans] 4th edition file server available

[Scott Schwartz]

Andrey writes:
| <               strncpy(system, p, sizeof system);

That still has the problem that strncpy is not required to NUL terminate
the destination.  How about strecpy?

Re: [9fans] 4th edition file server available

[andrey mirtchovski]

I agree, this opens up a whole new can of worms, as illustrated here:

Miller, T. C., Raadt, T. D.
strlcpy and strlcat -- Consistent, Safe, String Copy and Concatenation.
Proceedings of USENIX Annual Technical Conference. June,
1999. http://www.openbsd.org/papers/strlcpy-paper.ps

on the other hand I think we're in the unique position to fix strncpy
instead of adding another syscall -- after all it's not Ken C we're
dealing with :)

andrey

On Tue, 14 Jan 2003, Scott Schwartz wrote:

> Andrey writes:
> | <               strncpy(system, p, sizeof system);
>
> That still has the problem that strncpy is not required to NUL terminate
> the destination.  How about strecpy?
>

Re: [9fans] 4th edition file server available

[andrey mirtchovski]

or, we can just avoid it altogether...

s/Ken C/ANSI C/ in the previous email

andrey

Re: [9fans] 4th edition file server available

[Russ Cox]

> Miller, T. C., Raadt, T. D.
> strlcpy and strlcat -- Consistent, Safe, String Copy and Concatenation.
> Proceedings of USENIX Annual Technical Conference. June,
> 1999. http://www.openbsd.org/papers/strlcpy-paper.ps

surely this is near the top of the list for most trivial usenix paper ever.

> on the other hand I think we're in the unique position to fix strncpy
> instead of adding another syscall

strecpy serves a similar purpose.

we left strncat alone to avoid surprises when porting plan 9
code to other systems.

Re: [9fans] 4th edition file server available

[Douglas A. Gwyn]

Russ Cox wrote:
> we left strncat alone to avoid surprises when porting plan 9
> code to other systems.

An excellent policy, which also helps in importing software
from other systems.  Standards have a purpose.

Re: [9fans] 4th edition file server available

[Russ Cox]

> An excellent policy, which also helps in importing software
> from other systems.  Standards have a purpose.

as i wrote that, i suspected you would approve.

Re: [9fans] 4th edition file server available

[rob pike, esq.]

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

A less drastic step would be to disable network ports such as
cpu and telnet, to require people to use the console to debug.

-rob

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

From: Richard Miller <miller@hamnavoe.demon.co.uk>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 4th edition file server available
Date: Mon, 13 Jan 2003 10:01:30 0000
Message-ID: <14897aa3a24d632f340f30863deb7850@hamnavoe.demon.co.uk>

> One advantage (as I understood it) of using a specialized kernel
> was a form of security -- there were *no* user mode programs
> whose bugs could be exploited.

It went further than that: you couldn't even exploit a buffer overflow
to exec a shell, because there was no shell and no exec.

Would it be feasible, as part of bootstrapping a minimal fossil
server, to remove or otherwise disable the exec system call
once everything was running?

-- Richard

Re: [9fans] 4th edition file server available

[Andrey S. Kukhar]

I wonder, fossil, why so geological name?

-kyxap

Re: [9fans] 4th edition file server available

[Russ Cox]

g% pull
c sys/src/cmd/cpu.c
c 386/bin/cpu
g% 

g% cpu -h `{perl -e 'print "a"x1000'}
cpu: can't dial: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 aaaaaaaaaaaaaaaaaaaaaaaaaaa: cs: can't translate address
g% 

Re: [9fans] 4th edition file server available

[Skip Tavakkolian]

> It has both the letters f and s in it, was in out dictionary,
> and has a feel of permanence.

It is efficient by being skeletal?

Re: [9fans] 4th edition file server available

[okamoto]

> I wonder, fossil, why so geological name?

 From a view point of geologist, I suppose fossil is not so 'geologic'
name.  ?

Kenji

Re: [9fans] 4th edition file server available

[David Presotto]

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

It has both the letters f and s in it, was in out dictionary,
and has a feel of permanence.

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

From: okamoto@granite.cias.osakafu-u.ac.jp
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 4th edition file server available
Date: Tue, 14 Jan 2003 15:06:04 +0900
Message-ID: <e5fcb3c136701335102b6f15dc0c2525@granite.cias.osakafu-u.ac.jp>

> I wonder, fossil, why so geological name?

 From a view point of geologist, I suppose fossil is not so 'geologic'
name.  ?

Kenji

Re: [9fans] 4th edition file server available

[Andrey S. Kukhar]

dictionary-translator said me that this is geologic 
word (e.g., in expression ``useful fossils''). 
It`s not right?

-kyxap

> From a view point of geologist, I suppose fossil is not
> so 'geologic' name.  ?
>
> Kenji

[9fans] 4th edition file server available

[Joel Salomon]

>It is a user-level program rather than a special kernel
One advantage (as I understood it) of using a specialized kernel was a form of security -- there were *no* user mode programs whose bugs could be exploited. How "standalone" can a Fossil/Venti server be? Can I delete almost everything in /bin to "lock down" the system?

--Joel



_______________________________________________
Join Excite! - http://www.excite.com
The most personalized portal on the Web!

Re: [9fans] 4th edition file server available

[jmk]

On Sat Jan 11 21:37:18 EST 2003, joelcsalomon@excite.com wrote:
> 
> >It is a user-level program rather than a special kernel
> One advantage (as I understood it) of using a specialized kernel was a form of security -- there were *no* user mode programs whose bugs could be exploited. How "standalone" can a Fossil/Venti server be? Can I delete almost everything in /bin to "lock down" the system?
> 
> --Joel

The intent is that it should be possible to configure the system
via the kernel config such that the only process(es) running are
those necessary to run a fileserver, i.e. fossil and factotum, with
only a physical console for control. The less paranoid you are, the
more user level stuff you can leave running, e.g. starting fossil
from /bin/cpurc.

Of course, we're nowhere near there yet.

--jim

Re: [9fans] 4th edition file server available

[rog]

> /sys/doc/fossil.pdf mentions an ``experimental file stack device'' devfs(3).
> I'm just curious; is that man page available?
> (could not find on plan9 web nor on sources)

it's a mistake in the paper.
see instead fs(3).

Re: [9fans] 4th edition file server available

[Russ Cox]

the credit for fs(3) goes to nemo, by the way.

Re: [9fans] 4th edition file server available

[okamoto]

> there are many other differences.  It is a user-level
> program rather than a special kernel, it speaks 9P2000
> (and not 9P1), and there are numerous other improvements,
> including enormous file names and also soft updates so that
> the disk image is always in a consistent state.

Does this mean we don't need il protocol anymore?

Kenji

Re: [9fans] 4th edition file server available

[Russ Cox]

> Does this mean we don't need il protocol anymore?

Correct.

Re: [9fans] 4th edition file server available

[Skip Tavakkolian]

> there are numerous other improvements,
> including enormous file names
> g% x=`{perl -e 'print "a"x2000'}
> g% >$x
> g% ls -l $x

This is a new challenge to people coming up with class names (and depth)
for Java.

[9fans] 4th edition file server available

[Russ Cox]

The new 4th edition file server, named Fossil,
is now available on sources.  There are some
how-to docs for setting up Venti and Fossil at:

http://plan9.bell-labs.com/wiki/plan9/setting_up_venti
http://plan9.bell-labs.com/wiki/plan9/setting_up_fossil

The man pages fossil(4) and fossilcons(8) are
the definitive reference.  /sys/doc/fossil.pdf (aka
http://plan9.bell-labs.com/sys/doc/fossil.pdf)
describes the disk structures and also the Vac
structures for those interested in hacking the
internals.

Conceptually, Fossil is similar to the current file server
with Venti instead of a WORM juke box, but practically
there are many other differences.  It is a user-level
program rather than a special kernel, it speaks 9P2000
(and not 9P1), and there are numerous other improvements,
including enormous file names and also soft updates so that
the disk image is always in a consistent state.

It is still a work in progress, but it's ready to be used
by those feeling adventurous.

Enjoy.
Sean, Jim, Russ


g% x=`{perl -e 'print "a"x2000'}
g% >$x
g% ls -l $x
--rw-rw-r-- M 8 rsc rsc 0 Jan  8 01:30 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
g%

Re: [9fans] 4th edition file server available

[Axel Belinfante]

Congratulations!

I feel a bit adventurous -- but also in the need of
a little (or more?) hand-holding.

I have browsed through the setting up docs on wiki,
and a couple of the refered man pages, but
could not easily see how to build a fossil from
(to replace) an existing fake-worm file server,
taking into account the dump partition.

I recall reading before that at bell labs worm
disks of the fs were copied ``by hand'' one by one,
by taking them out of the fs.
Is there a way to transfer dump to fossil from
a running fake-worm fs (so, just using normal 9p
access, without going to the ``raw disks'')?

On a related note: my fake-worm fs uses relatively small
blocks (4Kb). Can I freely choose a block size for the
venti underlying the fossil, or should there be
a strict relation between the fake-worm  block size
and the fossil/venti block size (e.g. due to transfer
of dump blocks)?

Thanks for any insight (pointers welcome),
Axel.

> The new 4th edition file server, named Fossil,
> is now available on sources.  There are some
> how-to docs for setting up Venti and Fossil at:
[snip] 
> It is still a work in progress, but it's ready to be used
> by those feeling adventurous.

Re: [9fans] 4th edition file server available

[Fco.J.Ballesteros]

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

Not to fossil, but we're using this to move our worm into vac, which
can be serviced by venti. 9fs automates it for us.

#!/bin/rc
# mkvac: creates one vac archive. argument is day number.
#

srv -q il!sargazos.escet.urjc.es
mount /srv/il!sargazos.escet.urjc.es /n/dump dump
date
vname=`{echo $1 | sed 's|/|_|g'}
lname=`{cat mkvac.last}
echo vac -s -b16k -f dump/2002/$vname.vac -d dump/2002/$lname -q /n/dump/$1
time vac -s -b16k -f dump/2002/$vname.vac -d dump/2002/$lname -q /n/dump/$1
echo echo $vname.vac '>' mkvac.last
 echo $vname.vac > mkvac.last
unmount /n/dump
rm /srv/il!sargazos.escet.urjc.es
date


This other one calls the previous one to automate it:
#!/bin/rc
days=(0508 0507 0506 .....other preferred days here)
for (d in $days) {
	cp /dev/text /n/once/nemo/mkvacs.out
	echo -n $d starts ' '
	mkvac 2002/$d
	echo
}
exit


We are doing 1.5 months per day or so.

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

From: Axel Belinfante <Axel.Belinfante@cs.utwente.nl>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] 4th edition file server available
Date: Wed, 08 Jan 2003 12:09:07 +0100
Message-ID: <200301081109.h08B97629776@zamenhof.cs.utwente.nl>

Congratulations!

I feel a bit adventurous -- but also in the need of
a little (or more?) hand-holding.

I have browsed through the setting up docs on wiki,
and a couple of the refered man pages, but
could not easily see how to build a fossil from
(to replace) an existing fake-worm file server,
taking into account the dump partition.

I recall reading before that at bell labs worm
disks of the fs were copied ``by hand'' one by one,
by taking them out of the fs.
Is there a way to transfer dump to fossil from
a running fake-worm fs (so, just using normal 9p
access, without going to the ``raw disks'')?

On a related note: my fake-worm fs uses relatively small
blocks (4Kb). Can I freely choose a block size for the
venti underlying the fossil, or should there be
a strict relation between the fake-worm  block size
and the fossil/venti block size (e.g. due to transfer
of dump blocks)?

Thanks for any insight (pointers welcome),
Axel.

> The new 4th edition file server, named Fossil,
> is now available on sources.  There are some
> how-to docs for setting up Venti and Fossil at:
[snip] 
> It is still a work in progress, but it's ready to be used
> by those feeling adventurous.

Re: [9fans] 4th edition file server available

[andrey mirtchovski]

will you put a link to it on http://plan9.bell-labs.com/sys/doc/index.html
(the index page for Volume 2 documents) or it's not yet supposed to be
read by third parties?

thanx, andrey

On Wed, 8 Jan 2003, Russ Cox wrote:

> The man pages fossil(4) and fossilcons(8) are
> the definitive reference.  /sys/doc/fossil.pdf (aka
> http://plan9.bell-labs.com/sys/doc/fossil.pdf)

Re: [9fans] 4th edition file server available

[Russ Cox]

> will you put a link to it on http://plan9.bell-labs.com/sys/doc/index.html
> (the index page for Volume 2 documents) or it's not yet supposed to be
> read by third parties?

I'm not sure it's quite ready for that.

Re: [9fans] 4th edition file server available

[Andrew]

Maybe this is in the doc's somewhere, but just do i know ahead of time,
does fossil have support for worm devices, ie HP optical jukeboxes and
such? thanks

Andrew

Re: [9fans] 4th edition file server available

[Russ Cox]

There is no support for WORM devices.
The WORM is replaced by Venti.  You could
back up Venti to a WORM drive, I suppose.

Re: [9fans] 4th edition file server available

[Fco.J.Ballesteros]

> You could
> back up Venti to a WORM drive, I suppose.

An alternate way would be to use fs(3) to setup a mirror
for your venti.

Re: [9fans] 4th edition file server available

[Axel Belinfante]

/sys/doc/fossil.pdf mentions an ``experimental file stack device'' devfs(3).
I'm just curious; is that man page available?
(could not find on plan9 web nor on sources)

Axel.

Re: [9fans] ddc

[Russ Cox]

> Is there any plan to integrate some kind
> of ddc communication between monitors
> and vga cards in some near future?.

No.

> If not, why?.

Because there are no plans to go anywhere
near vga in the near future.  I actually rewrote
vga a couple years ago.  The new one is cleaner,
doesn't require anything in vgadb, makes it easy
to add switching back to text mode and other
video modes, and has DDC/EDID support (on
a card-by-card basis: each card lets you at the
DDC in a different way).  But it only supports three
cards.  Sad though it is, the current vga ``is neither
clean nor portable, but it has slowly come to terms
with its particular set of cranky devices.''
Basically, pushing the new vga out the door would
be a big time sink with little actual benefit.

Things work well enough that until there are more
pressing reasons, it's probably best to leave vga
alone.

Russ

Re: [9fans] ddc

[andrey mirtchovski]

On Wed, 6 Nov 2002, Russ Cox wrote:

> Things work well enough that until there are more
> pressing reasons, it's probably best to leave vga
> alone.
>

but would it hurt to push your new vga code out? supposedly
the benefit of open source is that someone else can do the
work for you, however badly. if you're concerned with having
to answer lots of stupid questions, that's a different issue :)

anyway, hasn't the graphics world come to behave much the same
way the CPU architecture world does? one graphics chip to rule
them all? i just re-read 'systems software research is irrelevant'
(http://www.cs.bell-labs.com/who/rob/utah2000.ps) and am under
the impression that supporting the two major graphics card vendors
suffices in 90% of the cases nowadays.

andrey

Re: [9fans] ddc

[Scott Schwartz]

Andrey writes:
| anyway, hasn't the graphics world come to behave much the same
| way the CPU architecture world does? one graphics chip to rule
| them all?

Yeahbut... my home computer is a Pentium 100 with a #9 771.  I'd hate
to be the case that Plan 9 stops supporting!

Re: [9fans] ddc

[Jim Choate]

Sigh, shouldn't the -user community- be making this decision...

I can say that there is a significant contingent of Hangar 18 users
who disagree with the assertion that the current VGA support is
good enough.

On Wed, 6 Nov 2002, Russ Cox wrote:

> > Is there any plan to integrate some kind
> > of ddc communication between monitors
> > and vga cards in some near future?.
>
> No.
>
> > If not, why?.
>
> Because there are no plans to go anywhere
> near vga in the near future.  I actually rewrote
> vga a couple years ago.  The new one is cleaner,
> doesn't require anything in vgadb, makes it easy
> to add switching back to text mode and other
> video modes, and has DDC/EDID support (on
> a card-by-card basis: each card lets you at the
> DDC in a different way).  But it only supports three
> cards.  Sad though it is, the current vga ``is neither
> clean nor portable, but it has slowly come to terms
> with its particular set of cranky devices.''
> Basically, pushing the new vga out the door would
> be a big time sink with little actual benefit.
>
> Things work well enough that until there are more
> pressing reasons, it's probably best to leave vga
> alone.


 --
    ____________________________________________________________________

    We don't see things as they are,                      ravage@ssz.com
    we see them as we are.                                   www.ssz.com
                                                  jchoate@open-forge.org
    Anais Nin                                         www.open-forge.org

    --------------------------------------------------------------------

Re: [9fans] ddc

[Doc Shipley]

On Wed, 6 Nov 2002, Jim Choate wrote:

>
> Sigh, shouldn't the -user community- be making this decision...

  More likely, "Shouldn't the -contributing- user community be making
this decision..."
  By what decree is Russ Cox the slave of the Plan9 community?

	Doc

Re: [9fans] ddc

[Jim Choate]

On Wed, 6 Nov 2002, Doc Shipley wrote:

> On Wed, 6 Nov 2002, Jim Choate wrote:
>
> >
> > Sigh, shouldn't the -user community- be making this decision...
>
>   More likely, "Shouldn't the -contributing- user community be making
> this decision..."

Depends on what one means by -contributing-.

>   By what decree is Russ Cox the slave of the Plan9 community?

No, the -user- community is the one who decides.

Only Russ can decide what his commitment is. Only the user community
can decide if it's worth it or not. Only Russ can decide if he can
live with their verdict.

Anyway, what's a Linux bigot like you doing here. Nobody at ALG to
run off so you decided to take over the Plan 9 world now too?  Or
did they run you out?

Plan 9 folks should stow away your virgins and gold. Me thinks the
pirates have beached.


 --
    ____________________________________________________________________

    We don't see things as they are,                      ravage@ssz.com
    we see them as we are.                                   www.ssz.com
                                                  jchoate@open-forge.org
    Anais Nin                                         www.open-forge.org

    --------------------------------------------------------------------

Re: [9fans] ddc

[Lucio De Re]

On Wed, Nov 06, 2002 at 10:57:40PM -0600, Jim Choate wrote:
>
> Depends on what one means by -contributing-.
>
Maybe.  What's _your_ definition?

> >   By what decree is Russ Cox the slave of the Plan9 community?
>
> No, the -user- community is the one who decides.
>
Maybe.  Your idea of a user community seems to exclude each and every
9fan except you.  Weird indeed.

> Only Russ can decide what his commitment is. Only the user community
> can decide if it's worth it or not. Only Russ can decide if he can
> live with their verdict.
>
I'm sure Russ has just decided to retire to a monastery on the
strength of your lack of acceptance <smirk>.

> Anyway, what's a Linux bigot like you doing here. Nobody at ALG to
> run off so you decided to take over the Plan 9 world now too?  Or
> did they run you out?
>
Please take your personal rants offline.

> Plan 9 folks should stow away your virgins and gold. Me thinks the
> pirates have beached.
>
I did, long ago.  I don't like exposing either valuable to your lack
of minimum social standards.

++L

Re: [9fans] ddc

[Doc Shipley]

On Wed, 6 Nov 2002, Jim Choate wrote:
>
> On Wed, 6 Nov 2002, Doc Shipley wrote:
>
> > On Wed, 6 Nov 2002, Jim Choate wrote:
> >
> > > Sigh, shouldn't the -user community- be making this decision...
> >
> >   More likely, "Shouldn't the -contributing- user community be making
> > this decision..."
>
> Depends on what one means by -contributing-.

  I mean writing code, writing documentation, directed testing &
feedback, donating hardware, running the helpdesk, hosting the mailing
list [on a non-black-holed server], answering questions - you know,
doing tangible, useful things.
  Um.  Maybe you wouldn't know.
  I mean "it's my money/time/code/$resource.  *I* decide if I need to
pursue a particular goal"

> Anyway, what's a Linux bigot like you doing here. Nobody at ALG to
> run off so you decided to take over the Plan 9 world now too?  Or
> did they run you out?

  What I'm doing here is looking at an interesting OS.  Something
"bigots" aren't much known for.
  Jim, can you spell "ad hominem"?

	Doc

Re: [9fans] ddc

[Jim Choate]

On Wed, 6 Nov 2002, Doc Shipley wrote:

>   I mean writing code, writing documentation, directed testing &
> feedback, donating hardware, running the helpdesk, hosting the mailing
> list [on a non-black-holed server], answering questions - you know,
> doing tangible, useful things.
>   Um.  Maybe you wouldn't know.
>   I mean "it's my money/time/code/$resource.  *I* decide if I need to
> pursue a particular goal"

Sounds more like tooting your own horn. However, for those who -are-
in the know you sound pretty damn silly.


 --
    ____________________________________________________________________

    We don't see things as they are,                      ravage@ssz.com
    we see them as we are.                                   www.ssz.com
                                                  jchoate@open-forge.org
    Anais Nin                                         www.open-forge.org

    --------------------------------------------------------------------

Re: [9fans] ddc

[Lucio De Re]

On Wed, Nov 06, 2002 at 12:37:05PM -0500, Russ Cox wrote:
>
> Things work well enough that until there are more
> pressing reasons, it's probably best to leave vga
> alone.
>
Publish and be damned?

I keep hearing about partially complete efforts that are being
abandoned and personally would hate to lose them altogether.  There
is the additional benefit of using an incomplete code base as a
learning platform and one of the things I like most about Plan 9
is that it deserves and gets a lot of documentation.

Please let's make these efforts public.

++L

Re: [9fans] ddc

[paurea]

Russ Cox writes:

 > Things work well enough that until there are more
 > pressing reasons, it's probably best to leave vga
 > alone.
 >
 > Russ


Thanks. I expected some of the sort...
--
                 Saludos,
                         Gorka

"Curiosity sKilled the cat"

[9fans] EHLO EHLO

[presotto]

Leesten vehry carefoolly, I veel say thees only wance...

Our smtp daemon wasn't recognizing the AUTH=<...> parameter
that crept into the the MAIL FROM command with ESMTP.  I changed
smtpd.y to cope and did an update.

Re: [9fans] EHLO EHLO

[Dan Cross]

Must kill moose and squirrel.

	- Dan C.

Re: [9fans] EHLO EHLO

[Anthony Mandic]

Dan Cross wrote:
> 
> Must kill moose and squirrel.

	Oh, Rene! You are so powerful.

-am	© 2002

RE: [9fans] EHLO EHLO

[Nigel Roles]

It's nice to see that good BBC period drama is still popular around the
world.

-----Original Message-----
From: 9fans-admin@cse.psu.edu [mailto:9fans-admin@cse.psu.edu] On Behalf
Of Anthony Mandic
Sent: 15 October 2002 17:48
To: 9fans@cse.psu.edu
Subject: Re: [9fans] EHLO EHLO


Dan Cross wrote:
>
> Must kill moose and squirrel.

	Oh, Rene! You are so powerful.

-am	C 2002

RE: [9fans] EHLO EHLO

[andrey mirtchovski]

I just watched "Blake's 7" couple of nights ago on PBS (north american
public television, commercial-free)!


On Tue, 15 Oct 2002, Nigel Roles wrote:

> It's nice to see that good BBC period drama is still popular around the
> world.
>

Re: [9fans] EHLO EHLO

[Steve Kilbane]

> I just watched "Blake's 7" couple of nights ago on PBS (north american
> public television, commercial-free)!

Well of course! It's BBC - it's *supposed* to be seen sans commercials.

And while we're *so* far off topic, a shameless plug:

http://www.conventions.org.uk/Redemption

Right. Back to other stuff...

steve

Re: [9fans] EHLO EHLO

[Boyd Roberts]

Steve Kilbane wrote:

>Well of course! It's BBC - it's *supposed* to be seen sans commercials.
>
>
Err, sans publicit� ...

Re: [9fans] EHLO EHLO

[Anthony Mandic]

Yes, that was period drama at its finest - bloody awful.

andrey mirtchovski wrote:
>
> I just watched "Blake's 7" couple of nights ago on PBS (north american
> public television, commercial-free)!
>
> On Tue, 15 Oct 2002, Nigel Roles wrote:
>
> > It's nice to see that good BBC period drama is still popular around the
> > world.

-am	� 2002