Really happy with my move from Ubuntu LTS to CentOS 7.

QA is so much better. I had so many production breaking bugs with Ubuntu, especially on bare-metal.

RPM packaging is more fun than DEB. I'm even using it for application deployment with tito[1].

Even the software deployment story got better thanks to the Software Collections (https://www.softwarecollections.org). Rock solid base OS and an up-to-data application stack.

CentOS on the servers + Fedora desktop is a great combination, since you can re-use your whole build infrastructure and skills for your workstations.

[1]: https://github.com/dgoodwin/tito

> QA is so much better. I had so many production breaking bugs with Ubuntu, especially on bare-metal.

Is it (Fedora) much better on the desktop? I dumped Win10 a couple months ago to go back to Ubuntu for the first time since PulseAudio broke everything horribly and I swore off Linux on the Desktop forever (haha), and I was shocked to find that the UIs of both Gnome and KDE have if anything more rough edges than when I last saw them as far as usability goes, performance (UI responsiveness mainly) is generally mediocre to poor, and that both are at least as unstable/buggy as before (KDE significantly worse than Gnome in that regard, though neither's good).

I'd consider jumping ship to an RPM-based distro for the first time since 2004 or so if the desktop experience is less... well, bad, frankly. Going back to Win10 isn't an option. What a garbage fire.

Not sure about KDE, but Fedora's version of GNOME definitely works better than Ubuntu's version of GNOME. Because of their valiant efforts to keep Unity from changing at all for six years, Ubuntu's desktop has a peculiar hodgepodge of software versions and unnecessary patches. There's a sense of teams of developers pulling in opposite directions from each other with your computer straining in the middle. Hopefully will get better in a year or two. On the other hand, a lot of what's been going on around GNOME has been about how stuff fits together, along with backend changes that have been getting more and more polished in Fedora but aren't really there in Ubuntu yet. Kind of depends on your system (and whether you have strong opinions about search-as-you-type), but in my own experience I've found that Fedora just feels sturdier as a result. More designed, in a number of ways.

Also its boot splash is the coolest. That's probably the real reason.

Does Fedora's GNOME hold up better in terms of performance? The animations on my Ubuntu GNOME setup (in particular when launching overview) get noticeably janky with more than just a handful of windows open.

Alas, haven't noticed much difference there. Chances are you'll find yourself in a Wayland session, so that may change things a little bit one way or another, and there's definitely some ongoing work to make animations better, but I think you'll probably have the same problem. (There's some nice stuff coming down the tubes, though).

Gnome is just total garbage as is windows 10. They both drove me to OSX which I admit merely carries the crown of being "the least crap".

I really want gnome2 back but fixed and as a first class citizen, not a fork that the big vendors wish would go away. That had some mileage.

I love macOS. It's a Unix system, with a fantastic GUI, well-integrated applications, an ecosystem that is rich and vibrant, and a command-line system the is extremely usable, also with a rich ecosystem (homebrew, macports, etc)

For me, after 10 years of trying to make desktop Linux work the way i wanted it to, macOS is everything I was looking for.

Gnome decided that they had no desire to make a usable DE. They took everything that made it good, threw it out the window, and went as far as they could to make it unusable.

KDE is just a clusterfuck. 2-3 system preferences panels, confusing options, and way too much gloss (glow, transparency, etc).

I spent a long time with tiling window managers, trying to roll a system that felt comfortable and usable to me. And for the most part I succeeded. But the lack of integration with applications is really what ruined it for me. I want a good email client, an address book that can have arbitrary amounts of phone numbers and email addresses per entry, and the ability to give those arbitrary names. I also want my email, address book, and calendar to be aware of each other and play well together. I want a nice way to sync all of that to my mobile devices. I want an experience that feels coherent, instead of something hacked together with bailing twine.

Don't get me wrong. I love Linux. For servers, I would never choose anything else (well, maybe FreeBSD). But it seems like over the last decade, distro developers and desktop environment developers have gone out of their way to sabotage their own efforts and make their software as unappealing as possible.

macOS is not configurable in key ways, so it isn't very usable unless you happen to find the one, unchangable macOS way to be the best. One Apple Way indeed.

It's also, fundamentally, closed. In this era of NSA wiretaps and everything else, that's just not acceptable. I have no idea what's in macOS, and I have no confidence Apple will do anything except give the NSA what it wants. With Linux, the attacks are much less obvious.

Fair points and I agree with all of them.

One killer for me is entirely disparate from yours and that it is pretty damn difficult to drive macOS from the keyboard.

In your opinion, why do you think so many people continue to use Desktop Linux?

Perhaps it's hope that things will eventually get better. That's one thing that kept me hanging on for a long time. The problem is that so many project seem to be asymptotic. The developers get to a point where the software is almost ready for prime time, or is getting really good, and then trash it, start over, or decide to switch direction. Or the dev team falls apart, and you get 3 forks out of the project that never go anywhere. It seems like no one ever wants to actually finish anything. And it gets tiresome.

Also ideological reasons, which I totally understand. I prefer FLOSS options when possible, but I'm not dogmatic about it. I understand a lot of people want to make sure every bit of software they are using is open, and I totally get that.

I mean, I still love Linux a great deal, and if DEs were less shit, and applications were more integrated, I would still be running Linux, or would return to it. But I suppose it's simply a matter of what people are comfortable with.

Use dwm. Alternatively "emacs -fs".

There is a system for you: Emacs.

Xubuntu to Fedora XFCE spin was entirely unexciting in terms of change, I like unexciting when it comes to the OS I use for my livliehood.

Gnome 3 is still a dumpster fire and KDE got so bad as packaged that the devs felt the need to do Neon.

KDE hasn't been good imo since 3 and Gnome since 2.

I'm an XFCE user because of the Gnome 2 debacle though I've considered MATE a few times there isn't anything about XFCE remotely bad enough to make me seriously consider a switch.

The Mate desktop is pretty good. It's Gnome 2, maintained and polished, and ported to gtk+3 in the latest release.

But there are a few better options than the latest KDE or Gnome. These projects have built houses of cards in their attempts to be the biggest and user-friendliest, sacrificing too much stability and quality.

I love Windows 10. I run the pro version and I develop cross platform web and mobile apps with it.

What went wrong for you?

My biggest problem was that I had to turn off Defender because it was causing some delays with the real time scanning.

Ads. Mostly for Microsoft stuff that I don't and will never want. That alone is fairly bad. Even after spending a bunch of time fixing the OS there were still a few. Privacy concerns (ditto).

The updates are a real problem, just all around. Final straw was when one added Outlook back to my start menu.

For all this I got an OS that, actual objectionable things aside, is less pleasant to use than Win7. I'm out. First time I haven't had Windows on something since 3.1.

[edit] by "added to my start menu" I meant "pinned to my task bar"

Try something simple like i3

I would, but I just don't use my home desktop enough to get used to anything too esoteric. I'd never remember the keyboard shortcuts and such. I just need to run some GUI utility programs, manage files, launch some (Steam, GoG) games, and manage simple network file sharing (Samba mostly). Anything else (and some of those things, to an extent) I can do from the command line. At work and at home I do Real Work™ on MacOS, so that's where I spend ~95% of my computer time.

If I started using Linux desktops most of the time again, I'd go back to what I found to provide the best experience: minimal everything, and manual config of practically the whole system past the base OS (and even some of that). So yeah, i3 or similar would be a likely choice, and probably Arch or Gentoo for the distro (used to love Gentoo).

As a user of i3, it is anything but simple. Outside the standard DEs, you vastly complicate things like power, network, and display management. It's possible to build out a fully functional environment with i3, but it is far from simple.

For the pieces you mention, I use tlp, connman and xrandr. Yes they have a small learning curve and I wouldn't recommend them to everyone, but they are stable and not likely to change (whereas Apple/Microsoft/Redhat are constantly reinventing their UIs).

Building out a desktop environment from ones own choice of components is much more aligned with the Unix philosophy.

I don't disagree that building your own DE is a fantastic way to operate, but the point remains that it is in no way, shape, nor form simple.

It's taken years for my own collection of tools to stabilize enough that it isn't painful to juggle ethernet/wifi/mbim connections. So that my displays are properly laid out (automatically) when I get to the office and plug in my monitor. So that my laptop consistently sleeps when I close the lid, instead of continuing to run in an enclosed bag. So that GPS on my cellular card is usable at the same time as an internet connection. So that Java applications run properly (don't forget to tell your window manager to lie about its name!).

Now that I've wasted so much time over the last decade tweaking and tuning this environment to make it stable and mine, I wouldn't give it up for the world -- and suspect I can't give it up at this point without massive changes to my workflows.

You are quoting me out of context. I originally said i3 is simple in a reply to a post complaining about KDE and GNOME, both of which are hugely complex installations of numerous libraries and services. So complex in fact, that they cannot be made to work reliably. Granted i3 provides substantially less functionality, but this comes from being simple.

Your examples above are mostly common configuration issues, easy to find with Google. Even a Windows user would likely need to Google many things (e.g. disabling forced updates, privacy settings, registry hacks).

I'm also skeptical that Gnome or KDE will make it significantly easier to solve such configuration issues. Do they even allow settings to be easily moved to another machine? Unfortunately Linux in general will always need some tweaking to work with specific hardware.

You provided absolutely no context to go with what was quoted.

You replied suggesting a specific window manager (a single component within a desktop environment) to a post lamenting the rough edges in popular modern DEs. You made no indication that your recommended replacement offers no way to hot plug a monitor, connect to the internet, or even launch an arbitrary application without installing and potentially configuring additional packages. These are very basic features folks have come to expect in a DE.

Making this sort of recommendation is throwing the user headfirst into a painful situation likely to give them an extremely negative impression of i3.

> You provided absolutely no context to go with what was quoted

Not explicitly, but I never said configuring or using i3 was simple. It is a very valid point, but is does not refute the fact that i3 is itself simple.

> You made no indication that your recommended replacement offers no way to hot plug a monitor, connect to the internet, or even launch an arbitrary application

I should have written more originally yes, but I have since given my recommendations for these. So why bring it up again?

> Making this sort of recommendation is throwing the user headfirst into a painful situation likely to give them an extremely negative impression of i3.

This is Hackernews and I was replying to knowledgeable posters. I think it is safe to assume they will look into it first without getting into a "painful situation".

Although you do raise some good points, I feel it is your posts that have given an overly negative impression of i3.

Well, kind of up-to-date application stack. If you worry about security fixes, SL repositories don't usually have the latest versions. E.g. PHP7 repo still has 7.0.10 [0]

Re: stability and QA, couldn't agree more. I only briefly used Ubuntu LTS in production back in '10 and it wasn't a fun experience. I'm sure it has improved but RHEL/CentOS (almost) never lets me down in that regard.

0 - https://www.cisecurity.org/advisory/multiple-vulnerabilities...

For PHP, you'd want to use IUS instead: https://dl.iuscommunity.org/pub/ius/stable/CentOS/7/x86_64/r...

Source repo: https://github.com/iuscommunity-pkg/php71u

For security reasons, I'm directly building the packages from Git. Works like a charm, and I don't have to include many different third party repos or introduce additional security dependencies.

Generally, Red Hat backports security fixes without incrementing the version number (though that doesn't seem to be the case here).

How does this compare to remi's repos ?

Personally I prefer remi because package names are kept the same, making it easier to upgrade. With IUS, the version is part of the package name (i.e. "yum install php71"), which tends to make maintenance and configuration messier.

>Re: stability and QA, couldn't agree more.

While generally all LTS distros are quite good these days, I've found that, unsurprisingly, features that are developed heavily or owned by a single distro end up being rocky. RHEL has a lot of things that are not as heavily used elsewhere, and they are far from production quality. For eg., their lvm thin provisioning feature, is pretty rough, and had some very obvious failure cases that could even lead to data loss. I'm guessing that no one uses thinp in production.

Please elaborate. I do use thinp in production (OpenShift + devicemapper pool as Docker backend, which uses thinp).

The default metadata pool size chosen by anaconda, at least up to RHEL 7.3, is paltry. Something like 100 MB for terabytes of data. Why they chose that is beyond me. Anaconda won't let you configure it manually during installation either. It'll get full in no time. Automatic extension is disabled by default. If you're lucky, you'll realize this by looking at your own logs. Then you'll try to extend it, at which point you'll realize that extending it won't extend the pmspare vol, and you've effectively disabled the pmspare functionality.

Yes but that's well-known and documented. Including it in Anaconda looks like an oversight though (a thinp deployment needs to be well-planned and you'd definitely want to read the docs).

There's a whole book-sized section about in the storage docs.

The docker-storage-setup utility, for example, sets it up correctly and enables automatic extension.

No, the use in Anaconda is perfectly legitimate. Docker aside, I use it for automatic snapshots. That's a fairly useful and unique feature that you can't have in any other legit way (not counting zfs, and btrfs is deprecated). There is also the yum-snapshot plugin that relies on it. It's not even that complicated. Just throw a few gigs at metadata and forget about extensions. If I have 2TB hard drives, I don't care if you use 16 G for metadata, which is the max.

LVM snapshots are really slow though.

That's the whole selling point of thinp (at least for root and home). They are supposed to be faster than regular snapshots.

The fact that RHEL recommends (recommended?) thin pool is malpractice. When deleting containers, the storage is never released. If you create lots of new containers, doing batch processing for instance, you will eventually exhaust the storage capacity even if you are extra careful to always garbage-collect the dead containers.

We switched to overlayfs and never looked back.

Storage with docker is just such a mess. In the end I went for Triton (SmartOS) which has ZFS and docker support and never looked back.

... which is now supported by rhel!

This. Our CentOS 6/7 deployment has been completely uneventful! Ubuntu going back to 10.04 LTS was hell.

In my experience they wax and wane. We're on our fourth distro in 10 years. Change has mainly happened because "it don't work with the new hardware we just bought". Currently on Ubuntu fwiw.

> RPM packaging is more fun than DEB.

How so? From my experience, these two are equivalent to a high degree and don't differ much, and I've built a lot of both.

Interesting - I did the exact opposite. Red Hat have a habit of removing packages that compete with their commercial offerings, which forces you to either compile from source or to install from other repositories - for example, they removed Apache ActiveMQ because they offer JBoss AMQ.

This starts to become annoying because all of a sudden you have multiple update processes to keep everything up-to-date, whereas previously, you had one. After being bitten by this at least twice, I shifted everything to Ubuntu.

I've had the opposite experience: compared to Debian, RPM distros feel like they were built by children. I guess YMMV :)

Notable point: Red Hat are effectively declaring btrfs has no future.

From the release notes: "The Btrfs file system has been in Technology Preview state since the initial release of Red Hat Enterprise Linux 6. Red Hat will not be moving Btrfs to a fully supported feature and it will be removed in a future major release of Red Hat Enterprise Linux."

https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...

That's bad, Btrfs has really grown on me, especially the ability to mix drives of different sizes in a RAID configuration.

XFS is just not flexible enough, I don't like to be unable to shrink a partition once created.

It looks like I'll be back to ext4 and various kludges then.

Mind that btrfs will remain in RHEL7, but as soon as you go to RHEL8... you could just build your own kernel. Or use the centosplus kernel which will almost surely include it (as they've been including various RH-disabled modules for RHEL6 and 7 already).

> That's bad, Btrfs has really grown on me, especially the ability to mix drives of different sizes in a RAID configuration.

That's nice, but the fact RAID 1 still is implemented with critical defects might help understand RH position.

Or, assuming you get over your partition resizing fetish, just stick with XFS. It's as close to bulletproof as you'll find on Linux.

Yet to gain data checksums though.

I wonder if they'll be supporting ZFS on Linux now that it's gaining momentum?

I highly doubt Red Hat will ever touch ZFS. Oracle and Red Hat have a very tenuous relationship.

I hope Red Hat will support bcachefs though. I think it's the most promising alternative FS.

Unlikely, given the license of ZFS and its incompatibility with the GPL

didn't they settled to xfs long ago? Isn't the default root fs on fedora xfs?

Yes, btrfs was a tech-preview, meaning use if you want with no support or future guarantees. It has been officially dropped from future plans now.

And they're working on adding CoW and deduplication to XFS.

Wow I didn't know that. Very interesting to hear. Hopefully Docker support is considered as well.

overlayfs + XFS works very well, so it's probably not a priority (wild guess)

XFS went through a tech preview -> support -> default over the RHEL 5/6/7 lifecycles.

The fact btrfs has been yanked from tech preview would tend to suggest feedback has been so bad that they believe it can never make it to being supportable.

I wonder why that's the case? is it not well-maintained?

Running btrfs in production is still a nightmare in 2017.

At least the random kernel crashes stopped.

With proper care and feeding, it won't run out of metadata either but you need to monitor it closely and run nightly balances. Which probably kill your SSD.

Documentation sucks. Get used to monitor the btrfs IRC channel closely and deduce what to do and what not to do on which kernel version.

It works well for very particular use cases (file server with few random writes and much duplicate data). Cannot recommend it otherwise. Even Docker runs more stable on XFS.

Have a look at the RAID 1 implementation.

If you have a 2-disk mirror and one disk fails, you can mount the remaining disk one more time to try to recover.

If you try and mount it a second time it is marked permanently read-only and can never be recovered. You need to dump the data and rebuild from scratch.

It's 2017. It's been in development for almost a decade, and getting the simplest RAID case correct hasn't worked.

RAID 5 and 6 were found to be losing data without a drive going bad. I pulled all my data off to backup and restored it on a freshly built array under XFS. That's not something I enjoy doing too often.

Yeah, having scrubs corrupt good data is basically the worst-case scenario for an FS whose selling point is checksumming for data integrity.

I ran btrfs for several years, and while the features are great (per-subvolume RAID policies, lightweight snapshots, unRAID-style RAID), I got sick of testing my backups regularly. I wouldn't be surprised if that's not uncommon.

A very big change, although not widely reported, is the update to OpenSSL 1.0.2k, which brings ALPN to RHEL & CentOS.

This in turn allows HTTP/2 on Chrome to work again if you're using Nginx as a TLS proxy on your server.

Some more info here; https://ma.ttias.be/rhel-centos-7-4-restores-http2-functiona...

Another big change is SELinux support for overlayfs, which means you can use the overlayfs2 driver with Docker without disabling SELinux.

One thing that is souring me on RHEL+clones is Red Hat's habit of yanking drivers for SAS and SCSI controller cards. On my home file server, CentOS 7 is the end of the line unless I buy a new HBA.

Then there was the old Dell server at a customer's site that we were planning to use for a development/testing system. It had a perfectly functional PERC/4e RAID controller, but Red Hat yanked the driver in 7.0, never mind that Ubuntu Server works perfectly on the same hardware. We ended up picking up a cheap refurbished desktop to use as the development box.

The driver loss has even caused problems for me working for Red Hat :-/ I had to build versions of virt-p2v on top of RHEL 5 and RHEL 6 so that our own customers could virtualize older physical machines with the HP/Compaq RAID controllers: http://oirase.annexia.org/virt-p2v/RHEL-7.3/

This is one reason I don't run RHEL on bare metal, but only on a VM(ware) host. I know it's not free, and not cheap, but I'd rather not hassle with issues like that.

ESXi is most definitely free if you can live without the enterprise features.

For example, in many setups a max of 8 cores per VM is sufficient, and IIRC there are no longer memory or storage limits for the free tier.

The web admin (which replaces phased out vCenter admin interface) is pretty decent. Between that and the cli you're sorted for most non-enterprise use cases.

But yeah, if you need vMotion and all the other orchestration features, the licensing is...far from free.

Indeed, I considered the idea of installing Ubuntu Server and then putting CentOS 7 into a KVM guest. In the end, just using a desktop machine for the testing system was more practical.

I would have been far happier if they retained the driver as an "unsupported" option with a warning during installation, rather than flat-out removing it.

Some examples would help. So far, any example of drivers disappearing that I encountered were due to quality issues.

The abovementioned PERC/4e is an example. The driver was deprecated in RHEL6, and gone in RHEL 7.

The card in my home server is an Intel SASUC8I reflashed with IT firmware, so it's equivalent to an LSI SAS1068E. The driver for that is listed as "deprecated" in 7.

Another is the 3ware 8000 series. We got a dead machine in recently for repair and were faced with either moving the RAID drives and card over to a new server chassis while being restricted to the EOL'd CentOS 5 or upgrading to CentOS 7 but being forced to buy a 9000 series card and rebuild the array.

Lose-lose.

Well, I can see why Red Hat wouldn't want to support those old cards forever. Including the driver would be easy, but actually supporting it (QA, support...) is not.

They already supported them for close to 10 years, which is much longer than most hardware lifecycles last nowadays (3-5 years).

You could still build a custom kernel but yeah.

Anyone know how much a lag CentOS is normally behind Red Hat releases?

About a month:

  7.0: 4 weeks
  7.1: 3 weeks
  7.2: 4 weeks
  7.3: 5 weeks

Source: https://en.m.wikipedia.org/wiki/CentOS#CentOS_releases

Does it come with python3 installed by default, like recent Fedora?

No. And it won't be until (at least) RHEL 8. It's available from SCL[1] and IUS[2] though.

[1] https://www.softwarecollections.org [2] https://ius.io

It's also in EPEL now. SCL is cumbersome by comparison for basic usage.

Nice.