[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SEUL: SEUL duplicating efforts?
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
> 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
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 <firstname.lastname@example.org> - SEUL Project system architect
/ \ SEUL: Simple End-User Linux -
| | M E G A Creating a Linux distribution
_\ /_ for the home or office user