On Mon, Feb 23, 2015 at 12:44 AM, Tim <ignored_mailbox@xxxxxxxxxxxx> 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 -- 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
