Re: Cross posting per request
Larry,
> >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 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. :)
> >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 :)
Somehow I believe it.
> >-> > 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)
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.
> >-> > >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,
> Hmm. I beg to differ. Just because one uses a packaging does not
> release the developers from being reasonable.
> >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.
> 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.
> >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 :)
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.
> >-> > >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.
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.... :)
> -> > >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.
> 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
> >complex effort than the massive changes that are outlined here, and
> >won't frustrate us oldbies that know where to look for things :)
This is certainly productive.
> -> > 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.
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.
Reply to: