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] Rant (was Re: Plan9 and Ada95?)

[Boyd Roberts]

It's just not the machine code for windows, it's the DLLs, the ghastly
run-time environment etc.  It is far from a trivial problem.

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

[Thomas Bushnell, BSG]

Andrew Simmons <andrew.simmons@xtra.co.nz> writes:

> It is surely neither polite nor accurate to describe mr pike as stamping his
> foot and saying it isn't fair. I take him to have been expressing a sense of
> frustration and sadness with the doctrinaire and ungenerous attitude of the
> free software ultras. I mean, here you are able to obtain at no cost a
> fascinating and elegant operating system (although admittedly the omission
> of the "-v" flag from "cat" is odd), complete with source code and some of
> the best-written documentation around, and instead of thanking Lucent and
> the Plan 9 team for their astonishing generosity, you complain because the
> system does not satisfy your arcane definition of "free".

Except cost has *nothing to do with it*.  Whether it's hugely
expensive or they pay you to run it (negative cost), it's not relevant
to the definition I was using.  Whether the source is generally
visible is not relevant.  What is relevant is whether people have
certain freedoms.  If Lucent doesn't want people to have those
freedoms, then lots and lots of people aren't going to have interest
in hacking on it.  And why should they?  To improve Lucent's bottom
line?  To enable Lucent to steal software from other people by
ignoring the licenses on it?

I'm sorry that Rob feels miffed; he probably did the level best he
could.

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

[Thomas Bushnell, BSG]

presotto@closedmind.org writes:

> I wouldn't put GCC at the other end of the spectrum; SUIF owns
> that extremity.

There's no doubt that GCC is not the best C compiler in the world.
But (when user -O), the tradeoffs in GCC are always towards making the
optimizer better at the expense of perhaps taking more compile time.

The non-optimized version is entirely subsidiary; the goal there is to
use parts of the "real" compiler in order to go as fast as possible.
A compiler optimized for fast translation would surely do better.

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

[Thomas Bushnell, BSG]

cross@math.psu.edu (Dan Cross) writes:

> I should note here that we tried switching to gcc, but because the
> stupid C++ ABI is so vastly different from compiler to compiler, it
> didn't work with our ODBC libraries.

Yeah, chalk this up to the horrors of C++...  sigh.  It is truly a
disaster that a language has so caught on for which there is no
general ABI around--not even a fairly straightfoward obvious one.

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

[martin.m.dowie]

"David Gordon Hogan" <dhog@plan9.bell-labs.com> wrote in message
news:20011109221155.BD850199B9@mail.cse.psu.edu...
> > There is the Ada Web Server, which should be trivial to get working on
> > Plan9 once we have an Ada compiler which will target the Plan9 platform.
>
> Yeah, the headlines could read:
>
> Plan 9 Targetted By Military

lol   :-)

....if slightly old fashioned viewpoint - today's Ada users include
the likes of Canal+ (interactive TV systems) to Mondex (electronic
cash systems) to Reuters (news agency).

and with the advent of the GNAT compiler a whole bunch of home
enthusiasts! :-)

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

[Andrew Simmons]

<RANT>
It is surely neither polite nor accurate to describe mr pike as stamping his
foot and saying it isn't fair. I take him to have been expressing a sense of
frustration and sadness with the doctrinaire and ungenerous attitude of the
free software ultras. I mean, here you are able to obtain at no cost a
fascinating and elegant operating system (although admittedly the omission
of the "-v" flag from "cat" is odd), complete with source code and some of
the best-written documentation around, and instead of thanking Lucent and
the Plan 9 team for their astonishing generosity, you complain because the
system does not satisfy your arcane definition of "free".

I would however mildly disagree with mr pike in his choice of the splits in
the Christian churches as the most apt comparison with the free software
community. To my mind, a better parallel is with the various Judaean
liberation groups in "Monty Python's Life of Brian". The similarity between
the odium heaped on "splitters" by the Judaean People's Liberation Front (or
was it the People's Front for the Liberation of Judaea?), and the odium
heaped on "forkers" by the various free software factions is uncanny.
</RANT>

>
> And the people who might work on Plan 9 but don't, because they are
> committed to free software, are committed to the libre definition, not
> the gratis one.  Stamping your foot and saying it isn't fair won't
> change that.

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

[Thomas Bushnell, BSG]

forsyth@vitanuova.com writes:

> by `if gnat is structured so as to allow another ... in principle',
> i meant, it has some internal representation of the Ada program that
> is at or near a useful level for code generation, before it produces RTL.
> if it is producing RTL directly from a basic parse tree,
> you'll have your work cut out.

Yes, that's true.  Most GCC front ends (and I'm sure gnat is the same
here) produce nice parse trees and generate code from those.  The
generation of the parse tree is, in principle, not tightly coupled
with anything to do with code generation.

However, the parse trees are usually partial (for example, the idea of
parsing a whole C file at once died a long time ago), and there may be
a lot of niggling little dependencies, since nobody's bothered to try
and separate the parts out that way.

Some people have tried to take the bison parser description files from
GCC and use them for other purposes as well, with varying degrees of
success.

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

[Dan Cross]

In article <15342.13829.659344.232543@nanonic.hilbert.space> you write:
>If the compiler generates fast code, you can always recompile the compiler
>and it will run faster :-).

Yes, but if you believe Proebsting, it'll take 18 years for it to be
twice as fast.  :-)

	- Dan C.

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

[Dan Cross]

In article <200111111120.LAA10681@localhost.localdomain> you write:
>...which you weren't doing. On a more general note, "faster compiler"
>fits in with "faster processor", "bigger disk" and "more memory" as
>excuses for "can't be bothered to design properly." Of course, "compiler
>generates faster/smaller code" also supports it.

True.  Hence the paradoxical result that our code wasn't really any
better for the pain of having to work that way.  You'd think that since
we had to do all this garbage to get it to build correctly, people
would have invested more time in getting things right the first time.
But they didn't.

I think that's a general result of people `growing up' in environments
where development revolves around a edit/compile/test/repeat cycle, but
leaving those environments before they've fully matured.  (Sorry for
the age/maturity metaphor.)  While that model is extremely powerful in
the hands of those with some experience and education in its proper
use, in the wrong hands, it can be disasterous, leading to the, ``just
hack it until it works'' syndrome.

Or maybe the problem was that at said company, doing a build was a good
excuse for going off and doing something else for 45 minutes....

	- Dan C.

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

