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.
