Re: Corel/Debian Linux Installer
Craig Sanders wrote:
>On Mon, Aug 16, 1999 at 12:07:04PM -0400, Christopher W. Curtis wrote:
>
>> The biggest problem with partitioning is planning. How much space
>> do I need? How much should I allocate? Is it enough? Too much?
[...]
>improved documentation is the answer to this planning problem.
RTFM is fine if you want everybody to become an expert in every arena of
their lives, including computing. Unfortunately, that's just not the way
life is. This attitude retains computing for the traditional computing
elite. That may be fine for Debian if end-user/new-users have no place
within the Debian community; however, it also alienates even quasi-competant
users who have become accustomed to the environment but not to the Faith.
Can users be totally ignorant their systems? Well, many of them are, like
it or not. "Well, they're not running Debian". Obviously - especially if
it requires they know the most intricate details of the system before they
can even properly install it. Maybe for these people one huge data
partition is fine - this seems to be a common trait of many messages I've
gotten - "partitioning? Who cares?!?" And rightly, who does? Maybe I'm an
oddball still liking partitions. DOS used partitions because of fs
limitations. I use them as a tool. Maybe a LVM will solve all of Unix's
problems. But it is not fair to know beforehand exactly which of the twenty
thousand packages the installer might find interesting and how much disk
space they use and how the are going to consume other system resources from
the outset.
>there really isn't any "one-size-fits-all" answer to partitioning
>disks. the "correct" partitioning scheme for any machine depends on the
>intended use for that machine. e.g. a workstation probably needs a huge
>/home, a server probably needs a huge /var or /var/spool (e.g. mail
>server needs a big /var/spool/mail, web server needs big /var/www, proxy
>server needs big /var/spool/squid)
Which is why I said that .deb might want to include an item to give an
estimate of a package's demand of resources in /var. It seemed to me that
if the system could say, "Hey, I see you want to install all this stuff.
Well, you're going to need at least this much space here, and probably
something like this much space somewhere else. I'll stick all the extra in
/home for you." And then let them decide. Someone running high intensity
mail or www or squid services probably won't want to do them on ext2 anyway
- they'll create a RAID mount for these. I am not suggesting removing
options from the power user; simply making it easier for the beginners.
Remember that everyone was a beginner at one time. And from that
perspective, which do you suppose is better: "Tell me how you want your
partitions so I can proceed", or "What to you want to install? Ok, how
about a layout like this:?" Computers are _supposed_ to make things easier.
To me, the "one big partition" seems like a lazy way out. But that's just
my opinion. However, it makes me curious then to see so many dists trying
to make partitioning easier. Like Disk Druid (disaster that it is). Why
not just setup one huge partition and then make dropping into a partitioning
program "experts only"? That is what has been insinuated. I guess some
manner of consistency would be best. Default to all one partition if that
is the best solution. Personally, I'd like to know how much disk space I'm
using when I install. Debian does not allow this now - it has several
"tasks" with overlapping packages and no indication of how much space is
going to be used when you press "start install".
I like the Solaris install.
>> not; don't force it as though it were. Leave partitioning to later;
>> for example, until _after_ they have chosen the software to install.
>
>no, that doesn't work. debian needs the disk(s) to be partitioned so
>that the base system can be installed before packages can be selected.
>
>the way debian does it now is the right way. it's not perfect, and
That is a matter of opinion. It may be The Right Way because it is The Only
Way due to a design deficiency in the installation proceedure. You may not
like this opinion, but that is how I see it. And you have every right to
disagree - I am not interested in pissing contests.
>another reason why this is a bad idea is that it is too limiting - it
>forces you to follow the standard install procedure perfectly, with no
>deviation. this is OK if you're only building one machine but would be a
>complete PITA if you were building dozens or hundreds.
This statement is nonsense. It makes installation easier because there are
reasonable defaults from the outset based on the selection your have made.
You can proceed without prior knowledge. And there is nothing about it that
prevents automated installations. In fact, they needn't change at all from
how they are currently done because in theory it is irrelevant what blanks
are filled in first: packages, or partitioning. Any deviation between
theory and practice is a shortcoming in the implementation.
>by contrast, the current install disks allow you to just go through
>the initial stages to get the disk partitioned and the base system
>installed, and then you can install the rest of the system any way
>you like - follow the standard install, or do whatever you need to
>mass-produce a machine.
I will admit that I haven't attempted to do this (flame away if you must -
I've been on usenet enough to realize that it is easier to attack a weakness
than to respond in whole in sincerety) but let's see the contrast for real:
Now (from your definition):
partition
install base
make modifications (if desired)
finish install
"My" way:
load package list (custom or predefined)
make modifications (if desired)
finish install
I fail to see where "my" method is more limiting, more difficult, or more
intrusive.
>> debian install can say, "I see what you want to do, and I think this
>> is a good disk layout for you. Accept/Resize".
>
>and what if the user's response is "that sucks - whoever wrote this
>installer has NFI what i need on my system!!!"?
Then they'll do exactly what I do when a program says I should put all my
files in one huge directory - they'll chose to "resize" and lay it out just
they like would have to anyway under the current scheme of lay it out first,
and always do manual layout.
>the trouble with automating stuff to this point is that it only helps
>those who probably shouldn't be building their own systems anyway (and
Ahh, the elitist argument. I suppose that everything I've said in reply has
been in vein. It is no matter. I'm not here to sell you on my way.
I don't have to, and have no interest in knocking you off your high horse.
>even then they would still be better off if they were taught how to
>do it properly rather than spoon-fed and "protected" from the gory
>details). the price of that "simplicity" is causing grief for those who
>do know what they are doing.
Does it not seem reasonable that the people who know what they are doing
might help design the system that makes the initial layout suggestions? Or
does expert knowledge simply not transfer out of one's head into the
software they write and influence?
>> /etc -- small, 16-32MB, mounted read-write, 0% reserve
>/etc has to be on the root fs.
It does. So does /dev. Which is why I admitted my error previously.
>it worries me that someone who doesn't know essential things like that is
>proposing an "improvement" to the way the debian install works.
You know - I may not know anything about how an internal combustion engine
works and how gas gets from the pump into pollution, but I can tell that if
you run into a GM minivan and the gas tank explodes that there's a problem
that can probably be fixed by tinkering with the gas can.
Craig Sanders further wrote:
> very true. these days with *minimum* disk sizes of 3 or 4 gig, it's not
> worth the bother of making lots of little partitions...once you've
> decided that / is going to be small then you have no choice but to make
> separate partitions for /usr, /var, /home, and probably /tmp.
Well, as I've said, I think that /, /usr, /var, and /home should be their
own partitions anyway. The problem with /tmp, in my opinion, and that Linux
lacks a "swapfs" like Solaris. I personally will live with a small /tmp
because I do little that requires a lot of /tmp space (most of the
importanat stuff goes into /var/tmp anyway) and I figure that by the time
I need it, there will be a reasonable "swapfs" partition. And preferrably
one with better resource constraints than I've seen on Solaris.
> i generally don't mount / or /usr as read-only so there's little or
> no point in putting them on separate partitions - they're going to be
> fsck-ed after a crash anyway.
That's fine for you. I'd prefer not to wait for a fsck of /usr when nothing
has changed. As you've demonstrated yourself, / can never be mounted
readonly. You make me question your own credibility now ... (a hint of
sarcasm here, but not too much).
> i find that creating arbitrarily small partitions actually causes
> hassles anyway - it's bloody irritating to have gigabytes free in /var
> or /home but be unable to install anything because /usr is nearly full.
> apart from making an ugly mess of symlinks, the only way to get around
> that is to backup everything, repartition, reinstall, and then restore.
You can also try your luck with resizefs.
> - however it is partitioned, the /usr directory should have at least a
> gig, preferably two.
One gig wastes (as I found out _after_ installing) around 450MB on my
machine acting as a dedicated broadcast station - 450MB which could be used
for holding more MP3s. I've created a symlink to use this extra space, but
now I can't mount that filesystem readonly. For someone who was just
complaining about wasted space due to bad partitioning, you seem to be
having some sort of split personality dysfunction here...
> - /var directory needs lots of disk space, especially on servers which
> do a lot of logging. minimum 250MB. preferably 500MB or 1GB. unless
On all the workstations I've installed, I've left /var at 64MB and have
never had any problems. If I ever found that this would be problematic, I'd
go to 96MB before using another whole GB.
> - on a workstation, /home gets a few gig...whatever is left over after
> /usr and /var are catered for. on a server /home is irrelevant.
Everything you've said sounds almost exactly like what I've said, with the
exception that I think the install can make a reasonable guess about the
space needed for (primarily) /usr, but possibly also /var. If they don't
install sendmail, squid, or apache, they probably don't need a huge /var.
And I like having /home on the server, as do most of the people I work
with. It is a good thing to log into any machine and have the same /home
directory. My biggest concerns have been what to do with the space I would
normally put in /home. The user of the workstation should probablly have
access to that, but without a "network raid" filesystem it cannot really be
properly utilized. I don't know if CODA fits this or not, but I suspect it
doesn't. I searched a few years ago and don't think it was CODA that
I found. AFS maybe? Anyway...
[more relatively uninsteresting way to partition a drive]
> in summary: disk is cheap and plentiful these days. worrying too much
> about partitioning is counter-productive.
To this I'll agree. If it's a simple change, no other dist does it and
there's no good reason for it not to. Debian is by far the best dist
available (though it is lacking a lot of 'polish' in regard to other dists)
and its biggest hinderance according to those in the press is the install.
As I said in my first email, this is what everone harps on about, and it is
one of the biggest wastes of effort (you're pretty much only going to do it
once) but I know Corel is working on it and if they're going to do it, I
think they ought to do it Right.
Whatever that may be.
Christopher
Reply to: