[9fans] book chapters

[9fans] book chapters

[A. Baker]

Please! and thank you.
:-)


The sections of the Reeds and McIlroy paper are also
accessible
directly at

  http://cm.bell-labs.com/cm/cs/cstr.html

They are in .ps.gz format; I'll distill into pdf
if anyone wants.

	Dennis

=====
Boojum

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: [9fans] book chapters

[Dennis Ritchie]

Per Baker's request, the Reeds and McIlroy papers
on the IX system collected in CSTR 163 are available in
PDF at

  http://cm.bell-labs.com/cm/cs/cstr.html

	Dennis

Re: [9fans] book chapters

[Dennis Ritchie]

About the CSTR pages (including the McIlroy-Reeds
paper references):

It appears that at some time in the past, the
index page forked. The more visually attractive one,
done by Holzmann, is the one at

  http://cm.bell-labs.com/cm/cs/cstr.html

while the original is at

  http://cm.bell-labs.com/cm/cs/cstr/index.html

The latter is the one I updated, and the
one that refers to the PDF version of
the papers.  I'll try to unify them (there
might be other differences) and make
sure the references from other pages are
consistent.

Sorry for the confusion.

	Dennis

[9fans] book chapters

[A. Baker]

Dennis,

CSTR #163, M. Douglas McIlroy and J. A. Reeds, The IX
Multilevel Secure Operating System, Bell Labs, January
1992. It comes in several pieces:

163a, 163b, 163c, 163d, 163e, 163f, 163g, 163h, 163i.

[An interesting experiment in adding Orange-book style
security facilities to a research Unix system.].

All still list ps.gz?
(Maybe I'm just not holding my tongue just right).

Thanks for taking time to convert them, now I'll see
if I can understand them.
;-)

-----------------8<-----------------

Per Baker's request, the Reeds and McIlroy papers
on the IX system collected in CSTR 163 are available
in PDF at

  http://cm.bell-labs.com/cm/cs/cstr.html

 Dennis


=====
Boojum

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

Re: [9fans] book chapters

[David Presotto]

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

The x bit is still the same.  It means you can walk the directory.
However, with plan 9, to remove a file you must first walk to it.

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

From: Kenji Arisawa <arisawa@ar.aichi-u.ac.jp>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] book chapters
Date: Tue, 1 Jul 2003 20:27:32 +0900
Message-ID: <01D63448-ABB7-11D7-A48F-000393A941BC@ar.aichi-u.ac.jp>

Hello,

 >You already have that.  Make the directory only writable by the
 >students.  They can create files in it but can't remove them.

Thanks.
I have examined and found that is exactly what I wanted.
It seems the meaning of x bit for directory has been changed.
Man page "chmod" is old.

Kenji Arisawa

Re: [9fans] book chapters

[Kenji Arisawa]

Hello,

 >You already have that.  Make the directory only writable by the
 >students.  They can create files in it but can't remove them.

Thanks.
I have examined and found that is exactly what I wanted.
It seems the meaning of x bit for directory has been changed.
Man page "chmod" is old.

Kenji Arisawa

Re: [9fans] book chapters

[matt]

>
> Where I have problems with matt's solution breaking down is when you
> have worker_5 creating random sets of files in a traditional
> hierarchy.  Any subfolders he/she/it creates lose the rw permissions
> for the bosses group, and even with the sticky bit set for the group
> you lose those permissions the next level deep.


One of the problems we have is that I (in group wheel or as root) make
some file that someone else needs to be able to edit but often I forget
all about the permissions and it ends up "-rw-r--r-- matt wheel"
leaving the editors unable to edit it. And as they used to phone me at
the ungodly hours when I'm likely to be in bed (i.e. pre 10am) I needed
a solution

here's my inelegant solution from FreeBSD that does kind of the opposite
which is an interesting synergie because it uses wait_on which is a
program that gives access to the kqueue mentioned in another thread.

I don't know how big the queue can get but I have well over 500 files in
it across four directory trees

