Subject: Cross posting per request

From: Glenn Bily <[email-masked]>
Date: Sun, 01 Sep 1996 04:06:05 -0400

Folks,

These ideas are being posted here from net news per request.
Response is desired (even if it's not Debian priority)

1) Long awaited cleaning out of /usr/lib. In addition, categorizing
what is left into subdirectories.

A reasonable setup would be:

/usr/lib/elf  -- elf shared libs
/usr/lib/aout -- a.out shared libs
/usr/lib/elf/static -- for static elf libs
/usr/lib/aout/static -- for static a.out libs

Other development packages could retain their own /usr/lib
subdirectories or more preferably build mini etc lib bin trees in
/usr/<package name>, /ap/<package name>, /usr/X11R6/<X package name>
directory. Such as:

/usr/lib/elf/SVGA

or

/usr/SVGA/lib

Things like /usr/lib/perl, /usr/lib/terminfo, etc. need to be moved back
to /usr or /ap were it makes more sense.

What are the advantages this?

If someone chooses not to install development type packages then their
lib directories are not cluttered with libraries that make the directory
long and unmanagable.

It great reduces confusion on the part of users and possibly developer
as to what libraries are where.

2) Figuring out whether /usr/local is really being used properly (which
in my reading of FSSTND it isn't)
If /usr/local is really for local configuration then it shouldn't be in
/usr. /usr would typically be read-only mounted to a server in the cases
where /usr/local would be used. You cannot mount on read-only
partitions.
The person maintaining the system would just end up making /usr/local a
symbolic link.

On a debian system I am looking at has a /usr/local/lib/emacs which I
consider to be stranded. The system is not a complete installation so
there is no telling what other things are placed in /usr/local.

A reasonable solution to this is to move /usr/local to /

I would create 2 directories in /local:

/local/bin
/local/etc

/local/bin would be placed in the path and would represent binaries that
would search before /usr/bin for binaries.
/local/etc would be configuration files typically found /etc. The person
maintaining the server would put symbolic links into /local/etc in /etc
if they need it to be a local configuration.

3) Server and client installation distinctions. Possible avenue for easy 
minimal setup of X clients.

A person installing a Linux system should have the option of choosing
where they want the local machine to be the server or use a remote
server. There are still people out there who want to make use of machine
with 4 megs of ram. Running an X client on a 386 with 4 megs of ram and
a resonable video arrangement is not a bad thing and may be cost
effective in some environments.

4) Allowing controls of how many X sessions can be lauched would be
reasonable as well. X has the seemingly unknown feature of running
numerous client/servers. By adding :1, :2, etc as server arguments, you
can launch multiple X session possible on different servers from the
same console. This is extremely powerful to say the least.
It would be a bonus to be able to have a system admin control how many X
sessions are being launched at one console. This would require a small
adjustment in startx. In addition, it should not be required that the
user keep track of :1, :2, :3. This is another adjustment that would be
made in startx.

5) If a startup shell script for window managers should also be easy to
add.

I think that the user should have the possibility of specifying the
window manager at the startx prompt such as:

     startx fvwm
     startx openwin
     startx fvwm-95

And have resonable assurances that it will work.
An additional bonus to this would be allowing root to setup a simple
table to map the names to various shell scripts that would start the
window managers. This would allow for practically all contingencies and
complexities in getting that window manager started. This would also
allow the package maintainer to move the main window manager binaries
out of the path and out of harms way.

6) The wisdom of put the contents of /etc/X11/xdm and /etc/X11/xinit
where they are needs to be re-evaluated.
Most of the files in these directories are shell scripts not
configuration files.

7) The configuration programs for /etc/printcap and the user maintaince
utilities from Redhat need to be lifted :)

---

From: "Larry 'Daffy' Daffner" <[email-masked]>
Date: Mon, 02 Sep 1996 12:40:24 -0500

Glenn Bily writes:
-> 1) Long awaited cleaning out of /usr/lib. In addition, categorizing
-> what is left into subdirectories.

