What's wrong with enterprise Linux
unix.foo
unix.foo
LetsEncrypt did us a huge favor by forcing automation vs having the guy who knows how to update the SSL certs every 4.9 years and left 6 months ago. I'd like to see the RHEL stability model go away too and force people to complete their automation and solve the problems of being able to rebuilding on demand - and actually doing it.
(I know, most HN folk are well disciplined but there are a lot of corporate cultures that are not.)
SSLMate is about as old as LE, they both started around the same time.
Whenever there's a new distribution release it invariably breaks a bunch of things with the automation and you spend more time massaging your playbook so it works again than it would have taken to do it by hand
But even still, things like snaps, the way Debian handles system Python, and various little changes that have an outsize effect on automated deployment do cause a good amount of churn with automation.
However, paying an extra engineer to sort through all the changes possibly will.
On the other hand, there's some interesting trends like monokernels and minimal OS images that leverage services running off-machine instead of expecting so many local services removing some of the complexity/volatility (DNS, SMTP, federated login)
Both these things should not be an issue for anyone, just one or the other.
The rolling-release life is that things break constantly, during each week’s upgrade, but only a little bit at a time (and hopefully in staging). I don’t know if this is better for system administration, necessarily, but if you’re used to a stable-release dynamic of heavy discrete breakage and piles of backported patches, then you might be imagining the same scale of breakage every upgrade, which is isn’t the experience at all. So don’t discard the rolling-release option because of this preconception.
If you only update every few years, each update becomes a full project distracting from and conflicting with other projects.
That entirely depends on your operations model. There's a difference between, say, a nuclear power plant and a colo web hosting shop. With the latter, sure, no problem risking "minor" weekly breakage. With the former, I'd much rather have scheduled, heavily tested and carefully monitored maintenance windows.
And HN tends to underestimate the number of places like the former exist. Backbones of global finance and telecom, industrial facilities of all kinds, etc.
And yes, upgrading that is a full blown project.
It is very different from a "living" software environment with ongoing development processes.
Changes to graphics drivers, can, do, and have impacted how things like MRI results get rendered by software. It's going to have at least some networking with the rest of the hospital and difficult to completely airgap, but at the same time you cannot update it willy nilly with the latest and greatest uncertified drivers.
That's precisely where "enterprise" distros are sometimes necessary.
The vendor (Siemens or whoever) should make updating the OS part of their development cycle and certify accordingly. If drivers are relevant part of the product there, they have to take enough ownership on the drivers to ensure they do the right thing.
Another example would be systems setup for CAD. Certain levels of CAD require certified video drivers in order to unsure tolerances are met. Error introduced at this level destroys product and possibly people.
I could be convinced the former were the answer in many cases, but I’ve never seen the argument for that move beyond a bare proclamation like you’ve just made. It may also be that the argument for this is so mired in the particulars of a situation that it essentially can’t be articulated, but for me that’s mutually exclusive with it applying to a broad, vaguely defined classes of deployments like you’ve just done. (A complex argument is bound to produce an intricately shaped class.)
My (admittedly theoretical) fear in my initial comment was that the LTS people read about kernel updates every month, think of the breakage their LTS encounters on every kernel update, and nope out. Yet without the humongous pile of backported patches the LTS requires kernel updates are the most benign thing in the world if you can afford the reboots—a decade of them with literally not a single issue can and does happen.
Do you work in an industry that requires a specific service level to be maintained? How many hours per day? What does downtime cost? What does redundancy cost?
We have situations that cost millions of dollars per hour when downtime occurs. Now how do you protect those systems?
A definition of Hubris is not believing something exists because you haven't seen it before.
Our tasks as Systems Administrators is not to make a career out of updating systems for maintenance patches. Our task is to design systems to minimize updates and then redesign systems to eliminate wasted user interaction and downtime.
There are too many places where the current guard is going to have to die off before they even _start_ automation. So we're looking at 20-30 years.
LTS is the actual sane solution for these places, despite how utterly insane it is.
Folks who know such things better than I do, have suggested that it would've been far better at like a 64-week rollover (or just chop it to 52 and leave part of the code space unused), that way everyone would have to have a plan for it. Nobody could claim they don't expect their hardware to be in use 64 weeks in the future therefore they can ignore rollover.
So how could this be accomplished?
A Nix-OS style approach coupled with an immutable OS core?
It is much harder to offer stability guarantees than to just publish updates in a rolling release fashion. And yet big organizations pay big money for that stability or the support to poke an enterprise software provider to get stuff working for their needs.
The issue is that a rolling-release approach does not have stability guarantees and forces everything to be upgrading all the time.
This does not work very well if you have specialized hardware or scientific equipment. If the drivers for your lab equipment work with a given release of an enterprise linux, you can't just jump on the next release until you have working drivers ready.
The same is true if you are working with some enterprise software which is only certified to work with a given release of an enterprise linux. Would you really want to run business critical software on a version of the operating system which is not (yet) supported by the vendor?
Also shout-out to Arch ... I've been using it since ... forever and never really had an issue in update.
Rolling updates mean that I have to carefully choose what to install in order to keep the maintenance costs down. This has the side effect of reducing the attack surface.
I also manually review updates, which means that I keep up with the news in OS land.
I have to reboot once in a while because of updates, which means that I test resilience of my infrastructure.
By comparison, RedHat stack at work feels creepled and ancient.
You need a RedHat account (read: subscription) for pretty much everything, even the most basic documentation or downloads and yet my bugs in their bugzilla linger for months with none even trying to reproduce, let alone fix.
If you dont have comprehensive integration tests it's less risky just to not upgrade unless you really need to.
Exactly. Most of us do not have sqlite-level (https://www.sqlite.org/testing.html) testing so we just do the best we can with the resources we have.
This tends to make most "enterprise" shops risk-averse and the motto becomes "if it's not broke, don't fix it".
How does Qubes OS work with drivers for specialized hardware such as scientific lab equipment?
Qubes OS doesn't really solve much in regards to stability and work required to update in a professional setting though, I'd say.
Using a GPU passthrough indeed decreases the security, but it is still much more secure than anything else. More details: https://groups.google.com/group/qubes-devel/browse_frm/threa...
> Qubes OS doesn't really solve much in regards to stability and work required to update in a professional setting
Couldn't disagree more. All software runs in VMs. The Admin VM never goes to the Internet or runs anything. Therefore it's less necessary to update and reboot it: https://www.qubes-os.org/doc/supported-releases/#note-on-dom...
All VMs are easy to backup/restore in a few clicks; cloning for testing and upgrading are amazingly smooth. All this with a great GUI.
Regardless, even with the ease of virtual machines, Qubes OS doesn't really solve problems involved in professional management, nor should it be considered for that given the overhead of the system. It's a neat system, and for general purpose use it's pretty cool, but for stability and work required to update a system, it really doesn't.
Sure, it makes general use-cases pretty easy to update, but those aren't really much of a problem if you've set up a PXE server and have a base image together with default configuration. The issues occur when you're updating servers, which is what I was talking about, because the end-user isn't that important in this context.
Whether you have it running in a hypervisor or bare metal, it all comes back to properly configured backups. Qubes OS doesn't solve this, nor is it meant to. It increases security at the cost of convenience and complexity. Nor does it solve stability in a professional environment, because while it does give you an isolated OS per application or stack of applications, you've now increased your maintenance surface. Servers need to be updated, within a reasonable time frame of ones being provided, and general computing often requires more of that too.
And at the end of the day, while I do like Qubes OS and do like virtual machines, they're not the be all, end all, in regards to security. Exploits exist, and as with all things, the more common they become, the more will be made.
I do still hope for a system like Qubes OS in the future, just not Qubes OS.
In this model, what happens when the next Python2->Python3 breaking change comes along?
Also, Enterprise Linus is one of the reasons (definitely not the only) that the migration took such a long time. Too many enterprise shops that stuck with Python 2 because it's the lazy thing to do. The tech debt grows every year you don't move with the ecosystem.
How far down does "own your application environment" extend? How about libc? What is the role of the underlying OS?
It depends on the needs of your application.
>> How about libc?
If you need to make sure the underlying libc has what you need, you must either bring your own libc or have sufficient feature test macros and adapters to account for possible differences.
>> What is the role of the underlying OS?
It depends on what the application requires. What operating system features, if any, do you require? Do you have any timing or scheduling requirements that are sensitive for your application? Do you need real-time responsiveness?
How does the operating system handle failure scenarios? What guarantees, if any, does it make when hardware fails? Is it okay for your application to crash if a portion of the computer's memory or disk borks?
Ideally none, with scratch containers for applications and the bare minimum running under your orchestrator which becomes your main interface.
Main issue is drivers, of course. It's hard to beat Linux. It contains open source drivers and server vendors usually target Linux and Windows with their driver efforts.
As for 10% security - it’s more than 10%. Take my same example, the Switch. No bugs have been found to launch unapproved software in the last 4 years. There’s always the Secure Boot bug by NVIDIA in earlier consoles, but not even a WebKit bug will get you homebrew on a Switch. Kind of a big deal…
Another example of this would be Microsoft’s experiments with what would happen if an OS was built with all apps running in managed code - no compiled apps. Performance cost? They got it down to just 7% (though, admittedly, Midori never shipped, but it did host Bing in a few countries for a few years.)
The five year reign of RHEL7 was too long and did result in the very issues you bring up, but the ~3 year duration of RHEL 5,6 & 8 was short enough to avoid problems due to attrition in enterprise settings (unlike startups which have higher turnover, and not counting bus factors of one - no release cycle can't solve that).
And like others have pointed out, automation doesn't help as much when moving between releases. We have everything configuration controlled with kickstart and ansible and/or docker, and it is great for reproducibility within a release cycle, but it doesn't save much time or knowledge between releases. And Ubuntu is even worse in that regard despite having a shorter release cycle.
Admittedly, Yahoo was an extreme case. It never solved the really building problem - the culture from the early days was to compile, ship and forget. Once a RHEL-6 package was pushed to our dist/yinst system (packages), it would never be rebuilt unless it was 1) necessary, or 2) It was time to try and figure out how to build it on RHEL-7.
A lot of effort was spent in the later years to try and address this (by burning the old tech stack to the ground), but the culture was pervasive for the longest time. If 10-year-RHEL didn't exist we would have been forced to address the building processes.
If it's hard or error prone, then do it frequently until you get the process nailed down.
Major life lesson -- practice makes perfect.
The average person could practice violin for 500 years and never be invited to play Carnegie Hall.
I assume you mean major releases. Less common than minor releases but, especially for air-gapped equipment, it's not that unusual.
Industry specific - but finance world, we still had straggling RHEL5 machines up until a year or two ago and still have a bunch of RHEL6 machines and have basically NO RHEL9. The vast majority of the machines are all sitting on RHEL7/8.
The ability to stay abreast of major version updates is a wonderful attribute of many environments, but definitely far from all.
I probably have some details wrong in the story above. I worked with those people, but never on the mainframe. I think the point stands though, if you don't do something often it can't be done.
Also Pascal and BASIC compilers with several extensions, e.g. VMS Pascal and VMS BASIC.
I always call them mainframes, regardless if the name is micro or whatever is the pedantic nomenclature.
The string handling functions in chapter 20 require the programmer to pass around separate pointer and length arguments, which is not what I would call proper strings.
Only half joking.
A mainframe has hardware different enough to require a different approach to the OS.
Of course a modern variant of System 390 happily runs tons of Linux VMs.
If a medical device or train works but needs support for years and years, should someone be constantly updating Linux? What about the software that runs on Linux and is tested there?
Considering just the modern cloud environment really limits where enterprise Linux runs and is useful. And, where there are calls for really long support contracts.
Yes. If you have embedded software in the field and it is running on hardware that has not reached its EOL, then you absolutely should be fixing bugs and vulnerabilities, doubly so when that hardware is attached to any kind of network, and triply so when the software talks to some kind of cloud services.
For most products, the customer should have the power decide when that hardware reaches EOL. In other words, it should be illegal (and severely punished) to disable or downgrade devices remotely, whether by abdicating the responsibility to maintain their software or by shutting down network services that those devices require to operate fully.
At the very least, that would prevent the proliferation of pervasive networking features that have no business communicating with anyone except their owners.
Talk to Qualcomm and NXP and MediaTek and Broadcom and STMicroelectronics and....
Seriously, most of this is completely out of the product engineers' control. We can't update the hardware because our vendors (ALL of our vendors) control the kernel selection, almost never upstream, and never keep the board support packages up to date. Never.
IME the only exceptions to that rule are RaspberryPi (kinda sorta), AMD, and Intel. I only recently managed to finally extricate all my projects from Linux 2.6 which I considered a minor miracle. In 2023.
Ok, I'll be the unpopular person here.
Some bugs, even security ones: are ok.
I know that a very significant amount of software is mature these days, but sometimes upgrading causes different bugs, which are either harder to diagnose or even potentially more deadly.
I work in gamedev though, releases are tradeoffs with which bugs we accept.
It is very frequently the case that fixing one bug will incur several other bugs, it's just a case of understanding if they're worse or not.
For example: I don't care that my TV will have a 1/100 crash when launching the settings. I will just launch settings again-
Coincidentally: having everything constantly updating and internet connected is counter-intuitive. I used to spend entire evenings waiting for my PS4 to install new software on itself, but the PS2 (which contained many bugs!) worked much more often.
When you only have a couple of hours free time, spending it updating firmware means that I just don't update or use it.
I mostly agree, but the severe punishment for not keeping software or services updated and running should be to release as much of the software as you own and a full hardware spec, well before you turn off the lights. People have to be allowed to get out of a business.
If you bought a product and the vendor said it will be supported for X years with updates — that’s all you get — X years. If you want to keep using a product for X+1 years, that’s fine, but that’s on you. I agree with your sentiment that hardware shouldn’t be disabled, but I don’t expect security updates past EOL. You can’t expect a business to keep supporting a product longer than they originally said they would (without compensation).
But these are enterprise products… support contracts last a long time. More than enough time to migrate (or past the time when you should be migrating). That’s part of why the long term support exists in the first place.
Where is your other embedded equipment???
I love that movie.
Usually you cannot do the same with a flight computer or a medical device controller.
And HN is full of developers.
On a related note, the new EU Cyber Resilience Act will make upgrades a necessity even in the most constrained environments like pacemakers.
But it can be really hard to change the culture at a place that has a long history of "ain't broke, don't fix it" engineering.
The places that don't do constant upgrades also don't usually have teams looking after that. If they time it right they can do with less people.
Of course it's less reliable not having as much active knowledge but I do think it can be cheaper if nothing goes wrong.
In my comment, I was thinking of well staffed (or at least close-enough to well staffed) teams making deliberate decisions to defer.
Upgrades however are a different story. The major version changes require a ton of testing and manual massaging. This is why enterprises like to have that infrequently. For the systems that are easier you can still choose to follow the releases quickly.
Because security patches are being back ported is usually not a real issue.
The main issue is that certificates should really be automated by every web server by default. At least for those with public IP addresses. There are servers like Caddy which implemented it, but it should be basic feature that just works without any additional configuration.
Those problems can also be mitigated with mandatory environment rebuilds which is trivial for a lot of setups with infrastructure as code.
At the extreme end, you have Kubernetes/CNCF where 6 months go by and you're many versions behind with a huge changelog of breaking changes you have to fix first. Stable APIs and stable ABIs are very useful here (which enterprise Linux provides).
An example of argument that belongs to a weird class of arguments you at the same time want to agree and disagree.
This is known as the out-of-the-loop performance problem. [1]
[1] https://en.wikipedia.org/wiki/Out-of-the-loop_performance_pr...
Not in my experience. There's still a guy who goes around and updates (manually) all the LetsEncrypt certificates every year.
Sounds like my org :)
LetsEncrypt certificates don't last for one year, they only last for 90 days, no exceptions. You may be thinking about something different.
1. Maintenance is expensive.
2. Maintenance of living systems is even more so.
3. People hate spending money on maintenance.
4. You reap what you sow.
This is not a Linux problem - it's a culture problem (and probably goes well beyond the US).
[0] - https://infrastructurereportcard.org/cat-item/bridges-infras...
I did not see that twist coming.
Strangely, the author makes a good point. Oracle or not, sticking closer to the upstream kernel is not a bad way to manage an “enterprise” kernel. Maybe we’ve all been too willing to sit back and accept how RHEL does kernels as “the way”.
Linus' "security problems are just bugs" approach has been worrisome.
To be clear, I only used Oracle Linux briefly while playing with the free tier of Oracle Cloud.
Edit: sorry, but I don't get it, please break it down for me. Latest UEK 7 is based off 5.15 LTS ( https://docs.oracle.com/en/operating-systems/uek/ ), that puts them at branching off a kernel released on 2021-10-31 (according to https://en.wikipedia.org/wiki/Linux_kernel_version_history#R... ). How is that even remotely 4 weeks behind master?!
Edit 2: my bad, I didn't read the "behind the tip of the LTS tree" part carefully. So, the difference is that Oracle tries to ship all LTS kernel updates, while RH tries to cherry-pick critical security and bug fixes only?
Most of the RHEL kernel is a few months behind upstream despite the old version. The next minor release of RHEL, to be released in November, probably will have features up to 6.3 for many subsystems and bugfixes up to 6.5 for example.
But you're still beholden to what the Red Hat maintainers are pulling in and focusing on. It's still not a general follow upstream wholesale.
You can see and track what UEK is doing by looking at their Github: https://github.com/oracle/linux-uek/commits/uek7/u1
Aren't they?
This is probably a lot better than expecting it to be possible to maintain a secure release with a level of compatibility guarantee for 10+ years.
Maybe the compromise solution is to use newer kernels but keep certain features turned off until they "bake" properly.
I think we need a fully open source alternative to RHEL not bound to any company. Something akin to the Debian project that can serve as an upstream reference distro and repository.
I believe the problem is not that there wouldn’t be open source alternatives but that that’s not what enterprise wants. Enterprise wants a company behind the distribution.
Or am I the only one?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...
Also kernel updates breaking drivers is a thing.
So there's definitely value with frozen kernel version. And its almost the same value as frozen software. It just works and it won't break after update.
I can't for two reasons:
1) The only way I avoid the repulsive side of Oracle in this is if I don't care about having a reliable guaranteed enterprise support contract. No one is going to have more expertise in how this distro is built & functions than Oracle, and that's the no-go zone.
2) It's not just about the current status of the project but also the future and what happens if this author is successful and lots of people switch over to Oracle Linux. Nothing stops them from switching things up at short notice (unless I pay them for a service guarantee!) and pulling the rug out from underneath the whole thing. And the more that people adopt it as their distro of choice, the more likely Oracle is to look around for some way to monetize it at gun-point (well, crippling legal bills at least)
I'm sorry, but this paragraph proves that the author has not fully understood the purpose of enterprise distributions.
The primary selling point is not the stability of the software, but the stability of the API and ABI. There is closed source software such as SAP that is compiled against the ABI of RHEL and SLES. And lots of expensive enterprise hardware ships Linux kernel drivers in binary form only, so that a stable, i.e. never-changing kernel ABI is required. Examples for such hardware is the SGI UV series whose drivers come in binary form only and therefore the hardware is supported on enterprise distributions only.
Both RedHat and SUSE put a lot of effort into keeping their API and ABI stable, so that enterprise customers are guaranteed that no distribution update is going to break the software that they're running on the hardware they're using.
Also, when you deploy Linux on hundreds or thousands of clients, a rolling release distribution would be a pure nightmare. Given the large amount of clients and applications, there will always be a combination of applications and use-cases that will break after a distribution package was updated to a completely new upstream version.
Companies don't want software that changes all the time since they want to control the time for an update rollout themselves.
Vs, the other LTS distros that just track the upstream LTS kernel. That kernel both breaks things, as well as is "old" because its only generally taking security and bug fixes.
Expand that out to all the other similar kinds of applications.
> Rolling release distributions like OpenSUSE Tumbleweed follow upstream much more closely while still maintaining stability through thorough automated testing
Shows the author hasn't used Tumbleweed for any reasonable amount of time himself[0][1][2]. I daily drove it for a short while before moving to Fedora.
0: https://github.com/Foundry376/Mailspring/issues/533
1: https://forums.opensuse.org/t/tumbleweed-breaks-after-update...
2: https://www.reddit.com/r/openSUSE/comments/v09hnc/tumbleweed...
Many times, even Debian has avoided being hit by a vulnerability, just due to a good wack of issues being in fresh code changes.
And many times, even when the vulnerability has been a long existing one: RHEL is pretty focused on defense-in-depth, through compiler flag choices, SELinux setups, etc.
Sure, if you already had Oracle as a hardware vendor then the cat is out of the bag, barn doors open w/ horse gone. After that, using their distro isn't going to increase your attack surface much, the killer is already inside the house.
And the music maker side of me thinks your post has the beginnings of a promising blues lyric. :-)
I’ll be impressed when they open source Oracle DB and let Microsoft fork it and sell support for it. It’s pretty easy to commit to “open source” a copy of RHEL. Especially when linux isn’t core to their business but a bait and switch to get their customers on Oracle’s platform.
You are always limited to their opinionated decisions on what your deployment should look like* (or risk losing support), but at the same time, the support you actually get is next to none.
If I can't fix it myself, it ain't gonna be fixed.
At this point, I don't know what we are paying for anyways.
*As an example, more recent versions of RHEL only allow the use of NetworkManager for permanent network configuration. In a production hypervisor system, NM is completely unsuitable in my opinion. It's full of footguns and that will bite us at some point
You get to shift your blame on someone else. It's a commercial "covering your behind as a service", that you just blame $vendor when things go bad. It's the game big corps play, sometimes called "compliance".
Note how “Ksplice was the first project for live patching the Linux kernel; however, ksplice was sold to Oracle and eventually changed to a closed-source tool.”
https://www.redhat.com/en/topics/linux/what-is-linux-kernel-...
That is different kind of stability. No rolling release distro offers API (nevermind ABI) stability the way rhel etc do, which is the big selling point. You can install updates on enterprise distros without needing to worry too much about your application breaking because someone decided to have some fun with the API.
https://news.ycombinator.com/item?id=36599118
Frankly, I don't get it Oracle. I would say the priorities are backwards - JRE free, Oracle Linux paid would make more objective sense (especially because the JRE used to be free... and there's a lot of free JREs out there.)
Also, don't be stupid enough to download the VirtualBox Extensions package at work; or your work will probably get an email from a licensing agent.
There might be different alignments, but you simply cannot write stuff like this and get away with it if any of your superiors disagree.
That page literally admits Oracle is an asshole company
Place I used to work blocked the virtualbox home page because exactly this had happened.
https://www.youtube.com/watch?v=-zRN7XLCRhc&t=1981s
> "As you know people, as you learn about things, you realize that these generalizations we have are, virtually to a generalization, false. Well, except for this one, as it turns out. What you think of Oracle, is even truer than you think it is. There has been no entity in human history with less complexity or nuance to it than Oracle. And I gotta say, as someone who has seen that complexity for my entire life, it's very hard to get used to that idea. It's like, 'surely this is more complicated!' but it's like: Wow, this is really simple! This company is very straightforward, in its defense. This company is about one man, his alter-ego, and what he wants to inflict upon humanity -- that's it! ...Ship mediocrity, inflict misery, lie our asses off, screw our customers, and make a whole shitload of money. Yeah... you talk to Oracle, it's like, 'no, we don't fucking make dreams happen -- we make money!' ...You need to think of Larry Ellison the way you think of a lawnmower. You don't anthropomorphize your lawnmower, the lawnmower just mows the lawn, you stick your hand in there and it'll chop it off, the end. You don't think 'oh, the lawnmower hates me' -- lawnmower doesn't give a shit about you, lawnmower can't hate you. Don't anthropomorphize the lawnmower. Don't fall into that trap about Oracle."
More or less setting up a rigorous de facto compliance regime and making the arms race for enterprise distros be about who can establish the best regime and best gauntlet automation.
Although it's possible that newer versions are more secure, I couldn't find evidence of it yet. (Links are welcome).
What that doesn’t consider is that the vast majority of programmers simply don’t care to keep up with security concerns. And that’s why two of the most dangerous, easy to exploit, easy to stop attacks out there (SQL injection, XSS) are still among the most prevalent.
As long as features are growing, the claims that new is more secure is difficult to believe.
With an unknown vulnerability, I don't have any information about it, it could be affecting me right now.
For me was when I was trying to incorporate Redhat, Intel and Mirantis as a secure platform for on-prem-cloud as a service offering - and we were setting up the environment with RH, Intel and Mirantis (I was the Mirantis tech PM) - and it was a nightmare of IBM-esque beurocracy.
it reminded me of the nightmares of installing equipment in an IBM/Intel DC in the 90s...
Too fn many non-technical stakes in an undefined landscape and RH attempting to "feel enterprise" with Intel - and it was a disaster. (two FN months to get IP allocations????)
Yeah - I signed off on redhat way before this - but this is what made me hate RHEL.
They got too smarmy, just as LinuxCare did...
But to answer the Q -- They attempted to get 'too enterprisey with it' and emulate those who they were previously trying to take down.
(want some linuxcare stories)
> In April 2019, it was announced that feature development for Scientific Linux would be discontinued
However I think this is in itself a false premise. The obvious counterargument is that it is newer releases in which new security vulnerabilities are introduced, so after a while, an older release with backported security fixes is more secure.
Which argument is true depends on the relative rates of fixes vs. vulnerability introductions. This will differ per project, and therefore the balance may tip both ways too, depending.
But the article fails to make any assessment of this at all.
Is this 10 year assumption true?
Are people running 10 year old versions of operating systems today in non-safety or non-high security aspects?
10 years ago today is when the following were roughly released:
- Linux 3.8.
- RHEL 6.4 with Linux 2.6.32-358
- RHEL 7 was Beta with Linux 3.10.0
Are these still alive out there?
Should these systems have been upgraded sooner? One year has usually allowed plenty of time for testing and rollout of the next major release.
RHEL 6 is still under extended support until next year.
https://techcommunity.microsoft.com/t5/windows-it-pro-blog/t...
Though for newer releases they partially reduced it to 5 years.
This is sometimes called "compliance".
At a previous job we had a bunch of servers that were reaching End of Life and the tech staff already was planning on upgrading, but someone in the bureaucracy with veto and signature powers decided to extend their life to an extended warranty.
We had to keep running those slow and power hungry things for a few more years because we run out of budget.
And the "upstream versions" are how better from a security POV when they are mostly an incompatible redesign ? Or the OP means that GTK4 has fewer CVEs than GTK3 because it is newer and better ?
A new version of a library (or a program) does not mean a more secure version. It is mostly "new features" and the bugs are left there to rot.
This model is the "waterfall" model for operating systems.
[1]: https://lkml.org/lkml/2012/12/23/75 [2]: https://news.ycombinator.com/item?id=36805308
No, they actually get paid pretty well to do it. And pretty sure all the paying enterprise customers are “thankful” for the distribution’s stability and security, or they’d take their business elsewhere.
It’s more important to them type be able to tell auditors that they are following a mitigation process.
In my case that means all I’m doing is pulling Amazon Linux images and running automatic security updates.
Using Amazon Linux is the path of least resistance because it comes with AWS tooling and it’s already optimized for AWS.
Everything else is basically “who cares?”
Yes, and we spin up RHEL in them for some of our application servers.
And there are bigger differences between the versions of Windows than Linux too.
The initiative begets the spend. The spend and roadmap stretches 10-12 years, chassis fans and PSUs have MTBF that conveniently coincide with Moore’s law and the dark arts of finance, where ownership is good but only to that boundary.