#!/usr/local/bin/rc

while () {
        chown -R www:www /www/document_root
        chmod -R g+w /www/document_root
        wait_on `{find /www/document_root}
        sleep 5
}


wait_on will return an index to which file has been changed/created for
more fine grained control

Re: [9fans] book chapters

[David Presotto]

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

You already have that.  Make the directory only writable by the
students.  They can create files in it but can't remove them.

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

From: Kenji Arisawa <arisawa@ar.aichi-u.ac.jp>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] book chapters
Date: Tue, 1 Jul 2003 08:16:37 +0900
Message-ID: <E5F74AD8-AB50-11D7-89E5-000393A941BC@ar.aichi-u.ac.jp>

Hello,

I have many students in my university.
In receiving reports from my students, Plan 9  doesn't have safe
solution.
I would be happy if Plan 9 has append only directory.
The concept is similar to that of append only file.

Kenji Arisawa

Re: [9fans] book chapters

[boyd, rounin]

> I would be happy if Plan 9 has append only directory.
> The concept is similar to that of append only file.

a blind directory?  gee that can't be hard.

Re: [9fans] book chapters

[Kenji Arisawa]

Hello,

I have many students in my university.
In receiving reports from my students, Plan 9  doesn't have safe
solution.
I would be happy if Plan 9 has append only directory.
The concept is similar to that of append only file.

Kenji Arisawa

Re: [9fans] book chapters

[rog]

> Where I have problems with matt's solution breaking down is when you
> have worker_5 creating random sets of files in a traditional hierarchy.
>   Any subfolders he/she/it creates lose the rw permissions for the
> bosses group, and even with the sticky bit set for the group you lose
> those permissions the next level deep.

actually, you're thinking in unix terms there.  plan 9 has different
semantics, such that the attributes of a directory *are* inherited.

% cd /tmp
% mkdir x
% ls -ld x
d-rwxr-xr-x M 9 rog rog 0 Jun 30 18:57 x
% chgrp sys x
% chmod 770 x
% ls -ld x
d-rwxrwx--- M 9 rog sys 0 Jun 30 18:57 x
% mkdir x/foo
% ls -ld x/foo
d-rwxrwx--- M 9 rog sys 0 Jun 30 18:57 x/foo
% > x/foo/bar
% ls -l x/foo
--rw-rw---- M 9 rog sys 0 Jun 30 18:57 x/foo/bar
%

> why not just a write a file server that mounts itself on / and implements
> whatever policy you'd like to dream up?  it would just implement the
> policy, whatever that might be, and use the underlying filesystem to
> store the bits.
>
> isn't it just protocol conversion?

the problem is that if parts of that filesystem are bound elsewhere in
the namespace, it's difficult to find out how to access the attributes
of a particular file without knowing where it comes from.

i've sometimes thought about a system where one might be able to
access filesystem-specific meta-information on a file through that
file itself.

> I was wondering if you could even implement the data and resources forks
> with 9p. The file would be somefile, with the actual data as
> somefile/data
> and resource fork under somefile/resource

the problem with this is that *all* files have to be stored this way,
or...  you have to try and open "file", then "file/data", and reading
the parent directory (the container of "file") doesn't tell you
anything useful about the attributes of the files it contains (you
have to ls */data).

NeXTstep (and presumably now macos X) does something like this for
applications, but it never seemed like a particularly elegant
solution, as it's not transparent to code that really doesn't care
about this kind of thing.

to wander away from reality a little:

one could add a 9p message, say "walkmeta", similar to
walk, but which provides a fid that corresponds to the
meta-information for a particular file.

there is precedent for using a fid for out of band information: the
fid created by attach and used by auth is just there to negotiate
protocol meta-information.

of course, what the conventions might be on such a fid is open to
argument: does it just look like a file which can be read and written,
or could it be a directory hierarchy (allowing meta-meta information,
perhaps?  :-]).

to follow this flight of fancy a little further, suppose that walkmeta
does provide a fid which can be further walked, and we add a new path
separator, say "#", such that evaluating
	x#y
means "walk to x in the normal namespace; then walkmeta to y".

then one could imagine a scenario similar to the following:

% ls -l x
--rw-rw---- M 9 rog sys 0 Jun 30 18:57 x
% cat 'x#acl'
rog
foo
bar
% echo add baz > 'x#acl'
echo: write error: unkown user
% cd 'x#.'
% ls
acl
% pwd
x#.
% ls -l
acl
fs
resource
% ls -l 'acl#.'
ls: acl#.: no metadata
%

just musing.

Re: [9fans] book chapters

[Richard C Bilson]

> From: Jack Johnson <fragment@nas.com>
>
> Where I have problems with matt's solution breaking down is when you
> have worker_5 creating random sets of files in a traditional hierarchy.
>   Any subfolders he/she/it creates lose the rw permissions for the
> bosses group, and even with the sticky bit set for the group you lose
> those permissions the next level deep.

Directories created in a group-sticky directory are group-sticky, at
least on the UNIX-esque systems that I use.

> The specific example I see at work is where you have (young) students
> who want or need direct assistance or supervision from their teachers,
> but the teachers don't want to make it drag-and-drop easy for the
> students to submit another's work as their own.  This often is as simple
> as helping a student locate the correct version of a document or
> assessing student work in-place without going through some sort of data
> or paper submission process.

We do exactly that here at Waterloo, using standard groups.  Every
student in CS 452 (for instance) has a cs452 directory owned by group
cs452; only the course staff are members of this group.  This works
well for things like e-mail help.  For the upper-year courses where
cheating is less of an issue, we can get students to submit simply by
throwing their stuff in this dir for us to peruse at our leisure.

A cron job sweeps the file system each night to fix the permissions on
class dirs for the benefit of those who delete or break things.

> Typical scenario:
> -> Disallow students to share/see each other's work
>    -> Allow staff to see work but not modify/delete
>      -> Allow administrators to read/modify/delete

This is almost what we get, although staff have modify/delete access.
If you don't trust your staff with student work I think you have bigger
problems than just your file system.

We have solutions for your other scenarios too, although I'm sure
they'd be much prettier with ACLs.

> Even in an ACL world things aren't perfect, but it does seem to allow
> one the flexibility of trying to accomodate the real world rather than
> attempting to manipulate human behavior to accomodate a file creation mask.

Although the flexibility generally comes at the price of increased
complexity.  Then again, human behavior is inherently complex, so it
might be an appropriate trade-off.

I don't really mean to come out against ACLs -- they're a good thing if
they allow users to create "groups" for themselves without
administrative intervention.  But if there existed a simple mechanism
to allow users to define and manage their own groups, I'd probably
never want them.

- Richard

Re: [9fans] book chapters

[boyd, rounin]

> Sorry, I left that out.

yeah, well i left out that i just see it as a matter of smashing 9P
requests/responses so that you get what you want.

there may be better ways, but it was the first one that sprang to mind.

Re: [9fans] book chapters

[ron minnich]

On Mon, 30 Jun 2003, ron minnich wrote:

> I was wondering if you could even implement the data and resources forks

for Macintosh file systems

> with 9p. The file would be somefile, with the actual data as
> somefile/data
> and resource fork under somefile/resource


Sorry, I left that out.

ron

Re: [9fans] book chapters

[ron minnich]

On Mon, 30 Jun 2003, boyd, rounin wrote:

> why not just a write a file server that mounts itself on / and implements
> whatever policy you'd like to dream up?  it would just implement the
> policy, whatever that might be, and use the underlying filesystem to
> store the bits.
>
> isn't it just protocol conversion?


I was wondering if you could even implement the data and resources forks
with 9p. The file would be somefile, with the actual data as
somefile/data
and resource fork under somefile/resource

ron

Re: [9fans] book chapters

[boyd, rounin]

why not just a write a file server that mounts itself on / and implements
whatever policy you'd like to dream up?  it would just implement the
policy, whatever that might be, and use the underlying filesystem to
store the bits.

isn't it just protocol conversion?

Re: [9fans] book chapters

[Jack Johnson]

ron minnich wrote:
> On Mon, 30 Jun 2003, matt wrote:
>>>For instance, you have a set of people whose files you want readable by
>>>their supervisors, but not by their peers.
>>maybe I'm missing something
>>-rw-rw----  1 worker_5  bosses  851968 Jun  3 17:11 daily.toil
> From my point of view this is not the same.
> Jack wants "anybody but my boss"

Nope, matt got it right, I'm just an idiot.

Actually, you both got it right, I just used two conflicting (and
probably unclear) examples.

"Everybody but Bob" where Bob is my boss (as opposed to my uncle), is a
pain to continually manage, as you said, but matt's example is correct
where worker_5 is Nameless_Worker_In_Cubicle_5 and bosses is the
fluctuating innumerable set of people who have authority over his work.

Where I have problems with matt's solution breaking down is when you
have worker_5 creating random sets of files in a traditional hierarchy.
  Any subfolders he/she/it creates lose the rw permissions for the
bosses group, and even with the sticky bit set for the group you lose
those permissions the next level deep.

The specific example I see at work is where you have (young) students
who want or need direct assistance or supervision from their teachers,
but the teachers don't want to make it drag-and-drop easy for the
students to submit another's work as their own.  This often is as simple
as helping a student locate the correct version of a document or
assessing student work in-place without going through some sort of data
or paper submission process.

Plus, without a super user per se in Plan 9, typical academic
institution style management slowly becomes increasingly complex:

(not to mention any Napsterized copyright infringements permanently
fossilized, or the variations in philosophy in the sharing of knowledge
vs. the stewardship of academic product :)

Typical scenario:
-> Disallow students to share/see each other's work
   -> Allow staff to see work but not modify/delete
     -> Allow administrators to read/modify/delete

Shared project space:
-> Allow staff/administrators to create folders
   -> Allow any to read/create/modify subfolders/files
     -> Allow owner or staff/administrators to read/modify/delete files

Project/assignment submission folders:
-> Allow students to write data but not read
   -> Disallow students to delete/overwrite previously written data
     -> Allow staff/administrators to read/delete files

...plus the lovely subsets of complex human interaction:

	- Jimmy and Sally are working on a project, Sally can't delete
	  Jimmy's file but can modify it, so she deletes its contents.

	- Billy wants to copy Wendy's work, but can't just take it.
	  She drops it in the shared filespace of another class for him
	  to retrieve.

Even in an ACL world things aren't perfect, but it does seem to allow
one the flexibility of trying to accomodate the real world rather than
attempting to manipulate human behavior to accomodate a file creation mask.

I realize Plan 9 wasn't necessarily designed for this environment (and
I'm not currently using it as such), but looking at the file permissions
model in general it's interesting to ponder what a good, alternative
model could be.

I was idly watching the first eight minutes of "Revolution OS" at
ifilm.com a while back

	http://www.ifilm.com/filmdetail?ifilmid=2419320

and chuckling at some comment (probably RMS) talking about using blank
passwords and password crackers in the early days to underline the idea
that security was sort of a misnomer, it's better to share, blah blah
blah, but it made me at least reconsider the whole notion of file
security.  I've always thought it was better to attempt to secure the
service, host or protocol rather than (increasingly common it seems)
relying on a secure network (using firewalls, VPN and IDS) to protect
your network, and now from that clip I sometimes think, OK, if you
assume your filespace is insecure, lousy or whatever, what can you do to
mitigate that?  Write-only like fossil, or some shared cryptographic
technique like SFS, maybe.  Private namespaces can go a long way to
making it kind of a non-issue depending on how you decide to handle the
shared filespace, but I think it's good to realize that there are a
dozen different, *decent* ways of looking at the problem.

-Jack

Re: [9fans] book chapters

[matt]

>
>
>worker_5 is "the 5 guys who are my coworkers today"
>

I meant worker_5 as one user

but my experience is minimal, I was just answering the question

Re: [9fans] book chapters

[ron minnich]

On Mon, 30 Jun 2003, matt wrote:

> >
> >
> >For instance, you have a set of people whose files you want readable by
> >their supervisors, but not by their peers.
> >
> >If you have a handy group solution for this, I'm all for enlightenment.
> >
> >-Jack
> >
> maybe I'm missing something
> -rw-rw----  1 worker_5  bosses  851968 Jun  3 17:11 daily.toil

 From my point of view this is not the same.

Jack wants "anybody but my boss"

worker_5 is "the 5 guys who are my coworkers today"

in the .com era you would have had to grow this group daily and the names
all change. In the .bom area you have to shrink it daily and the names
all change. Either way, the set of people "anybody but my boss" is not the
same as the set of "these guys who may change names or cardinality on a
daily basis"

worker_5 is a ton more work to keep set up correctly.

I used ACLs on Data General AOS and AOS/VS in 1981, and I have to say I
really got to like them. It's a very old idea but that doesn't mean a bad
idea.

ron

Re: [9fans] book chapters

[matt]

>
>
>For instance, you have a set of people whose files you want readable by
>their supervisors, but not by their peers.
>
>If you have a handy group solution for this, I'm all for enlightenment.
>
>-Jack
>
maybe I'm missing something
-rw-rw----  1 worker_5  bosses  851968 Jun  3 17:11 daily.toil

Re: [9fans] book chapters

[Jack Johnson]

On Fri, 2003-06-27 at 15:12, geoff@collyer.net wrote:
> I wonder if the people who rave about ACLs are actually attached to
> some aspect of a particular implementation

I'm not necessarily attached to ACLs, but the "everybody but Bob" case
is a standard scenario not easily handled by groups.

For instance, you have a set of people whose files you want readable by
their supervisors, but not by their peers.

If you have a handy group solution for this, I'm all for enlightenment.

-Jack

Re: [9fans] book chapters

[Dan Cross]

> There are 2^50000 - 1 such combinations (assuming one ignores the group
> with no one in it); a lot more than 50000!.

Watch which way you write your numbers, or more importantly when you
actually hit the Post button (hopefully not while you're still editting);
50000! is obviously a lot more than 2^50000 - 1 (though the latter is
the number of groups we're talking about).

	- Dan C.

Re: [9fans] book chapters

[Dan Cross]

> | I haven't, because groups serve nicely as ACLs,
>
> I disagree.  ACLs are things that any user can set on any of their files.
> That's the opposite of predefined groups stored on the BOFH's auth
> server.

I just want to point out that the ability to write user-level file
servers allows one to easily implement ACL's at that level.  It's
not convenient for, e.g., access to a fossil or some similar large
fileserver (think of the mess an ACL-enabled overlay would be), but
it works for other things.

> Do you really want to define groups for all 50000! combinations of users
> on PSUVM?  I'd rather just attach the access list to the file itself.

There are 2^50000 - 1 such combinations (assuming one ignores the group
with no one in it); a lot more than 50000!.  Besides, I thought PSUVM was
gone?  I'm out of touch with what's happening in Happy Valley, I guess.

> | I wonder if the people who rave about ACLs are actually attached to
> | some aspect of a particular implementation,
>
> The one in Primos (and Multics, I guess) was certainly beautiful,
> but it's the actual effect that I'm attached to.

I think the major benefit of ACL systems is that most implementations
don't require administrator intervention to set up or maintain them
(some do).

	- Dan C.

Re: [9fans] book chapters

[Scott Schwartz]

| I haven't, because groups serve nicely as ACLs,

I disagree.  ACLs are things that any user can set on any of their files.
That's the opposite of predefined groups stored on the BOFH's auth
server.

Do you really want to define groups for all 50000! combinations of users
on PSUVM?  I'd rather just attach the access list to the file itself.

| I wonder if the people who rave about ACLs are actually attached to
| some aspect of a particular implementation,

The one in Primos (and Multics, I guess) was certainly beautiful,
but it's the actual effect that I'm attached to.

Re: [9fans] book chapters

[Dennis Ritchie]

The sections of the Reeds and McIlroy paper are also accessible
directly at

  http://cm.bell-labs.com/cm/cs/cstr.html

They are in .ps.gz format; I'll distill into pdf
if anyone wants.

	Dennis

Re: [9fans] book chapters

[Geoff Collyer, geoff]

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

reeds & mcilroy, the ix system.  described in cstr 163:

This is really a collection of papers, and has been split into pieces:
to get all of them, say
	send 163a 163b 163c 163d 163e 163f 163g 163h 163i from research/cstr.

The IX Multilevel-Secure UNIX System
Contents:
163a Cover, 1 page
163b Abstract, 1 page
163c General description, 19 pages
163d Detailed specification of kernel behavior, 32 pages
163e Examples of use, 11 pages
163f Multilevel terminal, 3 pages
163g Secure network proposal, 8 pages
163h Glossary, 2 pages
163i Manual pages, 50 pages

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

From: "boyd, rounin" <boyd@insultant.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] book chapters
Date: Sat, 28 Jun 2003 01:43:25 +0200
Message-ID: <008d01c33d05$e6fbd360$d2944251@insultant.net>

ACLs?

did anybody read the 10th Ed paper (iirc) about bitmask security system for
unix?

jim reeds & i forget -- so simple and so powerful.

Re: [9fans] book chapters

[boyd, rounin]

ACLs?

did anybody read the 10th Ed paper (iirc) about bitmask security system for
unix?

jim reeds & i forget -- so simple and so powerful.

Re: [9fans] book chapters

[boyd, rounin]

ACLs -- they just had too much time on their hands, so why not build something
complex?

Re: [9fans] book chapters

[William Ahern]

On Fri, Jun 27, 2003 at 06:08:13PM -0400, Joel Salomon wrote:
> On Fri, 27 Jun 2003, pac wrote:
<snip>
> * Unix Assumes a Static File System
> I'm out of my depths here - anyone able to answer this?

Linux has this solution *wrong*. the DNOTIFY mechanism is accessed
thru fcntl(), and DNOTIFY uses signals. ugh!

I don't know if BSD _copied_ Linux. The free BSD's have kqueue(),
which is an interface that smoothes over file descriptors, signals,
process status and async-io context pointers. It includes a mechanism
to be notified on all file events. DNOTIFY on Linux only notifies
on directories (tho it will trigger a directory event when children
are modified).

However, Linux might get epoll(), which is supposed to be similar to
Solaris' /dev/poll, but a tad more general. It looks similar to kqueue(),
but not nearly as robust. (for better or worse)

I'm working on a shell utility, `watch', which outputs file event
notifications.

The code is ugly, because I ran into a lot of caveats figuring out
the semantics of kqueue vnode events.

	[http://www.25thandclement.com/~william/projects/watch.html]

I guess one tie-in to Plan 9 is that none of the BSD's (free ones, at least)
keep track of path names in their fs layer. Linux does, and in fact on Linux
/dev/pid/[fd] is analagous to fd2path(), except Linux tracks rename()s. Ted
Unangst, an OpenBSD developer, wrote me to say that he might hack OpenBSD to
keep some path info. I talked to him about it because if I'm monitoring a
large tree for events (say in a CMS), kqueue() forces me to open every last
file, while in Linux I need only open every directory; the issue being
descriptor table limits.

- Bill

Re: [9fans] book chapters

[Joel Salomon]

> > [...] has anyone found the lack of ACLs limiting?
>
> I haven't, because groups serve nicely as ACLs, especially since they
> take effect as soon as you tell the file server "users"

I'm sure this is in the manual somewhere, but is just any user allowed to
create a nonce group for some particular file?

 --Joel

Re: [9fans] book chapters

[Geoff Collyer, geoff]

No, you do have to have access to the file server console.  That is a
limitation.  However, I have access to my file server console, so
groups work as ACLs for me, at least.

Re: [9fans] book chapters

[Geoff Collyer, geoff]

> [...] has anyone found the lack of ACLs limiting?

I haven't, because groups serve nicely as ACLs, especially since they
take effect as soon as you tell the file server "users", unlike Unix,
where each process carries around a list of groups, so you essentially
have to login again to join another group, and there are usually
smallish limits (8 or 16) to the number of groups a process can be in
at once.

I wonder if the people who rave about ACLs are actually attached to
some aspect of a particular implementation, much like the people who
raved about Smalltalk or Lisp machines but were really just interested
in the window systems, not the languages (especially in the case of
Lisp).

Re: [9fans] book chapters

[Joel Salomon]

On Fri, 27 Jun 2003, pac wrote:

> folks!
> i'd like to hear your comments on these:
>
> http://catb.org/~esr/writings/taoup/html/plan9.html

like matt said.

> http://catb.org/~esr/writings/taoup/html/ch20s03.html
>
> regards,
> ++pac.

I may not be the best person to do this but...

* A Unix File is Just a Big Bag of Bytes
Plan 9 keeps this model, but avoids *some* of the problems esr points out
- I'll mention these is turn

* Unix Support For GUIs Is Weak.
Rio. Acme. It's not the "point and drool" of the macintosh, but is
internally consistent, convenient once you get used to it, and *very
well* integrated into the resr of the system, especially since many
"interesting" services (tcp/ip, mail, ftp, cd writing, etc.) implement
the file system interface

* File Deletion Is Forever
File Creation Is Forever :-)

* Unix Assumes a Static File System
I'm out of my depths here - anyone able to answer this?

* The Design of Job Control was Badly Botched
Rio. 'nuff said.

* The Unix API Doesn't Use Exceptions
http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&frame=right&th=7d07c12c4a19c45e&seekm=bf8367f8234d6dcb8847b6fd73d7f020%40plan9.escet.urjc.es
or search for "exception" on comp.os.plan9 where this subject has been
discused ad nauseum

* ioctl(2) and fcntl(2) are an embarrassment
That's why Plan9 doesn't have them!

* The Unix Security Model May Be Too Primitive
Plan 9 dosn't have a superuser account, but has anyone found the lack of
ACLs limiting?

* Unix has Too Many Different Kinds of Names
And he gives plan9 credit for unifying them. (but he mentions per-user
dynamically adjustable namespaces - I'm sure he was in error here, but
*is* there a way to simultaneously adjust the namespace of *all* my
processes? Perhaps with nemo's redirfs & badsrv underneath everything...)

* File Systems Might Be Considered Harmful
Then he goes on to say that "no major production operating system has
yet followed EROS's lead".

* Towards A Global Internet Address Space
Yup, we've got that too. In fact the model esr proposes is... Plan 9!

Did I leave anything out?

--Joel

Re: [9fans] book chapters

[matt]

pac wrote:

>folks!
>i'd like to hear your comments on these:
>


 > http://catb.org/~esr/writings/taoup/html/plan9.html

bland, looks like the writer has never actually *used* plan9 but has
read the papers and maybe installed it for a couple of hours

I know ftpfs seems to be the canonical example but Windows kind of does
that and Linux has a kernel level ftpfs program too (with an entry in fstab)

 > http://catb.org/~esr/writings/taoup/html/ch20s03.html

seems a bit unfocussed but I only program Unix in the shell

[9fans] book chapters

[pac]

folks!
i'd like to hear your comments on these:

http://catb.org/~esr/writings/taoup/html/plan9.html
http://catb.org/~esr/writings/taoup/html/ch20s03.html
(i cant agree with almost anything of the latter, however, imho)


regards,
++pac.