Re: SEUL: SEUL duplicating efforts?

[Erik Walthinsen <omega@omegacs.net>]

Kevin Forge wrote:
> > There is nothing wrong with a user using startx at least until he can
> > be confident in using xdm.
Yes, there is something wrong with it.  Our target user is typically going 
to be someone who is sick enough of Windoze's instability, which means that 
they likely have never seen a DOS prompt and had a clue what to do.

If SEUL is going to make any kind of dent in the market, we have to avoid 
text mode as much as possible.  Granted, as stated below, it shouldn't be 
ignored, because some machines just won't run X.  But booting the machine 
into text mode is a very good way to impress upon people the idea that 
SEUL is just another DOS/Windoze combination.  It's *not*.

Upon boot, a properly configured SEUL installation on a capable machine 
*will* start an X server, and present XDM or some similar login setup.

One of the hacks needed here is some way to reboot or shutdown the machine
from this point.  Something that has annoyed me equally in both Windoze and 
Linux is that you have to log in to shutdown the machine cleanly.  Being 
able to do so from the XDM login prompt will be a plus.

Donovan Rebbechi wrote:
> Another ( nutty?? what do you guys think of this one ? ) idea is to use
> some menu-based shell as a default. Away
> to make things user friendly in a non graphical environment. Possibly.
There *should* be some work put into building a valid text-mode 
configuration for people who either don't have the hardware for X, or just 
don't like X.  However, it will not be the default, unless the X 
configuration program determines that X just can't run.  Then it will 
indeed become the default, as there is nothing else to be done.

Given this, we need to make sure that we do indeed have a very user-friendly 
editor, as well as any other applications a user might find useful.  We may 
also want to put some time into SVGATextMode, or the enhanced modes that 
the 2.1.x kernels provide, so the user isn't stuck in 80x25 or if they're 
luck 80x50.

> That way, they just have to pick the "start X Windows" menu item and don't
> even have to remember 'startx'.
This is one more step that users don't need to take, so we shouldn't make 
them.  Even Windoze 3.x would put 'win' at the end of autoexec.bat for you.

> There's no obvious need to have XDM fire up at boot time ...
How many here have actually *used* XDM?  It doesn't seem like too many 
people so far understand what it actually does.

XDM is started as a daemon, and is managed by init.  If it dies, init 
restarts it.  It opens a socket on port 177, the XDMCP port.  Any incoming 
connection there, usually from an X terminal, opens a session and displays 
the login prompt.  But we're interested in the local behavior here, which 
is to start the X server, open a session, and display the login prompt.

Once the user types in their username and passwd (be it locally or from an 
X terminal), xdm steps aside and forks a shell to run the user's .xsession. 
The display is now under the control of whatever programs the .xsession 
started, usually some programs and a window manager.  The WM is always last 
in the file, and is not backgrounded.  When the WM dies, the .xsession 
script finishes, and XDM reclaims the X server to display the login prompt 
again.

In order to make things more friendly at the XDM login prompt, xbanner was 
invented.  This is what you see when you get an XDM prompt on a RedHat 
machine.  In reality, it's just a simple window-painter, but it could do 
anything we wanted.  This could include providing buttons to reboot and 
shutdown the machine.  I'm tempted to want to hack XDM itself, because that 
would allow us to present a more unified front to the user, rather than the 
XDM box and another one for SEUL functions.  However, that deviates from 
the standards in a way we will have to debate *at a later time* in detail.

> The idea of relying too heavily on X working at the drop of the hat seems
> mildly risky at best.
That's why we need to have text-mode fallbacks, and *good* ones, in case 
this happens.  For instance, if we do a partially X-based install, there 
must be a text-mode equivalent that will do *exactly* the same thing in 
almost exactly the same way.

> I just have these dark memories of my newbie days, almost going mad
> because exmh spat out error messages and I had no idea how to do
> X-athentication (and couldn't understand the man pages !!! <-" ) 
Yes, this is one area that needs a lot of work.  The simple case where the 
user just logs into the machine and does stuff is trivial.  What is 
difficult is when we start introducing SEUL machines into a networked 
environment.  What I propose is that we find a few other groups to work 
with, likely the Linnet group (the server side of things; though we may 
need to break off a few people to re-form that project, or fold it into 
SEUL), and come up with some standardized way of dealing with Xauth 
information over networks.  There are some hacks floating around, including 
something called 'xrsh' (I think) that will do the Xauth transfer, then 
start off the request program on the remote machine.

     Erik Walthinsen <omega@seul.org> - SEUL Project system architect
        __
       /  \                SEUL: Simple End-User Linux -
      |    | M E G A            Creating a Linux distribution
      _\  /_                         for the home or office user