Installer options I'd love to see

[Moem]

Many of us consider it pretty ideal to have a separate /home partition instead of having the home directory live in the same partition as the OS itself.
I'd love it if the installer would have an option to do that more or less automatically. It would probably be the best option for novice users who don't yet know anything about editing partitions by hand. So the options could look somewhat like this (but in better wording):

• Installation as the only OS (This will erase and overwrite data that is currently on the disk)
  • - Recommended installation: create three new partitions [description of partitions, one of which is /home]
    - Simple installation: create two new partitions [description of partitions]
  Installation next to an already present OS
  • - Recommended installation: create three new partitions [description of partitions, one of which is /home]
    - Simple installation: create two new partitions [description of partitions]
  Something else (advanced options for experienced users)

It would probably result in many, many newbies ending up with their data separated from their OS even if they did not know what that means. That sounds like a Good Thing to me. I've heard that Fedora does this, so I assume it was a concious choice not to adopt this system, but I can't fathom the reasoning.

[austin.texas]

You are right.
I think there is an amazing lack of explanation and guidance in the installation program. We regularly see questions about what to do, and how - many of which could be easily answered by adding tooltips and other guidance.
The questions we see about "no root defined" are a good example. For someone to have to ask that question is simply unacceptable.
I am not a programmer, but it can't be that difficult to add more text or popup tooltips.

[Moem]

I am not a programmer, but it can't be that difficult to add more text or popup tooltips.

