Corel/Debian Linux Installer
Hello all (not on list),
I just wanted to say hi and drop a suggestion about the install. Debian's
install is a thing of beauty, much in the same way that a baby ravenous
predator beast might be. So I'd like to address this primarily to the
people working on Corel's installer for Debian.
I mist first say that I have not seen the installer; I've seen some screen
shots but all that is eye candy is not all which is useful. The most
confusing thing for many people is how to partition the hard drive. Red
Hat and Caldera take the approach that a bad partitioning is better than
none, and tend to create a swap partition and then a single huge partition
for data. Or two. This is foolishness.
The biggest problem with partitioning is planning. How much space do I
need? How much should I allocate? Is it enough? Too much? Should I
reserve 5% for root or not? These are questions that the new user, and
even experienced users, would most likely prefer not to deal with. And
yet they are continually forced to. Why is this? Poor installations.
Even the slick installs are poor.
So how do we make the debian install better? The answer, at least to me,
seems simple: Do not make disk partitioning priority one. It is not;
don't force it as though it were. Leave partitioning to later; for
example, until _after_ they have chosen the software to install.
One there is a list of packages to be installed, the installer knows how
much disk space will be needed. The .deb format doesn't allow this, but
it would also be good if information could be kept as to how much space
these packages require in /var. With this information, the debian install
can say, "I see what you want to do, and I think this is a good disk
layout for you. Accept/Resize".
Also, I would like to try to emphasize filesystem layout on the partitions
so that they can be used most effectively:
/ -- small, 32-64MB, mounted readonly, 0% reserve
/etc -- small, 16-32MB, mounted read-write, 0% reserve
/usr -- dependent on packages selected, readonly, 2% reserve
/var -- dependent on packages selected, read-write, 5% reserve
/opt,/usr/local -- medium, read-write, 2-5% reserve
I say read-write for /usr/local/var, etc.
/home -- remainder, read-write, 2% reserve (assume large)
The key being readonly status being assigned to filesystems where it is
useful and makes sense, the rest are just eh guidelines that I've used in
the past and which have worked well. /lib may be a problem with kernel
modules living there, but I don't think it would be. Additionally, there
are exploits for Linux that have to do with replacing kernel modules;
while this won't prevent this, it might trip up some script kiddies and at
least give another tripwire.
And on another aside, I think that /usr/share/doc is a good idea; this
isn't binary data and can safely be exported/remote mounted.
$0.02, but _please_ pick packages first.
And then configure while installing in the background, like OpenLinux.
That is very slick.
Regards,
Christopher
Reply to: