On Wed, Jan 28, 2015 at 9:20 AM, Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> 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 -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
