I wonder if this consortium will end up defining "enterprise" Linux in the same way that POSIX forcibly seized the standards for UNIX from the control of AT&T and Sun.
It's enterprise in that you pay for it, but their support sucks. We had lots of open tickets they never solved. Total waste of money. Instead of fixing the problems they went back and forth with us asking for more log files until they just closed out the ticket because of lack of activity. It was their lack of activity.
At least Canonical/Ubuntu enterprise support stumbles into a solution and helps out.
I wonder what it means for SuSE Enterprise Linux in the long run.
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.
SuSE uses btrfs for the root filesystem, and although this can be quite dangerous if it fills up, it does allow much greater flexibility in rolling back the OS to a working state.
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.
I can guarantee you that SuSE will only ever support btrfs with their own kernel. There are a ton of fixes backported in theirs. At which point you are running SLES anyway.
I reckon most people complaining about RHEL:
- never really needed to use an enterprise OS, they could have just used any other *nix.
- don't understand that what Red Hat is doing is perfectly in line with not only Open Source but also Free Software
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.
This confuses me. I feel like we have a good thing going here between Fedora, CentOS, and RHEL. If they succeed and kill RHEL profitability are we really better off?
But that's the thing, there is no good thing going. CentOS used to be a community rebuild of RHEL, and you could then use that if you didn't want support from Red Hat. But that is no longer the case since Red Hat killed that. CentOS is now more like a beta version of RHEL and not a binary compatible build. At the same time, patches are made for RHEL that are kept secret and not published for CentOS.
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.
That's not true. CentOS Stream is literally the testing ground for RHEL patches. So CentOS gets patches much earlier now than it ever did as a community project.
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.
In a world where redhat is still an independent company, this would be horrible. In a world where they’re owned by IBM who is just barely better at “extracting maximum licensing value” than Broadcom and qualcom this isn’t just a good thing, it’s a necessary thing.
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.
it's 3000 repositories - one per package- all containing just a spec file and some patches. How is this remotely maintainable? Is this also how redhat upstream works? (I'm coming from nixpkgs where everything is in one mono-repo; which is great for cross-cutting concerns)
How do you make cross-operating system changes? Or are they just planning to ship Redhat verbatim and never make their own stuff?
In general I'd say nixpkgs is more of an outlier, though the nature of nix makes it a bit different to other package ecosystems.
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.
RHEL for each package has both a source-git and dist-git. The dist-git is used to build the package and for the src-git it can be a link to a tag to the upstream + some patches in the dist-git. Check the spec file. These look like copies of dist-gits.
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.
Readit News
https://en.m.wikipedia.org/wiki/Unix_wars
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.
At least Canonical/Ubuntu enterprise support stumbles into a solution and helps out.
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.
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.
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.
Strong disagree. I benefit greatly from Fedora and CentOS Stream.
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.
[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
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...
That is their stated mission.
Fedora has had 39 versions so far, it’s alive and kicking, so my guess is it’s maintainable enough.
https://openela.org/news/hello_world/