Hacker News new | ask | show | jobs
by jillesvangurp 1091 days ago
The solution here is forking and accepting that IBM just doesn't want to share. The whole value of the Red Hat eco system is lots of people using the down stream variants. Actual direct licensees of Red Hat are not where most of the action is.

The value creation is actually distributed across the ecosystem. People encounter issues, report them, and fixes are distributed. If you break that cycle and get IBM out of the loop, the process just continues elsewhere. The vast majority of that ecosystem does not pay IBM a single dollar and probably never will.

IBM is a company that is in slow decline, so the remaining Red Hat employees are facing an extended period of that company just squeezing harder and harder until nothing remains. It's death by a thousand cuts. But the bottom line is that a lot of people doing the hard work of committing actual code on behalf of the ecosystem that are currently employed there will be facing endless rounds layoffs, reorganizations, restructurings, etc. If there isn't an employee exodus happening there already, that might soon start to happen. The only question is where those people will end up.

A well funded foundation maintaining the fork of the distribution formerly known as Red Hat could be a nice destination for such people. Between Amazon, Oracle, and the countless users of Rocky, Alma, Centos, Fedora, etc. there should be plenty of brain power, motivation, and money to make that happen. They need a stable foundation. They don't need IBM to be part of that.

Don't play IBM's game on their terms. Just cut them loose. They get to do whatever they want downstream, not upstream. And they get to contribute all their fixes under GPL. That's not optional. This foundation would be free to use these fixes as they need to. Comparability with IBM's downstream distribution should not be a goal for this foundation. And if IBM wants to pretend they can do it all by themselves, they are more than welcome to try.

My prediction is that if the big supporters of this ecosystem join forces and do this, IBM will grumble a bit and then ultimately join the foundation because their alternative will be just writing off the investment they made in Red Hat and watch from the sidelines how most of the ecosystem stops depending on IBM's Red Hat.

2 comments

> IBM will grumble a bit and then ultimately join the foundation because their alternative will be just writing off the investment they made in Red Hat and watch from the sidelines how most of the ecosystem stops depending on IBM's Red Hat.

You could have said that if they switched to using CentOS Stream, and that would even have been my favorite outcome as a Red Hat employee.

However, Rocky Linux is neither a sibling nor a fork of RHEL. It's a debranded clone that by definition cannot even have a single bugfix that isn't in RHEL. For Oracle it's okay because it's peanut money in order to annoy Red Hat, so they can afford this; for Amazon or Facebook it's no good and that's why they forked upstream at the Fedora or CentOS Stream level.

As long as Rocky Linux stays a RHEL rebuild built by a third party like the CentOS of 2010 (except backed by corporate money rather than a guy in Nebraska), Red Hat is already putting millions into "the foundation". That's what they pay for the thousand people that develop Rocky Linux, ahem RHEL. Without them, there can be no Rocky Linux at all. So, as long as Rocky's money making side keeps undermining Red Hat's money making side, game theory predicts no other outcome than death for both RHEL and Rocky.

_EDIT_: if you downvote, I'd be very glad to learn where I'm wrong

And without the GPL and all the code that came with it, there would be no RH. Rocky is making use of the same legal protection that RH is. Yes, RH spends more on development but they are doing so using the tools and existing codebase given to them, for free, by others.

Rocky is doing something no different than what RH is doing, and if this is problematic for RH's hopes of sucking in a few $B, that's more a problem with RH's business model than it is Rocky's. They have made $Bs selling support for free software, some large part of which they didn't author, and now they want to squeeze the entire ecosystem for more.

I have zero sympathy for RH and fully support Rocky's approach here. This is a problem of RH's own creation and trying to deflect the blame onto Rocky is absurd.

> Rocky is doing something no different than what RH is doing

Count the contributors to Rocky and RHEL. Then tell me how they can be "doing the same thing".

Taking open source code, some large part of which wasn’t authored by them, and bundling it for others? Same thing, with one notable difference: one of them is trying to extort everyone into paying for code they themselves got, in part or in whole, for free.

RH didn’t write all of linux, but they’re trying to put a price on it like they have.

That makes a lot of sense.

Ideally, Rocky's money making side could come to some sort of agreement to share revenue with RHEL's money making side, so that in turn RHEL's software making side doesn't mind sharing code with Rocky's (lack of) software making side.

I think the abundant corporate sponsoring of Rocky Linux proves that AWS, Google, Facebook etc. are happy to pay for access to RedHat's work. They just do not agree to the way that the licensing scales (both costs and hassle).

> It's a debranded clone that by definition cannot even have a single bugfix that isn't in RHEL.

Not necessarily. They could easily have an optional repository for "bugfixes that aren't in RHEL". Those who want bug-for-bug compatibility with RHEL for some reason could simply not enable that repository.

That repo would undercut the entire purpose of Rocky, which in their wiki state

> Rocky Linux is a community enterprise Operating System designed to be 100% bug-for-bug compatible with Enterprise Linux. [1]

[1] https://wiki.rockylinux.org/

At that point, why wouldn't the user just be using centos stream?
Lets see how it goes, Red-Hat is a major contributor to anything GNOME, X Windows/Wayland, GCC, Linux kernel.

clang dropped to third place after Apple and Google decided to refocus on other languages, it is yet to recover from it.

FOSS is great as mantra, it turns out many people can only spend so many hours, if putting food on the table matters as existencial question.

>clang dropped to third place after Apple and Google decided to refocus on other languages, it is yet to recover from it.

what do you mean by this?

https://en.cppreference.com/w/cpp/compiler_support/20

Apple nowadays mainly focus on Swift, and C++ support only needs to be good enough for Metal Shading Language (a C++14 dialect), IO and DriverKit needs, and compiling LLVM (currently requires ISO C++17).

Likewise, on Google's side, those that went on to work on Carbon are no longer contributing to clang.

All the other compiler vendors that have clang forks, seem more interested into LLVM improvements than ISO C++ compliance, thus now clang lags behind GCC and VC++ in ISO C++ capabilities.