9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* Re: [9fans] correcting old failures, and NJ vs MA
@ 2001-10-09 21:44 forsyth
  0 siblings, 0 replies; 13+ messages in thread
From: forsyth @ 2001-10-09 21:44 UTC (permalink / raw)
  To: 9fans

>>finally, as forsyth points out, questions of "completeness and correctness"
>>are most often self-assesment exercises. particularly correctness, when
>>designing or building something new. who's to say what the "correct"
>>behaviour of mv/rename in Plan 9 is (well, when it was being designed)?

i was really referring, slightly sarcastically, to the assessment of the `Cambridge' approach
as having such-and-such splendid characteristics as opposed to the `NJ' approach
when i might just as easily have changed the assignment of attributes to each camp,
for much the reasons that anothy suggests (if you aim for simplicity,
a closer approximation to correctness often follows, for instance).
unfortunately, it seems nothing can save us from the new camp, W3C and XML.

as regards the comment above, my prejudice is that `completeness' and
`correctness' (with respect to a specification) have meaning in
mathematics, and that places some bound on our sloppiness, even in
computing.  doing mathematics isn't purely formal, pace Hilbert, but
it isn't arbitrary either.  deciding the specification might well be
subjective, although there are often external constraints on its
choice (eg, it's usually bad for a computer-controlled train to leave
the ground, maglev systems and the like excepted, but it's expected of
computer-controlled airplanes).  having settled on a target, though, i
can make a reasonable attempt to decide whether i've hit it.



^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: [9fans] correcting old failures, and NJ vs MA
@ 2001-10-11 11:39 forsyth
  0 siblings, 0 replies; 13+ messages in thread
From: forsyth @ 2001-10-11 11:39 UTC (permalink / raw)
  To: 9fans

>>Moving a directory can *NOT* be done in constant time without special
>>kernel support.  Even a Version 7 style unlink/link if it allowed
>>links to directories would at least allow it to be possible (though
>>with additional race conditions).

i see this rumbles on.  what i tried to point out in my video file example
(using a file not a directory but the point is the same)
is that unix doesn't do mv in constant time for either files or directories,
except in the particular case that both names point into the same physical file system.
otherwise it can only do what plan 9 does.

now, on all the out-of-the-box unix systems i looked at before
posting, of the set {/, /var, /tmp, /usr, /home} at least two were
always on different physical file systems, particularly /tmp and /usr
or /home.  i don't know why they do that when it's not necessary but
they do.  it would be worse if any possessed the chaos of automounted
NFS links i've seen on most large unix installations in the past.

i'd say all that makes it worse for the user because now i need to
understand the underlying file system topology to take advantage of the
optimisation and arguably it would be easier to understand under windows
which requires you to see all the device and partition boundaries!



^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: [9fans] correcting old failures, and NJ vs MA
@ 2001-10-10 13:04 presotto
  2001-10-11  9:10 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 13+ messages in thread
From: presotto @ 2001-10-10 13:04 UTC (permalink / raw)
  To: 9fans

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

Composing the viewpoints I've seen:

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

and

>People have noted (quite rightly) that the kernel code for moving
>directories is tricky and easy to get wrong and complex.  But what
>they haven't noted is that the user-space solution is even more tricky
>(if you expect it to solve the same problems), and even easier to get
>wrong, and even more complex.

...I guess we should write a web browser and stick it in the
kernel.

We are indeed driven by kernel simplicity more than anything else
because it has to survive a more varied load than individual commands.
A failure of the kernel is deadly to everything on the system.  It also
has the most persistent state of any part of the system so that leaks
and stray memory references that wouldn't bother a program tend to
eventually bring the kernel down.  Because of that, we try to put
things in kernel only if they significantly improve performance, are needed
to enforce some policy, or just can't be done outside the kernel.
Moving a directory doesn't fall into any of these categories, though
some parts of the operation do.  The move itself should be in a library
if it's going to be used by more than one program.

I find moving directories often useful, though orders of magnitude less
so than compiling, reading mail, buying wrenches on the web, ...
Making moving directories fast and convenient is as useful as
doing the same for rearranging furniture.  The current mv does let
you move directories and doesn't do it any less correctly than
the kernel could. I've spent more time reading the messages about
moving directories here than I ever would have saved by
had they been implemented.

As for find, this isn't rocket science.  Quit yapping and implement it
if you want it.  To be safe from graph cycles, you can keep 
track of qids of directories or, if you're lazy, use fd2path and give
up when the tree gets too deep.

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

From: Boyd Roberts <boyd@strakt.com>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] correcting old failures, and NJ vs MA
Date: Wed, 10 Oct 2001 11:16:10 +0200
Message-ID: <3BC411DA.3B191015@strakt.com>

"Thomas Bushnell, BSG" wrote:
> People have noted (quite rightly) that the kernel code for moving
> directories is tricky and easy to get wrong and complex.  But what
> they haven't noted is that the user-space solution is even more tricky
> (if you expect it to solve the same problems), and even easier to get
> wrong, and even more complex.

A user mode bug won't crash the machine.

^ permalink raw reply	[flat|nested] 13+ messages in thread
* Re: [9fans] correcting old failures, and NJ vs MA
@ 2001-10-09 21:51 bwc
  0 siblings, 0 replies; 13+ messages in thread
From: bwc @ 2001-10-09 21:51 UTC (permalink / raw)
  To: 9fans

I'm amazed at how long the ``ITS is better than CTSS'' debate can survive.

Would we be having this thread if undergrads at MIT were allowed more access
to CTSS accounts?

  Brantley


