The reason why upgrades between Enterprise Linux versions were never supported was due to the drastic differences between them. Before Red Hat became consistent in their release timing, you have to imagine how many fedora versions happened in between major releases, on top of the changes that occur during that EL release.
A good example is RHEL 7 is roughly Fedora 19, RHEL 8 is Fedora 28. RHEL 9 is Fedora 34. You have to ask yourself if you were a Fedora user at RHEL 8’s release, would you try to do an in place upgrade from 19 to 28? You’d likely say no. The same thing applies between 28 and 34 (yes it’s fewer releases, but the same thing applies, you’re jumping 3 years of releases with drastic changes such as glibc and rpm).
While leapp indeed exists and can help with upgrades, it’s not one size fits all. Your mileage may vary.
I understand the point about the sizeable differences in versions. There is also the question of whether or not you should perform an upgrade on a system. Sometimes a clean install is just the best thing to do. But I think the option to upgrade is significant. Even if it’s only used for “basic and simple” service systems.
None of that is relevant to the thread. With the RedHat response posted above. I am worried that even if the community finds a way around the current situation, RH has made it clear that they intend to kill all clones and if this doesn’t do it, they will try again with another tactic.
I am asking to make hard fork which means to completely fork the RHEL along with it’s repository
so that you will not required to revisit again & again and the create own packages so that the community benefit from it @jlehtone
@kp786 Forking doesn’t solve anything since you are no longer in sync with RHEL. The whole idea behind the clones like Alma, Oracle, Rocky, etc was to be directly compatible with RHEL (the same as what CentOS used to be before Stream). Once you fork and go a different way you are no longer the same anymore.
Forking is only good if you want to become your own distro, which is a far lot more work and effort obviously.
I totally agree with this. It is the whole difficulty. You want to be identical, bug for bug compatible with upstream distribution. So, you need to compile their sources (and remove copyrights and logo to replace with those of the clone). So you need to have access to these sources… Where will you pick them ?
I would ask whether anyone is tracking how Oracle is responding/will respond, since they offer a RHEL compatible OS. Going for compatibility with them could be feasible perhaps.
I saw it back to 16 later too but after last week’s announcement I find the timing too much of a coincidence to be a bug, I’m getting more of the feeling they did change it but then they changed their mind and changed it back.
Thank you so much for saying this. I am not a coder so I wouldn’t even TRY to contribute code to Red Hat or Rocky or Fedora or Arch. I am a hobbyist and a tinkerer, and I have to say that both Mike McGrath’s pull-quote dig at hobbyists and Magnus Glantz’s rip against freeloaders has left me feeling so small. (Glantz never used the word freeloaders, but he did cite “making money off others hard work”, which is the very definition of freeloader.) However, I am an advocate, I have donated to projects I believe in, and I try to help people I know who are struggling with Linux find the right fit for them. I used to think there was value in those minor contributions, but to hear Mike and Magnus go on about it, I’m nothing but a leech. Your comment helps alleviate that feeling. So again, thank you.
Ok, lot’s of emotions on stealing RockyLinux, big money IBM etc. etc. All which is very understandable. One of the nice features of Linux/Open Source is the huge amount of choices we can make. You don´t like Linux distro X, you can go for another one. You like Windows but you don’t like Microsoft, well, there’s not too much to choose…
Don’t get me wrong, I do like RockyLinux as I like AlmaLinux as I like Red Hat Enterprise Linux as I like Debian and so on. But let’s ask a reasonable question: “What did RockLinux add to the, so to say, Enterprise Linux eco system?”. OK, it is a more or less perfect clone but what more? Did RockyLinux add new stuff to the EL ecosystem? A new or different kernel, alternatives for Red Hat products like Satellite, Ansible Tower/AAP, maybe a new or different installer, use LibreSSL instead of OpenSSL or some other cool Open Source product to RockyLinux which is not there in RHEL or EPEL? Lot’s of choices I would say.
Whether or not you like Ubuntu, they did created something different. Taking the source code from Debian, Ubuntu added new value and a complete new Linux distro. Ubuntu/Canonical does not only take the Open Source Code, they also add new elements back. That’s nice and that’s how Open Source imho should work: take and give back.
So, did Red Hat/IBM really create this Source code problem only by themselve? Or maybe was the idea of “just” creating a clone also causing this problem…? I would say: go for it RockyLinux! Create your special taste of Enterprise Linux and add new features, software etc.
We provide live images of Workstation (gnome), KDE, XFCE, MATE, and now Cinnamon for 9
raspberry pi support by way of a custom kernel and images done by SIG/AltArch
We built our own build system for 9 and are working on version 2 of it, it’s open source
We built our own tool sets, it’s open source.
Those are just some examples. We also have devs who work with red hat folks on EPEL/Fedora Project related work and maintenance, which ultimately benefits the entire community. We’ve also reported several bugs to red hat’s bugzilla.
If what we’re doing doesn’t add value, then I’m not sure what does.
I’m disappointed that The Register seem to be on Red Hat’s side.
I always thought the main products of Red Hat were training, certification and support. You want to build something mission critical that you need someone to be able to step in and fix, you know you can find those people, either directly at Red Hat or Certified.
But they’re losing that race to Ubuntu, OpenSUSE and Oracle. Shutting out the clones is a gift to their biggest competitors, as users of clones may actually consider the switch to Red Hat in the future but now they won’t even start on that track.
I hate how Red Hat has a rules-for-thee-but-not-for-me attitude. Red Hat despite all it’s contributions to open source still would not exist if Red Hat had not used someone else’s code. The GPL states that derivatives must publish the source under GPL . Paywalling source code limits and violates GPL.
Another method that we will leverage is pay-per-use public cloud instances. With this, anyone can spin up RHEL images in the cloud and thus obtain the source code for all packages and errata. This is the easiest for us to scale as we can do all of this through CI pipelines, spinning up cloud images to obtain the sources via DNF, and post to our Git repositories automatically.
These methods are possible because of the power of GPL. No one can prevent redistribution of GPL software. To reiterate, both of these methods enable us to legitimately obtain RHEL binaries and SRPMs without compromising our commitment to open source software or agreeing to TOS or EULA limitations that impede our rights. Our legal advisors have reassured us that we have the right to obtain the source to any binaries we receive, ensuring that we can continue advancing Rocky Linux in line with our original intentions.
