Openela releases Red Hat source code on GitHub
github.com
github.com
There is nothing to standardise. If anything we need more commercially backed distributions to tear down the monoculture.
Two shining examples are the removal of older SAS controllers in the kernels of newer versions, and the fate of btrfs.
OpenELA could easily grow in influence to a point where rhel will lose customers if they try it again.
It will be interesting if such decisions push effective control of rhel to OpenELA. It could easily happen.
The SAS controllers may be a similar thing, maybe they don't have the hardware anymore to regression test against.
The first thing to do with a rhel install to restore complete functionality is to remove the stock kernel.
With extreme prejudice.
The two are not contradictory. Fedora's btrfs functionality can absolutely be exceptional - nothing about that means that Red Hat has engineers working on or able to effectively support it.
Disclaimer: I am an ex-Red Hat employee, though I was nowhere near RHEL.
Conversely, there is no value in the limitations imposed upon rhel. OpenELA gives us a voice in letting them go.
incidentally, i never had a chance to figure out what the big deal was with the centos stream change, because i was already forced to switch to debian because btrfs was removed from the centos kernel.
Funny!
At least Canonical/Ubuntu enterprise support stumbles into a solution and helps out.
We dumped support. We are paying enough for the database as it is.
It's been a while, but 5 years ago I worked for a company with a Red Hat support contract, and we found them incredibly helpful. Everyone we spoke to had deep Linux knowledge, and their team solved issues and gave us real worldn advice much faster and better than any vendor. I'd be sad if that's no longer true.
The flip side of the coin that I have seen is that some customers will rely heavily on redhat to do basic admin work that a system admin would/should be doing. Effectively taking a job with legal liability for work provided.
The sosreport Tarball makes an active effort not to gather private information. If you believe it does, please let support know as they are interested in improving this.
Are they going to migrate SLE to be bug-for-bug RHEL compatible but keep their own tools on top? What about OpenSUSE? I'm an avid SLE/OpenSUSE user and it was chosen specifically because it's not an RHEL clone.
It would be interesting if this capability returned to OpenELA. It could be done with rhel7 (and clones).
There are likely some users who consider this a must-have.
A further collaboration on an OpenELA btrfs-enabled kernel incorporating both SuSE and Oracle requirements will easily supplant stock rhel.
For one thing, the UEK returns support for a large array of hardware that has been removed from stock. This list is very large.
If you hate Red Hat or IBM, just don't use it and move on, use a community driven OS which is a lot easier and is probably a lot more flexible, you are not going to convince any enterprise to drop their RHEL subscriptions.
As many have pointed out: the support is RHEL, not the code, the code without Red Hat support and contracts is useless.
And all of this is extra bad since those masses of CentOS installs exist because people don't really want to deal with Red Hat, but some other vendor just happened to not test their application on another distro, and corporate policies then don't allow you to run it on a non-binary-compatible system.
If there would be different packages, i.e. just an OCI image or a single statically linked program, or perhaps a vended virtual machine image, none of this OS vendor BS would exist. You would be able to run wherever you want to run, on whatever you want to run it. And some people and companies would still choose Red Hat, but anyone who has used anything else would probably not.
Strong disagree. I benefit greatly from Fedora and CentOS Stream.
I relied heavily on CentOS but at least I'm being honest, I relied on CentOS because it was a free version of RHEL. People got so mad when RHEL took away their free OS that they make up all sorts of excuses.
Fact is Red Hat have been contributing back to open source for 25+ years. As far as companies goes, it's one of the best we have in the open source ecosystem.
So this is why we can't have nice things. When someone actually get successful in open source we try to destroy them.
It definitely is true, in our RHEL subscriptions we get patches that do not exist in CentOS. We also see those differences in fully patched systems where the patch versions run different binary code.
> I relied heavily on CentOS [..]
> Fact is [..]
> So this is why [..]
All those other arguments are not very relevant, they bought CentOS and then broke community trust multiple times to the point where we now have multiple re-incarnations of the CentOS concept and RHEL (or IBM) thought they could prevent that by hiding the sources used for current RHEL builds from the public by default.
Money-wise it's also not relevant because there are only two reasons you pay for support:
1. You actually need support (we never did in the past 15 years)
2. Corporate nonsense (this applies to some of our vendors)
Red Hat is fully leaning into #2 and it's just not having any real value if you don't also fit in #1.
Citation needed. Source: I work at Red Hat and made the policy that stuff needs to go to CentOS Stream first. The only exceptions should be embargoed or critical/important CVEs, those go to customers before CentOS Stream.
If you find any code, features, or bug sizes in RHEL that aren't in stream, it's a bug, let us know and we will fix it.
Maybe the issue wasn't highlighted as much in the past where the rebuild compatibility meant that packages could go out without also having the source (in CentOS).
They will go full throttle boiling the frog if left to their own devices and every company who has done business with them knows it.
Fedora has had 39 versions so far, it’s alive and kicking, so my guess is it’s maintainable enough.
[1] https://salsa.debian.org/public
[2] https://gitlab.com/redhat/centos-stream/rpms
[3] https://build.opensuse.org/project/show/openSUSE:Factory
[4] https://gitlab.archlinux.org/archlinux/packaging/packages
That is their stated mission.
Redhat (and IBM) are choosing who to release their source code to, and if they don't like you they won't give it to you. Richard Stallman (rms) ain't dead yet.
I've contributed to both models and you just end up with a lot of tooling and bots. One of the benifits of the repo-per-package approach is that you can have different maintainers for different package which is a bit tricker with a monorepo.
The kernel is unique because RHEL forks the kernel and backports things while keeping a stable interface for testing and people to build upon (you won't see the removal of some drivers 6 years into the RHEL life cycle because upstream removed them).
Strange, I do not see a kernel or linux package.
The kernel source is pulled in by the respective .nix to build the kernel. Eg. the following defines which commit of zen-kernel should be used as source.
https://github.com/NixOS/nixpkgs/blob/master/pkgs/os-specifi...
We are talking about a RHEL clone. Specifically the lack of dist-git pkg for the most heavily changed package that differentiates RHEL from an upstream distro. The forked Linux kernel source code.
This file does not point to that EL fork. Just the upstream with the zen patches... I guess? Not looking at it too much past that 6.6 value in the first few lines.