Re: SEUL: SEUL duplicating efforts?

[jfm2@club-internet.fr]

> X-Authentication-Warning: belegost.mit.edu: majordomo set sender to owner-seul-project@seul.org using -f
> X-Priority: 3 (Normal)
> Content-Type: text/plain; charset=us-ascii
> Date: Sat, 14 Feb 1998 01:36:18 -0500 (EST)
> From: Cyberdyn <cyberdyn@seul.org>
> Cc: seul-project@seul.org, Erik Walthinsen <omega@omegacs.net>
> Sender: owner-seul-project@seul.org
> To-Get-Off-This-List: mail majordomo@seul.org, body unsubscribe seul-project
> X-UIDL: 360e883f06083d1b10300f308a983938
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> 
> 
> This should be in the UI list.
> 
> On 14-Feb-98 Donovan Rebbechi wrote:
> - -> 
> - -> 
> - -> On Fri, 13 Feb 1998, Erik Walthinsen wrote:
> - -> 
> - ->> > Some heavy-duty improvements to the startx script wouldn't go
> - ->> > astray. What would be really nice is a program that generates an
> - ->> > 'xstartup' script or something of the sort. Just some program that
> - ->> > invites
> - ->> > you to do some options (Xauthority, default color depth , config file
> - ->> > etc)
> - ->> > and spits out a script.
> - ->> 
> - ->> We should be making use of XDM for SEUL.  The use of startx doesn't allow
> - ->> the machine to be used by multiple people without going into text mode. 
> - ->> In 
> - ->> order to log into the machine, they have to log into a text-based virtual
> - ->> console and type startx, or have it done for them.  XDM or similar allows
> - ->> us to stay completely graphical, which is the goal.
> 
> Already working on the graphics and functions like xconsole, fonts, and
> session manager.
> 
> - -> Standardizing on XDM is a nice idea, in that XDM takes care of some of the
> - -> main newbie annoyances, such as greatly simplifying the process of
> - -> starting multiple X-sessions, and taking care of X-authentication. 
> - -> 
> - -> You can do this with xinit but not  with
> - -> startx, so it's basically due to a shortcoming with the startx script.
> - -> Like I said, the existing startx script is not very good, since it doesn't
> - -> do what it's supposed to (fire up X and take care of everything in a
> - -> sensible way) 
> - -> 
> - -> My questions about XDM at the moment are:
> - -> 
> - -> (a)  It's hard to set things such as colour depth when you're running
> - -> XDM (still haven't worked this one out ...), some kind of "intuitive"
> - -> configuration tools for XDM would be nice. (?)
> 
> 2 scripts can handle 2 aspects of your statement.  Initial use should bring
> the user into an 8 bpp failsafe mode with a script to setup his color depth. 

8 bpp is not failsafe.  Only if you have a supported card.  The real
failsafe mode is 4bpp with VGA and even this is untrue because the
NVidia cards don't work with the VGA server in 3.3.1

> The script uses alternat Xserver files with progressive depth settings and
> times out if the user doesn't validate the depth is working.  The higher
> depth files are removed from the system and the default in the Xserver file
> is set to the highest his card handles.
> 

I disagree: first if you have a card with only 1 meg memory then high
depths can be something you don't want due to limited res.  My card at
work is theorically able to do 24 bpp but I never go beyond 16 bpp.
Second: Some programs do not work in all modes, in particular 16 bpp
is often unsupported the reason being than 16bpp is acompromise being
nor good for saving memory, nor good for graphists (certain scenes are
better rendered with an 8bpp mobile palette than in 16 bpp where you
only have 32 shades of red, 64 of green and 32 of blue).
Final: in some cases we could have bugs than manifest later.

The best is giving the user a tool for choosing the color depth and
present him only the supported and unbugged depths.  THen we set the X
files :-) and kill it to have XDM start a new one.

> 
> We can only do our best to cover all bets and make changes as new situations
> occur.  I wonder if xdm can be placed in the inittab so as to catch the
> repawning when the Xserver flashes due to an error.  Then init could stop
> this for us.  The user could switch to a VT and scream for help.  

XDM will not catch an Xserver frying your monitor and the Xserver will
not die from problems like a garbled display even if the user cannot
do anything with it.

There is nothing wrong with a user using startx at least until he can
be confident in using xdm.  The problem now is than many distributions
let the user figure out how to start X (and some just type X and get a
suprise), the user must get a welcome message telling him about startx.

> 

-- 
			Jean Francois Martinez

"For drinking muddy water if that is the water of truth,
            for that the camel is needed"