Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Red Hat cutting back RHEL source availability

lwn.net

Post reply on HN
Print view View original

311–320 of 339 posts

Re: Red Hat cutting back RHEL source availability

#311

Post by geerlingguy »

prmoustache wrote: post #279
g8oz wrote: post #214

Earlier quoted context omitted.

And those conditions are exactly what the OP meant by a licensing game.

There is notting in Jeff Geerling's project list[1] that warrant hundred's of rhel machines and containers at any given time. Containers are mostly ephemerals when used for build and test purpose. [1] https://www.jeffgeerling.com/projects

The fact that I have to spend more than 5 seconds considering how to integrate my Red Hat Subscription into my test builds (for dozens of projects) means I won't do it.

That's why I stuck with Rocky Linux instead of just dropping all RHEL support entirely.

And there are _a lot_ of test runs where I have more than 20-30 test containers running simultaneously with Rocky Linux 8 and 9.

Do I have to write new software that limits my test infrastructure to only run 16 tests at a time or something idiotic like that? Do I have to even wonder about that using Debian, Arch, heck even Amazon Linux? No.

Re: Red Hat cutting back RHEL source availability

#312

Post by jzb »

tristan957 wrote: post #229
jzb wrote: post #170

Earlier quoted context omitted.

Fedora is sponsored by Red Hat and many of its developers are employed by Red Hat. Much of the work in Fedora is done by Red Hat. Red Hat did not fire the FPL. They laid off the Fedora Program Manager, which is a different role entirely. I would still say that was a lousy decision, but the FPL is a very different role that goes back a very long time and AFAIK remains filled by Matthew Miller. I've seen the two roles…

How many is many? Thanks for the correction on the title.

A few years ago the figure was "several hundred" but the exact number is fluid because some people (like Matthew) are paid to work on Fedora full time, while others work on Fedora as part of their job but not their whole job.

It's also further confused by the fact that some Red Hatters contribute to Fedora but not as part of their day job.

I think it'd be fair to say more than 60% of the work that goes into Fedora's official releases is paid for by Red Hat. Maybe more. If you factor in spins and such, it might be less than 60%.

Re: Red Hat cutting back RHEL source availability

#314

Post by jacooper »

bonzini wrote: post #251
jacooper wrote: post #231

Earlier quoted context omitted.

Did you try their support before coming to such opinions?

1) Canonical does not have enough testers. As a developer I have seen what kind of bugs are reported on Ubuntu, and some of them denote a serious lack of QA. There are packages in Ubuntu that are almost certainly shipped untested. 2) Canonical does not have enough developers, unless they found a magic recipe by which their relatively few employees know how to fix issues in all these packages while not contributing up…

Honestly I never use PPAs on Ubuntu, because Ubuntu universe has everything I ever need, and now its supported by Ubuntu PRO.

Re: Red Hat cutting back RHEL source availability

#315

Post by jp10558 »

jzb wrote: post #195
Phrodo_00 wrote: post #162

Earlier quoted context omitted.

And I'm not sure I'd agree with their analysis, but they're clearly free to make the decision. If larger companies can run CentOS in production, they also can run Debian or any other distro without a support contract. They could even use a competing loss leader distro like OpenSuse Leap.

Yes, they could. But they (often) don't. The certification / training ecosystem that exists around RHEL has a lot value, even if a lot of folks like to handwave it away. The engineering that goes into RHEL and the very predictable lifecycle has a lot of value, too. I'm not going to say that Debian or SUSE aren't equally good, engineering-wise, but it seems like a lot of large companies have chosen RHEL clones over De…

It used to be for standardization, but I've seen more commercial tools provide Debian / Ubuntu support than Red Hat lately, since the late 2010s. I also think the amount of changes and the issues with licensing here mean that more people might up and convert to Debian than before. But IDK. I also hear that more ML work is done on Debian, and yes - with the containers becoming big - less need to run any particular linux, so I could see swapping out the underlying Linux.

And from a company perspective, Red Hat has already done a big swap out from satallite to Foreman / Puppet to really pushing Ansible. Similarly, they've stopped doing oVirt in favor of cloud style OpenStack, nee OpenShift. Which is great if you're building your own cloud fabric, but not really the VMWare / HyperV competitor oVirt was which is something lots of mid size orgs need. ProxMox still seems to be going.

And for people who aren't paying for support - I imagine they have skilled in house teams that can certainly figure out Debian if they've been orchestrating CENTOS and now Alma say.

Re: Red Hat cutting back RHEL source availability

