Question for the RL team here.
Would providing the last major version in maintenance support ie. 7 be a possibility and then say 8 when it got to 8.10 ? or are those updates not published by RH ?
It’s just that reliability/stability is a very large part of choosing a RHEL clone but if you can only ever get the last minor version warts ‘n’ all it kinda leaves you a bit exposed.
What’s your point ? RH provide 5 yrs of maintenance updates on the last major release. I’m asking if RL can do the same.
CIQ offer support for Rocky so I guess if you pay for it then maybe is possible.
I found this which seems to say when 9 comes out you can stay on RL 8.10 with updates for the next 5 years.
Looks like the thing to do for LTS/Stabililty was to stay on CentOS 7 until 2024 then move to RL 8.10 and stay there for the next 5 yrs.
It seems you have the notion that minor version updates introduce instability. Alternatively try to see a minor version update just like a bunch of updates, like a service pack in the windows world, i.e. there is just Rocky 8 (until 2029).
please have a look at
some notes:
the term LTS as it exists in Ubuntu has no direct counterpart in RHEL
RHEL 8 is supported from 2019 until 2029, and I expect Rocky 8 to be supported until 2029 too (and I could call that a long time support)
The sources for ELS (2029 to 2031) are not publicly available and therefore clones like Rocky can not rebuild that.
The last minor update broke my DE. True, a service pack might screw you over too…
Apparently RHEL 8.5 is only supported for 6 months so if you want updates for the next 6 months and you have an app developed to work in KDE, then you’re a bit f****d. … unless you want to run an 8.5 vm on an 8.6 host I suppose…
I’ll work around any issues over the next 2 yrs and then stop on 8.10, maybe use CentOS 7 for some stuff in the meantime. Problem solved… unless 3rd party stuff moving out of sync causes problems.
So, to sum up (correct me if I’m wrong), LTS - as in a stable version that only includes fixes for an extended period - is achievable by only taking on the last minor version of any major version and then some time after it has settled. You can then expect up to 5 yrs of relative* stability and these 5yr periods overlap so you have a yr+ to move between major versions.
WIth RL the first such period starts with 8.10 in 2024/5 and in the meatime the “LTS” option is CentOS 7 though there’s no overlap there.
*relative to the first 5yrs of a major version’s release cycle.
An entire RHEL release is LTS. It doesn’t matter which way you slice it, it is an LTS. Once the 5 year mark has it, there’s no more minor releases because it is now in maintenance only mode. You’re misleading yourself if you feel the need to wait until the very last minor release to be “LTS”.
In regards to your example of your DE being broken on updates, if your DE is from EPEL, you must come to expect that these kind of breakages can occur. For example. We didn’t release a KDE live image (again) because sddm and the kernel in 8.6 had issues with one another (as far as I’ve understood it). For XFCE, we were able to move back to lightdm.
In fact, more are likely to “break” during the last 5 years than the first 5 years. Not because the installation would change, but because hardware and expectations do. You want to run fancy app X that uses library Y? “Sorry, we are in maintenance mode and the version of Y is what it is, but your X depends on features of the next version of Y.”
The change that broke KDE in 8.6 was a bungled feature addition to RHEL. Features aren’t added in a stable LTS and in RHEL they don’t happen in the last 5 yrs - just fixes. Feature additions are typically going to be less reliable initially than bug/security fixes.
Horses for courses - I’m interested in stability primarily. I don’t need every new shiny thing and while v7 falls short of what I’m happy with v8.5 was plenty good enough for me for a while to come. Hell ! I’d still be using Windows 7 if they were publishing security updates for another 10 yrs.
Worryingly I came across this on my travels:
“CentOS Stream,” Miller said, “is continuous development of RHEL…the intention is for this stream to be as stable as the released RHEL product…”
… flying piglets free to good homes if anyone interested…
The thing is, KDE isn’t bundled by default in RHEL or Rocky. Had you not been using it, then nothing would have broke.
Then I guess don’t use third party repositories that can affect stability. Stick to the repositories that are provided by default.
This is just really continued from the other thread about broken desktops on 8.6. So you will just disagree with the statements I’ve made anyway. But hey ho 
It has turned into that and as you’re repeating the same argument here, yes I’ll disagree again.
The v7 is in maintenance phase. My point was exactly that: v7 falls short on your expectations, because it is 3-8 years old technology by now. You have to wait two years before v8 is “stable” by your definition. I five years from now v9 will reach that stage.
Those are the RHEL no charge options: you don’t want v7 as it is already “old”, nor v8 as it still gets features, and v9 is so new that most teething problems are yet to be reported.
One can set up RHEL 9 server today and it will serve “perfectly solid” for a decade. No bells, no whistles, just as we expect Enterprise Linux to be.
Ubuntu LTS has support for five years. Is it really true that they get no features after initial release?
Not the case - v7 falls short for me in the same way Windows 3 fell short compared to say xp - not because it was old or old compared to xp but because it hadn’t reached a certain level of maturity - once that level of maturity was reached everybody happily skipped vista and even windows 7 for a long time as xp was good enough for most people for most things. I’m pretty sure 8.10 will be good enough and by 2029 I probably won’t want/need to give it up for RL 9, though obviously I will be forced to.
Ubuntu LTS apparently goes through a shorter features phase, followed by a beta phase followed by a maintenance phase during which, in rare cases, stuff might be back ported but tbh I only ever used Ubuntu briefly and sporadically. The last time I attempted moving to linux was a few yrs back on CentOS 7, had issues with virtualisation and never had the time to follow through… and wasn’t as motivated as I am now.
I expect the 8.6 bug’ll be fixed in 8.7 though as a broken API on an included feature it should be fixed sooner if possible. I don’t really expect to see any major issues after that. So I’m good or can manage on 8 and once it gets to 8.10 I’m ok (as you can be) for 5 yrs. All Good !
What are you disagreeing with? The arguments presented by @iwalker make perfect sense: If you use third-party repositories, you cannot expect the same stability.
I’ll lay this out one last time in the clearest way I possibly can:
RHEL WS is a GENERAL PURPOSE OPERATING SYSTEM - it is NOT an off-the-shelf single/specified/restricted purpose offering. It is de facto no different from macOS or MS Windows in that respect and there are no banners screaming otherwise.
As such, any software that complies with the documentation and standards should work on it.
If said sw does not work because the OS fails to adhere to the documentation and standards that it has embraced then the fault lies with the OS.
There is nothing wrong with what is in the 3rd party repos - that works as it is supposed to.
So, no the arguments do not make perfect sense - If a program adheres to the docs and standards then it is perfectly reasonable to expect it to work and completely unreasonable to excuse the failure as “oh, we don’t support that particular program …ermm… or anything else that relies on us not screwing up some general purpose functionality”.
I won’t be repeating myself again. If this doesn’t explain it to you, nothing will.
RHEL WS is a GENERAL PURPOSE OPERATING SYSTEM
And Rocky Linux is not RHEL, so what RHEL is and isn’t in terms of their support offerings is irrelevant to the point.
Rocky Linux does not “support” anything. This is obvious from Licensing | Rocky Linux and it works exactly the same as pretty much any other open source project out there. If you want to be strict, support is not offered on any piece of software in any repo, including the ones that come enabled by default.
Your phrasing that “we” (whoever that is) do not support something shows that you do not understand the point in the above paragraph. There is, in technical terms, no support, period.
What I suppose people have tried to explain to you is that the chance for something breaking is increased when using software from third party repositories. That’s a statement of fact that I agree with and it’s not much affected by your opinions on what combination of software should and should not work. You are free to think whatever you like, it doesn’t change the expectations that you are entitled to against Rocky Linux as a project, which the license linked above states clearly.
Besides, while Rocky is not RHEL, lets not forget that Red Hat has paying customers that happily accept RHEL WS 8 already before it reaches maintenance phase. Big customers. Customers, whose money did accept RHEL WS 7 too (and 6, 5 before it), and deemed them mature and stable.
Presumably – trade secrets are not in the open, but Red Hat does report significant revenue.
