On Sun, Feb 22, 2015 at 3:39 PM, Heinz Diehl <htd+ml@xxxxxxxxxx> wrote: > On 22.02.2015, Chris Murphy wrote: > >> Windows, OS X installers have maybe 2-3 total layouts between them. >> And their installers are completely, totally, bullet proof. They don't >> ever crash, or ask the user to create required partitions, they always >> succeed in their penultimate goal which is to install a bootable OS. > > Frankly, the vast majority of the users of those operating systems > aren't even capable of installing them by themselves. The users don't know these things because they don't have to know them, not the other way around. There's no benefit in them knowing such things it's not intrinsically valuable knowledge for the majority. It's sufficient that a scant minority know such things. Look at even Android and cyanogen. Look at the reinvention of all OS's for mobile devices and how much simpler things are when constraining choices. Chromebooks are in that same category. Simple. Just works. They picked a layout and stuck with it. And that's not to say the layout of my cyanogen phone is exactly simple, it uses GPT partition scheme, and has 28 partitions. (Of course that's not by my choice, I had no say.) > >> And there are essentially zero user complaints about these installers. >> There's nothing at all to even complain about because they don't do >> anything except meet their primary requirement. Not even their >> developers or testers even complain about the installer, it does one >> thing successfully. > > I see. Maintainability preceeds flexibility by reducing/eliminating user > influence at the same time. While it took over 100 years in medicine to reduce > "i know what's best for you" and moving towards "shared decision making", it > goes the other way 'round here. - No, it's called picking battles. And what you're suggesting is a false dichotomy. Shared decision making actually turns into "I want partitioning with a cherry on top, you over there, go plant me a cherry tree." - No you can do it your way by using either blivet-gui, or gparted, or CLI tools in advance if you want. - Anaconda's Manual Partitioning is still one of the single most capable installer's of the lot, even if it doesn't support your specific use case. >Fortunately, there are still distributions > which let the user have the desired influence. Right. Because the problem Linux on the desktop has is it's 1000 knobs aren't enough and users need more choice. The inhibiting factor has been, this whole time, all these years, is that users really want more f'n confusion in their life. So the other day I used Yast to do an installation. Of course they're now using Btrfs by default. But it also allows me to check a box to use LVM and I thought "oh that's almost certainly a bad idea, let's see what happens" And what I got was 18 separate LV's, formatted Btrfs, instead of one Btrfs volume and 18 subvolumes (and even the 18 subvolumes is completely pathological). So yeah, less choice should be the default in any GUI ecosystem, not more choice. And besides, why in the world should so many resources go into creating advanced storage stacks only for OS installation? Why shouldn't I have such a tool for creating a big bad ass RAID with a bunch of LV's for each department? Why should I only find this in an installer, which arguably doesn't even need that? It's not it's primary use case. And it seems there's some agreement on that front, which is how the core storage portition of Anaconda got split out into its own package, python-blivet. And now there's blivet-gui which uses it, with a gparted-like UI. And OpenLMI uses python-blivet. And maybe one day soon, Cockpit on Fedora Server, will use it rather than everyone having to reinvent this wheel. -- 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
