Re: Cross posting per request
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
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
-> > >-> 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
Larry Daffner | Linux: Unleash the workstation in your PC!
email@example.com / 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