F21 partitioning circus

[Chris Murphy]

On Mon, Feb 23, 2015 at 12:44 AM, Tim <ignored_mailbox at yahoo.com.au> wrote:
> While I don't find it hard to believe that Windows developers won't
> complain.  After all, just about all Windows users do is install Windows
> as a new install, or over the top of a previous one, with no intention
> of doing anything like dual-boot.

Windows 8 has made a huge leap forward in terms of statelessness. The
refresh, reset, and restore options all work quite well and don't use
any installer at all. The installer itself does new installations and
upgrades, and I'd say upgrade comparison is now out of scope since
Anaconda doesn't do upgrades anymore, that's left to fedup.

Both Windows and OS X do support, explicitly, dual boot either two
version n's, or version n already installed, and a new version n+1,
reliably. However, both of them use separate utilities for doing fs
resizing for these cases, it's not built into the general purpose
installer. Further, OS X explicitly supports dual boot with Windows,
going so far as to prepare itself to accept an ordinary default
Windows installation. And again that's yet another utility, it's not
rolled into a giant monolithic installation program.

Meanwhile, Fedora can't manage version n, version n+1, default
installations without breaking the earlier version (due to LVM not
being enabled), and is a nearly three year old bug.
https://bugzilla.redhat.com/show_bug.cgi?id=825236

Because there are thousands of possible layouts among Linux OS's, it's
instantly non-deterministic to support dual boot on all of them. To do
better requires some standardization, and all you have to do is look
at the state of bootloaderspec to realize almost no one gives a shit
about this problem enough to compromise on it. They give a shit enough
to complain about the woeful state of cooperation among Linux distros,
but from start to finish Linux can't even standardize on one or two
bootloaders, or baring that they can't standardize all bootloaders on
a single configuration file format for those bootloaders, or they
can't come up with a standard on disk layout or  self describing one
by which discovery could be dynamic rather than relying on antiquated
static configuration files in the first place.

So from start to finish, dual boot is basically shit. Trying to
automate this has been one of the biggest nightmarish black holes I've
encountered, and really has exemplified the worst that can happen in
FOSS when there's insufficient cooperation and every distro tries to
build their own highway from the garage to downtown.

And multiboot is so beyond shit, I might have to first invent a new
category of profanity to do that one justice in explaining.

Yet again, it's a lack of discipline, and a bunch of people demanding
1000+1 more knob for their cockamamie use case. You know what? Fine,
do that in the CLI. Please don't defecate on the GUI, it makes them
untrustworthy. Our brains are wired to pattern recognition, and upon
associating mistrust with a GUI is very damaging and expensive to
unwind that mistrust.

>
> I, also, am rather incredulous of how difficult it is to have the Linux
> installer simply do what the user tells it to do, instead of
> second-guessing them and denying them of what they want to do.  If I
> select custom partition, and edit partitions myself, type of options, I
> expect it to have a GUI that does what I tell it to do.

Please cite a bug.

There's no doubt in my mind there are still lots of bugs in the
installer. But I keep hearing this level of cognitive dissonance from
folks who seem to think things are simple when they're told they
aren't. If you don't believe me, fine, go look at the code. But please
don't keep spouting this notion that making the installer do what you
want is an easy thing.

Every feature will include dozens, or hundreds of bugs. It's
inevitable. And again, Windows and OS X installers, they don't crash.
I've tried. I'm a goddamn bug magnet. To this day I'm still finding
crashing bugs in Anaconda, and the reason is because of code churn and
lack of stabilization because new functionality keeps being added. If
it were a brain dead installer, I guarantee you it would at least be
stable.


> I don't know what's really so hard about giving us a simple GUI hard
> drive partitioner somewhere in the install routine.

Please go code one yourself. You have 5 minutes to make Peking Duck,
even though I know it takes at least an hour to make it. I really
don't see what so hard about you doing this, seeing as by your own
admission it isn't hard.

I will even offer to troubleshoot it. But be prepared for vitriolic
levels of criticism when you f up basic things.

If you come back with something inside of 6 months, I will eat my hat.

>  Using the command
> line tool is a pain (e.g. you cannot see any details about the rest of
> the drive while you're working on making a partition), and there are
> other standalone GUI partitioning tools that exist.

If you really want partitions, why aren't you doing this with gparted
then? What's the problem with that workflow? Why do you need it
integrated in Anaconda?



-- 
Chris Murphy