Live data from Hacker News

Openela releases Red Hat source code on GitHub

github.com

31–40 of 57 posts

Re: Openela releases Red Hat source code on GitHub

#31
post #22

Earlier quoted context omitted.

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.

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.

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.

Re: Openela releases Red Hat source code on GitHub

#32
post #24
post #22

Earlier quoted context omitted.

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.

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.

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.

Re: Openela releases Red Hat source code on GitHub

#33
post #24

Earlier quoted context omitted.

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.

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.

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.

Re: Openela releases Red Hat source code on GitHub

#34

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?

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…

> 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...

Re: Openela releases Red Hat source code on GitHub

#35
post #33

Earlier quoted context omitted.

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.

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.

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.

Re: Openela releases Red Hat source code on GitHub

#36
post #24

Earlier quoted context omitted.

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.

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.

rather they don't have any customers demanding it. if they had, hiring engineers to support that should not be the problem.

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.

Re: Openela releases Red Hat source code on GitHub

#37
post #22

Earlier quoted context omitted.

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.

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.

Really?

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.

Re: Openela releases Red Hat source code on GitHub

#38
post #33

Earlier quoted context omitted.

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.

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.

[deleted]

Re: Openela releases Red Hat source code on GitHub

#39
post #33

Earlier quoted context omitted.

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.

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.

If there is no value in the technology within it, then why grasp it? Let it go, and cut the Fedora/rhel tie.

Conversely, there is no value in the limitations imposed upon rhel. OpenELA gives us a voice in letting them go.

Re: Openela releases Red Hat source code on GitHub

#40

Earlier quoted context omitted.

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.

Really? 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.

I remember thinking why don't they just do a WebEx with us to see what's going on. Nope, never. They just wanted us to ship logs to them and try random crap until they closed the ticket. Total waste of time and money.
Post reply on HN