Live data from Hacker News

Red Hat cutting back RHEL source availability

lwn.net

161–170 of 339 posts

Re: Red Hat cutting back RHEL source availability

#161

The comments there are insightful and actually make me think this is the right move: > Since the earliest days of Linux or MySQL, there were companies set up to profit from others’ contributions. Most recently in Linux, for example, Rocky Linux and Alma Linux both promise “bug for bug compatibility” with Red Hat Enterprise Linux (RHEL), while contributing nothing toward Red Hat’s success. Indeed, the natural conclusi…

>The comments there are insightful and actually make me think this is the right move

They are not. Maybe this is how the YC/VC crowd sees everything. Dollar went in, two dollars come out. Two points:

1) RHEL is not an island. It uses (and contributes) upstream.

2) They undercut the spirit, if not the letter, of GPL by forbidding customers from releasing the sources. Don't want derivatives ? Don't use copyleft free software. Can't have your cake and use it too.

Re: Red Hat cutting back RHEL source availability

#162
post #155

Earlier quoted context omitted.

> Most recently in Linux, for example, Rocky Linux and Alma Linux both promise “bug for bug compatibility” with Red Hat Enterprise Linux (RHEL), while contributing nothing toward Red Hat’s success. CentOS was huge towards equipping smaller IT departments, startups and student on the RHEL ways, allowing them to jump on "real RH" when they got bigger. Alma Linux is the same. Rocky Linux does sell support, but even then…

CentOS was also huge towards allowing a lot of larger companies to just run CentOS in production instead of RHEL and avoid paying anything at all. However you may feel about Red Hat's actions, I'd trust that folks at Red Hat have done enough legwork to figure out that "CentOS as a loss leader for RHEL" wasn't working out the way people like to imagine it would. (Note: I am a former Red Hat employee, but I do not have…

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.

Re: Red Hat cutting back RHEL source availability

#163

The comments there are insightful and actually make me think this is the right move: > Since the earliest days of Linux or MySQL, there were companies set up to profit from others’ contributions. Most recently in Linux, for example, Rocky Linux and Alma Linux both promise “bug for bug compatibility” with Red Hat Enterprise Linux (RHEL), while contributing nothing toward Red Hat’s success. Indeed, the natural conclusi…

There's a huge difference between Rocky/Alma, and Oracle. Oracle actually tries to steal RHEL business. They offer support, which I think is ludicrous when they don't even build the product.

Alma/Rocky aren't to my knowledge offering any support (and if they plan to, they shouldn't). Are customers cross-shopping RHEL with Alma? You either want support, and buy RHEL, or you don't, and you use something else (Alma/Rocky, or Debian/Ubuntu etc..)

Re: Red Hat cutting back RHEL source availability

#164
post #83

Earlier quoted context omitted.

> In the past, customers have been able to redistribute the RHEL repos freely. I assume that will remain the case as long as CentOS Stream is open source. There's a duality here. Yes, by the nature of the distribution, GPL, and licensing general, Red Hat cannot stop or prevent a customer from distributing RHEL packages and software to third parties. However, Red Hat reserves the right to terminate any existing subscr…

> Red Hat cannot stop or prevent a customer from distributing RHEL packages and software to third parties. However, Red Hat reserves the right to terminate any existing subscriptions a customer may have as a result of their package distributing. IANAL, but not so sure about that. From GPLv3: > You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example…

Linux is GPLv2, not Linux GPLv3. V2 does have a similar line in it:

> You may not impose any further restrictions on the recipients' exercise of the rights granted herein.

But I expect we'd have to see litigation to determine how broadly that can be interpreted.

Is applying a consequence as a result of an action the same as restricting that action?

Re: Red Hat cutting back RHEL source availability

#165

Earlier quoted context omitted.

This is only true it RHEL was self contained OS Project with no Upstream sources itself... That is not the case, RHEL is not possible with out the wider ecosystem, and to say Rocky Linux is a "dirtbag" for repacking RHEL, would be like saying RedHat is a "dirtbag" for packaging any number of free software projects they consume into their product. It completely antithetical the free software movement for which Linux i…

> However it is perfectly on brand of the "Open Source" corporatist movement that seems to be supplanting free software This has been happening on HN too. The vilification of GPL and AGPL as ”not free in the truest sense of the word”, the usage of RMS and his personal image to label the free software movement outdated/fanatical/toxic is a testament to how corporate rebranding efforts have succeeded in replacing free…

> , the usage of RMS and his personal image to label the free software movement outdated/fanatical/toxic

What if i love and use the AGPL, but also won't involve myself with the FSF because I think they are runining the movement and also definitely want no direct association with RMS.

I think RMS is an active harm to the cause of Free Software.

Re: Red Hat cutting back RHEL source availability

#166
post #83

Earlier quoted context omitted.

> In the past, customers have been able to redistribute the RHEL repos freely. I assume that will remain the case as long as CentOS Stream is open source. There's a duality here. Yes, by the nature of the distribution, GPL, and licensing general, Red Hat cannot stop or prevent a customer from distributing RHEL packages and software to third parties. However, Red Hat reserves the right to terminate any existing subscr…

