Re: [9fans] AFS-client for Plan9 - ?

Re: [9fans] AFS-client for Plan9 - ?

[anothy]

//Local caching would be great, I think.

okay, let me say off the bat i have no idea how
AFS handles caching, so this comparison may be
totally inapropriate. but for fs caching in
Plan 9 (without 9p↔AFS), take a look at cfs(4)
and the -C option to mount in bind(1).

if your goal is talking to AIX or other Unix
boxes, take a look at u9fs(4).
-α.

Re: [9fans] AFS-client for Plan9 - ?

[Wladimir Mutel]

anothy@cosym.net wrote:
> //Local caching would be great, I think.

> okay, let me say off the bat i have no idea how
> AFS handles caching, so this comparison may be
> totally inapropriate. but for fs caching in
> Plan 9 (without 9pAFS), take a look at cfs(4)
> and the -C option to mount in bind(1).

> if your goal is talking to AIX or other Unix
> boxes, take a look at u9fs(4).

	Here is a quote from their doc
http://oss.software.ibm.com/developerworks/opensource/afs/docs/html/AdminGd/auagd007.htm :

AFS Implements Save on Close

When an application issues the UNIX close system call on a file, the Cache
Manager performs a synchronous write of the data to
the File Server that maintains the central copy of the file. It does not
return control to the application until the File
Server has acknowledged receipt of the data. For the fsync system call,
control does not return to the application until the
File Server indicates that it has written the data to non-volatile storage
on the file server machine. 

When an application issues the UNIX write system call, the Cache Manager
writes modifications to the local AFS client cache
only. If the local machine crashes or an application program exits without
issuing the close system call, it is possible that
the modifications are not recorded in the central copy of the file
maintained by the File Server. The Cache Manager does
sometimes write this type of modified data from the cache to the File
Server without receiving the close or fsync system call,
for example if it needs to free cache chunks for new data. However, it is
not generally possible to predict when the Cache
Manager transfers modified data to the File Server in this way. 

The implication is that if an application's Save option invokes the write
system call rather than close or fsync, the changes
are not necessarily stored permanently on the File Server machine. Most
application programs issue the close system call for
save operations, as well as when they finish handling a file and when they
exit. 


--
mwg@alkar.net, 399916, 340044, 7442333, 7786458 -  

Re: [9fans] AFS-client for Plan9 - ?

[Tom Duff]

Wladimir Mutel <mwg@alkar.net> wrote:
> If the local machine crashes or an application program exits without
> issuing the close system call, it is possible that
> the modifications are not recorded in the central copy of the file
> maintained by the File Server.

I'm confused.  UNIX applications can't exit without issuing the
close system call.  The exit system call internally calls out
to close for each open file.  Unless some numskull changed it
since the last time I had my fingers in it.  (They've had plenty
of opportunity -- I haven't touched a non-BSD UNIX kernel in many
years.)

-- 
Tom Duff.  If all else fails, make it up.

Re: [9fans] AFS-client for Plan9 - ?

[Boyd Roberts]

From: Tom Duff <td@pixar.com>

> Unless some numskull changed it since the last time

sadly you're probably right -- between the sheets.

Re: [9fans] AFS-client for Plan9 - ?

[Alexander Viro]

On Tue, 14 Nov 2000, Tom Duff wrote:

> Wladimir Mutel <mwg@alkar.net> wrote:
> > If the local machine crashes or an application program exits without
> > issuing the close system call, it is possible that
> > the modifications are not recorded in the central copy of the file
> > maintained by the File Server.
> 
> I'm confused.  UNIX applications can't exit without issuing the
> close system call.  The exit system call internally calls out
> to close for each open file.  Unless some numskull changed it
> since the last time I had my fingers in it.  (They've had plenty
> of opportunity -- I haven't touched a non-BSD UNIX kernel in many
> years.)

Not bloody likely. _Many_ applications exit without calling close(), so
such system would die horribly under the leaks. OTOH... name a perversion
and somebody will find a place where it had been implemented.

Re: [9fans] AFS-client for Plan9 - ?

[Boyd Roberts]

From: Alexander Viro <viro@math.psu.edu>

> Not bloody likely. _Many_ applications exit without calling close

here we go.  the kernel closes the fd's as a part of exit,
like td said. 

duff knows what he's doing -- between the sheets.

you wanna outcode duff?

Re: [9fans] AFS-client for Plan9 - ?

[Tom Duff]

On Nov 14, 11:51pm, Boyd Roberts wrote:
> duff knows what he's doing -- between the sheets.
>
> you wanna outcode duff?

I am sitting in my workshop reading this,
and now my head won't fit through the door.

-- 
Tom Duff.  I spent an interesting evening recently with a grain of salt.

Re: [9fans] AFS-client for Plan9 - ?

[Chris Locke]

The kernel cannot close the fds if the machine has crashed.
The original post said "if the local machine crashes".
This can also be read as  "some numskul knocked
the reset button / kicked the power lead out /
raccoon sat on local power transformer etc. etc."

Chris.

Re: [9fans] AFS-client for Plan9 - ?

[Douglas A. Gwyn]

Boyd Roberts wrote:
> here we go.  the kernel closes the fd's as a part of exit,
> like td said.

Further, upon return from main(), all the exit() actions
are performed.

_exit(), on the other hand, does not perform any stdio.
(Its main use is in a child branch of a fork.)

Re: [9fans] AFS-client for Plan9 - ?

[Boyd Roberts]

From: Douglas A. Gwyn <gwyn@arl.army.mil>

> Boyd Roberts wrote:
> > here we go.  the kernel closes the fd's as a part of exit,
> > like td said.
> 
> Further, upon return from main(), all the exit() actions
> are performed.
> 
> _exit(), on the other hand, does not perform any stdio.
> (Its main use is in a child branch of a fork.)

absolutely correct.

Re: [9fans] AFS-client for Plan9 - ?

[Tom Duff]

On Nov 14,  5:41pm, Alexander Viro wrote:
> On Tue, 14 Nov 2000, Tom Duff wrote:
> > UNIX applications can't exit without issuing the
> > close system call.  The exit system call internally calls out
> > to close for each open file.
>
> Not bloody likely. _Many_ applications exit without calling close(), so
> such system would die horribly under the leaks.

