Unless you like your system to get updated and suddenly stop working, which I usually don't.
Like, I get it, they want people to turn to RHEL and pay them outright, they say so themselves in a blog post about replacing CentOS with CentOS Streams. Well, about not and moving to RHEL.
I'd have gone for a split model, like OpenSUSE, CentOS rolling -> CentOS stable -> RHEL.
That is not correct. What Red Hat has done is make the development of RHEL more open than ever, while also turning CentOS into a useful distribution with a clear purpose, and maintaining stability. The new Stream model is indeed prepared to run in a production environment (Meta/Facebook is a great example), as it is the stable branch of RHEL. Any update that CentOS receives has been approved for inclusion in RHEL.
And how can you say that Stream is the stable of RHEL when it's their upstream? It was more stable when it was downstream, and sure they've approved it for RHEL, but they also release to CentOS first for a final scream test. Sure it's not Arch with nightly builds levels of stable.
But then again, if you enjoy the distro, all the power to you!
But I feel that part of their argument in favour of Stream is: you don't use your OS anyway, just containerise everything, cloud this and docker that. Well, sure, but I don't do containers or cloud, why should I use containers to solve the issue that my OS wants to be trashable, that I need another layer of complexity, and loading another smaller OS inside. I might as well install whatever the containers are build from as my host instead...
But I guess I'm just an old asshole that hates change anyway. 🤷‍♀️
> I’m wondering if someone could shed some light on why is it dislike by the community
I think it's because Red Hat is an engineering company, and they tend to communicate like engineers. People who are not engineers tend to interpret statements from Red Hat to mean something quite different than intended, and misinterpretations lead to a lot of aggravation.
When Red Hat effectively replaced Red Hat Linux with Fedora Core, they made the distribution free-of-charge, and opened it for contributions from the community. Developers had been asking them to do that fo *years*. It was a huge improvement. But still, the most vocal reactions in the community were angry about one thing or another.
The same thing happened when Red Hat shifted their focus to CentOS Stream as a community distribution. The new process is a *huge* improvement, but a lot of people hang on to the old model because it fostered the illusion of "enterprise" readiness.
(CentOS Stream is more secure than CentOS Linux was, more reliable, its source code is more open, and it actually works like a community project, which CentOS Linux did not.)
The unsaid thing re: centos stream vs centos linux is that there were gaping holes in the update timeline where you could technically go with unfixed cves for some time.
There are so many reasons why people dislike Red Hat Enterprise Linux, some making more sense than others:
people just hating Red Hat as a company, or their parent company IBM,
the fact that RHEL is a commercial distribution that expects you to get a paid subscription for a lot of money (though there are exceptions such as the free developer subscription),
the fact that official RHEL binaries can only be obtained through a subscription, and the subscription terms prohibit their redistribution (which some people argue conflicts with the copyleft licenses on some of the software, but Red Hat lawyers of course argue it does not conflict),
the recent decision to stop publishing source code to non-subscribers (which is in fact not required even by copyleft licenses) and to also ban redistributing those in the subscription terms (which, as for the binaries, may or may not actually conflict with the licenses),
the embrace-extend-extinguish they did to CentOS, buying out the project, then discontinuing it,
the small amount of software they actually support (no KDE Plasma, no QtWebEngine, no X11, etc.), in fact, they do not even support all the subpackages that their SRPMs build, and the supported package set is not even self-hosting (a lot of -devel packages are unsupported, even when supported packages require them to build),
the fact that even EPEL does not provide everything RHEL has left out (e.g., there is no X11 in EPEL for RHEL 10),
the fact that some packages that are "built, but not supported" are not even shipped in the unsupported CRB repository, which is a problem because EPEL also cannot ship those packages due to the conflict potential,
the age of the shipped software at the time of the release,
the long time between two releases.
What some people would like is a distribution that is free and released every 6 months with lots of recent software, like Fedora, but supported for 10+ years, like RHEL. Of course, that is not going to happen for both financial and technical reasons.
As you said, some of these don't make sense. The reason that some of them don't make sense might not be obvious to all readers.
> the subscription terms prohibit their redistribution
This dosn't make sense, because the subscription specifically states that it does not limit any rights granted by the license. What it does prohibit is providing third parties access to Red Hat's support services.
> the recent decision to stop publishing source code to non-subscribers
This doesn't make sense because at any given time, there are up to 5 actively maintained branches of a RHEL major release. Historically, Red Hat published a sub-set of the code, of just one of the active branches at a time. The code they published was not the input to their build process, but a build artifact... an output of their build process. A fragile "Rube Goldberg"-esque process transformed those artifacts into something that looked like a git branch, but which was unusable for collaboration.
Today Red Hat publishes just one branch (the major-version branch) as they always have, but it's the *real* branch of RHEL that Red Hat developers work on. It's complete, and provides the bits that were missing from the old process. You can collaborate with RHEL through standard processes like Merge Requests in GitLab.
> the embrace-extend-extinguish they did to CentOS, buying out the project, then discontinuing it,
This doesn't make sense because they haven't discontinued CentOS, they've improved it.
> the fact that even EPEL does not provide everything RHEL has left out
This doesn't make sense because EPEL is not a Red Hat project, it's a Fedora project. It provides what Fedora maintainers build. The decisions about what is in EPEL are often not Red Hat's to make.
I know that you know these things, but I hope this helps some readers who are less familar with the process.
This dosn't make sense, because the subscription specifically states that it does not limit any rights granted by the license.
But it also states that exercising those rights automatically terminates your subscription, so you can only do that once in a lifetime, which, considering that the software constantly gets updated, defeats the point of the license, and of the subscription.
A fragile "Rube Goldberg"-esque process transformed those artifacts into something that looked like a git branch, but which was unusable for collaboration.
It was Red Hat's and only Red Hat's decision to publish the source code in that strange form (with the claim that it made it easier for (the original) CentOS to work with it) instead of the SRPMs that had been shipped in the past and that nobody ever complained about.
Today Red Hat publishes just one branch (the major-version branch) as they always have, but it's the *real* branch of RHEL that Red Hat developers work on.
That is the branch the developers work on, but not the branch that is shipped to users, which is the one most people actually care about. Especially for security fixes, what gets shipped to subscribers is often a backport that never makes it to CentOS Stream in that form, because CentOS Stream already has a newer version of the package and the fix is applied to that one instead. Also, due to embargos (and due to having to do the work twice due to differing package versions), fixes sometimes only make it into CentOS Stream days after they are shipped in RHEL.
This doesn't make sense because they haven't discontinued CentOS, they've improved it.
LOL, just like all that processed food with "improved" recipes where they replaced some premium ingredient with a cheap low-quality substitute.
This doesn't make sense because EPEL is not a Red Hat project, it's a Fedora project. It provides what Fedora maintainers build. The decisions about what is in EPEL are often not Red Hat's to make.
The decision about what is in RHEL is Red Hat's and only Red Hat's to make, and the answer there is often "no". It is clear that the community has to make a pick in what gaps they are able to fill through EPEL, because there are many. Also, sometimes, EPEL cannot ship something because RHEL ships too old dependencies and Red Hat refuses to upgrade them. And if Red Hat really wants something to be in EPEL, they can simply pay someone to put it there. Especially when that something is already in Fedora, the chances that EPEL will reject the package are basically nil.
> it also states that exercising those rights automatically terminates your subscription
I think people are usually referring to sections 1.2 f and h of the Software and Support Subscriptions Product Appendix, and that is not what those sections say. They prohibit reselling or sub-licensing the subscription.
I'm not a lawyer, and I could be wrong, but at the same time I don't believe anyone knows of any customer whose contract has been terminated under those clauses. Until such an example is available, I think this is just FUD.
> It was Red Hat's and only Red Hat's decision to publish the source code in that strange form
This is only a guess, but I think they intended to make the source accessible in a way that provided incremental updates and online browsing. The process was ugly and fragile, but it did have benefits.
But that's all superficial. The real issue, from my point of view, is that the source that was published in the past was incomplete, and the source that is published now is complete. The source that was published in the past did not enable collaboration, and the source that is published now does enable collaboration. Publishing the source as src.rpm wouldn't have fixed either of those issues.
> That is the branch the developers work on
All of the branches are branches that developers work on.
> but not the branch that is shipped to users
There have always been branches that were shipped to users for which source code was not published to the public.
Why is the latest minor release the correct branch, as opposed to the latest EUS branch? What makes a minor release more desirable than the major-version branch, and why does that not make the EUS branch more desirable than the latest minor version?
> what gets shipped to subscribers is often a backport that never makes it to CentOS Stream in that form, because CentOS Stream already has a newer version of the package and the fix is applied to that one instead
Yes, I can say the same thing about the EUS branch vs the latest minor. Updates shipped to each active EUS branch are often a backport that does not appear in the latest minor release, because the latest minor release already has a newer version of the package.
None of these arguments in favor of the old CentOS Linux model are logically consistent, and none of them acknowledge that the RHEL model represents a series of compromises that affect RHEL customers differently than they affected CentOS Linux users, because CentOS Linux was a fundamentally different release model than RHEL. Without overlapping (EUS) maintenance windows, minor releases are a bug. They're bad for reliability. Getting rid of them fixes a whole bunch of issues.
The real issue, from my point of view, is that the source that was published in the past was incomplete, and the source that is published now is complete.
The source that was published in the past was the complete source code for a well-defined release channel (the latest stable minor release). The source that is published now is also complete source code for an also well-defined, but different release channel (the work-in-progress code for what will become the next minor release). In Fedora, that would be updates vs. Rawhide (and yes, of course I know that CentOS Stream is branched off Rawhide once for the whole major release of RHEL, long before the actual release, and is then much less in flux than Rawhide is, but still, for any given major release number n, CentOS Stream n relates to the RHEL n.x minor releases the same way Rawhide relates to the Fedora y releases).
The source that was published in the past did not enable collaboration, and the source that is published now does enable collaboration.
Sure, running the development branch means that it is easier to actually upstream changes, but guess what, most people who are interested in RHEL source code are not interested in that at all. They just want to run a free rebuild of already fully tested RHEL packages, with the same 10-year support period. Just look at how popular Rocky Linux and AlmaLinux are.
All of the branches are branches that developers work on.
Of course, but those were your own words: "it's the *real* branch of RHEL that Red Hat developers work on".
There have always been branches that were shipped to users for which source code was not published to the public.
And that has always been an issue. But the change did not fix that issue, it just made it worse.
Without overlapping (EUS) maintenance windows, minor releases are a bug. They're bad for reliability. Getting rid of them fixes a whole bunch of issues.
But CentOS Stream does not actually "get rid" of the minor releases, it just ships the development code from which those releases are made. Just like using Rawhide does not "get rid" of Fedora releases.
And it also causes new issues. In particular, CentOS Stream as the development version of what will become the next minor release only makes sense as long as there is a next minor release to begin with, which is only half of the RHEL life cycle. As a result, CentOS Stream gets turned off after those 5 years, leaving only half of the support time of the old CentOS ("CentOS Linux").
> The source that was published in the past was the complete source code for a well-defined release channel
No, it wasn't. It contained only the portion of the sources that were packaged in the src.rpm. It lacked all of the tests that defined most of the QA process.
You might not care about that, but when I build a modified package, I would like to be able to run the tests and validate that the changes that I've introduced do not change the behavior or stability of the package, because I believe that reliability is the product of testing.
> In Fedora, that would be updates vs. Rawhide
Fedora releases branch from Rawhide, and RHEL minor releases branch from CentOS Stream, but beyond that very superficial similarity, CentOS Stream is not similar to Rawhide.
CentOS Stream is a release branch, and Rawhide is not a release branch.
That is, Red Hat expects CentOS Stream to always be ready for branching to produce a new minor release of RHEL. In order to meet that expectation, changes must pass QA *before* they merge to CentOS Stream.
Fedora is not that strict with Rawhide. Fedora has a long period between branching and release in which changes that were merged to Rawhide but which are not release ready can be reverted.
They're totally different processes, with different expectations and different controls.
> Of course, but those were your own words: "it's the *real* branch of RHEL that Red Hat developers work on".
Yes, that's what I said, but my emphasis was on "real", not "developers" because I'm not trying to scare people into believing that Stream is bad.
CentOS Stream is built from a real branch, not a pseudo-branch produced by a Rube Goldberg process. Being a real branch enables collaboration. Being a real branch means the process is open in a way the old process was not. Some people merely want to consume and not participate, and I respect that, but a process that allows engineers to participate is better than a process that does not allow engineers to participate, regardless of whether or not you are one of the engineers that wants to participate.
That's the whole *premise* of Free Software development.
RHEL is just an upstream version of Fedora meant for enterprise use. Unlike Fedora though, RHEL is more selective about what features it bring upstream. Fedora is fairly cutting edge, RHEL will be a bit behind to ensure stability.
For pretty much any casual user, Fedora is better because it’s more up to date and it’s not bound by any weird licensing like RHEL.
I’m pretty sure for commercial use you need a license to use RHEL, like Windows. There is a free license for personal use but at that point, most people choose to just use Fedora which requires no license at all.
I believe you need to make an account with them to get a download link.
I’m not sure if you’re trying to use it on desktop but if you’re really dead set on something like RHEL, try Rocky Linux. It’s built from the same source code but it’s completely free. No license
Gnome is a desktop environment. When you say GUI, you usually mean desktop environment. Gnome and KDE are two of the most popular desktop environments on linux. Almost every distro will have specific spins that come with them, but you can also install a DE on top of another one. I have a bunch of DEs on my computer, because I was trying them all out this past year.
> I’m pretty sure for commercial use you need a license to use RHEL
No, there's no restriction on commercial use. Developers can get free licenses, but it has to be licensed to an individual, not to an organization, and their subscription will be limited to 16 hosts.
Loveangel1337@reddit
They took a perfectly good distro and gave it anxiety!!
Poor CentOS never gonna recover :'(
Ok_Second2334@reddit
Recover from what? CentOS is now way better than before and it has become a true community project.
Loveangel1337@reddit
Being ever usable in a prod system.
Unless you like your system to get updated and suddenly stop working, which I usually don't.
Like, I get it, they want people to turn to RHEL and pay them outright, they say so themselves in a blog post about replacing CentOS with CentOS Streams. Well, about not and moving to RHEL.
I'd have gone for a split model, like OpenSUSE, CentOS rolling -> CentOS stable -> RHEL.
Ok_Second2334@reddit
That is not correct. What Red Hat has done is make the development of RHEL more open than ever, while also turning CentOS into a useful distribution with a clear purpose, and maintaining stability. The new Stream model is indeed prepared to run in a production environment (Meta/Facebook is a great example), as it is the stable branch of RHEL. Any update that CentOS receives has been approved for inclusion in RHEL.
Loveangel1337@reddit
I mean, Red Hat literally has a page dedicated to "Why is CentOS Stream in prod a bad idea when migrating from CentOS 8":
https://www.redhat.com/en/resources/centos-stream-checklist
And how can you say that Stream is the stable of RHEL when it's their upstream? It was more stable when it was downstream, and sure they've approved it for RHEL, but they also release to CentOS first for a final scream test. Sure it's not Arch with nightly builds levels of stable.
But then again, if you enjoy the distro, all the power to you!
PS:
So I just read https://crunchtools.com/before-you-get-mad-about-the-centos-stream-change-think-about/, and they make quite good points.
But I feel that part of their argument in favour of Stream is: you don't use your OS anyway, just containerise everything, cloud this and docker that. Well, sure, but I don't do containers or cloud, why should I use containers to solve the issue that my OS wants to be trashable, that I need another layer of complexity, and loading another smaller OS inside. I might as well install whatever the containers are build from as my host instead...
But I guess I'm just an old asshole that hates change anyway. 🤷‍♀️
gordonmessmer@reddit
> I’m wondering if someone could shed some light on why is it dislike by the community
I think it's because Red Hat is an engineering company, and they tend to communicate like engineers. People who are not engineers tend to interpret statements from Red Hat to mean something quite different than intended, and misinterpretations lead to a lot of aggravation.
When Red Hat effectively replaced Red Hat Linux with Fedora Core, they made the distribution free-of-charge, and opened it for contributions from the community. Developers had been asking them to do that fo *years*. It was a huge improvement. But still, the most vocal reactions in the community were angry about one thing or another.
The same thing happened when Red Hat shifted their focus to CentOS Stream as a community distribution. The new process is a *huge* improvement, but a lot of people hang on to the old model because it fostered the illusion of "enterprise" readiness.
(CentOS Stream is more secure than CentOS Linux was, more reliable, its source code is more open, and it actually works like a community project, which CentOS Linux did not.)
cyber-punky@reddit
The unsaid thing re: centos stream vs centos linux is that there were gaping holes in the update timeline where you could technically go with unfixed cves for some time.
gordonmessmer@reddit
Exactly. That's what I mean when I say that Stream is more secure than CentOS Linux was. :)
Kevin_Kofler@reddit
There are so many reasons why people dislike Red Hat Enterprise Linux, some making more sense than others:
What some people would like is a distribution that is free and released every 6 months with lots of recent software, like Fedora, but supported for 10+ years, like RHEL. Of course, that is not going to happen for both financial and technical reasons.
gordonmessmer@reddit
As you said, some of these don't make sense. The reason that some of them don't make sense might not be obvious to all readers.
> the subscription terms prohibit their redistribution
This dosn't make sense, because the subscription specifically states that it does not limit any rights granted by the license. What it does prohibit is providing third parties access to Red Hat's support services.
> the recent decision to stop publishing source code to non-subscribers
This doesn't make sense because at any given time, there are up to 5 actively maintained branches of a RHEL major release. Historically, Red Hat published a sub-set of the code, of just one of the active branches at a time. The code they published was not the input to their build process, but a build artifact... an output of their build process. A fragile "Rube Goldberg"-esque process transformed those artifacts into something that looked like a git branch, but which was unusable for collaboration.
Today Red Hat publishes just one branch (the major-version branch) as they always have, but it's the *real* branch of RHEL that Red Hat developers work on. It's complete, and provides the bits that were missing from the old process. You can collaborate with RHEL through standard processes like Merge Requests in GitLab.
> the embrace-extend-extinguish they did to CentOS, buying out the project, then discontinuing it,
This doesn't make sense because they haven't discontinued CentOS, they've improved it.
https://medium.com/@gordon.messmer/in-favor-of-centos-stream-e5a8a43bdcf8
> the fact that even EPEL does not provide everything RHEL has left out
This doesn't make sense because EPEL is not a Red Hat project, it's a Fedora project. It provides what Fedora maintainers build. The decisions about what is in EPEL are often not Red Hat's to make.
I know that you know these things, but I hope this helps some readers who are less familar with the process.
Kevin_Kofler@reddit
But it also states that exercising those rights automatically terminates your subscription, so you can only do that once in a lifetime, which, considering that the software constantly gets updated, defeats the point of the license, and of the subscription.
It was Red Hat's and only Red Hat's decision to publish the source code in that strange form (with the claim that it made it easier for (the original) CentOS to work with it) instead of the SRPMs that had been shipped in the past and that nobody ever complained about.
That is the branch the developers work on, but not the branch that is shipped to users, which is the one most people actually care about. Especially for security fixes, what gets shipped to subscribers is often a backport that never makes it to CentOS Stream in that form, because CentOS Stream already has a newer version of the package and the fix is applied to that one instead. Also, due to embargos (and due to having to do the work twice due to differing package versions), fixes sometimes only make it into CentOS Stream days after they are shipped in RHEL.
LOL, just like all that processed food with "improved" recipes where they replaced some premium ingredient with a cheap low-quality substitute.
The decision about what is in RHEL is Red Hat's and only Red Hat's to make, and the answer there is often "no". It is clear that the community has to make a pick in what gaps they are able to fill through EPEL, because there are many. Also, sometimes, EPEL cannot ship something because RHEL ships too old dependencies and Red Hat refuses to upgrade them. And if Red Hat really wants something to be in EPEL, they can simply pay someone to put it there. Especially when that something is already in Fedora, the chances that EPEL will reject the package are basically nil.
gordonmessmer@reddit
> it also states that exercising those rights automatically terminates your subscription
I think people are usually referring to sections 1.2 f and h of the Software and Support Subscriptions Product Appendix, and that is not what those sections say. They prohibit reselling or sub-licensing the subscription.
I'm not a lawyer, and I could be wrong, but at the same time I don't believe anyone knows of any customer whose contract has been terminated under those clauses. Until such an example is available, I think this is just FUD.
> It was Red Hat's and only Red Hat's decision to publish the source code in that strange form
This is only a guess, but I think they intended to make the source accessible in a way that provided incremental updates and online browsing. The process was ugly and fragile, but it did have benefits.
But that's all superficial. The real issue, from my point of view, is that the source that was published in the past was incomplete, and the source that is published now is complete. The source that was published in the past did not enable collaboration, and the source that is published now does enable collaboration. Publishing the source as src.rpm wouldn't have fixed either of those issues.
> That is the branch the developers work on
All of the branches are branches that developers work on.
> but not the branch that is shipped to users
There have always been branches that were shipped to users for which source code was not published to the public.
Why is the latest minor release the correct branch, as opposed to the latest EUS branch? What makes a minor release more desirable than the major-version branch, and why does that not make the EUS branch more desirable than the latest minor version?
> what gets shipped to subscribers is often a backport that never makes it to CentOS Stream in that form, because CentOS Stream already has a newer version of the package and the fix is applied to that one instead
Yes, I can say the same thing about the EUS branch vs the latest minor. Updates shipped to each active EUS branch are often a backport that does not appear in the latest minor release, because the latest minor release already has a newer version of the package.
None of these arguments in favor of the old CentOS Linux model are logically consistent, and none of them acknowledge that the RHEL model represents a series of compromises that affect RHEL customers differently than they affected CentOS Linux users, because CentOS Linux was a fundamentally different release model than RHEL. Without overlapping (EUS) maintenance windows, minor releases are a bug. They're bad for reliability. Getting rid of them fixes a whole bunch of issues.
Kevin_Kofler@reddit
The source that was published in the past was the complete source code for a well-defined release channel (the latest stable minor release). The source that is published now is also complete source code for an also well-defined, but different release channel (the work-in-progress code for what will become the next minor release). In Fedora, that would be updates vs. Rawhide (and yes, of course I know that CentOS Stream is branched off Rawhide once for the whole major release of RHEL, long before the actual release, and is then much less in flux than Rawhide is, but still, for any given major release number n, CentOS Stream n relates to the RHEL n.x minor releases the same way Rawhide relates to the Fedora y releases).
Sure, running the development branch means that it is easier to actually upstream changes, but guess what, most people who are interested in RHEL source code are not interested in that at all. They just want to run a free rebuild of already fully tested RHEL packages, with the same 10-year support period. Just look at how popular Rocky Linux and AlmaLinux are.
Of course, but those were your own words: "it's the *real* branch of RHEL that Red Hat developers work on".
And that has always been an issue. But the change did not fix that issue, it just made it worse.
But CentOS Stream does not actually "get rid" of the minor releases, it just ships the development code from which those releases are made. Just like using Rawhide does not "get rid" of Fedora releases.
And it also causes new issues. In particular, CentOS Stream as the development version of what will become the next minor release only makes sense as long as there is a next minor release to begin with, which is only half of the RHEL life cycle. As a result, CentOS Stream gets turned off after those 5 years, leaving only half of the support time of the old CentOS ("CentOS Linux").
gordonmessmer@reddit
> The source that was published in the past was the complete source code for a well-defined release channel
No, it wasn't. It contained only the portion of the sources that were packaged in the src.rpm. It lacked all of the tests that defined most of the QA process.
You might not care about that, but when I build a modified package, I would like to be able to run the tests and validate that the changes that I've introduced do not change the behavior or stability of the package, because I believe that reliability is the product of testing.
> In Fedora, that would be updates vs. Rawhide
Fedora releases branch from Rawhide, and RHEL minor releases branch from CentOS Stream, but beyond that very superficial similarity, CentOS Stream is not similar to Rawhide.
CentOS Stream is a release branch, and Rawhide is not a release branch.
That is, Red Hat expects CentOS Stream to always be ready for branching to produce a new minor release of RHEL. In order to meet that expectation, changes must pass QA *before* they merge to CentOS Stream.
Fedora is not that strict with Rawhide. Fedora has a long period between branching and release in which changes that were merged to Rawhide but which are not release ready can be reverted.
They're totally different processes, with different expectations and different controls.
> Of course, but those were your own words: "it's the *real* branch of RHEL that Red Hat developers work on".
Yes, that's what I said, but my emphasis was on "real", not "developers" because I'm not trying to scare people into believing that Stream is bad.
CentOS Stream is built from a real branch, not a pseudo-branch produced by a Rube Goldberg process. Being a real branch enables collaboration. Being a real branch means the process is open in a way the old process was not. Some people merely want to consume and not participate, and I respect that, but a process that allows engineers to participate is better than a process that does not allow engineers to participate, regardless of whether or not you are one of the engineers that wants to participate.
That's the whole *premise* of Free Software development.
Time_Way_6670@reddit
RHEL is just an upstream version of Fedora meant for enterprise use. Unlike Fedora though, RHEL is more selective about what features it bring upstream. Fedora is fairly cutting edge, RHEL will be a bit behind to ensure stability.
For pretty much any casual user, Fedora is better because it’s more up to date and it’s not bound by any weird licensing like RHEL.
Leading_Jury_6868@reddit (OP)
Thanks but what do you mean by weird licenseing
Time_Way_6670@reddit
I’m pretty sure for commercial use you need a license to use RHEL, like Windows. There is a free license for personal use but at that point, most people choose to just use Fedora which requires no license at all.
Leading_Jury_6868@reddit (OP)
I can’t find the download for rhel on there website
Time_Way_6670@reddit
I believe you need to make an account with them to get a download link.
I’m not sure if you’re trying to use it on desktop but if you’re really dead set on something like RHEL, try Rocky Linux. It’s built from the same source code but it’s completely free. No license
Leading_Jury_6868@reddit (OP)
Dose it have a gui or only a command line also useing for a server
Time_Way_6670@reddit
By default it’s GNOME. I think there is also a server version which is just command line.
Leading_Jury_6868@reddit (OP)
Why don’t Thay come with a gui
mattias_jcb@reddit
Like they said RHEL comes with GNOME.
Leading_Jury_6868@reddit (OP)
What is Gnome
Albend@reddit
Gnome is a desktop environment. When you say GUI, you usually mean desktop environment. Gnome and KDE are two of the most popular desktop environments on linux. Almost every distro will have specific spins that come with them, but you can also install a DE on top of another one. I have a bunch of DEs on my computer, because I was trying them all out this past year.
ABotelho23@reddit
Wow, please for god sake learn to use a search engine.
Leading_Jury_6868@reddit (OP)
Get a girlfriend
ABotelho23@reddit
How original.
mattias_jcb@reddit
See https://gnome.org
jebuizy@reddit
Servers never come with a gui. Why would you need one?
Time_Way_6670@reddit
You can install the GNOME version on the server if you’d like. I don’t think there is a big difference.
No_Rhubarb_7222@reddit
“server with gui” is the default installation package set.
https://developers.redhat.com/register
gordonmessmer@reddit
Start here: https://developers.redhat.com/articles/faqs-no-cost-red-hat-enterprise-linux
gordonmessmer@reddit
> I’m pretty sure for commercial use you need a license to use RHEL
No, there's no restriction on commercial use. Developers can get free licenses, but it has to be licensed to an individual, not to an organization, and their subscription will be limited to 16 hosts.
Time_Way_6670@reddit
I didn’t know, thank you for letting me know
cgoldberg@reddit
Fedora is the "upstream" for RHEL.
Time_Way_6670@reddit
Whoops got the terms mixed up. My bad