> Red Hat cannot stop or prevent a customer from distributing RHEL packages and software to third parties. However, Red Hat reserves the right to terminate any existing subscriptions a customer may have as a result of their package distributing. IANAL, but not so sure about that. From GPLv3: > You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example…

Yeah this is really pushing a gray area. Looking at it one way Red Hat is not obligated to do business with anyone, and if they stop doing business with a customer that customer still has all the rights granted to them by licenses of software they have already received, so in that sense Red Hat hasn't restricted the customer's rights in that software.

However, on the other hand refusing to do business with someone in retaliation for exercising the rights granted by the licenses smells a lot like a restriction.

Re: Red Hat cutting back RHEL source availability

#167

Earlier quoted context omitted.

> Red Hat cannot stop or prevent a customer from distributing RHEL packages and software to third parties. However, Red Hat reserves the right to terminate any existing subscriptions a customer may have as a result of their package distributing. IANAL, but not so sure about that. From GPLv3: > You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example…

Linux is GPLv2, not Linux GPLv3. V2 does have a similar line in it: > You may not impose any further restrictions on the recipients' exercise of the rights granted herein. But I expect we'd have to see litigation to determine how broadly that can be interpreted. Is applying a consequence as a result of an action the same as restricting that action?

> Is applying a consequence as a result of an action the same as restricting that action?

I mean, I don't disagree this needs to be tested in court if it hasn't, but what alternative ways of restriction do you think this is referring to? Do you expect it to only apply to the distributor physically restraining the licensee when attempting to redistribute it? Even the examples given in the license such as imposing fees are applying a consequence.

Re: Red Hat cutting back RHEL source availability

#168
post #124

Earlier quoted context omitted.

"Large" wasn't a very big standard at the time. Linux's multiprocessor support was ...lackluster at best... prior to IBM contributing all the Sequent (Dynix) derived multiprocessing stuff. Hyperthreading/Multicore started to get "normal" even in consumer systems only a couple years later, so that injection was pretty critical. Likewise, a lot of Linux's development inertia and cultural acceptance came from being a ch…

>Linux's multiprocessor support was ...lackluster at best... prior to IBM contributing all the Sequent (Dynix) derived multiprocessing stuff. Hyperthreading/Multicore started to get "normal" even in consumer systems only a couple years later, so that injection was pretty critical. It was certainly needed over time but capabilities from things like RCU out of Sequent weren't that important in the 2000 timeframe. And a…

I was mixing up where the big multiprocessor changes that went into the 2.5 series in that 2000-2005 era came from.

I was thinking of the the basic kernel preemption stuff and sched_setaffinity syscall + userspace plumbing like taskset that is _extremely_ consequential on little multicore/SMT machines, but the prominent name on a lot of that was Robert Love and he was at MontaVista at the time.

The Dynix parts that arrived via IBM were, as you say, mostly NUMA and RCU stuff based on Paul McKenney's work, which also went in in the same major overhaul during the 2.5 series but weren't quite so immediately consequential to smaller systems.

I hadn't heard that anecdote, but that is a neat tale of IBM using their gravitas at the time to legitimize Linux.

Re: Red Hat cutting back RHEL source availability

#169
post #21
post #17

Earlier quoted context omitted.

Many startups can only dream of being as long and influential as IBM is. Also note that IBM contributions to Linux kernel in 2000, was one of the reasons it actually took off.

I'd argue that IBM's contributions in that timeframe were more about about validating it from a large business perspective than about technical contributions (that tended to focus on large system performance which wasn't actually that important for Linux taking off).

Yes, certifying DB2 for Linux (back in 1998, https://slashdot.org/index2.pl?fhfilter=db2+linux, scroll to bottom) was an absolutely earth-shattering event that announced that Linux had arrived. I think that event (and of course Oracle and Sybase a few months prior) really sounded the death knell for big-iron UNIX.

But in 1999, IBM ported Linux to run on System 390 (https://slashdot.org/index2.pl?fhfilter=mainframe+linux) and I remember there was a story that some IBM scientist booted more than 30,000 Linux instances on a mainframe on his lunch break. This research led to the big SUSE partnership, as well as open-sourcing other enterprise-y software like JFS and putting a big devteam to make the kernel ready for real SMP (Linux didn't have efficient+mature SMP even into the early aughts, although a few companies had built some massive SMP boxes.)

Re: Red Hat cutting back RHEL source availability

#170

I've been using Red Hat and Fedora since the early RH4 days when the video driver only supported monochrome for my GPU. I'm now going to start switching to something not controlled by a corporation. Yes, I'm not happy about it but it's necessary. The days of being naive about Linux are over. I still consider Fedora one of the best distros out there (bleeding edge and polished as much as possible) and I prefer to use…

Fedora is pretty independent of Red Hat, especially since Red Hat fired the Fedora project lead.

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 conflated here and there so I figured it was worth correcting here so it doesn't continue to spread.

Post reply on HN