[presotto]

There is a trade off between the efficiency of the code and
the speed of the compiler.  Ken went for the latter with
some concessions to the former.  It made sense for us since
we spend most of our time writing code and are somewhat sensitive
to the speed of building.  It also makes it possible to build for
all architectures everytime without really worrying about the time
it takes.  Since we still regularly use multiple architectures,
'mk installall' is the thing I type most whenever I've changed
code.

I wouldn't put GCC at the other end of the spectrum; SUIF owns
that extremity.

However, this shouldn't be held up as a reason for not producing
compilers with better code generation.  There's plenty of room
in the Plan 9 world for a better/more feature rich compiler.
Perhaps dhog will massage GCC enough to make it fill that space.
More likely something else will come along.

The only thing I ask is that the code that comes out correctly
reflects the C that went in.  The rest, to a lesser or greater
extent, is just icing on the cake.

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

[Steve Kilbane]

Dan C:

> ...Or if you have to work on a large C++ project where the compilation
> process, running on a quad processor Sun Ultra Enterprise 450 with 4GB
> of RAM, takes 45 minutes.  And the boneheads working on the project
> have screwed up the build structure so totally that to compile an
> incremental change requires building the entire source, then compile
> time becomes very significant.


<boyd>
But if you're using C++, and you've screwed up the build structure,
then you get what you deserve. No point blaming the speed of the compiler
for those problems...
</boyd>

...which you weren't doing. On a more general note, "faster compiler"
fits in with "faster processor", "bigger disk" and "more memory" as
excuses for "can't be bothered to design properly." Of course, "compiler
generates faster/smaller code" also supports it.

steve

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

[paurea]

Steve Kilbane writes:
 > From: Steve Kilbane <steve@whitecrow.demon.co.uk>
 > Subject: Re: [9fans] Rant (was Re: Plan9 and Ada95?)
 > Date: Sun, 11 Nov 2001 01:38:59 +0000
 >
 > In terms of compilation speed versus compiled-code speed, the bias
 > is usually to the latter, 9fans notwithstanding. This is usually
 > the case: extra time spent during the coding phase (whether designing
 > or compiling) pays off in reduced time every time the application is
 > used.

If the compiler generates fast code, you can always recompile the compiler
and it will run faster :-).

--
                 Saludos,
                         Gorka

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

[Dan Cross]

In article <200111110138.BAA02696@localhost.localdomain> you write:
>But then, this ranking comes from a commercial compiler market, where
>the customer doesn't see anything but the finished product. If you're
>in an environment where you have cause to recompile the entire OS and
>surrounding applications four times a day, I can see how (5) might work
>its way up the list.

...Or if you have to work on a large C++ project where the compilation
process, running on a quad processor Sun Ultra Enterprise 450 with 4GB
of RAM, takes 45 minutes.  And the boneheads working on the project
have screwed up the build structure so totally that to compile an
incremental change requires building the entire source, then compile
time becomes very significant.

I should note here that we tried switching to gcc, but because the
stupid C++ ABI is so vastly different from compiler to compiler, it
didn't work with our ODBC libraries.

Testing on that project was a massive pain.  One would have thought
that that would have made the software have some slightly higher
quality, but oddly enough it didn't.

The really funny thing was that the solution would have been to ditch
C++ in favor of a `scripting' language like python, but management
nixed that idea.  Oh well....

	- Dan C.

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

[Steve Kilbane]

In terms of compilation speed versus compiled-code speed, the bias
is usually to the latter, 9fans notwithstanding. This is usually
the case: extra time spent during the coding phase (whether designing
or compiling) pays off in reduced time every time the application is
used.

If I had to rank the attributes of a compiler, I'd say:

1. Correctness.
2a. Speed of compiled code
2b. Size of compiled code
4. Usefulness of debugging
5. Speed of compilation process.

(2a and 2b vary in order, depending on particular circumstances)

But then, this ranking comes from a commercial compiler market, where
the customer doesn't see anything but the finished product. If you're
in an environment where you have cause to recompile the entire OS and
surrounding applications four times a day, I can see how (5) might work
its way up the list.

As a side-note: the "I don't care about run-time speed if I can run it
soon" approach is one of the reasons why Perl is popular.

steve

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

[forsyth]

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

so does lcc, if you're looking for something off Plan 9 that's small,
cleanly written, and portable.  you'll still need to sort out
the assembly and linking phases though.

there, you see: it needn't run on plan 9 for
some of us to like it, it must only be well done.


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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] Rant (was Re: Plan9 and Ada95?)
Date: Fri, 9 Nov 2001 17:26:24 -0500
Message-ID: <20011109222628.9842219A60@mail.cse.psu.edu>

> There's been a lot of noise about how GCC might be more ugly, or
> poorly constructed, or such.

Translation: some people here have opinions that differ from yours.

> I'm asking whether amidst all that noise
> anyone has bothered to see whether it actually performs its job better
> or worse.  It does seem to me to be an important question in
> evaluating tools which one is actually better at the principal job the
> tool is designed to perform.

GCC is painfully slow.  I really don't care if it produces an executable
that's 5% faster, if you're working in a compile-execute-debug-rewrite
cycle, you want that compile step to complete in a reasonable time.
Plan 9's compiler beats GCC hands down on this one.

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

[Andrey A Mirtchovski]

On Sat, 10 Nov 2001, Matthew Hannigan wrote:

>
> dhog says
> > cycle, you want that compile step to complete in a reasonable time.
> > Plan 9's compiler beats GCC hands down on this one.
>
> numbers?  don't disblieve you, but by how much does it beat it?
> even rought estimates would be nice
>

enough!

p9 compilers are twice as fast as gcc compiling code on same hardware...

gcc code is 5% faster than p9 compiled code on same hardware when it comes
to rendering povray images.


andrey

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

[Matthew Hannigan]

dhog says
> cycle, you want that compile step to complete in a reasonable time.
> Plan 9's compiler beats GCC hands down on this one.

numbers?  don't disblieve you, but by how much does it beat it?
even rought estimates would be nice

William Josephson wrote:
> True, although my biggest pet peeve with GCC
> is that it generates bogus code for the Alpha
> and mips.

i thought this was fixed the alpha in recent versions
(2.96 and above)
just in time for the alphas demise!

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

[William Josephson]

On Fri, Nov 09, 2001 at 05:26:24PM -0500, David Gordon Hogan wrote:
> > I'm asking whether amidst all that noise
> > anyone has bothered to see whether it actually performs its job better
> > or worse.  It does seem to me to be an important question in
> > evaluating tools which one is actually better at the principal job the
> > tool is designed to perform.
>
> GCC is painfully slow.  I really don't care if it produces an executable
> that's 5% faster, if you're working in a compile-execute-debug-rewrite
> cycle, you want that compile step to complete in a reasonable time.
> Plan 9's compiler beats GCC hands down on this one.

True, although my biggest pet peeve with GCC
is that it generates bogus code for the Alpha
and mips.

  -WJ

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

[David Gordon Hogan]

> If you take Nt and XP, and remove the last and first letters of
> those names (respectively), you end up with NP.  Hmm, coincidence?
> I think not.

I keep telling everybody that XP is Chi-Rho, but nobody listens...

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

[David Gordon Hogan]

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

And the result is so free, it's largely Design Unencumbered.  <ducks>

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

[David Gordon Hogan]

> Let's get off the hobbyhorse of criticising all the alternative
> platforms and actually co-operate with them or show that the Plan
> 9 way is as superior as we make it out to be.

Let's write some code.

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

[David Gordon Hogan]

> There's been a lot of noise about how GCC might be more ugly, or
> poorly constructed, or such.

Translation: some people here have opinions that differ from yours.

> I'm asking whether amidst all that noise
> anyone has bothered to see whether it actually performs its job better
> or worse.  It does seem to me to be an important question in
> evaluating tools which one is actually better at the principal job the
> tool is designed to perform.

GCC is painfully slow.  I really don't care if it produces an executable
that's 5% faster, if you're working in a compile-execute-debug-rewrite
cycle, you want that compile step to complete in a reasonable time.
Plan 9's compiler beats GCC hands down on this one.

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

[David Gordon Hogan]

> There is the Ada Web Server, which should be trivial to get working on
> Plan9 once we have an Ada compiler which will target the Plan9 platform.

Yeah, the headlines could read:

	Plan 9 Targetted By Military

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

[Boyd Roberts]

> ... like mozilla, it carries the leaden weight
> of history around inside it.

Mozilla is a horrible thing.  I've seen how it calls WinSock -- ick.

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

[Boyd Roberts]

> true. but i don't see that as a bad thing. what _would_ be bad would
> 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 :)...

Dude:  Yeah man, it really tied the room together -

...

Walter:  Forget it, Donny.  You're out of your element.

:)

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

[Dan Cross]

In article <20011109074116.B19B219A4D@mail.cse.psu.edu> you write:
>You think Windows runs in polynomial time?

No.  That was the point of the joke.

	- Dan C.

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

[Caffienator]

In article <24569.1005289364@apnic.net>, "George Michaelson"
<ggm@apnic.net> wrote:

> Apache is a bad idea because like mozilla, it carries the leaden weight
> of history around inside it.
>
> It has code inside to do threading. This is presumably irrelevant on
> plan9.
>
> It has code to pre-fork children. ditto.
>
> It has code to work around Microsoft .DLL strangeness.
>
> It has its own shared-library runtime load code.
>
> It has backwards compatibility code for NCSA httpd.
>
> If you want it because it has HTTP 1.1 conformant implementation, or an
> interesting model of how to represent a file directory as web, thats
> surely better done discretely?
>
> If you want a service which understands apache .htaccess formatted data,
> that too is surely better written another way? I can understand wanting
> to un-tar a tree of web, including .htaccess, even parse an httpd.conf
> but to port the daemon..
>
> 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

There is the Ada Web Server, which should be trivial to get working on
Plan9 once we have an Ada compiler which will target the Plan9 platform.

You can find it at http://www.adapower.com

Implementing Java through Ada is a piece of cake as well, via JGNAT.

Laters.

Caffienator
chris@dont.spam.me

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

[forsyth]

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

sometimes the plan 9 compilers do things that gcc doesn't, partly
because adherence to an often elaborate ABI isn't required.  certainly
that's true on the PowerPC and i think it's also true on the ARM. i'd
say from inspection of gcc and experience of 5?  that the 5l linker
for ARM has an easier time sorting out literal pools and ARM/Thumb
linkage than the gcc system, partly because it's working with an
abstract object program as input, not the encoded instruction forms.
we can then convert the resulting executable into a form that other
systems like.


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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] Rant (was Re: Plan9 and Ada95?)
Date: Fri, 9 Nov 2001 07:43:52 -0600 (CST)
Message-ID: <Pine.GSO.4.10.10111090740440.8629-100000@ultra5a.usask.ca>

plan9's compilers generate code with comparably equal performance to gcc
2.9.5

no, the code is not faster, no, the code is not noticeably slower for jobs
that do not require 5 days to complete (image rendering is what I have
tested -- povray on identical hardware).

that much I can say.

andrey

On Fri, 9 Nov 2001, Thomas Bushnell, BSG wrote:

> nigel@9fs.org writes:
>
> > >> Has anyone compared the efficiency of the code produced by GCC and the
> > >> Plan 9 compiler?
> >
> > I'm not sure that this is a very important issue, whichever is better.
>
> There's been a lot of noise about how GCC might be more ugly, or
> poorly constructed, or such.  I'm asking whether amidst all that noise
> anyone has bothered to see whether it actually performs its job better
> or worse.  It does seem to me to be an important question in
> evaluating tools which one is actually better at the principal job the
> tool is designed to perform.
>

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

[forsyth]

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

sorry, i wasn't clear.  i meant that you'd need to change the gnat code generator
to generate a different representation, not that you'd need another
code generator working from the RTL.  as you say, gcc's RTL
is machine-specific.

by `if gnat is structured so as to allow another ... in principle',
i meant, it has some internal representation of the Ada program that
is at or near a useful level for code generation, before it produces RTL.
if it is producing RTL directly from a basic parse tree,
you'll have your work cut out.

i don't remember dewar's description of gnat's structure,
except that it converts its internal representation of Ada
to RTL at some point, so i don't know the answer
and i can't be much more specific without looking
at Gnat's code (which i've also seen but forgotten as regards this point).
it was a good five years ago and i was curious
rather than interested.


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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] Rant (was Re: Plan9 and Ada95?)
Date: Fri, 9 Nov 2001 10:17:07 GMT
Message-ID: <874ro5vz8b.fsf@becket.becket.net>

