[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The Kernel

Paul Anderson wrote:
>On Tue, 20 Jan 1998, Erik Walthinsen wrote:
>> If we 
>> find that for instance a log-structured filesystem is better for end-user 
>> machines (reason: it survives ugly things like mounted power-off with 
>> almost *no* loss, *and* fsck's in fewer seconds than you have fingers even 
>> after that!), then we should seriously consider using it, if we can find 
>> one and "nurture" it.

Agreed.  But even if we 'nurture' an LFS, we should stick to ext2fs 'till
it's matured.

In order to deal with a power-off issue, we should make our start-up
fsck procedure explain in no uncertain terms, why it is unhappy with
the user for leaving a dirty FS lying around.  We should also do our
best (though this is a seul-dev-install issue) to enforse a reasonable
partitioning scheme, so that a frequently-written partition (/home or /var)
doesn't interfere much with / and /usr.

>An LFS would be REALLY pointless for the home user...  For all they care,
>syslog.conf needs one line:
>*.*					/dev/null

Frankly, I don't see the connection between an LFS and a syslog.   The purpose
of an LFS is to ensure FS continuity by preventing data corruption; a valid
copy of a file can almost always be reconstructed.  Syslogs have little to
do with it.

As for the syslogs, (though this as a seul-dev-admin issue) I disagree that
the end-user should have no contact with the syslogs.  We should process
them as much as possible, certainly, to keep the user from having to grovel
over meaningless messages, but I still think we should inform them of
significant happenings, such as failed logins, urgent kernel errors, attempted
SYN-floods, suspicious mail-spoofing, and so forth.

I'm going to post a request for research to seul-dev-admin tonight, asking
for people to hunt down useful admin frontends.  In this area, I'm rather
leaning towards a marriage of Roger's proclog filter and the Gtk log-viewer
(written by Cesar Miquel) which (IIRC) Gnome is supporting.  (See