Re: Cross posting per request
On Wed, 04 Sep 1996 11:04:06 CDT David Engel ([EMAIL PROTECTED]) wrote: Bruce Perens writes: It's unfortunate that the printer config stuff (and other stuff from Red Hat) is written in TCL/TK. One thing we _don't_ assume is that the user has X (or even a VGA card - it might be a serial console). A shell/dialog solution would be much better. There is a curses-based version of Tk, but I don't have any idea of how well it works. Do you know where we could find this thing ? Might be interesting... Phil.
Re: Cross posting per request
On Wed, 4 Sep 1996, Philippe Troin wrote: On Wed, 04 Sep 1996 11:04:06 CDT David Engel ([EMAIL PROTECTED]) wrote: There is a curses-based version of Tk, but I don't have any idea of how well it works. Do you know where we could find this thing ? Might be interesting... It's at ftp.neosoft.com:/languages/tcl/alcatel/potpourri/ctk-4.0.tar.gz. I already took a look at it and, although it works, it's barely usable, IMO. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: Cross posting per request
Greg Hudson writes: - In addition, the admin's life would only be made easier. - - Let's see where is perl stuffof course: /usr/perl - - Of course it looks easier if you only ask one question. - - Where are the operating system binaries that should go in users' - paths? - - Where are the standard C++ libraries? Where is the termcap library? - [ Rest of Greg's excellent explanation deleted ] I couldn't have said it better myself. :) This is the most compelling argument for the status quo. With the suggested changes, mapping a program to it's associated files gets slightly easier, but mapping a type of file or specific file to it's location in the filesystem gets much harder. It's probably one of the reasons why /opt hasn't caught on too well with 3rd party platforms. (Well, that and support for multiple platforms :) -Larry -- Larry Daffner| Linux: Unleash the workstation in your PC! [EMAIL PROTECTED] / http://web2.airmail.net/vizzie/ Whenever you find yourself on the side of the majority, it is time to pause and reflect. - Mark Twain
Re: Cross posting per request
Larry, They intend to implement /opt as a major mount point. They also plan to make /usr/local a very dangerous place to play. :) I hope that Debian will make a policy of staying out of /usr/local. This is way it is shaping up for each application: Beside the binary in /usr/bin or /bin. There will be a /usr/libexec subdirectory for each application. There will be a /usr/share subdirectory for each application. They specify the contents of this directory to be architecture independent data. /var is in a serious state of flux and I think that this will go to pot like /usr/lib is now. About half of it is currently local and half currently non-local. They seem to be refusing to fix ridiculous things like /usr/games and putting /dev/MAKEDEV where it belongs in /sbin. Well actually the FHS people are pretty set on this Greg Hudson writes: - In addition, the admin's life would only be made easier. - - Let's see where is perl stuffof course: /usr/perl - - Of course it looks easier if you only ask one question. - - Where are the operating system binaries that should go in users' - paths? - - Where are the standard C++ libraries? Where is the termcap library? - [ Rest of Greg's excellent explanation deleted ] I couldn't have said it better myself. :) This is the most compelling argument for the status quo. With the suggested changes, mapping a program to it's associated files gets slightly easier, but mapping a type of file or specific file to it's location in the filesystem gets much harder. It's probably one of the reasons why /opt hasn't caught on too well with 3rd party platforms. (Well, that and support for multiple platforms :) -Larry -- Larry Daffner| Linux: Unleash the workstation in your PC! [EMAIL PROTECTED] / http://web2.airmail.net/vizzie/ Whenever you find yourself on the side of the majority, it is time to pause and reflect. - Mark Twain
Re: Comments about FHS -and- Re: Cross posting per request
Folks, [This should spark a debate :)] What is the fine line between a library such as libc.so.5, libm.so.5 or libcurses.a and just a compiled object file? --Glenn
Re: Comments about FHS -and- Re: Cross posting per request
Glenn Bily [EMAIL PROTECTED] writes: Folks, [This should spark a debate :)] What is the fine line between a library such as libc.so.5, libm.so.5 or libcurses.a and just a compiled object file? Please do not try to spark debate (troll) on the FHS discussion mailing list. I do not appreciate it and I doubt that anyone else does either. You have already clearly demonstrated that you have not read the entire FHS draft and that you have some serious technical gaps in your understanding of Linux. I appreciate your desire to get involved, but I think you need to become more acquainted with the issues at hand before make a fool of yourself. I would appreciate it if members of the Debian User's mailing list would not Cc messages to the FHS mailing list (formerly FSSTND). Thank you. Dan
Re: Cross posting per request
Jason, On Sun, 1 Sep 1996, Glenn Bily wrote: Debian is parse through /etc/X11/window-managers and execute the first window manager that it finds (and is installed). In a larger environment where you have users that prefer one window manager over another, a convenient method we use here is to check the user's home directory for the existance of a special file and start its corresponding WM. We could merge both the startx and xdm WM startups by simply modifying the xinitrc and Xsession scripts to do the following: Your idea is sound. I'm opposed to merging XDM and startx too much. XDM and startx already share too much to some degree. We need to make considerations that someone running XDM will not necessarily have choices of window managers before the session begins. It would be a big plus if Debian did do that :) (and I have a script that does that) Choices of XDM security procedures that may want to be added by root should be considered too. There may be things done on a XDM login that shouldn't be done with startx. As a technicality: I'd also trade use of /usr/bin/X11 for /usr/X11R6/bin. /usr/bin/X11 is a symbolic link for backward compatibility.
Re: Cross posting per request
Bruce Perens writes: It's unfortunate that the printer config stuff (and other stuff from Red Hat) is written in TCL/TK. One thing we _don't_ assume is that the user has X (or even a VGA card - it might be a serial console). A shell/dialog solution would be much better. There is a curses-based version of Tk, but I don't have any idea of how well it works. David -- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
Re: Cross posting per request
Your idea is sound. I'm opposed to merging XDM and startx too much. XDM and startx already share too much to some degree. We need to make considerations that someone running XDM will not necessarily have choices of window managers before the session begins. It would be a big plus if Debian did do that :) (and I have a script that does that) There is a tool in the X11 contrib which allows you exactly that, it's called xsession. In addition you can preprocess the WM configuration either with CPP or M4 (yes, i know fvwm* can do this, but on the other hand twm and mwm can not!) and start applications from the menu bar, leaving you the mouse buttons free for more important stuff than launching apps. Cheers, Dominik =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Visit the FAN SITE of the WORLD LEAGUE OF AMERICAN FOOTBALL: A HREF=http://www.uni-mainz.de/~kubla/WLAF/Welcome.htmlHTTP/A or A HREF=file:/afs/zdv.uni-mainz.de/homes/UFO/kubla/public_html/WLAF/Welcome.ht mlAFS file/A access.
Re: Cross posting per request
Folks, These ideas are being posted here from net news per request. Response is desired (even if it's not Debian priority) [...] 3) Server and client installation distinctions. Possible avenue for easy minimal setup of X clients. A person installing a Linux system should have the option of choosing where they want the local machine to be the server or use a remote server. There are still people out there who want to make use of machine with 4 megs of ram. Running an X client on a 386 with 4 megs of ram and a resonable video arrangement is not a bad thing and may be cost effective in some environments. [...] So just running a client on the local machine makes no sense unless I am on a network and the windows/keyboard input/etc are showing up on -someone else's display-. It is reasonable, however, if you have a fast network, to run just an X server locally and X clients remotely. For most people, this isn't a sensible option, since most new Linux users are going to be individuals, with no fast network to support them. I think that Linux folk should be forward looking. Consider when (opinion: it is not a matter of ifit's a matter of when) multi-megabit come into being for average users in the next few years. Linux and Debian could be the first to embrace it. As for memory considerations... I am running both an X server and several X clients on my machine right now. The two biggestnt processes on my machine are exmh (an X client that acts as a mailreader, Tcl/Tk based, and a true memory hog), and XF86_SVGA (my X server). The server -right now- is only using about 2MB of memory, but that will grow with time. The mailreader is using about 4MB of space. After those two, I have an Xterm (another X client) using 1MB of memory, and everything else is less than that. Running just X clients on my machine would not help the memory issue (but just running an X server might). I recognize your concern. But also consider that you can buy 16 megs of ram for under $100. Making multiple queries to 4 or 5 XDM servers I found to be very practical on a 8 meg machine. 4) Allowing controls of how many X sessions can be lauched would be reasonable as well. X has the seemingly unknown feature of running numerous client/servers. By adding :1, :2, etc as server arguments, you can launch multiple X session possible on different servers from the same console. This is extremely powerful to say the least. It would be a bonus to be able to have a system admin control how many X sessions are being launched at one console. This would require a small adjustment in startx. In addition, it should not be required that the user keep track of :1, :2, :3. This is another adjustment that would be made in startx. It does have this option, but it is necessarily all that good of an option. Multiple X servers (which is what you do when you do that) eat up more memory, with little real benefit See top note above. [...] As an experiment, I just went to one of my shell windows and found out that my environment variable DISPLAY was set to :0.0 (or, display 0, screen 0 on the local machine). I then went to another virtual console, and started another X server using startx (which took a while, since I normally use xdm to manage my X sessions). On -that- server, I again checked my environment variable DISPLAY, ant it was set to :1.0 (or, display 1, screen 0, on the local machine). It appears that no change is really necessary -- the system already does the job as configured. The DISPLAY variable is what all properly written X clients use to determine what display (and screen!) they should use. This is a fact that I was unaware of. 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 And have resonable assurances that it will work. An additional bonus to this would be allowing root to setup a simple table to map the names to various shell scripts that would start the window managers. This would allow for practically all contingencies and complexities in getting that window manager started. This would also allow the package maintainer to move the main window manager binaries out of the path and out of harms way. I'm sorry... I don't agree here... The onus for getting -my- X session to look the way -I- want is right where it should be, on -me-, not the sysadmin. This wouldn't have to override the existing option of using ~/.Xsession. xinitrc is what makes the decision whether ~/.Xsession is launched. A test for .Xsession could exist before the default window manager decision is made or based on the startx argument. Startx is a front end to the xinit program, which in turn runs the program
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 stuffof 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.
Re: Cross posting per request
From: Glenn Bily [EMAIL PROTECTED] 1) Long awaited cleaning out of /usr/lib. In addition, categorizing what is left into subdirectories. A reasonable setup would be: /usr/lib/elf -- elf shared libs /usr/lib/aout -- a.out shared libs How about /usr/lib/i386-elf and /usr/lib/i386-aout? That lets you support multiple architectures more easily. I think this is more desirable from an architecture standpoint than an executable format standpoint - a.out is quickly waning, but supporting hetrogenous architectures is a continuing problem. Please contact Dan Quinlan [EMAIL PROTECTED] about joining the FHS group - they are the ones who will make this decision. Please get the current draft of the FHS standard from Dan (it's long) and become familiar with it before you join the discussion on their mailing list. If /usr/local is really for local configuration then it shouldn't be in /usr. Yes. It should probably be a symlink to somewhere else out of the box on a freshly-installed Debian system. The installation scripts can do that. Please submit a bug report on the boot-floppies package about this so I won't forget it. The info on how to use the bug system is on our web page www.debian.org . On a debian system I am looking at has a /usr/local/lib/emacs which I consider to be stranded. Please check that the _current_ Emacs package still does this. Debian packages aren't supposed to touch /usr/local at all, but perhaps some of them create directories there to give the user a hint that programs will look in there. /local/etc would be configuration files typically found /etc. /etc is by definition local - however I have done it exactly as you describe on my system (before upgrading with dpkg became so easy) in order to tell what I had changed. I've actually thought about using a source control system (like RCS) on /etc . dpkg doesn't currently know how to check control files in and out of RCS - is this a good idea? Currently, it will leave a filename.dpkg-new file around for you to hand-edit if you decline to over-write a control file. There should also be a dpkg flag to ask it if you have altered a control file from the version in the package. Since it keeps the md5 checksum around, that is possible. 3) Server and client installation distinctions. Possible avenue for easy minimal setup of X clients. Is this select a preset list of packages depending on what I say I want to use the system for? We just put functionality in dpkg that would make that easy to implement. A person installing a Linux system should have the option of choosing where they want the local machine to be the server or use a remote server. There are still people out there who want to make use of machine with 4 megs of ram. Running an X client on a 386 with 4 megs of ram and a resonable video arrangement is not a bad thing and may be cost effective in some environments. I'm not sure I understand the list of action items required for the above. I think it's just a matter of choosing the right packages - something we could definitely help the user with. [discussion of several new startx features deleted] This would require a small adjustment in startx. OK - go ahead and code it up, document it, and package it as an alternate startx. Packaging documentation is now in the dpkg and debian-doc packages. It's a lot easier now that there _is_ packaging documentation. If you get satisfied Debian users of your package, that'll help you convince XFree86 to adopt it. 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. /etc/X11/xinit only has one script on my system, and that's one I can see reasons to edit. About 3 files in xdm could be elsewhere, but they are small. You might want do discuss this with the xdm maintainer. The configuration programs for /etc/printcap and the user maintaince utilities from Redhat need to be lifted :) Hm. Who is in charge of printer set-up? I'd be happy to look at the user maintainance scripts from RedHat. Can you mail them to me? Thanks Bruce
Re: Cross posting per request
[EMAIL PROTECTED] (Bruce Perens) writes: (like RCS) on /etc . dpkg doesn't currently know how to check control files in and out of RCS - is this a good idea? Currently, it will leave a filename.dpkg-new file around for you to hand-edit if you decline to over-write a control file. This sounds like a really nice idea, but I bet there could be nasty logistical problems. -- Rob
Re: Cross posting per request
Bruce, If /usr/local is really for local configuration then it shouldn't be in /usr. Yes. It should probably be a symlink to somewhere else out of the box on a freshly-installed Debian system. The installation scripts can do that. Please submit a bug report on the boot-floppies package about this so I won't forget it. The info on how to use the bug system is on our web page www.debian.org . If it is suppose to be empty...Then why should it be at all? /local/etc would be configuration files typically found /etc. /etc is by definition local - however I have done it exactly as you describe on my system (before upgrading with dpkg became so easy) in order to tell what I had changed. I've actually thought about using a source control system (like RCS) on /etc . dpkg doesn't currently know how to check control files in and out of RCS - is this a good idea? Currently, it will leave a filename.dpkg-new file around for you to hand-edit if you decline to over-write a control file. The difference between local configuration and global configuration is vague. A good way to determine this would be: If I NFS mount /etc read-only from a server on a client (of course you can't do this). What would I find necessary to change to make the client work besides account based stuff? Off the top of my head...here are some pretty big candidates: sendmail.cf yp.conf syslog.conf securetty printcap Questionable: hosts.* shells resolv.conf If one wanted to give the installer a choice (wonderful!) then shell script could be lifted out of the kernel configuration utility. The type of choice code that could be used has already been written. There should also be a dpkg flag to ask it if you have altered a control file from the version in the package. Since it keeps the md5 checksum around, that is possible. 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. /etc/X11/xinit only has one script on my system, and that's one I can see reasons to edit. About 3 files in xdm could be elsewhere, but they are small. You might want do discuss this with the xdm maintainer. The fact you find need to edit this script suggest problems (to be distinuish from /etc/X11/xdm/xdm-config which is a genuine configuration file). One should be able to get away with only editing these scripts once or twice in a blue moon. The rests of this work should be done in ~/.Xsession as a regular user. It should be the perogative of any Unix system to keep users out of root as much as possible.
Re: Cross posting per request
On a debian system I am looking at has a /usr/local/lib/emacs which I consider to be stranded. Please check that the _current_ Emacs package still does this. Current emacs does *create* the directory (ie. it is in the package contents), as recommended by the debian packaging guidelines, as a hint to the user that emacs will *look* there if there's anything in it. It does not put any files there, of course.
Re: Cross posting per request
Mark, This doesn't answer the overall question...why is it there? --Glenn On a debian system I am looking at has a /usr/local/lib/emacs which I consider to be stranded. Please check that the _current_ Emacs package still does this. Current emacs does *create* the directory (ie. it is in the package contents), as recommended by the debian packaging guidelines, as a hint to the user that emacs will *look* there if there's anything in it. It does not put any files there, of course.
Re: Cross posting per request
On Sun, 1 Sep 1996, Glenn Bily wrote:
Bruce,
If /usr/local is really for local configuration then it shouldn't be in
/usr.
Yes. It should probably be a symlink to somewhere else out of the box
on a freshly-installed Debian system. The installation scripts can do
that. Please submit a bug report on the boot-floppies package about
this so I won't forget it. The info on how to use the bug system is
on our web page www.debian.org .
If it is suppose to be empty...Then why should it be at all?
Hmmm, i tend to agree here, except if Debian doesn't put it
there, I'm sure a slew of newbies will never figure out
where to put home grown stuff. Perhaps creating
/usr/local/{bin,include,lib,man} and a README file explaning
what the heck it all is.
/local/etc would be configuration files typically found /etc.
/etc is by definition local - however I have done it exactly as you
describe on my system (before upgrading with dpkg became so easy) in
order to tell what I had changed. I've actually thought about using a
source control system
(like RCS) on /etc . dpkg doesn't currently know how to check
control files in and out of RCS - is this a good idea? Currently, it
will leave a filename.dpkg-new file around for you to hand-edit if
you decline to over-write a control file.
No point in splitting hairs, etc is local already. When we
start to over scrutinize things to this extent, we need to
ask ourselves what it it we really want to accomplish.
Doesn't /etc/ already accomplish this? As far as using rcs,
I think its a good idea, but does it break some other
packages that offer a method for controlling and
distributing this information? Maybe using /var/lib/RCS or
something and keeping this stuff unlocked. That would give
dpkg the opportunity to have its own version information,
without encumbering other utilities.
The difference between local configuration and global configuration is
vague. A good way to determine this would be: If I NFS mount /etc
If one wanted to give the installer a choice (wonderful!) then shell
script could be lifted out of the kernel configuration utility. The type
of choice code that could be used has already been written.
you lost me here.
There should also be a dpkg flag to ask it if you have altered a control
file from the version in the package. Since it keeps the md5 checksum
around, that is possible.
If it keeps the md5sum around, can't it detect alterations?
The fact you find need to edit this script suggest problems (to be
distinuish from /etc/X11/xdm/xdm-config which is a genuine configuration
file). One should be able to get away with only editing these scripts
once or twice in a blue moon. The rests of this work should be done in
~/.Xsession as a regular user.
It should be the perogative of any Unix system to keep users out of root
as much as possible.
I've never had the need to let any user muck around in the
root filesystem for any reason on any flavor on UNIX. I'm
not sure I'm following this last part either ...
Thanks
Richard G. Roberto
[EMAIL PROTECTED]
201-739-2886 - whippany, nj
--
***
Bear Stearns is not responsible for any recommendation, solicitation, offer or
agreement or any information about any transaction, customer account or account
activity contained in this communication.
***
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 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
Re: Cross posting per request
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
Re: Cross posting per request
In addition, the admin's life would only be made easier.
Let's see where is perl stuffof course: /usr/perl
Of course it looks easier if you only ask one question.
Where are the operating system binaries that should go in users'
paths?
Where are the standard C++ libraries? Where is the termcap library?
If I want to export all architecture-independent read-only
application data via NFS to both Intel and Alpha machines running
Linux, what directories do I need to export?
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.
/etc/ld.so.conf lives on client machines; libraries may live on a
server. It's bad to force people to update configuration files on all
of their clients due to operating system changes.
I think that the user should have the possibility of specifying the
window manager at the startx prompt such as:
startx already takes command-line arguments. startx fvwm already
has a meaning.
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.
It is not acceptable to put materials under /usr which you expect the
system administrator to need to change in order to configure their
system. In particular, it means the system administrator can never
know what parts of their system are from the stock OS and what parts
are configuration information they may have modified.
Scripts make a poor configuration language, but if a script is
intended to be modified by the administrator, it belongs under /etc,
not /usr. The system admin could remount /usr read-write misses the
point.
While I'm here, Bruce Pixar wrote:
How about /usr/lib/i386-elf and /usr/lib/i386-aout?
That lets you support multiple architectures more easily.
The assumption behind the FHS is that the filesystem is generally
architecture-dependent except for /usr/share and parts of /var (the
parts Thomas Bushnell wants to move into /com). It makes no sense to
create architecture subdirectories for random things under /usr, or
you'll find tourself with architecture subdirectories of /usr/bin,
/usr/games, /usr/sbin, and so on.
If you're thinking about cross-compilation, then you haven't proposed
a complete solution (you need a place for include files and tools as
well), and the FSF has an existing standard (/usr/bfd
name/{bin,lib,include}) which is being used on Linux systems for
building a.out binaries on ELF machines.
Re: Cross posting per request
On Sun, 1 Sep 1996, Glenn Bily wrote: 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 And have resonable assurances that it will work. An additional bonus to this would be allowing root to setup a simple table to map the names to various shell scripts that would start the window managers. This would allow for practically all contingencies and complexities in getting that window manager started. This would also allow the package maintainer to move the main window manager binaries out of the path and out of harms way. This should apply to xdm startup as well. The current (default) setup for Debian is parse through /etc/X11/window-managers and execute the first window manager that it finds (and is installed). In a larger environment where you have users that prefer one window manager over another, a convenient method we use here is to check the user's home directory for the existance of a special file and start its corresponding WM. We could merge both the startx and xdm WM startups by simply modifying the xinitrc and Xsession scripts to do the following: ... ... [Initialization stuff] ... if (-e $HOME/.mwm_gui ) then set WINMGR = mwm else if (-e $HOME/.twm_gui ) then set WINMGR = twm else if (-e $HOME/.olvwm_gui ) then set WINMGR = olvwm else if (-e $HOME/.fvwm_gui ) then set WINMGR = fvwm else if (-e $HOME/.fvwm2_gui ) then set WINMGR = fvwm2 endif # Start up a window manager switch ($WINMGR) case mwm: /usr/bin/X11/mwm breaksw case twm: /usr/bin/X11/twm breaksw case olvwm: /usr/bin/X11/olvwm breaksw case fvwm: /usr/bin/X11/fvwm breaksw case fvwm2: /usr/bin/X11/fvwm2 breaksw default: echo Unsupported window manager: $WINMGR echo Starting up fvwm as a fall back... /usr/bin/X11/fvwm breaksw endsw Note that this is a portion of a csh script, but gives the basic idea. Not only would this give the _user_ the option of which WM to use, but this would also be _very_ compatible with other flavors of UNIX as well. Once you have common X startup files, you can just push the same scripts to every (Unix) machine on your network (which sys-admins like very much). -Jason Keimig [EMAIL PROTECTED] http://www.tisl.ukans.edu/~jkeimig -TiMCAN Project -University of Kansas === I have two very rare photographs: one is a picture of Houdini locking his keys in his car; the other is a rare photograph of Norman Rockwell beating up a child. -- Steven Wright
Re: Cross posting per request
It's unfortunate that the printer config stuff (and other stuff from Red Hat) is written in TCL/TK. One thing we _don't_ assume is that the user has X (or even a VGA card - it might be a serial console). A shell/dialog solution would be much better. Thanks Bruce
Cross posting per request
Folks, These ideas are being posted here from net news per request. Response is desired (even if it's not Debian priority) 1) Long awaited cleaning out of /usr/lib. In addition, categorizing what is left into subdirectories. A reasonable setup would be: /usr/lib/elf -- elf shared libs /usr/lib/aout -- a.out shared libs /usr/lib/elf/static -- for static elf libs /usr/lib/aout/static -- for static a.out libs Other development packages could retain their own /usr/lib subdirectories or more preferably build mini etc lib bin trees in /usr/package name, /ap/package name, /usr/X11R6/X package name directory. Such as: /usr/lib/elf/SVGA or /usr/SVGA/lib Things like /usr/lib/perl, /usr/lib/terminfo, etc. need to be moved back to /usr or /ap were it makes more sense. 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. It great reduces confusion on the part of users and possibly developer as to what libraries are where. 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. The person maintaining the system would just end up making /usr/local a symbolic link. On a debian system I am looking at has a /usr/local/lib/emacs which I consider to be stranded. The system is not a complete installation so there is no telling what other things are placed in /usr/local. A reasonable solution to this is to move /usr/local to / I would create 2 directories in /local: /local/bin /local/etc /local/bin would be placed in the path and would represent binaries that would search before /usr/bin for binaries. /local/etc would be configuration files typically found /etc. The person maintaining the server would put symbolic links into /local/etc in /etc if they need it to be a local configuration. 3) Server and client installation distinctions. Possible avenue for easy minimal setup of X clients. A person installing a Linux system should have the option of choosing where they want the local machine to be the server or use a remote server. There are still people out there who want to make use of machine with 4 megs of ram. Running an X client on a 386 with 4 megs of ram and a resonable video arrangement is not a bad thing and may be cost effective in some environments. 4) Allowing controls of how many X sessions can be lauched would be reasonable as well. X has the seemingly unknown feature of running numerous client/servers. By adding :1, :2, etc as server arguments, you can launch multiple X session possible on different servers from the same console. This is extremely powerful to say the least. It would be a bonus to be able to have a system admin control how many X sessions are being launched at one console. This would require a small adjustment in startx. In addition, it should not be required that the user keep track of :1, :2, :3. This is another adjustment that would be made in startx. 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 And have resonable assurances that it will work. An additional bonus to this would be allowing root to setup a simple table to map the names to various shell scripts that would start the window managers. This would allow for practically all contingencies and complexities in getting that window manager started. This would also allow the package maintainer to move the main window manager binaries out of the path and out of harms way. 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. 7) The configuration programs for /etc/printcap and the user maintaince utilities from Redhat need to be lifted :)
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 3) violates what most experienced UNIX users would expect - Other development packages could retain their own /usr/lib - subdirectories or more preferably build mini etc lib bin trees in - /usr/package name, /ap/package name, /usr/X11R6/X package name - directory. Such as: I'm sure you mean /opt, not /ap :). /opt/package, if a program uses it, gets all the config files for that package installed under it. It's a SysV.4 thing, but a draft exists for using it under Linux. - 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. - 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? - 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. - 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. - 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. - 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 :) - 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? :) -Larry -- Larry Daffner| Linux: Unleash the workstation in your PC! [EMAIL PROTECTED] / http://web2.airmail.net/vizzie/ The great tragedy of science, the slaying of a beautiful theory by an ugly fact. --Thomas Henry Huxley
