Newsgroups: comp.os.linux.development
Path: gmd.de!xlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!uunet!
portal!imurdock
From: imurd...@shell.portal.com (Ian A Murdock)
Subject: Debian: a brief status report
Message-ID: <CCF9Hu.6M7@unix.portal.com>
Keywords: ebian
Sender: n...@unix.portal.com
Nntp-Posting-Host: jobe.unix.portal.com
Organization: Portal Communications Company -- 408/973-9111 (voice)
408/973-8091 (data)
Date: Fri, 27 Aug 1993 14:27:28 GMT
Lines: 54
First of all, I'd like to thank everyone who dropped me a line with comments
and suggestions. I'm sorry that I didn't have time to respond to them all, but
there was simply no way for me to do so and make progress on the Debian
release at the same time :)
I'm going to keep this brief, but I just wanted everyone to know how things
were going. Sorry I've been so quiet for the last few weeks, but I've been
extremely busy (to say the least). First of all, two requests:
1) I have a generic IDE controller and drive, so if there are kernel
patches for your SCSI board that are not yet a part of the
standard kernel then please let me know. Please tell me the
*exact* name of the package and it's *exact* location. I will
patch the bootdisk kernel with all available SCSI patches
to ensure that as few people as possible have trouble with the
initial install. I don't keep up with SCSI developments so
please help me out. :)
2) Would everyone prefer a distribution in 'package' format (i.e.
base.tgz, bin.tgz, etc.) or 'disk' format (i.e. disk1, disk2,
etc.)? The latter 'disk' format would consist of Linux disk
images that would need to be either rawritten (under DOS)
or dd'ed (under UNIX). I would personally prefer the latter,
but if everyone else likes the 'package' format then I will
use it instead. The 'series' format, ala SLS and Slackware,
will not be used. Please let me know what you would prefer.
I would like to point out here that I would like this distribution to develop
in the same way as much of the rest of Linux has developed. In other words,
I want everyone to *contribute* to this effort and not simply use something
that one man or team has put together. This distribution will be improved
by the Linux community as a whole, and I will simply serve as the
coordinator of the effort.
For this reason, the first release of the Debian distribution will only be a
TESTING release. It will be available to everyone who wants it (the exact
location will be disclosed when an official announcement is made on c.o.l.a.),
but I strongly recommend that anyone who does not want to be involved in its
initial development wait until Debian has left the TESTING phase. Please
remember that I started this release from scratch and that thus far only a
few others have seen it. I want to get some input and make some changes
before I deem the distribution suitable for the 'end-user'.
Anyway, that's all for now. Keep an eye out for an official announcement on
c.o.l.a. at the beginning of next week. Please drop me a line if you're
interested in 'joining the team'.
See you on c.o.l.a.,
Ian
--
Ian Murdock Internet: imurd...@shell.portal.com
The Linux Warehouse
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!europa.eng.gtefsd.com!
uunet!montego!not-for-mail
From: l...@umcc.umcc.umich.edu (Leon Dent)
Newsgroups: comp.os.linux.development
Subject: Re: Debian: a brief status report
Date: 27 Aug 1993 16:22:04 -0400
Organization: UMCC, Ann Arbor, MI, USA
Lines: 10
Message-ID: <25lqdc$2fv@umcc.umcc.umich.edu>
References: <CCF9Hu.6M7@unix.portal.com> <1993Aug27.171626.13689@mksol.dseg.ti.com>
NNTP-Posting-Host: umcc.umcc.umich.edu
I'd prefer a package layout. This would allow a smaller base install and
let people decide whatever else they want. One day there may be a standard
way to upload binaries such that any uploaded binary may be installed
as a package.
(What is the derivation of the name Debian?)
Leon Dent
l...@umcc.umich.edu
Path: gmd.de!xlink.net!howland.reston.ans.net!agate!library.ucla.edu!
news.mic.ucla.edu!unixg.ubc.ca!rflab.ee.ubc.ca!jmorriso
From: jmorr...@rflab.ee.ubc.ca (John Paul Morrison)
Newsgroups: comp.os.linux.development
Subject: Linux Standards (was Re: Debian: a brief status report)
Date: 1 Sep 1993 23:11:16 GMT
Organization: UBC Electrical Engineering - Radio Lab
Lines: 115
Message-ID: <263a6k$28c@iskut.ucs.ubc.ca>
References: <CCF9Hu.6M7@unix.portal.com>
<1993Aug27.171626.13689@mksol.dseg.ti.com> <25lqdc$2fv@umcc.umcc.umich.edu>
NNTP-Posting-Host: rflab.ee.ubc.ca
In article <25lqdc$...@umcc.umcc.umich.edu>,
Leon Dent <l...@umcc.umcc.umich.edu> wrote:
>I'd prefer a package layout. This would allow a smaller base install and
>let people decide whatever else they want. One day there may be a standard
>way to upload binaries such that any uploaded binary may be installed
>as a package.
I'm interested in having some public discussion(or mailing list) about
the layout, the versions, etc. The outcome of the discussions would
be a "recommended" layout for Linux, so we don't have every package
making company/person coming up with their own esoteric and incompatible
system for naming things, organizing directories etc.
The newbies just want to get a system up and running, but many people
have previous experience and preferences about things should be done.
Ie, some people want Linux to be more like SunOS, or BSD or SysV or
whatever. I'm not trying to start a religious war, but I think reasonable
system organization would evolve if it were discussed openly a bit.
People can do what they like with their own machines, but I think some
public persuasion would help package developers create better packages.
I think SLS was a good way to bootstrap Linux, but because Peter
cobbled it together with his own personal preferences and idiosyncrasies,
SLS is cluttered, incompatible and hard to maintain.
SLS suffered from having duplicates, outdated versions, and *unknown*
versions of programs. If we discuss things publicly, and print up
a list of recommendations, then hopefully SLS, Slackware, MCC, Debian
will tag along. Maybe we can take a straw poll on a few programs, and
then try to stick to those; then the recommended list can say:
"it's a good idea to use Sys V init, version x.y.z". or "use getty_ps
version x.y, and put it in /etc". The package makers simply do not
have the experience to create an optimal distribution if they try to
go it alone. A recommend list should tell people: which program to use
(and whether to use it), what version, where to install it, any
important tips for compiling it properly; possible substitutes, ie
if someone is a UUCP only site, or an Internet site or whatever
If I can start things off (man hier I guess):
/dev
has the dust finally settled here?
(not trying to pick at old wounds, but it is a good idea
to get it right)
/bin
what should go here?
should it be shared lib linked files just to get the system
up? keep in mind that some people use (and probably most SHOULD)
a small root partition.
is a /sbin a better idea?
/etc
basic system files...
passwd... can we agree to use shadow passwds too?
(some people are multiuser systems on real, security conscious
networks. shadow passwds make sense, and it isnt a hassle to
the single user, no network system )
net2 seems to be the way to go. net-2 is organized like SysV
shall we use /etc/rd.d/ for rc files? net-2 and SysV init
like this setup.
"traditional" binaries, ie dont cram everything into /usr/bin
just because it is executable
/usr/etc
a seperate directory, not a symlink. probably on another filesystem
I hated the SLS /etc/inet setup
login, write, who: poeigl (possibly getty as well)
init, reboot, shutdown, halt, last, wall: SysV init 2.4
getty, uugetty: gettyps
networking: net-2 (if you are pl10 or higher). setup in /etc and /usr/etc.
patched for shadow passwds where needed.
man: man 1.1, patched for gzip instead of compress; -mandoc
/usr/bin: most Gnu things...binutils, shellutils, text etc...
/usr/ucb: make any sense? (I dont really care for it, but I'd go along
with it)
>
>(What is the derivation of the name Debian?)
instead of Linux/Pro, how about the Linux Standard Distribution (LSD)?
(not a distribution package, just the semi-official, right way to roll
you own distribution).
For the way Linux ought to be organized and maintained; if anyone is stuck
with an old SLS system, they can just read what the collective net experts
more-or-less agree is a good way to do things, and they can compile
the right programs and put them in the right place. I dont think
SLS or Slackware or MCC will every get it right so that upgrading is
painless and trivial. LSD guidelines would let people maintain their
own systems.
Maybe people can post the hier man page for a few popular Unixes, and we
can debate a bit about how to organize things. For particular versions
of a program, people can give their testimonials etc. (any package I've
recommended, is because it worked, it was flexible, and I could find
sources for it. the point isn't to say: my getty can beat up your getty!
what works and what can be managed easily is what matters)>
(I won't change the newsgroups, but maybe this should be followed up
in another newsgroup if appropriate)
>
>Leon Dent
>l...@umcc.umich.edu
>
--
___________________________________________________________________________
John Paul Morrison |
University of British Columbia, Canada | Hey hey!! Ho ho!!
Electrical Engineering | Tax & spend liberals
jmorr...@rflab.ee.ubc.ca VE7JPM | have got to go!!
________________________________________|__________________________________
Path: gmd.de!newsserver.jvnc.net!yale.edu!xlink.net!sol.ctr.columbia.edu!usc!
elroy.jpl.nasa.gov!news.aero.org!aerospace.aero.org!elkins
From: elk...@aerospace.aero.org (Michael Elkins)
Newsgroups: comp.os.linux.development
Subject: Re: Linux Standards (was Re: Debian: a brief status report)
Date: 1 Sep 1993 23:31:19 GMT
Organization: The Aerospace Corporation
Lines: 67
Message-ID: <263bc7$mcg@news.aero.org>
References: <CCF9Hu.6M7@unix.portal.com>
<1993Aug27.171626.13689@mksol.dseg.ti.com> <25lqdc$2fv@umcc.umcc.umich.edu>
<263a6k$28c@iskut.ucs.ubc.ca>
NNTP-Posting-Host: zzyzx.aero.org
In article <263a6k$...@iskut.ucs.ubc.ca>,
John Paul Morrison <jmorr...@rflab.ee.ubc.ca> wrote:
>/bin
> what should go here?
> should it be shared lib linked files just to get the system
> up? keep in mind that some people use (and probably most SHOULD)
> a small root partition.
> is a /sbin a better idea?
I personally vote for /sbin and /usr/sbin. But I'd like to see them be
something that is optional. Some people are of the opinion that a rather
large subset of progs should be statically linked, others are not (me being
one; i have no static links on my system)
>/etc
> basic system files...
> passwd... can we agree to use shadow passwds too?
> (some people are multiuser systems on real, security conscious
> networks. shadow passwds make sense, and it isnt a hassle to
> the single user, no network system )
I'd agree, once someone actually claims that everything I want to be running
will work ok (and be secure) under the shadow stuff. Right now there is an
awful lot of stuff in the SLS dist that needs recompiling (dunno about
slackware, but I assume the same for it)
> net2 seems to be the way to go. net-2 is organized like SysV
> shall we use /etc/rd.d/ for rc files? net-2 and SysV init
> like this setup.
yup.
> "traditional" binaries, ie dont cram everything into /usr/bin
> just because it is executable
>
>/usr/etc
> a seperate directory, not a symlink. probably on another filesystem
> I hated the SLS /etc/inet setup
>
>
>login, write, who: poeigl (possibly getty as well)
>init, reboot, shutdown, halt, last, wall: SysV init 2.4
>getty, uugetty: gettyps
>networking: net-2 (if you are pl10 or higher). setup in /etc and /usr/etc.
> patched for shadow passwds where needed.
I agree with this.
>man: man 1.1, patched for gzip instead of compress; -mandoc
>/usr/bin: most Gnu things...binutils, shellutils, text etc...
I'd argue that the shell, bin, and textutils should all be in /bin. Things
like ls are good to have when going single user and you have a separated /usr
filesystem... ;-)
>/usr/ucb: make any sense? (I dont really care for it, but I'd go along
> with it)
I suppose that would be ok, but I don't really think that it's necessary. Of
course, if you did, you'd have problems deciding which progs went in there
(should we put vi in there?, etc)
me
michael elkins elk...@aero.org
computer science and technology subdivision
aerospace corporation tel: +1 310-336-8040
el segundo, ca fax: +1 310-336-4402
Path: gmd.de!xlink.net!sol.ctr.columbia.edu!usc!elroy.jpl.nasa.gov!swrinde!
gatech!europa.eng.gtefsd.com!uunet!news2.uunet.ca!spool.mu.edu!news.clark.edu!
netnews.nwnet.net!bach.seattleu.edu!sumax.seattleu.edu!not-for-mail
From: aeh...@sumax.seattleu.edu (OUTTA HERE!)
Newsgroups: comp.os.linux.development
Subject: Re: Linux Standards (was Re: Debian: a brief status report)
Date: 1 Sep 1993 19:01:56 -0700
Organization: Lasciate ogni speranza, voi que entrate.
Lines: 46
Message-ID: <263k6kINNd31@sumax.seattleu.edu>
References: <25lqdc$2fv@umcc.umcc.umich.edu> <263a6k$28c@iskut.ucs.ubc.ca>
<263bc7$mcg@news.aero.org>
NNTP-Posting-Host: sumax.seattleu.edu
No flames, just honest questions:
In article <263bc7$...@news.aero.org> elk...@aerospace.aero.org (Michael Elkins)
writes:
>In article <263a6k$...@iskut.ucs.ubc.ca>,
>John Paul Morrison <jmorr...@rflab.ee.ubc.ca> wrote:
>>/bin
>I personally vote for /sbin and /usr/sbin. But I'd like to see them be
>something that is optional. Some people are of the opinion that a rather
>large subset of progs should be statically linked, others are not (me being
>one; i have no static links on my system)
^^^yes, the fewer of them damned links the better!
Why sbin rather than bin? (Personally, I prefer /bin -- most systems I've
used don't have an /sbin... what's the history behind /sbin??)
>>/usr/etc
>> a seperate directory, not a symlink. probably on another filesystem
>> I hated the SLS /etc/inet setup
>>
>>login, write, who: poeigl (possibly getty as well)
>>init, reboot, shutdown, halt, last, wall: SysV init 2.4
>>getty, uugetty: gettyps
>>networking: net-2 (if you are pl10 or higher). setup in /etc and /usr/etc.
>> patched for shadow passwds where needed.
What's the difference between /etc and /usr/etc? Similar to the
concept behind /bin and /usr/bin.
>>/usr/ucb: make any sense? (I dont really care for it, but I'd go along
>> with it)
What's /usr/ucb for?
On some systems I've seen stuff scattered between /usr/bin and /usr/ucb
with no real distinction.
I'm of the thought that we should keep things simple.
Maybe just /etc, /bin, and /usr/bin and maybe axe /usr/etc and /usr/ucb??
I'm fully behind a standard setup for Linux. I'd even like to help!
It drives me crazy to have some programs expect /bin/lpr and others
expect /usr/bin/lpr... so as a consequence I need to either hunt down
the darn source and recompile, or ln -s lpr ../usr/bin/lpr!
-Anthony
Newsgroups: comp.os.linux.development
Path: gmd.de!xlink.net!howland.reston.ans.net!vixen.cso.uiuc.edu!sdd.hp.com!
portal!imurdock
From: imurd...@shell.portal.com (Ian A Murdock)
Subject: Re: Linux Standards (was Re: Debian: a brief status report)
Message-ID: <CCpJDu.Jz0@unix.portal.com>
Sender: n...@unix.portal.com
Nntp-Posting-Host: jobe.unix.portal.com
Organization: Portal Communications Company -- 408/973-9111 (voice)
408/973-8091 (data)
References: <263a6k$28c@iskut.ucs.ubc.ca> <263bc7$mcg@news.aero.org>
<263k6kINNd31@sumax.seattleu.edu>
Date: Thu, 2 Sep 1993 03:37:05 GMT
Lines: 76
In article <263k6kINN...@sumax.seattleu.edu> aeh...@sumax.seattleu.edu (OUTTA HERE!)
writes:
>No flames, just honest questions:
>
>In article <263bc7$...@news.aero.org> elk...@aerospace.aero.org (Michael Elkins)
writes:
>>In article <263a6k$...@iskut.ucs.ubc.ca>,
>>John Paul Morrison <jmorr...@rflab.ee.ubc.ca> wrote:
>>>/bin
>>I personally vote for /sbin and /usr/sbin. But I'd like to see them be
>>something that is optional. Some people are of the opinion that a rather
>>large subset of progs should be statically linked, others are not (me being
>>one; i have no static links on my system)
> ^^^yes, the fewer of them damned links the better!
>
>Why sbin rather than bin? (Personally, I prefer /bin -- most systems I've
>used don't have an /sbin... what's the history behind /sbin??)
/sbin holds statically linked binaries, traditionally. One or two statically
linked binaries are justifiable (Debian contains a statically linked ln,
as I seem to have gotten into the habit of hosing my links in /lib on a
fairly regular basis :). In my opinion, any more than a few is a waste of
disk space.
>
>>>/usr/etc
>>> a seperate directory, not a symlink. probably on another filesystem
>>> I hated the SLS /etc/inet setup
>>>
>>>login, write, who: poeigl (possibly getty as well)
>>>init, reboot, shutdown, halt, last, wall: SysV init 2.4
>>>getty, uugetty: gettyps
>>>networking: net-2 (if you are pl10 or higher). setup in /etc and /usr/etc.
>>> patched for shadow passwds where needed.
>
>What's the difference between /etc and /usr/etc? Similar to the
>concept behind /bin and /usr/bin.
According to the SAG by Lars Wirzenius, /usr/etc "typically contains only
configuration files for programs in /usr/bin, not system-wide things."
I like /usr/etc because it helps /etc stay uncluttered.
>
>>>/usr/ucb: make any sense? (I dont really care for it, but I'd go along
>>> with it)
>
>What's /usr/ucb for?
>On some systems I've seen stuff scattered between /usr/bin and /usr/ucb
>with no real distinction.
/usr/ucb contains binaries from the Berkeley distribution, I believe: vi,
more, etc. etc. etc. I don't see much purpose in a Linux /usr/ucb, though.
Correct me if I'm wrong about the above.
>
>I'm of the thought that we should keep things simple.
>Maybe just /etc, /bin, and /usr/bin and maybe axe /usr/etc and /usr/ucb??
>
>I'm fully behind a standard setup for Linux. I'd even like to help!
Well, I don't know if there'll ever be a "standard" setup for Linux, but
I'm trying to start assembling people who are interested in becoming a
part of the Debian project. Anyone interested may join the DEBIAN channel
of the linux-activists mailing list at niksula.hut.fi. Please note that
I just created it so there's not too much activity yet :) I sent something
to c.o.l.a. a few days ago, but it hasn't appeared yet. So, let's get
some discussion going, guys and girls! Don't be shy! :)
One announcement for all of you who are interested in the status of Debian:
I'm going out-of-town for the weekend and I'll be giving Debian to a few
locals to install and kick around for the weekend. If all goes well it will
be available soon after I return. (Hmm, doesn't that sounds familiar... :)
Ian
--
Ian Murdock Internet: imurd...@shell.portal.com
The Linux Warehouse
Path: gmd.de!newsserver.jvnc.net!yale.edu!cmcl2!RM303.ECON.NYU.EDU!sens
From: s...@FASECON.ECON.NYU.EDU (Sunando Sen)
Newsgroups: comp.os.linux.development
Subject: Re: Linux Standards (was Re: Debian: a brief status report)
Date: Thu, 2 Sep 1993 04:40:30 GMT
Organization: New York University
Lines: 34
Message-ID: <sens.133.746944830@FASECON.ECON.NYU.EDU>
References: <CCF9Hu.6M7@unix.portal.com> <1993Aug27.171626.13689@mksol.dseg.ti.com>
<25lqdc$2fv@umcc.umcc.umich.edu> <263a6k$28c@iskut.ucs.ubc.ca>
NNTP-Posting-Host: rm303.econ.nyu.edu
All I can say is that it would be _extremely_ useful to have a standard
setup. As things stand now, if one wants to move from the SLS to the MCC
distribution (say, after hearing all those horror stories recently), one has
to pretty much reformat the disk and start from scratch, because the
distributions are so incompatible with each other. With more and more
distributions looming in the horizon, this is clearly getting out of hand.
I believe there is no reason why we cannot reach a consensus about file
system layout, _if_ the heavyweights (you know who you are, I hope) lend
their support. After all, things like the kernel and the libraries are
being developed in a systematic way.
That being said, however, consensus will not easy to achieve. The three
or four varieties of Unix that I have seen all seem to have differnt ideas.
For example, under AIX, /bin is linked to /usr/bin and /lib to /usr/lib.
One could take this as an effective end to questions like `does this go in
/bin or /usr/bin?' I noticed that SLS attempts to resolve the same question
by placing some of the binaries in both. At least AIX's method wastes less
space.
About /sbin, I think it is totally unncessary. There is a program called
`sash' (stands for `secure administration shell', or something like that)
that has a number of useful builtin commands: such as cp, ls, rm, mv, ln,
eventar and compress. Given a statically linked copy of this program, one
does not need anything else for emergencies. There is also another program
called `chlib' for safely upgrading shared libraries. For additional
insurance, one can statically link init, mount, sync. But then, these
programs have to remain in their standard place, which is probably /etc.
On the other hand, Linux is moving towards binary compatibility with
SVR4. If commercial SVR4 programs expect certain binaries to live in
certain places, this will pretty much force the issue. We will have no
choice but to adopt whatever is the SVR4 convention.
Sunando Sen
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!agate!library.ucla.edu!
news.mic.ucla.edu!unixg.ubc.ca!rflab.ee.ubc.ca!jmorriso
From: jmorr...@rflab.ee.ubc.ca (John Paul Morrison)
Newsgroups: comp.os.linux.development
Subject: Re: Linux Standards (was Re: Debian: a brief status report)
Date: 2 Sep 1993 05:53:41 GMT
Organization: UBC Electrical Engineering - Radio Lab
Lines: 158
Message-ID: <2641p5$3o0@iskut.ucs.ubc.ca>
References: <25lqdc$2fv@umcc.umcc.umich.edu> <263a6k$28c@iskut.ucs.ubc.ca>
<263bc7$mcg@news.aero.org> <263k6kINNd31@sumax.seattleu.edu>
NNTP-Posting-Host: rflab.ee.ubc.ca
In article <263k6kINN...@sumax.seattleu.edu>,
OUTTA HERE! <aeh...@sumax.seattleu.edu> wrote:
:No flames, just honest questions:
:
:In article <263bc7$...@news.aero.org> elk...@aerospace.aero.org (Michael Elkins)
writes:
:>In article <263a6k$...@iskut.ucs.ubc.ca>,
:>John Paul Morrison <jmorr...@rflab.ee.ubc.ca> wrote:
:>>/bin
:>I personally vote for /sbin and /usr/sbin. But I'd like to see them be
:>something that is optional. Some people are of the opinion that a rather
:>large subset of progs should be statically linked, others are not (me being
:>one; i have no static links on my system)
: ^^^yes, the fewer of them damned links the better!
:
:Why sbin rather than bin? (Personally, I prefer /bin -- most systems I've
:used don't have an /sbin... what's the history behind /sbin??)
I know Suns have a /sbin. The point is to keep a minimal set of binaries
around to make it easier if (when) the system gets hosed.
:
:What's the difference between /etc and /usr/etc? Similar to the
:concept behind /bin and /usr/bin.
/bin and /etc typically have a minimal set of binaries and config
files needed to mount the /usr, /var, /tmp and /home file systems, and
possibly NFS filesystems. If you are a single user system, or you have
a small disk, the distinction between /bin and /usr/bin probably don't
seem relevant.
Once filesystems are mounted, you wont notice the difference, but it is
important at the physical level. I keep a smallish root partition. That
way if / gets hosed, damage is limited. Except for /etc/passwd and
a few easily preserved files, the root partition should be expendable,
ie it can be easily restored. I think the root partion can be more likely
to get thrashed, so if individual partitions are easy to restore, that's
a Good Thing. Isolating things on different filesystems can help contain
damage, and make things a bit easier to restore.
If you have your filesystems on the same drive, then a drive failure
would trash everything, no matter how you partition it. but
partitioning can still help isolate damage caused by bugs (not
gauranteed to, but it can help). If you care about your users, you
can leave /home unmounted if you are doing anything risky.
At the very least, I think it is a good idea to have:
/ root, 5-20 megs, possibly higher depending on your drive(s)
/everything_else
I would go further still:
/ root, small drive or partition
/tmp small drive or partition
/var medium to large, depending on whether you spool news, uucp, mail etc.
/usr large drive or partion, or NFS
/home depends on how many users you plan to support. you can always have:
/home/mystuff....the good fast SCSI 2 drive
/home/friends....mount point for another drive, or symlink
/home/losers.....people you sort of have to give an account;
(old, MFM drive, need whack to start spinning :-)
Linux doesn't have quotas, and if you don't use extfs 2, you can't reserve
space for root. Isolating things on partitions can prevent the system
from gettting crippled by a runaway user process, or a pig in /home.
(obviously, you would have to keep world writable files out of important
filesystems). If waycoolfs alpha 0.9 is released, you can easily try it out,
by nuking /tmp. Or you can use a slower, but sturdy filesystem for /home,
but use a faster, possibly buggy filesystem, on a diectory that isn't
critical. An ideal distribution package would be so complete and easy to
install, that you would never have to back up /usr or /var, because
the whole deal was already on the distribution disks or tapes. That
makes it easier to back up a few files in /etc, and backup /home regularly.
(that can still be done on a filesystem, but havin seperate filesystems
tends to enforce it, so system stuff and user stuff dont get mixed).
That's the general idea. Once things are mounted, it doesnt matter.
but is makes sense for administration. Our Suns are organized
along those lines, depending on whether they are diskless, servers etc.
It's basic stuff, and it would be a nice idea for package developers
to offer to install that way. If good practices go into the installation
and distribution packages, that makes life easier for all.
:>>/usr/ucb: make any sense? (I dont really care for it, but I'd go along
:>> with it)
:
:What's /usr/ucb for?
:On some systems I've seen stuff scattered between /usr/bin and /usr/ucb
:with no real distinction.
typically, the Berkeley things go in ucb. Some people wanted compatibility
with SysV and berekely, so there might be a different ls in ucb. A lot
of Berekely networking things go in /usr/ucb, at least in SunOS.
:
:I'm of the thought that we should keep things simple.
:Maybe just /etc, /bin, and /usr/bin and maybe axe /usr/etc and /usr/ucb??
This was the SLS approach. There's the tradion based argument; that isn't
very convincing, except that it can make life easier, since other UNIX
people will know what you are talking about. For a practical reason, it
makes some things easier, for the reasons I described above (multiple
disks, etc).
:
:I'm fully behind a standard setup for Linux. I'd even like to help!
:
:It drives me crazy to have some programs expect /bin/lpr and others
:expect /usr/bin/lpr... so as a consequence I need to either hunt down
:the darn source and recompile, or ln -s lpr ../usr/bin/lpr!
most programs should use the path anyway. If the various Linux distributions
had some common guidelines to follow, then installed systems wouldnt have
that problem. Some problems are caused by bugs; otehr problems are caused
by improper configuration, becuase people arent sure what to do.
Example: is Linux BSD? SysV? POSIX? If people don't know the answer, then
stuff may be compiled wrong. init will make entries in /etc/utmp, but
so will some gettys. this just buggers up "last". If login sends logs
to the wrong place, then finger won't show correct login info for users.
If you put BSD manpages in with other man pages, your man pages wont
look right when formatted. The list goes on; when everyone does
their own thing, you have to be an expert to sort out and track down
all the bugs. When installation packages get it wrong, then total newbies
get confused, and people waste time, or get poor results. The FAQ
doesnt have enough scope to answer: where to install things, what version
of a program to install, where to install it, etc. If we can spec things
out then SLS, Slackware, Debian will (probably) follow. The merits of
each package can be based on how well it does the job, not in what or
where it installs things.
I saw a few things in the Linux-activists list. Once channel seems to
be secret and by invitation only (possibly a good thing); and I'm not
sure if others are active. Since the "Debian" packages looks like it
is trying to do things correctly from scratch, we can discuss it on
the Debian channel. If people don't mind, I think it would be nice to
discuss it out in the open. (unfortunately, at the risk of starting
religious wars; if we can reference things to published standards, or
at least to how some existing systems do it, maybe that can cut out
some nonsense. Above all, guidelines should be based on software that
is available, being maintained by someone, and that works correctly in
at least 90% of all cases, save the 10% of cases for some other
pacakge or way of configuring. So a guideline would recommend one
package over another based on those criteria). Perhaps we can setup an
automated "best of" poll for a few contentious issues, which would
resolve how things ought to be arranged, which package to use in
preference to another, etc.
:
:-Anthony
:
--
___________________________________________________________________________
John Paul Morrison |
University of British Columbia, Canada | Hey hey!! Ho ho!!
Electrical Engineering | Tax & spend liberals
jmorr...@rflab.ee.ubc.ca VE7JPM | have got to go!!
________________________________________|__________________________________
Path: gmd.de!xlink.net!howland.reston.ans.net!sol.ctr.columbia.edu!news.kei.com!
bloom-beacon.mit.edu!senator-bedfellow.mit.edu!senator-bedfellow.mit.edu!not-for-mail
From: ty...@athena.mit.edu (Theodore Ts'o)
Newsgroups: comp.os.linux.development
Subject: Re: Linux Standards (was Re: Debian: a brief status report)
Date: 2 Sep 1993 13:51:33 -0400
Organization: The Internet
Lines: 14
Sender: dae...@athena.mit.edu
Distribution: world
Message-ID: <265br5$n9o@senator-bedfellow.MIT.EDU>
Reply-To: ty...@athena.mit.edu (Theodore Ts'o)
NNTP-Posting-Host: senator-bedfellow.mit.edu
From: s...@FASECON.ECON.NYU.EDU (Sunando Sen)
Date: 2 Sep 93 04:40:30 GMT
About /sbin, I think it is totally unncessary. There is a program called
`sash' (stands for `secure administration shell', or something like that)
that has a number of useful builtin commands: such as cp, ls, rm, mv, ln,
eventar and compress.
/sbin is for more than just statically linked copies of cp, ls, rm, etc.
In the new BSD filesystem standard, /sbin is where all of the executable
files that used to be in /etc are moved to. So getty, init, fsck,
login, etc., would all be moved into /sbin.
- Ted
Newsgroups: comp.os.linux.development
Path: gmd.de!newsserver.jvnc.net!yale.edu!xlink.net!howland.reston.ans.net!
usenet.ins.cwru.edu!magnus.acs.ohio-state.edu!csn!boulder.parcplace.com!imp
From: i...@boulder.parcplace.com (Warner Losh)
Subject: Re: Linux Standards (was Re: Debian: a brief status report)
Message-ID: <CCqI5H.GB5@boulder.parcplace.com>
Sender: n...@boulder.parcplace.com
Organization: ParcPlace Boulder
References: <25lqdc$2fv@umcc.umcc.umich.edu> <263a6k$28c@iskut.ucs.ubc.ca>
<263bc7$mcg@news.aero.org>
Date: Thu, 2 Sep 1993 16:08:04 GMT
Lines: 43
>> passwd... can we agree to use shadow passwds too?
>> (some people are multiuser systems on real, security conscious
>> networks. shadow passwds make sense, and it isnt a hassle to
>> the single user, no network system )
Until shadow breaks old, non-recompiled programs in a fail-safe way,
it is totally useless, as it potentially allows root access (put a '*'
in the password field to find old, broken prorgams faster).
>I'd agree, once someone actually claims that everything I want to be running
>will work ok (and be secure) under the shadow stuff. Right now there is an
>awful lot of stuff in the SLS dist that needs recompiling (dunno about
>slackware, but I assume the same for it)
I know that rshd needs something done to it to make it secure with
shadow passwords.
We need to have /etc/rc files that will properly check file systems
before mounting them.
We need to have some way of UPDATING a system w/o wiping the old
configuration.
We need to at least set the damn time zone information from the
install script.
Net-2 configuration needs to be a little smoother. Don't get me
wrong, I think net-2 is wonderful. The config is not the easiest in
the world, however and some attention should be paid to it after the
other functionality bugs are fixed.
I think there should be some way to configure in various packages a
little more easily and elegantly than SLS does now.
I think that there should be some set of statically linked utilities
that will save your butt in case of fires. However, they could easily
be like the BSD boot disk where the programs aren't ment to used by
humans and have little error checking.
Warner
--
Warner Losh i...@boulder.parcplace.COM ParcPlace Boulder
I've almost finished my brute force solution to subtlety.
Newsgroups: comp.os.linux.development
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!usc!elroy.jpl.nasa.gov!
swrinde!cs.utexas.edu!uunet!mnemosyne.cs.du.edu!nyx!zevans
From: zev...@nyx.cs.du.edu (Zack Evans)
Subject: Re: Linux Standards (was Re: Debian: a brief status report)
Message-ID: <1993Sep2.223434.28575@mnemosyne.cs.du.edu>
Sender: use...@mnemosyne.cs.du.edu (netnews admin account)
Organization: Nyx, The Spirit Of The Night @ U. of Denver Math/CS dept.
References: <25lqdc$2fv@umcc.umcc.umich.edu> <263bc7$mcg@news.aero.org>
<263k6kINNd31@sumax.seattleu.edu> <2641p5$3o0@iskut.ucs.ubc.ca>
Date: Thu, 2 Sep 93 22:34:34 GMT
Lines: 70
[apologies in advance for incorrect attribution]
In article <2641p5$...@iskut.ucs.ubc.ca>,
John Paul Morrison <jmorr...@rflab.ee.ubc.ca> wrote: (jpm)
In article <263k6kINN...@sumax.seattleu.edu>,
OUTTA HERE! <aeh...@sumax.seattleu.edu> wrote: (ae)
In article <263bc7$...@news.aero.org> elk...@aerospace.aero.org (Michael Elkins)
writes: (me)
me> I personally vote for /sbin and /usr/sbin. But I'd like to see them be
me> something that is optional. Some people are of the opinion that a rather
me> large subset of progs should be statically linked, others are not (me being
me> one; i have no static links on my system)
Nor do I; since it's only me using the system, I can afford to rely on a
boot floppy. It strikes me that there will be a _lot_ of people in this
situation.
ah> Why sbin rather than bin? (Personally, I prefer /bin -- most systems I've
ah> used don't have an /sbin... what's the history behind /sbin??)
On Suns, the 's' is for statically linked I think, in other words if /lib dies
you still have enough binaries that work, to sort out the mess. Exactly what
constitutes 'enough' is one of those religious things...
jpm>Linux doesn't have quotas, and if you don't use extfs 2, you can't reserve
jpm>space for root.
I think the quota patches are heading for a revival and will be in PL13, or at
least available for PL13. And if you don't use ext2fs, why not?
jpm>typically, the Berkeley things go in ucb. Some people wanted compatibility
jpm>with SysV and berekely, so there might be a different ls in ucb. A lot
jpm>of Berekely networking things go in /usr/ucb, at least in SunOS.
Sun's 5bin is bloody confusing if you ask me - if you are going to have a dual
universe have one, instead of this bizarre kludge.
jpm>If you put BSD manpages in with other man pages, your man pages wont
jpm>look right when formatted.
I noticed that this morning :( Is there anything I can do about it? Does anyone
have a super duper BSD to Linux man page conversion perl script?
jpm>their own thing, you have to be an expert to sort out and track down
jpm>all the bugs.
I decided to have a good sort out and make sure I had the latest version of
everything, last week; I am still doing it now. It's great fun getting
everything to work with everything else :)
jpm>I saw a few things in the Linux-activists list. Once channel seems to
jpm>be secret and by invitation only (possibly a good thing); and I'm not
jpm>sure if others are active.
Is it? As far as I know the Standards discussion channel is as open as any of
the others... still, I won't give it's full name here just in case I am wrong
:) Someone on that channel is about to publish a draft standard as well...
As an aside, I now _do_ have an sbin, where s is for superuser not static -
everything that normal users won't use is in there - I don't have any binaries
in /etc now.
Zack
--
Zack Evans pyc...@cent1.lancs.ac.uk or zev...@nyx.cs.du.edu
UNIX was not designed to stop its users from doing stupid things,
as that would also stop them from doing clever things.
Newsgroups: comp.os.linux.development
From: ja...@purplet.demon.co.uk (Mike Jagdis)
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!usc!cs.utexas.edu!
uunet!pipex!bnr.co.uk!demon!purplet!jaggy
Subject: Re: Linux Standards (was Re: Debian: a brief status report)
Organization: FidoNet node 2:252/305 - The Purple Tentacle, Reading
Date: Fri, 3 Sep 1993 21:50:00 +0000
Message-ID: <343.2C89A885@purplet.demon.co.uk>
Sender: use...@demon.co.uk
Lines: 19
* In message <1993Sep2.223434.28...@mnemosyne.cs.du.edu>, Zack Evans said:
ZE> jpm>If you put BSD manpages in with other man pages, your man pages wont
ZE> jpm>look right when formatted.
ZE> I noticed that this morning :( Is there anything I can do
ZE> about it? Does anyone
ZE> have a super duper BSD to Linux man page conversion perl
ZE> script?
If you are using groff then you'll find that -mandoc works for more things
than -man.
man and xman generally invoke 'nroff -man'. With groff nroff is a shell
script. I changed mine to trap a -man argument and replace it with a -mandoc
before calling groff itself. It's that simple :-).
Mike
Newsgroups: comp.os.linux.development
From: ja...@purplet.demon.co.uk (Mike Jagdis)
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!agate!doc.ic.ac.uk!
uknet!pipex!bnr.co.uk!demon!purplet!jaggy
Subject: Re: Linux Standards (was Re: Debian: a brief status report)
Organization: FidoNet node 2:252/305 - The Purple Tentacle, Reading
Date: Fri, 3 Sep 1993 21:44:00 +0000
Message-ID: <342.2C89A885@purplet.demon.co.uk>
Sender: use...@demon.co.uk
Lines: 66
* In message <CCqI5H....@boulder.parcplace.com>, Warner Losh said:
WL> Until shadow breaks old, non-recompiled programs in a fail-safe way,
WL> it is totally useless, as it potentially allows root access (put a '*'
WL> in the password field to find old, broken prorgams faster).
Nonononono. Shadow *does* lock out the password field of /etc/passwd. SLS
might not but that's just SLS...
WL> >I'd agree, once someone actually claims that everything I want to be
WL> >running will work ok (and be secure) under the shadow stuff.
It's easy to fix. There are plenty of examples. I've released patches for
xdm, xlock, many of the network daemons. If "distributors" can't manage to
grep for crypt and copy code from half a dozen examples they should have
immediately to hand you've more to worry about than you think :-).
Is there a definitive list of things you want?
WL> I know that rshd needs something done to it to make it secure with
WL> shadow passwords.
That's about the only one of the net-2 programs I missed then. I didn't
think rshd did it's own password checks. I thought it just invoked
/bin/login if the incoming wasn't trusted according to hosts.equiv or
rhosts. The fix is trivial if you have the source :-).
WL> We need to have /etc/rc files that will properly check file
WL> systems before mounting them.
I have this. In fact everyone should have it. Simple inspection of the
bootutils should allow it to be added to just about any setup.
WL> We need to have some way of UPDATING a system w/o wiping the
WL> old configuration.
I have this.
WL> We need to at least set the damn time zone information from
WL> the install script.
I have this.
WL> Net-2 configuration needs to be a little smoother.
I have this too.
WL> I think there should be some way to configure in various packages a
WL> little more easily and elegantly than SLS does now.
And this. It's all in the Purple Distribution. I would put it on an archive
site but I'm on the end of a modem connection on which I pay the bills. So
far exactly two (2) people have shown an interest in it appearing on an
archive site so it hardly seems worth my while.
WL> I think that there should be some set of statically linked
WL> utilities that will save your butt in case of fires.
Now that's where we disagree :-). Use a boot disk. Even if you let LILO boot
a hard disk kernel but point it at a root floppy with root=/dev/fd0. Get in
the habit of thinking three times before doing *anything* as root. If you
have to recover it treat it as a learning experience. Make sure it has
impact :-).
Mike
Newsgroups: comp.os.linux.development
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!math.ohio-state.edu!
magnus.acs.ohio-state.edu!csn!boulder.parcplace.com!imp
From: i...@boulder.parcplace.com (Warner Losh)
Subject: Re: Linux Standards (was Re: Debian: a brief status report)
Message-ID: <CD5Lz7.HBB@boulder.parcplace.com>
Sender: n...@boulder.parcplace.com
Organization: ParcPlace Boulder
References: <342.2C89A885@purplet.demon.co.uk>
Date: Fri, 10 Sep 1993 19:54:43 GMT
Lines: 51
In article <342.2C89A...@purplet.demon.co.uk>
ja...@purplet.demon.co.uk (Mike Jagdis) writes:
>That's about the only one of the net-2 programs I missed then. I didn't
>think rshd did it's own password checks. I thought it just invoked
>/bin/login if the incoming wasn't trusted according to hosts.equiv or
>rhosts. The fix is trivial if you have the source :-).
It checks to see if there is a password, and if there isn't, it
goes ahead and approves the command.
>WL> We need to have /etc/rc files that will properly check file
>WL> systems before mounting them.
>
>I have this. In fact everyone should have it. Simple inspection of the
>bootutils should allow it to be added to just about any setup.
Where can I get them? I've hacked my /etc/rc files to do the right
thing for my system, but it needs to be default.
>And this. It's all in the Purple Distribution. I would put it on an archive
>site but I'm on the end of a modem connection on which I pay the bills. So
>far exactly two (2) people have shown an interest in it appearing on an
>archive site so it hardly seems worth my while.
Please share this with the rest of the world. It does no good to say
"I've got this great distribution, but I won't distribute it. If it
is as good as you say it is, then it might be worth it. Heck, if you
send me disks/tape, I'll be happy to give it a spin and upload it to
whatever archives you'd like.
>WL> I think that there should be some set of statically linked
>WL> utilities that will save your butt in case of fires.
>
>Now that's where we disagree :-). Use a boot disk. Even if you let LILO boot
>a hard disk kernel but point it at a root floppy with root=/dev/fd0. Get in
>the habit of thinking three times before doing *anything* as root. If you
>have to recover it treat it as a learning experience. Make sure it has
>impact :-).
I've been a Unix user for at least 7 years, and have had root access
for most of that time. Things still go wrong, and you do need a few,
choice staticlly linked aps to keep your system sane should something
go wrong. 50k of disk space should be ample for all the things that
I'd like to see (sync, which is one disk block, a simple staticlly
linked ln. mv, cp etc would be nice, but aren't needed).
Warner
--
Warner Losh i...@boulder.parcplace.COM ParcPlace Boulder
I've almost finished my brute force solution to subtlety.
Newsgroups: comp.os.linux.development
From: ja...@purplet.demon.co.uk (Mike Jagdis)
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!europa.eng.gtefsd.com!
uunet!mcsun!uknet!warwick!qmw-dcs!qmw!demon!purplet!jaggy
Subject: Re: Linux Standards (was Re: Debian: a brief status report)
Organization: FidoNet node 2:252/305 - The Purple Tentacle, Reading
Date: Mon, 13 Sep 1993 22:32:00 +0000
Message-ID: <351.2C963616@purplet.demon.co.uk>
Sender: use...@demon.co.uk
Lines: 39
* In message <CD5Lz7....@boulder.parcplace.com>, Warner Losh said:
[rshd...]
WL> It checks to see if there is a password, and if there isn't,
WL> it goes ahead and approves the command.
Ah! That would explain why it escaped the crypt() hunt :-). Does this imply
that there is only a problem with those broken versions of SLS which,
apprently, leave the password field blank rather than locking it in
/etc/passwd?
WL> >And this. It's all in the Purple Distribution. I would put it on an
WL> archive
WL> >site but I'm on the end of a modem connection on which I pay the bills.
WL> So
WL> >far exactly two (2) people have shown an interest in it appearing on an
WL> >archive site so it hardly seems worth my while.
WL> Please share this with the rest of the world. It does no good to say
WL> "I've got this great distribution, but I won't distribute
WL> it.
I never said that. In fact I *do* distribute it, particularly within the UK
FidoNet community.
WL> If it is as good as you say it is, then it might be worth it.
I never said it was particularly good either :-). If having all these
(essential) "features" that people keep mentioning make it "good" so be it.
I know where the bugs are though :-).
This distribution thread seems to have an excessively high
manager-to-worker ratio, however since I've now had almost a whole *half
dozen* expressions of interest from the Internet side I'll see about
uploading it somewhere. Or at least some of it...
Mike