This has a number of problems, namely:
1) Would require changes to binutils for linux that don't have to
   happen on other systems.  Too much work for too little gain.
2) violates the FSSTND
3) violates what most experienced UNIX users would expect

-> Other development packages could retain their own /usr/lib
-> subdirectories or more preferably build mini etc lib bin trees in
-> /usr/<package name>, /ap/<package name>, /usr/X11R6/<X package name>
-> directory. Such as:

I'm sure you mean /opt, not /ap :). /opt/<package>, if a program uses
it, gets all the config files for that package installed under it.
It's a SysV.4 thing, but a draft exists for using it under Linux.

-> Things like /usr/lib/perl, /usr/lib/terminfo, etc. need to be moved back
-> to /usr or /ap were it makes more sense.

Except for the fact that this is nonstandard and likely to make it
harder for people to go out, get a package, and compile it and drop it
in, since it makes Linux non-compatible with every other UNIX system
in existence.

-> What are the advantages this?
-> 
-> If someone chooses not to install development type packages then their
-> lib directories are not cluttered with libraries that make the directory
-> long and unmanagable.

One person's long and unmanagable is another's easy-to-find :)
Besides, how is the dynamic loader supposed to find shared libs if we
scatter them all over creation?

-> It great reduces confusion on the part of users and possibly developer
-> as to what libraries are where.

Only people who have never used any other UNIX system.  I'm willing to
bet that most linux users either already have some UNIX experience or
are trying to become familiar with UNIX.  No need to confuse people by
being rather gratuitously different from other UNIXes.

-> 2) Figuring out whether /usr/local is really being used properly (which
-> in my reading of FSSTND it isn't)
-> If /usr/local is really for local configuration then it shouldn't be in
-> /usr. /usr would typically be read-only mounted to a server in the cases
-> where /usr/local would be used. You cannot mount on read-only
-> partitions.

I think you're misunderstanding here... /usr/local is for local use.
In other words, /usr/local is where you put all the programs that you
download and compile yourself.  They should probably be using config
files in /etc and runtime files in /var if necessary.  "local
configuration" just means that it's up to the machine's sysadmin as to
how they want to set up and use /usr/local.

-> 5) If a startup shell script for window managers should also be easy to
-> add.
-> 
-> I think that the user should have the possibility of specifying the
-> window manager at the startx prompt such as:
-> 
->      startx fvwm
->      startx openwin
->      startx fvwm-95
-> 

This is what user configuration files are for.  If you want a
different window manager , it's fairly easy to set up a .xsession and
have startx use it.

-> 6) The wisdom of put the contents of /etc/X11/xdm and /etc/X11/xinit
-> where they are needs to be re-evaluated.
-> Most of the files in these directories are shell scripts not
-> configuration files.

Actually, they kind of walk the fine line between configuration files
and shell scripts, since they are what you edit to configure X to do
what you want.  So they're probably OK there, especially since if they
get put in /usr, they get a lot harder to configure if, as you
suggest, /usr is read only :)

-> 7) The configuration programs for /etc/printcap and the user maintaince
-> utilities from Redhat need to be lifted :)

Don't know what you mean by user maintenance, but a printer
configuration utility would definitely be a good thing. Who wants to
write it? :)

-Larry

--
  Larry Daffner        |  Linux: Unleash the workstation in your PC!
  [email-masked] / http://web2.airmail.net/vizzie/
	The great tragedy of science, the slaying of a beautiful
	theory by an ugly fact.  --Thomas Henry Huxley

---

From: Glenn Bily <[email-masked]>
Date: Sun, 1 Sep 1996 20:29:06 -0400 (EDT)

> Actually to move the directories out of use /usr/lib would not violate
> FSSTND it would just be a looser interpretation.
> And I think that organization gains a lot. More newbies because experts
> faster if the file structure is easier to understand.

> 3) violates what most experienced UNIX users would expect

Experienced UNIX users would not expect anything :) The fact is that
there are so many flavors of Unix with somewhat different filesystem
organizations that I doubt this would mean much to a Unix expert. In
addition, the admin's life would only be made easier.

"Let's see where is perl stuff....of course: /usr/perl"

> >-> Things like /usr/lib/perl, /usr/lib/terminfo, etc. need to >be moved back
> >Except for the fact that this is nonstandard and likely to >make it
> harder for people to go out, get a package, and >compile it and drop it
> in, since it makes Linux >non-compatible with every other UNIX system
> >in existence.

How is this any different from now. I have never seen a Linux system
that you could just "drop" in a package unless it was planned.

> >-> If someone chooses not to install development type >packages then their
> >-> lib directories are not cluttered with libraries that make >the directory
> >-> long and unmanagable.

> >One person's long and unmanagable is another's >easy-to-find :)
> >Besides, how is the dynamic loader supposed to find shared >libs if we

How is this any different from 300 files in /usr/lib. ld.so finding the
libs is a detail. Adding lines ld.so.conf would fix most problems.

> >-> It great reduces confusion on the part of users and >possibly developer
> >Only people who have never used any other UNIX system.  >I'm willing to
> bet that most linux users either already have >some UNIX experience or
> are trying to become familiar >with UNIX.  No need to confuse people by
> being rather >gratuitously different from other UNIXes.

I spend a substantial time on IRC in the #linux and probably see 50
newbies go in and out per hour.

> >-> 2) Figuring out whether /usr/local is really being used >properly (which
> >-> If /usr/local is really for local configuration then it >shouldn't be in
> >-> /usr. /usr would typically be read-only mounted to a >server in the cases
> >-> where /usr/local would be used. You cannot mount on >read-only
> >-> partitions.
>
> >I think you're misunderstanding here... /usr/local is for local >use.
> >In other words, /usr/local is where you put all the programs >that you
> >download and compile yourself.  They should probably be >using config
> >configuration" just means that it's up to the machine's >sysadmin as to

Even in this case. /usr/local is not being use properly.

> >-> 5) If a startup shell script for window managers should >also be easy to
> >-> add.
> >-> 
> >-> I think that the user should have the possibility of >specifying the
> >different window manager , it's fairly easy to set up a >.xsession and
> have startx use it.

Here again you assume infinite wisdom :).

> >-> 6) The wisdom of put the contents of /etc/X11/xdm and >/etc/X11/xinit
> >-> Most of the files in these directories are shell scripts >not
> >-> configuration files.
>
> >Actually, they kind of walk the fine line between >configuration files
> >and shell scripts, since they are what you edit to configure >X to do
> >what you want.  So they're probably OK there, especially >since if they

Don't see why these files would have to be changed on a constant basis.
Individual users could easily do it in ~/.xsession. System admin could
remount /usr read-write when he does the changes. Negliably harder.

> >-> 7) The configuration programs for /etc/printcap and the >user maintaince
> >Don't know what you mean by user maintenance, but a >printer
> >configuration utility would definitely be a good thing. Who >wants to
> write it? :)

Already written. It has been mentioned to me that Redhat doesn't mind if
we use their stuff.

---

From: "Larry 'Daffy' Daffner" <[email-masked]>
Date: Mon, 02 Sep 1996 21:17:18 -0500

Glenn Bily writes:
-> > Glenn Bily writes:
-> > -> 1) Long awaited cleaning out of /usr/lib. In addition, categorizing
-> > -> what is left into subdirectories.
-> 
-> > This has a number of problems, namely:
-> > 1) Would require changes to binutils for linux that don't have to
-> >    happen on other systems.  Too much work for too little gain.
-> > 2) violates the FSSTND
-> 
-> Actually to move the directories out of use /usr/lib would not violate
-> FSSTND it would just be a looser interpretation.
-> And I think that organization gains a lot. More newbies because experts
-> faster if the file structure is easier to understand.