#316

Post by prmoustache »

geerlingguy wrote: post #311
prmoustache wrote: post #279

Earlier quoted context omitted.

There is notting in Jeff Geerling's project list[1] that warrant hundred's of rhel machines and containers at any given time. Containers are mostly ephemerals when used for build and test purpose. [1] https://www.jeffgeerling.com/projects

The fact that I have to spend more than 5 seconds considering how to integrate my Red Hat Subscription into my test builds (for dozens of projects) means I won't do it. That's why I stuck with Rocky Linux instead of just dropping all RHEL support entirely. And there are _a lot_ of test runs where I have more than 20-30 test containers running simultaneously with Rocky Linux 8 and 9. Do I have to write new software th…

> The fact that I have to spend more than 5 seconds considering how to integrate my Red Hat Subscription into my test builds

So basically you are saying the author of an ansible book do not care spending a couple of minutes understanding a simple process to automatise it.

Sounds like great advertising for your books really.

Re: Red Hat cutting back RHEL source availability

#317

Post by schoen »

pabs3 wrote: post #301
palata wrote: post #264

Earlier quoted context omitted.

I was wrong indeed, thanks for the precision :-). So: Permissive licenses are free in the sense that they allow making free software (but they also allow making non-free software). GPLv3 enforces the complete derived work to be free. LGPLv3 says that the particular library should stay free. GPLv2, LGPLv2 and MPLv2 say that the source code (either of the whole derived work or just the library) should stay free, but ti…

Please note that "Tivoisation" isn't what Tivo actually did and both the GPLv2 and GPLv3 ban "Tivoisation" but allow what Tivo actually did. "Tivoisation" as it is popularly known refers to blocking the running of modified GPL code, while what Tivo actually did was block running their proprietary software (their UI etc) on top of modified GPL code (here Linux). Both GPL versions block the former while allowing the la…

That's interesting, I remember thinking that the original notion of Tivoization did apply to what Tivo did (including what you describe).

I wonder if this is a point of disagreement between FSF and SFC -- I know they now have several disagreements.

In a similar time frame, I criticized attestation features in trusted computing because they would allow (in fact one of their main purposes was to allow) network services to allow only certain software configurations to interact with them. And I thought I was talking about a similar concept!

Thanks for sharing those links.

Re: Red Hat cutting back RHEL source availability

#318

Post by progmetaldev »

awill wrote: post #212
progmetaldev wrote: post #210

Earlier quoted context omitted.

Rocky does offer support, but your comment about Oracle still stands. I believe Rocky works with Red Hat.

Rocky can offer support on helping you install it. But they can't offer real support. They can't fix bugs or do any real work on RHEL beyond requesting that Red Hat accept a fix. If Red Hat declines, Rocky can't even ship their own fix.

Doesn't Rocky offer their own repositories, where if they had an upstream fix that was important enough, they could just include it in their own repositories?

Re: Red Hat cutting back RHEL source availability

#319

Post by sliken »

jzb wrote: post #198
NegativeK wrote: post #185

Earlier quoted context omitted.

Rocky and Alma are doing exactly what CentOS pre-Stream did for _six_ years. Now they're frustrated that their decision to kill the CentOS idea didn't stick? Red Hat might have the legal right to gate their product, but it seems really slimy to build RHEL on the work of who knows how many people that publish it for free and then to put road blocks around their derivative. I don't really like reductionist blaming, but…

"it seems really slimy to build RHEL on the work of who knows how many people that publish it for free and then to put road blocks around their derivative" I'm always curious that people get angry at Red Hat profiting on the work of others, but few people get angry at the companies that use a RHEL clone to run their business and pay nothing and contribute nothing. Red Hat is still releasing source code. The only thin…

> Red Hat is still releasing source code. The only thing that it's not doing is making it super-convenient to rebuild exactly its product.

Releasing only to their customers and only if not redistributed. If you held redhat to the same standard for the open source they redistribute they couldn't exist.

Re: Red Hat cutting back RHEL source availability

#320

Post by worthless-trash »

sketch242 wrote: post #286
worthless-trash wrote: post #269

Earlier quoted context omitted.

Removed it midstream or between releases ?

RH generally only removes features in major releases. The exception is when they introduce features as a technology preview. Those are subject to potential removal before the EOL of that major release, though they rarely do.

That was what I had thought. I'm confused with the original statement being a problem as both vendor and the os both need to support the hardware. If there is a problem with the firmware who will RHEL go to keep its agreements ?
Post reply on HN