Why does Anaconda overrides user decisions?

[Chris Murphy]

On Wed, Jan 28, 2015 at 9:20 AM, Matthew Miller
<mattdm at fedoraproject.org> wrote:
> On Sat, Jan 24, 2015 at 05:15:53AM -0600, Glenn Holmer wrote:
>> > Anacoda is the weakest link in Fedora toolchain. The non-linear UI is
>> > completely non-intuitive
>> +1, the partitioner is the worst I've seen in 20 years of using Linux.
>
> It also covers more cases more simply than any other storage manager
> you've seen. You really can't have everything, here.

This installer's manual partitioning works differently than other
installers. This makes some tasks simpler, but it makes other tasks
more difficult. My contemporary example: bootloader partitions. It's
not just more difficult in Anaconda, it's unnecessarily more
difficult, as in doing the right thing would be easier for the
installer team, QA, and ultimately the end user. But the current
behavior is being defended, and instead users are being blamed for the
consequences.

Once  upon a time, there was just the MBR gap as the unofficial
bootloader partition. The user wasn't ever asked to create it, and
couldn't ever delete it. Even at the command line level, the gap
creation was built into the CLI partition tool. It was not user
domain, it was installer, bootloader, and firmware domain.

Today, BIOSBoot and EFI System partitions are literal partitions with
official standing. But for reasons unknown, the user is now burdened
with required knowledge about them. The installer's manual
partitioning now makes a required partition the responsibility of the
user to create, and avoid inadvertently deleting. And that's a bad
design.
https://bugzilla.redhat.com/show_bug.cgi?id=1022316
https://bugzilla.redhat.com/show_bug.cgi?id=1183880

Central to the problem is the installer team believes users should
know what they're doing in manual partitioning. It's exactly backwards
logic. They have to know this because the installer wrongly involves
the user in something that previously wasn't ever their domain, and
shouldn't be now either just because it has an explicit partition.

Even developers using kickstart wish the installer handled this
automatically. I argued this very same thing in the above closed bug
1022316 over a year ago, but it was closed as notabug just like it's
not a bug that the user is invited into easily deleting the EFI System
partition without warning.
https://bugzilla.redhat.com/show_bug.cgi?id=1108393#c12

Windows and OS X totally abstract the EFI System partition from the
user. It's always created when required. It's never mounted at boot
time. And no dynamic configuration data is stored there. We do the
opposite of each of these. In every case where the more difficult,
fragile, and confusing thing can be done, that's what we've chosen to
do. We're doing it wrong, across the board.

It's on thing to make mistakes, identify, and fix them. But that's not
what's happening here. Instead we have a sclerotic installer team,
defending bad design, and then blaming the user for the ensuing
problems and confusion. Why? Because they expect the user to know what
they're doing. A user who's using a GUI installer should know what
they're doing. Oh my god it's just comical!

Guess what? I expect the installer team to know what they're doing.
And rule #1 for GUI installer developers is to not blame the user!
Why? Because doing that is impudent betrayal, and that causes a loss
of trust. The installer team is tone deaf on this issue.

So Matthew, on this one particular narrow aspect of the installer? It
is not simpler. It's viciously, egregiously, more difficult and
dangerous. It's this way by choice, by design, and it's being
defended, and now the user is being blamed.




Chris Murphy