On Jul 2, 2015, at 5:33 PM, Chris Murphy <lists at colorremedies.com> wrote: > > On Thu, Jul 2, 2015 at 4:12 PM, Warren Young <wyml at etr-usa.com> wrote: >> On Jul 2, 2015, at 11:32 AM, Chris Murphy <lists at colorremedies.com> wrote: >>> >>> It's effectively impossible. Very few people know how to do this. >> >> Relatively few people know how to write C programs, but that doesn’t make it "effectively impossible” to write them, nor does it mean that CentOS can’t run C programs. > > Bad analogy. Car doesn't come with a CD player. Does the dealer > support your user installed CD player? No. Your CD player, you > installed it, you support it, or whoever you paid to install it can > support it, not the car manufacturer or dealer's problem. Car analogies are almost as bad as philosophy when it comes to getting oneself tangled in thought. The “CD player” equivalent of the current CentOS situation is the old DIN 7736 standard: https://en.wikipedia.org/wiki/ISO_7736 If your car has a DIN 7736 bay, you can easily replace the existing head unit without redesigning the car. This is directly equivalent to repartitioning and installing CentOS alongside Windows. If you have UEFI and Secure Boot screwing things up for you, that’s like one of these modern cars that integrates the body computer and what we used to call the head unit into a single proprietary electronics package so that if you tried to replace the radio, you could no longer roll down the windows. To blame CentOS for this UEFI+SB situation is like blaming Crutchfield for the fact that you can’t buy a Pioneer head unit for a 2015 Ford Focus. In both cases, the blame properly resides with the provider of the host hardware. >>> Fewer care to learn when there are platforms that make this much >>> easier. >> >> If you want Ubuntu, you know where to get it. > > Ubuntu fails to boot UEFI+Secure Boot Windows 8.x as well. For some > lame reason, only openSUSE has the secure boot patches for GRUB Whatever. Unimportant detail. The important thing is that the availability of OSes that do this does not force CentOS to also do it. Regardless, this is not the right place to argue about it. CentOS does not drive changes into Fedora or RHEL. If you want this fixed, get involved with Fedora. > Android arrived at rapid success Yyyeahh… A bit of revisionist history there. Android started out in 2003 as yet another boring cellphone OS, aimed at replacing the likes of Palm, Symbian, Blackberry, and Danger. Google bought them in 2005, but the resulting Android 1.0 utterly failed to set the world on fire. It wasn’t until 2007 when the iPhone came out and showed the world what a mobile communication device was supposed to look like that Google got onto the path that lead to what we think of as Android today. Android 2.x (2009) was Google’s first try at market space exclusively held by the iPhone, up to that time. It was to iPhone as Ubuntu is to OS X today: kinda the same thing, but not really a serious competitor. Then they rebuilt much of the OS in the semi-proprietary 3.x line, which wasn’t widely deployed to the rest of the OHA partners until 4.0 came out in 2011. That’s between 4 and 8 years to achieve “rapid success,” and it was done with the resources of a $133+ bn company chasing a 2+ bn handset market. The idea that CentOS can or even should follow such a trajectory is ridiculous. Oh, and just to drag this thing back on-point, Android won’t repartition an iOS device and dual-boot *it*, either. > And no it's not just about dual boot. It's also the never ending > regressions that break things. Welcome to computing. There is no shielded enclave where nothing changes, and nothing breaks. Get over it.