No.
Read what I said.
The exit system call closes all open files.
You cannot exit without closing.  (By `cannot'
I do not mean that you are enjoined from so
doing, but rather that it is not possible to
do so.)

You can, however, exit without fclosing, although
the stdio library tries to make that difficult.

-- 
Tom Duff.  I spent an interesting evening recently with a grain of salt.

Re: [9fans] AFS-client for Plan9 - ?

[Alexander Viro]

On Tue, 14 Nov 2000, Tom Duff wrote:

> On Nov 14,  5:41pm, Alexander Viro wrote:
> > On Tue, 14 Nov 2000, Tom Duff wrote:
> > > UNIX applications can't exit without issuing the
> > > close system call.  The exit system call internally calls out
> > > to close for each open file.
> >
> > Not bloody likely. _Many_ applications exit without calling close(), so
> > such system would die horribly under the leaks.
> 
> No.
> Read what I said.

Erm... Ditto.

> The exit system call closes all open files.

Precisely. And any kernel that will try _not_ to do that will die under the
leaks produced by the $BIGNUM of applications expecting it do act as any
sane UNIX should. Thus "not bloody likely" - any attempt to change the
behaviour in that area is pretty much doomed.

Re: [9fans] AFS-client for Plan9 - ?

[Tom Duff]

> Precisely. And any kernel that will try _not_ to do that will die under the
> leaks produced by the $BIGNUM of applications expecting it do act as any
> sane UNIX should.
Which UNIX version lacks this behavior?
(Or are you trying to run UNIX programs
on some non-UNIX?)

-- 
Tom Duff.  I spent an interesting evening recently with a grain of salt.

Re: [9fans] AFS-client for Plan9 - ?

[Alexander Viro]

On Tue, 14 Nov 2000, Tom Duff wrote:

> > Precisely. And any kernel that will try _not_ to do that will die under the
> > leaks produced by the $BIGNUM of applications expecting it do act as any
> > sane UNIX should.
> Which UNIX version lacks this behavior?
> (Or are you trying to run UNIX programs
> on some non-UNIX?)

Grr... OK, let me rephrase it:

	I really doubt that there is (or ever was) a UNIX variant that
would not do close-on-exit. Reason: lots and lots of programs that would
kill such system with file leaks.

IOW, "not likely" was about "some numskull changed it" part - such attempt
would backfire immediately. We are in violent agreement...

Re: [9fans] AFS-client for Plan9 - ?

[Boyd Roberts]

From: Alexander Viro <viro@math.psu.edu>

> IOW, "not likely" was about "some numskull changed it" part - such attempt
> would backfire immediately. We are in violent agreement...

if some 'numskull' would stand up and call bullshit on dat
the world world would be a better place.

tell me why the BSD f/S was written?

quadratic rehash -- give me a break.

[9fans] E attribute in libsec/port/x509.c

[Claude BONFANTI]

Various attributes could be specified this way.

% diff .../new.x509.c x509.c
2222c2222
< 	int		data[7];
---
> 	int		data[4];
2226,2232c2226,2231
< 	{4, 2, 5, 4, 6, 0, 0, 0, "C="},
< 	{4, 2, 5, 4, 8, 0, 0, 0, "ST="},
< 	{4, 2, 5, 4, 7, 0, 0, 0, "L="},
< 	{4, 2, 5, 4, 10, 0, 0, 0, "O="},
< 	{4, 2, 5, 4, 11, 0, 0, 0, "OU="},
< 	{7, 1,2,840,113549,1,9,1, "E="},
< 	{4, 2, 5, 4, 3, 0, 0, 0, "CN="},
---
> 	{4, 2, 5, 4, 6,  "C="},
> 	{4, 2, 5, 4, 8,  "ST="},
> 	{4, 2, 5, 4, 7,  "L="},
> 	{4, 2, 5, 4, 10, "O="},
> 	{4, 2, 5, 4, 11, "OU="},
> 	{4, 2, 5, 4, 3,  "CN="},
%


% aux/X509gen -p your_key.secret 'C=FR O=''-'' OU=''-'' E=''guess@nowere.fr'' CN=''Your_NAME'' ' >your_x509certificate.der

Re: [9fans] E attribute in libsec/port/x509.c

[Eric Grosse]

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

Done.

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

From: Claude BONFANTI <guess@nowere.fr>
To: 9fans@cse.psu.edu
Subject: [9fans] E attribute in libsec/port/x509.c
Date: Mon, 10 Mar 2003 13:13:35 0000
Message-ID: <802c9b0626bc30fd37f13ebc4f729d01@domik.fr>

Various attributes could be specified this way.

% diff .../new.x509.c x509.c
2222c2222
< 	int		data[7];
---
> 	int		data[4];
2226,2232c2226,2231
< 	{4, 2, 5, 4, 6, 0, 0, 0, "C="},
< 	{4, 2, 5, 4, 8, 0, 0, 0, "ST="},
< 	{4, 2, 5, 4, 7, 0, 0, 0, "L="},
< 	{4, 2, 5, 4, 10, 0, 0, 0, "O="},
< 	{4, 2, 5, 4, 11, 0, 0, 0, "OU="},
< 	{7, 1,2,840,113549,1,9,1, "E="},
< 	{4, 2, 5, 4, 3, 0, 0, 0, "CN="},
---
> 	{4, 2, 5, 4, 6,  "C="},
> 	{4, 2, 5, 4, 8,  "ST="},
> 	{4, 2, 5, 4, 7,  "L="},
> 	{4, 2, 5, 4, 10, "O="},
> 	{4, 2, 5, 4, 11, "OU="},
> 	{4, 2, 5, 4, 3,  "CN="},
%


% aux/X509gen -p your_key.secret 'C=FR O=''-'' OU=''-'' E=''guess@nowere.fr'' CN=''Your_NAME'' ' >your_x509certificate.der

[9fans] hardware support for the fs kernel

[Conor Williams]

hi
What graphics and network hardware is supported for the fs kernel.
I went through the emelie mkfile and all I could find was:
ether2114x
ether82557
Will my ne2000 card and S3 card work with this kernel?
tx
will551

Re: [9fans] hardware support for the fs kernel

[Geoff Collyer]

Graphics card is almost irrelevant; any VGA card will do.

: cpu; ls /sys/src/fs/pc/ether*.c
/sys/src/fs/pc/ether2114x.c
/sys/src/fs/pc/ether8139.c
/sys/src/fs/pc/ether82557.c
/sys/src/fs/pc/ether83815.c
/sys/src/fs/pc/etherdp83820.c
/sys/src/fs/pc/etherelnk3.c
/sys/src/fs/pc/etherga620.c

In particular, ether8139 drives the low-end RealTek 8139 chip that
everybody seems to selling now.  ether82557.c runs the Intel 8255[789]
cards, which should be easy to find.  ether83815.c drives the FA31[12]
cards, also pretty easy to find and cheap.  etherelink3.c will run
most any 3com card.

Re: [9fans] hardware support for the fs kernel

[Lucio De Re]

On Wed, Mar 12, 2003 at 09:33:18AM -0000, Conor Williams wrote:
> 
> What graphics and network hardware is supported for the fs kernel.
> I went through the emelie mkfile and all I could find was:
> ether2114x
> ether82557
> Will my ne2000 card and S3 card work with this kernel?

I think you're out of luck on the ne2000 side.  Maybe a bit of
effort in porting either an old ne2000 driver (I know I had been
using one on my 2ed server and replaced it with a 3Com when I
upgraded to 3.5ed :-) or even the driver from the workstation/cpu
code, I'm not sure which would be easier, will get you there.  But
ne2000s are pretty scrappy cards and performance won't be what it
could.

As for video, anything including an old digital monochrome or colour
monitor adapter ought to work.  The FS has no graphics requirements.
I'd keep the S3 for graphics work, use one of the _unsupported_ video
card on the file server.

++L

PS: I know why I haven't migrated to Fossil/Venti yet, but if you're
setting up a new server, why are you considering the obsolete file
server?  Or, better, are you aware that the server you're considering
is obsolete?

Re: [9fans] hardware support for the fs kernel

[Geoff Collyer]

The pre-fossil file server isn't entirely obsolete yet.  If one wants
automated, unattended dumps to optical storage, the old file server is
still a good choice, and that's why I'm using it.

I'm considering what it would take to make the jukebox code and
possibly the cached-worm code, in some form, fit sensibly into a cpu
server with venti and fossil on it.  Possibly an ordinary big disk in
front of the jukebox using a mirror device would be enough to supplant
the cached-worm code.

Re: [9fans] hardware support for the fs kernel

[Lucio De Re]

On Wed, Mar 12, 2003 at 02:12:55AM -0800, Geoff Collyer wrote:
> 
> The pre-fossil file server isn't entirely obsolete yet.  If one wants
> automated, unattended dumps to optical storage, the old file server is
> still a good choice, and that's why I'm using it.
> 
Fossil/Venti won't serve my 2ed and 3ed museums :-)  I like the 3.5ed
server, pity longnames are incompatible with the disk structures.
Maybe my question should have used "obsolescent" rather than
"obsolete".

> I'm considering what it would take to make the jukebox code and
> possibly the cached-worm code, in some form, fit sensibly into a cpu
> server with venti and fossil on it.  Possibly an ordinary big disk in
> front of the jukebox using a mirror device would be enough to supplant
> the cached-worm code.

The whole idea of "removable" media needs a re-think, it seems to me.
It is too convenient to disregard, but fits badly into existing
paradigms.  Mind you, decent cacheing, effectively replication, would
solve a lot of problems.  There's something about Venti that hints at
clever replication, but I can't quite fathom what, I like to think
that the key really lies there.

++L

Re: [9fans] hardware support for the fs kernel

[Russ Cox]

> Fossil/Venti won't serve my 2ed and 3ed museums :-)  I like the 3.5ed
> server, pity longnames are incompatible with the disk structures.
> Maybe my question should have used "obsolescent" rather than
> "obsolete".

It would be utterly trivial -- maybe 100 lines of code -- to
write a srvold9p to do the translation.  Kfs and u9fs have
this built into them.  We dropped it from fossil because it
is time to move on, but it would be easy to make it a separate
user program.  There's literally no state needed.  There's
an easy embedding from old to new requests and then new to 
old responses.

(Our current program called srvold9p is really mountold9p.)

Russ

Re: [9fans] hardware support for the fs kernel

[Lucio De Re]

On Wed, Mar 12, 2003 at 12:15:41PM -0500, Russ Cox wrote:
> 
> > Fossil/Venti won't serve my 2ed and 3ed museums :-)  I like the 3.5ed
> > server, pity longnames are incompatible with the disk structures.
> > Maybe my question should have used "obsolescent" rather than
> > "obsolete".
> 
> It would be utterly trivial -- maybe 100 lines of code -- to
> write a srvold9p to do the translation.  Kfs and u9fs have
> this built into them.  We dropped it from fossil because it
> is time to move on, but it would be easy to make it a separate
> user program.  There's literally no state needed.  There's
> an easy embedding from old to new requests and then new to 
> old responses.
> 
Yes, that's an excellent idea and I will look into it.  I would
certainly consider running a single fossil file server for all
conceivable purposes.  Right now, I'm sticking to the 3.5ed file
server because I have too much on my plate and too little is actually
getting done as a result.

Unless my reading of the Fossil documentation deceives me, fossil
gets its own namespace to serve, in which case it could also
assimilate duplicates into the namespace (the maps, fonts, astronomical
data) before serving the single copy to different requesters.  That
would be quite convenient.  Fortunately, one doesn't need to
continually update these information libraries, but consolidating
them into a single image would certainly be beneficial.

Another benefit would be the ability to serve arbitrary media: the
old fileserver, in my particular case, could not serve the contents
of the two CD-ROM changers, fossil will be better geared to do so.
I never considered that I would be wooed over by the new file server
being just another application, I always believed that it ought to
stand alone.  I guess one never stops learning :-)

> (Our current program called srvold9p is really mountold9p.)
> 
Good point, wouldn't be hard to rename it "mntold9p", although
renaming "srv" to "mnt" is right out of the question.  I find having
to resort to "-u none" all the time (am I misunderstanding the
documentation?) a little restrictive and irritating.  It probably
ought to have been the default.

++L

Re: [9fans] hardware support for the fs kernel

[Russ Cox]

> Unless my reading of the Fossil documentation deceives me, fossil
> gets its own namespace to serve, in which case it could also

I don't know what you mean by this, but I think you're confused.
As far as file service is concerned, fossil is conceptually 
identical to the worm fs but with long file names.

> Another benefit would be the ability to serve arbitrary media: the
> old fileserver, in my particular case, could not serve the contents
> of the two CD-ROM changers, fossil will be better geared to do so.

No.  See above.  Fossil is just a file server.

> Good point, wouldn't be hard to rename it "mntold9p", although
> renaming "srv" to "mnt" is right out of the question.  I find having
> to resort to "-u none" all the time (am I misunderstanding the
> documentation?) a little restrictive and irritating.  It probably
> ought to have been the default.

It's a throwaway program, meaning I can't wait to throw it away.

Russ

Re: [9fans] hardware support for the fs kernel

[Lucio De Re]

On Thu, Mar 13, 2003 at 10:45:49AM -0500, Russ Cox wrote:
> 
> > Unless my reading of the Fossil documentation deceives me, fossil
> > gets its own namespace to serve, in which case it could also
> 
> I don't know what you mean by this, but I think you're confused.
> As far as file service is concerned, fossil is conceptually 
> identical to the worm fs but with long file names.
> 
I'm confused.  I'll take a closer look before making a bigger fool of
myself.

> 
> It's a throwaway program, meaning I can't wait to throw it away.
> 
_I_ won't be needing srvold9p anymore.  I had three fileservers,
2ed, 3ed and 3.5ed.  Now I have two, both 3.5ed, serving 2ed, 3ed
and 4ed on two hosts.  I can recommend others do the same if they
have the same type of need, but it may be still early days.

++L

Re: [9fans] hardware support for the fs kernel

[James A. Robinson]

> The whole idea of "removable" media needs a re-think, it seems to me.
> It is too convenient to disregard, but fits badly into existing
> paradigms.  Mind you, decent cacheing, effectively replication, would
> solve a lot of problems.  There's something about Venti that hints at
> clever replication, but I can't quite fathom what, I like to think
> that the key really lies there.

Someone was pointing out the Nexsan ATABeast product, which advertises
13.4TB of disk starting at $40K (one assumes the 10.4TB they also
advertise would be cheaper).  It may not be blazingly fast disk,
but it's probably faster than optical, and is fairly cheap.  Just in
the context of an ordinary IT operation, it does seem like this kind
of hardware would replace optical jukeboxes, and next to it you would
have an ordinary tape box for absolute disaster recovery (or you have
an off-site mirror of the disk array).


Jim

Re: [9fans] hardware support for the fs kernel

[Lucio De Re]

On Wed, Mar 12, 2003 at 02:52:48AM -0800, James A. Robinson wrote:
> 
> Someone was pointing out the Nexsan ATABeast product, which advertises
> 13.4TB of disk starting at $40K (one assumes the 10.4TB they also
> advertise would be cheaper).  It may not be blazingly fast disk,
> but it's probably faster than optical, and is fairly cheap.  Just in
> the context of an ordinary IT operation, it does seem like this kind
> of hardware would replace optical jukeboxes, and next to it you would
> have an ordinary tape box for absolute disaster recovery (or you have
> an off-site mirror of the disk array).
> 
That covers Geoff's needs, in a fashion (and at a price, seeing as
you need two of them :-)

But it doesn't solve the problem of replication, which in fact
arises even in the scenario above.  In addition, replication is
multi-directional, although Geoff may not be interested in this
aspect.

++L

Re: [9fans] hardware support for the fs kernel

[Geoff Collyer]

Actually Jim Robinson's suggestion doesn't meet my needs (or desires,
anyway).  Magnetic media don't provide the permanence of optical
media.  Mirrors aren't a substitute for backups.

I've personally had enough of magnetic tape for one lifetime.  Mag
tapes aren't archival storage and are somewhat dubious as backups.
Plus mag tape gets you back into the business of manual backups and
restores.  I don't think anybody is going to want to dump 13 TB, which
will take quite a while and use a lot of tapes, so it probably won't
get done often enough.  If there is ever a need to restore from all
those tapes, it's likely to take even longer than the dumps took.

To top it off, the ATABeast new, at $40k, is two orders of magnitude
more than I've paid for my optical jukeboxes.

I'm waiting to see if holographic storage appears next year, as
promised.

Re: [9fans] hardware support for the fs kernel

[Jack Johnson]

Geoff Collyer wrote:
> Actually Jim Robinson's suggestion doesn't meet my needs (or desires,
> anyway).  Magnetic media don't provide the permanence of optical
> media.  Mirrors aren't a substitute for backups.

I really like the idea from the wiki (I believe) of creating CD-sized 
Venti arenas so you can make semi-permanent backups of the arenas and 
leave the archive alone (assuming you can maintain enough space).  Plus, 
because a full arena never changes, you only have to burn it to CD once. 
  It's like the perfect incremental backup.

I suppose it would be trivial to automate the process.  Hmm....

-Jack

[9fans] 9 in the news

[matt]

 How Apache & Plan 9 will defeat Microsoft's Passport

http://www.linuxworld.com/site-stories/2002/0918.plan9.html

http://slashdot.org/article.pl?sid=02/09/20/1532208&mode=nested&tid=156


---
Outgoing mail is certified as idiotic.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.384 / Virus Database: 216 - Release Date: 21/08/2002

Re: [9fans] 9 in the news

[Lucio De Re]

On Sat, Sep 21, 2002 at 03:01:09AM +0100, matt wrote:
>
> http://slashdot.org/article.pl?sid=02/09/20/1532208&mode=nested&tid=156
>
Is it just me, or were the responses surprisingly uninformed?

++L

Re: [9fans] 9 in the news

[Arnaud SAHUGUET]

The original article from LinuxWorld is a real mess.
They mix together so many different things and the title is really
misleading.

The /. comments are the usual stuff.
A lot of noise especially when the thread gets "hijacked" on a totally
different track.

But it is good PR for Plan9, putting it back on the radar screen of some
people.
This is called mindshare.

regards,

Arnaud

----- Original Message -----
From: "Lucio De Re" <lucio@proxima.alt.za>
To: <9fans@cse.psu.edu>
Sent: Saturday, September 21, 2002 7:16 AM
Subject: Re: [9fans] 9 in the news


> On Sat, Sep 21, 2002 at 03:01:09AM +0100, matt wrote:
> >
> > http://slashdot.org/article.pl?sid=02/09/20/1532208&mode=nested&tid=156
> >
> Is it just me, or were the responses surprisingly uninformed?
>
> ++L
>

Re: [9fans] 9 in the news

[Jack Johnson]

Lucio De Re wrote:
> On Sat, Sep 21, 2002 at 03:01:09AM +0100, matt wrote:
>>http://slashdot.org/article.pl?sid=02/09/20/1532208&mode=nested&tid=156
>>
> Is it just me, or were the responses surprisingly uninformed?

I'm less informed than I should be, and I felt the same way.

I was unimpressed by the LinuxWorld article in general, but yes,
Slashdot isn't what it used to be.

-Jack

Re: [9fans] 9 in the news

[Ronald G Minnich]

On Sat, 21 Sep 2002, Lucio De Re wrote:

> Is it just me, or were the responses surprisingly uninformed?

It's slashdot. What else do you need to know?

ron

Re: [9fans] 9 in the news

[Steve Kilbane]

> Is it just me, or were the responses surprisingly uninformed?

I'm surprised anybody bothers to read them in the first place.
Life's too short.

steve

Re: [9fans] 9 in the news

[matt]

er, looks like ntl's relay has decided to play a game

Received: from mta05-svc.ntlworld.com [62.253.162.45]
 by mail.cse.psu.edu (CSE Mail Server) with ESMTP id C741F19A68
 for <9fans@cse.psu.edu>; Tue,  1 Oct 2002 04:59:17 -0400 (EDT)

Received: from KIKE ([80.4.204.18]) by mta02-svc.ntlworld.com
          for <9fans@cse.psu.edu>; Sat, 21 Sep 2002 03:00:31 +0100


---
Outgoing mail is certified as idiotic.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.384 / Virus Database: 216 - Release Date: 22/08/2002

[9fans] did a replica/pull, now "mk 'CONF='pc" fails?

[Eric Dorman]

I did a pull last night; after making the world I went to rebuild 9pc and
got 'name not declared: E_data_mismatch_recover' compiling
sd53c8xx.c .. it seems sd53c8xx.c was updated, with the last time
stamp of (presumably) 1033135288. from /dist/replica/client/plan9.log.

I can recover it from yesterday(1) but I'm worried it's broken on
sources.bell-labs..
maybe I just need to rebuild from scratch?

--eric

Re: [9fans] sam and ssh

[Geoff Collyer]

Sorry, I thought Lucio was talking about Unix sam.

Re: [9fans] sam and ssh

[Lucio De Re]

On Wed, Mar 27, 2002 at 12:12:31PM -0800, Geoff Collyer wrote:
> 
> Sorry, I thought Lucio was talking about Unix sam.

I didn't specify.  I prefer the 3ed version, I have to confess, but
I just wanted to edit a remote file over a slow Internet link that
only allows me convenient access over SSH.   I have Unix, Plan 9 and
Windows versions of SAM, I don't mind which one I use.

I presume the above means that you second Scott's approach?

++L

Re: [9fans] sam and ssh

[Scott Schwartz]

> I presume the above means that you second Scott's approach?

On unix, I recompiled sam to exec ssh, so I second Geoff's approach.  :)

[9fans] PGP

[Lucio De Re]

I can't seem to find the sources, but I still have a 2ed PGP binary.
Does anyone know where I can find an update?  Or, for that matter, how
I came across the 2ed version?

++L

Re: [9fans] PGP

[Scott Schwartz]

> Or, for that matter, how I came across the 2ed version?

Ages ago I posted patches to get it to compile under APE.
Someone else can repeat the exercise this time. :)

Re: [9fans] PGP

[Dan Cross]

In article <20010423060128.16241.qmail@g.bio.cse.psu.edu> you write:
>Ages ago I posted patches to get it to compile under APE.
>Someone else can repeat the exercise this time. :)

PGP 2 is all well and good, but isn't compatable with the keys
generated by PGP >=5, which is what all the kids are using these
days.

Unfortunately, the latest version of PGP (6.5.8) uses C++.  Grrr....
I tried to port GPG (the GNU version, which at least is written in
straight up C), but gave up in disgust after a few hours of fixing
stupid type incompatabilities in various source files.

It'd be nice to see an OpenPGP implementation under Plan 9, maybe
built from the ground up.

	- Dan C.

[9fans] sam and ssh

[Lucio De Re]

Something in an early 3ed discussion gave me the impression that sam
can be run to a remote host over an ssh session.  I haven't quite
managed to get my mind around this, but I assume it means that sam can
originate an ssh session and request the remote ssh daemon to tunnel
the traffic.  Another possibility would be to use ssh tunneling, but
that's a pain at best.

Anyone would like to explain how it ought to be done, if I understood
the idea properly?  I seem to remember that the feature is available
in the Win version of sam too.  I can't find any details in the sam
man pages, but I'm notorious for not seeing the obvious :-(

++L

Re: [9fans] sam and ssh

[Scott Schwartz]

| Something in an early 3ed discussion gave me the impression that sam
| can be run to a remote host over an ssh session.

Sam always runs as two processes, and "sam -r" uses rx to launch the
backend on a remote system.  To use ssh instead, bind /bin/ssh on top
of /bin/rx.

Re: [9fans] sam and ssh

[Micah Stetson]

> the idea properly?  I seem to remember that the feature is available
> in the Win version of sam too.  I can't find any details in the sam
> man pages, but I'm notorious for not seeing the obvious :-(

Only in the new Windows version from the Plan 9 updates
page.  Running sam -r some_host from a Windows 98 box works
great, but it fails on Win95 and I haven't been able to
get sam to work at all on XP.  I haven't tried WinME.

On Windows sam uses srx which will pop up a window for
you to enter a username/password for the ssh connection.
I don't understand the behaviour on Win95: if I run srx
from a DOS window, it works fine and I can run any command
on the remote host.  If I run it from within a 9term window
I get 'fatal error: could not dial: some_host: socket:
error 10106'.  I get the sam message from sam -r if I run
it from within 9term.  If I run sam -r in a DOS window,
it fails, but prints no message.

Micah

Re: [9fans] sam and ssh

[Lucio De Re]

On Wed, Mar 27, 2002 at 05:28:56PM -0800, Micah Stetson wrote:
> 
> Only in the new Windows version from the Plan 9 updates
> page.  Running sam -r some_host from a Windows 98 box works
> great, but it fails on Win95 and I haven't been able to
> get sam to work at all on XP.  I haven't tried WinME.
> 
Tempting, but I won't install WinME just to check :-(  I'll keep it in
mind if I get near a WinME installation, additional motivation, as it
were...

> On Windows sam uses srx which will pop up a window for
> you to enter a username/password for the ssh connection.

Not on WinNT: I get a "panic: can't connect yet".

> I don't understand the behaviour on Win95: if I run srx
> from a DOS window, it works fine and I can run any command
> on the remote host.  If I run it from within a 9term window

Where do you get 9term?!

> I get 'fatal error: could not dial: some_host: socket:
> error 10106'.  I get the sam message from sam -r if I run

Hm, I suppose one can consult the MS KB for that error number.  The IP
stack under Win isn't wonderful and the error messages are an absolute
treat :-(

> it from within 9term.  If I run sam -r in a DOS window,
> it fails, but prints no message.
> 
Not even a very fast "not for console mode"?  Then again, I can't find
rsx either, I must be looking in totally the wrong place.

++L

Re: [9fans] sam and ssh

[Lucio De Re]

On Wed, Mar 27, 2002 at 10:15:19PM +0200, Lucio De Re wrote:
> 
> Where do you get 9term?!
> 
I found it, why did I only find it now?

> Not even a very fast "not for console mode"?  Then again, I can't find
> rsx either, I must be looking in totally the wrong place.
> 
Yep, I was.  Nice new, unused tools :-)  Yum!

For the record, under NT, SAM doesn't seem to care to connect
remotely, much.

++L

Re: [9fans] sam and ssh

[Lucio De Re]

On Wed, Mar 27, 2002 at 10:22:53PM +0200, Lucio De Re wrote:
> 
> For the record, under NT, SAM doesn't seem to care to connect
> remotely, much.
> 
Seems like I need a Win refresher course :-(

Sam under NT exhibits the same behaviour as suggested for 98, it
doesn't prompt for authentication if spawned from a 9term.

Nice tools, definitely.  I'm glad I asked the question, now.

++L

Re: [9fans] sam and ssh

[Lucio De Re]

On Wed, Mar 27, 2002 at 10:36:42PM +0200, Lucio De Re wrote:
> 
> Sam under NT exhibits the same behaviour as suggested for 98, it
> doesn't prompt for authentication if spawned from a 9term.
> 
I'm an unreliable witl^Hness :-(

I'm going to shut up now.  Under NT, sam works both off a DOS
command line and 9term.  Seems to take a while to get going, that's
all, and the prompt window needs to rise to the surface, not stay
buried under all the other garbage.

++L

Re: [9fans] sam and ssh

[peter huang]

I was able to copy plink.exe (from putty) over srx.exe.   I was able to edit
files from unix environment (this is under win2k).  the srx.exe works but I
want have better control of my ssh environment (such ssh2 and public key
support with openssh).

-peter

"Lucio De Re" <lucio@proxima.alt.za> wrote in message
news:20020327223641.M25951@cackle.proxima.alt.za...
> On Wed, Mar 27, 2002 at 10:22:53PM +0200, Lucio De Re wrote:
> >
> > For the record, under NT, SAM doesn't seem to care to connect
> > remotely, much.
> >
> Seems like I need a Win refresher course :-(
>
> Sam under NT exhibits the same behaviour as suggested for 98, it
> doesn't prompt for authentication if spawned from a 9term.
>
> Nice tools, definitely.  I'm glad I asked the question, now.
>
> ++L
Followup-To:
Distribution:
Organization: University of Bath Computing Services, UK
Keywords:
Cc:


--
Dennis Davis, BUCS, University of Bath, Bath, BA2 7AY, UK
D.H.Davis@bath.ac.uk

[9fans] samuel

[Alex Danilo]

>If you just prefer GUIs to composition of commands, just say so.

I don't prefer GUIs.  What does sam itself do - provide a GUI
where grep, find, ed, and sed would have worked just fine:-)

Rob states:

>make grandiose philosophical statements about it.  Well, I have tried
>samuel and I didn't like it, partly because it didn't seem to help all
>that much (because grep could do a lot of the work for you just fine);
>partly because added a set of special-purpose features rather than a
>general-purpose approach; partly because it cluttered up the menus to
>have that extra functionality, making it less useful as an editor; and
>partly because it just wasn't very well done.

The last point is the correct one.  It was badly done, but it was an
experiment.  I quote myself:

>The whole point of samuel was an experiment in application development
>environments.  Nothing more.

Rob:
>You won't get me to say I don't like tools and don't want to add to
>the the toolkit.  I will say, however, that I demand the tools be good
>and that they should increase the set of problems to be solved or
>significantly increase the ease with which they can be solved.

True - most of samuel was junk - the interpreter didn't work, the
advisor was ill-advised.  But the browser (one whole extra menu entry,
gee) added a wonderful code navigation tool.  'grep' can't parse and
so arguing that layout is a substitute for the language aware cscope
is _really_ misguided.  Heck, what are most of you coding in anyway?
Limbo and C probably.  Not much has changed since the 70's huh!

The point of my post is that as supposedly intelligent beings we should
apply that to make everyones job easier.  If you can get "90% of the
functionality with grep" and you're happy with that - then fine.

But, if you insist on building systems which require an IQ of more
than 100 to operate, then by definition you are excluding more
than 1/2 of the world's population from using the system.

>Samuel didn't make the grade.  If it had, I think it would still be
>around.

Well it is, you just have to know where.

Alex

Re: [9fans] samuel

[Alexander Viro]

On Mon, 11 Mar 2002, Alex Danilo wrote:

> True - most of samuel was junk - the interpreter didn't work, the
> advisor was ill-advised.  But the browser (one whole extra menu entry,
> gee) added a wonderful code navigation tool.  'grep' can't parse and
> so arguing that layout is a substitute for the language aware cscope
> is _really_ misguided.  Heck, what are most of you coding in anyway?
> Limbo and C probably.  Not much has changed since the 70's huh!

I have to deal with pretty large codebase regulary (Linux kernel) and
compared to intelligent use of grep cscope _sucks_.  For a lot of
reasons, starting with the fact that in most of the cases what you
are looking for is not just an identifier.  And that's aside of such
details as existence of cpp(1)...

Re: [9fans] samuel

[Steve Kilbane]

Alexander Viro wrote:
>  And that's aside of such
> details as existence of cpp(1)...

Yeah, well. Determined application of cpp pretty much defeats any source
browsing method. :-)

steve

Re: [9fans] samuel

[Andrew Simmons]

>But, if you insist on building systems which require an IQ of more
>than 100 to operate, then by definition you are excluding more
>than 1/2 of the world's population from using the system.
>
Well, I don't see how that could be true by definition, but surely the
point is that the discussion concerns an environment for programmers,
rather than the world's population in general, and one would hope that the
average programmer has an IQ greater than 100. Programmers may be happy to
put in the time to learn a system that is difficult to use at first glance,
in exchange for increased productivity down the track. Having said that,
I'm with you on the usefulness of syntax-aware tools. The problem is that
they are often done badly (Visual C++), or appallingly badly (Visual
Basic). I do however like the Codewarrior IDE on the Mac, which provides a
drop down list of functions. Others here would hate it. Live and let live.

Re: [9fans] samuel

[Thomas Bushnell, BSG]

andrew@mbmnz.co.nz (Andrew Simmons) writes:

> >But, if you insist on building systems which require an IQ of more
> >than 100 to operate, then by definition you are excluding more
> >than 1/2 of the world's population from using the system.
> >
> Well, I don't see how that could be true by definition [...]

Well, strictly it's not.  IQ is (supposedly) normed with the average
at 100.  Alex Danilo's statement was I guess taking it that the median
was 100.  The point is still pretty much the same; if IQ follows a
normal distribution, then they are identical criteria.

Most people think they are above average, but it just ain't so.  The
average person is really, well, average.

Thomas

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[anothy]

// ...continuous criticism... ...of everything beyond the boundaries
// of Plan 9/Inferno, no matter how justified, isn't healthy.

i'd agree with the implication but disagree with the statement.

i think constant criticism is a very good thing, provided it's done in a
productive manner, and the criticism is somewhat more concrete than
"not invented here." it is this ongoing criticism that will help all these
systems change, correct their flaws or failures of vision, and improve.

which brings me to my point of agreement. you say "everything beyond
the boundaries of Plan 9/Inferno" and i think that's a good observation.
Plan 9 and Inferno are by no means perfect. as someone noted some
time ago, the alt.sysadmin.recovery FAQ gets it right: no systems don't
suck, plan 9 simply sucks less than others. i think it's important that
_everybody_ needs to be occasionally reminded that they suck in some
fashion or other. but with that needs to come info on _how_ one sucks,
and how to suck less.

take the current compiler discussion. i would say the contention here is
not that GCC is worthless and ?c/?l are perfect, but rather that one can
be more productive improving ?c/?l than GCC. you correctly note that
the Plan 9 tools don't deal with cross-OS compiling (except in very
limited cases), whereas GCC does (to some degree, anyway). i don't
believe anyone is disputing this, nor claiming it doesn't matter. but i bet
most people here would say it'd require less overall man-hours to get
8c/8l to build Linux binaries than to get GCC to build Plan 9 ones, and
that the results would enable people on whatever platform to develop
things better and more quickly.

// Perl would open another [door], Python a third, Apache a fourth, etc.

Perl and Python i can see, for sure. they're languages, with apps
written in them, that people want to be able to use. and for good reason.
Perl and Python each have benefits one cannot get with C, rc, or Limbo.
i'd love to see them supported better on Plan 9.

Apache's a harder sell. do people want "Apache" or a web server with a
certain feature set? if the later, one has a decision to make: port (and
maybe improve) Apache, improve Plan 9's httpd, or build something
new. there's a legitamate cost/gain analysis here; the fact that we didn't
build Apache shouldn't enter into it.

i agree everyone could benefit by more active exchange between Plan 9
and other systems. but i think it's a big leap to go from there to saying
we should spend more time improving GCC or porting Apache.
ア

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[Lucio De Re]

On Wed, Nov 07, 2001 at 04:34:47PM -0500, anothy@cosym.net wrote:
>
> Apache's a harder sell. do people want "Apache" or a web server with a
> certain feature set? if the later, one has a decision to make: port (and
> maybe improve) Apache, improve Plan 9's httpd, or build something
> new. there's a legitamate cost/gain analysis here; the fact that we didn't
> build Apache shouldn't enter into it.
>
I was using examples that came to mind immediately, not a short
wish list.  I have never used plan 9's httpd, but from the features
list it seems very good.  Certainly can't fault it from the client's
perspective.

A better point would have been made (but I was really trying not
to fan the flames) by suggesting that Mozilla be ported to Plan 9.

It's not the product, the developers, as much as the usefulness.
My point is that there is a developers' community out there and if
only they knew about acme and ?c, they might embrace them.  But
they need attracting, which can only be done with the familiar.
In my opinion, as a NetBSD user amongst Linux developers, what
caught the imagination there was Doom/(oops, can't remember the
name now).  From the large group of game aficionados (not to call
them addicts) grew a smaller community of contributors.

I have no difficulty concurring with everyone here that quality is
not high on these developer's agenda, but bulk cannot be avoided.
Amongst all the chaff, there are a few gems, of which Apache would
certainly be one.

So, to re-iterate my point, Plan 9 is the better platform, but should
not present itself from a position of arrogance, but rather endeavour
to provide a better platform for development (which is easy) with a
more familiar environment.

> i agree everyone could benefit by more active exchange between Plan 9
> and other systems. but i think it's a big leap to go from there to saying
> we should spend more time improving GCC or porting Apache.
> ?

It's a matter of perspective, I think.  My platform needs are closer
to SQL-oriented databases, volume processing, event-oriented diary
systems.  Some of this I can find in the public domain (postgreSQL
or mySQL would be options) while the rest (ERP stuff like SAP) is
unnecessarily complex and expensive, there isn't enough fat in my
client's profit margins to afford SAP or Great Plains, nor is there
enough money to invest in the doubtful expertise of an MCSE as
server administrator.

Plan 9 has all the right attribute as the platform of choice, is
just missing the applications.  And I have little doubt that
developing the applications would be easier and for the same
complexity one may get a much richer feature set.  But it takes a
large community of developers to produce (amongst the noise) good,
solid products.

And one of Plan 9's greatest assets is what my mind has latched on
as the "Bell Labs Giants".  I find it hard to appreciate all their
contributions, though, when their attitude is unnecessarily (not
"unjustifiably", I admit) disparaging.  And I see some churn on
this list as a result, the person I believe should be in there with
the Giants but has been sadly quiet for a long time is G David
Butler, I really thought he had already added good value to Plan
9 and was going to provide more.  There are others I should recall
but it's probably best that I can't who are brushed aside because
they don't quite tow the party line.  I guess that's what I find
hard to swallow.

Not that the party line isn't good, quite the contrary, but it also
benefits from occasional divergence, while using it as a soap box to
denigrate the opposition seems to me to be very short sighted.  Which
is heavy accusation to level at the Giants, but it appears to me to be
a truthful one.

++L

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[George Michaelson]

God, time cycles get shorter. At least for Jerry Cornelius the loop
is the 64,000 year 'small' circuit.

As one who has never run it, but often pressed for wider deployment of Plan9,
suggesting it could be bedded in as DNS servers, or critical infrastructure,
I can only repeat the Al Haig line once again:

	In order to sell Plan 9, it was neccessary to destroy it.

Folks, its a research tool. Its not a bet-the-farm-lucent-will-rise-again
product, its not a tool for the masses, If Tom Duff can make movies on it
thats way cool, but please, don't turn it into the kind of packaged crap
its "finger-quotes" competing against.

For me, half the pleasure of reading about this thing is that its obviously
fanatically small, and reductionist. Making it any bigger will ruin it.

No irony intended.

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

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[Jim Choate]

On Thu, 8 Nov 2001, George Michaelson wrote:

> Folks, its a research tool. Its not a bet-the-farm-lucent-will-rise-again
> product, its not a tool for the masses, If Tom Duff can make movies on it
> thats way cool, but please, don't turn it into the kind of packaged crap
> its "finger-quotes" competing against.
>
> For me, half the pleasure of reading about this thing is that its obviously
> fanatically small, and reductionist. Making it any bigger will ruin it.

Then get ready to have it 'ruined'.

http://einstein.ssz.com/hangar18


 --
    ____________________________________________________________________

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

                                             Bumper Sticker

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

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[Lucio De Re]

On Thu, Nov 08, 2001 at 03:43:53PM +1000, George Michaelson wrote:
>
> Folks, its a research tool. Its not a bet-the-farm-lucent-will-rise-again
> product, its not a tool for the masses, If Tom Duff can make movies on it
> thats way cool, but please, don't turn it into the kind of packaged crap
> its "finger-quotes" competing against.
>
I'm not sure where this discussion is going.  I started by questioning
the wisdom of criticising competing products in a detrimental rather
than constructive fashion, a habit I believe detracts from the
otherwise impeccable record of the Plan 9 developers and contributors.

Naturally, I also wanted to know where the attitude originated and
whether it was conceivable that it could be better channeled.  Not
that I can express myself so well as to be understood without much
gesticulation and verbal diarrhoea.

> For me, half the pleasure of reading about this thing is that its obviously
> fanatically small, and reductionist. Making it any bigger will ruin it.
>
A lot of same criticism seems to point to a desire to see Plan 9
gain its rightful position in the operating system marketplace and
the unfairness of it having to compete with obviously inferior
products with greater market share.

I certainly can't speak for the Plan 9 developers, but in my opinion
the Plan 9 concepts, across the board, deserve much greater
acceptance.  Where I believe my opinions disagree with the Plan 9
developers' is how such broader acceptance should occur: I'm almost
Microsoftish with an "embrace and extend" philosophy, while "they"
seem to have more of an "educate and conquer" approach.

At the core, I have always believed that we can draw on the broad
developer community for further development, mainly because that
is all I can contribute to Plan 9 myself.  It is my impression,
and it must please be seen as such, that the Plan 9 developer are
fearful that the GNU/Linux/*BSD etc. developer community will
"taint" Plan 9 with their indiscriminate bloat.  Maybe such
contamination is possible (I believe it is called miscegenation in
the Old Testament) and likely, but I would argue that we have not
yet seen the results that are so greatly feared, and that we should
encourage the experimentation, not prevent it by taking a critical
approach to it.

I don't expect the Plan 9 team to agree with me, we have a very
different outlook at the "social" level, but perhaps there are
others on this mailing list who feel that the "social experiment
(Che Guevara)" is worth conducting even if the casualties could be
numerous.

Naturally, unlike Che Guevara, I don't propose to snatch the
leadership position from the Plan 9 team, quite the contrary, I
very much appreciate their continued contribution.  I would just
appreciate it even more if they were encouraging rather than critical
in those areas that apparently offend their sensibilities.

++L

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[Thomas Bushnell, BSG]

lucio@proxima.alt.za (Lucio De Re) writes:

> A lot of same criticism seems to point to a desire to see Plan 9
> gain its rightful position in the operating system marketplace and
> the unfairness of it having to compete with obviously inferior
> products with greater market share.

I can't speak for the evils of Redmond.  But a clear reason that Plan
9 is beaten out by GNU/Linux is that the latter is a free operating
system, and always has been, and Plan 9 isn't and never was.

> At the core, I have always believed that we can draw on the broad
> developer community for further development, mainly because that
> is all I can contribute to Plan 9 myself.

The broad developer community you can hope to draw from is, more or
less, committed to free software.  I would turn around tomorrow and
run Plan 9 nearly exclusively if it were free software, and I'd spend
effort making it as good as possible.

But it's not free software, so I won't.  And there are *many* people
who share the same ideals.  Those people contribute to systems like
the GNU/Linux distributions and the various *BSD systems.

Thomas

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[Quinn Dunkan]

> is all I can contribute to Plan 9 myself.  It is my impression,
> and it must please be seen as such, that the Plan 9 developer are
> fearful that the GNU/Linux/*BSD etc. developer community will
> "taint" Plan 9 with their indiscriminate bloat.  Maybe such
> contamination is possible (I believe it is called miscegenation in

I think it's a much more practical matter.  gcc is not ported because no one
has ported it.  No one has ported it because no one has the time, which means
that no one wants it enough to set aside the time.  Hey, maybe dhog will
finish whatever he's doing with it, and then everyone who wants gcc can go get
it.

Sure, 9fans is often critical of things like gcc.  But if all it takes to
scare you out of porting something is a few disparaging comments from a
mailing list, you'd never have the stomach to do the port in the first place.

Plan9 was obviously designed, and designed by people who have clear and strong
ideas about what good design is.  But if you port or create something that
violates the design ideas of some other people, they're not going to come to
your house and shoot you.  Maybe someday someone will finish and release a gcc
port.  Then maybe someone will port mozilla.  I wouldn't expect those to go
into the standard distribution, but we do have a wiki, and it's dirt simple to
put up a page and a link.

Plan9 is also plenty free enough for me, and I suspect it is for most other
people as well (naturally you only hear from the vocal dissenters, though).
comp.os.plan9 has its share of silly time wasting arguments, but it would
hardly be Usenet without them.

> I don't expect the Plan 9 team to agree with me, we have a very
> different outlook at the "social" level, but perhaps there are
> others on this mailing list who feel that the "social experiment
> (Che Guevara)" is worth conducting even if the casualties could be
> numerous.

If you were waiting for *my* approval, go ahead and conduct it, whatever that
means.  Do whatever you want, as long as it doesn't involve shooting people.

> Naturally, unlike Che Guevara, I don't propose to snatch the
> leadership position from the Plan 9 team, quite the contrary, I
> very much appreciate their continued contribution.  I would just
> appreciate it even more if they were encouraging rather than critical
> in those areas that apparently offend their sensibilities.

I think they're very encouraging.  When technical questions are raised, they
give helpful and clear answers, even when those questions are answered in the
documentation.  When "philosophical" questions are raised, they actually try
to understand what the question is (which is often most of the work, see the
"link" debate), and then give their honest opinions.  What more do you want, a
lollipop?  Since when does anyone need a unanimous vote of acceptance from
9fans to do anything?


On the subject of "what makes plan9 unique", for me, plan9 completely changed
my views on the mouse.  Forget the networking stuff, I just have a 14.4K
modem, the UI is more fun than anything else.  Once, not long ago, I honestly
believed that if I wanted to replace a word I had typed it was easier and
faster to type "^]2bWcWfoo^]A" than to click on the word and type "foo", and
therefore, it was a necessary evil to embed GNU readline into everything that
read from the terminal.

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[Andrey A Mirtchovski]

On Thu, 8 Nov 2001, Lucio De Re wrote:

> So, to re-iterate my point, Plan 9 is the better platform, but should
> not present itself from a position of arrogance, but rather endeavour
> to provide a better platform for development (which is easy) with a
> more familiar environment.
>

I have a different opinion, much based on what I see on this list and what I
hear from prople with attitudes similar to this:

Plan 9 developers are not arrogant, rather, they are trying to defend
themselves and their ideas from the random bunch of people who come here
and lend their advise and thoughts without being asked for, or without
really being aware of the system they discuss (it's really mostly a "you're
out of your element.." issue, to continue throwing quotes from favourite
movie :)...

I do believe that Plan 9 is _the_ OS with the clearest philosophy behind it
-- one that has the system build around it and one that can be continuously
defended without running into infinite loops (examples of the opposite would
be -- Simple OS (Linux) and Optimized for i386 (FreeBSD))... Should we break
this just to lure more people in, without making sure they appreciate P9 at
a level different than just very neatly written code?

Well, come to think of it, after a few glasses of wine, P9 might as well be
called 'the dude'... Then everyone else starts to sound like they ask 'vere
is ze money libouski' :)

This not a flame, simply musings I've wanted to share but haven't had the
guts to up until now...

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[Steve Kilbane]

I don't see tools like Perl or Python bringing more people into Plan 9,
particularly when faced with the mass of Windows users. Plan 9 is
about doing things a different way, with the implied assumption that the
difference arises from an attempt to improve things. If potential users
need their comfy feature set to attract them, then they're the wrong user
set. Plan 9 is implicitly targeted at people who are willing to try changing
how they work.

This is also one reason why concepts from Plan 9 (which includes manner of
thought as well as software models) has less impact on the outside world:
both the *nix worlds and the Windows worlds are significantly larger user
bases that are more into evolutionary change than revolutionary change.
Windows XP has only just dropped DOS; Linux and GNU are basically copies of
30-year-old systems. Such large user bases are inherently resistant to
change.

This is also one reason why gcc is the crufty behemoth it is, and ?c
isn't: gcc had to accept and deal with problems on many systems, while
?c could assume they'd go away, by being fixed elsewhere. As forsyth says,
portable compilers aren't inherently that nasty, but gcc itself has become
a large system, dealing with many scenarios, and thus encouraging evolution
rather than revolution. That's why it's a platypus.

steve

Re: [9fans] Rant (was Re: Plan9 and Ada95?)

[Boyd Roberts]

    Perl and Python i can see, for sure.

There are many things I like and dislike about Python, but it's as close to
limbo as I'm likely to get, at the moment.

Re: Plan 9 annoyances (was: Re: [9fans] mv vs cp)

[bwc]

>>Inferno != Plan 9.
>>There is no web browser in Plan 9---and that's got to be a big obstacle.

I have an iMAC for that.  One OS doesn't have to do everything.

Brantley Coile

Re: Plan 9 annoyances (was: Re: [9fans] mv vs cp)

[Douglas A. Gwyn]

bwc@borf.com wrote:
> >>There is no web browser in Plan 9---and that's got to be a big obstacle.
> I have an iMAC for that.  One OS doesn't have to do everything.

But Plan 9 has been advertised as a superior alternative to the
usual developer's interactive computing environment.  A good Web
browser is another essential tool, these days.  Why should one
be forced to buy a second computer to do something that ought to
be right up the alley of the first one?

Browsers (was: Re: Plan 9 annoyances (was: Re: [9fans] mv vs cp))

[Lucio De Re]

On Wed, Oct 10, 2001 at 08:57:21AM +0000, Douglas A. Gwyn wrote:
> 
> But Plan 9 has been advertised as a superior alternative to the
> usual developer's interactive computing environment.  A good Web
> browser is another essential tool, these days.  Why should one
> be forced to buy a second computer to do something that ought to
> be right up the alley of the first one?

Because no-one has produced a browser that matches the quality of
the operating system it runs on (well, now that I re-read what I
wrote, of course Microsoft did, indeed).  But a web browser for
Plan 9 is a tall order and no-one has the resources to produce one.
Second best is Charon and if the threat from Rog is as I understand
it, Charon for Plan 9 is not that far away at least in some guise.

The other factor is Plan 9's origin.  Bell Labs (in the broadest
sense) are determined to do what they are good at and do it well.
I don't think it is an idle claim that Plan 9 is "a superior
alternative", although that is distinctly a value judgement.  But
given Plan 9's complete environment it ought to be moderately easy
for a dedicated developer to produce the ultimate browser.  It's
just Bell Labs that understandably do not feel obliged to do it
themselves.  Perhaps mothra showed up a weakness in their skill
set, or, more likely, warned of the price they'd have to pay to
succeed.

And then there's Java, isn't that a massive obstacle?  Should that
also be released as part of Plan 9 because it is "something that
ought to be right up the alley"?

On the other hand, I would be willing to pay Opera if they ported
their browser to Plan 9, even though it's been a while since I used
it.  I'm sorry they didn't appreciate Bell Labs' overtures and I
wonder what kind of misunderstanding might be behind it.  Of course,
there's also a philosophical shift involved, much as porting Mozilla
to Plan 9 would hardly be feasible without enormous (C++) efforts.

Which reminds me.  Was it dhog that threatened to release GCC 3.0
on us?

++L

Re: Browsers (was: Re: Plan 9 annoyances (was: Re: [9fans] mv vs cp))

[Steve Kilbane]

>  But
> given Plan 9's complete environment it ought to be moderately easy
> for a dedicated developer to produce the ultimate browser.

Plan 9 was an opportunity to redo from scratch, properly this time.
The web, in contrast, builds kruft upon kruft at an horrendous rate.
For a browser to be usable, it has to import all that kruft back in.
While there's a sliding boundary for how much kruft is acceptable in
order to communicate with non-Plan 9 systems, I think browsers crossed
over that boundary years ago.

steve

Re: Browsers (was: Re: Plan 9 annoyances (was: Re: [9fans] mv vs cp))

[John Murdie]

On 10 Oct, Steve Kilbane wrote:
>>  But
>> given Plan 9's complete environment it ought to be moderately easy
>> for a dedicated developer to produce the ultimate browser.
> 
> Plan 9 was an opportunity to redo from scratch, properly this time.
> The web, in contrast, builds kruft upon kruft at an horrendous rate.
> For a browser to be usable, it has to import all that kruft back in.
> While there's a sliding boundary for how much kruft is acceptable in
> order to communicate with non-Plan 9 systems, I think browsers crossed
> over that boundary years ago.
> 
> steve

Perhaps someone in the Plan 9 world has implemented a `browser' for a
`web' document description language in Plan 9 style. There's no reason
why the Plan 9 form of innovation (step back, think, redesign and
rewrite) should not be applied to the Web, is there?

Anyone?

-- 

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

Re: Browsers (was: Re: Plan 9 annoyances (was: Re: [9fans] mv vs cp))

[Steve Kilbane]

John wrote:
> There's no reason
> why the Plan 9 form of innovation (step back, think, redesign and
> rewrite) should not be applied to the Web, is there?

No reason at all, although it wouldn't solve the primary complaint
about the lack of a web browser, namely that one cannot read one's
favorite site, because the sites wouldn't be compatible.

steve

[9fans] Re: Browsers

[Boyd Roberts]

The problem is intractable, but not inabstraktable.

Re: [9fans] mv vs cp

[jmk]

As Dave points out, there are a lot of balls in the air during
an atomic 'rename'. 4.2BSD introduced the 'rename' system call,
and as an alpha/beta tester for 4.1[abc] and 4.2BSD I can testify
to how long it took to get it right and how much ugly code was
involved.

--jim

Re: [9fans] mv vs cp

[Lucio De Re]

On Sun, Oct 07, 2001 at 12:23:59PM -0400, jmk@plan9.bell-labs.com wrote:
> 
> As Dave points out, there are a lot of balls in the air during
> an atomic 'rename'. 4.2BSD introduced the 'rename' system call,
> and as an alpha/beta tester for 4.1[abc] and 4.2BSD I can testify
> to how long it took to get it right and how much ugly code was
> involved.
> 
There are really only two social factors overriding here.  People
like me have grown to expect it, unfortunate as it may be, and the
alternative is inconsistent and open to error, besides being much
more time and resource intensive.

In addition, it may be more consistent for mv not to go part way
and do a cp+rm on my behalf _on_condition_ that the request is not
recursive, rather not do it at all.  But I suppose my MSDOS background
shows here, the "mv" I'm thinking of is "REN".  That, I ought to
be able to fix by crippling "mv".

What wasn't clear from Dave's response, is whether we would need
a "Tmv" to do it all, including recursive copies that (shudder!)
may need to understand the entire namespace, or just "Tren" that
may still change the namespace, but at least won't have to make
decisions on how to follow mounted resources.

I should imagine that BSD "rename" must have been made orders of
magnitude more complex by symbolic links.  After all, SysV 3.2 "mv"
could rename directories into other directories in the same
filesystem, couldn't it?  It's been a long time since my 3B2 was
turned off, so it's hard for me to check.  I'm almost certain SCO
Xenix and Unix could do it without copying.

++L

Re: [9fans] mv vs cp

[Alexander Viro]

On Mon, 8 Oct 2001, Lucio De Re wrote:

> On Sun, Oct 07, 2001 at 12:23:59PM -0400, jmk@plan9.bell-labs.com wrote:
> > 
> > As Dave points out, there are a lot of balls in the air during
> > an atomic 'rename'. 4.2BSD introduced the 'rename' system call,
> > and as an alpha/beta tester for 4.1[abc] and 4.2BSD I can testify
> > to how long it took to get it right and how much ugly code was
> > involved.

So can anybody who had seen current 4.4BSD derivatives.  _None_ of them
got it right.  rename()/rename() race (creating a loop and detaching it
from the rest of tree) is still there.
 
> There are really only two social factors overriding here.  People
> like me have grown to expect it, unfortunate as it may be, and the
> alternative is inconsistent and open to error, besides being much
> more time and resource intensive.

> I should imagine that BSD "rename" must have been made orders of
> magnitude more complex by symbolic links.  After all, SysV 3.2 "mv"
> could rename directories into other directories in the same
> filesystem, couldn't it?  It's been a long time since my 3B2 was

Same race + metric buttload of other fun stuff.

And then there is _really_ fun stuff in userland.  Like find / mv and
rm -rf / mv races that allow any user to create a deep tree in /tmp,
wait for cron-ran script to start removing it and do something along
the lines of mv /tmp/foo/bar/baz /tmp/quux, tricking find(1) or rm(1)
into walking up into the root and proceeding from there.  Works like
charm on almost all Unices I've seen.

Sure, it's a broken userland and it needs to be fixed whenever such
bugs are found, but the point is that writing correct tree-walker
that would deal gracefully with cross-directory renames is _nasty_.

Re: [9fans] mv vs cp

[George Michaelson]

> So can anybody who had seen current 4.4BSD derivatives.  _None_ of them
> got it right.  rename()/rename() race (creating a loop and detaching it
> from the rest of tree) is still there.
>  

So can you say how often in practice that race condition is exercised? 

> > I should imagine that BSD "rename" must have been made orders of
> > magnitude more complex by symbolic links.  After all, SysV 3.2 "mv"
> > could rename directories into other directories in the same
> > filesystem, couldn't it?  It's been a long time since my 3B2 was
> 
> Same race + metric buttload of other fun stuff.

turning a strict tree into a mesh/DAG is always fun. But, its also possibly
useful for some people. Me? I liked the newcastle connection but we don't
have /.../ so I guess I lost. Namespaces might be in the same spirit.

I understand its a deeply held religion, but what IS it with runtime/use-time
reference by name which people find so offensive in the filesystem apart from
implementation complexity? We have call by name/value/reference in code, why
not in namespaces?

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

Re: [9fans] mv vs cp

[Alexander Viro]

On Mon, 8 Oct 2001, George Michaelson wrote:

> 
> > So can anybody who had seen current 4.4BSD derivatives.  _None_ of them
> > got it right.  rename()/rename() race (creating a loop and detaching it
> > from the rest of tree) is still there.
> >  
> 
> So can you say how often in practice that race condition is exercised? 

Any time when attacker feels like that.  System where nonprivileged users
can cause filesystem corruption is broken.  Period.

Re: [9fans] mv vs cp

[George Michaelson]

> Any time when attacker feels like that.  System where nonprivileged users
> can cause filesystem corruption is broken.  Period.
> 

Umm yes, but Alexander, when was the last time you *saw* one of these?

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

Re: [9fans] mv vs cp

[Lucio De Re]

On Mon, Oct 08, 2001 at 04:49:43PM +1000, George Michaelson wrote:
> 
> > Any time when attacker feels like that.  System where nonprivileged users
> > can cause filesystem corruption is broken.  Period.
> > 
> 
> Umm yes, but Alexander, when was the last time you *saw* one of these?
> 
It only needs to happen once.  Code Red/NIMDA anyone?

++L

Re: [9fans] mv vs cp

[George Michaelson]

> On Mon, Oct 08, 2001 at 04:49:43PM +1000, George Michaelson wrote:
> > 
> > > Any time when attacker feels like that.  System where nonprivileged use
rs
> > > can cause filesystem corruption is broken.  Period.
> > > 
> > 
> > Umm yes, but Alexander, when was the last time you *saw* one of these?
> > 
> It only needs to happen once.  Code Red/NIMDA anyone?
> 
> ++L
> 

Are you saying that this problem demonstrably exploited the race condition
between cp/mv and rename as implemented in FreeBSD?

I really do mean the question as put:

when was the last time anybody saw a successful exploit of this race condition
or an unstable filesystem they can show came from it, exploit or accident?

I have seen many problems with UFS/FFS, and Softupdates gave me the willeys
but I have also not yet seen serious corruption of the on-disk state which
lies directly with problems in the FS code itself. Side-effects of kernel
crashes during meta-state updates, sure. But this sounds to me like FUD which
in practice doesn't exist.

You could probably argue half a million potential race conditions exist in
lots of systems. The frequency they occur is different.

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

Re: [9fans] mv vs cp

[Alexander Viro]

[I suggest taking the thread off-list - further details of rename() races
in *BSD may be interesting, but they are off-topic for 9fans]

On Mon, 8 Oct 2001, George Michaelson wrote:

> Are you saying that this problem demonstrably exploited the race condition
> between cp/mv and rename as implemented in FreeBSD?

	Yes.  ufs_rename() is racy and yes, that race is wide enough to be
exploitable.  BTDT.
 
> I really do mean the question as put:
> 
> when was the last time anybody saw a successful exploit of this race condition
> or an unstable filesystem they can show came from it, exploit or accident?
> 
> I have seen many problems with UFS/FFS, and Softupdates gave me the willeys
> but I have also not yet seen serious corruption of the on-disk state which
> lies directly with problems in the FS code itself. Side-effects of kernel
> crashes during meta-state updates, sure. But this sounds to me like FUD which
> in practice doesn't exist.

	process 1:  current directory in /tmp/a/a/a/a/a, does
rename("/tmp/b/b", "a");
	process 2:  current directory in /tmp/b/b/b/b/b, does
rename("/tmp/a/a", "b");

	Normal outcome: first process to do rename() succeeds, second - fails
with ELOOP.  With the right timing _both_ succeed, creating a loop and
detaching it from the rest of filesystem.

	Notice that use of relative pathnames is critical here - otherwise
lookup in the second rename() will block on the lock acquired by the first
one.  Code in /sys/ufs/ufs/ufs_vnops.c implicitly assumes that lookups
ending in descendants of directory will have to pass through that directory.
That assumption is obviously false - namei(9) can start in a descendant of
directory in question.

	And no, it's not too narrow - window includes quite a bit of disk
IO.  Figuring out details of turning that into full-blown attack (i.e.
what should be done to widen the window) are left as an exercise to anyone
who can RTFS - it's pretty straightforward.

Re: [9fans] mv vs cp

[Alexander Viro]

On Mon, 8 Oct 2001, Lucio De Re wrote:

> On Mon, Oct 08, 2001 at 04:49:43PM +1000, George Michaelson wrote:
> > 
> > > Any time when attacker feels like that.  System where nonprivileged users
> > > can cause filesystem corruption is broken.  Period.
> > 
> > Umm yes, but Alexander, when was the last time you *saw* one of these?
> > 
> It only needs to happen once.  Code Red/NIMDA anyone?

Now, now.  It's nowhere near the nastiness of remote root compromise, but
yes, "nobody will ever try to screw me" is exactly the attitude that made
them possible.

As for the original question - two weeks ago, when I had demonstrated the
effect to a guy who claimed the OpenBSD kernel was "bulletproof".  OTOH, in
case of OpenBSD it's one of the mildest problems - there being able to do
rfork(RFPROC) means being able to cause kernel panic (races between
fstat()/close(), dup2()/close(), write()/close() - you name it).

Re: [9fans] mv vs cp

[Lucio De Re]

On Mon, Oct 08, 2001 at 04:10:29PM +1000, George Michaelson wrote:
> 
> I understand its a deeply held religion, but what IS it with runtime/use-time
> reference by name which people find so offensive in the filesystem apart from
> implementation complexity? We have call by name/value/reference in code, why
> not in namespaces?
> 
I suppose the fact that some, like me, will have trouble understanding
the discussion (took me a while just to figure the Directed Acyclical
Graph reference) I suppose religious war is to be expected?

If I understand the above correctly, my take is that symbolic links
are totally unchecked filesystem GOTOs and deserve a much worse fate
than they get.  Specially as they can point to the void and often do.

As to the rules (-L) for when they are dereferenced or not, that's a
morrass of confusion.

++L

Re: [9fans] mv vs cp

[George Michaelson]

> I suppose the fact that some, like me, will have trouble understanding
> the discussion (took me a while just to figure the Directed Acyclical
> Graph reference) I suppose religious war is to be expected?
> 
> If I understand the above correctly, my take is that symbolic links
> are totally unchecked filesystem GOTOs and deserve a much worse fate
> than they get.  Specially as they can point to the void and often do.
> 

Riiight, but that was designed in. Its a goal. They wanted that behaviour.

> As to the rules (-L) for when they are dereferenced or not, that's a
> morrass of confusion.

No argument. That could have been done so much better.

But the idea of a filename, booked into the filename space which says

	"I may not resolve all the time, but if I do, I point to <x>"

Isn't so inherently evil to me. it seems to me it mimics real-world behaviours
rather well.

Pointing out M$ has .LNK isn't going to help my cause much is it :-)

cheers
	-George

Re: [9fans] mv vs cp

[Lucio De Re]

On Mon, Oct 08, 2001 at 05:10:27PM +1000, George Michaelson wrote:
> 
> Pointing out M$ has .LNK isn't going to help my cause much is it :-)
> 
Well, and a registry.  In Plan 9's idiom, they could do with a few
more iterations.

One valid point is that computers are able to mimic real life more
closely, but I'm of the school that was trained on deterministic
behaviour.

Non-deterministic bahaviour is a curse and a sufficiently vast
computer system is non-deterministic.  Dijkstra had trouble with
interrupts, but I believe they could be assimilated into a
deterministic framework, modern bloat is orders of magnitude too
complex for such treatment.

There's a strange commercial strength in non-determinism, basically
getting the luser to accept failure as if it were essential.  I
suppose that was the M$ genius: don't let the user expect perfection
in anything but the _next_ generation of software.

++L

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

viro@math.psu.edu (Alexander Viro) writes:

> So can anybody who had seen current 4.4BSD derivatives.  _None_ of them
> got it right.  rename()/rename() race (creating a loop and detaching it
> from the rest of tree) is still there.

I'm pretty sure you're incorrect.  Can you describe the case in more
detail? 

Re: [9fans] mv vs cp

[Alexander Viro]

On Mon, 8 Oct 2001, Thomas Bushnell, BSG wrote:

> viro@math.psu.edu (Alexander Viro) writes:
> 
> > So can anybody who had seen current 4.4BSD derivatives.  _None_ of them
> > got it right.  rename()/rename() race (creating a loop and detaching it
> > from the rest of tree) is still there.
> 
> I'm pretty sure you're incorrect.  Can you describe the case in more
> detail? 

I'm pretty sure in the opposite and unfortunately *BSD source happens to
agree with me.  Consider the scenario I've described upthread (s/ELOOP/EINVAL/
- sorry about the braino) and think what happens if both renames get to
ufs_checkpath() simultaneously.  See /src/ufs/ufs/ufs_vnode.c::ufs_rename()
for details.  Notice that none of the lookups is going to come anywhere near
the vnodes affected by another rename() and ufs_checkpath() is called with
fvp unlocked and it unlocks dp (parent of fvp).

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

viro@math.psu.edu (Alexander Viro) writes:

> I'm pretty sure in the opposite and unfortunately *BSD source
> happens to agree with me.  Consider the scenario I've described
> upthread (s/ELOOP/EINVAL/ - sorry about the braino) and think what
> happens if both renames get to ufs_checkpath() simultaneously.  See
> /src/ufs/ufs/ufs_vnode.c::ufs_rename() for details.  Notice that
> none of the lookups is going to come anywhere near the vnodes
> affected by another rename() and ufs_checkpath() is called with fvp
> unlocked and it unlocks dp (parent of fvp).

It would certainly be a bug if two processes got to ufs_checkpath
simultaneously.  

My recollection is that BSD 4.3 contained code to serialize directory
renames, which solves the problem quite nicely.  I can't find an
analog in NetBSD (which of course has totally changed the organization
of the filesystem code since BSD 4.3).

It's adequate to do this on a per-filesystem basis (assuming you
prohibit cross-device renames), so the Hurd can conveniently do it in
individual servers (and does); Plan 9 could do the same I would
suspect.

Thomas

Re: [9fans] mv vs cp

[Alexander Viro]

On Tue, 9 Oct 2001, Thomas Bushnell, BSG wrote:

> It's adequate to do this on a per-filesystem basis (assuming you
> prohibit cross-device renames), so the Hurd can conveniently do it in

BTDT (see fs/namei.c::vfs_rename_dir() in Linux 2.4.x).  But that's far
from the only annoying piece of shit in rename(2) semantics.  E.g. you
are getting very ugly locking rules if you want to handle the case of
rename() removing an empty directory correctly.

Again, I've really been there and done that.  It wasn't pretty and I
would be much happier if rename() couldn't change the topology.  We
couldn't do that since it would break a lot of userland stuff;  Plan 9
has a luxury of dropping annoying crap and being able to find and fix
resulting breakage in userland.  In this case crap is not there in the
first place, so introducing it would cause a lot of ugliness in the kernel
for no good reason.

> individual servers (and does); Plan 9 could do the same I would
> suspect.

I suspect that Hurd has slightly, erm, different design philosophy (and
that's about the only printable comment I can make on the thing, so let's
not go there).

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

viro@math.psu.edu (Alexander Viro) writes:

> Again, I've really been there and done that.  It wasn't pretty and I
> would be much happier if rename() couldn't change the topology.  We
> couldn't do that since it would break a lot of userland stuff;  Plan 9
> has a luxury of dropping annoying crap and being able to find and fix
> resulting breakage in userland.  In this case crap is not there in the
> first place, so introducing it would cause a lot of ugliness in the kernel
> for no good reason.

I'm not expert in Plan 9, but it seems to me that it breaks it for the
user.

Is this just an example of the "New Jersey" preference for simplicity
of implementation over the "Cambridge" preference for correctness and
completeness?

Re: [9fans] mv vs cp

[davel]

On Tue, Oct 09, 2001 at 03:58:47PM +0000, Thomas Bushnell, BSG wrote:
> I'm not expert in Plan 9, but it seems to me that it breaks it for the
> user.

"The user"?
You mean there's only one?!?:-)
Most of the people who have been complaining are not typical "users".

In reality, I doubt that most users want to move large directories around.
(In my experience, most Windows users just leave files wherever
  the application drops them and then complain when they can't find them ...)

Plan9's ability to present a flexible view of the file system
probably obviates most reasons to want to shuffle directories around.

Also, to be brutal for a minute,
why *do* people want to move directories around:
why not just put them in the right place to start with?

The only time I can remember needing to move large directories
was when i needed to balance NFS servers,
i.e. relocating them from one file server or volume to another ...

> Is this just an example of the "New Jersey" preference for simplicity 
> of implementation over the "Cambridge" preference for correctness and
> completeness?

No polite comment available:-).

Cheers,
	Dave.

Re: [9fans] mv vs cp

[Ralph Corderoy]

Hi Dave,

> Also, to be brutal for a minute,
> why *do* people want to move directories around:

Typical reason is wanting to re-arrange a directory structure after a
better layout becomes clearer with use.


Ralph.

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

davel@luchie-chowchows.demon.co.uk writes:

> Also, to be brutal for a minute,
> why *do* people want to move directories around:
> why not just put them in the right place to start with?

Unlike people here, apparently, I sometimes make mistakes.  

Re: [9fans] mv vs cp

[davel]

On Wed, Oct 10, 2001 at 08:49:41AM +0000, Thomas Bushnell, BSG wrote:
> davel@luchie-chowchows.demon.co.uk writes:
> 
> > Also, to be brutal for a minute,
> > why *do* people want to move directories around:
> > why not just put them in the right place to start with?
> 
> Unlike people here, apparently, I sometimes make mistakes.  

So do I, and I expect to suffer for them,
not have kernel hacks put in place to make them easier to bodge around.

Cheers,
	Dave.

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

davel@luchie-chowchows.demon.co.uk writes:

> On Wed, Oct 10, 2001 at 08:49:41AM +0000, Thomas Bushnell, BSG wrote:
> > davel@luchie-chowchows.demon.co.uk writes:
> > 
> > > Also, to be brutal for a minute,
> > > why *do* people want to move directories around:
> > > why not just put them in the right place to start with?
> > 
> > Unlike people here, apparently, I sometimes make mistakes.  
> 
> So do I, and I expect to suffer for them,
> not have kernel hacks put in place to make them easier to bodge around.

Ah!  The job of software is not to make users' lives easier.  Not to
provide them tools to be more productive.

No--the job of the computer is to administer punishments for their
errors.

Are you really serious?

There are reasons to have a feature, and reasons not to.  But "we want
to punish people for making mistakes" is never a reason not to, and it
sounds like you have run out of steam when that's all you muster.

Re: [9fans] mv vs cp

[davel]

On Thu, Oct 11, 2001 at 09:10:20AM +0000, Thomas Bushnell, BSG wrote:

> Ah!  The job of software is not to make users' lives easier.  Not to
> provide them tools to be more productive.

What has that got to do with putting in hacks to get round mistakes?

> No--the job of the computer is to administer punishments for their
> errors.
> 
> Are you really serious?

Are YOU really serious?  Who said anything about punishment?

My point is that
a) we shouldn't be putting in hacks to ameliorate user mistakes:
   do you want undelete in there too?
b) Plan9 already has this nice-flexible FS architecture
   which gets around lots of the directory shuffling
   necessary on other OSs.

> There are reasons to have a feature, and reasons not to.  But "we want
> to punish people for making mistakes" is never a reason not to, and it
> sounds like you have run out of steam when that's all you muster.

a) It sounds like you have run out of steam if all you can do is misconstrue
   my meaning.
b) You make me sound like a sadist according to your logic,
   when in fact I'm a sado-masochist, since I'm punishing myself too!

Can we now please agree to differ?
This has gone on long enough.

Cheers,
	Dave.

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

davel@luchie-chowchows.demon.co.uk writes:

> My point is that
> a) we shouldn't be putting in hacks to ameliorate user mistakes:
>    do you want undelete in there too?

Plan 9 already *has* that feature.  Of course, it would be even nicer
if it had a complete version history, instead of "yesterday's
snapshot", but that's pretty good too (better than Unix!).

Yes, a good system should be making automatic backups.  And even
having convenient commands to recover files from the backup in the
event of mistakes is a good idea.

Re: [9fans] mv vs cp

[Alexander Viro]

On Tue, 9 Oct 2001, Thomas Bushnell, BSG wrote:

> Is this just an example of the "New Jersey" preference for simplicity
> of implementation over the "Cambridge" preference for correctness and
> completeness?

Taste vs. GNU?  That too, but there's more to it.

BTW, while we are at it, check what does GNU find(1) (which is the
default on Hurd, IIRC) do when somebody moves a directory while
find is walking through its subdirectories.  And think about the
implications.  What was that about correctness and completeness, again?

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

viro@math.psu.edu (Alexander Viro) writes:

> BTW, while we are at it, check what does GNU find(1) (which is the
> default on Hurd, IIRC) do when somebody moves a directory while
> find is walking through its subdirectories.  And think about the
> implications.  What was that about correctness and completeness, again?

find does not necessarily traverse every file on an active partition.  

But that has nothing to do with the moving of directories?  The same
thing happens with the moving of single files too.

Re: [9fans] mv vs cp

[Alexander Viro]

On Wed, 10 Oct 2001, Thomas Bushnell, BSG wrote:

> viro@math.psu.edu (Alexander Viro) writes:
> 
> > BTW, while we are at it, check what does GNU find(1) (which is the
> > default on Hurd, IIRC) do when somebody moves a directory while
> > find is walking through its subdirectories.  And think about the
> > implications.  What was that about correctness and completeness, again?
> 
> find does not necessarily traverse every file on an active partition.  
> 
> But that has nothing to do with the moving of directories?  The same
> thing happens with the moving of single files too.

GNU find traverses the tree with chdir() into subdirectories and _blind_
chdir("..") to go back.  Cwd follows directory when you do rename(2).
It does no such thing if you do mkdir() + recursive copy + recursive remove +
rmdir().  See the problem now?  "Find something under /tmp and do something
with all such objects" can be subverted into "find something under / and
do something with all such objects" by attacker that has access only to
subdirectories of /tmp.

And no, it's not only GNU.  Solaris find(1) has the same lovely property
(at least had it not too long ago - I hadn't checked the recent versions).
And it's not only find(1) - other tree-walkers are often vulnerable to
the same kind of crap.

I don't think that security implications really need to be explained.
Before you start saying that shared /tmp or all-mighty root are bad ideas,
think for a minute and see how the scenario can be modified for situations
other than one described above.

Notice that "generate pathnames and don't bother with chdir() at all" is
also not an answer.  E.g. Plan 9 rm(1) would become a glaring security
hole if ported on any recent UNIX.  Symlink attacks would make it very
interesting...  Something like dup, walk, clunk, stat and remove exported
to userland would allow to do such stuff more or less elegantly, but
without that you need fchdir() to avoid symlink attacks.

Anyway, the point is that cross-directory rename(2) leads to userland bugs
that are really nasty and, as experience shows, not obvious for a lot of
people.  Actually you've just demonstrated that.

It's not about kernel simplicity; userland code becomes much more complicated
to be able to cope with effects of having cross-directory rename(2) around.

Re: [9fans] mv vs cp

[erik quanstrom]

>Also, to be brutal for a minute,
>why *do* people want to move directories around:
>why not just put them in the right place to start with?

plan 9, an operating system for people who never change their minds 
or have new ideas.

erik

Re: [9fans] mv vs cp

[david presotto]

Hence my domain name.  Right on!
----- Original Message ----- 
From: erik quanstrom <quanstro@speakeasy.net>
To: <9fans@cse.psu.edu>
Sent: Tuesday, October 09, 2001 9:05 PM
Subject: Re: [9fans] mv vs cp


> >Also, to be brutal for a minute,
> >why *do* people want to move directories around:
> >why not just put them in the right place to start with?
> 
> plan 9, an operating system for people who never change their minds 
> or have new ideas.
> 
> erik
> 

Re: [9fans] mv vs cp

[Skip Tavakkolian]

and the minimalist home page. what? no javascript?!!!!

At 10:15 PM 10/9/2001 -0400, david presotto wrote:
>Hence my domain name.  Right on!
>----- Original Message ----- 
>From: erik quanstrom <quanstro@speakeasy.net>
>To: <9fans@cse.psu.edu>
>Sent: Tuesday, October 09, 2001 9:05 PM
>Subject: Re: [9fans] mv vs cp
>
>
>> >Also, to be brutal for a minute,
>> >why *do* people want to move directories around:
>> >why not just put them in the right place to start with?
>> 
>> plan 9, an operating system for people who never change their minds 
>> or have new ideas.
>> 
>> erik
>> 
>
>

Re: [9fans] mv vs cp

[davel]

On Tue, Oct 09, 2001 at 09:05:08PM -0400, erik quanstrom wrote:
> plan 9, an operating system for people who never change their minds 
> or have new ideas.

(I almost ignored this as a troll)

Just to be explicit:
* The _old_ idea here is *being* able to rename directories.
* The _new_ idea here is *not being* able to rename directories.

Also, I have yet to see anyone explain *why* moving directories around
is such a big win.  All I hear is
"Well, I can do it on this other system ...".

As I said
> > Plan9's ability to present a flexible view of the file system
> > probably obviates most reasons to want to shuffle directories around. 

Cheers,
	Dave.

Re: [9fans] mv vs cp

[Boyd Roberts]

"Thomas Bushnell, BSG" wrote:
> I'm pretty sure you're incorrect.  Can you describe the case in more
> detail?

They spent quite a while in rename hell.

Re: [9fans] mv vs cp

[Douglas A. Gwyn]

Lucio De Re wrote:
> There are really only two social factors overriding here.  People
> like me have grown to expect it, unfortunate as it may be, and the
> alternative is inconsistent and open to error, besides being much
> more time and resource intensive.

We should be careful to distinguish between a utility command,
which usually is best if it works as widely as it can to do a
simply described function (from the user point of view; it might
be complicated to implement), and a fundamental operation in the
protocol itself (I/O primitive).

I think it is reasonable for the 9P200x protocol to have a
Trename request, which of course can fail if the operation is
not possible or makes no sense for the particular object.
Then it is up to the (file) server to make it happen; the
important thing is that the file server need only use local
locks while it shuffles things around (if precached, it could
be serviced as an atomic operation).

There is the question of what permissions should be required
for a rename to succeed: write access on the directory, and/or
on the named object itself?  This may be the same question as
whether the rename ought to be for a handle in the directory
(i.e. Trename is an operation on a directory) or for a handle
on the named object.

I am inclined to think rename ought to work within a directory
but not in general between distinct path prefixes.

Re: [9fans] mv vs cp

[Lucio De Re]

On Mon, Oct 08, 2001 at 09:50:27AM +0000, Douglas A. Gwyn wrote:
> 
> We should be careful to distinguish between a utility command,
> which usually is best if it works as widely as it can to do a
> simply described function (from the user point of view; it might
> be complicated to implement), and a fundamental operation in the
> protocol itself (I/O primitive).
> 
With the principle of least surprise applying here.  Mv copying only
one layer of files is in breach of it, in my opinion.

> I think it is reasonable for the 9P200x protocol to have a
> Trename request, which of course can fail if the operation is
> not possible or makes no sense for the particular object.
> Then it is up to the (file) server to make it happen; the
> important thing is that the file server need only use local
> locks while it shuffles things around (if precached, it could
> be serviced as an atomic operation).
> 
I think there's growing agreement on this score.  I certainly feel
it's justified.  But Jim's reservations about race conditions have to
be taken into account.  Alexander seems to think BSD did it wrong (did
Linux improve on that?) but didn't suggest it can't be done.

> There is the question of what permissions should be required
> for a rename to succeed: write access on the directory, and/or
> on the named object itself?  This may be the same question as
> whether the rename ought to be for a handle in the directory
> (i.e. Trename is an operation on a directory) or for a handle
> on the named object.
> 
These are rules, they need to be established and documented (and make
sense, of course).  But that's about it, really.

> I am inclined to think rename ought to work within a directory
> but not in general between distinct path prefixes.

My choice would be the point where copying the data becomes necessary.
Whatever operation doesn't need to relocate the actual file contents,
ought to succeed.  But I can't say I understand all the subtleties
involved.

++L

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

jmk@plan9.bell-labs.com writes:

> As Dave points out, there are a lot of balls in the air during
> an atomic 'rename'. 4.2BSD introduced the 'rename' system call,
> and as an alpha/beta tester for 4.1[abc] and 4.2BSD I can testify
> to how long it took to get it right and how much ugly code was
> involved.

Color me confused, but isn't it a jillion times harder to get it right
in user space?

[9fans] rewriting paths [was: mv vs cp]

[Richard Uhtenwoldt]

I was thinking about this in the bathtub just now.  One could interpose
a filesystem between the user and kfs --or wherever one's files are
really stored-- called renamefs, which rewrites paths before forwarding
them to kfs.  9P requests do not really contain paths, but you get the
idea: the new file server, renamefs, maintains a rewrite table
containing the paths specified by past move commands (2 paths per move
command to be precise).  This state is used to rewrite certain 9P
requests (eg, some walk requests) before relaying them to the 
server that really stores files.

To increase the usefulness of renamefs, we allow it to store 2 types of
records.  Specifically, a record can take the form

  D<path>

, which means that the string <path> "no longer lives here"
(ie, renamefs will act as if <path> does not exist), or it can
take the form

  A<path><path2>

, which means that <path2> will get rewritten as <path> and does not
carry the implication that <path> no longer lives here.  (Yes, yes, I
know: between <path> and <path2> you need some lexeme that does not
occur in paths.)

Then,

  Mv <path> <path2> 

can be implemented by adding two records, A<path><path2> and D<path>, and
something resembling Unix's

  Ln -s <path> <path2>

is implementable by adding one record, A<path><path2>, to the rewrite
table inside renamefs.  The main socioeconomic purpose of these features
is to make Unix users feel more at home by providing means to move
directories, means to do inter-directory moves and symlinks.  Moreover,

  Del <path>

which just adds D<path> to the rewrite table, is a delete that supports
undelete (via removal of the D record).  And resource forks can be
implemented via ... --Just kidding.

No need to modify 9P of course: just have renamefs listen on a specific
file like /foo/rename where foo might be mnt (sorry for my unfamiliarity
with Plan9 file naming conventions) and have mv write requests
(candidates already in the form of strings for entry into the rewrite
table) to /foo/rename (rather than having mv send rename or copy and
delete requests like it does now).

When everyone is sleeping, or when the user says so, renamefs can empty
the rewrite table by actually copying and deleting files in the
underlying filesystem.  Call this operation "update".

There are multiple ways I'm sure to create pathological situations with
renamefs, and I do not know enough about Plan 9 to address them, except
to point out that one way to recover from pathology --assuming the
update operation has not run yet-- is simply to delete the rewrite table
via, eg, echo clear >>/foo/rename or, if the namespace is so screwed up
that that impossible, to reboot without mounting renamefs.

Advantages of my design:

Users who do not need the functionality do not pay any cost: the code
for renamefs and it's clients (eg, the new mv command) lie dormant on
the hard drive where they cannot cause problems.  No modification
of extant code is required.

Makes Plan 9 look more like Unix for those who want want that sort
of thing, and yes I hear loud and clear that many here do not.

Re: [9fans] Sam question

[nigel]

OK, so 8 space tabs, ridiculously long variable names, unnecessary
nesting, hungarian notation, and insuffcient use of subfunctions
blows the 80 column limit too quickly.

So use more columns! When did you last use a VT100?

As for clarity, a consistent style is all that is required. Within bounds, it
doesn't matter so much what the style is. The assistance it gives in
reading other people's code is immense.

Programmers should be flexible enough to communicate in the local
dialect whether it be OTB, or something widly different.

Re: [9fans] Sam question

[Steve Kilbane]

Nigel:

> As for clarity, a consistent style is all that is required. Within bounds, it
> doesn't matter so much what the style is. The assistance it gives in
> reading other people's code is immense.
> 
> Programmers should be flexible enough to communicate in the local
> dialect whether it be OTB, or something widly different.

Exactly my point. Put any two programmers together, and they'll find
*something* they can disagree on, for layout. It's a holy war issue that'll
never be completely solved, so why worry? Get them to write better code,
instead.

steve

Re: [9fans] Sam question

[Luis Fernandes]

>>>>> "steve" == Steve Kilbane <steve@whitecrow.demon.co.uk> writes:

    steve> Exactly my point. Put any two programmers together, and
    steve> they'll find *something* they can disagree on, for
    steve> layout. It's a holy war issue that'll never be completely
    steve> solved, so why worry?

Well, what if there was an editor that re-displayed the code (braces,
tabs, everything) in the exact manner you preferred, regradless of
it's structure in the actual file? Then everyone could have their
very own One True Brace Style and One True Tab Setting.  Wouldn't
that put an end to the holy wars?

I once proposed this idea to Barry Warsaw, the author of C-mode for
Emacs, and IIRC he said it wasn't worth the effort.

Re: [9fans] Sam question

[Boyd Roberts]

> I once proposed this idea to Barry Warsaw, the author of C-mode for
> Emacs, and IIRC he said it wasn't worth the effort.

sounds like a good call and from an emacs head too -- amazing.

Re: [9fans] Sam question

[Boyd Roberts]

> As for clarity, a consistent style is all that is required. Within bounds, it
> doesn't matter so much what the style is. The assistance it gives in
> reading other people's code is immense.

very necessary when hacking the 7th ed's shell's shellgol.

Re: [9fans] Sam question

[Lucio De Re]

On Sat, Aug 18, 2001 at 08:38:31AM +0100, nigel@9fs.org wrote:
> 
> So use more columns! When did you last use a VT100?
> 
All the time, in emulation at least :-(

Encouraging wider lines has the drawback that my ceiling may
well be your floor.  So how do we communicate?

As Boyd aptly pointed out, readability should come very high in
the priorities.  I'll even accept "continue", "break", "return"
and "exit()" as compromises for the sake of readability.  I
_do_ draw the line at "goto".

++L

Re: [9fans] Sam question

[Boyd Roberts]

From: "Lucio De Re" <lucio@proxima.alt.za>
> I _do_ draw the line at "goto".

well it's a toolkit.  sometimes you have to use 'goto' for clarity,
much as i am loathed to.  usually a:

    for (;;)
    {
        for (;;)
        {
            ...

            if (forbid(c))
                goto break2;

            ...
        }
    }

break2:

the problem being that at the end of the first loop requires
some sort of test (probably the same test as in the second
loop) which will cause code duplication and one day you will
forget to keep both tests in sync.

iirc it should be 'goto fonfon' :)

Re: [9fans] Sam question

[Lucio De Re]

On Sun, Aug 19, 2001 at 12:54:18PM +0200, Boyd Roberts wrote:
> 
> well it's a toolkit.  sometimes you have to use 'goto' for clarity,
> much as i am loathed to.  usually a:
> 
I believe "goto" was retained in C for the benefit of code
generators.

The alternative to "goto" in your instance is actually (almost)
obvious from your explanation ;-)  You need the duplicate test
to check a condition that will not change with changed
circumstances, for example a variable set earlier or a
function.  The redundancy is unavoidable, at the end of a
search you still need to know if you succeeded or failed:

	while (!finished && !found) {
	}
	if (finished) {
	} else { // found!
	}

Sorry to teach you to suck eggs, I'm sure I'm not telling you
anything new :-)  On the other hand, I'd love a language where
the above can be represented elegantly (for some value of
elegantly, and SNOBOL doesn't count :-)

++L

PS: Try/Catch in C++ addresses this out-of-band behaviour, Tcl
uses "uplevel" and all round it does cry out for a clean
solution.  But I think it is quite intractable in linear
languages and the human intellect balks at coding in two
dimensions (or is it two-dimensional what we do and three-
dimensional would be too hard?).

Re: [9fans] Sam question

[Boyd Roberts]

> Sorry to teach you to suck eggs, I'm sure I'm not telling you
> anything new :-)

the trouble is that the mess you are trying to get out of may
be extremely inelegant to test for at the end of the outer loop.

it's usually error cases that screw things up and destroy perfectly
good loops.

Re: [9fans] Sam question

[Lucio De Re]

On Sun, Aug 19, 2001 at 02:02:44PM +0200, Boyd Roberts wrote:
> 
> the trouble is that the mess you are trying to get out of may
> be extremely inelegant to test for at the end of the outer loop.
> 
> it's usually error cases that screw things up and destroy perfectly
> good loops.
> 
Agreed.  And it isn't always feasible to test in advance,
although even when it is, one may inherit a previous pile of
spaghetti.

With errors (I like to think of them as contingencies), one
knows something may go wrong, but not what, only the effects
can be identified (an NFS service is unmounted, or a file is
corrupt, whatever).  The "try/catch" approach makes sense, but
a clean (nevermind elegant) implementations would have to pass
a lot of criticism.  Yet the alternative is the dreaded "goto"
- better the devil you know syndrome?

Hm, the other contributing factor is the lifetime of code.  One
never expects prototyping code to be still running 20 years
later, yet I doubt there's much that is proper
production-quality code out there.  If one profiled code for a
while, the uncertainty in the middle of a loop would eventually
turn into predictable events and the "goto"s could be replaced
with precondition testing.  But who profiles prototypes?

++L

Re: [9fans] Sam question

[Steve Kilbane]

> The "try/catch" approach makes sense, but
> a clean (nevermind elegant) implementations would have to pass
> a lot of criticism.

Except that breaking out of several loops can be normal program
behaviour, rather than an error condition. It's not out-of-bounds,
necessarily.

> Yet the alternative is the dreaded "goto"

Not really. Being able to name loops and exit or continue a
particular nesting loop is a safe middle ground - it just
happens to be missing from C. There's inner-loop-only, and
there's goto-anywhere-in-this-function, which is a shame.

steve

Re: [9fans] Sam question

[Dan Cross]

In article <E15Y0gh-000N2j-0U@anchor-post-30.mail.demon.net> you write:
>OK, so 8 space tabs, ridiculously long variable names, unnecessary
>nesting, hungarian notation, and insuffcient use of subfunctions
>blows the 80 column limit too quickly.
>
>So use more columns! When did you last use a VT100?

Probably six years ago (really!), but I did use a laser printer on
Friday.

One reason the 80 column limit still makes sense is that one can print
the code out with a minimum of hassle (no special pretty printers or
whatever) and it'll be readable enough to review.

>As for clarity, a consistent style is all that is required. Within bounds, it
>doesn't matter so much what the style is. The assistance it gives in
>reading other people's code is immense.

I think it's the, ``within bounds'' part that throws so many people
off.  Things like ``Hungarian notation'' just tend to obscure a program,
and even though my company's coding standards specifically ban it,
the windows programmers put it in anyway.  How terribly frustrating.

I agree that consistency is important, but consistent unreadable garbage
isn't too helpful.

Something I've noticed is that programmers who don't take the time
and care to produce a *readable* program are the ones who write bad
software.  Someone who actually puts some effort into the presentation
is, in my experience, more likely to produce a correct, working and
maintainable program than someone who doesn't.

>Programmers should be flexible enough to communicate in the local
>dialect whether it be OTB, or something widly different.

Sure, as long as the local dialect is reasonable, or should I say
readable?  :-)

	- Dan C.

Re: [9fans] AFS-client for Plan9 - ?

[rog]

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

however, it's worth remembering, that in the Unix i remember at any
rate, _exit() is not always invoked on program exit.  it isn't invoked
if the program dies from a signal, for instance.

i've always presumed that the final close of fds is done when their
refcount drops to zero, i.e.  when the exited process's file table is
cleared up by the kernel.

so the actual _?exit() system calls are not that crucial to the issue
of file closing under AFS. stdio is a different matter, of course.

but i'm not entirely sure whether we're on topic here...  :-)

  cheers,
    rog.


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

To: <cse.psu.edu!9fans>
Subject: Re: [9fans] AFS-client for Plan9 - ?
Date: Mon, 20 Nov 2000 14:24:48 +0100
Message-ID: <009201c052f5$420a2480$0ab9c6d4@cybercable.fr>

From: Douglas A. Gwyn <gwyn@arl.army.mil>

> Boyd Roberts wrote:
> > here we go.  the kernel closes the fd's as a part of exit,
> > like td said.
> 
> Further, upon return from main(), all the exit() actions
> are performed.
> 
> _exit(), on the other hand, does not perform any stdio.
> (Its main use is in a child branch of a fork.)

absolutely correct.

Re: [9fans] AFS-client for Plan9 - ?

[Douglas A. Gwyn]

rog@vitanuova.com wrote:
> however, it's worth remembering, that in the Unix i remember at any
> rate, _exit() is not always invoked on program exit.  it isn't invoked
> if the program dies from a signal, for instance.

Right; upon abnormal termination (what POSIX terms "termination
with actions" as I recall), the application process has lost
control, so only the kernel clean-up actions can be performed
(which include closing open FDs, as others have remarked).

> i've always presumed that the final close of fds is done when their
> refcount drops to zero, i.e.  when the exited process's file table is
> cleared up by the kernel.

It depends on the kernel (there might be process-owned locks to
release, for example), but that's the roght general idea.
Closing a "file" decrements its in-use count and only when that
count goes to zero is the "real" close function performed, e.g.
device driver drops READY etc.

> so the actual _?exit() system calls are not that crucial to the issue
> of file closing under AFS. stdio is a different matter, of course.

Yes, sorry if I digressed.

Re: [9fans] AFS-client for Plan9 - ?

[nigel]

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

Let me explain (and, yes, this is a quote from Fawlty Towers)

Programs which do not explicitly close flies before invoking exit() are
not

1) badly written

or

2) forcing Unix implementations to have to do close on exit to compensate

These are the defined semantics. So the reason is "because that's what
the program quite reasonably expects".

Just in the same way that you don't have to free all memory before
calling exit, unless, as in td's words "they've changed that since I
last looked".  I know "they" did for 16 bit Windows applications, and
it's certainly the case for semaphores in Unix.

> Grr... OK, let me rephrase it:
> 
> 	I really doubt that there is (or ever was) a UNIX variant that
> would not do close-on-exit. Reason: lots and lots of programs that would
> kill such system with file leaks.


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

From: Alexander Viro <viro@math.psu.edu>
To: Tom Duff <td@pixar.com>
Cc: 9fans@cse.psu.edu
Subject: Re: [9fans] AFS-client for Plan9 - ?
Date: Tue, 14 Nov 2000 19:31:13 -0500 (EST)
Message-ID: <Pine.GSO.4.21.0011141923210.5482-100000@weyl.math.psu.edu>



On Tue, 14 Nov 2000, Tom Duff wrote:

> > Precisely. And any kernel that will try _not_ to do that will die under the
> > leaks produced by the $BIGNUM of applications expecting it do act as any
> > sane UNIX should.
> Which UNIX version lacks this behavior?
> (Or are you trying to run UNIX programs
> on some non-UNIX?)

Grr... OK, let me rephrase it:

	I really doubt that there is (or ever was) a UNIX variant that
would not do close-on-exit. Reason: lots and lots of programs that would
kill such system with file leaks.

IOW, "not likely" was about "some numskull changed it" part - such attempt
would backfire immediately. We are in violent agreement...

Re: [9fans] AFS-client for Plan9 - ?

[Alexander Viro]

On Wed, 15 Nov 2000 nigel@9fs.org wrote:

> Let me explain (and, yes, this is a quote from Fawlty Towers)
> 
> Programs which do not explicitly close flies before invoking exit() are
> not
> 
> 1) badly written

Sure.

> or
> 
> 2) forcing Unix implementations to have to do close on exit to compensate

Sure.

> These are the defined semantics. So the reason is "because that's what
> the program quite reasonably expects".
... and so many programs _do_ expect it (quite reasonably) that changing
that behaviour would require the audit and rewrite of the whole userland.

Folks, how about finally agreeing that we agree and stopping that subthread?
It's getting really silly.

Re: [9fans] AFS-client for Plan9 - ?

[David Gordon Hogan]

> > Precisely. And any kernel that will try _not_ to do that will die under the
> > leaks produced by the $BIGNUM of applications expecting it do act as any
> > sane UNIX should.
> Which UNIX version lacks this behavior?
> (Or are you trying to run UNIX programs
> on some non-UNIX?)

The hypothetical one positted earlier in this thread.

Sorry to butt in, but this is just getting riddiculous.

Re: [9fans] AFS-client for Plan9 - ?

[presotto]

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

Andrew can cache whole files locally and send back journaled updates.
It's a lot more than cfs.  This is not a trivial project.  Might be
interesting though.

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

From: anothy@cosym.net
To: 9fans@cse.psu.edu
Subject: Re: [9fans] AFS-client for Plan9 - ?
Date: Mon, 13 Nov 2000 15:19:02 -0500
Message-ID: <20001113201911.6003E199EB@mail.cse.psu.edu>

//Local caching would be great, I think.

okay, let me say off the bat i have no idea how
AFS handles caching, so this comparison may be
totally inapropriate. but for fs caching in
Plan 9 (without 9p↔AFS), take a look at cfs(4)
and the -C option to mount in bind(1).

if your goal is talking to AIX or other Unix
boxes, take a look at u9fs(4).
-α.

Re: [9fans] AFS-client for Plan9 - ?

[Wladimir Mutel]

> Are you volunteering?  I don't know of anyone else writing
> an AFS<->9P converter.

	Oh sorry, I do not feel excessive inspiration and (the worst) spare
	time. I often think I am only able to drop in an idea ...

--
mwg@alkar.net, 399916, 340044, 7442333, 7786458 - Владимир Мутель

Re: [9fans] AFS-client for Plan9 - ?

[presotto]

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

Are you volunteering?  I don't know of anyone else writing
an AFS<->9P converter.

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

From: Wladimir Mutel <mwg@alkar.net>
To: 9fans@cse.psu.edu
Subject: [9fans] AFS-client for Plan9 - ?
Date: Mon, 13 Nov 2000 16:30:52 GMT
Message-ID: <8uoutp$als$1@pandora.alkar.net>

	IBM recently opened their AFS (distributed file system with local
	caching) -
	http://oss.software.ibm.com/developerworks/opensource/afs/

	Could there be any reason or use to make Plan9 AFS-client (like
	afssrv, to connect to afs-servers and map 9p to afs) ?

	Could Plan9 fs(8) get some afs features ? Local caching would be
	great, I think.

--
mwg@alkar.net, 399916, 340044, 7442333, 7786458 - Владимир Мутель

Re: [9fans] AFS-client for Plan9 - ?

[Boyd Roberts]

----- Original Message ----- 
From: <presotto@plan9.bell-labs.com>

> Are you volunteering?  I don't know of anyone else writing
> an AFS<->9P converter.

oooh, protocol conversion.  danger, will robinson.

although, 9P is sane.  whereas, NFS is not.

[9fans] AFS-client for Plan9 - ?

[Wladimir Mutel]

	IBM recently opened their AFS (distributed file system with local
	caching) -
	http://oss.software.ibm.com/developerworks/opensource/afs/

	Could there be any reason or use to make Plan9 AFS-client (like
	afssrv, to connect to afs-servers and map 9p to afs) ?

	Could Plan9 fs(8) get some afs features ? Local caching would be
	great, I think.

--
mwg@alkar.net, 399916, 340044, 7442333, 7786458 - Владимир Мутель

Re: [9fans] /n/smtp

[Russ Cox]

	russ told me that it would serve no purpose, but i
	'counter attacked' :-) importing it off the firewall.
	a free proxy; code running on the the firewall with
	9P/styx gluing it to wherever it's needed.

even after all this discussion,
i still don't think it serves any purpose.
the data only flows in one direction, and
only in one format.  file servers are good
for handling interactive resources or 
resources with complex presentations.
mail delivery is neither.

people have pointed out that it's like 
sendmail -t.  so have upas/marshal -t,
which i agree would be useful.

want to get the service from a firewall?
instead of marshal -t, do rx firewall marshal -t.

to me, it feels a lot more like a good
pipeline piece than a full-blown filesystem.

russ

Re: [9fans] /n/smtp

[Boyd Roberts]

From: Russ Cox <rsc@plan9.bell-labs.com>

> even after all this discussion,
> i still don't think it serves any purpose.

i understand what you're saying.  i just don't agree.

given i smash a template into sam with B and then
hand up 'f /n/postoffice' and with one mouse click
[write] in can send it.

for years i've been using an MH like mail user agent:

   com

   <creates template and then uses B>

   del

   <delivers it>

anyway, a difference of opinion, i can cope with that :-)

Re: [9fans] /n/smtp

[Boyd Roberts]

> given i smash a template into sam with B ...

B is acredited to me for the unix sam, but it wasn't
my idea.  rob saw how i was using sam to send mail
via a mechanism that did a B via some god awful X11
thing.  as soon as he saw that he just said that
sam should have a named pipe for commands, thus B.

the idea was John J. Mackin's:

    http://perso.wanadoo.fr/shand/jjm/index.html

Re: [9fans] /n/smtp

[Scott Schwartz]

> sam should have a named pipe for commands

Speaking of that... the diffs I just posted don't provide it.  Sam wants
to use plumbing now, and having Plan 9 in front of me saps my will to
code approximations for unix.

Re: [9fans] /n/smtp

[Boyd Roberts]

> Speaking of that... the diffs I just posted don't provide it.  Sam wants
> to use plumbing now, and having Plan 9 in front of me saps my will to
> code approximations for unix.

the code is trivial.  50 lines?

i think it's in unix.c.

Re: [9fans] file server problems

[ianb]

>i've not had any trouble with my IDE fileserver,

I thought that fileservers had to be SCSI?

Ian

Re: [9fans] file server problems

[Eric Dorman]

----- Original Message ----- 
From: <ianb@cs.york.ac.uk>
To: <9fans@cse.psu.edu>
Sent: Wednesday, July 12, 2000 2:04 AM
Subject: Re: [9fans] file server problems


> >i've not had any trouble with my IDE fileserver,
> I thought that fileservers had to be SCSI?
> Ian

<chuckle>
'had' is somewhat strong, eh?  it's just a software problem.
i have an interface that allows using IDE drives for
the fileserver.  i have 2 3.5Gb IDEs striped together.

Eric Dorman
edorman@san.rr.com

Re: [9fans] file server problems

[Eric Dorman]

----- Original Message ----- 
From: "Eric Dorman" <edorman@san.rr.com>
To: <9fans@cse.psu.edu>
Sent: Wednesday, July 12, 2000 6:33 PM
Subject: Re: [9fans] file server problems


> > >i've not had any trouble with my IDE fileserver,
> > I thought that fileservers had to be SCSI?
> > Ian
> 
> <chuckle>
> 'had' is somewhat strong, eh?  it's just a software problem.
> i have an interface that allows using IDE drives for
> the fileserver.  i have 2 3.5Gb IDEs striped together.

oh yeah, if you'd like a snapshot of it i can provide it.  i don't
see it getting rolled into the base tree (however that works) but
it might be useful for some people.

--eld

Re: [9fans] file server problems

[Lucio De Re]

On Wed, Jul 12, 2000 at 07:28:13PM -0700, Eric Dorman wrote:
> > 
> > <chuckle>
> > 'had' is somewhat strong, eh?  it's just a software problem.
> > i have an interface that allows using IDE drives for
> > the fileserver.  i have 2 3.5Gb IDEs striped together.
> 
> oh yeah, if you'd like a snapshot of it i can provide it.  i don't
> see it getting rolled into the base tree (however that works) but
> it might be useful for some people.
> 
If Russ has CVS compiled, we may not be far from a public CVS repository
(hint, hint) where we may be able to have a few branches for software
such as your IDE fileserver.

I recall David Butler's extensions to the file server, too, and I was
really hoping to see those in the source tree.

In fact, there is also the issue of externally supporting Alef, although
Limbo may be the better option in this case.  And largely it would be
useful to make available second edition source code which, although
obsolete, may be released either for curiosity's sake or as unsupported
alternatives to newer stuff.

++L

PS: Russ, could I have a copy of the Makefile/mkfile you used to
compile CVS?

Re: [9fans] file server problems

[Scott Schwartz]

> If Russ has CVS compiled, we may not be far from a public CVS repository

We've got a wizzy file server that supports time travel.  Let's use
that instead.

Re: [9fans] file server problems

[Lucio De Re]

On Thu, Jul 13, 2000 at 12:33:11AM -0400, Scott Schwartz wrote:
> 
> > If Russ has CVS compiled, we may not be far from a public CVS repository
> 
> We've got a wizzy file server that supports time travel.  Let's use
> that instead.

The administration is different, and not necessarily to everyone's
comfort.  But I do appreciate the abilities of the Plan 9 file
system, although I must confess that I have never had quite enough
hardware to try it out.

Heck, I can't even figure out how to run NFS, or the CD-ROM jukeboxes
in any sensible manner :-(

++L