Re: SEUL: SEUL duplicating efforts?

[Erik Walthinsen <omega@omegacs.net>]

> I'm not technically aware enough to say much more on this other than the
> fact that it boils down to whether it's possible to catch xdm if it fails
> at boot, or somehow detect the 'loop of death'. 
I haven't though too hard about it (working on website right now), but my 
guess, based on experience, is that it's possible.  Almost anything is 
possible, because of the modular nature of Unix.

As for the 'loop of death', you've aptly named it.  In fact, I discovered 
just such a thing yesterday at work.  My friend's computer (dual PPro-120) 
was recently installed with RedHat 5.0 (which he's slowly starting to 
regret, because of all the little things that're broken), but he kinda 
forgot one detail.  Both his machine and mine (dual PPro-100, if you can 
believe it) are effectively headless, as we have Xterminals on a private 
network.  So he was booting to runlevel 5 (X) to get an xdm login on his 
terminal, but he, for obvious reasons, hadn't installed or configured a 
local X server.  Guess what we found?  A 250MB+ log file with 160,000+ 
iterations of X saying "there's no xf86config file!".  He never noticed it 
until his disk ran out of space, because he keeps his machine sufficiently 
loaded to mask the continual loop, and the machine is loud enough to mask 
all disk noise (a nice feature, IMO).

> in fact the IRIX machines have such a thing. Moreover, they you can shut
> them down as user, you are presented with a root password to shut it down,
> and on success, the machine shuts down.
A slightly smarter mechanism could be constructed that would allow any user 
to shut down the machine if no one else is using it.  A quick check of 
running processes and logged in users would decide whether the user can 
shut it down from the login prompt with their own login/passwd, or it'll 
have to be force by the superuser.

That way a machine can be used and shutdown by a child, without needing the 
superuser password.  But if Dad is using the machine's disk via NFS or SMB 
from another computer, it wouldn't shut down the machine without Dad coming 
in and entering the superuser password, which he wouldn't do until he's 
done with the mount.

Someone (george?) mentioned that newer computers don't have actual power 
switches.  In such a networked, child-parent environment, such a machine 
would add a nice level of child-proofing.

> Again, I guess it's for the programming gurus to work out how the machine
> "knows" if X fails.
Unfortunately, this is a little tricky.  Anyone care to find out how 
Windoze deals with it?  Obviously much of the work is done by figuring out 
what card the machine has and looking through their database.  And if 
there's a card that isn't supported natively, the driver from the manuf. 
has the appropriate information.  X is almost a disadvantage in this area, 
because it natively supports everything, and *doesn't* have such a database.

BTW, I have the start of a perl script to extract information from 
Windoze's monitors.inf files.  Someone needs to take over that project.

> nedit is the nicest one I've seen so far. Feels a lot like wordpad.
> Haven't really played with console editors other than emacs/vi/jed. 
OK, people need to try out all these editors, gather screen shots, and 
write up details technical and opinion papers on them.  They will go to the 
website.  We *must* do these things.  Without them we'll fail.

> one wouldn't do haphazardly and spontaneously on a machine connected to
> several terminals...
Well, the normal end-user won't have terminals connected, though it's a 
simple task to find out if they're in use, if they exist.  But actually, 
switching runlevels doesn't kill things like that.  In fact, I can see 
several cases where switching runlevels would be a good way to achieve 
certain objectives.  (NOTE: the user doesn't care what a runlevel is, it's 
just a mechanism for use to use)  The most glaring one in my mind is a 
secondary runlevel designed for laptops that would shut down or put to 
sleep any recurring events, flush the buffer cache, and make sure all the 
.TEXT pages are in core.  This would allow someone to put their laptop in 
standby without the disk spinning up every 30sec.

> of course it does create yet another step in the initialisation process
> though. 
Which is precisely what we must avoid.  End-users don't want to follow a 
list of steps, no matter how easy or self-documenting.  They want to get to 
work.  We can't put in steps that don't need to be there.  Yes, it will 
take a lot of work to make things safe enough to do many of these things, 
but that's what we're trying to do, no?  If we do the job half-way, why are 
we doing anything at all?

     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