Hacker News new | past | comments | ask | show | jobs | submit login
Red Hat Is Not Linux (2000) (archive.org)
143 points by lproven on July 4, 2023 | hide | past | favorite | 184 comments



The anger and resentment towards Red Hat in the open source world had always made me sad. Red Hat made linux mainstream. Before Red Hat, big expensive commercial software (engineering tools, databases, simulation software, network services, all the big enterprisey things) all ran on and was officially supported on UNIX (and maybe Windows NT): HP-UX, Solaris, Irix. People were dabbling with Linux, crazy start ups were inventing crazy new things with it, but it wasn't until Red Hat basically mimicked the commercial UNIX model of stable releases, official safety and security certifications, support contracts, etc., that Linux went mainstream and UNIX (and NT) withered to almost nothing. Linux and all other open source code has flourished because of this!

Red Hat has always been open source. They have followed the letter of the license and still do. Not only that, they make big money! And they have employed and still do employ many top tier open source developers who contribute open source code to a variety of projects. The money they make makes all of open source better!

Their business model probably isn't for you, non-enterprisey do-it-yourself HN reader. But that's ok. There's absolutely no reason for you to be bitter or resentful about that because you have many other choices of Linux distribution available to you. All of which has been improved in some way by Red Hat.

I actually wish more open source projects followed the Red Hat model. Corporations making big money using open source would actually be paying the developers of those open source projects! That would be amazing!


[OP here]

> Red Hat made linux mainstream.

1. In the English-speaking world, mainly meaning North America.

For instance, SUSE is just as old, and brought Linux to the mainstream in Mitteleuropa. Not just in "DACH" (the German speaking world: Deutschland, Austria, Confœderatio Helvetica), but also for instance it was the first Czech-language distro. I worked for SUSE in Prague for 4 years, and it is still big in that part of the world.

Conectiva brought it to LatAm. TurboLinux to Japan. Etc., etc.

2. FSVO "mainstream" -- Red Hat Linux (note, not RHEL) was not really very useful as a desktop OS. I ran it, I used it, but trying to install something as complex as a desktop using raw RPM with no dependency management was nightmarish. That's where Mandrake came from: Red Hat refused to bundle KDE because Qt wasn't 100% GPL, so Mandrake ported KDE to RHL and bundled them.

Caldera was even earlier, and OpenLinux 1.0 with KDE was the first desktop distro I tried that was polished enough to make my primary OS for a while.

RHL was mainly a server OS, and as such, not very mainstream for most people.


> RHL was mainly a server OS, and as such, not very mainstream for most people.

I think that's what gp is saying: in the "enterprise" space, Solaris and HP-UX and Irix were kings. RedHat moved into that space by providing businesses the same model of support, while ALSO having a desktop version/free version for people to learn on.

RedHat THINKS they're still doing that with Fedora/CentOS Stream, but everyone disagrees.


> RedHat moved into that space by providing businesses the same model of support

But it didn't, not back then. In the 1990s, and for most of the company's first decade in business, it offered a free distribution and made most of its money from selling merchandise. Which is to say, not very much money at all.

It's only around 2003 but its management hit upon the idea of having a premium enterprise distribution, and making the only way to obtain it being to buy commercial support for it. That was a stroke of genius, and over the last 20 years, it's made the company very rich indeed — in stark contrast to its first decade.

> while ALSO having a desktop version/free version for people to learn on.

Again, that split only came after about a decade in business. For its first 10 years or so, there was only the free version.

Also, more to the point, back when Solaris and HP UX were big, Red Hat was still very small and mainly in the business of selling T-shirts and mouse mats.

It's a bit of a generalisation, but to an extent, it was Microsoft Windows which put commercial UNIX out of business, followed by Apple macOS which showed that UNIX on the desktop could be as good or better than Windows.

Windows established a marketplace of COTS high-end x86 kit with decent graphics capabilities and capable storage subsystems. Apple successfully piggybacked on that to make desirable easy to use RISC UNIX workstations for consumers, using their own processors but otherwise pretty much off the shelf PC industry parts.

And those things put together are what created a marketplace in which Linux could thrive and compete effectively.

When Linux was first invented, a high end PC had a crappy VGA card on the ISA bus, and many of them didn't even have mice, sound or networking as standard. I was there. It was grim.


> It's only around 2003 but its management hit upon the idea of having a premium enterprise distribution, and making the only way to obtain it being to buy commercial support for it. That was a stroke of genius, and over the last 20 years, it's made the company very rich indeed — in stark contrast to its first decade.

Their enterprise support started around RH6, which was in 1999 and grew from there. It eventually morphed into RHEL because of the enterprise success, but didn't start with it.


Oh really? I didn't know that. OK, conceded.


Yes, Wintel was huge for desktops, but not for high powered engineering software like EDA tools, modeling, simulation, etc. (I think AutoCAD was the only Windows software that real engineers used).

MacOS wasn't UNIX based until the big MacOS X rewrite which was around 1999, if I remember right. It felt very much like it was a reaction to Linux, especially with them making a big deal about how it was an Official UNIX(TM), not so subtly reminding us that Linux was not.


OSX wasn't a rewrite of MacOS. It was a new chrome over top of NeXTStep, which was BSD on Mach (or Mach in BSD). It wasn't a reaction to anything, it was Steve Jobs bringing NeXT in to give Apple a real OS.

What really killed Unix on workstations was NT, and it killed it when the first sgi NT workstations shipped.

In the server space, Linux began to replace Solaris once you could run Oracle on Linux. That was the end of every other Unix.


> OSX wasn't a rewrite of MacOS. It was a new chrome over top of NeXTStep

In addition major new chrome (Cocoa, OS X Finder, etc.) Mac OS X originally included a version of the older Mac OS APIs (Carbon) as well as a Mac OS 9 virtual environment (Classic) for running older non-Carbon apps. It was really a chimera that included pretty complete Mac OS 9 ABI support as well as a Mac-flavored version of NeXTSTEP.

It's a bit of a shame that Apple keeps abandoning its backward compatibility layers (I hope Rosetta2 will be different) but I guess that's what emulators are for.


Both excellent points. I really should have highlighted this:

> What really killed Unix on workstations was NT, and it killed it when the first sgi NT workstations shipped.

'Cos it sure as anything wasn't Windows 9x that persuaded businesses that Windows was a legitimate OS.


~2003 was about when Amazon migrated their database servers off of HP-UX and onto relatively commodity Intel servers running Oracle/RHEL.

And RedHat had previously already displaced Digital Unix for all the webservers by the end of 2001.


1993... I bought a 486-dx2/66 with VESA Local Bus graphics, 1024x768 monitor with mouse and sound card. At first I ran OS/2 and later Yggdrasil Linux I think.


Same. (Well, 486sx33) OS/2 to Caldera, to NT4 and RedHat.


They also organized courses and certification which is super important in Enterprise


Good point, yes.


I don't think Red Hat thinks they are doing it with CentOS and Fedora.

They are doing that with the free developer licencing.


Redhat didn't move into that space originally though. They moved into the SCO space off of the goodwill of 'geeks'. Then Redhat leveraged that into the larger UNIX space. That is why the community of 'geeks' is disappointed in them and their current moves. They have forgotten where they come from.


I don't know, this kinda feels like RMS always complaining that we don't call it GNU/Linux. Like, yeah, I get it, you deserve credit for sure, but...really?


> Confœderatio Helvetica

That's Switzerland (or if you're particularly pedantic: the Swiss Confederation) for those not brushed up on their Latin and Latin graphemes.


A name chosen largely as it's not in any one of the four official languages of Switzerland: German, French, Italian, and Romansh. A political compromise.


Well, it’s clearly biased towards Italian and French ;)


I was explaining what DACH stood for.

https://en.wikipedia.org/wiki/Geographical_distribution_of_G...

TBH I didn't even consider that anyone might not know where Helvetia was, but you're right, I should have mentioned that.


Sorry, it just came off a bit pretentious. You could have just written "German-speaking world (e.g. Germany, Austria, Switzerland)"


It's a standard term:

https://ecommercegermany.com/blog/the-complete-guide-to-unde...

But a lot of people don't know it, and as the terms are in 3 languages, its meaning is not obvious.


The acronym was new to me and I found your introduction of it into the conversation interesting, and your brief explanation of it sufficient.

(And I didn't in the least find it pretentious)


Oh, that is great to hear! Thank you!

I only learned the term a few years ago, while working at SUSE, and it fits a need I wasn't aware I had.

"The German-speaking world" is awfully long and yet remains imprecise:

* Are we talking about countries where there are some German speaking people? No -- that's probably every country.

* Are we referring to countries where there's a resident German-speaking minority? No. The USA has the Amish who speak "Pennsylvania Dutch" (among other minorities there among whom old folks speak Germanic languages) and that isn't Dutch at all but a Low Germanic dialect -- or a family of them.

Then there are the Volga Germans: https://en.wikipedia.org/wiki/Volga_Germans -- hundreds of thousands of German speakers around the former USSR.

* Are we talking about countries where German is the majority language then, like Anglosphere in English? The Teutonosphere?

* Oh, but hang on, then shouldn't the term be in German?

* Ah, but hang on, I do know a little German, and German speakers love coining new words by ramming existing words together, so it's probably been invented a dozen times. The Deutchsprachigewelt or something.

* Uhoh... maybe there is such a word but non-German speakers don't know it because they don't understand it, or they can't say it?

* And anyway, whose German then? Hochdeutsch or Schweitscherduutsch or Bayerisch or Swabish?

So I looked, and there is, and it's short and easy, and it cuts through the difficulty of two of the countries having different forms of German and the third having a really weird form of German but anyway it's not the standard language it's just one of four...

It's in German and English and Latin! Cool!


If you’re providing links and explanations of DACH for my benefit, you don’t need to keep giving me links as I knew what DACH meant before reading any of your comments.


Nah, it's for the general record. ;-)

In another thread today, there are a lot of people upset and angry that they could not work out that a story about how an AI image generator can't create an image of a single banana, called the "AI lone banana problem" or something, did not say clearly that the problem was that an chatbot can't draw just one banana. And the story was really long at nearly 3000 words, which apparently is a 10-15 minute read and also apparently ain't nobody got time for that.

The HN commentariat does not always pick up on messages I would consider very obvious indeed... :-/


Czech is not german, at all.


SUSE definitely deserves credit here too! But also SUSE doesn't get hated on like Red Hat


Agreed (as someone in the English-speaking world whose first Linux distribution was SUSE) - though even SUSE uses rpm, as does TurboLinux, so in a very real way, they are standing on the shoulders of Red Hat.


Up to a point, yes. As I understand it, though, SUSE originally was bootstrapped from SLS, Soft Landing Linux, and it only gained rpm support later on.


Suse came from Slackware.


SLS provided the SL in "SLackware", I believe.


The Red Hat is now IBM. And IBM is the quintessential big evil corporation with a hundred years of dirty business practices, far beyond anything Microsoft or Apple has done.

Red Hat itself was mostly fine. I've competed against them and fought against their FUD. They're an enterprise software vendor no different from Oracle in this regard. But besides the sales and marketing knife fights necessitating unsavory tactics (everyone's does it), it was a mostly ethical decent business.

That said, as an old OS/2 fan and former IT executive that had to deal with large strategic outsourcing deals: IBM is not a trustworthy vendor, and plays old school dirty tactics in almost every large customer: from attempting to get people fired for questioning IBM, to near bribery. For this reason, I never want to do business with them or Red Hat unless I absolutely must.


> as an old OS/2 fan and former IT executive that had to deal with large strategic outsourcing deals: IBM is not a trustworthy vendor

Amen. IBM doesn't believe their customers are "developers" or "sysadmins"; they believe their customers are C-levels who will always come back. They miss the point that C-levels rotate out as previous devs and sysops rise up. That's how they lost the mainframe market, and the desktop market, and now the minicomputer market that they clawed back with RHEL. The cloud they already lost.


> IBM is not a trustworthy vendor, and plays old school dirty tactics in almost every large customer: from attempting to get people fired for questioning IBM, to near bribery.

Or straight up bribery. An IBM exec in Poland pleaded guilty to bribing an government official to get a contract in 2012.


"referral agent fees" or "lead generation"


https://gwern.net/complement

>the pattern of “commoditizing your complement”, an alternative to vertical integration, where companies seek to secure a chokepoint or quasi-monopoly in products composed of many necessary & sufficient layers by dominating one layer while fostering so much competition in another layer above or below its layer that no competing monopolist can emerge, prices are driven down to marginal costs elsewhere in the stack, total price drops & increases demand, and the majority of the consumer surplus of the final product can be diverted to the quasi-monopolist.

What red hat is doing is commodotizing their complement, it's nothing more than that. One big example is that I would rather be using an OpenRC init system, but because redhat throws their weight around I need to use a systemd-based distro at work, to work on embedded systems (can't use ~~chroots~~ systemd-nspawn unless the host is also running systemd).

By throwing all this shit out for free they're able to destroy any sort of organic competition that might arise. Honestly I wouldn't even be mad, except a big chunk of it enterprise-ey shit and introduce major security issues just from how they're architected.

There's good and bad, but the problem is they make it very hard to just take the good and leave the bad. They bundle things together, like the decision to make Gnome depend on systemd, or the way networkd can't really be seperated from systemd, or renaming gummiboot to systemd-boot.

They also don't do a good job of disclosing what open source projects they have de-facto control over, and you're likely to find a lot of redhat employees in key positions in projects you didn't realize had anything to do with redhat.


Imho it’s all just a purity test, coupled with so much of the tech community just loving drama. This is our equivalent to reality shows where there’s a celebrity train wreck.

I agree with you, Red Hat are a huge contributor to open source. Their business model lets them make money and then they use that money to contribute to projects in the wild. To me, it’s a win win.

I can understand why people would be upset with the changes. I don’t understand why they would be angry though.

The choice of down stream repackage distros has always been at RH’s convenience. This has always been clear since the day CentOS was a thing, and Rocky/Alma after it. Their product model depended on the whims of another product.


Ask yourself how many things RH has done for the community also directly contributed to their bottom line.

Now combine that with its new business leaders that promise explicitly to pare back efforts that don't help or even hurt the bottom line.

Would that make you happy with them? Sure, they aren't under an obligation to drive FOSS, but there is an obvious and notable change in direction here.


That’s pure speculation and conjecture though without any specifics.

What notable change has their been to their contributions has their been? Please point to some reduction or drop in quality.

Without a concrete talking point, the statement is so empty that I could say the same about any distro, for example Ubuntu or Suse which also have commercial components to their businesses


I'm just going based on their direct comments: https://www.redhat.com/en/blog/red-hats-commitment-open-sour...

"There was a time, not too long ago, that Red Hat found value in the work done by rebuilders like CentOS. We pushed our SRPMs out to git.centos.org in a neat package that made them easy to rebuild; we even de-branded it for them. More recently, we have determined that there isn’t value in having a downstream rebuilder."

These comments are explicitly about a focus on doing the things that directly drive revenue. Their actions correlate with their stated direction.

We can debate whether the direction is right or wrong for them (I'm explictly not making a judgment here), but the direction and intent are clear.


That’s conflating things. Red Hat still continue to contribute to open source projects.

Whether they are effectively maintaining components for another distro is besides the point.

That does not make their direction or intent clear with regards to open source contributions


I never said they stopped contributing to open source. But the emphasis on the bottom line is already having consequences.

Do you think they will keep advancing spice as much as before now that they've deprecated it in their products?

More wood into fewer arrows means just what it sounds like it means.


How do you think Redhat got in the door? People like me and my friends way back in the day staying late and porting our product over on our own time and convincing management to make it an offering. People like us who were our client's pet neckbeards convincing them it was ok to go with our Linux offering. No one buys Redhat without an application to run on top of it. That's how they cracked large market industries. Not on their own, but from good will from neckbeards who found it fun to spend their weeknights on a skunk works port on a frankenputer we hacked together (corporate was happy to stay with just offering SCO).

The Redhat that this last week has been on an anti-neckbeard crusade saying 'we aren't the distro for your type' to those of us who got them in the market is what is disappointing. It's like you help your friend become part of your larger friends group and then they ghost you when they don't need you anymore and are 'too cool' for you. So yeah, fuck off Redhat. They can do whatever they want, but they won't be getting any good will, and the petty anarchist in me will take advantage of any situations that come up to do ill upon them if it has a low personal cost.


I'm afraid you are missing my point completely. Because they found a way to make money off of open source, us neckbeards have been able to continue using open source for the rest of our careers, and it just keeps getting better and better! And we don't have to hide in the basement of the skunk works anymore! And we have literally hundreds of Linux distros to chose from now! It's totally fine if you don't like RHEL at all, it really isn't for you. But the money it makes off of the suits totally benefits us neckbeards, because open source is awesome like that!


Please consider rereading what you wrote. You seem to have a lot of anger which is unhealthy but also adds nothing to the conversation. I’m sure you’d appreciate that invective does nothing to improve the signal to noise.

Publicly stating you will “do ill upon” a multinational corporation sounds a lot like a threat, and we don’t do that here.


> Red Hat has always been open source. They have followed the letter of the license and still do.

It is very much an open question whether they comply with the GPL by imposing additional restrictions on a license which states that you may not add restrictions.


It has always been OK to restrict distribution of source to your customers.

From the GPL: "For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received."

The operative word being recipients.

Redhat may be the devil incarnate now that they apparently are a part of IBM... Though as far as this distribution change I don't see the problem.


That's not the problem. The problem is that if you are a customer who receives the source code and then gives it to somebody else - an action with the GPL explicitly allows and says you can't restrict - then Red Hat will terminate your contract, which sure looks like a restriction to me.


It's crappy and evil, but it's a restriction on their service/support contract, not on the GPL code.


I'm sure that's their claim, but I can also tell you that I wouldn't want to tell a judge that such retaliation wasn't intended to prevent (one might even say, limit) exercise of the GPL.


If they put in their support contract "sure you can distribute the code but you'll have to pay a $10_000 for each line of code you distribute" then is that adding restrictions to the GPL code? Why is that OK but losing a very expensive support contract not? Does it get better if it's a month to month support contract?

To me this seems like a pretty clear cut case of adding restrictions to GPL code and risking getting those licenses taken away. It will be interesting to see if they face any real repercussions though.


> If they put in their support contract "sure you can distribute the code but you'll have to pay a $10_000 for each line of code you distribute" then is that adding restrictions to the GPL code?

That would be a restriction, in your example, but that is not what Red Hat is doing.

> Why is that OK but losing a very expensive support contract not? Does it get better if it's a month to month support contract?

Because in your first example, they are applying a restriction to copies of the software you have already received. That would be against the GPL, but that is NOT what Red Hat is doing.

Red Hat, if they were to terminate their support contract with you, does not affect any of the free software you have already received. You are still free to do with it as you like because there are no restrictions. But, Red Hat might not give you any _more_ software, and they don't have to because the transaction covered by the GPL for the software they already distributed to you was completely fulfilled.

Personally, I am doggone tired of people continually misrepresenting this point. Red Hat is simply __not__ violating the GPL.


I think the SFC's take is the most interesting. This particular action is in no way a GPL violation. The health of RHEL repackagers directly indicates how at-risk Red Hat's customers are of the isolated GPL abuses that pre-IBM Red Hat has engaged in historically. Which makes

>Red Hat is simply __not__ violating the GPL.

a particularly interesting thought to unpack. Because while this event isn't a violation, the 'jury is out' on whether or not Red Hat's entire business model is compatible with the GPL in the first place. One thing that we do know is that Red Hat has displayed willingness to violate the GPL in the past.

https://sfconservancy.org/blog/2023/jun/23/rhel-gpl-analysis...


There's some subtlety between "$10_000 fine" and "have to spend $10_000 to change a bunch of infrastructure around" that's lost on me.


> And they have employed and still do employ many top tier open source developers who contribute open source code to a variety of projects. The money they make makes all of open source better!

I have to question that.

Nearly all of my worst experiences when using Linux have involved software that they or their developers have, to the best of my knowledge, been significantly involved with creating.

I'm thinking of software like systemd, PulseAudio, NetworkManager, GNOME 3, and Wayland, for example.

I've wasted far too much of my time dealing with unnecessary, silly, and inexcusable problems involving such software.

What makes it even worse is that despite me trying to avoid their ecosystem, their software has unfortunately still made it into other major distros, including Debian.


If PulseAudio, Wayland, etc are all some of the worst software then how does it keep ending up in distros like Debian? If there are better alternatives why would they willingly adopt it?


Part of the reason PulseAudio got a bad rap is because of bad audio drivers (and sometimes bad hardware), because they refused to work around those bugs at the "wrong" layer of the stack.

After a few painful years though, the bugs got fixed in the "right" places, and that's part of why Pipewire (also developed by Red Hat) was able to come along and replace it so quickly.

And thankfully Pipewire addresses a lot of the actually legitimate issues with PulseAudio


Lets not forget canonical shipped pulseaudio in Ubuntu before it was really ready. The devs got a lot of hate for something they didn't much control.


dont know much about linux audio -- what are the problmes?



I keep wondering whether it is even still true that RH drives those projects. Poettering left RH for MS a while back, AFAIK. Are NetworkManager, GNOME, and Wayland still heavily RH driven?


Ever consider if you have a problem with that many different projects, the common denominator is you?


I certainly considered that.

However, whenever I started searching for solutions to the various problems I was encountering, I pretty much always found numerous other bug reports, mailing list threads, blog posts, Stack Overflow questions, forum posts, and so on, from other people running into the same troubles, along with other problems that I thankfully hadn't been experiencing.

It was clear to me that I wasn't alone.


I think that things started to go downhill when RedHat decided to kill CentOS and invented the CentOS Stream; the killed that.

My guess is IBM and some RedHat people decided to be greedier than than they should and by shutting down access to the RH repositories somehow they think they can squeeze as many companies as possible to pay for Linux.

Terrible how good things are ruined by greed.


[OP here]

I disagree. I think the mistake was bringing CentOS in house: legitimising a free version of their own cash cow.

It is virtually Rule No. 1 of business: don't compete with yourself. If you are selling something expensive, don't later start to offer an unrestricted free version too.


AFAICT, that's why they "bought" CentOS: to embrace-extend-extinguish it. There was no mistake about it.


In hindsight, that does look plausible. However I'm not sure that the timeframe supports it. The company acquired the CentOS organisation in 2014, and it didn't kill off the free Linux distro until 2020. That's a pretty big gap.


And the decision to withdraw CentOS 8 was taken quite suddenly, part way through the advertised 10 year lifetime of EL8. And the free RHEL development licence offer wasn't ready to go the day of the announcement - there was a delay of some months.

I'm thinking a sudden change of view because of internal politics rather than an organic change as part of some master plan.


The decisions seem rushed, not borne out of consensus, and not well thought out


So...IBM, huh?


I think the existence of Scientific Linux was one of the things keeping RH honest until then.

In 2019 the Scientific Linux developers announced they would stop development and collaborate on CentOS instead.

At that point Red Hat had captured the RHEL-clone world, leaving them in a position to destroy it.


There's still Springdale / PUIAS, out there just trying to do their thing... not sure what route they'll take.

I remember trying out PUIAS for a short time back when CentOS was having a lot of community issues.


This exactly


I do not think that companies that were paying RedHat customers all of a sudden starting replacing RHEL with CentOS depriving it of revenue and that's why RedHat decided to end CentOS.

I personally used CentOS for systems that I knew had a long lifetime ahead of them and for their use a distribution that could be "supported" for a number of years was the way to go. But since upgrading from CentOS 7 to CentOS 8 was such a PITA, I started slowly migrating to Ubuntu LTS which makes version upgrades painless.


> I do not think that companies that were paying RedHat customers all of a sudden starting replacing RHEL with CentOS

I think they did. Place I worked had explicit direction to replace RHEL with CentOS to cut licensing costs. Most big companies would pay when they are force to pay and no free alternatives available that'd do the job. They won't pay just because it is nice thing to do.


Red Hat made a fateful choice when they acquired JBoss, against the express wishes of Oracle and Larry Ellison.

Oracle then forked the distribution, and their presence far outweighs CentOS.

For those who would argue against this assertion, run the command "wsl.exe -l -o" inside a Microsoft Windows command prompt.

You will not find CentOS there, and you will not find Red Hat, but the coverage of Oracle Linux is quite thorough.

Red Hat has a long history of antagonism of their partners and users, and they have paid dearly for it.


You don't need to have anger or resentment towards Red Hat to agree with the principle that Red Hat is not Linux, or want to encourage developers to not limit their "linux app" or hardware products to only support Red Hat.

Which is what this site and petition is about, at my first glance anyhow.


My resentment toward Red Hat is really about the impact they've had on other distributions. Red Hat has a very specific vision of how they want Linux to be, and are successful in convincing other distros of adopting it. It's a vision I personally hate, so in my view, Red Hat is ruining Linux for me.

So I resent them. It's the resentment of personal loss, not some grand philosophical stance.


If they are so Open Source, what is this BS that they are pulling out now that you cannot get the source code unless you are a paying customer, and if you are a paying customer you get terminated if you share the code? Or am I missing something?


> you cannot get the source code unless you are a paying customer

That's literally the GPL.

> if you are a paying customer you get terminated if you share the code

And that's shit, but also the problem with tethering yourself to a single vendor. They don't have to do business with you.

There are plenty of other RPM enterprise vendors, switch to SUSE.


> The anger and resentment towards Red Hat in the open source world had always made me sad. Red Hat made linux mainstream. Before Red Hat, big expensive commercial software all ran on UNIX: HP-UX, Solaris, Irix.

Now we have just fscking Linux, no apps, and RH is even closing it down. There you have your reasons. Open source my ass - that you can't even redistribute; it's just a big scam.

Update: fortunately there's still Mac OS.


> Update: fortunately there's still Mac OS.

Go download the source for Darwin.. https://github.com/apple/darwin-xnu

Compile it. Install it on your MacBook. Tell us how well MacOS boots that kernel.


When I was young and optimistic, I was doing a bunch of side IT jobs. At one, a local insurance company needed to replace their Windows NT server. Instead of going with Windows 2000, I talked them into me setting up a RedHat Linux server running Samba. I had a few hiccups as the workstations weren't actually connected to a domain originally, but I eventually got them all going with AD login, roaming profiles, tape backups, etc. The big selling point was the open source nature, free updates forever.

Less than six months later, Redhat announced that the were going to discontinue RedHat Linux and start releasing their new RedHat Enteprise Linux. This left me rather angry and embarrassed. It was definitely a turning point in my understanding of FOSS. It also made me a lifelong Debian/Debian derivative user.

I've supported RHEL professionally, even getting RHCEs in it. RedHat has also contributed a lot to the open source community. But I've certainly never forgot that first pivot, so I'm not surprised with their recent decisions regarding RHEL's source code.


I understand embarrassment, but anger might be misplaced. Red Hat was a newly public company trying to turn a profit. It identified its market and Red Hat Linux wasn't serving it, and the model they were pursuing with Red Hat Linux wasn't working.

But I am a solid supporter of the "pay for RHEL or use Debian" philosophy. If you need promises about the future, pay for RHEL or use a project that doesn't have commercial motives. Debian is great and I wish more companies would standardize on it and support it.

I'm not such a fan of the middle road of hoping that vendors will continue supplying things of value for free. It's especially ironic that an insurance vendor got burned by placing a bet on a free operating system with no assurances whatsoever. The RHEL subscription is insurance.


Pay for RHEL or use Ubuntu

Edit: I guess people don’t like Ubuntu that much


Both Canonical and Ubuntu have their own share of problems, and they've been struggling to monetize Ubuntu for the past few years. Once you get burned by one commercial vendor (not once actually… it's the third time afaik), it's probably wise to use this opportunity for migrating to a more stable distribution where commercial interest doesn't have much influence, and which has never intentionally burned its users (since Debian developers are users too and are also doing it for themselves).


Heh. Saw the edit, but responding anyway. Canonical has its own issues. I can overlook some, others (like forcing Snap on users) have put me off a lot.

Ubuntu did a lot to popularize Linux and make the Linux desktop experience more usable. It struggled for a long time to figure out how to monetize that, though. They seem to be profitable now[1] claiming a growth in revenue to $205.4m and operating profit of $44m with a headcount of 858 (up from 705 the prior year).

The "Ubuntu Pro" move this year (which also raised many hackles, briefly) will probably pad the coffers a bit more.

[1] https://find-and-update.company-information.service.gov.uk/c... (See "Group of companies' accounts" through December 2022. The PDF link is atrocious.)


I don’t see a reason to use Ubuntu over Debian


AKS and AKS Engine uses Ubuntu. From an Enterprise point of view, Ubuntu LTS and RHEL are more attractive.


For what reason? The certifications?


> Pay for RHEL or use Debian

In this climate, that is a solid philosophy


> The big selling point was the open source nature, free updates forever. Less than six months later, Redhat announced that the were going to discontinue RedHat Linux and start releasing their new RedHat Enteprise Linux.

I wish there were legal consequences when companies lied about future prices of things or durations of support.


I mean there are if you are under contract or otherwise paid for a product as advertised…


How about if you are under EULA, and paid $0 as advertised?


Indeed. It's absurd for them to be able to treat EULAs as real signed contracts when you violate them, but as nothing at all when they do.


You were not the only one.

Notes and presentations from various HEPiX conferences around 2003/2004 will reveal the reaction to academic licence fees for RHEL, and the birth of Scientific Linux as an EL rebuild.

Remember these were/are publicly funded projects with budget time-lines.


Fedora was released and all of us that used Red Hat Linux just moved right over like nothing happened.


Remember kids, if you're not paying for it, you're the product.


Open Source was supposed to be the opposite of that though.


The problem is money. The solution is money.

At the turn of the century the only ones paying for this linux thing we were all dedicating our lives to proliferating. Around this time solaris was teasing going open source and freebsd was on parity with linux. We had options then and we have options now. Redhat eventually relented, but here we are again. We've come a long way, now we're leaders and decision makers at our respective organizations. I've since abandoned redhat, I invite you to do the same.


GPL Version 2: "6. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein." (emphasis added)

GPL Version 3: "You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License" (emphasis added)


And they don't - if you buy a license, you can download all of the sources for free. They simply refuse to do further business with you if you choose to excercise your right to distribute it further. Nothing in the letter of the GPL prevents me from refusing to do further business with you (including providing you access to future changes to the GPL software or its sources) if you choose to excercise any of the four freedoms.

Of course, there are good reasons to believe this violates the spirit of the GPL, but that's beside the point.


The question is whether Red Hat's subscriber agreement constitutes a restriction on exercising their GPL'ed rights.

You get source to RHEL 8.5. You rebuild it (carefully removing Red Hat marks/logos to avoid being snagged for abusing the trademarks), and Red Hat says "ok, you're done. Go ahead and distribute that all you like, but we're cutting you off."

Your rights are intact, but your subscription and access are severed.

I've said this elsewhere: I don't think you or anybody really wants a GPL that can be used to force a business to continue its relationship with someone it doesn't want to do business with.

What's to stop a company from claiming that their subscription was really terminated for redistributing code and not because they failed to pay their bill or maybe because they were abusive to Red Hat support folks?

For that matter, what's to stop Red Hat or another company from removing that from their agreement but continuing to cancel subscriptions (or just refusing to renew) without stating cause?

People who think that this GPL provision is going to force Red Hat to just open the floodgates again and continue pushing out exact RHEL release code are likely very, very mistaken.

If Red Hat has decided to stick a spoke in the clones' wheels, it can simply release only GPL'ed code and stop releasing any non-GPL'ed code that doesn't require it. The current scenario with the code Red Hat releases to Stream is infinitely better in every way except if all you want to do is rebuild the "bug-for-bug" clones or consume them.

As far as I'm concerned it more than meets Red Hat's minimum requirements to comply with the GPL and as a participant in open source. Unlike scores of open core companies, all of Red Hat's features and innovations are being released - the sole thing being held back is exact clones of its product.


They could also release just application source code and not the spec files for building the package. It's the spec files and the patches that's central in this conflict, not the actual source code, but people keep conflating the two.


Red Hat may release spec files to conform to the requirement that source code includes "scripts used to control compilation and installation of the executable."

Note that this particular requirement got a fair amount of attention in 2011 when Red Hat changed its kernel source releases and stopped breaking out patches. (Here: https://lwn.net/Articles/430098/)


Hard to judge if that covers just makefiles or if it also covers rpms. Guess it makes sense they should share the scripts required to rebuild the binary as it's delivered by them


Yeah. Here I see Red Hat trying hard to live up to the letter and spirit of the GPL, but it's not getting appropriate credit on that one.

In some ways I think of the GPL(s) like the Bill of Rights. Great document, great ideas behind it - falls flat in some respects today due to age and ambiguity.


More purity fight even before that. Remember, when pre-compiled kernels started to get popular, it was seen as bad thing, as everyone was supposed to compile their own kernel which took into consideration of their hardware configuration for optimization.


Ah, self-compiled kernels at least once a week. Those were the days... which i would not want to return to.


The Gentoo way. The tradition lives on...somewhere...


Doesn’t Gentoo handle the compilation for you though? From the end user perspective, it’s effectively just a really long install process.


That's what compilation itself usually is though? You don't go and call cc manually for every single compilation unit youself, you just run something like "make" and wait.


True, but I guess I meant more that people who are installing Gentoo aren’t necessarily cognizant of what is being compiled.

They’re not following each dependency, building it, then testing it, debugging etc…

That’s not a judgement on them. I wouldn’t want to do that either. I just meant to say that they “feel” different to me, even if the end result is the same.


The kernel is much more likely to be "actually" built from source by Gentoo users (in the sense of going and doing things with "make" in the kernel source directory) than any other package. There are automatic options available for the kernel but the "just get the sources and handle the rest yourself" option is, I'm sure, more popular for the kernel than anything else.


Gentoo has binary kernel (if you want it) - and of course other options for source, vanilla, etc.


NixOS and GuixSD, much younger distributions in the same broad source-based package management tradition as Gentoo, also make custom kernels super easy to integrate with their usual package management systems while providing convenient, pre-built options.

I'm fine with generic kernel builds and that's what I usually use, but I don't think tweaking your kernel is as painful or manual today as the greybeards here remember.


> I'm fine with generic kernel builds and that's what I usually use, but I don't think tweaking your kernel is as painful or manual today as the greybeards here remember.

Back then, we went into "make menuconfig", and meticulously reviewed every single configuration option, carefully tuning them to our bespoke hardware; it only took a few hours. Try doing that nowadays; there's simply way too many configuration options (each new device driver adds a couple, and even the kernel core has grown to hundreds of them). So yeah, I'd say fully tweaking your kernel is a more painful process today than in the past.

(The same for packages; back then, we could open "dselect" and page through all the available packages in a single evening; nowadays, there's too many of them.)


When I was in high school, I used to use `make menuconfig` that way. I guess I hadn't thought about extending that comprehensive review process to contemporary kernels. I imagine that most people compiling their own kernels today are doing it for the sake of specific, targeted tweaks that they are aware they want in advance.


How much extra performance would you squeeze out on a normal consumer laptop by compiling the kernel yourself nowadays? One per cent?

Even back in the Gentoo days, when we measured the differences, they were underwhelming.


Wasn't the kernel so much as compiling all the other stuff with GCC picking the right arch/optimisation. Cause those were for sure faster than running the stock i386 or i686 or x64 apps. But it's been so long (2005) I don't have the numbers in front of me anymore. Not as critical in 2023.


"Caldera is preferred by 127 petitioners"

Well, I've got something to tell these 127 people from 2000 about SCO who have an issue with RedHat about some impending doom in 2003 [1] ;-)

[1] https://en.wikipedia.org/wiki/SCO%E2%80%93Linux_disputes


To be fair, nobody saw that one coming. Caldera was fine, they had done some fun stuff with the installer (Tetris!) and they had a exotically named CEO (Ransom Love), but they were fine.

Their heel turn happened after a management change. The whole debacle was stranger-than-fiction (at least at the time). The whole "we're SCO now, and we're evil" was just bonkers.

The lesson that people should've taken from that, though, is that any company is just one management change away from major changes.


This issue has gotten a lot of attention on HN lately, but I'm still struggling to wrap my head around it. If anyone can clarify my understanding I'd appreciate it.

My understanding is that Red Hat Enterprise Linux can be thought of as Fedora + stability + patches, and that the patches themselves should be released downstream as part of the GPL.

What's now changed is that these patches are either (a) not distributed as required by the GPL, or (b) the patches are distributed, but in a way that is intentionally less useful, e.g. by having to get them via the Red Hat portal. This has made it more difficult for "repackagers" like CentOS, Rocky and Alma to keep their disros up to date.

Assuming I have the above correct (and I may not), my suspicion is that Red Hat is looking at cloud providers who also have been repackaging, for example, Amazon Web Services' Amazon Linux has historically been RHEL repackaged and bundled with some aws tools. I'm not aware of AWS distributing their changes either. From this perspective, it looks like the AWS benefits from the stability + patches without paying RedHat for their development. (I'm also not aware of whether aws distributes the Amazon Linux sources and if so those are done in a way that is useful for the community... I'll do some further research on my own. edit: It looks like the Amazon Linux sources are here: https://github.com/amazonlinux/linux)


Short version: Red Hat ceased distributing RHEL sources directly to git.centos.org in a way that easily enabled Rocky, Alma and others to rebuild "bug-for-bug" compatible clones to RHEL releases.

Also, folks are realizing that Red Hat's subscription agreement allows it to terminate the subscription (and access to future source code) if someone redistributes code (including GPL'ed code) in a way that Red Hat doesn't like.

People who misunderstand the GPL are accusing Red Hat of violating it by not widely distributing RHEL source to everyone.

People who sort-of understand the GPL (or willfully misrepresent it) are accusing Red Hat of violating the GPL by "restricting" the ability to redistribute sources. IMO it is not, because customers have all their rights to the code they receive under the subscription prior to termination - they simply are blocked from later releases.

Red Hat has basically acknowledged that it "sees no value" in a free RHEL clone, and is under no obligation to make it easy for clones to exist - so it's not going to anymore. It prefers you use Stream or pay for RHEL or do something else.

I've been writing about this a lot on my blog, starting here: https://dissociatedpress.net/2023/06/24/red-hat-and-the-clon...

(Disclaimer: I'm a former employee of Red Hat, so I am potentially biased one way or another.)


> What's now changed is that these patches are either (a) not distributed as required by the GPL, or (b) the patches are distributed, but in a way that is intentionally less useful, e.g. by having to get them via the Red Hat portal. This has made it more difficult for "repackagers" like CentOS, Rocky and Alma to keep their disros up to date.

The situation is actually (c) - IBM RedHat is distributing the patches (and sources) as required by the GPL, but only to people who pay for their license. Re-distributing said patches or sources automatically invalidates your license, so if you exercise your GPL rights to re-distribute the GPL code you bought from IBM, you immediately lose both your support contract with them and any access to any future patches.

This has meant that many companies and projects who were historically using CentOS for free have found that they either have to pay IBM to move to RHEL, or to switch to another distro. Projects like Rocky and Alma which were trying to replace CentOS are now on rather shaky grounds (though they are trying to find additional ways of surviving).


The software is GPL, you do not pay for a license. You pay a subscription.


Piggybacking off your comment to add some additional questions; I'm in a similar boat as you.

I've always been a user of the Debian and Arch worlds. The RHEL/Fedora/etc world has been this "other" part of Linux that I frankly haven't touched much, and haven't yet found a reason to.

One thing I'm not totally clear on is what specifically Red Hat offers that people pay for, i.e. what are the details of the "+ stability + patches" of what GP mentioned. Are there paid applications as well? Is paid support a large part of the business model? And so on and so on. I'm still just a little mystified by the RHEL business model, and every time I hear someone talk about it, it's literally vague one-word answers such as "stability," "patches," "support," "enterprise stuff," etc. Even the RHEL FAQ offers essentially just that.

I'm still not quite informed enough to be able to confidently lean one way or the other, but I have to say that I can't shake the feeling that RHEL's business model ultimately relies on exploiting their customers' desire to change their systems as little as possible, even if it means the customers eschew more modern systems that make obsolete the need for the kind of products and services RHEL provides. Or to put it another way, RHEL enables their customers to live with "the devil they know," and not adopt more modern best practices. Which isn't necessarily a bad thing, I get it, but also if that is indeed the case, it seems like a rickety foundation upon the already rickety foundation of trying to sell open source software that easily be unseated by, say, the nix model of doing things.

I don't know, I could be dead wrong, but starting from what I've seen most other tech companies do and mixing it with a dash of "the idea of paying for Linux seems insane to me"...in lieu of better information, I can't dismiss the above out of hand.


One benefit is if you pick a major version of RHEL or an LTS Ubuntu, you know that you’ll have 10+ years of consistent APIs and ABIs. If you stick to latest upstream distros, you can run into unexpected API incompatibilities causing bugs and breakage.


Right, I get that, and I totally empathize with customers that would want that. But that's also part and parcel to the "devil you know" I mentioned. Like, in my experience -- which, sure, is absolutely not in a world that has ever touched RHEL, so once again I want to stress that I could definitely be talking out of my ass -- the safer place is actually to continually roll close to the cutting edge.

Very, very generally, updates tend to play better with or expect that the software it's working with is also updated; and so, while yes it can be stable to stick with a particular version for 10+ years, the value of that stability drops as time goes on, as the software/OS in question has more and more trouble operating in the context of/with other/newer software, and so 5+ years into that 10+ year timespan, that stability you're supposedly paying for doesn't feel very stable at all -- and that doesn't even begin to touch what happens once those 10+ years run out and you need to get with the times.

Which is all to say: this is why rolling releases exist. Better to get used to surfing the wave all the time, rather than sitting on the beach for years and then having to swim an Olympic race after you're out of shape. I'm mixing metaphors here but you get the idea.

What's more, obviously riding the wave can be a little tiring, and thus more and more best practices are borne out of that problem -- which is why I mentioned nix in my last comment. I'm not even a nix user, have never done more than read about it, lest one think that I'm yet another nix zealot on HN, but I do think that it or something like it is a very very good solution to the pains that can be had by constantly staying up to date. I for one will always be more interested in that kind of route, rather than agreeing to the golden handcuffs of long-term support. While not in a RHEL-like setting, I've been bitten by the "I just want this old thing to keep going and never change" problem too many times before.

Like, I was listening to the most recent episode of Linux Unplugged, and they had a member of the RHEL team on, and when asked about the value proposition of RHEL, he said something to the effect of that it's not just the software, but being able to offer the specific versions with the specific patches in particular combinations of other software with whatever patches. And I couldn't help but think -- isn't he basically just describing nix? Nix's whole thing is to super easily enable declaring specific versions of software in specific combinations, and to be able to recall it with a config file -- Matthew Croughan's talk at SCALE this year was essentially...that, and doing it super easily. And perhaps if we aren't keeping so much old software alive, it wouldn't all need so many patches to allow all the various combinations required.

I don't know. It all seems like a very heavy-handed, people-y solution to a problem that we've mostly solved, and perhaps even eliminated the conditions for to exist in the first place.

Anyways, this is all mostly hypothetical pontification, and I'm sure that those who actually work with RHEL on a daily basis could poke tons of holes in my point of view. Would love that actually, as like I said I feel very much like an outsider looking in. But it just seems like a goal that is fundamentally flawed.


I agree with you in theory, but most large enterprises will never, ever be able to make rolling OS releases happen for political and even structural reasons. When the EOL comes, they pay for extended lifecycle support and hope for sunnier days in the future.

For those enterprises, the value of the stability RHEL provides goes UP as time goes on, because the longer you wait, the more risky and costly it is to migrate to the new version/solution/etc.


You're understanding of what RHEL is seems to be off. Basically the current pipeline is Fedora->CentOS Stream->RHEL or CentOS Stream -> Fedora, RHEL. The downstream from redhat distros (centos, rocky, alma) were just recompiling the same packages as rhel and claiming 1:1 bug compatibility, which is a claim that might not even be true. They were able to do this because RHEL used to publish the packages that made up the distro to the public, but now they are only doing that for their customers. Everything that exists inside RHEL is available through centOS stream, the issue for the clones is that there also exists some changes that have not been added to RHEL yet.

Ultimately, the issue is RedHat thinks people should be using centOS stream if they don't need enterprise support and a significant part of the community just want RHEL but free.


What @dcow said.

> the patches themselves should be released downstream as part of the GPL.

The GPL only says you must provide the source to your customers. Not to anyone else. It does not compel you to offer them the world, gratis, no, not if you don't want.


But your customers are free to provide said source to anyone for free. In practice, letting your customers have the source means letting everyone have it.


Not really, though: if you do so, you lose the right to continue doing business with IBM/RedHat, so you can only really do it once.


Hmm, this seems counter to the notion of GPL, IMO. The GPL allows you to redistribute the source. I don't think it allows companies like RedHat to impose restrictions like "here's the source, but this is the end of the road: you can't take it any further than this"... it would surprise me if RedHat's terms weren't themselves a GPL violation, if what you're saying is true.


I want to know what their DRM strategy is going to be. Are they just going to terminate the contracts of anyone who downloads the full sources?


The thing is, AWS Linux has already moved to being based directly on Fedora. So it's probably not them specifically being targeted.


> My understanding is that Red Hat Enterprise Linux can be thought of as Fedora + stability + patches, and that the patches themselves should be released downstream as part of the GPL.

> What's now changed is that these patches are either (a) not distributed as required by the GPL, or (b) the patches are distributed, but in a way that is intentionally less useful, e.g. by having to get them via the Red Hat portal.

My understanding is a bit different:

Red Hat submits patches upstream and also back-ports those patches into existing RHEL releases that have long-term support.

The upstream patches are still as open as ever, nothing has changed.

The back-ports into existing RHEL releases are what Red Hat is trying to make harder for people to consume outside of a Red Hat subscription (the free developer subscription and the paid support contracts).

I'm not making a judgement either way in this comment, just trying to help clarify my understanding.


> The back-ports into existing RHEL releases are what Red Hat is trying to make harder for people to consume outside of a Red Hat subscription

That’s an interesting detail. Thanks!


I think the two main culprits for limiting RHEL sources are RHEL based cloud offerings including AWS Cloud for Compute and Rakuten Cloud for Telcos (Symphony)[1]. This is very similar case to the MongoDB situation when it finally decided to change the original open source license but instead Red Hat limits its source codes.

[1]Has Rakuten made a Rocky-er road for Red Hat?

https://www.mobileeurope.co.uk/has-rakuten-made-a-rocky-er-r...


Nothing in the GPL says sources must be available to anonymous unauthenticated users. RHEL just requires you to sign in to download the sources, which is making some maintainers grumpy. I don’t believe this is some grand scheme to make maintainers grumpy, they are just curmudgeons.


> RHEL just requires you to sign in to download the sources, which is making some maintainers grumpy.

From what I've read, what's actually making people grumpy is that signing in to download the sources, and later giving these sources to anyone else, could risk losing your RHEL account.


It's not that it could risk that, it's that it absolutely means you lose your RHEL account (and any other contract you had with IBM), at least if they find out about it.


I don't believe this is true. It's almost certainly not true for instances of distributing a limited set of sources. That is, I seriously doubt Red Hat or IBM are looking to cancel subscriptions if I download the latest package from RHEL 9.x for Bash or even the Linux kernel and distribute those sources quietly.

If I download everything and advertise a rebuild based on those sources? I'd expect that my subscription will be going away soon. There's probably a line somewhere in between where Red Hat would take notice and care.

But I would wager a good bottle of Scotch[1] that line is much closer to "everything" than a maintainer grabbing Red Hat's changes to their work via a sign-in to the no-cost account and incorporating those changes or something like that.

[1] Say, Auchentoshan Three Wood or something good but not like 30-year-old Speyside. I'm not made of money...


Per the RHEL subscription agreement, you lose your subscription if you do any of this. Of course, whether they will choose to act on the letter of the contract or not is up to them, but the letter is clear.


No, per the RHEL agreement they have the right to terminate your subscription "upon review" if you do any of this. It's a subtle difference but it's also worlds apart from "you will have your subscription terminated" (i.e. automatically, as a matter of fact/contract) in the court of law (and in terms of real world repercussions for anyone that isn't building a competing distro).


That risk is non-zero in a world where zero of these risks exist for any other GPL software. Relying on nonenforcement is a monumentally foolish business decision.


Does RH not sell individual copies of RHEL to random members of the public? Is it strictly a large customer account product?

Because if they distribute a copy to an individual, RHEL account access banned or not, distribution of binaries puts them on the hook for providing sources. Unless there's no way to buy a single copy as a random stranger, this all seems incredibly impractical to enforce.


AFAIK, Red Hat doesn't dabble in any retail redistribution of RHEL that would work as you suggest. You can, I think, get a self-support 1-year subscription online with a credit card for about $350. You can also sign up for no-cost subscriptions. Either of those would be distribution, but also are subscriptions that provide access to binaries + source.

In any case: Red Hat giving you a copy of RHEL only entitles you to source for that version and not future (or past) versions.

So if you somehow receive RHEL 8.5.1 from Red Hat on media independent of a subscription, you have the right to receive the sources for GPL'ed software present in that release.

Not RHEL 8.5, not RHEL 8.5.2, etc. And, technically, you only have the right to source to GPL'ed software, so they don't have to give you source for Apache HTTPD or other permissively licensed software in RHEL.

An interesting wrinkle that I haven't seen addressed yet is whether Red Hat has to find a way to convey source to you after the subscription if you had access to download source during the subscription but didn't exercise it. It was there, you just didn't take it. If you want it later, do they have to ship you a DVD or something? I have no idea.


the moral of the story is, nothing happened, RHEL was a great product, everyone was happy. Just like I think they will be when they realize CentOS Stream is still a viable product.


CentOS Stream is at least as good as CentOS (probably better) was before Red Hat "acquired" it.[1] It's funny how rose-colored people's memories or suppositions about the past are.

Basically - there's never been a bug-for-bug compatible RHEL clone that shipped quickly until Red Hat made it possible to do.

Stream isn't a product, it's a project. And it should be a project. If Rocky or somebody else wants to add value and make it a product, they can do the work to do so. Rocky/CIQ, in particular, has made all kinds of noise about how Rocky is the "stable foundation you can build on and rely on for years to come."

Well... Red Hat has decided to stop making it super-easy. It's a bummer that this hits users who were never potential revenue sources for Red Hat/RHEL, but I can just hear investors asking "why the ever-loving ** are you making it so easy for others to clone your biggest product?"

[1] https://dissociatedpress.net/2023/07/03/red-hat-and-the-clon...


< I can just hear investors asking "why the ever-loving * are you making it so easy for others to clone your biggest product?"

It is telling that no one in the meeting could actually answer that: "We still face formidable competition, and we do not believe our moat will hold for more than 12-18 months before whatever replaces us in the market emerges and begins rapidly eroding market share, resulting in dwindling profits and share prices. By allowing an unofficial free-tier -- a clone, as you say -- of our enterprise product, we keep developers from rapidly switching to Debian and it's derivatives. Once that happens, the hosting and enterprise data center markets will collapse irretrievably leaving us with only legacy customers who will leave, one server age-out at a time."


Precisely. It's pretty incredible. Even with CentOS they were losing ground to the competition, it's going to accelerate going forward.


If you like beta-testing in production, maybe.


Note that while CentOS Stream is continuously integrated (in a way that may not be suitable for production), each patch is still thoroughly tested, using roughly the same testing procedure as RHEL. So it's a mischaracterization to call it a beta test, but it's nevertheless not a production-grade stable platform for most purposes. It's a rather weird middle ground to be in, not one that I can think of any parallels for.


The release model for CentOS stream is basically the same as debian. If people are happy using debian in production, I don't see why CentOS stream would be fundamentally different.


Why would you expect for profit business to do all the testing for you?


Why would you expect doing free testing and contributions for a for profit business?


No one expects that. Use it or not. But don't demand the final product for free.


Who demands final product for free?

The final product includes support; nobody is asking for that. There is no expectation for dedicated engineer time or solving their support cases. Nor is there any expectation of certifications or any other value-adds that RH provides.

Afaik the cloners demand the access to sources and patches to what is being shipped, which is their right. They are GPL, and not Redhat's for most part.


"There is no expectation for dedicated engineer time or solving their support cases"

Sorry, but yes there is. The final product includes the outcome of all that. Especially the minor and z-stream releases are the culmination of all the work of customers reporting bugs and Red Hat applying that dedicated engineer time and solved support cases to the next release.

There are many companies (including the one I work for) who treat clones as equivalent to RHEL. So, yes, it effectively conveys many of the certifications and system requirements to receive support from other companies. The clones have been promising "bug-for-bug" compatibility for a reason, and that reason is (in part) to ride the certification coat-tails.

If these things were not true, there'd be none of this drama. Rocky and Alma could easily base Linux distros off Stream and do additional testing and add or modify features to be more interesting. The code is there. The product is not.


> are the culmination of all the work of customers reporting bug

Aren't these supposed to go into Stream?

> So, yes, it effectively conveys many of the certifications and system requirements to receive support from other companies. The clones have been promising "bug-for-bug" compatibility for a reason, and that reason is (in part) to ride the certification coat-tails.

Yet, it is not the same as certifications. Certifications apply only to the original RHEL; clones are in the gray zone: it should work, but if there are problems and you need to use them, you better have it on RHEL.

> If these things were not true, there'd be none of this drama.

The drama is there, because RH/IBM thought, they could squeeze those customers, that use both CentOS and RHEL (usually CentOS for dev or staging and RHEL for production); they wanted it all.

I can understand if those companies file support cases that originated in CentOS and RH things, that they abuse their support contract. That's not OK. But RH has it's own skeletons in closet, too.

The clones themselves are a collateral damage there.


> Who demands final product for free?

Just about everyone. The final product is RHEL in this context.

> which is their right

No, as per the GPL they only have to provide sources to paying customers.


> No, as per the GPL they only have to provide sources to paying customers.

If they were providing binaries only to paying customers, that would be right.

But they aren't. Anyone, who spins up RHEL VM in the cloud, uses UBI image or downloads it from the developer account has the same right.

In all cases, RH cannot prevent anyone, who obtained the sources, from distributing them further; not even threatening with contract termination. That would be "further restrictions", which GPL explicitly forbids.


Use Fedora Server. Or any other distro. The uproar for not having the exact same thing they provide for a fee (while still giving you extremely close options) is unjustified.


Ultimately each (major) Linux distro is its own independent Operating System that is its own thing and will make its own decisions. Sure, they might share many, if not most, common components, but an distro is an example where the whole is more than its parts.


>redhatisnotlinux.org runs Slackware Linux 7.1, Stronghold 2.3, PHP 4.0.0, and PostgresQL 7.0

An elegant weapon for a more civilized age.


So shocking to see PostgreSQL in that list. MySQL was definitely what was in vogue at the time.


I remember that too, but I think I've heard that postgres was also popular in the linux/oss world at the time


I'm still not over the end of CentOS

That was so disappointing.

Waiting to see which of the two alternatives shakes out.

Dangerously past EOL on some servers, I just don't have to motivation to rebuild.


> which of the two alternatives

There are not just 2 and never were.

Oracle is, you know, quite big and fairly well known.

https://www.oracle.com/linux/

It's also much older than either Alma or Rocky.

So is Springdale Linux, formerly PUIAS Linux:

https://springdale.math.ias.edu/

EuroLinux is also a thing for the wider world, i.e. outside North America:

https://en.euro-linux.com/eurolinux/what-is/

In Japan there is Miracle Linux:

https://distrowatch.com/table.php?distribution=miracle

In China there is Euler OS:

https://developer.huaweicloud.com/intl/en-us/euleros/index.h...

There was also Inspur K-UX:

https://en.wikipedia.org/wiki/Inspur_K-UX

Both the latter were even officially UNIX™ certified.

I am sure there are many more I don't know about.


Alma and Rocky were the only two real matching replacements and considering Alma is the only one with $1 Million/year on the tablet to guarantee survival until 2029, I'm not going through the drama of a small or unanchored product again so that might be the "winner".


Alternatives? Are you not following the news? They are kaput. Dead in their infancy.


It seems like you aren't following the news. Both Rocky and Alma have announced they will proceed with a workaround.


People typically shorthand the most popular thing as inevitable.

After Red Hat, Ubuntu was the one that people would think was all of Linux.

This doesn't just happen in operating systems. I've talked to several people who seem to think AWS is literally the only way to run a server, and have it as their baseline assumption at all times.


And this attitude is exactly why Linux is still 20 years behind everything else. Red Hat can't be Linux because Linux doesn't exist.

Every install is different. There's no platform to target. No API levels or anything like that. The Linux idea of compatibility is "You can make it work, with a hammer, if you spend a half hour".

I fully believe that it would be easier to add the missing bits to Android, to make it able to replace "Real Linux" even on servers, than to get Linux to a state that was fully ready for the Year of the Linux Desktop.

I used to think it was being held back by big tech or something.... but as time goes on, I realize it's more about the fact that Steam doesn't work on my laptop and I will probably have to spend 20 minutes fixing it, and this is on Mint.


Must have been mid 90's, and I was in France with my parents who were doing up a run down house there, and we ended up in some shop and I stumbled upon a "Linux Pour Les Nuls" book which came with a RedHat disc - that was my first ever foray into Linux! I spent my summer holidays messing about on a laptop with it, and that pretty much cemented my joy it. So, whatever happens (and I have no idea as I'm not really paying much attention to it) but it was always my first!


I'm assuming that's the French version of "Linux for Dummies", but it sounds like it might translate better as "for Nobodys"? Seems a bit more approachable.


RedHat is still doing a lot of work in upstream open source projects, I want them to stay around and continue to do so.

To do that they need to be commercially successful.

Now, you can argue whether the recent moves are helpful to their bottomline or not (I think this is short-sighted and in the end will hurt them), but we need to acknowledge they are not charity, and also that we all are already benefiting from their money and their work.


I started on RedHat and it has a special place in my heart - even now they still host the original distributions I cut my unix teeth on all the way back.

But sadly times change. Get it, they want to make money, but doesn't change the sadness these recent moves have caused.


Nostalgic to have this take an unnecessary detour into the whole "GNU/Linux" nonsense.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: