Re: [9fans] mv vs cp

Re: [9fans] mv vs cp

[jmk]

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

--jim

Re: [9fans] mv vs cp

[Lucio De Re]

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

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

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

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

++L

Re: [9fans] mv vs cp

[Alexander Viro]

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

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

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

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

Same race + metric buttload of other fun stuff.

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

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

Re: [9fans] mv vs cp

[George Michaelson]

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

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

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

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

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

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

Re: [9fans] mv vs cp

[Alexander Viro]

On Mon, 8 Oct 2001, George Michaelson wrote:

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

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

Re: [9fans] mv vs cp

[George Michaelson]

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

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

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

Re: [9fans] mv vs cp

[Lucio De Re]

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

++L

Re: [9fans] mv vs cp

[George Michaelson]

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

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

I really do mean the question as put:

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

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

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

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

Re: [9fans] mv vs cp

[Alexander Viro]

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

On Mon, 8 Oct 2001, George Michaelson wrote:

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

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

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

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

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

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

Re: [9fans] mv vs cp

[Alexander Viro]

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

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

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

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

Re: [9fans] mv vs cp

[Lucio De Re]

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

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

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

++L

Re: [9fans] mv vs cp

[George Michaelson]

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

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

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

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

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

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

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

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

cheers
	-George

Re: [9fans] mv vs cp

[Lucio De Re]

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

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

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

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

++L

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

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

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

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

Re: [9fans] mv vs cp

[Alexander Viro]

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

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

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

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

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

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

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

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

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

Thomas

Re: [9fans] mv vs cp

[Alexander Viro]

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

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

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

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

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

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

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

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

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

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

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

Re: [9fans] mv vs cp

[davel]

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

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

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

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

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

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

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

No polite comment available:-).

Cheers,
	Dave.

Re: [9fans] mv vs cp

[Ralph Corderoy]

Hi Dave,

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

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


Ralph.

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

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

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

Unlike people here, apparently, I sometimes make mistakes.  

Re: [9fans] mv vs cp

[davel]

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

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

Cheers,
	Dave.

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

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

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

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

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

Are you really serious?

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

Re: [9fans] mv vs cp

[davel]

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

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

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

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

Are YOU really serious?  Who said anything about punishment?

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

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

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

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

Cheers,
	Dave.

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

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

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

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

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

Re: [9fans] mv vs cp

[Alexander Viro]

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

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

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

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

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

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

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

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

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

Re: [9fans] mv vs cp

[Alexander Viro]

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

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

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

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

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

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

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

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

Re: [9fans] mv vs cp

[erik quanstrom]

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

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

erik

Re: [9fans] mv vs cp

[david presotto]

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


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

Re: [9fans] mv vs cp

[Skip Tavakkolian]

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

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

Re: [9fans] mv vs cp

[davel]

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

(I almost ignored this as a troll)

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

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

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

Cheers,
	Dave.

Re: [9fans] mv vs cp

[Boyd Roberts]

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

They spent quite a while in rename hell.

Re: [9fans] mv vs cp

[Douglas A. Gwyn]

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

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

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

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

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

Re: [9fans] mv vs cp

[Lucio De Re]

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

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

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

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

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

++L

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

jmk@plan9.bell-labs.com writes:

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

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

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

[Richard Uhtenwoldt]

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

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

  D<path>

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

  A<path><path2>

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

Then,

  Mv <path> <path2> 

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

  Ln -s <path> <path2>

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

  Del <path>

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

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

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

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

Advantages of my design:

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

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

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

[Claude BONFANTI]

Various attributes could be specified this way.

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


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

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

[Eric Grosse]

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

Done.

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

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

Various attributes could be specified this way.

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


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

[9fans] hardware support for the fs kernel

[Conor Williams]

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

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

[Geoff Collyer]

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

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

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

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

[Lucio De Re]

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

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

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

++L

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

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

[Geoff Collyer]

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

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

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

[Lucio De Re]

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

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

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

++L

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

[Russ Cox]

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

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

(Our current program called srvold9p is really mountold9p.)

Russ

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

[Lucio De Re]

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

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

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

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

++L

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

[Russ Cox]

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

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

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

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

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

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

Russ

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

[Lucio De Re]

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

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

++L

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

[James A. Robinson]

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

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


Jim

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

[Lucio De Re]

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

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

++L

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

[Geoff Collyer]

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

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

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

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

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

[Jack Johnson]

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

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

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

-Jack

[9fans] 9 in the news

[matt]

 How Apache & Plan 9 will defeat Microsoft's Passport

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

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


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

Re: [9fans] 9 in the news

[Lucio De Re]

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

++L

Re: [9fans] 9 in the news

[Arnaud SAHUGUET]

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

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

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

regards,

Arnaud

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


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

Re: [9fans] 9 in the news

[Jack Johnson]

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

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

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

-Jack

Re: [9fans] 9 in the news

[Ronald G Minnich]

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

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

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

ron

Re: [9fans] 9 in the news

[Steve Kilbane]

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

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

steve

Re: [9fans] 9 in the news

[matt]

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

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

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


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

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

[Eric Dorman]

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

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

--eric

Re: [9fans] sam and ssh

[Geoff Collyer]

Sorry, I thought Lucio was talking about Unix sam.

Re: [9fans] sam and ssh

[Lucio De Re]

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

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

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

++L

Re: [9fans] sam and ssh

[Scott Schwartz]

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

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

[9fans] PGP

[Lucio De Re]

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

++L

Re: [9fans] PGP

[Scott Schwartz]

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

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

Re: [9fans] PGP

[Dan Cross]

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

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

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

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

	- Dan C.

[9fans] sam and ssh

[Lucio De Re]

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

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

++L

Re: [9fans] sam and ssh

[Scott Schwartz]

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

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

Re: [9fans] sam and ssh

[Micah Stetson]

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

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

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

Micah

Re: [9fans] sam and ssh

[Lucio De Re]

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

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

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

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

Where do you get 9term?!

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

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

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

++L

Re: [9fans] sam and ssh

[Lucio De Re]

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

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

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

++L

Re: [9fans] sam and ssh

[Lucio De Re]

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

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

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

++L

Re: [9fans] sam and ssh

[Lucio De Re]

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

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

++L

Re: [9fans] sam and ssh

[peter huang]

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

-peter

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


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

[9fans] samuel

[Alex Danilo]

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

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

Rob states:

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

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

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

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

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

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

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

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

Well it is, you just have to know where.

Alex

Re: [9fans] samuel

[Alexander Viro]

On Mon, 11 Mar 2002, Alex Danilo wrote:

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

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

Re: [9fans] samuel

[Steve Kilbane]

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

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

steve

Re: [9fans] samuel

[Andrew Simmons]

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

Re: [9fans] samuel

[Thomas Bushnell, BSG]

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

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

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

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

Thomas

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

[anothy]

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

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

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

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

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

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

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

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

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

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

[Lucio De Re]

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

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

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

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

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

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

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

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

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

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

++L

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

[George Michaelson]

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

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

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

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

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

No irony intended.

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

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

[Jim Choate]

On Thu, 8 Nov 2001, George Michaelson wrote:

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

Then get ready to have it 'ruined'.

http://einstein.ssz.com/hangar18


 --
    ____________________________________________________________________

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

                                             Bumper Sticker

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

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

[Lucio De Re]

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

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

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

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

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

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

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

++L

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

[Thomas Bushnell, BSG]

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

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

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

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

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

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

Thomas

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

[Quinn Dunkan]

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

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

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

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

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

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

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

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

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


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

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

[Andrey A Mirtchovski]

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

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

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

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

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

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

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

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

[Steve Kilbane]

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

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

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

steve

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

[Boyd Roberts]

    Perl and Python i can see, for sure.

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

Re: [9fans] mv vs cp

[anothy]

yeah, but whoever's _got_ your fileserver can do
pretty much whatever they please.

Re: [9fans] mv vs cp

[okamoto]

Do you have some special Plan 9 file server kernel?

Kenji

Re: [9fans] mv vs cp

[Russ Cox]

That's okay, whoever runs your file server
can read your mail box too.

Russ

Re: [9fans] mv vs cp

[okamoto]

>Before you start saying that shared /tmp or all-mighty root are bad ideas,

I hate all-mighty root user because s/he can read my mail box.

Kenji

Re: [9fans] mv vs cp

[forsyth]

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

yes, i don't think the desire to move directory contents was at issue,
for that and other examples.
the question was whether to implement an optimisation for the
case where source and target names are on the same file store.

since in both the Plan 9 and Unix cases, it's necessary to copy,
plan 9 settles for renaming files and directories (in their containing directories),
but does not allow either files or directories to be moved without copying.
(depending on what the move operation means in the presence of
arbitrary per-process binds and mounts, it might be impossible to
provide a sensible definition of move from a user's point of view anyway.)

some versions of unix attempt to allow directories to be moved,
that typically doesn't work across file systems, so mv ends
up copying anyway, doing pretty much what plan 9 would do.
on unix, i might like to do {mv /tmp/superbigvideofile $home/videofarm/birthday}
without having the system copy a big file, but that usually doesn't work.
so on unix i probably would do {recordvideo $home/videofarm/tmp.$pid}
and rename it later, which is how i'd get round the problem on plan 9.


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

To: 9fans@cse.psu.edu
Subject: Re: [9fans] mv vs cp
Date: Wed, 10 Oct 2001 08:49:09 GMT
Message-ID: <9pvcjf$k1f$1@inputplus.demon.co.uk>

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

[okamoto]

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

I responded your comment before I read another comment on EROS, 
which said EROS is persistent.  Maybe it indicates it has no concept 
of directory graph.   If so, I understand your behaviour here.

Thanks

Kenji


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

From: Richard <greon@best.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] mv vs cp
Date: Mon, 08 Oct 2001 22:46:41 -0700
Message-ID: <E15qpiz-0000EM-00@localhost>

okamoto@granite.cias.osakafu-u.ac.jp writes:

>I don't understand your stance anymore...
>Aren't you who recommended us EROS?
>Isn't the file system of EROS directory graph?

my stance is that OS designers should learn about
capability OSes like EROS and that Plan 9 should 
be made more attractive to people used to Unix's mv
command.  do you detect an inconsistency in
that?

Re: [9fans] mv vs cp

[presotto]

On Tue Oct  9 12:35:49 EDT 2001, tb+usenet@becket.net wrote:
> 
> (One thing; please clear up my ignorance: sometimes a symlink is used
> for the benefit of all the users; where in a Plan 9 system do I put a
> "bind" such that it is the automatic default for all users in that
> way?)

That's what /lib/namespace is.  It represents a global namespace for
all users on a machine.  Of course, the user can then do whatever
he/she wants but serves as the default namespace.

/lib/namespace and your profile also represent persistence which is
another useful property you get from symlinks.

Re: [9fans] mv vs cp

[rog]

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

surely it's "broken for the user" the moment the user can't move a
file from one place to another for any reason at all (e.g.  because
the file is on a different disk, or a different location on the
network, or whatever).

under Windows, where disks and networks are visible at the top level
of the file tree to the user, perhaps this is slightly more
understandable, but where the file tree is unified, the difference
between "can't because it's on a different disk" and "can't because
it's in a different directory" is surely one of degree not of kind?

  rog.

Re: [9fans] mv vs cp

[forsyth]

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

``correctness and completeness''?  this sounds like the result of
a self-assessment exercise.

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

forsyth@vitanuova.com writes:

> >>Is this just an example of the "New Jersey" preference for simplicity
> >>of implementation over the "Cambridge" preference for correctness and
> >>completeness?
> 
> ``correctness and completeness''?  this sounds like the result of
> a self-assessment exercise.

Have you read the "wrong is better" paper?

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

[bwc]

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

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

Brantley Coile

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

[Douglas A. Gwyn]

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

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

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

[Lucio De Re]

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

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

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

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

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

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

++L

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

[Steve Kilbane]

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

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

steve

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

[John Murdie]

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

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

Anyone?

-- 

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

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

[Steve Kilbane]

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

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

steve

[9fans] Re: Browsers

[Boyd Roberts]

The problem is intractable, but not inabstraktable.

Re: [9fans] mv vs cp

[rob pike]

> walk away from symlinks because it was hard to get right, more than
> because  philosophically they were 'wrong'? 

Symlinks were put in to make it possible to link directories from user
mode and to have cross-file system links.  Plan 9 does both those
things another way.  I have never felt the need for symbolic links in
Plan 9.

They also have some ugly properties.  I find the delayed evaluation
mystifying sometimes.  Also, although they are used to implement
cross-system links, they live on a single file system.  For example,
/usr/rob might be a link to /home/rob even though /usr and /home live
on different disks or even different servers, which means /usr has a
file that talks about /home, a file on a different machine.  Besides
the creepiness of that, the delayed evaluation can bite you hard, the
permanence of the link can be troublesome, and this little piece of
name space stored as a time bomb somewhere in the network rather than
in the client's representation of its resources is poor compartment-
alization and therefore lousy design.  And why on earth does ls
default to showing you the link rather than what it points to?

This does not imply that Plan 9's name space was designed in reaction
to symbolic links, of course, but at least some of us did observe that
symbolic links were little more than a disgusting hack and that there
had to be a better way.  Ken was already thinking about that way when
all this was happening back in the early '80s.  I believe that the
design he came up with, Plan 9's name space, is indeed better,
although it has some problems of its own and doesn't exactly cover
symlinks (the lack of permanence of the mount table comes to mind).
The unification of all naming operations into a single data structure
(the mount table), the well-defined evaluation, and the clean
separation of file servers and name spaces, and most important the
user-modifiable, per-process name space were all improvements.

As I said in my `dot-dot' paper, Unix still hasn't recovered from all
the problems wrought by the introduction of symbolic links.  It is a
lesson, although not a new one, that the ugly, supposedly temporary
hack of symlinks became a permanent fixture of the system, and one
that people argue for passionately, mistaking the addressing of the
issue for a true solution to the problem (c.f.  Plan 9's # notation).

-rob

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

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

[about symlinks]

> and this little piece of
> name space stored as a time bomb somewhere in the network rather than
> in the client's representation of its resources is poor compartment-
> alization and therefore lousy design

This makes me think of something.

Plan 9 puts the mount hierarchy over in the per-process namespace,
which is a nifty idea.

Rob points out here that symlinks also really belong in per-process
places (and the same effect can be more cleanly realized with
"bind").  So clearly, there is no need for symlinks in Plan 9.

(One thing; please clear up my ignorance: sometimes a symlink is used
for the benefit of all the users; where in a Plan 9 system do I put a
"bind" such that it is the automatic default for all users in that
way?)

It seems to me that the same could be true of directory renames, if
the entire naming hierarchy were regarded as a per-process namespace,
rather than just the "mount" portions.  Then a given user could move,
mount, unlink, etc, without changing anything on the fileserver at all
(except a ref count).  [Actually, let it become more liberal and a ref
count is probably not sufficient any more.]

Re: [9fans] mv vs cp

[forsyth]

>>Surely hard links couldn't point to directories, so it was only about
>>alternate paths to leaf objects. Thats not the same as a GOTO loop.

they could, but (at least by 5th eidtion) it was restricted to the super-user.
in fact, that was how directory rename was implemented, by setuid mv using
link and unlink.  races?  argument checking?  ``values of [beta] will give rise to dom!''.
the . and .. names were actual links in the directory, put there by the mkdir command.
the rmdir command did the 3 unlinks (for ., .., and the name itself).

Re: [9fans] mv vs cp

[okamoto]

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

I don't understand your stance anymore...
Aren't you who recommended us EROS?
Isn't the file system of EROS directory graph?

Kenji


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

From: Richard <greon@best.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] mv vs cp
Date: Mon, 08 Oct 2001 08:37:59 -0700
Message-ID: <E15qcTf-0007iJ-00@localhost>

jmk@plan9.bell-labs.com writes:

>How often do you do a move of a whole tree, not just a rename?
>I can't remember the last time I did other than a rename or a copy
>of a few files. But I'm probably not the average user and I don't
>ever use a local disc.

I do it all the time (at least 5, 10 times a month) on Linux, because
I'm kind of compulsive about maintaining just the right names for data
files I care about.

The point is not that it is necessary, but rather that millions are
already used to being able to do it, and letting them do it on Plan 9
(provided of course it is implemented cleanly) will lower the obstacle
to their become Plan 9 users.

Re: [9fans] mv vs cp

[Richard]

okamoto@granite.cias.osakafu-u.ac.jp writes:

>I don't understand your stance anymore...
>Aren't you who recommended us EROS?
>Isn't the file system of EROS directory graph?

my stance is that OS designers should learn about
capability OSes like EROS and that Plan 9 should 
be made more attractive to people used to Unix's mv
command.  do you detect an inconsistency in
that?

Re: [9fans] mv vs cp

[presotto]

There are a number of solutions being aired here:

1) avoiding a copy the data and perhaps some of the metadata
2) on a recursive call, avoiding a message per file
3) getting it right if two people/programs do it simultaneously

The first 2 are performance, the last is adding something that
you can't do with our current mv.

(3) seems to be a solving a problem in the wrong place.
If two people simultaneously move a graph, the result is going to
be confusing/scarey even if everything resides in the same file
server and we somehow manage to lock the whole file server while
it happens, since in the absolute best case one is going to see
his graph inexpicably disappear.  This is more a social problem than
a technical one.  If programs are going to do it, they'ld better
set locks somewhere and have some agreement on what name space is
being looked at.

In plan 9, as rob pointed out, there's no way
for the file server to know what your name space is.
Therefore, the application or kernel has to walk the whole
subspace being moved and then try to create a set of requests
to the relevant file servers.  Not only will this set not 
be locked but you'll have done a large amount of walking
to figure out what to do.  Because of this, I think we're stuck with
forgetting about (2) and (3) without majorly changing how mounts
work.

(1), on the otherhand, may be possible.  It still requires that
you walk both paths and make sure they end up on the same
server.  Then you can have a message that says 'mv fid1 to fid2'.
I think that that's the best you can do, i.e., file by file.
You might improve that to a directory mv but you'ld have to
know that nothing was mounted below the source directory.
That is probably more trouble than its worth.

The file server can always say 'error - unimplemented' and
you can fall back to the create/copy/rm.  That way you
don't have to require exportfs, ftpfs, upas/fs and a
slurry of other impossible to understand servers to
change.

By the way, think about the following scenario:

	mkdir x
	> x/y
	bind -a x .
	mv y z

What do you want to happen here?  Should y change directory when
renamed to z or not?

On the whole, I don't think it worth the trouble.  As the above
example points out, the result of mv is already pretty confusing
in our namespace.  Whatever solution you choose should make things
less confusing, not more.

Re: [9fans] mv vs cp

[anothy]

// 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 is to me. how do i know if it does or doesn't? what's the condition?
what's the behaviour if it doesn't? hell, what's the behaviour if it _does_
resolve? questions of whether to follow links or not... it's just never
seemed worth it. the _only_ time i've missed symlinks in Plan 9 is in
importing packages from elsewhere. this simpler version of what you
have above, which _wouldn't_ seem inherently evil to me, would be:
	"I point to <x>, where x is a set of data."
much simpler, much easier to implement (uh, like, files?), much more
consistant, and thus easier to understand. even multiple hard links
under unix satisfy this: if it's there, it points to a certain set of data.
no condidtions on that.

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

no, not likely. it's been a while since i've poked at any Windows box,
but under at least '95 and '98revA, drop into a shell prompt and try
to cat^Wtype foo.lnk. it's not even built into the FS, it's interpreted by
the tools, like explorer.
-α.

Re: [9fans] mv vs cp

[rob pike]

> We accept that the "trees" (you're perfectly right about directed
> graphs) are rooted at the same fileserver, I think.

Do you?  A mv-tree thingy would require the server to know the name
space of the client to get this right.  The server doesn't know that
one of the files in the client's tree is somewhere else.  I honestly
don't see a reasonable way to do this right, even if we don't worry
about race conditions (and we do).

-rob

Re: [9fans] mv vs cp

[Alexander Viro]

On Mon, 8 Oct 2001, rob pike wrote:

> > We accept that the "trees" (you're perfectly right about directed
> > graphs) are rooted at the same fileserver, I think.
> 
> Do you?  A mv-tree thingy would require the server to know the name
> space of the client to get this right.  The server doesn't know that
> one of the files in the client's tree is somewhere else.  I honestly
> don't see a reasonable way to do this right, even if we don't worry
> about race conditions (and we do).

Actually, there's another fun issue here:

bind /foo/bar/baz /quux
cd /quux/crap
mv /foo/bar/baz/crap /foo/bar/crap
cd ..

Where should we end up?  I have a somewhat reasonable answer for our
semantics of bindings, but I don't see it for Plan 9 one.

Re: [9fans] mv vs cp

[Markus Friedl]

On Mon, Oct 08, 2001 at 11:00:24AM -0400, Alexander Viro wrote:
> Actually, there's another fun issue here:
> 
> bind /foo/bar/baz /quux
> cd /quux/crap
> mv /foo/bar/baz/crap /foo/bar/crap
> cd ..
> 
> Where should we end up?  I have a somewhat reasonable answer for our
> semantics of bindings, but I don't see it for Plan 9 one.

there are probably many ways to mess with your own
namespace. but why should the system care? after
all it's your own process-local namespace.

Re: [9fans] mv vs cp

[Lucio De Re]

On Mon, Oct 08, 2001 at 10:46:44AM -0400, rob pike wrote:
> 
> Do you?  A mv-tree thingy would require the server to know the name
> space of the client to get this right.  The server doesn't know that
> one of the files in the client's tree is somewhere else.  I honestly
> don't see a reasonable way to do this right, even if we don't worry
> about race conditions (and we do).
> 
Wait, I'm being obtuse here.  Do you see a "mv-tree thingy" as
essential to a "rename" function?  I'm going along with Dave's
suggestion that the kernel determine the fids of source and
destination (and I'm using fids loosely because I'm not really
familiar with them) and then submit then (Tmv or, my preference,
Trename) to the fileserver for actioning.

Moves that require data to be tranferred are forbidden in my model
(they can be handled by user-space operations, I suppose) and damage
to the namespace is the user's responsibility.

Again, in my ignorance, I assume that one would create an anonymous
node at the destination and point it (in some fashion I really
don't know enough about, but I'll be pleased to have my nose rubbed
into the details of, whichever way) to the fileserver entity
originally pointed at by the source.  The original connection would
then be removed and name transfer take place (roughly).  Please
educate me on this, reading the documents and man pages didn't make
the picture any clearer.

I certainly can't agree that the fileserver won't know that a file
is elsewhere: if the nameserver can't tell which files it serves
we have a serious problem.  Now, if by the time the fileserver
considers a file it has an id that looks like a local one, we
certainly have a crisis, but I'm hoping that the kernel can prevent
this _at_the_root_ of the rename, yet I hear continuous references
to the remainder of the graph, which puzzles me because I don't
see rename navigating the graph at all.  I'm sure I'm wrong, so
please tell me where.

As for Alexander's example, I really need to look at it more
carefully, I don't understand the details at all.

++L

Re: [9fans] mv vs cp

[rob pike]

What should mv do to a `tree' that resides on multiple file servers?
If you can't do something right, sometimes it's not worth doing at
all.

-rob

Re: [9fans] mv vs cp

[Lucio De Re]

On Mon, Oct 08, 2001 at 09:03:28AM -0400, rob pike wrote:
> 
> What should mv do to a `tree' that resides on multiple file servers?
> If you can't do something right, sometimes it's not worth doing at
> all.
> 
We accept that the "trees" (you're perfectly right about directed
graphs) are rooted at the same fileserver, I think.  Moving the root
to a new location on the fileserver isn't going to be affected by
portions below it that may stride other filesystems.

In my ignorance, I presume that only the root needs to move around and
the rest (hopefully acyclically) will remain unchanged.  Does the
possibility exist that we may be creating loops?

++L

Re: [9fans] mv vs cp

[rob pike]

> writing correct tree-walker
> that would deal gracefully with cross-directory renames is _nasty_.

This is because the file system isn't a tree and hasn't been for a very
long time. It's a graph, but people still talk about it as thought it were
a tree and write simple recursive algorithms and get themselves in
trouble all the time.

-rob

Re: [9fans] mv vs cp

[Douglas A. Gwyn]

rob pike wrote:
> This is because the file system isn't a tree ...

? It has a root, and in every directory including the root there
are names that refer to things that are either directories or not.
The only thing that would keep those properties from imposing a
tree structure would be the existence of cycles.  Sure, it is
possible to construct Moebius poiuyts, but most of the time if
someone wants to invoke a tree walker it is because he *knows*
that no such shenanigans are present.  On UNIX variants these
days, there are symbolic links that allow cycles, but all that
is necessary to keep them from causing problems is to flag an
error when path-walking revisits a node that is in the parent
path.  Even on pre-7th Edition Unix, it was fairly easy to make
a cyclic structure using (hard) links.  But tree-walking has
been common and useful for decades despite those opportunities
for cyclic behavior.

As the WWW has shown, structures don't have to be perfect to
be very useful.  We're still waiting for Xanadu..

Re: [9fans] mv vs cp

[George Michaelson]

> path.  Even on pre-7th Edition Unix, it was fairly easy to make
> a cyclic structure using (hard) links.  But tree-walking has
> been common and useful for decades despite those opportunities
> for cyclic behavior.

Surely hard links couldn't point to directories, so it was only about
alternate paths to leaf objects. Thats not the same as a GOTO loop.

> 
> As the WWW has shown, structures don't have to be perfect to
> be very useful.  We're still waiting for Xanadu..

I entirely agree. I think that symlinks can be viewed as runtime
evaluated conditionals in the filespace. That it means perfoming
more work than traversing the hard link is true. That it lets
you perform a large number of tasks that want to walk into partitioned
spaces it also true I think. 

That the only extant implementation has severe flaws and inconsistencies
is a damn shame.

Didn't the guys one stack down on the shoulders of the giants decide to
walk away from symlinks because it was hard to get right, more than
because  philosophically they were 'wrong'? Unlike with dead physicists,
we get to ask these questions and sometimes get answers more than conjecture.

-George

Re: [9fans] mv vs cp

[Douglas A. Gwyn]

George Michaelson wrote:
> Surely hard links couldn't point to directories, ...

Yes, they could.  It was a common form of corruption in 6th Edition
UNIX.

Re: [9fans] mv vs cp

[Borja Marcos]

On Wednesday 10 October 2001 10:57, you wrote:
> George Michaelson wrote:
> > Surely hard links couldn't point to directories, ...
>
> Yes, they could.  It was a common form of corruption in 6th Edition
> UNIX.

	You could even do weird things. For example, this worked under SCO Unix.

	cd /some/directory
	mkdir another
	unlink ..
	link another ..
	unlink another

	And you had a directory called "/some/directory/.." which didn't actually 
point to "/some/directory", but was a new directory. It was a great way for 
hackers to hide things in a machine.



	Borja.

Re: [9fans] mv vs cp

[Borja Marcos]

On Wednesday 10 October 2001 13:50, you wrote:
> 	And you had a directory called "/some/directory/.." which didn't actually
> point to "/some/directory", but was a new directory. It was a great way for

	TYPO: I meant point to "/some", obviously ;-)



	Borja.

Re: [9fans] mv vs cp

[nigel]

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

Well, I've seen only one Windows machine infected with a virus my
whole life. Am I to conclude that viruses are not a problem?


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

From: George Michaelson <ggm@apnic.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] mv vs cp
Date: Mon, 08 Oct 2001 16:49:43 +1000
Message-ID: <4615.1002523783@apnic.net>


> 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

[jmk]

How often do you do a move of a whole tree, not just a rename?
I can't remember the last time I did other than a rename or a copy
of a few files. But I'm probably not the average user and I don't
ever use a local disc.

Re: [9fans] mv vs cp

[Mike Haertel]

>How often do you do a move of a whole tree, not just a rename?
>I can't remember the last time I did other than a rename or a copy
>of a few files. But I'm probably not the average user and I don't
>ever use a local disc.

Often.  This is one of the things that most irritates me about Plan 9.

In particular, the oft-cited idiom of using tar to copy the hierarchy
is especially undesirable under Plan 9 because it generates lots of
garbage that will fill up your dump filesystem much faster.

To what extent do you think your expectations and habits are shaped by
the limitations of your tools?

Re: [9fans] mv vs cp

[Lucio De Re]

On Sun, Oct 07, 2001 at 10:45:24PM -0700, Mike Haertel wrote:
> 
> Often.  This is one of the things that most irritates me about Plan 9.
> 
Talk about extreme responses :-)

++L

Re: [9fans] mv vs cp

[Lucio De Re]

On Mon, Oct 08, 2001 at 01:05:30AM -0400, jmk@plan9.bell-labs.com wrote:
> 
> How often do you do a move of a whole tree, not just a rename?
> I can't remember the last time I did other than a rename or a copy
> of a few files. But I'm probably not the average user and I don't
> ever use a local disc.

Because I'm steeped in SysV (which is where I cut my Unix teeth), I
wouldn't find it hard to use "find . -print | cpio -pvdm dest" as
taught in one of the man pages in my early days.  So, to answer your
question truthfully: "Never".

++L

Re: [9fans] mv vs cp

[Douglas A. Gwyn]

jmk@plan9.bell-labs.com wrote:
> How often do you do a move of a whole tree, not just a rename?
> I can't remember the last time I did other than a rename or a copy
> of a few files. But I'm probably not the average user and I don't
> ever use a local disc.

I frequently move large trees around, but often they are not within
the same filesystem.

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

jmk@plan9.bell-labs.com writes:

> How often do you do a move of a whole tree, not just a rename?
> I can't remember the last time I did other than a rename or a copy
> of a few files. But I'm probably not the average user and I don't
> ever use a local disc.

I do it all the time.  

Re: [9fans] mv vs cp

[Richard]

jmk@plan9.bell-labs.com writes:

>How often do you do a move of a whole tree, not just a rename?
>I can't remember the last time I did other than a rename or a copy
>of a few files. But I'm probably not the average user and I don't
>ever use a local disc.

I do it all the time (at least 5, 10 times a month) on Linux, because
I'm kind of compulsive about maintaining just the right names for data
files I care about.

The point is not that it is necessary, but rather that millions are
already used to being able to do it, and letting them do it on Plan 9
(provided of course it is implemented cleanly) will lower the obstacle
to their become Plan 9 users.

Re: [9fans] mv vs cp

[William Josephson]

On Mon, Oct 08, 2001 at 08:37:59AM -0700, Richard wrote:
> I do it all the time (at least 5, 10 times a month) on Linux, because
> I'm kind of compulsive about maintaining just the right names for data
> files I care about.
> 
> The point is not that it is necessary, but rather that millions are
> already used to being able to do it, and letting them do it on Plan 9
> (provided of course it is implemented cleanly) will lower the obstacle
> to their become Plan 9 users.

But Plan 9 is not Unix and the more one tries to make it look like
Unix, feel like Unix, or quack like Unix, the more grief one comes to.
Under Unix I use mv to move trees around fairly frequently (as often
as once or twice a day), although at least half the time it is across
partitions so the point is moot anyway.  The urge to do this
disappeared pretty quickly when I started using Plan 9 to the
exclusion of Unix this summer.  I'm more of a neat-freak when it comes
to directory structure than most and I still didn't feel the loss.
Perhaps having a real fileserver makes the difference, but I'd suggest
living for a while with Plan 9 as Plan 9 and not Unix and see if you
still find it intolerable.  I think the biggest obstacle to using Plan
9 is knowing that it was built in the same room as Unix.

  -WJ

RE: [9fans] mv vs cp

[nigel]

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

Don't know the name, but it's been available mail order here for years.


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

From: presotto@closedmind.org
To: 9fans@cse.psu.edu
Subject: RE: [9fans] mv vs cp
Date: Sun, 7 Oct 2001 15:11:27 -0400
Message-ID: <20011007191129.4E4CB1998A@mail.cse.psu.edu>

Sorry about that.  I didn't see that the return address was
9fans.  But if anyone can come up with the name of the tool,
I'ld be a happy camper...

RE: [9fans] mv vs cp

[presotto]

Sorry about that.  I didn't see that the return address was
9fans.  But if anyone can come up with the name of the tool,
I'ld be a happy camper...

RE: [9fans] mv vs cp

[Skip Tavakkolian]

Gator Grip, comes with a handy ratchet and a drill attachment too.

At 03:11 PM 10/7/2001 -0400, presotto@closedmind.org wrote:
>Sorry about that.  I didn't see that the return address was
>9fans.  But if anyone can come up with the name of the tool,
>I'ld be a happy camper...
>
>

RE: [9fans] mv vs cp

[presotto]

It was time.  I got cable too.  Now I've seen a $19.95
tool I want, though I can't remember the name.  It's a socket
wrench that's essentially a cylinder filled with pins that can
contour around a nut.  Seen it?  Even cooler than the metriwrench.

Re: [9fans] mv vs cp

[presotto]

On Sun Oct  7 02:30:21 EDT 2001, lucio@proxima.alt.za wrote:
> Am I being utterly obtuse, or does it really make sense to duplicate
> then delete files when moving them to another directory?

It could be done, it just depends on what you'ld like to pay for it,
its just code after all.

You'ld need to create a new file system message (Tmv) and a new system
call (mv).  The kernel would have to start by walking both paths and
determine if they came from the same mount point, error if not.  It would
then send a Tmv message with 2 fids.  The file system would determine
if it could do it and return an error if not (might not be space, ...).
The file system structure would also have to be changed to accomodate it, we
don't have links, though the copy on write makes that not too terrible.

We consciously traded simplicity for it.  It hasn't bothered us enough to
regret it, perhaps because a real file server is faster than kfs, perhaps
because we don't do a lot of file moving.

If you think otherwise, that's why the source is open.  Have a look and
see what you'ld need to change and then convince others that the change
is worth it.  Implementations are no big deals.  New file system messages
are since you have to change lots of file servers to go with it.

> I had the distribution archives in /dist under "kfs" and decided to do
> the following:
> 
> 	% cd /dist
> 	% mkdir plan9
> 	% mv *.9gz plan9
> 
> the machine is still busy copying plan9.9gz :-(
> 
> In this case, a "rename" would have been appropriate.  Is it not
> possible to determine whether it would work and resort to cp+rm if
> it doesn't?

This is indeed what happened, mv determined it wouldn't work and did a
cp+rm when it found it wouldn't.

Re: [9fans] mv vs cp

[Lucio De Re]

On Sun, Oct 07, 2001 at 08:43:53AM -0400, presotto@closedmind.org wrote:
> 
> It could be done, it just depends on what you'ld like to pay for it,
> its just code after all.
> 
I guess I'll have to put my money where my mouth is.  Don't nobody
hold their breath!  :-)

Presotto certainly covered the important facets rather nicely, it
would be a pity to drop that particular ball now.

In passing, I can't easily find a reference to the 9P2000 preliminary
information, could someone post a URL?  I seem to remember some
sort of version information being designed in which would certainly be
helpful.

++L

PS: Dave, nice domain name.

RE: [9fans] mv vs cp

[philw]

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

like the new email address.
phil

[-- Attachment #2: Type: text/html, Size: 423 bytes --]

Re: [9fans] mv vs cp

[forsyth]

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

wstat gives a directory entry a new name;
it doesn't move it.


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

From: Lucio De Re <lucio@proxima.alt.za>
To: 9fans mailing list <9fans@cse.psu.edu>
Subject: [9fans] mv vs cp
Date: Sun, 7 Oct 2001 08:29:00 +0200
Message-ID: <20011007082859.I28720@cackle.proxima.alt.za>

Am I being utterly obtuse, or does it really make sense to duplicate
then delete files when moving them to another directory?

I had the distribution archives in /dist under "kfs" and decided to do
the following:

	% cd /dist
	% mkdir plan9
	% mv *.9gz plan9

the machine is still busy copying plan9.9gz :-(

In this case, a "rename" would have been appropriate.  Is it not
possible to determine whether it would work and resort to cp+rm if
it doesn't?

In fact, a rename command would be an adequate compromise.  I see
there's a "kfs" command called "rename" but the man page does not
specify its actual scope.  Should I have used that (one file at the
time) instead?

++L

Re: [9fans] mv vs cp

[Russ Cox]

> In this case, a "rename" would have been appropriate.  Is it not
> possible to determine whether it would work and resort to cp+rm if
> it doesn't?

How would you determine whether it would work?
How would you specify it to the underlying 9P server?

Don't use kfs rename; it doesn't move files 
between directories.

Russ

Re: [9fans] mv vs cp

[Thomas Bushnell, BSG]

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

> How would you determine whether it would work?
> How would you specify it to the underlying 9P server?

We had this problem in the Hurd, and the answer was give to one of the
servers for the two names (it doesn't matter which) your capability
for the other server.  

Then if both are handled by the same server (what Unix thinks of as
"same filesystem") it can be done directly.  If not, the server could
return EXDEV (as Unix does).  Or, two cooperating servers might have a
private protocol for arranging it between them.  

I don't know whether this would work in Plan 9, though I'm interested
in hearing details.  Can you hand your capability for one server off
to the other?  

[9fans] mv vs cp

[Lucio De Re]

Am I being utterly obtuse, or does it really make sense to duplicate
then delete files when moving them to another directory?

I had the distribution archives in /dist under "kfs" and decided to do
the following:

	% cd /dist
	% mkdir plan9
	% mv *.9gz plan9

the machine is still busy copying plan9.9gz :-(

In this case, a "rename" would have been appropriate.  Is it not
possible to determine whether it would work and resort to cp+rm if
it doesn't?

In fact, a rename command would be an adequate compromise.  I see
there's a "kfs" command called "rename" but the man page does not
specify its actual scope.  Should I have used that (one file at the
time) instead?

++L

Re: [9fans] mv vs cp

[Quinn Dunkan]

> Am I being utterly obtuse, or does it really make sense to duplicate
> then delete files when moving them to another directory?

mv does try to rename (uses dirwstat, I think), but you can only rename to the
same directory, check mv.c.  There was a discussion a while back about how
hard cross directory renames are.

Re: [9fans] mv vs cp

[Lucio De Re]

On Sat, Oct 06, 2001 at 11:42:15PM -0700, Quinn Dunkan wrote:
> 
> mv does try to rename (uses dirwstat, I think), but you can only rename to the
> same directory, check mv.c.  There was a discussion a while back about how
> hard cross directory renames are.

Sorry to be pig-headed about this, but I guess I'm spoilt (Boyd,
none of your sarcasm, please) with NetBSD doing it all for me.

Thing is, I may be representative of a largish community of spoilt
users, but there are also other considerations, for example, there
may not be enough space for the copy, a situation made worse by
the presence of a large time window in which race conditions can
occur.

Russ asks a pertinent question, how does one tell?  I'm wondering,
not being too good at the innards of Plan 9 and/or the filesystem,
whether it would not be worth sacrificing the cleanliness of the
filesystem to the ability to know.  Yes, it is a slippery slope:
once you can tell, why not move directories around, and so forth.

All I can say in self-defence is that user convenience is being
sacrificed here (I ought to know, but I can't remember how the
various Windows flavours deal with the problem) and the sacrifice
may be greater than the gain in simplicity.

I'm sure I'm wrong, but I never quite understood the underlying
limitation, so perhaps I can be pointed in the right direction and
I'll shut up for good.

++L

Re: [9fans] Sam question

[nigel]

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

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

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

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

Re: [9fans] Sam question

[Steve Kilbane]

Nigel:

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

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

steve

Re: [9fans] Sam question

[Luis Fernandes]

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

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

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

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

Re: [9fans] Sam question

[Boyd Roberts]

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

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

Re: [9fans] Sam question

[Boyd Roberts]

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

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

Re: [9fans] Sam question

[Lucio De Re]

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

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

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

++L

Re: [9fans] Sam question

[Boyd Roberts]

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

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

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

            if (forbid(c))
                goto break2;

            ...
        }
    }

break2:

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

iirc it should be 'goto fonfon' :)

Re: [9fans] Sam question

[Lucio De Re]

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

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

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

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

++L

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

Re: [9fans] Sam question

[Boyd Roberts]

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

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

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

Re: [9fans] Sam question

[Lucio De Re]

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

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

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

++L

Re: [9fans] Sam question

[Steve Kilbane]

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

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

> Yet the alternative is the dreaded "goto"

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

steve

Re: [9fans] Sam question

[Dan Cross]

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

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

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

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

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

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

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

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

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

	- Dan C.

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

[anothy]

//Local caching would be great, I think.

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

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

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

[Wladimir Mutel]

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

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

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

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

AFS Implements Save on Close

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

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

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


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

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

[Tom Duff]

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

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

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

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

[Boyd Roberts]

From: Tom Duff <td@pixar.com>

> Unless some numskull changed it since the last time

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

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

[Alexander Viro]

On Tue, 14 Nov 2000, Tom Duff wrote:

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

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

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

[Boyd Roberts]

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

> Not bloody likely. _Many_ applications exit without calling close

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

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

you wanna outcode duff?

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

[Tom Duff]

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

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

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

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

[Chris Locke]

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

Chris.

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

[Douglas A. Gwyn]

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

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

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

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

[Boyd Roberts]

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

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

absolutely correct.

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

[Tom Duff]

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

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

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

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

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

[Alexander Viro]

On Tue, 14 Nov 2000, Tom Duff wrote:

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

Erm... Ditto.

> The exit system call closes all open files.

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

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

[Tom Duff]

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

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

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

[Alexander Viro]

On Tue, 14 Nov 2000, Tom Duff wrote:

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

Grr... OK, let me rephrase it:

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

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

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

[Boyd Roberts]

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

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

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

tell me why the BSD f/S was written?

quadratic rehash -- give me a break.

Re: [9fans] /n/smtp

[Russ Cox]

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

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

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

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

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

russ

Re: [9fans] /n/smtp

[Boyd Roberts]

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

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

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

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

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

   com

   <creates template and then uses B>

   del

   <delivers it>

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

Re: [9fans] /n/smtp

[Boyd Roberts]

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

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

the idea was John J. Mackin's:

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

Re: [9fans] /n/smtp

[Scott Schwartz]

> sam should have a named pipe for commands

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

Re: [9fans] /n/smtp

[Boyd Roberts]

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

the code is trivial.  50 lines?

i think it's in unix.c.

Re: [9fans] file server problems

[ianb]

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

I thought that fileservers had to be SCSI?

Ian

Re: [9fans] file server problems

[Eric Dorman]

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


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

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

Eric Dorman
edorman@san.rr.com

Re: [9fans] file server problems

[Eric Dorman]

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


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

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

--eld

Re: [9fans] file server problems

[Lucio De Re]

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

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

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

++L

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

Re: [9fans] file server problems

[Scott Schwartz]

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

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

Re: [9fans] file server problems

[Lucio De Re]

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

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

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

++L