Hi all I have downloaded centos and burn the iso file every time I install centos it deletes my windows 7 what am I doing wrong mike
Am 01.07.2015 um 08:52 schrieb Michael Wright michael_j.w09@hotmail.com:
Hi all I have downloaded centos and burn the iso file every time I install centos it deletes my windows 7 what am I doing wrong mike
I apologize but let us start with
in general
http://www.catb.org/~esr/faqs/smart-questions.html
and especially
http://www.catb.org/~esr/faqs/smart-questions.html#beprecise
-- LF
On Wed, Jul 1, 2015 at 12:52 AM, Michael Wright michael_j.w09@hotmail.com wrote:
Hi all I have downloaded centos and burn the iso file every time I install centos it deletes my windows 7 what am I doing wrong mike
This lacks sufficient detail to answer your question, I can only speculate that somehow you're telling the installer to delete the Windows 7 installation.
Since CentOS install media doesn't include ntfsprogs (I haven't checked if 7.1 does), it's not possible to shrink NTFS in the CentOS installer. You'd have to do the shrink in Windows, and then Anaconda will install by default into the resulting free space.
On Wed, Jul 01, 2015 at 09:56:18AM -0600, Chris Murphy wrote:
On Wed, Jul 1, 2015 at 12:52 AM, Michael Wright michael_j.w09@hotmail.com wrote:
Hi all I have downloaded centos and burn the iso file every time I install centos it deletes my windows 7 what am I doing wrong mike
This lacks sufficient detail to answer your question, I can only speculate that somehow you're telling the installer to delete the Windows 7 installation.
Since CentOS install media doesn't include ntfsprogs (I haven't checked if 7.1 does), it's not possible to shrink NTFS in the CentOS installer. You'd have to do the shrink in Windows, and then Anaconda will install by default into the resulting free space.
unfortunately, even having done that, Anaconda/Grub2 will not create a dual-boot setup because the default installs do not include ntfs-3g or ntfsprogs. I've posted a recipe before for making a grub2 dual-boot setup AFTER the installation, I can do it again if anyone needs it, but otherwise won't clutter up the list with another copy of it .
On Wed, Jul 1, 2015 at 10:01 AM, Fred Smith fredex@fcshome.stoneham.ma.us wrote:
unfortunately, even having done that, Anaconda/Grub2 will not create a dual-boot setup because the default installs do not include ntfs-3g or ntfsprogs. I've posted a recipe before for making a grub2 dual-boot setup AFTER the installation, I can do it again if anyone needs it, but otherwise won't clutter up the list with another copy of it .
Right. So basically yum install ntfsprogs and then grub2-mkconfig -o /boot/grub2/grub.cfg assuming this is a system with BIOS firmware.
My understanding is CentOS doesn't really support dual-boot anyway, whereas Fedora does.
On Jul 1, 2015, at 12:20, Chris Murphy lists@colorremedies.com wrote:
My understanding is CentOS doesn't really support dual-boot anyway, whereas Fedora does.
Nope. CentOS 5, 6 and 7 all support dual-boot.
-- Jonathan Billings
On 07/01/2015 05:10 PM, Jonathan Billings wrote:
On Jul 1, 2015, at 12:20, Chris Murphy lists@colorremedies.com wrote:
My understanding is CentOS doesn't really support dual-boot anyway, whereas Fedora does.
Nope. CentOS 5, 6 and 7 all support dual-boot.
-- Jonathan Billings
Since Linux first came out in '92, every distro I've used-- SLS, Slackware, Redhat, Suse, CentOS, and probably one or two others-- *all* have allowed dual-boot. The feature is built into grub, and lilo before that. Anyone who put together a distro which didn't support dual-boot would have to take the feature out-- rewrite the code (and why do that just to take out a perfectly functioning feature?)--, else use some other boot loader... e.g., the Raspberry Pi distros don't support dual-boot AFAIK.
On Thu, Jul 2, 2015 at 2:43 AM, ken gebser@mousecar.com wrote:
On 07/01/2015 05:10 PM, Jonathan Billings wrote:
On Jul 1, 2015, at 12:20, Chris Murphy lists@colorremedies.com wrote:
My understanding is CentOS doesn't really support dual-boot anyway, whereas Fedora does.
Nope. CentOS 5, 6 and 7 all support dual-boot.
Considering CentOS 7, at least, doesn't include ntfsprogs, the installation of CentOS can't support shrink or discovery of Windows in order to create a GRUB menu entry for it. That tools exist the user can make this work after installation is not at all what I'd consider "supported".
Since Linux first came out in '92, every distro I've used-- SLS, Slackware, Redhat, Suse, CentOS, and probably one or two others-- *all* have allowed dual-boot. The feature is built into grub, and lilo before that. Anyone who put together a distro which didn't support dual-boot would have to take the feature out-- rewrite the code (and why do that just to take out a perfectly functioning feature?)--, else use some other boot loader... e.g., the Raspberry Pi distros don't support dual-boot AFAIK.
Dual boot support has a large number of dependencies, it's not just dependent on GRUB doing the right thing. When ntfsprogs isn't included on installation media, for example, Windows dual boot isn't going to happen at install time, you have to do it manually after installing ntfsprogs.
Further, Anaconda (the installer used by RHEL, CentOS, Fedora) does not support enabling all LVs at installation time. Therefore GRUB won't find other Linux installations. So a default CentOS installation followed by a default Fedora installation, or vice versa; or CentOS/Fedora n system which then has n+1 installed, renders the n version unbootable. The user has to fix this post install. I'd hardly call this form of dual boot support, any kind of support whatsoever. https://bugzilla.redhat.com/show_bug.cgi?id=825236
Next, the RHEL/CentOS/Fedora GRUB lacks the rather old patches that SUSE submitted, to bring UEFI Secure Boot to GRUB's chainloader.mod. Therefore it isn't possible to have Secure Boot enabled, and chainload Windows 8 (it fails). So that's broken too. https://bugzilla.redhat.com/show_bug.cgi?id=1170245#c23
Finally, GRUB's grub-mkconfig command doesn't create EFI chainloading entries for OS X. Instead it wrongly assumes Linux is booted in CSM-BIOS mode, and has OS X boot entries designed to do an EFI boot from a BIOS build of GRUB and the result is a kernel panic. For this to work correctly it needs to chainload Apple's OS X bootloader, which is the only reliable way to do this now that they've moved to using their version of a logical volume manager by default, and nothing in the free software world knows how to read that format yet. https://bugzilla.redhat.com/show_bug.cgi?id=893179#c16
So pretty much in every possible way this is broken. I don't see how anyone says dual boot is supported on CentOS. It's barely supported on Fedora where right now only Windows on BIOS or 'UEFI without Secure Boot' are supported configurations. It's not even supported to install Fedora after CentOS, there's no release criteria saying that it must work, therefore there's no blocking releases on that bug, therefore it's considered not supported.
On 07/02/2015 11:51 AM, Chris Murphy wrote:
On Thu, Jul 2, 2015 at 2:43 AM, ken gebser@mousecar.com wrote:
On 07/01/2015 05:10 PM, Jonathan Billings wrote:
On Jul 1, 2015, at 12:20, Chris Murphy lists@colorremedies.com wrote:
My understanding is CentOS doesn't really support dual-boot anyway, whereas Fedora does.
Nope. CentOS 5, 6 and 7 all support dual-boot.
Considering CentOS 7, at least, doesn't include ntfsprogs, the installation of CentOS can't support shrink or discovery of Windows in order to create a GRUB menu entry for it. That tools exist the user can make this work after installation is not at all what I'd consider "supported".
Since Linux first came out in '92, every distro I've used-- SLS, Slackware, Redhat, Suse, CentOS, and probably one or two others-- *all* have allowed dual-boot. The feature is built into grub, and lilo before that. Anyone who put together a distro which didn't support dual-boot would have to take the feature out-- rewrite the code (and why do that just to take out a perfectly functioning feature?)--, else use some other boot loader... e.g., the Raspberry Pi distros don't support dual-boot AFAIK.
Dual boot support has a large number of dependencies, it's not just dependent on GRUB doing the right thing. When ntfsprogs isn't included on installation media, for example, Windows dual boot isn't going to happen at install time, you have to do it manually after installing ntfsprogs.
.... <snip>
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.
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? 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.
With VMs solid and much more useful and with deep market penetration, the need for dual-booting seems to be fading anyway.
On Thu, Jul 2, 2015 at 10:42 AM, ken gebser@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.
On Jul 2, 2015, at 11:32 AM, Chris Murphy lists@colorremedies.com wrote:
On Thu, Jul 2, 2015 at 10:42 AM, ken gebser@mousecar.com wrote:
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.
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.
Fewer care to learn when there are platforms that make this much easier.
If you want Ubuntu, you know where to get it.
Oh, and let me point out that Windows doesn’t resize Linux partitions, so please don’t give me any kind of argument that this is a necessary step before we can get to the Glorious Year of Linux.
On Thu, Jul 2, 2015 at 4:12 PM, Warren Young wyml@etr-usa.com wrote:
On Jul 2, 2015, at 11:32 AM, Chris Murphy lists@colorremedies.com wrote:
On Thu, Jul 2, 2015 at 10:42 AM, ken gebser@mousecar.com wrote:
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.
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.
And the same here, dual boot is not a supported feature on RHEL/CentOS, the piece to enable that is missing and the user has to install that to make it possible. User supported. Not distro supported.
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, I've found them no where else so far even though they've been around for years.
Oh, and let me point out that Windows doesn’t resize Linux partitions, so please don’t give me any kind of argument that this is a necessary step before we can get to the Glorious Year of Linux. _______________________________________________
No, the list of requirements to get there is quite long still. Android arrived at rapid success in the "everybody else can use it" where Linux on the desktop still struggles with catering to users who think "everybody else" is a moron because they want a dumbed down system and therefore they don't matter. So as long as "everybody" doesn't matter and only the current user base does matter, the Linux desktop market isn't ever going to grow.
And no it's not just about dual boot. It's also the never ending regressions that break things. It isn't any one thing, and that's why this is hard. But the dual booting thing is pretty much completely figured out, yet it's essentially inaccessible because that knowledge hasn't been translated through development to enable "everyone" to benefit.
On Jul 2, 2015, at 5:33 PM, Chris Murphy lists@colorremedies.com wrote:
On Thu, Jul 2, 2015 at 4:12 PM, Warren Young wyml@etr-usa.com wrote:
On Jul 2, 2015, at 11:32 AM, Chris Murphy lists@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.
On 7/2/2015 5:22 PM, Warren Young wrote:
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.
how many modern cars have DIN mount stereos anymore? almost all have some weird custom shaped dashboard specific stereo insert. sure, you can get DIN adapters for most cars, for instance I installed one in my daughter's 2004 Camry.
then there's the wiring, you have to make up an adapter where one end is car model specific, and the other end is stereo specific. and if the car has more than 4 speakers, life gets more complex, you'll probably need to add in additional amplification.
On Jul 2, 2015, at 6:35 PM, John R Pierce pierce@hogranch.com wrote:
On 7/2/2015 5:22 PM, Warren Young wrote:
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.
how many modern cars have DIN mount stereos anymore?
I covered that in my previous post: Crutchfield isn’t to blame for this situation any more than CentOS is for the UEFI+SB situation. Blame Ford and Honda, Intel and Microsoft.
then there's the wiring, you have to make up an adapter where one end is car model specific, and the other end is stereo specific. and if the car has more than 4 speakers, life gets more complex, you'll probably need to add in additional amplification.
The skills and equipment you need to do this are directly analogous to those needed to repartition a Windows box for dual-boot. The two cohorts are probably about the same order of magnitude in size, and somewhat overlapping.
On Thu, Jul 2, 2015 at 6:22 PM, Warren Young wyml@etr-usa.com wrote:
On Jul 2, 2015, at 5:33 PM, Chris Murphy lists@colorremedies.com wrote:
On Thu, Jul 2, 2015 at 4:12 PM, Warren Young wyml@etr-usa.com wrote:
On Jul 2, 2015, at 11:32 AM, Chris Murphy lists@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.
OK? CentOS doesn't support dual boot, because I did all the work to make that happen, the CentOS installer did nothing to help me make this possible. Just like the car dealer doesn't support this new head unit I installed, because I installed it.
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.
Bad analogy, you clearly don't understand the purpose of Secure Boot, or you've subscribed to some distorting philosophy.
I should not have to use proprietary software to be reasonably assured I'm not inadvertently owned by boot loader malware. So yes, free software absolutely must support UEFI Secure Boot properly. And, by the way, openSUSE has done this correctly for ~3 years. It's RH/CentOS/Fedora's GRUB that doesn't have these patches, I've already cited that bug. It's like you're willfully ignoring the facts and just making up regurgitated Secure Boot nonsense.
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.
This is wrong. And it's dangerous for any user to believe it. You would have users subscribe to "big sky theory" when it comes to root kits, and just hope to some deity that they never get such a thing. It's the good old plain luck method of computer security.
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.
I never said it did. I said it's embarassing that it doesn't.
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.
I included URLs for the bugs I either filed or have contributed to in trying to get this problems solved *on 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.
No I'd be better off comparing it to Windows or OS X. Desktop vs desktop, rather than desktop vs mobile. The reason why I compared to Android is because it is Linux based and a lot of it is free software. So that Android managed to get where it is today has to do with what's made all of these things more successful than Linux on the desktop and that's simply better user experience.
Oh, and just to drag this thing back on-point, Android won’t repartition an iOS device and dual-boot *it*, either.
Nope, it's not a supported configuration. The user can do that, therefore it's user supported. But it's also a fairly obscure use case, so I don't expect it to be easy. There are a lot of people dual booting who don't understand how it works, or how to make it work or how to fix it. And that is why I say it needs better support. It's for those users I advocate it. Otherwise, they use a Mac - which just so happens to have this so totally figured out they've put a GUI boot manager into the firmware, so it doesn't really matter (other than ugliness) that GRUB's OS X menu entries kernel panic the system.
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.
Apple's installer. Nothing changes. Nothing's broken. Windows installer? Nothing changes. Nothing's broken.
Aanconda? Constant changes, and give me 5 minutes and I guarantee you I will find a bug worth filing a report for (in addition to the ~ hundred I've already filed). Anacona is like the great city of New York. It's bad ass. But it's never finished, and something's always broken.
On Jul 2, 2015, at 9:21 PM, Chris Murphy lists@colorremedies.com wrote:
CentOS doesn't support dual boot, because I did all the work to make that happen, the CentOS installer did nothing to help me make this possible.
If free space on a drive is available at time of installation, CentOS will let you install itself into it, and it will even offer to put its boot loader on a CentOS partition instead of overwriting the boot drive’s boot sector.
That counts as “supports dual boot” in my book.
I do not require that CentOS be able to *create* that free space. That’s my job.
Just like the car dealer doesn't support this new head unit I installed, because I installed it.
If you buy a car from a dealer and it has an open DIN bay, you can install your own head unit into it.
This is exactly analogous to booting the CentOS installer with free space on a second drive or an unused partition.
Just because most cars come off the lot with something plugging that space up doesn’t mean it’s Crutchfield’s problem to fix, any more than it’s CentOS’s problem to fix UEFI+SB on your new Dell.
Once again: It would indeed be *nice* if CentOS could resize an NTFS partition to make room for itself, despite UEFI+SB. My problem is only with your insistence that it *must* do this.
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.
I included URLs for the bugs I either filed or have contributed to in trying to get this problems solved *on Fedora*.
So why are you continuing to bang on about it on a CentOS mailing list? No amount of yelling here will change anything. Take it to where you can effect change.
I will expect to see the results of your efforts when CentOS 8 comes out, years hence.
The idea that CentOS can or even should follow such a trajectory is ridiculous.
No I'd be better off comparing it to Windows or OS X.
Neither Windows nor OS X will nondestructively push aside a competing OS’s installation to make room for itself to dual-boot.
The reason why I compared to Android is because it is Linux based and a lot of it is free software.
Android only installs single-boot on hardware made specifically for it. It can make up whatever rules it likes for that hardware.
You’re trying to extend that to CentOS pushing Windows aside on a machine that came from the factory running Windows. It’s a specious argument.
Android managed to get where it is today has to do with what's made all of these things more successful than Linux on the desktop and that's simply better user experience.
Until you explain how you’re going to get CentOS to be preinstalled on a billion devices per year, I don’t see how you can connect Android’s success to CentOS. Where is the market force that will cause this to happen?
...they use a Mac - which just so happens to have this so totally figured out they've put a GUI boot manager into the firmware
While I will agree that holding Option or C down on boot is worlds better than madly pressing DEL and then poking around in a BIOS/EFI screen to switch around the boot order, I don’t really see what this has to do with the question at hand. OS X’s installer won’t push a Windows installation aside and make room for itself to dual-boot, either.
Windows likewise won’t push OS X aside on Apple hardware. It requires Boot Camp’s help to do that, which is a nice tool, but you’re arguing against using third-party utilities. (Boot Camp being third-party with respect to Windows.)
You’re asking CentOS to *exceed* what Apple, Microsoft, and Google do without giving it any of their market advantages first.
There is no shielded enclave where nothing changes, and nothing breaks.
Apple's installer. Nothing changes. Nothing's broken.
Apple breaks stuff *all* *the* *time*. They’re famous for it.
And I’m telling you this as an Apple fanboi. I have accepted the fact that I must cope with broken stuff on my Macs, just as I do on my CentOS boxen.
Windows installer? Nothing changes. Nothing's broken.
Go compare the standard paths for changing network settings in Windows 2000, XP, Vista, 7, 8, and 10, and tell me Microsoft never moves things around.
Go try to run No One Lives Forever on Windows 8, and tell me nothing breaks.
And this despite Microsoft’s heroic levels of backwards-compatibility, fueled by $173 billion in assets, which allows it to employ 128,000 people.
But CentOS must meet this same level.
Y’right!
On Thu, Jul 2, 2015, 11:05 PM Warren Young wyml@etr-usa.com wrote:
On Jul 2, 2015, at 9:21 PM, Chris Murphy lists@colorremedies.com wrote:
CentOS doesn't support dual boot, because I did all the work to make that happen, the CentOS installer did nothing to help me make this possible.
If free space on a drive is available at time of installation, CentOS
will let you install itself into it, and it will even offer to put its boot loader on a CentOS partition instead of overwriting the boot drive’s boot sector.
The CentOS 7 installer does not support installing GRUB to a partition. It can be installed, or not. If installed it goes in the MBR gap, or the BIOSboot partition, or EFI System partition.
And because there's no ntfsprogs, grub2-mkconfig won't find Windows and won't create a menu entry for it.
That counts as “supports dual boot” in my book.
Supporting dual boot means ability to boot both installed OS's upon completion of installing the second. This doesn't happen when the first OS is Linux using LVM, or Windows, or OS X.
Merely installing into free space constituting dual boot support means anything and everything supports dual boot to the point the term is meaningless.
I do not require that CentOS be able to *create* that free space. That’s
my job.
You have more jobs to do than that post-install to actually get it to dual boot. The operative word is boot.
Android only installs single-boot on hardware made specifically for it.
It can make up whatever rules it likes for that hardware.
You’re trying to extend that to CentOS pushing Windows aside on a machine
that came from the factory running Windows. It’s a specious argument.
No I'm saying it does a better job doing what most of its users want it to do rather than requiring them to knows esoteric things. It's not meant to be an dual boot comparison.
And it's established that Cent OS does not push Windows aside. You have to do that outside the CentOS installer.
Android managed to get where it is today has to do with what's made all of these things more successful than Linux on the desktop and that's simply better user experience.
Until you explain how you’re going to get CentOS to be preinstalled on a
billion devices per year, I don’t see how you can connect Android’s success to CentOS. Where is the market force that will cause this to happen?
I'm not making a number of installs argument. I'm talking about user experience.
For the significant minority who need dual boot, they are not at all well served by these distros. Only Fedora really supports it, and only with Windows, and only if Secure Boot isn't enabled.
While I will agree that holding Option or C down on boot is worlds better
than madly pressing DEL and then poking around in a BIOS/EFI screen to switch around the boot order, I don’t really see what this has to do with the question at hand. OS X’s installer won’t push a Windows installation aside and make room for itself to dual-boot, either.
Correct. It does not support installing after Windows. Its dual boot support is only supported when installing after Windows.
Of course it can be done with CLI tools by the user. But this isn't an Apple supported configuration.
You’re asking CentOS to *exceed* what Apple, Microsoft, and Google do
without giving it any of their market advantages first.
I'm asking that the CentOS installer not break bootability of the first installed OS. And that to be "supporting dual boot" that two OS's can in fact be booted upon completion of the installation.
NTFS shrink is icing. It's not the main requirement.
There is no shielded enclave where nothing changes, and nothing breaks.
Apple's installer. Nothing changes. Nothing's broken.
Apple breaks stuff *all* *the* *time*. They’re famous for it.
Not their installer. It's pretty much the same since ancient times. If anything it now has fewer features.
And I’m telling you this as an Apple fanboi. I have accepted the fact
that I must cope with broken stuff on my Macs, just as I do on my CentOS boxen.
OS X 10.n only on the computer. Then shrink that volume, and make a second volume, and install 10.n+1. Both boot. Out of the box. No post install work. Same for Windows.
RHEL/CentOS/Fedora? N and then N+1? N will fail to boot until you fix it post install. And grub2-mkconfig won't help do it correctly in a way that obviates having to always manually run it again.
Terrible UX.
Windows installer? Nothing changes. Nothing's broken.
Go compare the standard paths for changing network settings in Windows
2000, XP, Vista, 7, 8, and 10, and tell me Microsoft never moves things around.
Installer. You said there is no shielded enclave. All I had to do to prove that wrong was provide one example. I provided two.
But at least you let the Secure Boot arguing go...
Chris Murphy
Wow. So many _passionate_ words. Still have no idea what Chris is really going on about.
This seems to be running in two threads in Gmail, which makes it even more confusing.
K
On 07/03/2015 02:51 AM, Kahlil Hodgson wrote:
Wow. So many _passionate_ words. Still have no idea what Chris is really going on about.
Yeah, it's one of those threads with "more heat than light."
I believe that Chris wants (among many other things) is a CentOS which will automatically resize an existing Windows or OSX partition when setting up a dual-boot machine. I suspect that it doesn't (and won't, and actually shouldn't) due to legal and PR reasons. That is, if some user clicks on a button which says "Resize [other] partition", someone somewhere sometime is going to complain that a Linux install messed up her Windows or OSX partition. This could lead to a legal and/or PR nightmare for Linux and Linux devs. For these reason I'd think it better that, if you want to manipulate, say, a Windows partition, we're all better off if you do that with Windows software or at least separately from a no-brain-required Linux install program.
Just to respond to one objection in advance (because I'm not going to be drawn into this thread anymore than I have), years ago, in the early days of dual-boot, Windows put a critical and non-moveable file at the end of their partition. This made blithely shrinking that partition either impossible or dangerous-- so quite risky. And to me and everyone I knew there seemed to be no reason at all for this file being where and how it was, except to make shrinking the partition difficult. If you went into Windows, however, and knew the three or four steps, you could move this file and then, outside of Windows, resize the partition, then proceed with the dual-boot install.
Now imagine a Linux dual-boot install which automatically resized a Windows partition. Then imagine a Windows software update which included some such Gatesenheimer in it. The above-mentioned nightmare would begin and a lot of people would be called in for jury duty over something they didn't and wouldn't understand. Settled out of court, there'd begin a fee on Linux to cover damages assessed by the settlement. The Linux devs would probably have to go work for MS at minimum wage to cover or comply with their part of that settlement. Absurd and paranoid scenario? Yes. Possible? Still yes.
Peace out.
On Fri, Jul 3, 2015 at 5:59 AM, ken gebser@mousecar.com wrote:
On 07/03/2015 02:51 AM, Kahlil Hodgson wrote:
Wow. So many _passionate_ words. Still have no idea what Chris is really going on about.
Yeah, it's one of those threads with "more heat than light."
I believe that Chris wants (among many other things) is a CentOS which will automatically resize an existing Windows or OSX partition when setting up a dual-boot machine.
No, I want both OS's to be bootable after CentOS is installed, rather than the first OS bootability being broken. Broken is the rule, with one exception: the first OS is linux without the use of LVM.
And the reason I want it isn't for me, it's for the endless stream of users who have WTF moments over and over again asking about these problems, including the OP of this thread. It comes up constantly. They are so lost they have a difficult time even articulating the problem with more detail than "it didn't work".
I suspect that it doesn't (and won't, and actually shouldn't) due to legal and PR reasons. That is, if some user clicks on a button which says "Resize [other] partition", someone somewhere sometime is going to complain that a Linux install messed up her Windows or OSX partition. This could lead to a legal and/or PR nightmare for Linux and Linux devs. For these reason I'd think it better that, if you want to manipulate, say, a Windows partition, we're all better off if you do that with Windows software or at least separately from a no-brain-required Linux install program.
That's plausible up to the point where the default installation breaks the bootability of Windows (and superficially OS X as well which appears to KP as a result of the installation).
If the idea is to be conservative and protect the user, then the installer probably shouldn't be stepping on the existing boot loader without warning.
Just to respond to one objection in advance (because I'm not going to be drawn into this thread anymore than I have), years ago, in the early days of dual-boot, Windows put a critical and non-moveable file at the end of their partition. This made blithely shrinking that partition either impossible or dangerous-- so quite risky. And to me and everyone I knew there seemed to be no reason at all for this file being where and how it was, except to make shrinking the partition difficult. If you went into Windows, however, and knew the three or four steps, you could move this file and then, outside of Windows, resize the partition, then proceed with the dual-boot install.
Now imagine a Linux dual-boot install which automatically resized a Windows partition. Then imagine a Windows software update which included some such Gatesenheimer in it. The above-mentioned nightmare would begin and a lot of people would be called in for jury duty over something they didn't and wouldn't understand. Settled out of court, there'd begin a fee on Linux to cover damages assessed by the settlement. The Linux devs would probably have to go work for MS at minimum wage to cover or comply with their part of that settlement. Absurd and paranoid scenario? Yes. Possible? Still yes.
This is specious because we essentially have that with the current behavior.
The 440 bytes of boot code in the MBR that's the first boot loader code in the chain to boot Windows is both critical and unmovable. And yet it's stepped on in a default CentOS 7 installation along side Windows. And then because ntfsprogs isn't on the install media, grub2-mkconfig doesn't find Windows, and therefore doesn't create a Windows menu entry to chainload the rest of the Windows bootloader.
Yes, total corruption of the Windows volume in an fs resize gone wrong would be worse (unfixable) compared to the likely fixable problem under discussion, post-install. But I still think for a GUI installer to get the user into the weeds like this, silently, is a travesty of UI/UX. GUI programs should not get users into this much trouble. The installer should do this correctly or it should refuse to install CentOS or it should warn the user or even advise them on alternatives. But instead, it does all of the exact wrong things that can be done.
That is not dual boot support.
On Jul 3, 2015, at 12:23 AM, Chris Murphy lists@colorremedies.com wrote:
On Thu, Jul 2, 2015, 11:05 PM Warren Young wyml@etr-usa.com wrote:
Until you explain how you’re going to get CentOS to be preinstalled on a
billion devices per year, I don’t see how you can connect Android’s success to CentOS. Where is the market force that will cause this to happen?
I'm not making a number of installs argument. I'm talking about user experience.
It makes no sense to talk about the UX of CentOS as compared to Android while ignoring the billions of dollars that flow into the Android ecosystem. You cannot expect CentOS UX to approach or exceed Android’s UX without giving it equivalent resources.
OS X 10.n only on the computer. Then shrink that volume, and make a second volume, and install 10.n+1. Both boot. Out of the box. No post install work. Same for Windows.
RHEL/CentOS/Fedora? N and then N+1? N will fail to boot until you fix it post install. And grub2-mkconfig won't help do it correctly in a way that obviates having to always manually run it again.
Terrible UX.
Now you’re finally talking sense.
I agree, Linuxes generally should be able to push other Linux installs around, dual-boot, etc. I will even go so far as to say that it is not unreasonable to expect that, say, Debian should be able to carve a slice for itself on a computer currently monopolized by CentOS.
You’ll be working on fixing this as soon as you’re done writing emails about it, right? :)
But at least you let the Secure Boot arguing go…
You misunderstand. I am not on a crusade, like you seem to be. I can make my point and move on. I have no need to keep making the same point again and again and again, all on the wrong list.
IMHO dual booting, although interesting, is a dying technology. A necessary hack from less civilised times.
The modern approach is to choose the OS that personally gives you the most comfort (legal, physical, moral, aesthetic, financial, ...) and use virtualization to boot any other OS you may need.
Investing time in improving the UX for dual-booting may be fun or satisfy the soul, but it seems inappropriate to suggest its an important issue that must be resolved. Personally I'd choose investing my time in improving virtualization.
K
Chris Murphy wrote:
Supporting dual boot means ability to boot both installed OS's upon completion of installing the second. This doesn't happen when the first OS is Linux using LVM, or Windows, or OS X.
In that case, wouldn't it be more precise to say: CentOS-7 doesn't support dual boot if you are using LVM? It seems to me to work reasonably well with ext4. Does it work with LVM if you have a separate ext4 /boot partition?
On Fri, Jul 3, 2015 at 4:42 AM, Timothy Murphy gayleard@eircom.net wrote:
Chris Murphy wrote:
Supporting dual boot means ability to boot both installed OS's upon completion of installing the second. This doesn't happen when the first OS is Linux using LVM, or Windows, or OS X.
In that case, wouldn't it be more precise to say: CentOS-7 doesn't support dual boot if you are using LVM?
Or using Windows or OS X (just an ugly failure in that it causes XNU to panic, but it hasn't actually injured anything, it is still possible to boot OS X via the firmware boot manager).
It seems to me to work reasonably well with ext4.
Correct. If the existing OS uses ext3/4 on standard partitions, then the installer can do fs shrink, and when it calls grub2-mkconfig, the installation is found and boot entries are created for it. That the boot entry is distinctly sub-optimal is a long standing GRUB problem not an installer problem and not a CentOS problem per se. But it's still sloppy. The tools already exist for this to be done better, but for reasons unknown GRUB upstream likes to do things the hard and sub optimal way whenever possible.
Does it work with LVM if you have a separate ext4 /boot partition?
No. The root fs is hidden in an inactive LV, so os-prober (via grub2-mkconfig) won't find that Linux installation. The installer should make all LVs active so os-prober can find other OS's and make boot entries for them, but it doesn't.
On Jul 2, 2015, at 9:51 AM, Chris Murphy lists@colorremedies.com wrote:
On 07/01/2015 05:10 PM, Jonathan Billings wrote:
Nope. CentOS 5, 6 and 7 all support dual-boot.
Considering CentOS 7, at least, doesn't include ntfsprogs, the installation of CentOS can't support shrink or discovery of Windows in order to create a GRUB menu entry for it. That tools exist the user can make this work after installation is not at all what I'd consider "supported”.
That’s a really narrow interpretation.
The behavior you describe, where the OS installer can shrink an existing NTFS partition to allow room for Linux partitions doesn’t go back to 1992, yet we managed to dual-boot back then.
Would it be *nice* if RHEL/Fedora/CentOS could do this? Sure. Is it a necessary prerequisite? Absolutely not.
On Thu, Jul 2, 2015 at 4:06 PM, Warren Young wyml@etr-usa.com wrote:
On Jul 2, 2015, at 9:51 AM, Chris Murphy lists@colorremedies.com wrote:
On 07/01/2015 05:10 PM, Jonathan Billings wrote:
Nope. CentOS 5, 6 and 7 all support dual-boot.
Considering CentOS 7, at least, doesn't include ntfsprogs, the installation of CentOS can't support shrink or discovery of Windows in order to create a GRUB menu entry for it. That tools exist the user can make this work after installation is not at all what I'd consider "supported”.
That’s a really narrow interpretation.
The behavior you describe, where the OS installer can shrink an existing NTFS partition to allow room for Linux partitions doesn’t go back to 1992, yet we managed to dual-boot back then.
I've suggested that the distribution doesn't support dual boot if it has no hand in making it possible. The user doing this on their own manually is user enabled and supported. The distro has nothing to do with it.
Would it be *nice* if RHEL/Fedora/CentOS could do this? Sure. Is it a necessary prerequisite? Absolutely not.
I disagree.
Along the same lines as this, relating primarily to security and privacy: http://mjg59.dreamwidth.org/32686.html
I'll argue that the four freedoms aren't meaningful when they only benefit a scant minority. And the end result is, increasingly, developers are picking Macs because so many basic UI/UX things are handled so well and continue to be a PITA on Linux (desktop in particular). http://mjg59.dreamwidth.org/31714.html
On Jul 2, 2015, at 5:14 PM, Chris Murphy lists@colorremedies.com wrote:
I've suggested that the distribution doesn't support dual boot if it has no hand in making it possible. The user doing this on their own manually is user enabled and supported. The distro has nothing to do with it.
The difference between us is that you see that as a problem.
There are a great many things the CentOS installer doesn’t do for you, that you are expected to do for yourself.
Would it be *nice* if RHEL/Fedora/CentOS could do this? Sure. Is it a necessary prerequisite? Absolutely not.
I disagree.
Along the same lines as this, relating primarily to security and privacy: http://mjg59.dreamwidth.org/32686.html
I'll argue that the four freedoms aren't meaningful when they only benefit a scant minority.
Ah, it's *philosophy* then. The “science” that lets us spin words until we get ourselves so dizzy we can’t think straight. Sigh.
Given that CentOS doesn’t let you create C programs without any knowledge of how to program, would you also argue that CentOS doesn’t give you Freedom 0?
This is what happens when you start using entitlement arguments.
CentOS isn’t required to do absolutely everything for you that it could possibly do. Someone has to spend the time to make that happen. If you are not willing and able to do this work yourself, you have no claim on the time of people who can.
And the end result is, increasingly, developers are picking Macs because so many basic UI/UX things are handled so well and continue to be a PITA on Linux (desktop in particular).
OS X *also* doesn’t resize Windows partitions for you.
OS X's Boot Camp feature will resize an HFS+ partition to make room for Windows, but it can’t then split the NTFS partition to make room for Linux.
Boot Camp won’t even support triple boot. If you want to, you’re into a situation that’s considerably more complicated than what you have to go through to dual-boot Windows and CentOS:
http://wiki.onmac.net/index.php/Triple_Boot_via_BootCamp
Oh, and lest you think I have no idea what I’m talking about, I’m writing this on an OS X box which I’m using instead of CentOS not because CentOS sucks, but because Apple is one of the few sources of really nice modern Unix workstations. I’ve got a SecureCRT window constantly open to the CentOS box I develop on, I’m making a CentOS 7.1 USB stick right now in the background, and I’m about to build another CentOS server once it’s finished dd’ing that stick.
So no, “developers” are not abandoning Linux for OS X. A bunch of us are choosing to use OS X on the desktop, but when it comes to deployment, well, let’s just say that macminicolo.net is very much on the fringe.
On Thu, Jul 2, 2015 at 5:39 PM, Warren Young wyml@etr-usa.com wrote:
On Jul 2, 2015, at 5:14 PM, Chris Murphy lists@colorremedies.com wrote:
I've suggested that the distribution doesn't support dual boot if it has no hand in making it possible. The user doing this on their own manually is user enabled and supported. The distro has nothing to do with it.
The difference between us is that you see that as a problem.
It is a problem for everyone except the privileged few. It is not a problem for me, because I happen to be one of the privileged few and I happen to think dual boot UX is complete utter shit and therefore avoid it whenever possible. But that reality doesn't help everybody else achieve their goals.
There are a great many things the CentOS installer doesn’t do for you, that you are expected to do for yourself.
And those are likewise things that are not supported by the CentOS installer. All I've said here is that dual boot is NOT actually supported by the CentOS installer.
Now if you want to argue that's a bug, and ntfsprogs should have been included in the media so that this could be supported, that's an improvement. But the support would still be weak because it'd still be broken in more use cases.
Would it be *nice* if RHEL/Fedora/CentOS could do this? Sure. Is it a necessary prerequisite? Absolutely not.
I disagree.
Along the same lines as this, relating primarily to security and privacy: http://mjg59.dreamwidth.org/32686.html
I'll argue that the four freedoms aren't meaningful when they only benefit a scant minority.
Ah, it's *philosophy* then. The “science” that lets us spin words until we get ourselves so dizzy we can’t think straight. Sigh.
I'm not dizzy, my clarity on this is quite good. Philosophy is in part what's brought us the concept of libre software in the first place, I seriously doubt you're going to castigate the whole concept of free software just because it's founded in a philosophy of, you know, freedom.
Given that CentOS doesn’t let you create C programs without any knowledge of how to program, would you also argue that CentOS doesn’t give you Freedom 0?
No, but that would render the freedoms moot. Programs are assumed to exist, just like electricity is assumed to exist.
This is what happens when you start using entitlement arguments.
No entitlement argument has been made. Software freedom doesn't matter if there's no software. Software freedom doesn't matter if there are no users. When you have users who need a particular workflow for which all the programs exist, and the solutions to deficiencies are known but aren't addressed by development, then there are disenfranchised users and to them the freedoms don't matter. Those freedoms can't be realized without access. I'm not saying access is a right or an entitlement, I'm saying the lack of access has consequences, and that consequence is free software is rendered impotent to those users. It doesn't free them if it's not something they can use.
CentOS isn’t required to do absolutely everything for you that it could possibly do. Someone has to spend the time to make that happen. If you are not willing and able to do this work yourself, you have no claim on the time of people who can.
I'm not making a claim on anyone's time. I'm stating, as provable fact, that as a consequence of those who could do this work and choose not to, even when the problems and solutions are clear and even well tested, many users who could and would use free software do not use free software. They resort to using proprietary software.
And the end result is, increasingly, developers are picking Macs because so many basic UI/UX things are handled so well and continue to be a PITA on Linux (desktop in particular).
OS X *also* doesn’t resize Windows partitions for you.
OS X's Boot Camp feature will resize an HFS+ partition to make room for Windows, but it can’t then split the NTFS partition to make room for Linux.
Triple booting is an unsupported configuration by Apple. Installing OS X after Windows is an unsupported configuration. There is only one supported configuration, and that's a disk with one (visible) partition with OS X on it. Boot Camp Assistant will only split that configuration to make room for a single Windows installation.
But this can be done with CLI tools successfully. But it's still unsupported by Boot Camp Assistant. Just like CentOS's installer not being able to shrink NTFS, install to free space, and configure a boot loader that boots both OS's means the CentOS installer doesn't support dual boot (with Windows, and also doesn't support dual boot with any Linux that uses LVM).
I'm being completely consistent here. Just because there's some way for the user to make something work doesn't mean it's supported by anyone except them.
Boot Camp won’t even support triple boot. If you want to, you’re into a situation that’s considerably more complicated than what you have to go through to dual-boot Windows and CentOS:
http://wiki.onmac.net/index.php/Triple_Boot_via_BootCampOh, and lest you think I have no idea what I’m talking about, I’m writing this on an OS X box which I’m using instead of CentOS not because CentOS sucks, but because Apple is one of the few sources of really nice modern Unix workstations.
I don't know what "really nice modern Unix workstation" means in contrast to CentOS. OK it's nice, but it must also necessarily be better in some important ways or you'd use CentOS.
At this moment I'm using Fedora 22 on a Mac mainly because I'm testing. Most of the time I use OS X because it's more reliable in pretty much every single way: automatic graphics switching just works, the track pad just works, and Bluetooth just works. At the moment all of those things when running any Linux distro make the system next to unusable for more than a few hours. So because choices, including Apple's choice to keep so much of their hardware proprietary and their hardware vendors shushed, and my choice to buy this hardware, as a consequence my experience of software freedom is more limited.
I'm not asserting rights.
I’ve got a SecureCRT window constantly open to the CentOS box I develop on, I’m making a CentOS 7.1 USB stick right now in the background, and I’m about to build another CentOS server once it’s finished dd’ing that stick.
So no, “developers” are not abandoning Linux for OS X. A bunch of us are choosing to use OS X on the desktop, but when it comes to deployment, well, let’s just say that macminicolo.net is very much on the fringe.
OK well it's funny you say they're not abandoning Linux for OS X while you're doing what so many others have decided to do which is make OS X their primary platform for free software development because of some deficiency of doing that work on a free OS. You are not wholesale abandoning Linux, but you have abandoned it for certain work loads presumably for completely rational reasons where you conclude your productivity is simply better on OS X. So instead of a vague "it's a nice platform" without stating the pros of OS X or the cons of CentOS (or Linux in general) you haven't really helped stem this transition.
I'd prefer to see free software developed on free software. That's why I continue to put in a lot of effort on QA'ing Fedora.
On Jul 2, 2015, at 8:46 PM, Chris Murphy lists@colorremedies.com wrote:
I seriously doubt you're going to castigate the whole concept of free software just because it's founded in a philosophy of, you know, freedom.
Freedom isn’t free. Someone has to do the work.
I have yet to see how you explain who will do this work, how those people will get the resources to do this work, or what your role is in helping with the provisioning of those resources.
And I still have yet to see how any of this involves the CentOS project, short of distributing the result as part of CentOS 8+.
Given that CentOS doesn’t let you create C programs without any knowledge of how to program, would you also argue that CentOS doesn’t give you Freedom 0?
No, but that would render the freedoms moot. Programs are assumed to exist, just like electricity is assumed to exist.
“Free” time is not free. It is a gift of someone’s finite time on this Earth.
You have said that you are not entitled to receive this gift, and that you have no natural right to it. I don’t see that you are spending your own free time writing the software, nor are you hiring others to do it for you. So why do you expect to get this gift? Who will give it to you, undeserved, and why?
Those freedoms can't be realized without access. I'm not saying access is a right or an entitlement, I'm saying the lack of access has consequences, and that consequence is free software is rendered impotent to those users. It doesn't free them if it's not something they can use.
I came up in computers in the early 1980s, when every computer came with a BASIC interpreter, and all the computer magazines had programs in them. The expectation at the time was that everyone who wanted to use a computer would create at least *some* of their own programs.
Then people discovered that they could give money to other people to get them to license them copies of programs they created.
Others discovered that they’d rather just give the software away, under assorted licenses and schemes.
The missing link is the tie between that latter group and the necessity that they create arbitrary programs for you. You will not join them, and you disclaim a right to their time and resources. So where’s the link?
Until you can close this gap, all you’ve got is Sad Trombone.
So no, “developers” are not abandoning Linux for OS X. A bunch of us are choosing to use OS X on the desktop, but when it comes to deployment, well, let’s just say that macminicolo.net is very much on the fringe.
OK well it's funny you say they're not abandoning Linux for OS X while you're doing what so many others have decided to do which is make OS X their primary platform for free software development because of some deficiency of doing that work on a free OS.
A developer may switch to OS X on the desktop while still writing software primarily on and for Linux, and while deploying primarily to Linux. I held myself up as an example of this. I’m not alone.
I have reason to believe that software I wrote is running on many thousands of Linux boxes. (I have no way to count them. It’s just a guess.) Why does it matter which OS was running the text editor that software was written in?
you haven't really helped stem this transition.
Developer adoption of OS X will not be the thing that destroys Linux, if anything ever does. OS X’s popularity probably is exchanging some potential Linux growth for BSD growth, but that’s not so bad a thing, is it? The BSDs can use a lot more developer love than mainstream Linuxes like CentOS.
Am 01.07.2015 um 18:20 schrieb Chris Murphy:
Right. So basically yum install ntfsprogs and then grub2-mkconfig -o /boot/grub2/grub.cfg assuming this is a system with BIOS firmware. My understanding is CentOS doesn't really support dual-boot anyway, whereas Fedora does.
My experience is different: my system previously comes with Windows-7, which I shrinked and installed CentOS-6 in parallel, where the installer created an entry to start windows. Later when CentOS-7 comes out, I replaced Windows by Centos-7. After installation, the Grub2 boot menu included entries to start CenOS-6. The only problem (not really) is that a kernel update in CentOS-6 does not update the boot menu, I must boot CentOS-7 and rebuild it there.
__ Gabriella
-
Chris Murphy -
Fred Smith -
Gabriella Schmidt -
John R Pierce -
Jonathan Billings -
Kahlil Hodgson -
ken -
Leon Fauster -
Michael Wright -
Timothy Murphy -
Warren Young