On Thu, Jul 2, 2015 at 10:42 AM, ken <gebser@xxxxxxxxxxxx> 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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
