Re: Corel/Debian Linux Installer
While I am not involved in the Corel installer project, there are a few things
that need to be dealt with. (Comments inserted in the appropriate places)
On Mon, 16 Aug 1999, Christopher W. Curtis wrote:
> Date: Mon, 16 Aug 1999 12:07:04 -0400
> From: "Christopher W. Curtis" <ccurtis@aet-usa.com>
> To: debian-devel@lists.debian.org
> Subject: Corel/Debian Linux Installer
> Resent-Date: 16 Aug 1999 16:22:49 -0000
> Resent-From: debian-devel@lists.debian.org
> Resent-cc: recipient list not shown: ;
>
> 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.
I agree with you here, more intelligent "Default" partition sizes would be nice
for new users, as well as more advanced users.
> 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.
You should always save 5% for root, simply to avoid potential data corruption
issues(how many people have found that when disk space runs out, that files
arn't there anymore, even when they are listed in the ls output?)
> 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.
The problem with this is it forces the minimum ammount of RAM to be larger to
handle the package list. We need to allow for people with 4 or 8 megs of RAM.
> 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".
I believe that apt can handle this issue, though would need a few modifications
to check for how much goes under each partition.
>
> 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)
I've never cared for /opt. If you plan to install a "foreign" package,
/usr/local is much more common and standard. /opt also feels too much like
Solaris, which is the only UNIX type system I have seen that uses it. Also, the
total size of the hard drive would need to be taken into account, since I've
been hearing from a number of people trying to install on 384 meg hard drives
they had in a closet. Overall, it's not a bad idea, and is similar to the idea
that I put forward about module selection being done BEFORE installing the base
system because of hardware driver issues. I would do a RAM check before using
your idea though, to make sure there won't be any issues.
Dave Bristel
> 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
>
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
Reply to: