> >> 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.
