Red Hat announces no-cost RHEL for small production environments
redhat.com
redhat.com
Especially given that they won't make any commitments to long term availability beyond "we have no intent".
https://arstechnica.com/gadgets/2021/01/centos-is-gone-but-r...
>We have no intent to end this program and we’ve set it up to be sustainable
I can't imagine this will sell many people much less attract former CentOS users. Given the fact that they've changed course so quickly on CentOS stream I can't imagine there's much good user faith to go around.
To me, this was much bigger than just a shot in the foot.
Besides, I've had a RHEL developer account (which allowed me to register 16 hosts) for a few years now and it's been unused. Having to request it be renewed annually is a pain in the ass too.
If you don't like Debian, pick an open source distribution that is not backed by a business and begin sending the money you would've dumped into subscriptions as donations.
Despite Debian being phenomenal in many ways, it doesn't offer up a head for the chopping block to replace yours if things go wrong in a corporate application. Good luck getting IT folks to deploy anything that doesn't offer them an out.
Using CentOS knowing that it is downstream from RedHat but that RedHat would step up and fix things in a semi-timely manner was good enough for many enterprises....at least until IBM got involved.
Ubuntu is also a weird choice generally speaking because Ubuntu just uses Debian's testing repo as a base and really only significantly varies in the kernels that they roll for various products/services.[cloud,live patching,etc.] They used to maintain their own desktop[Unity] and service management[upstart] and a bunch more variances from Debian...but that ain't really the case today.
https://threatpost.com/how-debian-openssl-bug-almost-spawned...
Here's the mailing list email that inspired the bug:
https://marc.info/?l=openssl-dev&m=114651085826293&w=2
I kind of doubt that some guy that thinks he "knows better than the OpenSSL developers" is saying things like this on their mailing list:
> What I currently see as best option is to actually comment out those 2 lines of code. But I have no idea what effect this really has on the RNG. The only effect I see is that the pool might receive less entropy. But on the other hand, I'm not even sure how much entropy some unitialised data has.
The result was something like 32k sources of entropy which is not enough.
Here's the bug Kurt was trying to fix: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=363516
I was always a little confused by how popular Ubuntu became. Canonical never did much to add value, often replacing more standard tools with strange canonical replacements that didn't survive the test of time.
If you use Ubuntu now, give Debian a try. The stability and community are really second to none. For all my personal use I run Arch, but I would not hesitate to run Debian in production instead of a commercial distribution.
By comparison I never fully understood the Debian versioning story. I have no idea when the next version will become stable, or how stale the versions are in stable, whether I could install it without driver issues on my desktop, etc.
With Ubuntu I could take a break for a few years and know there will be an LTS release in April or 2022, that the previous LTS release was 20.04, and 18.04 was the one before that, etc. That each will be supported for 5 years and so on.
When I started using Linux a couple decades ago, "we ship when it's ready" was the dominant FOSS approach, and I thought it was the most sensible approach.
Then I got my first job and experienced the realities of enterprise support and planning. Today I wish more projects were as predictable as Ubuntu, and I'm gratefully for every one that is.
Ubuntu is far from my favorite distro technically, but the predictability of its LTS releases makes it my recommendation for most uses.
I think if debian augmented the toy story names with dates, that might help.
Before that I was on FreeBSD, and before that I was in Slackware. All were always fine
What does “difficult to install” even mean?
Besides, last time I ran a GUI on linux was probably over 20 years ago.
Stable is too stable for the average desktop user - often kernel is missing drivers for newer hardware models, or system libraries are too old for newer applications.
Testing works most of the time but is not stable enough. Most recent example; zfs, which is on 0.8.x, is completely broken in testing since the kernel upgrade to 5.10 in December. zfs has not (and prob will not) backported 5.10 compatibility to 0.8.x. Last I heard, the Debian maintainers were still not decided on if they are going to backport the 5.10 fix to their own fork of zfs 0.8.x, or if they're going to do the upgrade to zfs 2.0 already.
I had a couple of servers where I had stupidly enabled unattended-upgrades, which broke the filesystems and required recovery to make services start again. Annoying, but it was my mistake.
This kind of situation is completely expected and there's really no one at fault. But it is a good example of why vanilla Debian is not suitable for many users and use-cases. Mint does seem like a better Ubuntu, though.
They do not have the time and resources to figure out every inevitable configuration, and they end up supporting a mishmash of unsupportable software.
Backported ZFS just brings fear in my eyes, these filesystems have to have many decades of testing before people are comfortable with it, and Debian finds it acceptable to make a custom patched version. Not cool.
If you want to store all your data on that configuration then by all means, but I'm afraid I won't run a distro that plays games to avoid changing a version number.
> the backporting part was just hearsay that it was under debate
I guess if it is just hearsay then thats something else. Does Debian have guidelines about what they wouldn't backport?
They employ a number of people who maintain core Debian packages to work on Debian packaging full time and generally to land improvements in Debian.
I do agree that Canonical never did much to add value to Ubuntu beyond what they added to Debian, but they certainly added value to Debian, and ironically you don't even need use their distro for that, let alone pay them!
Second, it would be nice if the package manager had an actual database behind it capturing everything that the rpmdb does. Instead you have a flat file with some of the data in it, and log files with other data (where the log files can be rotated out eventually). I want to be able to do things like "rpm -qa --last" on Debian. Or "yum history".
How difficult would it be to write a version of the apt suite of tools that uses an sqlite db? Would that break other items in Debian? It sounds like an interesting project to take on.
https://wiki.debian.org/Teams/Dpkg/RoadMap https://wiki.debian.org/Teams/Dpkg/Spec/MetadataTracking
Personally I vastly prefer the flat file version, it is much easier to inspect and modify and maybe less likely to get corrupted.
I wish Linus had veto'd the binary logfiles of systemd.
How is that as useful to you personally as a support subscription? You can't replace a support contract with wishful thinking and a donation.
It's great to support open source projects, but lets not mix concerns here.
"Software in the Public Interest, Inc. is a tax-exempt non-profit corporation based in the United States of America, founded by Debian people in 1997 to help free software/hardware organisations."
It owns the various Debian trademarks, etc.
You can argue that Ubuntu provides a counter model to RHEL where only services and select products require a subscription but the OS is otherwise free.
https://wiki.debian.org/Teams/Treasurer/Organizations https://wiki.debian.org/Teams/DPL/TrustedOrganizationCriteri...
If you pay for software, like we do in VFX/Animation, then RHEL is basically the standard and what's supported best.
^ This is what I have been told by my older colleagues; I wasn’t around for this. My current employer danced around with RHL and Fedora Core before moving to CentOS 6 (now 7, and looking at what to do with 8). Pretty much all studios using Linux in this industry are running RHEL/CentOS, with a very small handful operating on Ubuntu. Home users will do whatever they want and deal with whatever incompatibilities arise ;)
While most hobby level video software is targeted at windows or Mac, the truly powerful stuff (houdini, maya, nuke, blender) are first class citizens on Linux. Currently one of the few artist programs that aren't available for Linux is the adobe suite which is mostly used by editors (for timelines) and photo editing (for promotional material) and most of that happens on Macs, usually in the editing department.
Something to keep in mind is that many VFX shops are kind of specialized and will work on very specific portions of a movie or TV show. For example, the company that owns the final product (Disney, Fox, MGM, etc) will pay company A to shoot the movie, then company A will send the footage for a 30 second scene to company B to rotoscope everything, then it gets sent to company C for VFX elements, then to company D for 3d conversion, then to company E for lighting and finally to company F for audio and final stitching. This is repeated (often with different companies A-F) for each scene since different scenes required different levels of expertise in different areas such as crowd generation, fire simulation, raindrop removal (yes, it's as painful as it sounds), background replacement, CG helicopters, etc. Because of this, the few steps that require windows are typically handled by 1 or 2 companies so the rest only need enough Mac/Windows machines for their local editors to stick timelines together for daily reviews.
An interesting side effect of the above is that almost every company you see in the credits of a movie had no idea what the dialog was because audio is one of the last things that gets added and completely bypasses 90% of the VFX houses involved.
People tried selling Enterprise Support for Debian back even before Red Hat went commercial, if I remember correctly, but somehow Red Hat timed their effort right and became the defacto replacement for UNIX in these environments.
https://www.debian.org/support https://www.debian.org/consultants/
Ubuntu, Red Hat and SUSE are owned by companies. That ownership is more than just trademarks. The own the trademark and are the sole decision makers.
Personally, I used to support a $25m/yr business on a cluster of Debian servers, which itself supported about 1000 remote field installations, also running Debian.
Let me tell you, Debian was the least of my troubles in that job. It really did just work
Updating a personal server every 6 months may be easy, but in a mature business it often makes sense to wait 5 years or more before upgrading certain infrastructure so that time and effort can be invested in other areas instead.
The days of having a fleet of servers that were carefully hand-crafted and evolved over the years are hopefully coming to a close.
Second, this is only of value to the teeny tiny companies and individual users with a single server in their home. Small companies with any expectation of growth should probably just use Rocky instead from the get go.
I have a single server in my home running CentOS 7. I gain nothing by using RHEL over Rocky in the future, except with RHEL I have to accept ToS, do some subscription checks, and run the risk that Red Hat cancels this programme down the road. I only see this of value for someone who actually runs real RHEL in prod, and needs to test/validate hardware/software. For anyone just wanting 'free' RHEL, they should just use Rocky.
It probably wont be completely broken and useless, but they replaced a stable OS with a beta, which is particularly galling to many users who picked that OS specifically because it was so stable.
Just trying to see how you define "beta"
Slightly detached because of their processing/release process (Fedora X never quite matched to RHEL Y even if there was some derivation), but yes, Fedora is absolutely the alpha for RHEL. It gets changes, including breaking changes, on a fast track (IIRC, Fedora frequently goes toe-to-toe with Arch for having the most recent packages), has a 13-month lifecycle with a strong expectation that you'll `dnf system-upgrade` regularly, and doesn't shy away from pushing on tech that they believe to be desirable even if it's not (yet) widely used (Wayland, BTRFS, CGroupsV2).
> Did you consider RHEL to be a beta for CentOS previously?
Now that's an interesting point that actually makes me stop and consider:) It is true that previously CentOS could legitimately claim to be even more stable/slow-moving than RHEL. I think the distinction that I would make is that RHEL had its own betas that were called betas, and that each point release was frozen/stable until the next one came along, while Stream is explicitly unfrozen all the time. So yes, I suppose a person could have described RHEL as CentOS's beta, although probably only jokingly because it still had Red Hat supporting it and feature freezes to control changes.
The benefit of Fedora was that they handled a lot of things that were a pain to configure. The biggest culprit being fonts. But now that TrueType patents have expired, and it's included in Arch automatically it's one less reason to use Fedora.
The point is that with CentOS you expect a super stable release. Red Hat replaced that with what is clearly a less stable project. And as was said before, if you used CentOS, it's probably precisely because you want something super stable with long term support. Those are not the sorts of users who'll want to use Stream.
CentOS Stream seems like "Fedora, again" and does not do what CentOS did. And now, the willingness to blow up CentOS with so little warning means there is a massive trust deficit here.
More generally, orgs that are running "Enterprise" software are already set up to pay for software. Going from spending $X to spending $X+Y is often not a big deal ("Ok, I'll run that through the same process I used to get approval for buying FooSoftWorks"), while going from $0 to $Y can be very hard ("I don't even know who I'd need to ask to get purchase approval for that").
Except when $Y == $1000X. Then it really is a big deal.
When you only have a tiny minority of RHEL hosts that you have full support contracts on, and an overwhelming majority of CentOS hosts that you administer in-house, it really isn't trivial.
It's almost certainly cheaper to migrate to Oracle or Rocky. Migrations aren't cheap either.
Crucially, though, most entities who are running their own "enterprise" software deployments will need way more than 16 servers.
Small shops do use "enterprise" software, of course, but they usually just pay somebody else to run it for them.
Red Hat offers a "no support" server license for $350/year, which is the lowest licensing tier. Tiers with more capability and support are available for $800, and $1300.
https://www.redhat.com/en/store/red-hat-enterprise-linux-ser...
Oracle has a larger range of tiers. The "no support" license is $120/year. Tiers with more capability and support are available for $500, $1200, $1400, and $2300.
Oracle Linux can be used in production without a paid license of any kind; Red Hat Linux cannot be used in this way for large deployments (excepting the new 16-seat license for a developer account).
Red Hat is aggressive with software audits; I have seen one.
Both Oracle and Red Hat now have complete toolsets to convert support between an installed CentOS/RedHat/Oracle OS.
Red Hat can now convert an installed CentOS or Oracle Linux to RHEL; previously a wipe and reinstall was required ("have fun reinstalling your system" is still on Oracle's CentOS site). The description looks much more thorough in replacing all possible packages with Red Hat versions:
https://access.redhat.com/articles/2360841
Oracle does not replace CentOS or RedHat RPMs in their conversion (AFAIK), so it is much less violent on the platform changes.
https://github.com/oracle/centos2ol
https://linux.oracle.com/switch/centos/
https://blogs.oracle.com/linux/reasons-for-switching-centos-...
Apologies if a dumb question, but I assumed CentOS 8 was a clone of RHEL 8. What would change?
If memory serves, the process consists of, basically, installing the <distro>-release package for the "new" distro (which includes the files in the /etc/yum.repos.d/ (or whatever) directory that defines the package repositories), enabling the repositories it just added, disabling the "old" distribution's repositories, then running a "yum update" to replace the "old" distributions packages (including the kernel) with the (nearly identical) ones from the "new" distribution. After all that is done, you reboot the host so that the new kernel is loaded and that's pretty much it.
Mostly out of curiosity, I tried out Oracle's "centos2ol.sh" (or something like that) script ~8 years ago on a new CentOS 6 VM I had set up for just that purpose and it was as easy as they claim that it is. I don't recall encountering any issues and I suspect that, by now, they've ran into most of the potential issues and have devised ways to resolve them automatically.
Note that while CentOS 8 is a clone of RHEL 8, the CentOS packages are rebuilt versions of the RHEL ones. Most of them are built from the exact same source code but some packages do have minor changes made to them before they are rebuilt (for trademarks, etc.).
When switching the provider of package updates, the old repository must be disabled, and a new one substituted, among other changes that the new provider requires to switch support.
Oracle makes (by default) modest changes for such a switch. Red Hat essentially rewrites your whole operating system, and has added a warning that consultants should be retained for such conversions in case of trouble.
At the end of the day, you are looking for a free distro and this is what you can get. If you want a guarantee, pay for a contract. You have the right to sue if it is broken.
Edit: grammar.
Pay for RHEL, use CentOS 7, or switch to Ubuntu.
Is the difference that RHEL does subscription checks so they don't need to audit customers so much?
In terms of open source contributions, RH certainly do more, but Oracle are no slouch. They're doing actually exciting stuff with GraalVM and I don't really remember the last time I saw Red Hat do anything describable as research, their Java stewardship has been pretty responsible, they publish quite a lot of useful tools and stuff.
> First, they should have announced this when they killed CentOS.
I agree.
>Second, this is only of value to the teeny tiny companies and individual users with a single server in their home. Small companies with any expectation of growth should probably just use Rocky instead from the get go.
Without saying too much - stay tuned for further announcements.
It's a horrible way to treat users.
They aren't paying customers, so whatever for RH short-term bottom line. But amount of community backslash approach like that is bringing can have negative long term impact.
RH pulled the rug from under the people, and is telling them to stay tuned. I wouldn't base my infra on a system like that.
But that's good for overall Linux community - RH has way too much power there.
The need to expand the developer program into production seats could not have been anticipated.
I don't know of any other vendor that wraps developer accounts into production licenses.
Notice that this access is in no way promised to the end of support for RHEL 8.
I will say again, Red Hat has terminated two major Linux platforms over the last two decades - the original Red Hat Linux, which was terminated at v9, and now CentOS.
Oracle has "somewhat" terminated a Linux platform, Oracle Linux for SPARC, which was only supported for two minor releases. Oracle Linux for ARM64 and AMD64/x86 seem reasonably healthy.
There is other baggage in and between these corporations, but the track record on Linux OS platforms between these two is demonstrably different.
The free converters between them should be used fluidly.
I don't follow. Are you suggesting that RH actually didn't realize that people were running CentOS at scale in production?
I might be misreading these motivations.
With this management perspective, the CentOS community reaction to the retraction of the end of life date, and potential reduction in stability, was likely not anticipated.
CentOS streams is literally RHEL with fixed major version and rolling minor versions. So, in the past, you got CentOS 7.1, then 7.2, etc., with streams, you get CentOS 8.x.
Saying that this is moving away from RHEL stability sounds highly disingenuous. Are you saying you've seen RHEL 7.X to break as opposed to 7.(X-1) version, and your solution was to wait for RHEL 7.(X+1)?
Are we not reading this correctly? If not, could you get Red Hat's CTO to retract this [mis]information?
'Another official part of it is, as [Chris] Wright [RedHat CTO] said, is that CentOS Stream as a "rolling preview" of what's next in RHEL, both in terms of kernels and features can be used in today's containerized, cloud-native IT world.'
https://www.zdnet.com/article/why-red-hat-dumped-centos-for-...
> Saying that this is moving away from RHEL stability sounds highly disingenuous.
If it were so great, they'd do the same for paying customers. That they don't move RHEL to being just 8.X makes me think that Red Hat does in fact understand that that undermines the stability of the platform.
It’s funny how everyone still says Red Hat when we mean IBM.
It doesn't matter much to me anymore, I've already migrated my small business internal server that was running Centos 7 to Debian. We had basically just a fileserver, FTP box, and a couple VMs for some time clock, wiki, and building security systems, so nothing we were running yet was CentOS specific.
But in case it can be useful to you, please share with your team that the writing they're putting on the wall looks pretty bad. Knowing I'd have to update eventually, I just took the safe option, which is no longer any distro controlled by Red Hat. I didn't want to leave our server in a state where we could be building dependencies on a platform that was likely to be pulled out from under us, and while RHEL isn't too expensive to just buy for one server, and we might have qualified for something free or something you've not yet announced, my test was surprisingly painless and the migration was easier than I anticipated.
RedHat seems to forget the for the majority of CentOS users STABLITY was the driving factor in the choice to use CentOS.
I am not sure what internal metrics they have, or if I am missing a glaring use case somewhere but from where I sit RedHat seems to completely miss the boat as to who is using CentOS in the real world.
I want STABLE UNCHANGING SECURE systems, not the latest and greatest features, or some new shiny "cloudy" technology...
When your house is on fire, and you have a very short time to save your prized possessions, haste easily leads to observable contradictory actions.
as a peace offering to prevent mindshare from fleeing the redhat ecosystem, i am underwhelmed. i don't think that redhat really realizes yet how cheesed off this made a lot of people.
being shrewish about money is one thing; we can deal with that (see: oracle, IBM). it's really the complete unpredictability and how arrogantly hamfisted this centos debacle was. I can put up with a lot of shit in my job, but what i especially don't like or need is more unreliable unpredictable shit.
It’s possible they could choose to restart work on Scientific Linux, but nothing has been announced yet.
>CERN and Fermilab acknowledge the recent decision to shift focus from CentOS Linux to CentOS Stream, and the sudden change of the end of life of the CentOS 8 release. This may entail significant consequences for the worldwide particle physics community. We are currently investigating together the best path forward. We will keep you informed about any developments in this area during Q1 2021.
https://news.fnal.gov/2020/12/joint-cern-fermilab-statement-...
It's obvious in retrospect that their intention was to pull this when they acquired the CentOS project - plotting to turn CentOS into a RHEL on-ramp while dressing it as an embrace of the community feels like a kick in the groin.
Also, 16 servers is barely enough for tech companies caught by this, and is less of a good will gesture, and more subscription growth hacking.
The value of going through a company is that you can choose to write a check to Canonical or RedHat and say “I’m hitting this issue with the software you repackaged, here is money, fix the problem”. There’s no similarly direct pay-to-win for Fedora or Debian. You can shop around for a consultancy or engineer and pay them to try to debug the issue, but they’re always going to be coming in as a 3rd party, which has an impact on the levers they can pull to resolve an issue.
Except for software that was written in-house or the packaging itself, RH or Canonical would also always be coming in as a third party.
... whereas your consultant might be the original author of the upstream code.
Oh! I didn't realize Red Hat had hired RMS. :-/
Setting aside the controversial nature of those three specific projects (and the fact that this statement is demonstrably false), this statement demeans the contributions of thousands of coders, even from before Linux existed.
(let alone before Red Hat was a gleam on Bob Young's head.)
Source: Formal Red Hat packager working on Fedora.
Were are the volunteers for Sony and Nintendo console OSes, Android, ChromeOS, Fuchsia, IBM i, IBM z/OS, INTEGRITY, QNX,Unisys ClearPath, Solaris, HP-UX, Aix, vxWorks.....?
Those listings are required by the license.
Also they aren't Linux or BSD derivatives, rather their own OSes.
Nevertheless for me that is not a replacement for what CentOS was: easy to deploy for small or personal projects without requiring registration/sign-up and you could leave it (mostly) alone for 10 years or so. Though for now I'm fairly happy with CentOS Stream, we'll see where it goes.
Like... sorta? On the other hand, they went on the record saying that they would support CentOS 8 through 2029 [0], so I think it's reasonable to be unhappy with them for going back on that even in the absence of a monetary relationship.
[0] https://web.archive.org/web/20201101131417/https://wiki.cent...
So while this is disruptive and bound to be upsetting, Red Hat are still being quite generous with their new offerings. And as far as I know, they are not standing in the way of CentOS replacements such as Rocky[0] or Lenix[1].
[0] https://rockylinux.org/ [1] https://www.projectlenix.org/
Once the unfortunate decision was made to shut down CentOS, it would be very nice if the public outrage was tempered with a little appreciation for the 6 years of support that Red Hat gave to it, and also an appreciation for the new options for free access to RHEL they are providing.
People seem awfully entitled in their outrage.
That's the cost of building a product on GPL2 licensed software.
The CentOS project itself wasn't started by Red Hat. It was given to them with the expectation that they would be good stewards of it. In killing its core mission, they haven't been.
EDIT: Clarify sentence.
Are you claiming they are in violation of the GPL license? I believe they still are 100% in compliance.
> The CentOS project itself wasn't started by Red Hat. It was given to them with the expectation that they would be good stewards of it. They haven't.
They stepped in to stewardship of the product quite naturally, with the full backing of the previous stewards. Nobody was forced into that agreement. It wasn't given to them as a gift, Red Hat has sponsored the project for the last 6+ years. The fact that you disagree with the direction it has since gone, does not mean it's wrong. It may be the difference between having something more modest, and having nothing at all.
And if you want something closer to the original CentOS check out:
Which was created by the CentOS founder.
I'm not, they are indeed compliant, and Red Hat is not obligated to directly maintain CentOS. They are only obligated to provide the source to customers under the terms of the GPL.
However, if Red Hat no longer wants to maintain CentOS in the spirit in which it was founded and taken over, I'd argue the ethical thing to do would be to spin the project back out of Red Hat.
>That's the cost of building a product on GPL2 licensed software.
You are only entitled to the GPL code if it is distributed to you (as in you are a customer).
Yes, they covered home users, and probably decided to take the hit on the few tens of thousands of small businesses buying a $1k or so of subscriptions a year (and not via Dell/HP/etc). Which probably wasn't even a hit once they factored in the weight of having account managers, and the like looking at a tiny $1k a year deals.
But it completely ignores the "build our product on centos" appliance market that existed. As well as a few others that might have shipped fairly significant volumes, but never wanted/needed support or did their own product+linux support as part of their general support channel. Yes, various hyperscalers were doing that and rebranding their own modified versions but that was more an error on the part of RHEL to fail to listen to those users anyway.
Basically RH has consistently failed to understand that centos was the "OEM/toolkit" version of RHEL for a lot of pretty serious organizations.
They seem to have some company blindness about answering specific technical pre-sale questions with "I will have X call you." and that call never ever comes. So the next person calls you and you ask again and the cycle repeats.
They are another company that likes you to go through partners and some of their partners aren't exactly quick about it.
As an example, I wanted to set up kerberos. Red Hat had a guide on setting up IdM, covering every step in the process, often with two alternates depending on desired final state and having an intro paragraph to choose between them, full command line docs for every command ran, steps to test this was ran correctly, and troubleshooting steps for commonly-encountered errors. In contrast, the Ubuntu docs for setting up a IdM client were a wiki, half of which was for the old version, and a detailed stackoverflow response. Server and client setups took the same amount of time; the client should have been much faster.
I would at least say it is more consistent, without having a split between the man and info commands.
2. First-class support for systemd. Well, I'm not sure that's a fair point.. But with Debian I'm always seeing some messages about sysv scripts, even when I'm using systemctl. It feels like some scripts were not fully ported to systemd or something like that. Some people don't like systemd, but I, personally, think that it's a good solution. AFAIK systemd development is sponsored by Redhat and its support is very good, all services are shipped with proper systemd units.
3. First-class support for NetworkManager, Firewalld. I think that those packages are available for Debian, but it's nice to have them installed and configured from the start, they're very convenient to use.
4. Documentation. Most of that documentation is hidden behind loginwall, but http://access.redhat.com/ contains plenty of information.
There are some drawbacks of RHEL. The major one for me is limited software selection. You need to enable EPEL even for some basic software like Strongswan, Certbot or OpenDKIM. And EPEL is not RHEL (although it's quite good).
For anyone who might be interested in Fedora-family, namely systemd, SELinux, and firewalld bits I am writing a book now about deploying with Fedora and CentOS Stream[0] and I am almost finished. With this announcement I might add RHEL support directly - the difference is just in running a subscription manager.
Also, if you are using Vagrant, you can use RHEL with a vagrant-registration plugin that automatically subscribe you (disclaimer: I made the plugin when working for Red Hat and packaging Vagrant for Fedora).
This is changing with CentOS Stream. Bugs can be filed against CentOS Stream in the Red Hat Bugzilla and they will do something with that bug report. Additionally, if you know what to backport to fix it, you can submit pull requests on any package in CentOS Stream to have it reviewed and merged to fix your issue. The fix would then be built and released within days of merging your fix.
From my perspective, that's pretty golden for an Enterprise Linux platform. The only other that's like that is openSUSE Leap/SUSE Linux Enterprise.
To summarize, the RHEL model of releasing an OS every 5 years with these staggered upstreams is really not that great. It creates immense inertia and pain down the road. RedHat itself hasn't been able to port its own offerings like Satellite to RHEL 8. I would rather have the Ubuntu cadence of LTS releases every 2 years so that you are at most 2 years away from any fixes you need.
Matthew Miller (@mattdm) tweeted out the "Fedora->RHEL formula": https://twitter.com/mattdm/status/1349037318200561665
Last workplace had a storage array. Tested on Red Hat, supported on Red Hat. The same is true for lots of other things. Enterprise databases, drivers for hardware, CAD software, that sort of stuff.
Once you have it in place, you are guaranteed not to have to change it a decade. All security fixes is backported. They also vet upstream changes to minimize nasty surprises. You do pay handsomely for the privilege.
Additionally the length of support, Ubuntu LTS gets close but RHEL will sell you support FOREVER.
A question is whether that is truly positive. A long cycle means that each update becomes a project in itself disrupting whatever else you are doing. (After 10 years so many things changed everywhere, that you need to bring so many things together ...) With frequent updates it is part of the ongoing process.
(And yes, there are cases for which one can make an argument)
Looking at Red Hat's customer list, most of them are based in finance, transportation, retail, hotel, and other such sectors.
Looking at Debian's statistics of use per sector, the plurality is companies that develop computer software, though retail comes second, but after that it's i.t. again.
This is primarily the difference and the gap that RHEL attempts to bridge through it's extensive inclusive support, which is what one is really paying for. The target of RHEL has never been i.t. companies.
- Installing a package on RH is always non-interactive. To install packages reliably on Ubuntu, we had to set three separate "Please just install the package, don't try to ask questions" options for different layers of the stack, and still occasionally ran into buggy packages that would hang the installation waiting for a nonexistent user to type something.
- On RH, when I try to install or upgrade an RPM that's missing dependencies, it gives me an error and refuses to break my system unless I specify --force. With debian, there's no way to query "Are the dependencies for this .deb satisfied" that I could ever find, and "dpkg -i foo.deb" will instead leave it "half-installed", and your package database is broken until you manually fix it.
- I really missed an equivalent of `rpm -V` (list files in an installed RPM that have been modified since installation). Asking Google now, I see that there's `debsums` which can handle some of this; I don't recall whether I failed to find that before, or if there was some other reason I didn't use it at the time.
- On RH, automated installation with kickstart is fantastic and comprehensive. It's well-documented, and has just worked for every configuration I've thrown at it. Debian's preseed is severely under-documented, and many combinations of features are just unimplemented and silently didn't work. For example, you can reserve unallocated disk space from a raw partition, but that's ignored for LVM, so to keep space free for snapshots in my volume group, I had to configure a "delete_me" volume, and then later delete it.
- Red Hat's SELinux support is fantastic. Ubuntu's choice of apparmor and deficient SELinux support has been annoying.
- I've personally found Red Hat's packages to be higher-quality. The biggest defect I remember finding in Ubuntu's repos was a service whose init script was literally copied from Red Hat, which didn't work, as it tried to source a file of init script utility functions which doesn't exist on Ubuntu, among other issues.
- Red Hat's documentation is fantastic. Ubuntu's documentation is, uh... sometimes present.
- I've found building RPMs to be much simpler and much-better-documented than the process of building debian packages. I vaguely remember being repeatedly frustrated at debian packaging that felt like "this magic thing just interferes and does special stuff when this case is detected", vs RPM's "it just does what the spec file says to do", but I can't remember any details or examples.
- I've had a much easier time building yum repositories than building debian repositories. Just dump a bunch of RPMs in a directory, run createrepo, serve over HTTP. I failed to find something similarly-simple for apt repos.
- Red Hat family had systemd way earlier, and with way better support and integration, than Debian family. While I do agree that there are some implementation issues with systemd, it's been a huge usability and quality-of-life improvement for me professionally.
To me, Debian has always felt like it's designed for someone administering a small number of long-lived pets with a variety of special circumstances, which really isn't what I want professionally. Red Hat has felt like it's engineered for use-cases I care about.
Also 16 is actually not a small number, people with Kubernetes orchestration sometimes forget how much you can run on a single machine :).
I am even considering adding and marketing RHEL for my book[0] since the difference is just the registration.
Speaking of which, if you use Vagrant, have a look at vagrant-registration. It can register your box automatically (I am the original author).
https://www.redhat.com/en/blog/introducing-red-hat-universal...
https://developers.redhat.com/articles/ubi-faq#introduction
re: licensing, the FAQ says:
Do I need a subscription to use UBI?
Accessing non-UBI content does require a Red Hat subscription.
https://www.redhat.com/en/store/red-hat-enterprise-linux-ser...
Oracle has a larger range of tiers. The "no support" license is $120/year. Tiers with more capability and support are available for $500, $1200, $1400, and $2300.
Oracle Linux can be used in production without a paid license of any kind; Red Hat Linux cannot be used in this way for large deployments (excepting the new 16-seat license for a developer account).
Red Hat is aggressive with software audits; I have seen one.
Both Oracle and Red Hat now have complete toolsets to convert support between an installed CentOS/RedHat/Oracle OS.
Red Hat can now convert an installed CentOS or Oracle Linux to RHEL; previously a wipe and reinstall was required ("have fun reinstalling your system" is still on Oracle's CentOS site). The description looks much more thorough in replacing all possible packages with Red Hat versions:
https://access.redhat.com/articles/2360841
Oracle does not replace CentOS or RedHat RPMs in their conversion (AFAIK), so it is much less violent on the platform changes.
https://github.com/oracle/centos2ol
https://linux.oracle.com/switch/centos/
https://blogs.oracle.com/linux/reasons-for-switching-centos-...
Red Hat has terminated two major platforms over the last two decades - the original Red Hat Linux, which was terminated at v9, and now CentOS.
Oracle has "somewhat" terminated a platform, Oracle Linux for SPARC, which was only supported for two minor releases. The Linux for ARM64 and AMD64/x86 seem reasonably healthy.
There is other baggage in and between these corporations, but the track record on Linux OS platforms between these two is demonstrably different.
You're forgetting:
* They killed OpenSolaris by making it proprietary again
* They effectively killed Solaris (formerly OpenSolaris) without the formality of making it official dtrace.org/blogs/bmc/2017/09/04/the-sudden-death-and-eternal-life-of-solaris/
However, there is a long list of platforms that would never have survived elsewhere. JD Edwards, Peoplesoft, and Siebel are prime examples.
And I am still using the Oracle RDB database platform.
Red Hat would have euthanized all of these long, long ago.
Not to defend Oracle, but I am pretty sure all proprietary unix have contracted over the last 10 years. AIX, HP-UX and whatever other flavors don't seem to be doing well regardless of who is controlling it. If Sun remained in control I am not sure how much better Solaris would actually be doing.
I do not consider it unfair.
1. It clearly states "Not for Production" on the license
2. It says it can not be stacked with other license, I am not sure if that means you can only have this license and not others in the environment
3. the biggest is Physical hardware Only, no VM's.
Oracle does the same thing, but they don't care about OS licensing. One thing that they do care about is the extended support (RPM updates after end of life).
> Oracle Linux can be used in production without a paid license of any kind
So... what offers this $120/year "no support" license when you can use it with no cost at all for production?
For a license "in name only," either the $120 Oracle or $350 Red Hat tier will suffice.
I don't see the need to waste any more than $120 on support that I largely don't use. My Oracle Linux licenses expired several years ago, and I don't see any point in renewing them.
I have had to use alternate Oracle CSI support to fix some of their own self-inflicted brain damage. Oracle managed to disable microcode updates in the UEKR4, killing spectre/meltdown remediation. They would not listen to me on the forums, and insisted that I file an SR, so I used a general corporate CSI to get that fixed (and it still took several months).
What RedHat provides is an enormous development effort and an extremely long lived LTS platform. That doesn't come for free.
Many seem to want RHEL for free, but there are free alternatives. You can run: Debian, Ubuntu or Slackware, if the cost is such a huge issue.
I won't argue that RedHat has handled the change to CentOS in a good way, they clearly haven't. On the other hand I don't free sorry for those companies how want all the benefits provided by RedHat, but not pay to keeping RedHat in business. Open source isn't about free, it's about giving you the option to make changes to the code yourself, or pay others to do it for you. RedHat would like to get paid for their work, if you don't want to do that, that's fine to, but then you need to do the work yourself.
But gambling that a for profit company will always provide you with a free alternative to they commercial offering is a calculated risk. In this case it might not have paid of.
So next step for rhel, allowing dockerized rhel images would be nice. That is a real hurting point you created by your centos change!
Doesn't engender a bunch of trust.
> When we announced our intent to transition to CentOS Stream, we did so with a plan to create new programs to address use cases traditionally served by CentOS Linux.
This is a load of bullshit. If that was their plan they would have announced both of these changes together. It's not like they were under time pressure to get the announcement out.
I work for Red Hat, opinions are my own, etc. I don't know why they decided to announce the CentOS plans before announcing at least some of the expanded RHEL offerings, and many people are just as confused as myself. However, whatever the reason was, it's absolutely true that expanding access to no-cost and low-cost RHEL was always the plan, and the original announcement effectively stated as much.
I also have no doubts they wanted to see how much bad PR the announcment made before figuring out that those expanded options where
It was from be beginning a Monetary Grab, Redhat did a global scream test to see how much they would have to give away to take the screams down to a dull roar and stop the bleeding just enough to not lose any market share
They have landed on 16 as the magic number for now, but like the OP I have visions of Darth Vader saying “I am altering the deal. Pray I don't alter it any further.” while wearing a RedHat
It does not fill me with confidence that I should make use of that 16 server license...
https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-d...
1, OpenSUSE Leap cannot do full version upgrades 2, They use AppArmor instead of SELinux 3, Support is shorter than CentOS Stream[0]
[0] https://nts.strzibny.name/how-long-will-be-centos-stream-sup...
Is that setup still 16 systems or do they count the number of virtual machines?
Btw. I did not check, it's possible it's based on number of CPUs or smth.
I don't really have a good rationale hah, but I was working for Red Hat and it could be cool to finally run my side project on RHEL.
Now that Centos and RHEL will no longer be in lockstep, some people are looking for alternatives. The upgrade from 1 RHEL license to 16 is a way for Red Hat to try and retain small projects and let home labbers and evangelists legally replace Centos rather than switch.
For context, CentOS was a popular Linux distro that tracked RHEL, being mostly identical except for not requiring a support package. Red Hat stopped supporting it, which put a lot of its users in a bind. This is intended to replace it.
I hope my large government customers ditch RHEL for something else - maybe a derivative that's home grown.
Edit: I'm sure this is not a popular opinion but it is what it is.
As a Red Hat employee for ~5 years, every line of code I've ever written professionally has been open source and licensed under the GPL. The same is generally true across the entire company (with the exception of contributions to external projects licensed Apache / MIT / BSD).
Can you explain what you mean by "open/free"? Perhaps "free beer" rather than "freedom"?
You installed 16 systems and a half year later RH says, and in 1 year you have to pay for these or change to CentOS Stream, i think it's a very founded consideration after the CentOS debacle.
But not sure what he means that RH does not care about Opensource...
https://www.servethehome.com/red-hat-goes-full-ibm-and-says-...
I'd still prefer CentOS lived, this is probably meant to keep people from grabbing pitchforks.