Re: How to migrate a Debian system to another hard drive?
On Tue, 3 Sep 1996, Tim Egbert wrote: > On our Debian system, we have two hard drives. The primary drive has the > root directory and swap partition and is bootable. It also contains the > various Debian software packages, programs, libraries, etc. The second > drive just has the /home directory tree. > > Our problem is that the primary drive is starting to make some "expensive > sounding noises" and may not last much longer. We would like simply to > migrate the entire system to the second hard drive and disconnect the > first drive. Is there an easy way to do this without reinstalling the > entire system and fixing up all the configuration files? I've used dd() to essentially do the same thing, but only in cases where the system partitions I've copied have been of the same size. I'll describe the situation I've used: /dev/hd*1 is a 32-meg swap partition /dev/hd*2 is a 815-meg ext2 partition /dev/hd*3 is a 70?-meg partition for NT (currently unused) With the active partition being /dev/hda, I'll attach the target drive as /dev/hdc, bring the system up, and execute 'dd if=/dev/hda2 of=/dev/hdc2' to do the copy. Because the source partition is active when the duplication is done, you'll need to "fisk" the target partition, a la 'e2fsck /dev/hdc2' afterward. I've shut the machine down, put /dev/hdc back into its own machine as /dev/hda, bring it back up, and modify /etc/hostname, /etc/init.d/network, and a number of other files to give the target machine its own identity. (Presumably, you won't have to change any files in this manner.) I don't know what would happen if the source and target partitions aren't of the same size. Some pretty nasty things are probably possible, but all of my partitions were identical. David [EMAIL PROTECTED] Office: 3503 WeH, x86720 MTFBWY
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: Two Packages Missing
On Tue, 3 Sep 1996, Buddha Buck wrote: > > Guy Maor: > > > > > pbmplus was replaced by netpbm. > > > > Hmm. Perhaps some kind soul can make a debian package?! > > > > Someone did... > > bash$ dpkg -s netpbm > Package: netpbm > Status: install ok installed > Priority: optional > Section: non-free > Maintainer: Jim Robinson <[EMAIL PROTECTED]> > Version: 1994.03.01p1-5 > Description: netpbm -- graphics conversion tools. > Netpbm is a toolkit for conversion of images between a variety of > different formats, as well as to allow a few basic image operations. > It is based on the pbmplus distribution. > True, however this package should also say that it provides pbmplus so that other packages which require pbmplus will install correctly. Maybe additional links would also be necessary. Cheers, Carlo *** *Carlo U. Segre * * Department of Biological, Chemical and Physical Sciences * *Illinois Institute of Technology, Chicago, IL 60616 * * Voice: (312) 567-3498 FAX: (312) 567-3494* * [EMAIL PROTECTED] * ***
Problem with Netscape 3.0x on Linux
I am having a problem, probably not unique to Debian, on my Linux machine. The problem is the print command produces an error in the postscript output that will not allow it to print. When I further test by printing output to a file, and try to preview with ghostscript, gs cannot interpret it correctly either. I have 2.0.17 of the kernel, very current 1.1 Debian distribution, and v 3.0-elf of netscape. I first saw the problem in one of the v 3.0 betas, but did not realize it. Anyone else having a similar problem? I've seen alot of Java-related problems on the newsgroups, but not this one. BTW, all other ps output prints fine to the same printer. -- /--\ | James D. Freels, P.E._i, Ph.D. | Phone: (423)576-8645 | | L | | Oak Ridge National Laboratory | FAX:(423)574-9172 | H | I | | Research Reactors Division | Internet: [EMAIL PROTECTED] | F | N | | P. O. Box 2008 | Reactor Technology | I | U | | Oak Ridge, Tennessee 37831-6392 | world's best neutrons! | R | X | |--| | out the 10Base-T, through the router, down the T1, over the | | leased line, off the bridge, past the firewall...nothing but Net | \--/
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
Re: How to migrate a Debian system to another hard drive?
At 07:20 AM 9/3/96 -0600, you wrote: > >Is there a simple way to migrate a Debian system to another hard drive? > >On our Debian system, we have two hard drives. The primary drive has the >root directory and swap partition and is bootable. It also contains the >various Debian software packages, programs, libraries, etc. The second >drive just has the /home directory tree. > >Our problem is that the primary drive is starting to make some "expensive >sounding noises" and may not last much longer. We would like simply to >migrate the entire system to the second hard drive and disconnect the >first drive. Is there an easy way to do this without reinstalling the >entire system and fixing up all the configuration files? > >Thanks, > >// Tim Egbert >// Bioengineering Lab, Anesthesiology Department >// University of Utah Health Sciences Center > > > I have done this under other flavors of UNIX by doing a full dump to tape, then doing a fresh install of just a base system, then doing a full restore from tape. As I recall, some of the symbolic links didn't come back right and I had to tweak them manually, but I got the systems up and running without too much pain. I am interested to hear others' opinions about this. --- Key fingerprint = D6 A7 D7 8C 92 CB 42 FD 60 D5 62 1C D7 B9 EA 8E Ken Gaugler N6OSK Hybrid Networks, Inc. Cupertino, Calif. URL: www.hybrid.com (home: [EMAIL PROTECTED] URL: users.aimnet.com/~keng) "The life of a Repo Man is ALWAYS INTENSE..."
Re: need libbsd.so.1.0.0
> > On Mon, 2 Sep 1996, Susan G. Kleinmann wrote: > > The current implementation of postgres95 for Debian requires > > libbsd.so.1.0.0, but the libc5 package includes only libbsd.a. > > (How) can I make libbsd.so.1.0.0 from the .a file? > > (Sorry to be asking what I imagine is such a naive question.) > > I have no idea where the libbsd.so.1.0.0 came from. But if you've got the .a file, cannot you make the .so file by: mkdir t cd t ar -x ../libbsd.a gcc -o libbsd.so.1.0.0 -shared -W,l-soname,libbsd.so.1 *.o (I may well be _very_ wrong, and please flame me if I am, but I just _think_ it would work, and it's easy to find out). -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
Re: Make errors
> > Just a user problem I'm sure but when I go to use the make command I get: > > make: makeinfo: Command not found > make: Error 127 > > What am I doing wrong? Nothing to do with make, or gcc, I'm afraid. You just don't have the command "makeinfo" installed. It's in the texinfo package. Installl texinfo, and you should be OK. -- joost witteveen [EMAIL PROTECTED] [EMAIL PROTECTED] -- Use Debian/GNU Linux!
Re: Is smail MIME compliant
As Mike Wood said: > > > I just had somebody tell me that *NIX mailers (They didn't specify > which one) don't support MIME. This person claims that the MIME messages > he's been sending through my mail server aren't working because it's a *NIX > host. This I find hard to swallow. Could somebody clear this up for me, > DOES smail support MIME? Thank you for your time. To the transport agen (smail, sendmail), the contents of the e-mail message don't matter. It's the user agent (pine, elm, mail, xmail) that should decode the MIME part of your message. > > mike... > --gilbert __ Gilbert Ramirez Jr. [EMAIL PROTECTED] University of Texas http://merece.uthscsa.edu/gram Health Science Center at San AntonioUniversity Health System
How to migrate a Debian system to another hard drive?
Is there a simple way to migrate a Debian system to another hard drive? On our Debian system, we have two hard drives. The primary drive has the root directory and swap partition and is bootable. It also contains the various Debian software packages, programs, libraries, etc. The second drive just has the /home directory tree. Our problem is that the primary drive is starting to make some "expensive sounding noises" and may not last much longer. We would like simply to migrate the entire system to the second hard drive and disconnect the first drive. Is there an easy way to do this without reinstalling the entire system and fixing up all the configuration files? Thanks, // Tim Egbert // Bioengineering Lab, Anesthesiology Department // University of Utah Health Sciences Center
netscape de-caffeinated
> The browser works fine, but I can't get any java applets to work. I
> have > the setting set right and used the package setup that Brian
> put together, but something still isn't working. I don't receive any
> errors when I aim > at a page that I know has an applet on it, it
> just doesn't work. The
> applet space is blank.
Strangely enough this situation came up on my cluster of ten spark
stations. (one disk server {nis} and 9 nis clients)
The root user is able to view java apps no_problem (nice and speedy)
however the casual users are getting a blank area for the java app.
Java_30 has been moved to all suggested locations for test purposes.
AND lately when a user tries to view the app the netscape client
application crashes, dumping core.
Re: Two Packages Missing
> Guy Maor: > > > pbmplus was replaced by netpbm. > > Hmm. Perhaps some kind soul can make a debian package?! > Someone did... bash$ dpkg -s netpbm Package: netpbm Status: install ok installed Priority: optional Section: non-free Maintainer: Jim Robinson <[EMAIL PROTECTED]> Version: 1994.03.01p1-5 Description: netpbm -- graphics conversion tools. Netpbm is a toolkit for conversion of images between a variety of different formats, as well as to allow a few basic image operations. It is based on the pbmplus distribution. bash$ -- Buddha Buck [EMAIL PROTECTED] "Just as the strength of the Internet is chaos, so the strength of our liberty depends upon the chaos and cacaphony of the unfettered speech the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
Is smail MIME compliant
I just had somebody tell me that *NIX mailers (They didn't specify which one) don't support MIME. This person claims that the MIME messages he's been sending through my mail server aren't working because it's a *NIX host. This I find hard to swallow. Could somebody clear this up for me, DOES smail support MIME? Thank you for your time. mike...
wrong /dev/console messes up mouse -- why?
I touched on this in an earlier message about making a debian box run
headless (turns out the problem I encoutnered was my mistake). Anyway,
it's piqued my curiosity about something:
In debian, /dev/console is generally a symlink to /dev/tty0. I managed to
mess that up so /dev/console linked to /dev/tty1. Most stuff continued to
work fine, the only casulty was my mouse. I have a serial mouse, and I run
gpm and also start up X. This works fine, the 2 don't normally conflict.
If /dev/console is linked to /dev/tty1, though, they do conflict, and X
only gets some of the mouse events it should get, leading to a choppy
mouse movement at best.
Anyone know why /dev/console is important to gpm or to x in this way? I
don't think it's a bug, I just wanna figure out _why_ this happens..
--
#!/usr/bin/perl -lisubstr($_,39+38*sin++$y/9,2)=$s # [EMAIL PROTECTED]
for($s=' '||McQ;$_='JOEY HESS 'x8;print){eval$^I} # Joey Hess
"He. He. He." - - Herman Toothrot
Re: need libbsd.so.1.0.0
On Mon, 2 Sep 1996, Susan G. Kleinmann wrote: > The current implementation of postgres95 for Debian requires > libbsd.so.1.0.0, but the libc5 package includes only libbsd.a. > (How) can I make libbsd.so.1.0.0 from the .a file? > (Sorry to be asking what I imagine is such a naive question.) I have no idea where the libbsd.so.1.0.0 came from. David --- David EngelOptical Data Systems, Inc. [EMAIL PROTECTED] 1101 E. Arapaho Road (214) 234-6400 Richardson, TX 75081
tex font problems
Hi,
I am having trouble with the latex font, all non normal characters like
\"{a}, \aa and so on does not show up in the .dvi file. Has anybody else
moticed this? And maby has a fix for it?
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
How can I reconfigure packages??
It happened to me, that I misconfigured some packages when installing. Is there a way to repeat the reconfiguration step without reinstalling the whole package? Particularly: Is there a tool to manipulate the XF86Config file (as xf86config from slackware)? Thanks in advance! == Hubert Palme Bergische Universitaet-Gesamthochschule Wuppertal Computing Center D-42097 Wuppertal Email: [EMAIL PROTECTED] (Germany) http://www.uni-wuppertal.de/hrz/daten/adressen/h.palme.html
Re: Two Packages Missing
Guy Maor: > > 2. A lot of packages (e.g. magicfilter) recommend pbmlus which isn't > > available as a debian package too. > > pbmplus was replaced by netpbm. Hmm. Perhaps some kind soul can make a debian package?! > > > Guy > == Hubert Palme Bergische Universitaet-Gesamthochschule Wuppertal Computing Center D-42097 Wuppertal Email: [EMAIL PROTECTED] (Germany) http://www.uni-wuppertal.de/hrz/daten/adressen/h.palme.html
Re: dselect ftp through fire-wall
First of all I'd like to thank you a lot for your advise. Unfortunately I couldn't get our firewall to let me pass through to ftp.debian.org using the parameters in dselect's ftp access. Fortunately control lies in perl scripts. I had to modify those that call FTP.pm, but then it worked like a charm. I use the original parameters to log on to our gateway. So I needed to add a 'quote site some.debian.mirror' and a logon for it. Thanks a lot to get me going, -- Martin Fehlhaber [EMAIL PROTECTED]
Re: What is fvwm-95 and where can it be found
On Tue, 3 Sep 1996, Jim Worthington wrote: > What is fvwm-95 and where can it be found? From the name, it sounds > like it might emulate the Windows95 four button window format. Is this > the case? Yes, its bit modified fvwm2. All modifications have been done towards Windows '95 appearance. fvwm2 usually name taskbar as only improvement, but there is also one new focusing mode, fvwm menus stay active bit longer and there are those four buttons on each window title. > Where is fvwm-95 located and what is it's developmental status. http://ltiwww.epfl.ch/~barth/fvwm95.html is their official WWW page. Considering debian, situation is currently such that someone is creating package about it, but it hasn't yet reached unstable level (or just haven't been mirrored to the sites that I check). However it seems to be reasonably easy to compile, if you don't mind doing some minor work for it. -- Juha 'Ylis' Ylitalo [EMAIL PROTECTED] Hiomo 5/1/Maisema http://sam.ntc.nokia.com/~jylitalo +358 0 511 23313http://www.helsinki.fi/~jylitalo "True friendship is never serene." - Marie de Rabutin-Chantal
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//{bin,lib,include}) which is being used on Linux systems for
building a.out binaries on ELF machines.
Re: What is fvwm-95 and where can it be found
Jim, Fvwm-95 is a X window manager that mimics Window 95 interface. It can be found at: http://ltiwww.epfl.ch/~barth/fvwm95.html Excerpts from mail: 3-Sep-96 What is fvwm-95 and where c.. Jim [EMAIL PROTECTED] (430*) > What is fvwm-95 and where can it be found? From the name, it sounds > like it might emulate the Windows95 four button window format. Is this > the case? > Where is fvwm-95 located and what is it's developmental status. > I prefer the windows 95 window format over most of the X manager formats > that I have tried. I particularly like the dedicated exit button. I'm > currently running fvwm-2. > Jim <[EMAIL PROTECTED]>
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 e
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
What is fvwm-95 and where can it be found
What is fvwm-95 and where can it be found? From the name, it sounds like it might emulate the Windows95 four button window format. Is this the case? Where is fvwm-95 located and what is it's developmental status. I prefer the windows 95 window format over most of the X manager formats that I have tried. I particularly like the dedicated exit button. I'm currently running fvwm-2. Jim <[EMAIL PROTECTED]>
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
> 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 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: Two Packages Missing
On Mon, 2 Sep 1996, Joey Hess wrote: > On Mon, 2 Sep 1996 [EMAIL PROTECTED] wrote: > > > > > Richard> I taper no longer supported or is there an updated package that > > Richard> includes it? I kind of liked it. > > > > It is orphaned. If you really like taper, you could maintain it. There have > > been new upstream releases. :-) > > > > As for tape backups, we have "tob" which most people who tried it seem to > > be rather happy with, your's truly included. > > I'm a fan of taper myself. I'll take over maintaining it, ok? Didn't > realize it was orphaned or I would have done that sooner. > Kindly ignore my previous post and take it. I hadn't gotten down far enough to see there was another reply! Its all yours, and 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: Two Packages Missing
On Mon, 2 Sep 1996 [EMAIL PROTECTED] wrote: > > Richard> I taper no longer supported or is there an updated package that > Richard> includes it? I kind of liked it. > > It is orphaned. If you really like taper, you could maintain it. There have > been new upstream releases. :-) > > As for tape backups, we have "tob" which most people who tried it seem to > be rather happy with, your's truly included. > > -- > Dirk Eddelb"uttel http://qed.econ.queensu.ca/~edd > Hmmm, tob seems like a pretty useful interface to afio, but I dig taper's menu driven approach. I'll consider picking it up, but not for at least 8 more weeks. That puts it out of range of 1.2 :-( But by all means, don't hold me to this, at lot can happen in 8 weeks! 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
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
[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
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: Debian LInux
Hi Mark -- You asked: > When using dselect, do I have to download from the ftp site, packages or are > they on the install disks ? The install disks only contain enough software to set up your system so that it is *capable* of being used to fetch the major packages. All tolled, the Debian software packages take up several hundred MBytes. They can't fit onto floppy disks. (Of course, you don't have to install all of the files -- just the ones you need for your purposes.) > The programs that I am interested in are the XFree86, Emacs and Latex > including software to access the net. The programs you need for XFree86 are in the Debian FTP archive, in the directory stable/binary/x11. The programs you need for Emacs are in the Debian FTP archive, in the directory stable/binary/editors. The programs you need for Latex are in the Debian FTP archive, in the directory stable/binary/tex. You may also be interested in the files in stable/binary/text. Programs to access the net are mostly in stable/binary/net. > I can not find any man pages. 'man' and the 'manpages' are additional large packages. They are in stable/binary/doc at the Debian FTP archives. > I have looked for FAQ`s but have found none pertaining to the info that I > need. See http://www.debian.org/FAQ > Does the install contain a list of commands for Linux ? I don't know what this question means. The installation disks boot up, then present the user with a dialog to help guide him through setting up the disk partitions, formatting the disk, then setting up the basic directories. It then guides the user through the installation of the very basic Unix-like tools which are on the base disks into his newly-made Linux system. > While installing Debian 1.1 when it came to loading and configuring modules > to place in the kernal there where a few things I did not understand . > > 1. Under Fsystem/smbfs involved a Windows 95 Sharing . What is this ? smbfs is a file system for sharing data and directories with other computers running Windows. > 2. Under Vfat there was a driver ( I guess ) that you could install for > Windows 95 long file names under DOS. What is this ? Windows 95 allows the usr to (think he can) use file names longer than 8 characters, a dot, and a 3-character extension. (Actually, windows translates the filenames to shorter, MS-DOS compatible filenames for use by the DOS filesystem, but the user is in general unaware of that.) The vfat driver allows a Linux user to use Windows-95 style file names in accessing file on a Win95 drive on his Linux system. Good luck, Susan Kleinmann
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
> >> 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 .Xsess
