Re: [9fans] file server problems

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

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] 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,  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 - ?

[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 - ?

[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.

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.

[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.

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

[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] 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] 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: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

[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]

> 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

[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]

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

[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

[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]

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?

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

[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

[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

[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

[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] 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: 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: [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

[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

[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

[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

[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: 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?

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.

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: [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: 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: [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: 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

[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] 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?)

[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?)

[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?)

[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?)

[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?)

[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.

[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

[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

[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

[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

[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

[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 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 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

[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

[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.  :)

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

[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

[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] 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

[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

[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

[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

[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

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] samuel

[Joel Salomon]

"AMSRL-CI-CN" <gwyn@arl.army.mil> wrote
> One thing you can do is maintain a file of your favorite macros,
> open that in sam when you're editing, and snarf and send as
> needed.

What I actually meant was a macro that looks like [[:cfuncdef foo:]]
(I think that's an existing extension syntax [[:alpha:]] for [a-zA-Z]
)
but is a shorthand for :
foo[[:ccomment:]]*[[:cparenth:]][[:ccomment:]]*.....
meaning: foo, possibly followed by some comments, followed by
parenthesized text, again maybe followed by comments, then an open
brace - all allowing for whitespace.  Of course by this time you'd
just embed perl into your editor and bloat the code size 5000% - oh,
well)

Re: [9fans] samuel

[Ralph Corderoy]

Boyd Roberts <9fans@cse.psu.edu> wrote:
> Harri J Haataja wrote:
> > Sucks? Well, I suppose people are allowed opinions. Vim makes me more
> > efficient every day and there's no end in sight.
> 
> goto fonfon;

Yawn.

Re: [9fans] samuel

[Boyd Roberts]

Harri J Haataja wrote:
> Sucks? Well, I suppose people are allowed opinions. Vim makes me more
> efficient every day and there's no end in sight.

goto fonfon;

Re: [9fans] samuel

[Harri J Haataja]

Escape Clause wrote:
>Lucio De Re wrote:
>> On Wed, Feb 27, 2002 at 06:05:20PM -0500, seanq@plan9.bell-labs.com wrote:
>> 
>>>     SEE ALSO
>>>          sam(1), vi(1)
>>>
>>                     ^^^^^ Huh?!  Surely this needs updating?
>I like vi. Don't need no steeenkeeeng mouse slowing down my typing. But 
>I'll grant its copy & paste does suck a bit.

^V*clicketyclick*^V*yclicketyclick*p
4yy5jP
d2}3{p

Sucks? Well, I suppose people are allowed opinions. Vim makes me more
efficient every day and there's no end in sight.

-- 
YOU CAN'T DO THAT!
	-- Error message from a DG Nova system

Re: [9fans] samuel

[AMSRL-CI-CN]

"Joel Salomon" <joelcsalomon@excite.com> wrote...
> Simple searching with regexps works in sam just fine.  However, I
> would like to see regexp 'macros' or something similar, so I can
> search for (c:ident) instead of /[A-Za-z_][A-Za-z_0-9]*/

One thing you can do is maintain a file of your favorite macros,
open that in sam when you're editing, and snarf and send as
needed.

[9fans] samuel

[Joel Salomon]

Simple searching with regexps works in sam just fine.  However, I
would like to see regexp 'macros' or something similar, so I can
search for (c:ident) instead of /[A-Za-z_][A-Za-z_0-9]*/

Re: [9fans] samuel

[Douglas A. Gwyn]

Laura Creighton wrote:
> Build a better mousetrap, and the bastards who already have
> market share and have locked up the distribution channels
> will continue to dominate the market.

I don't think it's just that; after all, almost anything can be
marketed via Internet nowadays.  A large part of the problem
seems to be in educating (informing) enough consumers to create
a significant demand.  Some have noted that back in the mainframe
days, Burroughs had a nice implementation of virtual memory and
other features, but it wasn't until IBM marketing started pushing
the features that many customers started demanding them.

Re: [9fans] samuel

[Lucio De Re]

On Wed, Mar 13, 2002 at 07:08:18PM +0100, Laura Creighton wrote:
> 
> You can read an exerpt from that book here. 
> http://www.ingenuitygap.com/home.html
> 
Thank you, Laura.

> I don't think its the same sort of book (but all I have read is
> the book chapter exerpt on the site.)  This book appears to be 
> 'Wow, life is complicated, and we don't have the ingenuity to
> deal with the increased complexity', whereas _Fumbling the Future_
> is about 'We just spent a fortune and built a whole new future.
> Too bad the only corporate management person who understood this
> is dead, and we don't know how to talk to suits.'
> 
Hm.  The picture I had of the Ingenuity Gap was more how gullible
individuals are, but I'll try and get to read both.

++L

Re: [9fans] samuel

[Laura Creighton]

Lucio wrote:
On Wed, Mar 13, 2002 at 03:13:40PM +0100, Laura Creighton wrote:
>
> I'm re-reading 'Fumbling the Future' right now.  (thanks Boyd who
> leant it to me.)  It's very sad.
>
>I'm told, in a similar vein, I believe, that The Ingenuity Gap by
>Thomas Homer-Dickson (spelling errors mine) is a good read.  Anyone
>else come across it?


You can read an exerpt from that book here. 
http://www.ingenuitygap.com/home.html

I don't think its the same sort of book (but all I have read is
the book chapter exerpt on the site.)  This book appears to be 
'Wow, life is complicated, and we don't have the ingenuity to
deal with the increased complexity', whereas _Fumbling the Future_
is about 'We just spent a fortune and built a whole new future.
Too bad the only corporate management person who understood this
is dead, and we don't know how to talk to suits.'

Laura

Re: [9fans] samuel

[bwc]

Laura,

It is true that just building a better technology won't, in itself, create
a demand.  It's not the current owner of market share.  True, they won't
help and will go out of their way to protect their space, but the bigger
problem is that just having the better technology, by itself, doesn't
do anyone any good.  The full cycle is
	1) better way,
	2) communication better way to the people who will benefit
	3) provide channel for people who will benefit to purchase
	4) be able to provide better way at an acceptable price
	5) help the people who will benefit learn how to use new way

I'm sure in my haste this morning I'm leaving something out.  (2) and (3)
are functions of marketing, (4) is manufactoring, (5) is marketing and
support.  A lot has to happen, and the ultimate choice is the
people who will potentially benefit.

There are always counter examples, such as monopolies.  But, having
taken on some real big guys and won, (they gave in and bought us), I can
say you can do all this--don't dispare.  It's just a whole lot of work.

  Brantley Coile

BTW, I turned off my prototype PIX firewall last week after over six
years of service.

Re: [9fans] samuel

[Lucio De Re]

On Wed, Mar 13, 2002 at 03:13:40PM +0100, Laura Creighton wrote:
> 
> I'm re-reading 'Fumbling the Future' right now.  (thanks Boyd who
> leant it to me.)  It's very sad.
> 
I'm told, in a similar vein, I believe, that The Ingenuity Gap by
Thomas Homer-Dickson (spelling errors mine) is a good read.  Anyone
else come across it?

++L

Re: [9fans] samuel

[Laura Creighton]

The American Spectator ran an article about 5 years ago which
showed the various 'mouse trap patents' and working mousetraps
(where available) that the US patent office received.  It was
crushing confirmation that the old adage 'build a better 
mousetrap and the world will beat a path to your door' is nonsense.
Lots of people built better mousetraps.  It is not hard to be
better than the mousetrap that has largest market share in the USA.
That one is the metal spring on a small piece of wood, popularised 
by the Saturday Morning Cartoons.

Build a better mousetrap, and the bastards who already have 
market share and have locked up the distribution channels
will continue to dominate the market.  This is the grim reality
that we have proven again and again and again over the last 20 years
in this industry.

I'm re-reading 'Fumbling the Future' right now.  (thanks Boyd who
leant it to me.)  It's very sad.

Laura Creighton

Re: [9fans] samuel

[ozan s. yigit]

Andrew Simmons:

> ... I'd just like some way to find function definitions without
> changing the way I lay them out. grep ^nurdge *.c does have the appeal of
> simplicity, but I don't like adjusting my style to suit the machine.

it is not hard to write an ad-hoc scanner/parser to look for right
sorts of things and capture what you want. i once wrote a tool that
finds anything that looks like a function call in c-like programs.
it knows how to skip comments, and how to collect the arguments
(string or otherwise in multiple lines) after an identifier and an
opening paren, with proper number of closing parens:

csee -e 'draw$' frdelete.c
	..
draw(f->b, Rect(pt0.x, pt0.y, pt0.x+(f->r.max.x-pt1.x), q0), f->b,
nil, pt1)
draw(f->b, Rect(f->r.min.x, q0, f->r.max.x, q0+(q2-q1)), f->b, nil,
Pt(f->r.min.x, q1))

whereas unaided grep 'draw' will only get you

draw(f->b, Rect(pt0.x, pt0.y, pt0.x+(f->r.max.x-pt1.x), q0),
draw(f->b, Rect(f->r.min.x, q0, f->r.max.x, q0+(q2-q1)),

this was handy in finding functions regardless of how they were laid
out
instead of just bits and pieces.

oz
---
computing is cognitively constrained. -- peter roosen-runge

Re: [9fans] samuel

[Thomas Bushnell, BSG]

rob@plan9.bell-labs.com (rob pike) writes:

> The editor I use is the best.  It's the one I use, which helps make it
> the best.  I like it because I use it.  Because I use it, it's wired
> right into my fingertips.  This also helps make it best.  Anyone who
> thinks otherwise is a moron, and therefore not me.  Now can we please
> stop talking about editors?

Except that I didn't say anything about "best" or "moron", or anything
else.  I said, well, something like the above, only with actual
content.

Re: [9fans] samuel

[Thomas Bushnell, BSG]

rsc@plan9.bell-labs.com (Russ Cox) writes:

> Yet you try to turn this thread into an editor war.

No, actually I was saying that I think I can use just about any editor
well, and there are particular idiosyncratic reasons that I prefer
emacs.  Other people have particular idiosyncratic reasons to prefer
other editors, more power to them.

> > Actually, the most important reason I don't use vi is that I use the
> > Dvorak keyboard, and the use of positional keys in vi (hjkl) is a pain
> > when you are using a different key layout.
> 
> Speaking of which, maybe you can clear up some other things.
> What's the One True Byte Order?  Are PCs really better
> than Macintoshes?  Is Linux really better than Windows?
> Is worse really better?

Huh?  I'm a little confused; vi happens to be wedded to a qwerty
keyboard layout, and that's one reason I don't use it anymore.

I'm not sure what that has to do with any of the rest.

Re: [9fans] samuel

[ozan s. yigit]

rsc@plan9.bell-labs.com (Russ Cox) wrote:

> 			For many acme users, the
> cscope-like tool of choice is grep, especially
> since cscope doesn't compile on Plan 9 (it's too tied
> to curses [sic]).

i have occasionally used a small toolkit named id [later gnufied and
forgotten as idutils; a non-gnu version cleaned up by mark moraes is
still around in ftp.cs.utoronto.ca] it requires an identifier database
be built forehand. even though it has many creaky parts, it did have
a few interesting features; numeric identifiers are searched in all
radixes:

	lid 235

0353           sys/src/cmd/dd.c sys/src/cmd/troff/hytab.c
0x00EB         sys/src/cmd/tcs/tcs.c
0xEB           sys/src/boot/pc/x16.h sys/src/9/boot/key.c

since the database contains proper identifiers, lid regular expressions
apply not to lines but to identifiers:

	lid '^xx'

xxxincoff      sys/src/cmd/troff/n3.c
xxxvers        sys/src/ape/cmd/make/ident.c
xxyy           sys/src/cmd/gs/src/gspaint.c

output is path adjusted relative to the id database:

	lid 'xx$'

errxx          ../ape/cmd/expr/expr.y

and so on.

id tools had the idea of having scanners for different languages, but
only C, assembler and text scanners were implemented.

oz
---
www.cs.yorku.ca/~oz      | don't count your chickens in glass houses
york u. computer science | until the cows come home. -- david vestal

Re: [9fans] samuel

[rob pike]

To save us all a little time, here is the Universal Editor Post:

==

The editor I use is the best.  It's the one I use, which helps make it
the best.  I like it because I use it.  Because I use it, it's wired
right into my fingertips.  This also helps make it best.  Anyone who
thinks otherwise is a moron, and therefore not me.  Now can we please
stop talking about editors?

==

-rob

Re: [9fans] samuel

[Russ Cox]

> Emacs is not an editor, it's a comprehensive user interface
> environment.  

And it's also an editor.

[snip religious arguments for emacs the comprehensive,
emacs the all-encompassing, emacs the chameleon.]

> So I find editor wars singularly boring.

Of course they're boring: they perfectly fit Needham's
definition of a religious war -- one in which there is no
content.

Yet you try to turn this thread into an editor war.

> Actually, the most important reason I don't use vi is that I use the
> Dvorak keyboard, and the use of positional keys in vi (hjkl) is a pain
> when you are using a different key layout.

Speaking of which, maybe you can clear up some other things.
What's the One True Byte Order?  Are PCs really better
than Macintoshes?  Is Linux really better than Windows?
Is worse really better?

More religious wars!

Russ

Re: [9fans] samuel

[Thomas Bushnell, BSG]

rsc@plan9.bell-labs.com (Russ Cox) writes:

> I'm impressed.  We're in the middle of a religious war
> over editors and neither emacs nor vi is involved.

Emacs is not an editor, it's a comprehensive user interface
environment.  

That's why it gets such strong emotions: people who think it should
just be an editor, or who dislike the particular UI environment it
gives you, hate it.

People who compare it only against other editors and find it way
better also miss the point, because to be fair, it should be compared
against the whole suite of editor, debugger UI, news reader, mail
client, etc.

I prefer emacs over other user interfaces because

1) I need to move the mouse less
2) The same commands (nearly) work everywhere
3) My brain happens to be well wired for it.

But I once was a perfectly content vi user, and I can use it pretty
darn efficiently too.  I'm sure the same is true for nearly any sane
editor, and insane ones really just aren't in the running.  So I find
editor wars singularly boring.

Actually, the most important reason I don't use vi is that I use the
Dvorak keyboard, and the use of positional keys in vi (hjkl) is a pain
when you are using a different key layout.

Re: [9fans] samuel

[Thomas Bushnell, BSG]

geoff@collyer.net (Geoff Collyer) writes:

> Assigned gotos, COBOL "alter" verbs, writing large programs in
> assembler, self-modifying code, and many other things in this young
> field are bad ideas, but they aren't archaic, even if they are
> wretched mistakes.  Old != bad, and New != good; quality and age are
> largely unrelated, though with luck we learn things with experience.

I think what makes them archaic is that they are now moribund: people
recognize they are mistakes, and they date from the very early days of
the field.  Being bad isn't something automatic with archaic.  But
something still in use isn't archaic; the reason those things aren't
still in use (or shouldn't be ::grin::) is that they are now seen bad.

So not "bad because archaic".  And not really "archaic because bad".
Rather, "archaic" meaning "dating from the earliest days, and not
current now", and it happens that those techniques are no longer
current because they happen to be bad.  A little reflection, however,
will show that being bad is neither a sufficient nor a necessary
condition for a programming technique falling into disuse.  So there
are many archaic things which are not bad (like, say, nine track
magtape) and there are many bad things which are not archaic (like,
say, FORTRAN, which is old but still in use, and perl, which is new).

"Archaic" is relative to the context.  In my usual circles, "archaic"
means "before ancient", where "ancient" refers to something roughly
like 500 BC - 400 AD.  But surely in CS, archaic means "dating back to
the earliest days of computing", and ancient "slightly newer than
archaic".

Borrowing the usual sense from classical studies, might mean that we
should call Babbage and early APL and lambda calculus "archaic", and
we should call things like computed gotos and self-modifying code
"ancient". 

Thomas

Re: [9fans] samuel

[Ralph Corderoy]

Hi Andrew,

> Fair enough. I'd just like some way to find function definitions
> without changing the way I lay them out. grep ^nurdge *.c does have
> the appeal of simplicity, but I don't like adjusting my style to suit
> the machine.

Like you, I too prefer the K&R2 style of function prototypes and find
the argument for /^foo inconsistent otherwise we'd see

    typedef struct {
        ...
    }
    foo;

    bar *
    barlist[NUM_BAR];

since finding a non-function definition can be just as useful.

Cheers,


Ralph.

Re: [9fans] samuel

[Escape Clause]

Lucio De Re wrote:
> On Wed, Feb 27, 2002 at 06:05:20PM -0500, seanq@plan9.bell-labs.com wrote:
> 
>>     SEE ALSO
>>          sam(1), vi(1)
>>
>                     ^^^^^ Huh?!  Surely this needs updating?
> 
> ++L
> 

I like vi. Don't need no steeenkeeeng mouse slowing down my typing. But 
I'll grant its copy & paste does suck a bit.

Re: [9fans] samuel

[Bengt Kleberg]

> Delivered-To: 9fans@cse.psu.edu
> From: presotto@plan9.bell-labs.com
> To: 9fans@cse.psu.edu

> to find functions.  The most important part of the declaration
> for me is the function name.  The rest is a description of what
> that name represents which I can find pretty easily once I find the
> function in my visual field.

this sounds logical, and will hopefully help to put limbo in front of c
when it comes to language usage.


bengt

Re: [9fans] samuel

[Geoff Collyer]

Sorry, that's an American-ism; Fahrenheit.

Re: [9fans] samuel

[Russ Cox]

I'm impressed.  We're in the middle of a religious war
over editors and neither emacs nor vi is involved.

As was pointed out earlier, it's trivial to use cscope-like
tools quite naturally with acme.  The same was not true
of sam when samuel got written; now that sam has
plumbing it might fit better, but it still pales in
comparison to acme.  For many acme users, the
cscope-like tool of choice is grep, especially
since cscope doesn't compile on Plan 9 (it's too tied
to curses [sic]).

If you really care, give acme+grep or acme+cscope
a try before you knock it -- acme's great strength
is how well it integrates external commands.

AFAICT, rob is the only person who has tried both
samuel and acme+grep and expressed an opinion.
Thus far, consensus among the informed seems to
be unanimous: acme+grep beats samuel.

Re: [9fans] samuel

[Andrew Simmons]

>i sometimes think that the silliness that gets established (syntax
colouring) ...
>
Not to defend syntax colouring in general, but I've grown rather fond of
the way the rest of a file turns green after I type /*

Re: [9fans] samuel

[Geoff Collyer]

sam provides more than a GUI; the other face of its user interface is
a command language in which composition from simpler commands provides
considerable power.

I wasn't aware that Limbo existed in the '70s; can you cite a
reference?  One could argue that Java is merely Limbo done badly and
with lots of complex yet unhelpful class libraries piled on.  And who
cares if we're using languages and tools from the '70s?  The good ones
survive.  Or are we just not hep enough?  Following fashion has never
interested me.

> 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.

This is a stunning statement.  If we prefer systems that haven't been
dumbed-down, we're horrible elitist scum.  Given the plentiful supply
of stupidity on this planet, I'll take the systems that require an IQ
above room temperature to understand and use.  There are lots of other
existing systems for the bottom half of the IQ curve to use.

Re: [9fans] samuel

[Geoff Collyer]

Assigned gotos, COBOL "alter" verbs, writing large programs in
assembler, self-modifying code, and many other things in this young
field are bad ideas, but they aren't archaic, even if they are
wretched mistakes.  Old != bad, and New != good; quality and age are
largely unrelated, though with luck we learn things with experience.

Re: [9fans] samuel

[forsyth]

>>(i know, i know, i could use something that
>>puts the function names in chartreuse.)

which isn't to say i think that putting everything in Courier
for ever and ever is right too.    i sometimes think that the
silliness that gets established (syntax colouring) tends to divert
people from more interesting applications of available technology.

Re: [9fans] samuel

[forsyth]

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

actually, quite apart from the understandable desire to
have improvements in the programming environment,
i have to say that given C's syntax, i still find
	static int
	burble(stuff)
	{
easier to spot at a glance than
	static int burble(stuff)
	{
even when the aim is not to grep for things, but perhaps
that's just me.  i thought lcc was
a good program, but i found it harder to read for that reason.
(i know, i know, i could use something that
puts the function names in chartreuse.)


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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] samuel
Date: Mon, 11 Mar 2002 10:13:49 +1300
Message-ID: <3.0.6.32.20020311101349.00998010@pop3.clear.net.nz>

>Samuel didn't make the grade.  If it had, I think it would still be
>around.
>
Fair enough. I'd just like some way to find function definitions without
changing the way I lay them out. grep ^nurdge *.c does have the appeal of
simplicity, but I don't like adjusting my style to suit the machine.

Re: [9fans] samuel

[Steve Kilbane]

> If, however, they find that style
> ugly and distracting (and maybe I'm the only one who does) but do it
> anyway, because it allows then to find the function definition using grep,
> then maybe the tail has started to wag the dog a little, and it's time to
> consider extending the toolkit?

I think it goes both ways. The advantage of formatting source this way is
that it works with a large subset of tools, rather than just one that's
been extended. It's a simple convention with a significant benefit.
I don't see it as being any different from having the compiler output
error messages in a form which can be processed by acme button-clicks.

steve

Re: [9fans] samuel

[presotto]

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

Actually, I started using the style before I started using grep
to find functions.  The most important part of the declaration
for me is the function name.  The rest is a description of what
that name represents which I can find pretty easily once I find the
function in my visual field.  Anything that hides it from me,
I find distracting.  The big difference for me when I started coding on
plan 9 was putting the formal parameters on the same line as the
function name.  I used to separate them onto subesequent lines,
one per line with comments.  However, I bent to local practice
on that.

However, if you don't like it, I see no reason why you should do
it.  I automaticly reformat other people's code to meet my
particular nuances before I try to understand it, especially
if it's rather complex.

I'm not quite sure why anyone is railing against samuel; if
samuel helps some people manage code a bit better, use it.
I prefer the plumber to do similar things since it's not
oriented to a single editor.

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

From: Andrew Simmons <andrew@mbmnz.co.nz>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] samuel
Date: Mon, 11 Mar 2002 09:17:07 +1300
Message-ID: <3.0.6.32.20020311091707.00998010@pop3.clear.net.nz>

>
>Dinosaurs didn't have grep.
>
They do now.

Sorry, that was really cheap, but I do think Alex has a point. It ties in
with a query I made re coding layout. If people lay out function
definitions with the return type on a separate line because they find it
makes them easier to read, then fine. If, however, they find that style
ugly and distracting (and maybe I'm the only one who does) but do it
anyway, because it allows then to find the function definition using grep,
then maybe the tail has started to wag the dog a little, and it's time to
consider extending the toolkit?

Re: [9fans] samuel

[William Josephson]

On Mon, Mar 11, 2002 at 10:13:49AM +1300, Andrew Simmons wrote:
> >Samuel didn't make the grade.  If it had, I think it would still be
> >around.
> >
> Fair enough. I'd just like some way to find function definitions without
> changing the way I lay them out. grep ^nurdge *.c does have the appeal of
> simplicity, but I don't like adjusting my style to suit the machine.

To each his own: I find the style easier on the eyes :-/

Re: [9fans] samuel

[Andrew Simmons]

>Samuel didn't make the grade.  If it had, I think it would still be
>around.
>
Fair enough. I'd just like some way to find function definitions without
changing the way I lay them out. grep ^nurdge *.c does have the appeal of
simplicity, but I don't like adjusting my style to suit the machine.

Re: [9fans] samuel

[rob pike]

> maybe the tail has started to wag the dog a little, and it's time to
> consider extending the toolkit?

Yesterday it was claimed that those who hadn't tried samuel shouldn't
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.

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.

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

-rob

Re: [9fans] samuel

[Andrew Simmons]

>
>Dinosaurs didn't have grep.
>
They do now.

Sorry, that was really cheap, but I do think Alex has a point. It ties in
with a query I made re coding layout. If people lay out function
definitions with the return type on a separate line because they find it
makes them easier to read, then fine. If, however, they find that style
ugly and distracting (and maybe I'm the only one who does) but do it
anyway, because it allows then to find the function definition using grep,
then maybe the tail has started to wag the dog a little, and it's time to
consider extending the toolkit?

Re: [9fans] samuel

[Andrew Simmons]

>How anything in the field can be considered archaic is beyond me.

Not even the assigned goto statement?

[9fans] samuel

[rob pike]

> If you haven't used it, then I suggest you try it before making
> grandiose philosophical remarks about the purity of little tools
> combined with archaic regular expression munging.  You sound like
> dinosaurs.

Dinosaurs didn't have grep.

-rob

Re: [9fans] samuel

[geoff]

> If you haven't used it, then I suggest you try it before making
> grandiose philosophical remarks about the purity of little tools
> combined with archaic regular expression munging.  You sound like
> dinosaurs.

``In computer science, we stand on each other's feet.'''  - Brian Reid

The modern field of computing (using stored-program electronic digital
computers) is just over 50 years old.  How anything in the field can
be considered archaic is beyond me.  If we're dinosaurs for using
something as relatively recent as regular expression searches, what
hope is there for building on the work of others?

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

[9fans] samuel

[Alex Danilo]

Most of the discussion here shows no-one ever used samuel.

Most of you are confusing samuel with 'samx'.

'samx' was a bunch of hacks to give auto-indent and other awful
features to sam.

'samuel' does not change the behaviour of 'sam' at all - it just adds
more menu items which give you access to cscope.  When the samuel
features aren't in use, you just get an extra menu entry called 'browser'.
(There was an interface to a C interpreter too, but I could never get
any sense out of it).

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

But if you do use it, you get the nice facility that you can do stuff
like 'search for calls to <function>'.  This builds a cascading menu
that can be looked at, and you can see which file/function/line the
function call is in.  Yes, this can all be done with grep, etc, but
that approach is clumsy by comparison, unless you are stubbornly
bent on intellectual masturbation.  The single fastest way to navigate
a huge unknown codebase is samuel.

If you haven't used it, then I suggest you try it before making
grandiose philosophical remarks about the purity of little tools
combined with archaic regular expression munging.  You sound like
dinosaurs.

Anyway, the one glitch with samuel was that it was done on the old
ASCII sam, and was never integrated with the utf version in Plan
9 or the one Rob released for UNIX, so you're stuffed anyway.

Alex

Re: [9fans] samuel

[Jim Kelleman]

Mr. Puttress (John) was my supervisor until he retired
this past summer.  If you're interested in the code,
send mail to me privately and I'll give you his home email address.

jim


rob pike wrote:
> 
> > Yes please, release it. I'd love to try samuel.
> 
> I have no idea where the code is.  It was done by a Mr. Puttress,
> who was working for Ted Kowalski at the time.  I don't know where
> those people are any more, but they might be at AT&T.
> 
> I looked around the Lucent and AT&T sites with no luck.  The code
> has never been part of our tree, as far as I know.
> 
> -rob

Re: [9fans] samuel

[Boyd Roberts]

Lucio De Re wrote:
> >           sam(1), vi(1)
>                     ^^^^^ Huh?!  Surely this needs updating?

I'm pretty sure this comes from as far back at the 9th Ed manual.

Re: [9fans] samuel

[Boyd Roberts]

seanq@plan9.bell-labs.com wrote:
> 
>      EMACS(1)                                                 EMACS(1)

Yes, remember it well.

Re: [9fans] samuel

[Lucio De Re]

On Wed, Feb 27, 2002 at 06:05:20PM -0500, seanq@plan9.bell-labs.com wrote:
> 
>      SEE ALSO
>           sam(1), vi(1)
                    ^^^^^ Huh?!  Surely this needs updating?

++L

Re: [9fans] samuel

[William Josephson]

On Wed, Feb 27, 2002 at 06:05:20PM -0500, seanq@plan9.bell-labs.com wrote:
>      EMACS(1)                                                 EMACS(1)

Damn.  You beat me to it.

Re: [9fans] samuel

[seanq]

     EMACS(1)                                                 EMACS(1)

     NAME
          emacs - editor macros

     SYNOPSIS
          emacs [ options ]

     DESCRIPTION
          This page intentionally left blank.

     SOURCE
          MIT

     SEE ALSO
          sam(1), vi(1)

     BUGS
          Yes.

     Page 1                       Plan 9             (printed 2/27/02)

Re: [9fans] samuel

[skipt]

At 02:17 PM 2/27/2002 +0100, Boyd Roberts wrote:
>I'd like to teach it about python, much as I hate syntax directed
>editors, but I want to be able to get to classes without typing.

(Allow me to mount my high and mighty horse...)

try man emacs

Re: [9fans] samuel

[forsyth]

>This was the 10th Ed version of sam that understood C/C++ (written

samuel UNDERSTOOD C++?  respect!

Re: [9fans] samuel

[Boyd Roberts]

forsyth@caldo.demon.co.uk wrote:
> samuel UNDERSTOOD C++?  respect!

This would have been 1989, before C++ got into its terminal stage.

Re: [9fans] samuel

[Fco.J.Ballesteros]

It's funny how acme can also be used to do that kind of stuff,
without knowing a bit about C. 
With a few scripts, you generate prototypes from functions,
locate struct definitions and the like. 

Re: [9fans] samuel

[rob pike]

> In any case, what did exactly samuel with its knowledge of
> the C syntax to help editing? Something like the C mode used
> in Emacs? 

It kept a database on the side to make it easy to look up declarations
and that sort of thing.  The database needed to be updated whenever
you changed the program.

-rob

Re: [9fans] samuel

[Fco.J.Ballesteros]

In any case, what did exactly samuel with its knowledge of
the C syntax to help editing? Something like the C mode used
in Emacs? 

Re: [9fans] samuel

[rob pike]

> Yes please, release it. I'd love to try samuel. 

I have no idea where the code is.  It was done by a Mr. Puttress,
who was working for Ted Kowalski at the time.  I don't know where
those people are any more, but they might be at AT&T.

I looked around the Lucent and AT&T sites with no luck.  The code
has never been part of our tree, as far as I know.

-rob

Re: [9fans] samuel

[Fco.J.Ballesteros]

Yes please, release it. I'd love to try samuel. 

[9fans] samuel

[Boyd Roberts]

This was the 10th Ed version of sam that understood C/C++ (written
by Tom Cargill/Killian?).  Can we get the source released?

I'd like to teach it about python, much as I hate syntax directed
editors, but I want to be able to get to classes without typing.