Subject: Re: Cross posting per request

From: Glenn Bily <[email-masked]>
Date: Sun, 1 Sep 1996 20:12:55 -0400 (EDT)

> >> 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 if....it'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 /etc/X11/xinit/xinitrc as the initial client for >the X server
> (when this client exits, so does X).  On the >Debian system, 
> >/etc/X11/xinit/xinitrc is a symbolic link to >/etc/X11/Xsession, 

> Someone please tell me why this link exist.
> And what are executables (even shell scripts) doing in /etc?

> >which is a script that an a Debian system sets does some >basic
> configuration of the session for the user (i.e., >prepares the errors
> log file, loads in the system-wide or >user-specific keyboard
> modification map, and >system-wide or user-specific X resources, and
> then tries >to run a reasonable default (if a ~/.xsession is executable,
> >and the system is set up to allow user X session files, run it,
> >otherwise,
> > run the first windowmanager that is executable in the file
> >/etc/X11/window-managers, 

> Um. /etc shouldn't have executables

> >or if that doesn't work (no windowmanagers in the file, or >file
> doesn't exist), run fvwm if it exists, otherwise, run >twm).

Personal opinion: FVWM should be default :)

> >For most practical cases, this means that I, as end user, >have as much
> control over my X session that I want via a file >I control.  My
> .xsession file, for instance, starts up a few X >clients (a couple of 
> >clocks, a couple of load meters, a mail reader, a shell), and >then
> invokes a window manager.  My window manager is >controlled by the
> contents of my .fvwm2rc file, so I can >control that, and so on.
> >Yes, there are systemwide defaults that work reasonably well if none of 
> >these are specified, and you can configure it so that an 
> >.xsession/.fvwm is automatically created for new users, but >they are
> also easily overridden by the end user.
>
> >And this is how it shoudl be.

> >Besides, are you familiar with xdm?

> I'm should be familiar with this. I recently setup a xdm server and a
> bunch of clients.

> >This is an X session manager program, designed to allow >people to log
> into and out of X displays directly.  It presents >a login window, into
> which people enter there username and >password.  If they are good, xdm
> automatically starts up 
> >an X server with a configurable client application (in the >default
> Debian enironment, it works out to be the same >/etc/X11/Xsession file I
> discussed above).  Xdm is good in >environments where you don't want 
> >anyone -not- using X. Since I use xdm on my own machine, >I never even
> use startx.  How do you want your schema to >deal with this setup?

> My thinking is that xdm should be a separate execution path from startx.
> The fact that xdm runs /etc/X11/Xsession leaves something to be desired
> (this was a very undesirable setup in the XDM system I setup). xdm
> should run a completely separate set of shell scripts. But could still
> make test and calls for ~/.xsession and other user specific scripts.

> My particular setup had /etc/X11/xsession as the master script running
> as the logging in user from XDM. Another completely different script I
> named /etc/X11/xconsole ran the console setup and was notably different.
> This allows the superuser to put in such options as running multiple
> window manager when logging in via XDM. It also allows for the superuser
> security or otherwise based things that he may want done as a user
> logging in via XDM. Any checks for ~/.xsession could be made here. 

> So on XDM connection:

> /?usr?/X11R6/xdm/Xsetup would be launched.
> Login received
> /?usr?/X11R6/xdm/Xstartup is launched (after login as root)
> /?usr?/X11R6/xdm/Xsession is launched (separate file from one launch at
> console). All considerations for ~/.Xsession, ~/.Xresources, etc. are
> made. Default window manager is launched or other arrangments are made.
> (On my XDM server, on XDM login screen, there is a small box in the
> corner allowing you to choose your window manager as you login.)

> For console startx:

> /usr/X11R6/bin/startx is launched. Client args and server args or window
> manager name is received.
> xinit is launched
> X server is run by xinit of course
> /?usr?/X11R6/?xinit?/Xconsole would take over and launch the window
> manager of choice or ~/.Xsession.

> If you like I'll post my xdm and startx scripts for my XDM server.

> >> 
> >> 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.
>
> >Half the files in /etc/X11/xdm on my system are executable.  >As has
> recently been discussed on fhs-discuss, just >because it is a shell
> script doesn't mean that it isn't a >configuration file.  Should
> /etc/init.d/cron be moved?  It is a >shell script.  It is also an
> important part of system >configuration.

> The booting scripts probably do not belong in /etc. A directory
> hierarchy should probably be developed in /boot. /lib/modules should be
> moved to /boot as well.

> >OTOH, if you are saying Debian should change in these 7 >points because
> that is how Red Hat does things, then all I >can really say is that
> Debian is not Red Hat.

Not implying this.