This question is seeking answers usable as front-door advise to newly-arrived refugees after a rocky road here. My only reason getting here is I noticed MariaDB publishes binaries for both Rocky 8 and 9 (equivalents of CentOS), so I am driven by end-use mostly, not hacking the next best OS.
I even went to CentOS in the first place because I noticed MariaDB were active there after MS booted end-users and their providers from their EoL Win32, MariaDB included.
My big question: I come from CentOS 8 Stream. Never dabbled with CentOS 9 nor with CentOS Linux, so my migration issues are purely CentOS Stream. So this is a question I should have investigated there but it is now in the past. So the question is:
Between Rocky 8 and Rocky 9, which platform is better suited for only enduser-upstream add-ons? In the same fashion I follow MariaDB, what are the percentages of upstream should I expect to find in ‘stable’ version between Rocky 8 versus Rocky 9?
My typical list of 3rd Party applications includes LibreOffice, Gimp, Shotcut, NetBeans, IntelliJ, Firefox; and I certainly want xserver support for remote xhost DISPLAY (Gnome on CentOS has been a challenge with xsever).
If there is a place where I can browse the upstream support level differences; that is a good answer too.
Thanks. I haven’t installed Rocky any where yet pending know which to use.
I can answer at least some of your questions. Essentially, if it is/was available on CentOS, it is likely available on Rocky Linux (at least version 8.6). On my 8.6 laptop installation, the following packages from your list are available to install:
- NetBeans via separate procedure here
- Shotcut via snap install
- IntelliJ via separate procedure here
While it is certainly technically possible to do xserver support for a remote xhost DISPLAY, It has been forever ago since I’ve done it. I’m hoping that someone else will weigh in on that.
Seems I might have to guesswork answer myself. If it were a decision for quickly available up-streams I should go the Rocky 8 Linux route. The ecosystem strategy at Rocky seems to be to source-fork RHEL, which means it’s straight RHEL re-compile first and then upstream merge after (some blood, sweat & tears). This would have been an ideal place had I been a CentOS Linux refugee; but CentOS Stream(*) has totally disappeared from the old-style accessible universe, and it might take a while to re-emerge in that no-man’s land between RHEL and Rocky Linux, perhaps as a Rocky Stream yet to be.
So I shall install Rocky Linux 8 and close this thread with a prognosis after finding out for myself in a day or two.
(*) There’s a thing at CentOS now referred to as CentOS Appstream that erstwhile CentOS Stream(ers) were left the impression of safe continuation as post CentOS Linux EoL; but it is not. This one is dnf/yum gate-kept by an ‘entitlements server’ reminscent of AS/400-AIX licensing days of olde. No matter how many times one re-registers it just does not recognize legitimate cheapskates from pre-EoL CentOS Linux days of yore.
This certainly is good news. I blind opted to go the Rocky Linux 8 route. The prognosis is turning better than during my blind jump into Rocky 8.
They are derived from RHEL 8 and RHEL 9, respectively. Lets just say el8 and el9.
el8 appeared in 2019, will have feature updates to 2024 and maintenance to 2029.
el9 appeared in 2022, will have feature updates to 2027 and maintenance to 2032.
In typical RHEL fashion neither has wide variety of desktop toys in them.
For some of those “holes” the EPEL provides EPEL-8 and EPEL-9.
The EPEL-8 has had three more years to build content than EPEL-9.
That is most likely true for many third-party repositories.
Hence, at this moment el8 has more to choose from than el9, but not forever.
I think this allays my fears over being orphaned at Rocky Linux, as I see EPEL may be turned on once Rocky is up and running.
The day or two has actually turned into a whole two months and some. The hold up was absence of a direct migration path given the broken CentOS Stream dnf / yum that migrate2Rocky relies on. I finally got a small / old box to install from scratch and it shall be x85_64 Rocky 8.7 (already :).
For the curious I’ve managed to download minimal iso (2.2GB) over approx 3hr. The complete 8.8 GB iso failed overnight and started off requiring 1 day + 8hrs. I’m on optical Fibre bradband in South Africa so I think the bottleneck is somewhere in between. Might post a copy for locals once I’m up and running.
If this is going to be an issue with CentOS stream migrations then I might look into some sort of solution for migrate2rocky. Can you give details about what happened when you tried to run migrate2rocky from CentOS stream 8?
I do not think it’s a problem to warrant mainstream resources. It’s a perineal problem for any low budget users. The migrare2rocky invokes dnf which works as always for mainstream CentOS Linux. CentOS 8 at time I first installed provided the standard Linux image distro or a light weight on demand Stream variant that came minimum size without RHEL for example. When monetizing CentOS ‘Stream’ changed to ‘Appstream’ which required subscription and dnf stopped working for old 'Stream’ers. I think it’s an edge case.
Typically dnf complains that the installed CentOS does not have entitlement for Appstream installs or updates etc. I personally have’nt tried migtate2rocky knowing that DNS shall fail. My last ‘problem’ was also a low budget hw issue that caused failures on old fashioned grubb style installs. CentOS seem to be trying to reach maroons like myself but I suspect their paywalls will block out many still.
That sounds like miscommunication. There is no paywall nor subscription, AFAIK, and ‘appstream’ is one of the base repos of RHEL 8 and Rocky 8 (and was of the CentOS Linux 8).
Totally unrelated to CentOS Stream 8 (which has ‘appstream’ repo due to relation to RHEL 8).
You have a system with (rather vague) “CentOS Stream” that existed before the discontinuation of CentOS Linux was announced (Dec 2020)? Seriously old now?
Migrations from CentOS stream is supported by migrate2rocky. If it’s not working for some reason we need to fix it. That’s not an edge case.