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 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.
Reply to: