Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 14 Jul 2000 18:05:26 -0700 (PDT)
From:      Matthew Jacob <mjacob@feral.com>
To:        Alfred Perlstein <bright@wintelcom.net>
Cc:        arch@FreeBSD.ORG, marcel@FreeBSD.ORG
Subject:   Re: I'm fixing the build/install kernel target
Message-ID:  <Pine.BSF.4.05.10007141754320.5888-100000@semuta.feral.com>
In-Reply-To: <20000714175620.R25571@fw.wintelcom.net>

next in thread | previous in thread | raw e-mail | index | archive | help

> Being better than Windows isn't really aiming that high now is it?

That's not the point. The point here is about what sophistication we
expect from users.

The slightly more sophisticated then average windows user will dork with their
registry and leave their system in an unusable state. This also include users
who, on installing new versions of not so bright software that does this for
them, have to do a forklift upgrade afterwards. Most Windoze users have come
to expect this "every system knob ties directly to 3 pound of plastique!"
way of doing business.

*BSD, like Unix has always been, is still a shipped toolkit, but unlike 10
years ago we expect these systems to be usable after install for nearly all
user environments. That is, a kernel reconfiguration should rarely be
required.

If it is required, the steps are fairly straightforward to do so, but the
assumption still is that the users are smart enough to know which end of a
sabre saw to grab- there are very, very, few violations of the Principle of
Least Surprise here. I don't see much utility in spending a lot of cycles come
up with child safety locks in this area.

If you feel that kernel reconfiguration is a must for the novice user (the one
who might get bit by not paying attention to overwriting a bootable kernel,
i.e., not using the current 'make install', which will most certainly leave
you with a bootable kernel/modules set if the new one is wrong), then instead
of making this process super safe, I suggest that the install tools are a
better place to do this. We should then take the approach that, say, Tru64
takes, and reconfig and rebuild a kernel specific for a user's configuration
as part of the install process.

-matt




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.05.10007141754320.5888-100000>