[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
> >    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
"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: