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 PROTECTED] / 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