^ permalink raw reply	[flat|nested] 13+ messages in thread
* [9fans] correcting old failures, and NJ vs MA
@ 2001-10-09 17:43 anothy
  2001-10-10  8:56 ` Thomas Bushnell, BSG
  0 siblings, 1 reply; 13+ messages in thread
From: anothy @ 2001-10-09 17:43 UTC (permalink / raw)
  To: 9fans

// I'm not expert in Plan 9, but it seems to me that it [plan 9's rename
// behaviour] breaks it for the user.

i believe viro was talking specifically about the fact that changing this
awkward behaviour in Unix would break a bunch of user-level code
and user-created scripts, whereas in Plan 9 no user-level code or
user-created scripts existed to break yet. thus, when designing Plan 9,
the simpler approach to mv/rename was taken.

the remainder of this post is a bit of a rant. skip it if you're short on time.

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

the first time i was exposed to this distinction was in an appendix to "the
Unix-haters Handbook", appendix C, an article called "The Rise of Worse
is Better", by Richard P. Gabriel. the delibrate mis-representation of Unix
(and, by extention, Plan 9 and Inferno) design principles, and thus the
false distinction and conclusions, continually annoy me. here's why.

Gabriel characterized "the MIT/Stanford style of design" in four points
(taken from the above-mentioned source):

	• Simplicity - the design must be simple, both in implementation and
	interface. It is more important for the interface to be simple than that
	the implementation be simple.
	• Correctness - the design must be correct in all observable aspects.
	Incorrectness is simple not allowed.
	• Consistency - the design must not be inconsistent. A design is
	allowed to be slightly less simple and less complete to avoid
	inconsistency. Consistency is as important as correctness.
	• Completeness - the design must cover as many important situations
	as is practical. All reasonably expected cases must be covered.
	Simplicity is not allowed to overly reduce completeness.

Gabriel asserts that, for MIT/Stanford style programmers, all of these points
must be met. failure to meet any one is unacceptable (nevermind that he
contradicts that in the "Consistency" point, ironically). Gabriel contrasts this
with "the New Jersey approach" in the following ways (paraphrased for
simplicity and brevity):

	• Simplicity - it is more imporant for the implementation to be simple
	than the interface. simplicity is the most imporant design element.
	• Correctness - things still need to be correct, but it's slightly better to
	be simple than correct.
	• Consistency - can be sacrificed for simplicity, but it's better to drop
	completeness to save both consistency and simplicity
	• Completeness - the design must be as complete as is practical, but
	this can be sacrificed for any above quality, particularly simplicity. of
	particularly low value is consistancy of interface.

Gabriel is, however, an idiot (at least here).

first of all, the example he cites to show this difference uses a "famous
person" from Berkeley as an example of the NJ approach. problem one, as,
in my opinion, Berkeley mostly just missed the point. he then goes on to
talk about the difference between the MIT and "NJ" (really Berkeley)
approach to a specific problem ("PC losering" in Unix and ITS).

Gabriel is correct, in my opinion, that the NJ approach takes simplicity to be
the most important design constraint. Gabriel, however, sees this as in
conflict with the other three listed goals, whereas i believe the NJ approach
uses simplicity to achieve the other goals.

take windowing systems as an example. MIT produced X Windows, NJ
produced /dev/draw and rio. the NJ approach focuses on simplicity, and in
particular, simplicity and consistancy of interfaces. as a result, upon
designing the graphics system around 9P (a simple protocol consistantly
used to interface to the entire system), you get networked, remote displays
for free. focusing on simplicity (and consistancy of interace) helps achieve
the other goals in a much better manner. MIT, by contrast, focused, i think,
primarialy on completeness and correctness, and the result was a
complicated, often incorrect, inconsistant, and incomplete system.

it's worth noting that the same simple, consistant interface that made that
possible for Plan 9 gave us networked file systems that are more complete,
more correct, more consistant, and far simpler than NFS or SMB. look at
all the crap the X folks introduce to do things like remote audio.

finally, as forsyth points out, questions of "completeness and correctness"
are most often self-assesment exercises. particularly correctness, when
designing or building something new. who's to say what the "correct"
behaviour of mv/rename in Plan 9 is (well, when it was being designed)?
different definitions of "correct" carry different costs. having "correctness"
as a fundamental design principle (for new things - this is obviously
different if you're porting, rewriting, or emulating something) causes one
to ignore these tradeoffs in favor of whatever pre-concieved notions one
has about how something should work. this leads to systems or apps that
sacrifice one or more of the other three design goals - most often
simplicity - in favor of some ill-concieved notion of "correctness", which
quite likely a different notion of "correctness" than others have.

okay, rant off.
-α.



^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2001-10-11 15:54 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-10-09 21:44 [9fans] correcting old failures, and NJ vs MA forsyth
  -- strict thread matches above, loose matches on Subject: below --
2001-10-11 11:39 forsyth
2001-10-10 13:04 presotto
2001-10-11  9:10 ` Thomas Bushnell, BSG
2001-10-11 14:29   ` david presotto
2001-10-11 15:26     ` Boyd Roberts
2001-10-11 15:54       ` andrey mirtchovski
2001-10-09 21:51 bwc
2001-10-09 17:43 anothy
2001-10-10  8:56 ` Thomas Bushnell, BSG
2001-10-10  9:16   ` Boyd Roberts
2001-10-11  4:27   ` Alexander Viro
2001-10-11  9:11     ` Thomas Bushnell, BSG

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).