I fully agree, but what I really meant (and maybe I wasn't very clear) is this:
I'd like to suggest changes to the installer that make it so that if you do not adjust anything, and just keep hitting Continue, you'd end up with an installation that had a separate /home partition.

Right now, if I want that, there is no automatic way to do that, no option I can even select (far less a default that's preselected). I'll have to dive in with the partitioning tool, and that is not self-explanatory or intuitive at all. Complete newbies won't usually manage it. I certainly didn't!

[austin.texas]

I'd like to suggest changes to the installer that make it so that if you do not adjust anything, and just keep hitting Continue, you'd end up with an installation that had a separate /home partition.

The installation program is not a Mint team product. It comes from Ubuntu (Canonical).

[Moem]

Ah, thank you for that information. That's good to know.

[Cosmo.]

The idea is worth to support.

But I see some difficulties:

#1: As already noted, the installer comes from Ubuntu. This reduces IMO the chance of a change. So the Mint team would have to fork or replace it. And this is a matter of developer resources and priorities.

#2: Numerous situations would have to be considered. Only as examples (leaving swap out of consideration for better understanding):

Suppose the system has only one drive. How would you assign to / and to /home in case you have left:

• - 50 GB
  - 100 GB
  - 1 TB

Surely not the same amount for / partition in those cases.

Suppose you have 2 drives:
/ on first drive (perhaps a SSD)
/home on the second:
Seems logical. But how to handle the situation, if on the second drive is already a data-partition? Maybe the user wants to leave this drive untouched as a backup of his data. Nothing, what a software can decide by its own, so the user has to get asked - and then he might get confused. In the worst case he makes the wrong decision and looses all of his data.

All that is not unsolvable; I simply want to show, that doing such a thing is not so easy as it might appear at the first sight. This means it will take time.

[Pjotr]

I don't think it's a good idea, because I consider a separate /home partition to be a needless complication.....

Needless, because you must have *external* backups of your documents anyway.

Needless too, because with up to five years of support for a Mint version, with easy in-place upgrading within a series, the "clean upgrade" issue (clean upgrading is easier with a separate /home) is no longer as important as it once was.

And even worse: on small hard drives, a separate /home causes too often a non-optimal allocation of disk space to either the /home partition or the / partition. Causing lack-of-space problems.

Furthermore, multiboot machines (with several Linux OS'es alongside each other) get a far too complicated partition structure with separate /home partitions.

[Moem]

I don't think it's a good idea, because I consider a separate /home partition to be a needless complication.....

Needless, because you must have *external* backups of your documents anyway.

Surely it's even better to do both? No one makes a backup every hour.
And there are advantages that differ from those that a good external backup obviously has. If only to replace a damaged install quickly and easily.

And even worse: on small hard drives, a separate /home causes too often a non-optimal allocation of disk space to either the /home partition or the / partition. Causing lack-of-space problems.

I'd assume that can be detected, and in that case, the option could not be offered.

Furthermore, multiboot machines (with several Linux OS'es alongside each other) get a far too complicated partition structure with separate /home partitions.

People who are running several distros of Linux probably know what they're doing, and would not be very likely to need or use such an option.

But you did make me think. Maybe it's better to only offer this option for installs that are meant to be the only Linux OS on the disk, in other words: when no Linux install can be detected. After all, that's the typical newbie situation.

[Cosmo.]

Pjotr,

the question, if a separate home is useful or even an advantage, has been discussed several times. It is obviously, that there are different opinions, probably not coming to an agreement.

But this is about the question, if the installer should provide an user-friendly way to make a separate home. As I showed here, even Clem thinks about this matter.

In this linked thread some of your arguments given here have been answered - needless to rewrite the answers. Regarding this:

Needless too, because with up to five years of support for a Mint version, with easy in-place upgrading within a series, the "clean upgrade" issue (clean upgrading is easier with a separate /home) is no longer as important as it once was.

You have obviously overlooked one point. Although the LM 17 branch gets support for another 3 1/2 years, there will be - as far is I understand - no more feature enhancements (which also include bug fixes, as the change log for LM 17.3 shows) in this branch. LM 17.3 is - again: in my understanding - the last point release for this branch. Users, who don't want to stay statically on that level until 2019, have to upgrade to LM 18 in half a year.

If we expect, that LM 18 will be a significant improvement - as the previously released new Mints have always been - it is more likely, that the users (I am included) want to do the upgrade than that they want to stay with the LM 17 branch. So the argument with the in-place upgrading has ended (or will end for KDE and XFCE edition in a few weeks). Why should the users be expected, suddenly not to want the enhancements, that the LM 18 branch will bring in the next 2 years? The future of LM 18 does not begin in 5 years, not in 3 years, but in 6 months.

So at the end: 5 years of security and stability fixes: Surely, without doubt. But that does not mean 5 years of feature enhancements.

Simply compare LM 13 with LM 17: What I big difference! I wouldn't want to miss the enhancements, that the system got. This has nothing to do with the fact, that LM 13 still get support until 2017.

I think, that we both belong to the users, who have a good overview about the system, which others use and post their questions about in this forum. The vast majority uses a LM 17 version and many of the LM 13 users stay with it because of hardware limitations (PAE, available drivers for old hardware, limited hardware resources).

[Moem]

this is about the question, if the installer should provide an user-friendly way to make a separate home. As I showed here, even Clem thinks about this matter.

Cosmo., thank you for that link. I have searched for previous suggestions of a similar nature and not found them, while I was sure that this idea must have been thought about many many times. It's so logical after all, I knew it could not possibly be new. You dug up some interesting information!

[MartyMint]

I don't think it's a good idea, because I consider a separate /home partition to be a needless complication.....

I agree. I think gives people a false sense of "backup" ease-of-use.
Just do drive imaging and use the "incremental backup" feature in your backup program, if it's available.

[Pjotr]

I don't think it's a good idea, because I consider a separate /home partition to be a needless complication.....

I agree. I think gives people a false sense of "backup" ease-of-use.
Just do drive imaging and use the "incremental backup" feature in your backup program, if it's available.

So it is. Only copies on *external* media have real backup safety value.... There's no data safety when backups are on the same disk or even in the same machine. And a separate /home isn't even a backup at all.

The only advantage of a separate /home is easier re-installations of the same Linux Mint version (and easier upgrading to a newer Mint series, if you don't mind some pollution from old settings). Which I consider to be a pretty small advantage when compared to the disadvantages that I outlined in my earlier message in this thread.

In the period 2007 - 2009 (approximately) I always used a separate /home myself. Then I realized that instead of making life easier for me, it actually created *more* problems and bother. We live and learn.

[Moem]

Pjotr, in my view the disadvantages you mention don't stand up to scrutiny. Let's look at them one by one, if you don't mind.

I don't think it's a good idea, because I consider a separate /home partition to be a needless complication.....

Needless, because you must have *external* backups of your documents anyway.

Needless is not a disadvantage.

Needless too, because with up to five years of support for a Mint version, with easy in-place upgrading within a series, the "clean upgrade" issue (clean upgrading is easier with a separate /home) is no longer as important as it once was.

As we've seen pointed out, with Mint18 coming up, that doesn't hold water. Many users will want the new features that come with the new version.

And even worse: on small hard drives, a separate /home causes too often a non-optimal allocation of disk space to either the /home partition or the / partition. Causing lack-of-space problems.

I've already refuted this: small drives can be detected, in that case the option can simply be hidden (not offered).

Furthermore, multiboot machines (with several Linux OS'es alongside each other) get a far too complicated partition structure with separate /home partitions.

Like I said: now we're talking about users who are unlikely to use or need such a feature. They would most likely be capable of doing their own partitioning.

Indeed, we live and learn, but we do not all come to the same conclusions. And that is fine! To each their own.

[Pjotr]

Needless is not a disadvantage.

Yes it is. A simple technical solution is *always* better, even if the end result is the same as with a complicated technical solution. Simple is an advantage of its own.

Many users will want the new features that come with the new version (Mint 18).

Even so: it's better to start without potential pollution from old outdated settings from the former series.

small drives can be detected, in that case the option can simply be hidden (not offered).

More complications, and therefore more risk of bugs in the installer....

Indeed, we live and learn, but we do not all come to the same conclusions. And that is fine! To each their own.

With that I can agree.

[Cosmo.]

Small drives - although this case happens here and then - are today a specialty, not the usual case. so this "disadvantage" affects a minority. The installer options are supposed to support the majority.
If I take a look at my computer-online dealer I find the smallest drives with 250 GB size.

And as the argument goes about "documents", it is obvious, that this is about home. I have not the least imagination, how backing up the home should get only the smallest bit more complicated. In fact, that makes no difference for an usual backup. But - in the contrary - if the user wants to do an image backup of his home (and only home!), than the separate home partition is obviously the only possible way to accomplish that.

So the "disadvantage" arguments morphs into the contrary.

Multiboot: Although not so seldom, this is also not the usual case. I have a multiboot system (Linux only) with all systems having a separate home. I don't see any complicated partition structure. I admit, that I give after installation all of my partitions a label, which makes the usage of the partitions very easy to identify. I only have to read the labels.

So the real solution would not be to "ban" separate homes, but to integrate the labeling of partitions in the installer. Of course no user should be forced to label, just as no user should be forced to separate his home.

In the starting post M0em wrote "I would love to have an option ...". If this wish should be qualified as to complicated, the whole "something else" mode would at first have to get completely removed. (No, I do not vote for that.)

But I understand, that with such an option the likeliness, that more system gets installed with separate home partitions, will increase with the advantages for those, who accept this option.

[Cosmo.]

Many users will want the new features that come with the new version (Mint 18).

Even so: it's better to start without potential pollution from old outdated settings from the former series.

We all have known Clem to be a developer, who really cares about the stability of the user's system.

We have also learned in the last year, that the upgrade feature - introduced with LM 17.1 - works very reliable and is the recommended way to upgrade.

Do you believe, that Clem will throw his philosophy over board? Or how do you else explain, that Clem has plans, to make the upgrade also from 17.x to 18 to an easy upgrade process and will - if things proceed, as he plans - recommend this also?

[Pjotr]

We all have known Clem to be a developer, who really cares about the stability of the user's system.

We have also learned in the last year, that the upgrade feature - introduced with LM 17.1 - works very reliable and is the recommended way to upgrade.

Do you believe, that Clem will throw his philosophy over board? Or how do you else explain, that Clem has plans, to make the upgrade also from 17.x to 18 to an easy upgrade process and will - if things proceed, as he plans - recommend this also?

Of course I think that Clem is an excellent developer, and I fully support his development vision for Linux Mint. No doubt about it: Linux Mint is currently the best that desktop Linux has to offer. More than that: I think Linux Mint is the finest desktop operating system in the world.

However, that doesn't mean that I should agree with *everything* Clem does. If I would, I wouldn't publish my "first things to do after install" lists, for example.

[Cosmo.]

No one says, that you have to agree with everything. Also nobody will prevent you to skip the upgrade to LM 18 at all or do to do it the old school way (assuming the planned upgrade feature will come) and to ignore the (planned) recommendation.

But writing about potential pollution - you did not say "probably" - and your conclusion, that is better to start without that pollution sounds, as if you start from the expectation, that this will happen, even if the upgrade recommendation should arrive as planned. In Contradiction to that I do not assume, that this happens and consequently I do not accept your pollution argument as a valid argument against the separate home. My experience with my home, which has not been erased when I upgraded from LM 16 to LM 17 1 1/2 year ago confirms my assumption.

BTW: I do not expect that there will an direct upgrade be possible for LM 13 systems. Simply because also Ubuntu only supports upgrades between directly following (LTS) releases. On the other hand the planned upgrade mechanism is nothing what made me surprise. I did expect this already a few months after the (at that time new) upgrade option for LM 17.1, 9 months ago.

Another BTW (and very private opinion): I would also not be very surprised, if the release of LM 18 would be somehow later than usual (end of the second quarter of the year). As long as LM was based on the STS (= non LTS) versions of Ubuntu, a quick appearance after the release of the based Ubuntu version was necessary, especially after Ubuntu shortened the life time of the STS versions to 9 months; otherwise the latest Mint (16 in this case) would have been without updates. But as we now have only LTS-based Mint versions, the time pressure is more or less gone. After the release of Ubuntu 16.04 Mint 13 will have another 12 months of support, so that a part of this time could be used for further development and testing.

[Pjotr]

@Cosmo. : you might find this IRC chat interesting, that I had today with Clem.

My intention was to discuss an idea of mine, to only allow an in-place upgrade from 17.x to the 18 series, after the release of 18.1 (so not directly after the initial 18). Just like Ubuntu does: an in-place upgrade of 14.04.x to the 16 series, will only become possible after the release of 16.04.1 (the first point release).

This is how it went:

Code: Select all

* Now talking on #linuxmint-dev
* Topic for #linuxmint-dev is: Roadmap @ https://github.com/linuxmint/Roadmap, Developer Center @ http://projects.linuxmint.com    Specifications are for the weak and timid!
* Topic for #linuxmint-dev set by mtwebster!quassel@linuxmint/team/mtwebster (Thu Oct 29 15:50:46 2015)
<pjotr> clem: I have a suggestion for the upgrade path to Mint 18
<pjotr> I prefer a clean upgrade myself, but I've read that you're considering an in-place upgrade of 17.x to 18
<pjotr> I think such an in-place upgrade should only be offered after 18.1 has been released. Just like Ubuntu LTS: the upgrade path for an older LTS, is only made available after the first point release of the new LTS.
<pjotr> That provides maximum upgrade safety, because many bugs in the new LTS will have disappeared by then.
<pjotr> The same will be true for 18.1, when compared to the initial 18.
<clem> pjotr, I understand the rationale, but with the same logic you'd wait for 18.2 or even 18.3?
<clem> we've two audiences to cater for here:
<clem> 1. people who WANT to upgrade no matter what
<clem> ^ and these will want to upgrade at 18 without waiting another 6 months
<clem> 2. people who don't mind too much or don't know much about it
<clem> the challenge is to please both
<clem> the way we do that is by keeping audience #2 on Mint 17.x until 2019
<clem> while making it possible for audience 1 (no # sign thank you very much mintbotd) to do what they want, easily and as soon as they want to do it
<pjotr> clem: no, because the first point release of the Ubuntu LTS (for example: 14.04.1) is always with the same kernel series and graphical stack as the original LTS (for example: 14.04). The next point releases have newer kernel series and newer graphical stacks.
<clem> inner 17.x upgrades are trivial of course and can't be compared to 17->18
<clem> but from an audience point of view, it's similar..
<pjotr> the first Ubuntu point release is about bug removal only
<clem> that's great on paper but we won't know what's at stake until it's almost ready
<clem> it largely depends on what the Ubuntu release is like, how stable etc..
<pjotr> clem: that's true. Good luck with all the work you're facing! :)
<clem> My feeling is that our audience is mostly silent
<clem> it's really hard to assess because we went from a tiny little project in 2006 driven by really vocal people
<clem> to a really mainstream OS
<clem> and especially now that we turned our back on non-LTS and modern desktop paradigms
<clem> more than ever before, we're losing the vocal minorities
<clem> so our top priority should be to make sure things don't break
<clem> and to be conservative with updates
<clem> but we still have to acknowledge demand and expectations
<clem> that expectation is that you can upgrade, if you feel like it
<clem> the 18 upgrade path is probably going to be very treacherous, and so we might not recommend it to everybody, but we'll need to work on it and at the very least propose something to people willing to risk it
<clem> if you look at 17.x upgrade paths, even though they're trivial and safe, you do find odd comments here and there of people who failed..
<clem> there's always a little risk
<clem> and you'll notice also that the upgrade is burried in the menus
<clem> it's not discoverable without browsing these menus
<clem> that means blog readers (i.e. the most techie of our users) get to upgrade easily
<clem> while casual users don't take any risk and happily continue to enjoy their release without knowing about the new ones
<clem> somebody suggested we pop up a notification to raise user's awareness when new releases are out
<clem> that's precisely what we shouldn't do
<clem> anyway long story short, I've no idea what 18 will be like or its upgrade path, but we've got the philosophy/policy on upgrades pretty ironed out
<pjotr> I think the reason that Ubuntu LTS only offers an in-place upgrade to the next LTS after the first point release of that next LTS, is corporate users.
<pjotr> Businesses want maximum upgrade security.
<pjotr> security = safety

[Cosmo.]

The first sentence by Clem says it all:

pjotr, I understand the rationale, but with the same logic you'd wait for 18.2 or even 18.3?