Re: Cross posting per request
> 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.
Reply to: