this post was submitted on 13 Jan 2025
278 points (98.9% liked)
linuxmemes
21877 readers
886 users here now
Hint: :q!
Sister communities:
Community rules (click to expand)
1. Follow the site-wide rules
- Instance-wide TOS: https://legal.lemmy.world/tos/
- Lemmy code of conduct: https://join-lemmy.org/docs/code_of_conduct.html
2. Be civil
- Understand the difference between a joke and an insult.
- Do not harrass or attack users for any reason. This includes using blanket terms, like "every user of thing".
- Don't get baited into back-and-forth insults. We are not animals.
- Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
- Bigotry will not be tolerated.
- These rules are somewhat loosened when the subject is a public figure. Still, do not attack their person or incite harrassment.
3. Post Linux-related content
- Including Unix and BSD.
- Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of
sudoin Windows. - No porn. Even if you watch it on a Linux machine.
4. No recent reposts
- Everybody uses Arch btw, can't quit Vim, <loves/tolerates/hates> systemd, and wants to interject for a moment. You can stop now.
Please report posts and comments that break these rules!
Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
RHEL 7 and RHEL 5 need to be flipped in your meme.
Any large enterprise still running RHEL 5 in Prod (or even, yes, older RHEL versions) has fully accepted the risks and will grumble about supporting it, but go forward with whatever workarounds are necessary to keep the application running on it running. The RHEL 7 folks, however, are modern enough that the answer for any problem is "Upgrade to RHEL 9, because we know you can with some effort, because we don't want to waste time on supporting something you should be able to upgrade away from".
This is the game of chicken in a modern enterprise for app teams. If their application is critical enough to business continuity and they remain on RHEL 7 long enough, they too will join the select few applications in the org that either get a cash injection for an application rewrite to modern RHEL 9 or be enshrined next to the RHEL 5 apps still running with grumbling, but continued support.
In a perfect world these EOL unsupported OSes should be retired and replaced with modern supported version, but we're talking about reality now which is what the modern enterprise is, and which is far far from the perfect world.
What's blowing my mind about this entire thread is the "rewrite application to support RHEL9" thing I keep seeing. What the fuck applications are y'all running that are so tightly bound to the OS that they can't handle library and/or kernel updates?
Most of the time I've run into this its COTS software and the customer refuses to pay for the cost of the updated version or the company that wrote the original COTS application is long since out of business.
That's what I'm thinking too but then remember my first corporate job where the application depended on an exact subversion of Java 8, no earlier and no later. This was in 2021. Knowing that company I'd bet they're still rocking the same setup.
It is more like 'involuntarily end up riding the risks of using unsupported old software'. RHEL 7 and RHEL 5 are in the right order.
RHEL sells an unrealistic expectation that you don't need to worry about the OS for another 10 years, so the enterprise gets designed around it and becomes unable to handle an OS upgrade, ever.
Involuntarily? An org choosing to use an EOL OS to keep running an application is a business choice that accepts the risk of compromise/lack of support of an EOL OS. Any org in this situation has 3 choices:
There's nothing involuntary here.
This is the involuntary choice. If you cannot choose from the first three, you end up implicitly choosing the fourth.
Your #4 is the same as my #3. Play out your #4 and it ends up as my #3:
Security or Compliance teams raise the concern with continuing to run the EOL OS, they demand the App team power down the offending servers or upgrade. App team escalates to leadership advocating for the upgrade and they ask for the funding. Leadership asks for a business case justifying the large spend requiring the ROI numbers. App team mostly shrugs because the ROI are intangibles of security or support-ability. Leadership sees no immediate monetary benefit being realized in the next 2 quarters from a costly upgrade and instead chooses to accept the risk. They send an exception order to Security or Compliance teams that this EOL OS should continue running as is and the App team shouldn't be bothered anymore.
...and we end up with my #3.