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

301–310 of 339 posts

Re: Red Hat cutting back RHEL source availability

#301

Post by pabs3 »

palata wrote: post #264
schoen wrote: post #261

Earlier quoted context omitted.

Right, so you might have, for example, FreeBSD, which as distributed by the FreeBSD developers is free software , but which can also potentially be used in a proprietary downstream product, which is not free software . The FreeBSD developers did not deny users any of the four freedoms. They just allowed other people to potentially do so. This Venn diagram is FSF's view of the taxonomy: https://www.gnu.org/philosophy/…

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 latter. At least according to Software Freedom Conservancy.

https://sfconservancy.org/blog/2021/mar/25/install-gplv2/ https://sfconservancy.org/blog/2021/jul/23/tivoization-and-t... https://events19.linuxfoundation.org/wp-content/uploads/2017...

Re: Red Hat cutting back RHEL source availability

#302

Post by pabs3 »

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…

Lots of companies do contribute to Debian and this has been happening for a long time. To start with Canonical employs people to contribute back. For a while HPE was donating large amounts of server hardware. Several companies (early HP, ARM etc) contributed lots of work on new ports like arm64, hppa, etc. Almost the entirety of the LTS effort is funded by companies. The current status is summarised on on the wiki:

https://wiki.debian.org/LTS/Funding https://wiki.debian.org/ExternalEntities

Re: Red Hat cutting back RHEL source availability

#303

Post by Beermotor »

bonzini wrote: post #288
genmud wrote: post #256

Earlier quoted context omitted.

RHELs model is to support such ancient versions of software that they don't have to support many pieces of software, because the features most people would rely on aren't in 3, 5 or 10 year old software. If it wasn't effectively required (until recently) for most US government use, I would imagine they would have a substantially smaller customer base.

This is not entirely true; some packages have been removed from RHEL7 to 8 to 9, because the interpretation of "if we ship it we support it" has become stricter. RHEL9 is as new or sometimes newer than Debian 11 (bullseye).

RedHat also backports fixes, security patches, and (occasionally) features to existing RPMs without incrementing the minor version.

For example fuzzywhatsit-3.0 in RHEL could be functionally equivalent to 3.5 in another distro.

Re: Red Hat cutting back RHEL source availability

#304

Post by Beermotor »

cmiles74 wrote: post #108
LordShredda wrote: post #40

NASA recently made a deal with Rocky Linux, which is literally just RHEL with branding replaced afaik. Probably pissed IBM real bad since they're usually the government's darling for tech contracts

I believe NASA does use RHEL, I remember a story last year where they were moving some systems from SUSE to RHEL. My guess is that IBM was so difficult to deal with that they decided to move away from RHEL wherever they could. Perhaps getting the actual support they purchased was too much of a challenge. If IBM is pissed, they should take a good hard look in the mirror before they malign other distributions. https://…

NASA's IT used to be split into the field centers and a central core IT organization. The field centers managed their own stuff, but anything agency-wide was handled by the core IT organization. Central IT also usually won out when there was a conflict.

When NASA combined their disparate field center mail systems into one (OneNASA and later NOMAD) massive mail system in 2006-2008 they deployed everything that wasn't the squishy Exchange underbelly on SuSE Enterprise 10.

The field centers were very invested in RHEL. Mostly for scientific software and Oracle.

JPL has traditionally been separate from the rest of NASA and works with CalTech for their infrastructure.

Re: Red Hat cutting back RHEL source availability

#305

Post by ilyt »

scj wrote: post #224
ilyt wrote: post #203

Earlier quoted context omitted.

Yes, not making it ridiculously easy for corporate to make money off someone's else work without giving anything back is a huge difference. I don't really get why people are for non-copyleft licenses. LGPL is fine license.

https://lwn.net/2001/0301/a/rms-ov-license.php3

So it changed to BSD yet still lost. Your point ?

Re: Red Hat cutting back RHEL source availability

#306

Post by matheusmoreira »

pietro72ohboy wrote: post #74
phpisthebest wrote: post #62

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…

Yeah. Open source is a wealth transfer from developers to corporations. I've reached the conclusion that anything other than AGPLv3 means we're working against our own interests. Giving up the leverage provided by the GPL benefits only corporations.

Re: Red Hat cutting back RHEL source availability

#307

Post by lost_tourist »

RedShift1 wrote: post #272
lost_tourist wrote: post #113

Earlier quoted context omitted.

debian stable

I've used Debian before but always had a disdain for how their packaging works. Dpkg seems completely over engineered (why are there more package states than just installed/not installed?) and the way they package things is just annoying. At random times an install or upgrade asks you questions in a wizard style and they always mess around with the configuration files and directories to the point where I don't even k…

Okay, don't use it, I use it and never had an issue, but I only use it on a few servers and my desktop for the past couple of decades

Re: Red Hat cutting back RHEL source availability

#308

Post by birdyrooster »

2OEH8eoCRo0 wrote: post #34

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…

It has ocfs2 working out of the box which is a pretty good clustered file system.

Re: Red Hat cutting back RHEL source availability

#309

Post by birdyrooster »

chasil wrote: post #43
2OEH8eoCRo0 wrote: post #34

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…

It has a few add-ons. The "Unbreakable Enterprise Kernel" includes full btrfs, extensive device support (that is removed from the stock kernel), is tuned for the eponymous database, and is always more current. There are several scenarios where it is very attractive. Oracle bought K-Splice several years ago, which was the first rebootless patch solution for Linux. It's only available with a premium license; Kernelcare…

Don't forget OCFS2 as well! I am surprised that HN didn't know OEL wasn't just s/redhat/oracle/

Re: Red Hat cutting back RHEL source availability

#310

Post by pamhalpert »

Phrodo_00 wrote: post #112
2OEH8eoCRo0 wrote: post #34

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…

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

There's nothing stopping them from using CentOS still? The latest rolling releases are so close to RHEL you'd never notice. Use an older more reliable version locked release that works to your needs and update periodically. these problems are solved for small shops quite easily.
Post reply on HN