[HN Gopher] OpenELA releases redhat source code on github
___________________________________________________________________
OpenELA releases redhat source code on github
Author : nolist_policy
Score : 52 points
Date : 2023-11-04 18:16 UTC (4 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| chasil wrote:
| 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.
|
| https://en.m.wikipedia.org/wiki/Unix_wars
| mbakke wrote:
| The only "enterprise" feature of RHEL is Red Hat support.
|
| There is nothing to standardise. If anything we need _more_
| commercially backed distributions to tear down the monoculture.
| chasil wrote:
| Rhel does things to their distribution that customers do not
| want. This is well-known.
|
| 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.
| nolist_policy wrote:
| Redhat doesn't ship btrfs because they don't have any
| engineers working on it and thus can't provide support for
| it. Anything that ships in RHEL is comes with a strong
| support guarantee that they just couldn't hold up for
| btrfs.
|
| The SAS controllers may be a similar thing, maybe they
| don't have the hardware anymore to regression test against.
| chasil wrote:
| Amazing how well btrfs works in Fedora.
|
| The first thing to do with a rhel install to restore
| complete functionality is to remove the stock kernel.
|
| With extreme prejudice.
| FireBeyond wrote:
| What support "guarantees" does Fedora come with?
|
| 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.
| spandextwins wrote:
| 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.
| chasil wrote:
| Oracle's UEKR4 stopped updating Intel microcode for several
| months (in the middle of the spectre/meltdown hysteria).
| After a community forum post, they demanded an open SR so I
| had the pleasure of explaining all of this again. Even with
| a support contract, sometimes they are amazingly obtuse.
|
| We dumped support. We are paying enough for the database as
| it is.
| bastard_op wrote:
| This is likely just defining a baseline to build on or off of.
| Ideally off.
| amelius wrote:
| I'm an avid Linux user, but never heard of OpenELA before.
| Shadowmist wrote:
| It's less than 3 months old.
|
| https://openela.org/news/hello_world/
| klooney wrote:
| It's really only relevant if you have Big Business Problems and
| also don't want to pay Red Hat to solve them.
| fffrantz wrote:
| 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.
| chasil wrote:
| 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.
| nolist_policy wrote:
| 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.
| chasil wrote:
| Oracle's UEK also has btrfs support, and I use it. It is
| designed to be installed over rhel.
|
| 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.
| arianvanp wrote:
| 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?
| WesolyKubeczek wrote:
| At least in Fedora it's exactly like that: many repos, one per
| source package. Guess CentOS/RHEL are doing it in the same
| fashion.
|
| Fedora has had 39 versions so far, it's alive and kicking, so
| my guess is it's maintainable enough.
| nolist_policy wrote:
| I'd say the majority of distributions work this way. At least
| Debian[1], Fedora/CentOS/RHEL[2], SUSE[3], Arch[4], ...
|
| [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
| eraser215 wrote:
| "Or are they just planning to ship Redhat verbatim and never
| make their own stuff?"
|
| That is their stated mission.
| spandextwins wrote:
| Anybody can do that with open source as long as they make the
| source code available. That shouldn't surprise anyone. Source
| code is free and open.
| wmf wrote:
| Did you miss the discussion about RHEL source code being
| kind of hidden?
| spandextwins wrote:
| It's not "kind of hidden"
|
| 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.
| tempay wrote:
| 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.
| rwmj wrote:
| That's how things were distributed by CentOS.
| csdreamer7 wrote:
| 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.
| nani8ot wrote:
| > 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...
| spandextwins wrote:
| Great! Redhat and IBM can kiss my a*
| 2OEH8eoCRo0 wrote:
| But you want their sources. Which is it?
| spandextwins wrote:
| It's open source. That's the deal.
| 2OEH8eoCRo0 wrote:
| 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?
| spandextwins wrote:
| Yes, because everyone else figured it out except Red Hat (IBM)
| oneplane wrote:
| 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.
| tw04 wrote:
| 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.
___________________________________________________________________
(page generated 2023-11-04 23:01 UTC)