[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SEUL: SEUL duplicating efforts?
> 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
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 <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