Re: Summary of shared EFI system partition discussion

On 10/15/2015 02:58 PM, Chris Murphy wrote:
>     To be fair - many of the users who are ignorant of bootloader blocks
>     are also ignorant of why they'd want to go beyond the default FS /
>     partition layout choices and wouldn't end up in custom partitioning
>     anyway.
>
>
> I see no such correlation. I routinely see users who only have ever used
> custom partitioning (not just Anaconda, but other distro installers as
> well)

You can't really compare our install setup to other distros at this 
point. It's too different.

The body of people installing their own distros today is also not the 
same body of people who are generally ignorant of bootloader blocks 
(that population is much, much larger) and it is also not where Fedora 
can (or should) grow as a distribution given a mission to spread 
software freedom. (If you've already got it, it's not getting spread if 
you use it.)

There are *plenty* of people using the installer who don't use the 
custom partitioning feature, and they are blissfully ignorant of 
bootloader blocks and many other technical details I think the user 
population you're thinking of are quite aware of.

> have no idea what firmware their computer has, why that matters,
> how it affects what partition scheme is used, what partitions are
> created, the fact that grub2-install no longer applies, myriad changes
> that are thrust upon the user as a result of not so much the UEFI spec
> but because of this very weird (to me) installer idea that users need to
> see all partitions just because that's they way it's always been.
>
> And by so doing, they are now getting into trouble in ways they never
> previously got into trouble. And in ways they don't get into trouble
> with other OS partitioning tools that don't show them the whole story.

It's just a new way to get into trouble. There's tons of other ways to 
get into trouble in any partition editing scenario that would remain if 
we hid ESPs, but because they've been there longer they're harder to get 
rid of and their removal would most certainly piss populations of users off.

(see 
https://fedoraproject.org/wiki/User:Duffy/FundamentalTheoremOfDevelopingFLOSS 
  #1 and #5 particularly)

If a user doesn't want to see all the partitions - they shouldn't use 
the custom partitioning tool. If they want to work with partitions but 
don't like how anaconda displays them, they certainly have the knowledge 
and capability to use a 3rd party partitioning tool to do exactly what 
they want. Remember that anaconda's primary directive here is to install 
the operating system, not to be a general purpose partition manager.

>     This issue does not affect guided storage path nor the reclaim disk
>     space dialog.
>
>
> This issue does not affect custom partitioning with MBR gaps either.
> That is, it doesn't happen on BIOS+MBR systems. The user cannot delete
> the Windows bootloader even in custom partitioning on such systems. They
> literally can't get into trouble.

Actually they can, and I have in the past. They could overwrite the MBR. 
I believe part of the redesign involved making that no longer possible, 
but for many years it was possible to wipe out your ability to boot windows.

> Replicate that behavior, is what I'm suggesting, rather than falling
> into this trap of showing partitions for the sake of showing partitions,
> when doing so does not aid user success.

I think we need a lot more info/research into how that might affect 
folks before we can safely do something like that. I agree in principle 
generally with what you're suggesting, but the devil is certainly in the 
details. Aren't MBRs are a lot smaller on disk than ESPs?; if there 
isn't an ability to evaluate space taken up by ESPs and offer their 
management as an option in custom part, would we (for random potentially 
stupid example) be hurting some embedded users with very limited storage 
capacity? This isn't a simple change and needs to be considered a bit 
more deeply.

> The consequence of showing them such things is that we're effectively
> telling users for the first time in free software OS installer history
> they need to understand how Windows boots. They never had to understand
> the Windows bootloader esoterics before,

Again, they absolutely had to. Your last sentence there is absolutely 
untrue. I have had to manually set up a bootloader to access a Windows 
install I unwittingly rendered unbootable via a Linux multiboot 
installation before. Multiple times. Multiple distros.

> but now they do, in order to
> avoid trouble in custom partitioning. And that's not a ding on just
> Anaconda, all the other distributions do this too by exposing these
> bootloader structures to the user. And confusion ensues.

This all affects folks in multi-boot scenarios, which are the majority 
case nor really should they be. In 2015 this is an extremely limited 
user population we're talking about here: an edge case.

> The appropriate thing to do for all users is totally abstract bootloader
> blocks, however they manifest, and just manage it for them correctly.
> It's the only way to be sure. Leave the user out of it, they're not
> reliable.

~m