As a user who wants an OS that 'just works' so that I can work on other things, why wouldn't I choose CentOS over Fedora for my laptop?
But, Fedora is pretty darned good about Just Working, in my experience. Because my laptop was a super new design when I got it, things were a bit shakey (I ended up using the Windows it came with for about a month because GPU drivers weren't working under Linux and running at any high res caused it to lock up frequently). But, once I was able to get all the right drivers and everything was working, I haven't had to do anything, even through a Fedora 25->26 upgrade (I have the nvidia drivers, but I got them from the rpmfusion-nonfree repo, so they update in the normal way).
Some examples are major changes to config files by certain apps - like rsyslog or squid. I also went through the transition from init.d to some other one I can't recall and then to systemd.
But I also had a pretty heavily configured/customized system...
In the end, I decided it was too bleeding edge for continuous upgrades in my specific environment.
I switched to CentOS7 and I keep my configuration in ansible scripts. I also use EPEL and ELRepo for the mainline kernel.
But if you're just running a laptop desktop ... and you're willing to reinstall at major revs, or you just don't customize it that much, yeah, give it a try!
It was a very battered OS when I was done :)
Again, Fedora is great -- but for my use case, I wanted something with a longer life cycle. CentOS7 is great!
CentOS is aimed at servers which are maintained by sysadmins who know RHEL well (e.g. RHEL certified), or who just want really friggin' stable shit.
A developer usually wants someting that has a tradeoff closer to "newer" on the "stability vs upgrades" tradeoff.
For a dev laptop, absolutely use fedora over centos.
Critically for potential desktop users, this means you can't necessarily expect things like touchpad drivers to work. Hardware support, especially consumer hardware support, can take years to trickle into centos releases.
That stability may well be deeply desirable in a server that has to undergo security audits every so often, but it won't help you install it on a laptop.
Not necessarily, after all non-technical Red Hat employees run RHEL on bog standard Lenovo ThinkPads and model choice includes pretty recent hardware (and even some models with Optimus, lately).
Technical employees mostly run Fedora, though some use RHEL and others are die hard Debian or Gentoo fans.
Main due to my using a Dell laptop with an ALPS touchpad at the time, and getting fed up with the crappy support it originally presented. ;)
(FWIW I have also experimented with stable versions of Debian and, when I am not seeking the newest software which has been the case in the recent years, it works just as well for me as unstable distribution. But FWIW2, the Debian Sid on your Workstation paradigm has only bit me twice in nearing twenty years, and both times were valuable learning experiences.)
My advice would be to use whatever you're most comfortable with. With an addendum to use whatever you have running in production if possible, because that will maximize the chances that you discover a bug in production before it bites you hard.
Admittedly that was a while ago! Testing, depending on what part of the release cycle you are in, can be a few weeks behind Sid or significantly more, though. Most upstream release managers probably pay some attention to the release cycles nowadays so, with luck you wouldn't notice this too much.
(The start date of the testing freeze is well publicized in advance and known, so competent release managers should avoid potentially breaking/broken updates immediately before that date, if I remember correctly how this works.)
As to why not to use CentOS/RHEL: they're not supported by half the companies that Ubuntu is so if you buy commercial software (indie video games at least) Ubuntu is the better option.
I've seen enough things that are "fine in sid" but broken in every Ubuntu distro including next, that your argument against Debian does not sound convincing to me.
Yeah, things can break in sid, but are you better off using Ubuntu Next? I don't know anyone who would seriously argue this.
Nobody develops on or targets Ubuntu Next that I am aware of, unless a release is imminent. Lots of developers pay attention to Debian Sid all the time, because that's where new releases land first (maybe you find them in rawhide first if the developers are RH-focused, I wouldn't know.) Debian Sid actually has the lowest barrier to entry for release managers, the changes just need to successfully make it out of Experimental.
I'm sure they're usually close enough that I'm not going to dispute anecdata though.
Hardware makers target Ubuntu and game makers target Ubuntu. Libc differences can give you a real hard time when it comes to running binaries that are not compiled on your target OS. I have definitely seen that! It's no fun and you may not be able to solve it based on strange timing of libc versions with respect to the Debian 2-annually release cycle. Game developers certainly don't care what versions of libc made it into Debian stable or Debian testing these cycles, so you may be out of luck for two cycles in a row and it's no better in Sid. I mean, this is anecdata too. But it's real and if you haven't had this problem, it's because you didn't use Debian, but used Ubuntu instead. I suspect RHEL/CentOS users didn't have this issue either for one reason or another, and Fedora users neither.
But it sure is a problem in Debian, if that's what you're into. To clear things up if it sounds like I'm talking in circles, I ran my share of games on Debian and I had definitely hit this type of issue, and ultimately failed to solve it for myself.
If I was using closed-source software or intending to play games, you'd get no disagreement from me I'd rather do it on Ubuntu, and that's a fundamental disagreement with Debian policy and any either closed-source or other than rolling release target (eg. one-and-done) game developer or realistically any other code system that needs either kind of g/libc as a specific version of shared library to link to.
You may genuinely be onto something here. But in my production systems, I tend to target using 100% open solutions, so I'm not sure I would have ever run into this at dayjob. Farewell!
Additionally, in practice a module (driver) that ignores the kABI will usually work for all patched kernel versions on a given minor release (~service pack). e.g. A minor release 6.X introduces a new kernel X' (2.6.32-X'.Y) and a module built against X'-0 will work for all Y.
(CentOS/RHEL 7.x is new enough that this isn't a big issue yet, but it normally does become a pain point the older the RHEL/CentOS major release gets - there are a lot of drivers that does not get backported to the RHEL/CentOS minor releases)