From Linux-standards-request@banjo.concert.net Sun Mar 8 04:15:42 1992
Return-Path: <Linux-standards-request@banjo.concert.net>
Received: from sun2.nsfnet-relay.ac.uk by banjo.concert.net with SMTP (PP)
id <10504-0@banjo.concert.net>; Sun, 8 Mar 1992 04:15:23 -0500
Received: from ukc.ac.uk by sun2.nsfnet-relay.ac.uk via JANET with NIFTP
id <15825-0@sun2.nsfnet-relay.ac.uk>; Sat, 7 Mar 1992 21:44:39 +0000
Received: from falcon by mercury.ukc.ac.uk with UKC POP3+ id aa01361;
7 Mar 92 21:45 GMT
Date: Sat, 07 Mar 92 21:40:33 +0000
From: Damiano Bolla <db1@ukc.ac.uk>
To: Linux-standards@banjo.concert.net
Subject: Small suggestion.... :-)
I spent a bit of time porting stuff this weekend. The various problems I
had suggested to me that there must be a way to make things easyer.
What I mean is that all people around is sayng: This is missing, this is
not standard SYSV, this has to be added.
To who should this be directed ?
To Linux ?
To the linux-standards ?
Who decides if /unix is /unix or /linux ?
It is useful to know it so you can count on something when you start coding !
Damiano
P.S. When will the tree structure be published ?
Can /unix be put in the tree structure ?
( I am against of reinventing new names for old things )
From Linux-standards-request@banjo.concert.net Sun Mar 8 10:58:07 1992
Return-Path: <Linux-standards-request@banjo.concert.net>
Received: from sumax.seattleu.edu by banjo.concert.net with SMTP (PP)
id <10703-0@banjo.concert.net>; Sun, 8 Mar 1992 10:57:48 -0500
Received: by sumax.seattleu.edu id AA02939 (5.65a/IDA-1.4.2
for Linux-standards@banjo.concert.net); Sun, 8 Mar 92 08:00:48 -0800
Date: Sun, 8 Mar 92 08:00:48 -0800
From: Chuck Boyer < boyer@sumax.seattleu.edu>
Message-Id: <9203081600.AA02939@sumax.seattleu.edu>
To: Linux-standards@banjo.concert.net, db1@ukc.ac.uk
Subject: Re: Small suggestion.... :-)
Linus himself should decide what basic tree structure is used in Linux
and let all others restructure according to their needs. When they publish
a 'port' of some program they should designate what tree structure they
use in a readme file.
chuck
From Linux-standards-request@banjo.concert.net Sun Mar 8 11:29:26 1992
Return-Path: <Linux-standards-request@banjo.concert.net>
Received: from kruuna.Helsinki.FI by banjo.concert.net with SMTP (PP)
id <10739-0@banjo.concert.net>; Sun, 8 Mar 1992 11:29:10 -0500
Received: by kruuna.helsinki.fi id AA22422 (5.65c/IDA-1.4.4
for Linux-standards@banjo.concert.net);
Sun, 8 Mar 1992 18:29:04 +0200
Date: Sun, 8 Mar 1992 18:29:04 +0200
From: Linus Benedict Torvalds <torvalds@cc.helsinki.fi>
Message-Id: <199203081629.AA22422@kruuna.helsinki.fi>
X-Mailer: Mail User's Shell (7.1.1 5/02/90)
To: Linux-standards@banjo.concert.net
Subject: Re: Small suggestion.... :-)
Chuck Boyer: "Re: Small suggestion.... :-)" (Mar 8, 8:00):
> Linus himself should decide what basic tree structure is used in Linux
> and let all others restructure according to their needs. When they publish
> a 'port' of some program they should designate what tree structure they
> use in a readme file.
Thanks for the vote of confidence, but I feel that this kind of standard
is something I need not decide: the last draft I saw looked nice, and as
long as it's simple and relatively standard, I'll go along. The
discussion on the directory structure seemed to be well enough thought
out, and all the points I ever wanted to say came up in mails by others.
There was a lot of "noise", but the result looked simple and workable.
I don't see why that couldn't be accepted as "final" - if there are
major problems we can always make changes later, but I wouldn't think
that would be needed.
I'm also more than happy enough to see that people are ready to engage
in this kind of discussion: I'm mostly interested in the kernel proper,
and I feel user-level (even if the user is root) things are better
decided by people who use the system. I'd rather just make the /really/
low-level things available: the kernel and the root-image. If the rest
of the distribution can be organized some other way (ABC-release), I'll
be very happy indeed.
Linus