Umm, from the FSSTND:
    No large package (such as TeX and GNU Emacs) should use a direct
    subdirectory of /usr.  Instead, there should be a subdirectory
    within /usr/lib (or /usr/local/lib if it was installed completely
    locally) for the purpose.  An exception is made for the X Window
    System because of considerable precedent and widely-accepted
    practice. 

I didn't see anything in the FSSTND to directly recommend against
splitting up /usr/lib, but it makes life a LOT easier for the
sysadmin, the user and the linker to have all this stuff in one
place.  And believe it or not, /usr/lib looks like that on every UNIX
system I've used :)

-> > 3) violates what most experienced UNIX users would expect
-> 
-> Experienced UNIX users would not expect anything :) The fact is that
-> there are so many flavors of Unix with somewhat different filesystem
-> organizations that I doubt this would mean much to a Unix expert. In
-> addition, the admin's life would only be made easier.

I beg to differ here.  Granted, there are a lot of things which are
not standard from system to system, but there are a lot of things,
such as /usr/lib, which ARE pretty standard from UNIX to UNIX.  If we
move THOSE things around, People who think they know UNIX end up even
more frustrated. (At least, I know I would)

-> > >Except for the fact that this is nonstandard and likely to >make it
-> > harder for people to go out, get a package, and >compile it and drop it
-> > in, since it makes Linux >non-compatible with every other UNIX system
-> > >in existence.
-> 
-> How is this any different from now. I have never seen a Linux system
-> that you could just "drop" in a package unless it was planned.

On prepackaged systems, it may not matter as much, since you don't do
a lot of compilation of your own packages.  But certainly, as a
maintainer you do not want to go around editing 500 files to make sure
you change every instance of /usr/lib/foo to /usr/foo/lib. This is why
the FSSTND allows for things like a link from /usr/lib/sendmail ->
/usr/sbin/sendmail, /etc/utmp -> /var/run/utmp, and so forth.
Gratuitous changes should not be made unless you understand what
impact those changes have.  The FSSTND represents a lot of discussion
and debate by many experienced users.  Please, be aware of the spirit
AND the letter :)

-> > >One person's long and unmanagable is another's >easy-to-find :)
-> > >Besides, how is the dynamic loader supposed to find shared >libs if we
-> > >scatter them all over creation?
-> 
-> How is this any different from 300 files in /usr/lib. ld.so finding the
-> libs is a detail. Adding lines ld.so.conf would fix most problems.

Except for compilation.  ld doesn't use /etc/ld.so.cache, so that it
can be close to the 'standard' GNU ld.  H.J. Liu &co. have put a fair
amount of work into getting closer to the standard GNU stuff.  It just
doesn't make sense to start diverging again.

-> > >-> 5) If a startup shell script for window managers should >also be easy 
to
-> > >-> add.
-> > >-> 
-> > >-> I think that the user should have the possibility of >specifying the
-> > >-> window manager at the startx prompt such as:
-> > >-> 
-> > >->      startx fvwm
-> > >->      startx openwin
-> > >->      startx fvwm-95
-> > >-> 
-> >
-> > >This is what user configuration files are for.  If you want a
-> > >different window manager , it's fairly easy to set up a >.xsession and
-> > have startx use it.
-> 
-> Here again you assume infinite wisdom :).

A .xsession is a trivial thing to write, especially of a type close to
the default.  It's certainly not significantly more difficult than
figuring out what window managers are available.  Granted, I may be a
bit out of touch with the standard newbie, but if little things like
this are so difficult to find out, maybe there's a need for a more
comprehensive 'Linux new user' document, and more obvious pointers to
it.  Such a project certainly sounds like a more productive and less
complex effort than the massive changes that are outlined here, and
won't frustrate us oldbies that know where to look for things :)

-> > Don't know what you mean by user maintenance, but a printer
-> > configuration utility would definitely be a good thing. Who wants to
-> > write it? :)
-> 
-> Already written. It has been mentioned to me that Redhat doesn't mind if
-> we use their stuff.

Is the printer config stuff written in python, or in a more reasonable
language? :)  Python is huge, and isn't very common in the Real
World.  One of the biggest reasons why I didn't like RedHat was how my
system ground (8M memory at the time) ground to a halt when I started
X because of the size of the python interpreter.  In addition,
consider the disk space it takes up.  I don't think that we want to
require python to do printer configuration, when otherwise it goes
unused.

-Larry

--
  Larry Daffner        |  Linux: Unleash the workstation in your PC!
  [email-masked] / http://web2.airmail.net/vizzie/
"I believe every human has a finite number of heartbeats. I don't intend to
 waste any of mine running around doing exercises."  --Neil Armstrong

---

From: Glenn Bily <[email-masked]>
Date: Mon, 2 Sep 1996 01:08:02 -0400 (EDT)

Larry,

> >    System because of considerable precedent and widely-accepted

I firmly disagree with this point of the FSSTND. It is going to be
changed I'm told.
What has happened to /usr/lib should be obvious. :)

> >place.  And believe it or not, /usr/lib looks like that on every UNIX

Somehow I believe it.

> >more frustrated. (At least, I know I would)

Hopefully, seeing how unreasonable /usr/lib has become is convincing
enough to be sure
that changes are on the way. I welcome them personally. This is almost a
paradox.
"You change, people will be upset. You don't change, you system will
suffer". There is
a certain multi billion dollar software company who writes an OS that is locked
into this paradox.

> >On prepackaged systems, it may not matter as much,

> Hmm. I beg to differ. Just because one uses a packaging does not
> release the developers from being reasonable.

> >since you don't do
> >you change every instance of /usr/lib/foo to /usr/foo/lib. 

> >This is why

> Every instance of /etc/utmp should be eliminated if at all possible. I'm
> eager to phase out /etc/utmp. Same goes for /usr/lib/sendmail. This was
> the intention of FSSTND.

> >and debate by many experienced users.  Please, be aware of the spirit

I am aware. I'm also aware that a new phase of changes are necessary for
things to
improve. We are, after all, pushing for improvment.

> >doesn't make sense to start diverging again.

Simply done...change the specs file. 
I see absolutely no reason why GNU can't do its thing and Linux its thing.
I'm treading on thin ice here.... :)

> >it.

> These changes are necessary. Even documentation cannot make some
> things that are going on clear.

> >Such a project certainly sounds like a more productive and less

This is certainly productive. 

> >require python to do printer configuration, when otherwise it goes

It requires something possibly a degree worse. TCL/TK. But for a newbie
it might
be a life saver. There is also the possibility of compiling it.

---

From: Greg Hudson <[email-masked]>
Date: Tue, 03 Sep 1996 01:40:31 EDT

>> In addition, the admin's life would only be made easier.

> "Let's see where is perl stuff....of course: /usr/perl"

Of course it looks easier if you only ask one question.

"Where are the operating system binaries that should go in users'
paths?"

"Where are the standard C++ libraries?  Where is the termcap library?"

"If I want to export all architecture-independent read-only
application data via NFS to both Intel and Alpha machines running
Linux, what directories do I need to export?"

> How is this any different from 300 files in /usr/lib. ld.so finding
> the libs is a detail. Adding lines ld.so.conf would fix most
> problems.

/etc/ld.so.conf lives on client machines; libraries may live on a
server.  It's bad to force people to update configuration files on all
of their clients due to operating system changes.

>>> window manager at the startx prompt such as:

startx already takes command-line arguments.  "startx fvwm" already
has a meaning.

> Don't see why these files would have to be changed on a constant
> basis.  Individual users could easily do it in ~/.xsession. System
> admin could remount /usr read-write when he does the
> changes. Negliably harder.

It is not acceptable to put materials under /usr which you expect the
system administrator to need to change in order to configure their
system.  In particular, it means the system administrator can never
know what parts of their system are from the stock OS and what parts
are configuration information they may have modified.

Scripts make a poor configuration language, but if a script is
intended to be modified by the administrator, it belongs under /etc,
not /usr.  "The system admin could remount /usr read-write" misses the
point.

While I'm here, Bruce Pixar wrote:
> How about /usr/lib/i386-elf and /usr/lib/i386-aout?
> That lets you support multiple architectures more easily.

The assumption behind the FHS is that the filesystem is generally
architecture-dependent except for /usr/share and parts of /var (the
parts Thomas Bushnell wants to move into /com).  It makes no sense to
create architecture subdirectories for random things under /usr, or
you'll find tourself with architecture subdirectories of /usr/bin,
/usr/games, /usr/sbin, and so on.

If you're thinking about cross-compilation, then you haven't proposed
a complete solution (you need a place for include files and tools as
well), and the FSF has an existing standard (/usr/<bfd
name>/{bin,lib,include}) which is being used on Linux systems for
building a.out binaries on ELF machines.

---

From: "Jason K. Keimig" <[email-masked]>
Date: Tue, 3 Sep 1996 10:14:27 -0500 (CDT)

> out of the path and out of harms way.

  This should apply to xdm startup as well.  The current (default) setup for
Debian is parse through /etc/X11/window-managers and execute the first
window manager that it finds (and is installed).  In a larger environment
where you have users that prefer one window manager over another, a
convenient method we use here is to check the user's home directory for
the existance of a special file and start its corresponding WM.
  We could merge both the startx and xdm WM startups by simply modifying
the xinitrc and Xsession scripts to do the following:

 ...
 ... [Initialization stuff]
 ...
if (-e $HOME/.mwm_gui ) then
        set WINMGR = "mwm"
else if (-e $HOME/.twm_gui ) then
        set WINMGR = "twm"
else if (-e $HOME/.olvwm_gui ) then
        set WINMGR = "olvwm"
else if (-e $HOME/.fvwm_gui ) then
        set WINMGR = "fvwm"
else if (-e $HOME/.fvwm2_gui ) then
        set WINMGR = "fvwm2"
endif

# Start up a window manager
switch ($WINMGR)
case mwm:
        /usr/bin/X11/mwm
        breaksw
case twm:
        /usr/bin/X11/twm
        breaksw
case olvwm:
        /usr/bin/X11/olvwm
        breaksw
case fvwm:
        /usr/bin/X11/fvwm
        breaksw
case fvwm2:
        /usr/bin/X11/fvwm2
        breaksw
default: 
        echo "Unsupported window manager: $WINMGR"
        echo "Starting up fvwm as a fall back..."
        /usr/bin/X11/fvwm
        breaksw
endsw

  Note that this is a portion of a csh script, but gives the basic idea.
Not only would this give the _user_ the option of which WM to use, but
this would also be _very_ compatible with other flavors of UNIX as well.
Once you have common X startup files, you can just push the same scripts
to every (Unix) machine on your network (which sys-admins like very much).

-Jason Keimig
[email-masked]  http://www.tisl.ukans.edu/~jkeimig
-TiMCAN Project
-University of Kansas
=======================================================================
"I have two very rare photographs: one is a picture of Houdini locking
his keys in his car; the other is a rare photograph of Norman Rockwell
beating up a child."
                -- Steven Wright

---

From: [email-masked] (Bruce Perens)
Date: Tue, 3 Sep 96 14:42 PDT

It's unfortunate that the printer config stuff (and other stuff from
Red Hat) is written in TCL/TK. One thing we _don't_ assume is that the
user has X (or even a VGA card - it might be a serial console).

A shell/dialog solution would be much better.

	Thanks

	Bruce

---

From: Glenn Bily <[email-masked]>
Date: Mon, 2 Sep 1996 18:38:06 -0400 (EDT)

> Jason,

> window manager that it finds (and is >installed).  In a larger
> environment where you have users that prefer one window manager over
> another, a
> the existance of a special file and start its >corresponding WM. We
> could merge both the startx and xdm WM startups by simply modifying the
> xinitrc and >Xsession scripts to do the following:

Your idea is sound. I'm opposed to merging XDM and startx too much. XDM
and startx already share too much to some degree. We need to make
considerations that someone running XDM will not necessarily have
choices of window managers before the session begins. It would be a big
plus if Debian did do that :) (and I have a script that does that) 
Choices of XDM "security" procedures that may want to be added by root
should be considered too. There may be things done on a XDM login that
shouldn't be done with startx. 
As a technicality:
I'd also trade use of /usr/bin/X11 for /usr/X11R6/bin. /usr/bin/X11 is a
symbolic link for backward compatibility.

---

From: [email-masked] (David Engel)
Date: Wed, 4 Sep 1996 11:04:06 -0500 (CDT)

> A shell/dialog solution would be much better.

There is a curses-based version of Tk, but I don't have any idea of
how well it works.

David
-- 
David Engel                        Optical Data Systems, Inc.
[email-masked]                      1101 E. Arapaho Road
(214) 234-6400                     Richardson, TX  75081

---

From: Dominik Kubla <[email-masked]>
Date: Wed, 04 Sep 1996 18:24:23 +0200

> plus if Debian did do that :) (and I have a script that does that) 

There is a tool in the X11 contrib which allows you exactly that, it's
called xsession.  In addition you can preprocess the WM configuration
either with CPP or M4 (yes, i know fvwm* can do this, but on the other
hand twm and mwm can not!) and start applications from the menu bar, leaving
you the mouse buttons free for more important stuff than launching apps.

Cheers,
  Dominik
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Visit the FAN SITE of the WORLD LEAGUE OF AMERICAN FOOTBALL:
<A HREF="http://www.uni-mainz.de/~kubla/WLAF/Welcome.html>HTTP</A> or
<A HREF="file:/afs/zdv.uni-mainz.de/homes/UFO/kubla/public_html/WLAF/Welcome.ht
ml">AFS file</A> access.

---

From: Philippe Troin <[email-masked]>
Date: Wed, 04 Sep 1996 11:49:52 -0700

> There is a curses-based version of Tk, but I don't have any idea of

Do you know where we could find this thing ? Might be interesting...

Phil.

---

From: David Engel <[email-masked]>
Date: Wed, 4 Sep 1996 18:00:03 -0500 (CDT)

> Do you know where we could find this thing ? Might be interesting...

It's at
ftp.neosoft.com:/languages/tcl/alcatel/potpourri/ctk-4.0.tar.gz.  I
already took a look at it and, although it works, it's barely usable,
IMO.

David

---

From: "Larry 'Daffy' Daffner" <[email-masked]>
Date: Wed, 04 Sep 1996 19:46:14 -0500

Greg Hudson writes:
-> >> In addition, the admin's life would only be made easier.
-> 
-> > "Let's see where is perl stuff....of course: /usr/perl"
-> 
-> Of course it looks easier if you only ask one question.
-> 
-> "Where are the operating system binaries that should go in users'
-> paths?"
-> 
-> "Where are the standard C++ libraries?  Where is the termcap library?"
-> 

[ Rest of Greg's excellent explanation deleted ]

I couldn't have said it better myself. :)

This is the most compelling argument for the status quo.  With the
suggested changes, mapping a program to it's associated files gets
slightly easier, but mapping a type of file or specific file to it's
location in the filesystem gets much harder.  It's probably one of the
reasons why /opt hasn't caught on too well with 3rd party
platforms. (Well, that and support for multiple platforms :)

-Larry

--
  Larry Daffner        |  Linux: Unleash the workstation in your PC!
  [email-masked] / http://web2.airmail.net/vizzie/
Whenever you find yourself on the side of the majority, it is time to
pause and reflect." - Mark Twain

---

From: Glenn Bily <[email-masked]>
Date: Wed, 4 Sep 1996 00:06:46 -0400 (EDT)

Larry,

They intend to implement /opt as a major mount point. They also plan to
make /usr/local a very dangerous place to play. :)
I hope that Debian will make a policy of staying out of /usr/local.

