On Thu, Jul 2, 2015 at 10:42 AM, ken <gebser at mousecar.com> wrote: > I guess it depends on one's definition of "support". Your definition seems > to be more demanding... which often is a good thing, urging Linux on to be > better. > > Me, I didn't use the word "support" at all. I only said that I've done it > on every one of my Linux systems since 1992 (except Raspberry Pi's). Yes, a > little manual work was needed on the Windows side, but this was well > documented and frankly not that hard. Since I've done it-- numerous times-- > I'm not readily persuaded that it's impossible to do. It's effectively impossible. Very few people know how to do this. Fewer care to learn when there are platforms that make this much easier. > Sure, it would be nice during the install process to simply click a button > for "Yes, I want to dual-boot with Windows (or whatever)" and it would just > happen. Yeah, I'd like that. On the other hand, what other (i.e., > commercial) OSs support/allow/permit dual-booting? Windows explicitly permits dual boot with Windows. So does OS X, but in addition can even set up the system to accept a Windows installation. So I personally think it's embarrassing that RH/CentOS/Fedora can't reliably install N+1 after version N, and for both of them to be bootable; *and* for both of them to do kernel updates that cause their respective boot entries to be automatically updated (and visible to the user) as well. That part is completely busted in GRUB because instead of using configfile to point to distro specific grub.cfg, it creates a whole new boot entry for that first distro instance in a grub.cfg that's only available to the 2nd instance. It's an ugly mess, bad UX all around. >Given all the code for > Linux is readily available to Apple and MS, it's much, much simper for them. > The exact opposite is true for Linux developers. Yeah I don't buy that. The way Windows, OS X, and Linux boot are not secrets. It's well understood by those who know this, but getting developers to fix GRUB is what's hard. I explained to GRUB upstream what needs to be done to get a Mac to boot OS X properly from GRUB, but no one cares to actually do the work. So not only does that not get done, but the old code that wrongly puts in bad OS X menu entry that panics the system, isn't removed. It's 2x the bad UX of two Linux systems coexisting. And has nothing to do with how proprietary those other systems are. And, to underscore it again, Linux code is available to Linux developers, and yet the most common outcome for Linux A + Linux B dual boot is Linux B literally *enjoys* stepping on Linux A. The cooperation that exists with the kernel? It's nearly the opposite level of cooperation when it comes to OS installation and booting. Every distro reinvents the wheel, and has zero concern about how hostile their installer is to an existing Linux installation that isn't their own. Hell, the RH/CentOS/Fedora eco system borks it's own prior installations! So it has nothing to do with code availability. It has to do with not caring (and to some degree the resources to care). > With VMs solid and much more useful and with deep market penetration, the > need for dual-booting seems to be fading anyway. Sure, but increasingly it's Linux being put into that VM. Not the other way around. And that's due to things like dual-GPU systems simply working better, automatically, with no fuss, on Windows and OS X. This is at least variable on Linux, still. And yes a lot of this is because of proprietary behaviors on the part of Nvidia and AMD. So the reasons why this is difficult on free software are all valid, but it's also valid when users just give up and use a different platform because they don't have to deal with these sorts of problems. -- Chris Murphy