forsyth@vitanuova.com writes:

> the gnat code generator doesn't generate code
> directly (or it didn't), it generates the gcc internal representation,
> so it's a non-trivial modification, even if gnat is structured
> so as to allow another code generator in principle.

The "gcc internal representation" (RTL) is not something a different
code generator could work with.  The definition of "valid RTL" is
entirely machine-specific and so forth.  When a GCC front-end begins
writing RTL, it is tightly coupled with the back-end.  (Indeed, it
generates RTL mostly by asking the back-end to spit out RTL for
various operations.)

The value of RTL in GCC is not to firmly decouple the front end from
the back end, but rather to decouple optimizations from the back end.

Thomas

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

[Andrey A Mirtchovski]

plan9's compilers generate code with comparably equal performance to gcc
2.9.5

no, the code is not faster, no, the code is not noticeably slower for jobs
that do not require 5 days to complete (image rendering is what I have
tested -- povray on identical hardware).

that much I can say.

andrey

On Fri, 9 Nov 2001, Thomas Bushnell, BSG wrote:

> nigel@9fs.org writes:
>
> > >> Has anyone compared the efficiency of the code produced by GCC and the
> > >> Plan 9 compiler?
> >
> > I'm not sure that this is a very important issue, whichever is better.
>
> There's been a lot of noise about how GCC might be more ugly, or
> poorly constructed, or such.  I'm asking whether amidst all that noise
> anyone has bothered to see whether it actually performs its job better
> or worse.  It does seem to me to be an important question in
> evaluating tools which one is actually better at the principal job the
> tool is designed to perform.
>

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

[Thomas Bushnell, BSG]

forsyth@vitanuova.com writes:

> the gnat code generator doesn't generate code
> directly (or it didn't), it generates the gcc internal representation,
> so it's a non-trivial modification, even if gnat is structured
> so as to allow another code generator in principle.

The "gcc internal representation" (RTL) is not something a different
code generator could work with.  The definition of "valid RTL" is
entirely machine-specific and so forth.  When a GCC front-end begins
writing RTL, it is tightly coupled with the back-end.  (Indeed, it
generates RTL mostly by asking the back-end to spit out RTL for
various operations.)

The value of RTL in GCC is not to firmly decouple the front end from
the back end, but rather to decouple optimizations from the back end.

Thomas

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

[Thomas Bushnell, BSG]

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

> > But it's not free software...
>
> Yes it is.  It really is.  When I see people say this, which I do from time
> to time, it makes me sad for many reasons.  The parallel with religions,
> with the Catholic schism, with the fissiparous history of the Protestant
> church, is so obvious it's almost embarrassing to point out.  But I must.
>
> The `free' software people have won, but they're so intent on having
> everyone agree with their fundamentalist and faith-based definition
> of `free' that they label many of their allies as enemies.  It's painful to
> watch.  It hurts.

The people that are committed to free software are committed to
software that comes with liberties and rights.  I'll gladly pay for a
copy of something as nice as Plan 9.  But I won't sacrifice my
freedoms for it.

And the people who might work on Plan 9 but don't, because they are
committed to free software, are committed to the libre definition, not
the gratis one.  Stamping your foot and saying it isn't fair won't
change that.

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

[Thomas Bushnell, BSG]

nigel@9fs.org writes:

> >> Has anyone compared the efficiency of the code produced by GCC and the
> >> Plan 9 compiler?
>
> I'm not sure that this is a very important issue, whichever is better.

There's been a lot of noise about how GCC might be more ugly, or
poorly constructed, or such.  I'm asking whether amidst all that noise
anyone has bothered to see whether it actually performs its job better
or worse.  It does seem to me to be an important question in
evaluating tools which one is actually better at the principal job the
tool is designed to perform.

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

[Taj Khattra]

On Thu, Nov 08, 2001 at 07:30:39AM -0500, bwc@borf.com wrote:
>
> What do these economics say about optimizing compilers?
>

here's a link to proebsting's "law" of compiler optimization

	http://research.microsoft.com/~toddpro/papers/law.htm

and some related observations

	http://www.cs.virginia.edu/~jks6b/on_proebstings_law.pdf
	http://www.cs.umd.edu/~pugh/IsCodeOptimizationRelevant.pdf

-taj

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

[Russ Cox]

You think Windows runs in polynomial time?

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

[George Michaelson]

Apache is a bad idea because like mozilla, it carries the leaden weight
of history around inside it.

It has code inside to do threading. This is presumably irrelevant on plan9.

It has code to pre-fork children. ditto.

It has code to work around Microsoft .DLL strangeness.

It has its own shared-library runtime load code.

It has backwards compatibility code for NCSA httpd.

If you want it because it has HTTP 1.1 conformant implementation, or
an interesting model of how to represent a file directory as web, thats
surely better done discretely?

If you want a service which understands apache .htaccess formatted data,
that too is surely better written another way? I can understand wanting
to un-tar a tree of web, including .htaccess, even parse an httpd.conf
but to port the daemon..

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

[Steve Kilbane]

Going back slightly, anothy said:

> // ...suggesting that Mozilla be ported to Plan 9.
>
> this is the same discussion as apache, i think.

..with which I'd disagree. A server doesn't fall into the same
category as a program with a GUI (or even a UI), because its
externally-discernable behaviour is far more clearly defined;
in this case, it's defined within a domain - TCP - that Plan 9
supports.

Putting it another way, interoperating with other programs/systems
is a different class of problem from interacting with users used
to those systems.

steve

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

[Dan Cross]

In article <20011108015655.1AA94199E7@mail.cse.psu.edu> you write:
>What means 'NP', sorry I'm comming from another planet. :-)

P = NP?

Polynomial versus Non-deterministic Polynomial; in other words,
does the algorithm run in a *deterministic* amount of time?  From
theoretical computer science.

	- Dan C.

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

[Noah Diewald]

On Thu, Nov 08, 2001 at 12:58:07PM +0000, Matt wrote:
> If the world has got time for transparent menus and java applets then
> it can suffer not unrolling every loop and using registers when
> possible.

I've implemented a transparent menu in this email.  See below.

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

[Matthew Hannigan]

It would be interesting to see ?c
ranked here: http://www.bagley.org/~doug/shootout/

Very interesting site.


"Thomas Bushnell, BSG" wrote:
>
> Has anyone compared the efficiency of the code produced by GCC and the
> Plan 9 compiler?

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

[anothy]

// Well, let's see if we can agree: XML, GCC, X, C++, JAVA, Perl, off
// the cuff, have all drawn criticism on this list.

true. but i don't see that as a bad thing. what _would_ be bad would
be if Plan 9 did _not_ recieve criticism on this list, or if such criticism
was not listened to or addressed. i believe it is. all these things - your
list and Plan 9 - have problems, and we can only correct them by
addressing them.

// None of the criticism has addressed the social need, as you so
// eloquently explain in your example, to support these entities in
// some fashion or provide alternatives,

i'm not sure that's true. i agree there hasn't been much, if any, talk
about how to support XML or X. but there's been talk of and work on
importing GCC (thus C++) and Perl. further, note your own trailing
clause: "or provide alternatives." so we don't have X, and nobody's
working on getting it. why? because we've got an alternative we like
better, and nobody's shown reason to like X better. there's been a
little talk of getting Java going, but not much, because i think most
people who'd be interested in what it offers on this list consider us
to have an alternative we prefer: Limbo.

i think maybe there's a missing catagory in the discussion here:
interoperability tools. VNC is a great example, i think. what VNC
does for graphics is most definatly _not_ the Plan 9 graphics
model, but it's a very useful tool for talking to a diverse range of
systems. and we've got a vnc viewer. i think that suggests we (as a
community) do look at things from other places, and make the
cost/gain decision i keep harping on. there _are_ things of value
that come from other places, but getting them running locally has
some cost associated with it. each case is a seperate decision.

that being said, not everyone has to come to the _same_ conclusion
when such decisions are made. don't think the correct call was made
in ignoring a local X server? maybe you're right (i still consider that);
go do it. think a Java VM would give you things better than Inferno?
cool, import or build one. think Perl, or Python, or Ada is a good
development language/tool? wonderful, we eagerly anticipate your
results. i really think we do.

i don't think anyone'd be "mad" at you for importing X, or GCC, or
whatever. people might suggest it wasn't the best use of your time,
but that's their decision to make. luckily, you get to determine what
you do with your time, not they.

maybe we do get overly critical from time to time. maybe we do get
too set in our ways. but i still hold that to be the exception here, not
the rule. and i think we do okay at avoiding it.
ア

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

[forsyth]

>>Is there anything in GNAT
>>that exclusively requires GCC? Can those issues be dealt with via a
>>little select modification of the GNAT sources?

the gnat code generator doesn't generate code
directly (or it didn't), it generates the gcc internal representation,
so it's a non-trivial modification, even if gnat is structured
so as to allow another code generator in principle.

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

[forsyth]

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

if it's that superior(!), perhaps it doesn't think much of your laptop.


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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] Rant (was Re: Plan9 and Ada95?)
Date: Thu, 8 Nov 2001 10:39:32 GMT
Message-ID: <87n11xyaar.fsf@becket.becket.net>

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

> Let's get off the hobbyhorse of criticising all the alternative
> platforms and actually co-operate with them or show that the Plan
> 9 way is as superior as we make it out to be.

And hey, if it's that superior, it would run on my laptop, right? :)

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

[presotto]

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

The lack of a browser pretty much makes it useless
for most peoples' laptops.

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

From: "Thomas Bushnell, BSG" <tb+usenet@becket.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Rant (was Re: Plan9 and Ada95?)
Date: Thu, 8 Nov 2001 10:39:32 GMT
Message-ID: <87n11xyaar.fsf@becket.becket.net>

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

> Let's get off the hobbyhorse of criticising all the alternative
> platforms and actually co-operate with them or show that the Plan
> 9 way is as superior as we make it out to be.

And hey, if it's that superior, it would run on my laptop, right? :)

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

[rob pike]

> But it's not free software...

Yes it is.  It really is.  When I see people say this, which I do from time
to time, it makes me sad for many reasons.  The parallel with religions,
with the Catholic schism, with the fissiparous history of the Protestant
church, is so obvious it's almost embarrassing to point out.  But I must.

The `free' software people have won, but they're so intent on having
everyone agree with their fundamentalist and faith-based definition
of `free' that they label many of their allies as enemies.  It's painful to
watch.  It hurts.

-rob

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

[bwc]

> Has anyone compared the efficiency of the code produced by GCC and the
> Plan 9 compiler?

I recently re-read Jim Gray's paper `The 5-minute Rule.'  It's interesting
to note that when he wrote the paper (1985) a meg of memory was $5K and a MIP
was $50K.  Now, by my calulations, a meg is about $0.50 and a mip is about
$0.30.

The economics of CS used to be:
	1) correctness of programs
	2) time efficiency
	3) space efficiency

Considering the changes in speed and memory, I assert that for all but
the most demanding case, only 1) is still a limited resource.

What do these economics say about optimizing compilers?

  Brantley Coile

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

[nigel]

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

>> Has anyone compared the efficiency of the code produced by GCC and the
>> Plan 9 compiler?

I'm not sure that this is a very important issue, whichever is better.

If the Plan 9 C compiler produced better code, would that immediately
causes the free-nix community to change compiler? Of course not, there
are many considerations other than efficiency.

The answer is that gcc is probably/possibly/allegedly more efficient,
but not by a substantial degree.

So, lets say the code is X% faster, and even X% smaller.  How does
this help?  If the code you want to run is within X% of catastrophe,
then squeezing the code with the aid of a compiler is not the only
solution.  Throwing away a lot of the code is quite a good one too.

And, before I get flamed that this is not a commercially minded
answer, a substantial part of my employ has been spent building small
embedded systems.  When the code didn't fit, we invariably played with
the compiler, decided it didn't help enough, and then started removing
code.

What value of X makes changing compiler worthwhile?


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

From: "Thomas Bushnell, BSG" <tb+usenet@becket.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Rant (was Re: Plan9 and Ada95?)
Date: Thu, 8 Nov 2001 10:39:58 GMT
Message-ID: <87g07pya0g.fsf@becket.becket.net>


Has anyone compared the efficiency of the code produced by GCC and the
Plan 9 compiler?

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

[Thomas Bushnell, BSG]

Has anyone compared the efficiency of the code produced by GCC and the
Plan 9 compiler?

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

[Thomas Bushnell, BSG]

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

> Let's get off the hobbyhorse of criticising all the alternative
> platforms and actually co-operate with them or show that the Plan
> 9 way is as superior as we make it out to be.

And hey, if it's that superior, it would run on my laptop, right? :)

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

[Caffienator]

In article <20011107192058.2C84D199E7@mail.cse.psu.edu>, "forsyth"
<forsyth@caldo.demon.co.uk> wrote:

>>>Let's get off the hobbyhorse of criticising all the alternative
>>>platforms and actually co-operate with them or show that the Plan 9 way
>>>is as superior as we make it out to be.
>
> you're possibly overlooking the possibility that some of us have written
> things such as portable compilers (and other things) ourselves for a
> good few other systems, and take that into account when making
> comparisons -- it's not
> just that this or that isn't Plan 9.


I certainly didnt intend to start a flamewar with my post.

Right now, I develop for Linux. Primarily because it's the simplest to
use in regards to the development tools that are available. Sure, I could
figure out how to jerry rig alot of those tools into Plan9, but I just
dont have the time(for now) to do that sort of thing.
I've been running Plan9 across a few local workstations, just to play
around with it. It has alot of potential, and I would really like to
develop for it, but the tools available on Plan9 are somewhat limited.

With that being said, I do plan on developing some of my own tools and
making them available to the Plan9 community, but the big ones, like an
Ada compiler, just might be a little too much for me to bite off at this
point.

Now, Plan9 does have it's own C compiler. I dont suppose it would be
impossible to integrate GNAT on top of that? Is there anything in GNAT
that exclusively requires GCC? Can those issues be dealt with via a
little select modification of the GNAT sources?

Thoughts?

Caffienator
chris@dont.spam.me

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

[Christopher Nielsen]

On Thu, Nov 08, 2001 at 10:05:38AM +0200, Lucio De Re wrote:

[snip]
> A CVS repository could be a start, but without the participation of
[snip]

CVS has a lot of problems. If you're thinking of creating a
source repo, take a look at subversion:

http://subversion.tigris.org/

It's not quite ready yet, but it should be in a couple months,
and it's far superior to CVS.

As nifty as the dump fs is, there are some things it doesn't
provide that a large development team needs in the software
development process. Of course, maybe the idea is to rethink
the development process.

My thought is that something like subversion that utilizes
the ideas of plan9 would be a powerful and useful development
tool.

--
Christopher Nielsen - Metal-wielding pyro techie
cnielsen@pobox.com
"Those who are willing to trade freedom for security deserve
 neither freedom nor security." --Benjamin Franklin

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

[Lucio De Re]

On Thu, Nov 08, 2001 at 03:51:47AM -0500, Russ Cox wrote:
>
> > of the core entity.  A CVS repository could be a start, but without
>
> I'd be a lot happier using CVS if it didn't require
> having droppings scattered all over my directory trees.
>
> </unhelpful>

Sorry, really don't know how to help that :-)  Maybe you can bind all
the CVS directories from a single, parallel namespace? :-) :-) :-)

++L

PS: what I meant by "CVS repository" was a well maintained public
repository.  What keeps it in shape is of little relevance.  Only
two things are important: it must encourage contributions and it
must draw healthy discussion.

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

[Russ Cox]

> of the core entity.  A CVS repository could be a start, but without

I'd be a lot happier using CVS if it didn't require
having droppings scattered all over my directory trees.

</unhelpful>

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

[Lucio De Re]

On Thu, Nov 08, 2001 at 01:45:51AM -0500, anothy@cosym.net wrote:
>
> i don't think this is so, but i'm not sure it's what you intended to
> say, either. elsewhere you seem to argue that it takes a large
> community of developers to produce _lots_ of _different_type_ of good,
> solid products. and i'd agree with that.
>
That's where the _noise_ comes in.  We could wish for an elite of
really cool programmers, of the caliber we're familiar with, but
without Bell Labs' selection criteria, we have to allow natural
selection to perform the discrimination.

> i guess i just don't see the "party line" bit. maybe it's there, but i
> don't see it. i find this to be a much more open forum than most others
> i've spent time in, computer-related or not.
> ?

Well, let's see if we can agree: XML, GCC, X, C++, JAVA, Perl, off
the cuff, have all drawn criticism on this list.  None of the
criticism has addressed the social need, as you so eloquently
explain in your example, to support these entities in some fashion
or provide alternatives, even if only as opening moves towards
superior replacements.

Maybe I expect too much, but I'd like to see the type of comment
that encourages the developer to consider alternatives and eventually
produces them, even if somewhere in the quest for acceptance some
principles have to be compromised.o

For example, C++ is too unwieldy to implement efficiently, but a
few features, such as extensions to structs, operator overloading
might be worth adding to the C compiler for the benefit of compiling
existing code, on the assumption that only some C++ extensions have
really gained popularity.  Purists will frown on such suggestions,
and their opinion should be noted, but not necessarily followed.

I could get myself excommunicated from here by listing all the
heresies I have considered, the above is just a sample.  My feeling
is that one needs a place where heresies are vented in public, draw
appropriate criticism and what valid essence they have becomes part
of the core entity.  A CVS repository could be a start, but without
the participation of the Plan 9 team (which incidentally would
mirror, magnified, Linus Torvald's role in the Linux kernel) it
would soon deteriorate to bulk for the sake of publication.  Maybe
I'm just dreaming, because something along these lines ought to
develop of its own accord, but my fear is that criticism of "foreign"
products discourages such contributions.

++L

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

[anothy]

// I have never used plan 9's httpd, but from the features list it seem
// very good.  Certainly can't fault it from the client's perspective.

i can't say i recomend it. apache was a reasonable example; it really
_might_ make sense to port it (i don't think so, but it might). i
certainly believe something more robust than what we've got now would be
very usefull.

// ...suggesting that Mozilla be ported to Plan 9.

this is the same discussion as apache, i think. there are features that
we want: good html rendering, good javascript support, good set of
plugins (where good in those three cases, unfortunatly, really should be
read as "what web developers expect"). this is very hard to do. but so
is porting Mozilla (i looked at it. breifly). someone interested in
exerting effort to get these features needs to decide where to spend her
effort. a cost/gain decision.

// ...it takes a large community of developers to produce (amongst the
// noise) good, solid products.

i don't think this is so, but i'm not sure it's what you intended to
say, either. elsewhere you seem to argue that it takes a large
community of developers to produce _lots_ of _different_type_ of good,
solid products. and i'd agree with that.

there is a balance to be struck between the usefulness of importing
foreign code and the danger of doing so - diluting the system's
benefits, turning it into "just another unix". as such, i'm still not
sure what i think of the GCC port. GCC is ugly and awful. but it can
give me things that i want. like helping me get rid of the one
remaining Solaris box i run, when i can build the two things we use
it for that're in c++ on Plan 9. then i can get the web developer
who writes code for those two bits to be writing code on Plan 9, and
i have a chance at migrating him to better things.

i guess i just don't see the "party line" bit. maybe it's there, but i
don't see it. i find this to be a much more open forum than most others
i've spent time in, computer-related or not.
ア

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

[okamoto]

What means 'NP', sorry I'm comming from another planet. :-)

Kenji

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

[Dan Cross]

In article <20011107185604.2664B199F3@mail.cse.psu.edu> you write:
>I don't know about Nt/XP yet, but I'm guessing that they'll
>be harder.

If you take Nt and XP, and remove the last and first letters of
those names (respectively), you end up with NP.  Hmm, coincidence?
I think not.

	- Dan C.

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

[Lucio De Re]

On Wed, Nov 07, 2001 at 07:58:32PM +0000, forsyth@caldo.demon.co.uk wrote:
>
> >>And the fact that at the present value of our currency, the Inferno
> >>sources (I presume I need that licence to help develop the Inferno
> >>tools) would cost me one month's income :-(
>
> no, that bit is free.  i always intended it to be but it didn't end up
> on the web site until recently for some reason.

Thank you, that is very encouraging.  I'd love to contribute to
Vita Nuova's revenues, I really think you deserve it, but we're on
an economic downwards spiral here, with no end to it in sight.  It
isn't even clear what the causes for it could be.

++L

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

[Lucio De Re]

On Wed, Nov 07, 2001 at 07:25:32PM +0000, forsyth@caldo.demon.co.uk wrote:
>
> >>Let's get off the hobbyhorse of criticising all the alternative
> >>platforms and actually co-operate with them or show that the Plan
> >>9 way is as superior as we make it out to be.
>
> you're possibly overlooking the possibility that some of us have
> written things such as portable compilers (and other things)
> ourselves for a good few other systems, and take that into account
> when making comparisons -- it's not
> just that this or that isn't Plan 9.

My point isn't in the achievements, one would have to be very blind
or inexperienced to fault the contributions made by the Plan 9 team
(in its broadest sense).

On the other hand, continuous criticism (it's an attitude that's
been bothering me for years now) of everything beyond the boundaries
of Plan 9/Inferno, no matter how justified, isn't healthy.

Whether it's GCC, USB, X or Emacs, nobody needs to be reminded that
they suck in some fashion or other.  What we all need are replacement
tools that provide equivalent value with all the advantages of the
Plan 9 platform.  And even more importantly, one needs the platform
to support the user base.  Take my bread-and-butter client:  they
run their computer system under SCO Unix (too shy of Solaris, but
they need multiprocessing power for the COBOL application they are
continually developing) and most of the users are effectively data
capture clerks with terminal emulators on their desks.

The cheapest terminal today is a Win'9x workstation, specially if
e-mail, a web browser, a word processor and a spreadsheet are
complementary, productivity enhancing tools.  They needn't be, but
if the perception is they are, one may as well learn to live with
it.  Then there's compatibility with Word and Excel that is more
critical than the compatibility of the terminal emulator - there's
some control in making the COBOL program not push the terminal
emulator too far, the same cannot be said of e-mail messages and the
spread of office documents.

I could go further, but I'm sure the scenario is familiar enough.
We'd all love to put Plan 9 terminals on these desks, reduce the
cost of onwership, support, need to upgrade etc. by one or two
orders of magnitudes.  But this isn't possible, clearly.  Next
best, coordinate the Win'9x workstation using SAMBA to provide file
services (mostly for backup and information exchange) rather than
the more expensive, more difficult to administer NT.  Can we use
Plan 9 there?  No, again.  More's the pity.

We can learn lessons from Plan 9, centralise file services and
authentication, set up roaming profiles, minimise hardware differences,
lots of hints from the Plan 9 philosophy, but the real thing runs
exclusively on my desk and then mostly in the guise of VNCviewer
(I also use Charon as the browser, wherever I can).

So the reality is that Plan 9 _is_ the superior platform, but there
isn't the appeal in it that draws the software developers to produce
applications that users actually want.  Why is this so?  Because
the bridges to the more popular development platforms are not being
built.  Much as I was horrified that dhog was prepared to port GCC
3.0 to Plan 9 (I was, honestly), it would open a door; Perl would
open another, Python a third, Apache a fourth, etc.  One can improve
on each of these, replace them with more suitable implementations,
later.

So let's not spend our efforts knocking what's familiar, let's
encourage it and then improve it.  There's plenty of effort in
that.

OK, I'd better shut up now, I know this is a boring subject, sorry
to have let off steam at everyone's expense.

++L

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

[forsyth]

>>And the fact that at the present value of our currency, the Inferno
>>sources (I presume I need that licence to help develop the Inferno
>>tools) would cost me one month's income :-(

no, that bit is free.  i always intended it to be but it didn't end up
on the web site until recently for some reason.

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

[Lucio De Re]

On Wed, Nov 07, 2001 at 01:56:02PM -0500, David Gordon Hogan wrote:
>
> No, it's a symptom of ``I wasted weeks of my life struggling
> with this awful code''.
>
Which I'm sure it is.  But a lot of effort has gone into it, and even
though they may not be giants, the GCC developers are hard working
people with good intentions and a legacy that cannot summarily be
discarded.

> > In the meantime, if I want to cross-develop for Windows or Linux,
> > or any other established platforms, Plan 9 is just no use to me,
> > while GCC and its offspring are.  I know what my choice would be,
> > but it's no choice, is it?  Oh, I forget the Inferno tools, those
>
> GCC (Cygnus) is useless for Windows.  There's no way to link
> a VXD!  So if you're doing any _serious_ development, are you
> going to use two compilers, just so you can have the dubious
> pleasure of using GCC?  I don't think so.
>
Unless I'm much mistaken, there's been a flurry of activity in that
direction (I'm afraid I'm only a very superficial follower of the
binutils efforts, I could not follow the GCC mailing list too, it
would be wasted on me) and I got the impression that good results were
obtained.

> I'm sorry to be so ascerbic here, but I am sick of hearing people
> defending GCC.
>
Surely it is more the case that people attack GCC?  It doesn't need
defending, it is by far the most common Unix language compiler, unless
I'm missing something.  I'm frightened to bits of what will happen
when it grows too large to be manageable, but the army of ants that
are still holding it together deserve admiration, not insults.

GCC is like a very large city.  None of it makes sense, but its
citizens cannot escape from it.  Nor can a more logical, more user
friendly version be built to replace it, it will just not succeed.
Think Brazilia.

> Why don't you help us improve the Inferno tools instead of
> complaining about them?
>
Huh?  Quite the contrary, the only flaw I found in the Inferno tools
was that I totally forgot about them - maybe because when I tried to
use them, they complained about a missing rcmain.  As soon as I can
figure out how to use them, I'll be only too pleased to do so.
Specially that old favourite of mine, the rc shell, which I presume is
what rcsh.exe is (lack of documentation, while excusable, is a bit of
a problem).

And the fact that at the present value of our currency, the Inferno
sources (I presume I need that licence to help develop the Inferno
tools) would cost me one month's income :-(

> You want suggestions?  We could force all those GNU people to read
> Rob's essay on programming style, for starters.
>
I guess software bloat is like being overweight is like late software
projects: one bit at the time.  Adn by the time you take stock the
effort involved in undoing the damage may be far too much.

> I have a cunning plan to use 8c to generate files that will
> run under Windows 9x/Me.  Stay tuned...
>
And MS-DOS?  I still use Zortech C to produce .COM files - shouldn't
be exactly a tall order.  CYGWIN isn't quite as slick, but it's
more consistent with what I find familiar.  Sorry, didn't meant to
be tangential, please let me know as you progress, I think the idea
is excellent.

Now that I think about it, of course 8c is already being used for
that, I just need to figure out how.

> Yes, you'll have to use MS compilers for the VXD and EXE
> that get the show started, but that's it.  Unlike GCC, the
> pleasure of using 8c is real.
>
> I don't know about Nt/XP yet, but I'm guessing that they'll
> be harder.

I wouldn't touch 9x/Me if Nt/2000/XP (I'm guessing at the last two,
I'm time-warped with NT4.0SP6a) is available.  Too flimsy.  NT at
least stays up when a task fails, with the MS-DOS based OSes I can't
resist rebooting whenever something falls over.

++L

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

[forsyth]

>>Let's get off the hobbyhorse of criticising all the alternative
>>platforms and actually co-operate with them or show that the Plan
>>9 way is as superior as we make it out to be.

you're possibly overlooking the possibility that some of us have
written things such as portable compilers (and other things)
ourselves for a good few other systems, and take that into account
when making comparisons -- it's not
just that this or that isn't Plan 9.

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

[David Gordon Hogan]

> On Wed, Nov 07, 2001 at 12:54:15PM -0500, David Gordon Hogan wrote:
> >
> > It's not.  If anything, it's worse.
>
> That's cheap.  Much as I can easily agree that GNU bloat can be
> improved on, I don't see anyone getting it right.
>
> Maybe the approach is flawed, but the results are out there.  Unlike
> Plan 9's ?c, GCC has to deal not only with different architectures,
> but also different operating systems.
>
> The above comment is a symptom of a Plan 9 syndrome I, for one, am
> not proud of: "we didn't contribute to it, it can't be any good".

No, it's a symptom of ``I wasted weeks of my life struggling
with this awful code''.

> In the meantime, if I want to cross-develop for Windows or Linux,
> or any other established platforms, Plan 9 is just no use to me,
> while GCC and its offspring are.  I know what my choice would be,
> but it's no choice, is it?  Oh, I forget the Inferno tools, those

GCC (Cygnus) is useless for Windows.  There's no way to link
a VXD!  So if you're doing any _serious_ development, are you
going to use two compilers, just so you can have the dubious
pleasure of using GCC?  I don't think so.

I'm sorry to be so ascerbic here, but I am sick of hearing people
defending GCC.

Why don't you help us improve the Inferno tools instead of
complaining about them?

> Sorry for the rant, I really don't mean it in a personal fashion,
> but I also fail to see the benefit of just criticising without
> providing any suggestions on _how_ to improve the things that are
> being criticised.  Like, you can't exactly remove GCC from today's
> development environment, what will you put in its place?  Across
> the board?

You want suggestions?  We could force all those GNU people to read
Rob's essay on programming style, for starters.

I have a cunning plan to use 8c to generate files that will
run under Windows 9x/Me.  Stay tuned...

Yes, you'll have to use MS compilers for the VXD and EXE
that get the show started, but that's it.  Unlike GCC, the
pleasure of using 8c is real.

I don't know about Nt/XP yet, but I'm guessing that they'll
be harder.

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

[Lucio De Re]

I'm not inviting flames, here, I'm just voicing an opinion no one else
seems to share :-(

On Wed, Nov 07, 2001 at 12:54:15PM -0500, David Gordon Hogan wrote:
>
> It's not.  If anything, it's worse.

That's cheap.  Much as I can easily agree that GNU bloat can be
improved on, I don't see anyone getting it right.

Maybe the approach is flawed, but the results are out there.  Unlike
Plan 9's ?c, GCC has to deal not only with different architectures,
but also different operating systems.

The above comment is a symptom of a Plan 9 syndrome I, for one, am
not proud of: "we didn't contribute to it, it can't be any good".

In the meantime, if I want to cross-develop for Windows or Linux,
or any other established platforms, Plan 9 is just no use to me,
while GCC and its offspring are.  I know what my choice would be,
but it's no choice, is it?  Oh, I forget the Inferno tools, those
are extremely useful, but they just don't reach far enough,
unfortunately.  I think that is a good direction, but still falls
short of present developers' needs.

Russ considered using ?c to produce Linux executables, but how much
work is involved?  OK, so dynamic libraries are a bad idea, but
even producing static binaries is near as damn out of the question.

Then forsyth mentions in passing he resorted to redefining thread
code for FreeBSD because Posix threads wouldn't cut it, so why is
the new design not submitted for inclusion in *BSD code?

Let's get off the hobbyhorse of criticising all the alternative
platforms and actually co-operate with them or show that the Plan
9 way is as superior as we make it out to be.

Sorry for the rant, I really don't mean it in a personal fashion,
but I also fail to see the benefit of just criticising without
providing any suggestions on _how_ to improve the things that are
being criticised.  Like, you can't exactly remove GCC from today's
development environment, what will you put in its place?  Across
the board?

++L