> 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. > 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. "Let's see where is perl stuff....of course: /usr/perl" > >-> Things like /usr/lib/perl, /usr/lib/terminfo, etc. need to >be moved back > >-> to /usr or /ap were it makes more sense. > > >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. > >-> What are the advantages this? > >-> > >-> If someone chooses not to install development type >packages then their > >-> lib directories are not cluttered with libraries that make >the directory > >-> long and unmanagable. > >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. > >-> It great reduces confusion on the part of users and >possibly developer > >-> as to what libraries are where. > > >Only people who have never used any other UNIX system. >I'm willing to > bet that most linux users either already have >some UNIX experience or > are trying to become familiar >with UNIX. No need to confuse people by > being rather >gratuitously different from other UNIXes. I spend a substantial time on IRC in the #linux and probably see 50 newbies go in and out per hour. > >-> 2) Figuring out whether /usr/local is really being used >properly (which > >-> in my reading of FSSTND it isn't) > >-> If /usr/local is really for local configuration then it >shouldn't be in > >-> /usr. /usr would typically be read-only mounted to a >server in the cases > >-> where /usr/local would be used. You cannot mount on >read-only > >-> partitions. > > >I think you're misunderstanding here... /usr/local is for local >use. > >In other words, /usr/local is where you put all the programs >that you > >download and compile yourself. They should probably be >using config > files in /etc and runtime files in /var if > > necessary. "local > >configuration" just means that it's up to the machine's >sysadmin as to > how they want to set up and use /usr/local. Even in this case. /usr/local is not being use properly. > >-> 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 :). > >-> 6) The wisdom of put the contents of /etc/X11/xdm and >/etc/X11/xinit > >-> where they are needs to be re-evaluated. > >-> Most of the files in these directories are shell scripts >not > >-> configuration files. > > >Actually, they kind of walk the fine line between >configuration files > >and shell scripts, since they are what you edit to configure >X to do > >what you want. So they're probably OK there, especially >since if they > >get put in /usr, they get a lot harder to configure if, as you > >suggest, /usr is read only :) Don't see why these files would have to be changed on a constant basis. Individual users could easily do it in ~/.xsession. System admin could remount /usr read-write when he does the changes. Negliably harder. > >-> 7) The configuration programs for /etc/printcap and the >user maintaince > >-> utilities from Redhat need to be lifted :) > > >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.