This is way it is shaping up for each application:

Beside the binary in /usr/bin or /bin.
There will be a /usr/libexec subdirectory for each application.
There will be a /usr/share subdirectory for each application. They
specify the contents of this directory to be "architecture independent
data".
/var is in a serious state of flux and I think that this will go to pot
like /usr/lib is now. About half of it is currently local and half
currently non-local.
They seem to be refusing to fix ridiculous things like /usr/games and
putting /dev/MAKEDEV where it belongs in /sbin.

Well actually the FHS people are pretty set on this

---

From: Glenn Bily <[email-masked]>
Date: Wed, 4 Sep 1996 00:34:03 -0400 (EDT)

Folks,

[This should spark a debate :)]

What is the fine line between a library such as libc.so.5, libm.so.5 or
libcurses.a and just a compiled object file?

           --Glenn

---

From: [email-masked] (Bruce Perens)
Date: Wed, 4 Sep 96 22:40 PDT

From: Glenn Bily <[email-masked]>
> libcurses.a and just a compiled object file?

If I had my druthers I'd clean lots of stuff like that up.
The task is a lot more complicated than that, because you
are working with other people. You need to:

    + Figure out how to get from point A to point B in gentle steps that
      don't break _everything_. Otherwise lots of people will dig in their
      heels on this sort of change.

    + Cultivate patience. You can't get stuff like this done without the
      patience to watch it happening for years.

    + Establish your own credibility with the people who help make the
      decisions (like the FHS group) by presenting intelligent dialogue
      on other topics for months. Once you've done that, it's easier to
      get them to listen to argument on your own pet projects.

    + Lead only where the others will follow.

    + Detach yourself emotionally from the issue. I can't overstress this.
      I'd be a hopeless basket case if I let myself get emotional over
      decisions made for Debian. Just ask the developers what it was like
      when I last got that way.

You can achieve the goal of getting things organized in a more sensible
manner. You can not achieve it tomorrow, unless you go off and make your
own system (which I would not advise because of the leading where people
will follow thing).

	Thanks

	Bruce

---

From: Daniel Quinlan <[email-masked]>
Date: Wed, 4 Sep 1996 22:42:42 -0700

> libcurses.a and just a compiled object file?

Please do not try to "spark debate" (troll) on the FHS discussion
mailing list.  I do not appreciate it and I doubt that anyone else
does either.

You have already clearly demonstrated that you have not read the
entire FHS draft and that you have some serious technical gaps in your
understanding of Linux.  I appreciate your desire to get involved, but
I think you need to become more acquainted with the issues at hand
before make a fool of yourself.

I would appreciate it if members of the Debian User's mailing list
would not Cc messages to the FHS mailing list (formerly FSSTND).
Thank you.

Dan

---

From: "Theodore Y. Ts'o" <[email-masked]>
Date: Thu, 5 Sep 1996 13:04:38 -0400

Glenn, 

In addition to Bruce's good advice for working with people, I'll add

    + Understand that people may have different goals than you, and that
      their goals may be just as valid as what you have on your agenda.

This is part of why it's good to participate in a group for a long time
before trying barge in with suggestions which you *know* must be better
than what we've spent years working on.  You may come to understand that
in fact this is a very tightly constrained problem, where issues like
backwards compatibility, compatibility with other Unix systems,
technical requirements of system administrators, and aesthetic
cleanliness of the design all compete to come to a compromise solution.

Flip suggestions like "Let's break it :)" betray a lack of understanding
of the many concerns that drive this process.  It says, "I don't think
your concerns are important" and that's not a way to win friends and
influence people.

							- Ted