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

Re: Bug#652275: Guided partitioning should not offer separate /usr, /var, and /tmp partitions; leave that to manual partitioning

Hi Josh,

Seems you're as much passionate about this topic as I am! :)
At this point, I don't remotely hope to convince you, but perhaps you
will find some of my points valid.

On 12/17/2011 02:46 AM, Josh Triplett wrote:
> Hence why I said "most people" (because I didn't want to imply
> unanimity), but there's a difference between "consensus" and "complete
> lack of dissent".  In any case, note that I specifically mentioned
> separate /usr as a special-purpose configuration, not other separate
> partitions.  I don't want to argue here that no possible reason exists
> for separate /usr (that seems like another argument entirely, and a
> mostly orthogonal one); I simply suggested that it represents an
> uncommon configuration.  Do you really disagree with the statement
> that separate /usr represents an uncommon configuration?
>> On 12/16/2011 04:46 AM, Josh Triplett wrote:
>>> Meanwhile, we don't want to steer any new users towards a setup with a
>>> pile of different partitions, which makes their system more complex with
>>> more potential failure modes.
>> I hope that we are still the universal operating system,
>> and that we don't want to force anyone to do anything.
>> If I want to use many partitions, this is *my* call, and
>> not everyone's business. Please don't try to force your
>> view on partitioning to anyone.
> Nobody stops you from using as many partitions as you like.  I've
> suggested a change to the guided partitioner, which exists to make the
> most common partition configurations easy, and to steer new Debian users
> in the direction of configurations which will work well for them and not
> give them too much trouble.

But I do not agree with your steering, just for the sake of making it
more easy. We shouldn't only target "most common partition
configurations easy", there's isn't a "one solution fits all", but
really some choice depending on your needs. Showing to our users that
separate /usr, /var, /tmp and /home can be a good choice is also
important to me.

Pushing users to do encryption would also be great. The Debian installer
shouldn't only aim to be easy: it should do the job and do it well.

I'd be happy if we had a partionner which could do as much as we can
with right now with partman (which is: a lot!), just more efficiently.
In other words: I'd like to do more complicated things faster.

> A configuration with everything in one partition needs no extra
> configuration; anyone who wants such a configuration will like what the
> guided partitioner comes up with.

Of course, anyone who wants X will like X... What if I like Y?

> A configuration with five separate
> partitions seems almost impossible to provide sensible proportions for
> that work for everyone without editing. And getting the proportions
> wrong means people have to deal with strange and annoying cases like
> /var filling up when /home has tons of room, or / filling up when /usr
> has tons of room.

Sometimes, you just don't care about partition sizes, you just want them
to be there automatically (as long as there's a separate /var and /tmp...).

But well anyway, that's a valid reason for giving *more* template
choices and control in partman not less! :) Indeed, I'd be cool to
select such layout, then just quickly just enter sizes on the LVM,
without having to define types and mount points manually (which takes
soooooo muuuuuuch time).

I have tried multiple times to convince Otavio at the last Debconf11
that I believed partman should also be providing templates with RAID1 /
RAID10 setups, since a lot of people are using it in the server room. I
had a hard time, and I think he stand in your side for less choices,
since his answer was that I should make a custom ISO for myself (which
doesn't satisfy me, really).

>>> Please consider removing the option in the guided partitioner for
>>> separate /usr, /var, and /tmp partitions; that would leave only the "All
>>> files in one partition" and "Separate /home partition" setups, both of
>>> which potentially make sense for users of the guided partitioner.
>> Please don't remove the above option, I like it, and I
>> don't see why it needs to be removed just because
>> you Josh (and maybe others) don't like/use it.
> That line of reasoning would never let Debian remove *anything*, ever.

We have debconf priority and the expert install mode for a reason. If
you said you want to remove some templates from the non-expert
installer, then I'd say it's a good idea. But not for the expert mode.

>> You feel like a separate partition for /home is useful.
> Actually, I don't, but I didn't advocate that today. :)
>> Good for you, and your desktop. But when it comes
>> to servers, the /home separate partition is useless,
>> and having a separate /var makes things faster.
> Exactly my point, then.  The guided partitioning option I mentioned
> makes /home, /usr, /var, and /tmp all separate partitions.  You just
> said you don't want a separate /home, and you do want a separate /var.
> Thus, you have custom requirements that don't fit the guided option, and
> you'd need to use the manual partitioner instead.  I argue that the same
> holds true for almost anyone who might want something similar to that
> guided option: they don't actually want what the guided option provides.

If your point is to say that partman can do everything BUT it's GUI
isn't convenient, then would agree. I'd really love to have more
predefined templates, and only change sizes only, and there really,
partman missed the point of templates. On an average server install, I
spend like half of my time in it. Ideally, it'd be really a cool feature
to be able to scp/ftp an HDD template directly from the installer (both
ways: load and save).

>> Also, having a separate /tmp avoids that the rootfs
>> gets full, and I consider it quite important especially
>> on servers. I would recommend using it for absolutely
>> *every* setup (desktop or servers) as a security measure,
>> especially considering any application can fill up the
>> temp space.
> Note that newly installed Debian systems have /tmp on tmpfs by default.

I'm not so sure I will like the "improvement" of eating my RAM when a
program is explicitly asking to write on a storage medium, but we'll see
if I like it. :)

> Also, it really doesn't matter for single-user systems, only for
> multi-user systems with untrusted users.

With untrusted users, I think I'd implement quotas for writing in /tmp
(it was like that under OSF1 10/15 years ago...). But when you have
separate /usr and /var, your rootfs can be very small, so you don't want
any random program, for a valid or an invalid reason, fills your rootfs
with anything until it's full. I've seen MySQL doing that for example,
and was very happy that my dedicated /tmp showed it to me (and that's
only *one* example of what can happen in a normal usage of a computer
running Debian).

> Distributions *exist* to make choices for you, most of which you don't
> care about.

One of the reason I like Debian is that it gives me the choice to have
the choice (eg: debconf priority is configurable).



Reply to: