Comment by ezoe
7 years ago
Actually Red Hat is exactly like IBM. Huge and slow.
I know the contribution to FOSS from Red Hat is great and all, but their product, RHEL, was a cancer for a modern software development.
Just easier to maintain for sysadmins doesn't make enough excuse for really long release cycle and the worst of all is they keep supporting the old products.
The result is a nightmare development environment for all the programmers who has to workaround the old bugs that was fixed years ago in the upstream but not fixed in the RHEL packages, but they have to use the RHEL packaged software for stupid sysadmin reasons.
What's the alternative? All of the places I've worked that used Red Hat never explicitly looked at the Red Hat support timeline. They looked at their business, the software they used, the features they needed, and based their upgrade cycles around that. They'd only upgrade the major versions of their primary software when a project would benefit and skipped major updates that were problematic. At my current job they're only now upgrading from a 2016 piece of software to 2018, they're also straddling Cent 6.7 and Cent 7.2 and only making moderate progress.
Usually the reason for updating the OS is because new software doesn't run, there's a major feature needed, or supporting the old OS is too much trouble.
But it's not like it's any different on the Windows side. XP stuck around forever. At my previous job they had Win7 on workstations with little to no intention of updating to Win10. On the server side it was all over the place including Windows Server 2003.
I suggest the latest Debian stable or Ubuntu LTS.
Debian stable keep the history of roughly 2 years release cycles. Ubuntu LTS is set to follow strict 2 years release cycle.
Ubuntu seems like a good replacement. We use it, and I greatly appreciate that the compiler is not stuck on barely getting C++11 support.
The problem isn't that RedHat's release cycle was too long, it's that companies want support for 5 year release cycles. Most places I've been don't even look at testing a major version of a new OS for at least year. There are just too many variables between hardware, drivers, and software and little to no benefit in staying bleeding edge.
Let's say there was a new feature. It might be an improvement in almost every regard, but how it behaves at the limits or when left unattended might not play well with every other piece in the system. Part of it might be changing user/business expectations, or changing the pieces around, but that can literally take years.
A few wrinkles I've heard about, but haven't directly dealt with is that RHEL7/systemd is too polite about unmounting disks on shutdown which means it will just hang. This is a huge problem for remote workstations that don't have IPMI. Another issue I've heard about is issues with a bunch of our diskless servers don't play well with it. Having to migrate and troubleshoot core issues like these every 2 years is just unfeasible.
As you point out, just working at a place where everything is 10 years old is frustrating, too. Last week I was trying to build VLC, which requires C++11 and had issues. At previous jobs I pushed really hard for a new enough kernel to evaluate Docker and have spent a lot of time selling people on Git.
"stupid sysadmin reasons" Yeah, who needs stability and consistency? It far more important to be able to jump upon the latest whizz, bang, wheeeeee!
By using the obsolete software versions, it cause instability and inconsistency and a lot of effort will be wasted to workaround the issue rather than solving the real problem.
You’re fundamentally wrong here. Red Hat providing a long-term and stable operating system and software target provides stability to users of RHEL. Upgrading your operating system, system libraries and toolchain are valuable changes, and should be done periodically, but these changes, like any other, introduce instability across the change. Those risks can be mitigated, but they are risks nonetheless.
by "cancer" do you mean its not shiny and new?
Yes, RHEL6.x is a pain but that's because its old. For what ever reason AWS decided to standardise on that and not 7.x.
The crucial part is this: it works, and when it doesn't, there is a boat load of documentation on why and how to fix it.
Totally agree. RHEL's support windows are FAR too long and result in more problems than they solve. Large businesses wait till the last minute to upgrade then realize that working through a minimum of 5 years (often 10) of changes is extremely hard. This means that you often run unsupported while everyone scrambles to fix all the changes introduced by the upgrade. Cannonical's 5 year support window is much more sensible.
For individuals and small businesses, sure it makes no sense. But large enterprise customers will pay a lot of money for support windows that are far too long. That's why Red Hat (and every other large company) offers them. Even when the publicly available support ends, they still often have hangers-on who will pay even more money to get a few more years support out of them.
Look how slow Redhat moves up their kernel, Redhat simply is the IBM in the open source world!