Red Hat announces no-cost RHEL for small production environments(redhat.com)
redhat.com
Red Hat announces no-cost RHEL for small production environments
https://www.redhat.com/en/blog/new-year-new-red-hat-enterprise-linux-programs-easier-ways-access-rhel
267 comments
16 servers in a data center is probably a medium sized business, if not a larger small business that does zero virtualization. 16 servers in the cloud that are rightly sized sounds incredibly small.
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.
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.
i've got more than 16 "right-sized" VMs on the VMware cluster in my homelab. Between the other half-dozen physical servers, there's probably another 40+ "OS instances".
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.
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.
The weird thing here is the consistent recommendation of corporate backed distributions. Debian has existed for quite some time without any need for a corporation. Are there problems? Yes, but Debian isn't going to suddenly announce that it's going to kill itself either. I would suggest getting involved in the Debian community (without trying to take it over), and making meaningful contributions.
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.
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.
Honestly, I can't remember the last time I had Debian stable go wrong in any application[server,desktop,laptops or raspian]. I use it everywhere and it is pretty fantastic.
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.
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.
Debian was responsible for one of the, if not the, biggest security disasters in Linux distributions' history. A Debian developer thought they knew better than the OpenSSL developers and made a change that compromised every SSH and SSH private key you generated.
https://threatpost.com/how-debian-openssl-bug-almost-spawned...
https://threatpost.com/how-debian-openssl-bug-almost-spawned...
I remember this bug. It was what made my interest in systems engineering soar. Unfortunately your characterization of it falls quite short.
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
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
Ubuntu is actually based on Debian unstable, they do their own QA rather than relying on the Debian's testing migration QA.
Debian is amazing, and sadly often overlooked.
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.
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.
I’ve been using Ubuntu in some form since the first versions in 2004, and mostly sticking with LTS since 2006. What won me over in the early days was the clear versioning story with predictable cadence of releases and support intervals, pragmatic approach to proprietary drivers and video codecs, and the fact that server and desktop were the same distro.
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.
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.
In my opinion you've hit on Ubuntu's biggest contribution to Free and Open Source software.
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.
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 have to agree. The year.month scheme, and the predictability are things that make ubuntu easy to adopt for corporate users.
I think if debian augmented the toy story names with dates, that might help.
I think if debian augmented the toy story names with dates, that might help.
When Ubuntu came out, Debian was notoriously difficult to install. The joke was that Ubuntu was the African word for, "can't install Debian."
I’ve never had any issues with installing Debian.
Before that I was on FreeBSD, and before that I was in Slackware. All were always fine
What does “difficult to install” even mean?
Before that I was on FreeBSD, and before that I was in Slackware. All were always fine
What does “difficult to install” even mean?
fighting with XF86Config, hoping not to fry your monitor.
Well, that was with any dist, and not really a Debian issue.
Besides, last time I ran a GUI on linux was probably over 20 years ago.
Besides, last time I ran a GUI on linux was probably over 20 years ago.
What complicated it is that usually when you were coming to Debian you were coming from Slackware or a BSD, so everything you knew about init systems and software distribution went out the window. Where's rc.local? Why did ./configure && make && make install destroy my system? Also: we're talking about 20 years ago: everything was harder then.
If you came from a BSD, then you (were supposed to) already know why make install is not a good idea. Although Debian package management was not particularly similar to FreeBSD ports and packages, the fundamental idea was the same.
I use Debian, a lot, I happily run it on most of my servers. But I can completely understand that it's not great for the majority of users.
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.
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.
Backport frankenware is probably the biggest reason I wouldn't recommend Debian.
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.
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.
Just to be clear, the backporting part was just hearsay that it was under debate, so don't take my word for that one.
I'm sorry I misread this.
> 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?
> 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?
I'm not certain about guidelines, but zfs 2.0.1 has landed in bullseye \o/
https://packages.debian.org/bullseye/zfs-dkms
https://packages.debian.org/bullseye/zfs-dkms
They backport all sorts of things, the fact that this is even a discussion point is bad enough.
Solution: use a distro-agnostic package manager (Nix, Guix, Homebrew, FlatPak, ...) on top of Debian. Stable base + modern apps.
> Canonical never did much to add value
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!
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!
Two things that I would like to see in Debian. First, something more similar to Red Hat Kickstart. The Debian equivalent (Preseed) doesn't quite cut it (effectively it is an "answer" file for the Debian installation, so when the questions in the installation evolve you need to regenerate the preseed config (this is my understanding, everything I've read says that it would be really difficult to make a preseed configuration by hand).
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.
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.
The dpkg roadmap mentions a metadata tracking proposal, which seems likely to provide something like the database that you want.
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.
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 think a database to speed things up would be ok, as long as the flat text files were the truth.
I wish Linus had veto'd the binary logfiles of systemd.
I wish Linus had veto'd the binary logfiles of systemd.
I think the best of both worlds would be an sqlite DB (which is extremely reliable) along with a rotated export to a flat file whenever there are modifications.
There is something called kickseed, which is documented on the Ubuntu wiki and seems to be available in Debian too, possibly in the Debian installer as well.
https://help.ubuntu.com/community/KickstartCompatibility
https://help.ubuntu.com/community/KickstartCompatibility
They made it so that when the system booted you got a graphical login prompt, and not just a stock xdm config, either.
> 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.
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.
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.
Debian is in fact incorporated.
"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.
"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.
There is a massive difference between a company that manages trademarks and a for-profit business that depends entirely on gatekeeping behind a subscription and support contract. Before someone brings up Fedora, RHEL exercises ultimate control over that too. Think about that, RHEL owns the trademark to Fedora. Feel free to browse their board too.
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.
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.
There are actually several non-profits holding Debian assets, in years with a physical DebConf usually a new or existing organisation is enlisted to hold funds for that conference.
https://wiki.debian.org/Teams/Treasurer/Organizations https://wiki.debian.org/Teams/DPL/TrustedOrganizationCriteri...
https://wiki.debian.org/Teams/Treasurer/Organizations https://wiki.debian.org/Teams/DPL/TrustedOrganizationCriteri...
> The weird thing here is the consistent recommendation of corporate backed distributions.
If you pay for software, like we do in VFX/Animation, then RHEL is basically the standard and what's supported best.
If you pay for software, like we do in VFX/Animation, then RHEL is basically the standard and what's supported best.
Would you write out more about that? I would assume Windows is the standard for workstations.
In addition to the other responses, the VFX community has strong roots coming in the SGI/IRIX days. When those platforms started to decline due to competition from modern commodity hardware among other reasons, Linux offered the best path of migration from both a hardware support perspective and reasonable compatibility with existing pipelines and tools (the latter being very important). Red Hat became a sort of de facto at that point.
^ 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 ;)
^ 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 ;)
Standard? Someone in vfx would have to answer that, but my understanding is: not really. There is a lot of vfx work that happens on Linux workstations.
https://vfxplatform.com/about/
https://vfxplatform.com/about/
In the VFX environments I've seen (100+ artists), most artist workstations and servers are Linux (usually RHEL or CentOS due to much higher rpm than deb support in the industry). Macs are common for editors (who use the Adobe suite to make timelines for dailies) and producers (because shiny), while Windows is mainly used by admin staff (accounting, hr, etc) because they use the same terrible accounting software as every other company out there (note: this may be less so now with the move to web based solutions).
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.
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.
Apples and oranges. Corporations that feel they need Enterprise Support, either for the OS itself, or for software that runs on the OS (commercial databases, engineering tools, etc.), pay for Red Hat Enterprise Linux. Or, if they were small just feeling like throwing caution to the wind, they would use Centos (and not tell anyone that it wasn't actually Red Hat). These are businesses and software that used to run only on commercial UNIX operating systems.
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.
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.
So companies should expect OSS maintainers to provide the same level of service that a RedHat subscription does if they donate?
Who is suggesting that?
I am
It may not be to the level of support that RedHat provides, but Debian does provide gratis support and there are consultancies providing paid support:
https://www.debian.org/support https://www.debian.org/consultants/
https://www.debian.org/support https://www.debian.org/consultants/
The Linux kernel itself is corporate backed.
There is a difference between corporate backed and being owned and operated by a corporation.
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.
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.
I don't see a lot of production workloads running debian unless it's a Ubuntu which is backed by canonical.
Considering that Ubuntu is a superset of Debian, then yes you do see lots of debian production workloads
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
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
I wish I could use Debian at work, I run it at home on the same server for 8+ years through multiple full version upgrades with very little hassle or trouble. With RedHat I'm fighting satellite server and subscription nonsense and have to rebuild from scratch to upgrade, I've never understood that requirement.
I see you've been downvoted, but this statement is true. Ubuntu on both servers and desktop is far more popular than debian. Popular is not always a good proxy for better, but in this case following a well tread path is advantageous when you run into trouble.
Is there anything Ubuntu-specific in Ubuntu these days (other than process stuff, like release cycle)? Or is it just Debian with commercial support and branding?
I know you mean in terms of host OS, but as an aside, loads of Docker images are based on the "slim" Debian images.
Google's production servers run a customised version of Debian https://www.usenix.org/conference/lisa13/technical-sessions/...
Also desktops: https://en.wikipedia.org/wiki/GLinux
I usually choose debian for docker images if alpine isn't the right solution. Their slim images are pretty nice.
From a business perspective, the biggest problem I've experienced with community-based distributions is the limited support cycle. Debian averages about 3 years with LTS, which is really good for for a community distro but really short for a commercial distro.
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.
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.
Is that still the case with cloud-first, software-defined infrastructure, and IAAS? Even in non-cloud environments you have pets vs. cattle, with the cattle hopefully out-numbering pets. So your data sits off in a storage device, and gets attached to containers running on an OS that is built from a kickstart or similar install. In that case you can spin up VMs running any OS version, make sure you can deploy your containers on it, test it, and off you go.
The days of having a fleet of servers that were carefully hand-crafted and evolved over the years are hopefully coming to a close.
The days of having a fleet of servers that were carefully hand-crafted and evolved over the years are hopefully coming to a close.
You might be thinking as a technologist rather than as a business person. Debian is great, but there is no accountability if things go wrong. Accountability and QA may be worth the licensing costs, even if 100% of the software is "free".
First, they should have announced this when they killed CentOS.
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.
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.
I manage a "tiny company", but we have 10-ish production CentOS 7/8 servers and this sounds interesting. Although my web-app use case is probably fine with Stream, I don't know why everyone is assuming Stream will be completely broken and useless.
It's not that the expectation is that it will be broken and useless. It's that the reason to choose CentOS was for the fact that it has slow release cycles which allow for long support periods.
> I don't know why everyone is assuming Stream will be completely broken and useless.
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.
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.
Curious, do you consider Fedora to be an alpha? Did you consider RHEL to be a beta for CentOS previously?
Just trying to see how you define "beta"
Just trying to see how you define "beta"
> Curious, do you consider Fedora to be an alpha?
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.
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.
Funny to read this because Fedora is definitely beta, because their distribution doesn't seem very stable. I switched away from Fedora because it seemed to break more than my Arch installation. There are a lot of things they are doing that no other distros are doing right now. Cgroups v2, for instance.
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 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.
I think you're digging in the wrong place, and focusing on the label. This shouldn't be kicking fedora down. It has a place, as does stream.
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.
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.
To me, Fedora is a desktop environment (my preferred one!) and absolutely an alpha/early-beta server option at best.
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.
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.
There's a pretty big difference. While I'm very much not an expert on the RHEL QE process, my understanding is that Fedora is pretty much its own thing that is used to rebase RHEL on major revs. Whereas Stream is RHEL builds that have passed CI testing in the RHEL dev/test process.
Many people use CentOS to run "Enterprise" software that expects to be run on RHEL.
Those are probably the users that RedHat is trying to nudge onto RHEL. "Enterprise" software is normally quite expensive, so the marginal cost of some RHEL Server licenses is probably a small fraction of the total cost of deploying the software in most cases.
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").
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").
> Going from spending $X to spending $X+Y is often not a big deal
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.
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.
> More generally, orgs that are running "Enterprise" software are already set up to pay for software.
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.
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.
Okay but I can't help but think about the social security in my country which I know runs likely to be more than hundreds of CentOS servers ... It's not like social security is a company making any profits, it's even the opposite, and now they are in such situation.
We are a smallish company with six CentOS 8 servers. Seems we fit into the profile of this new Developer program. To be honest, I can see us paying for full RHEL subscriptions before we would change distributions.
Go ahead and buy licenses as a show of support, but I strongly suggest that you exercise the converter scripts in both directions, partially to know what will cause them to fail, and partially to have an option when the vendor misbehaves.
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.
https://www.oracle.com/linux/
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 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.
https://www.oracle.com/linux/
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 can now convert an installed CentOS or Oracle Linux to RHEL"
Apologies if a dumb question, but I assumed CentOS 8 was a clone of RHEL 8. What would change?
Apologies if a dumb question, but I assumed CentOS 8 was a clone of RHEL 8. What would change?
Take a look at Oracle's "CentOS to Oracle Linux" (and other similar) scripts to see how they work and what they do (sorry, I don't have a link handy as I'm on a mobile device at the moment).
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.).
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 running "yum update" the packages are pulled from the registered repository, found in the /etc/yum.repos.d directory.
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.
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.
It's easy enough to suggest "just use Rocky" but Rocky doesn't exist beyond a collective promise. What about production now, or in the next few months?
You could say the same about CentOS 8. There is no contract guaranteeing support-just a collective promise that was broken in a single day.
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.
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.
There is also AlmaLinux [0], expected to be available in Q1 2021.
[0] https://almalinux.org/
[0] https://almalinux.org/
I believe CentOS images are still available and supported as much as they were before through the rest of this year, fwiw.
Agreed. But Rocky is supposed to launch before CentOS 8 is EOL. There should be time to wait and migrate.
> What about production now, or in the next few months?
Pay for RHEL, use CentOS 7, or switch to Ubuntu.
Pay for RHEL, use CentOS 7, or switch to Ubuntu.
Even though it sounds bad, Oracle Linux works surprisingly well
It's not just that it sounds bad, you'd have to be willing to sell your soul to the devil.
As I remarked to a RH employee when the CentOS 8 discontinuation came out - do you have any idea how much trust you have to burn that people are considering Oracle as the good option?
What's the specific difference between Oracle and IBM/RedHat in this regard? As far as I can tell Oracle has burned a lot of people because they don't do license checks in their software (no DRM of any kind), which is usually what the HN crowd wants. But the flip side is they have to check you in some other way, leading to audits, and audits are very painful.
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.
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.
This page has some interesting details: https://linux.oracle.com/switch/centos/
Or scrap all three and start using *BSD.
This seems more and more to be the reality we are moving towards. Been dabbling with FreeBSD lately and it just works. Also, ports are updated or new submitted quite often making it feel less out of date.
That's not a decision you make and then train staff + switch in a short time. At least not beyond trivial deployments. People used CentOS so they don't have to deal with this and they will have other less-extreme options before CentOS EOL.
[deleted]
Whats wrong with Centos Stream?
... you know, I had actually forgotten about that as an actual option. Yes, some people would probably be fine running Stream. I personally would avoid it because you're sacrificing stability by beta-testing Red Hat's software for them, but it is free, it is close to CentOS 8 (RIP), and it is likely to be good enough™ for many uses.
Are there any actual reports of instability of Stream? I mean, it's _barely_ ahead of RHEL/odl CentOS.
(RH Employee)
> 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.
> 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.
> 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.
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.
Red Hat was not expecting the reaction to killing CentOS.
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.
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.
> The need to expand the developer program into production seats could not have been anticipated.
I don't follow. Are you suggesting that RH actually didn't realize that people were running CentOS at scale in production?
I don't follow. Are you suggesting that RH actually didn't realize that people were running CentOS at scale in production?
I see the decision to convert to CentOS stream as driven by two motivations, cost containment, and facilitating outside contributions by pushing CentOS towards Fedora (and away from RHEL stability).
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.
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.
> pushing CentOS towards Fedora (and away from RHEL stability)
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)?
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)?
Is a "preview" as stable as the base release?
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-...
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-...
> 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.
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.
> 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.
Red Hat was not expecting the reaction to killing CentOS.
It’s funny how everyone still says Red Hat when we mean IBM.
It’s funny how everyone still says Red Hat when we mean IBM.
I understand as an RH employee you're likely not in a position to make decisions about what you can disclose when, but... (I'm sure you're aware) your first answer contradicts your second.
There's no contradiction, only an acknowledgement that (in my personal opinion) the piecemeal way these plans are being announced is understandably frustrating, but that they are legitimately serious about making RHEL easier to use across a spectrum of use cases (which the official post is pretty clear about).
It's worse than frustrating, it's damaging for Red Hat.
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.
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.
I Agree 100%
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...
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...
And yet you're not willing to pay for it.
I dont drive those decisions butI will say if they had better "no support" options my org probably would buy it. We have no desire for RHEL support, they had had bad experiences in the past which was one of the driving reason to drop RHEL for CentOS, why pay for support if it sucks?
My guess is that at least 10% of the CentOS yum repository traffic was immediately lost at the announcement, as it switched to Oracle.
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.
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.
That's fine, but it would be negligent of a company to wait and hope that Red Hat pulls a rabbit out of a hat. The plan for most companies is going to be a new distro, and they're not going to reconsider when RH announces something new because by then decisions have been made and trust has been lost.
[deleted]
yeah, stop playing games, redhat? just say what you're going to say already. i have no idea why you're trying to focus so hard on building mindshare, building a mystery around it like you're a sarah mclachlan tribute band, but you already blew it. go back to what you're good at, please.
they didn't have this when they announced the death of centos. this is what they scrambled to come up with when they realized how much of an "oops" move messing with centos really was.
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.
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.
Scientific Linux (sponsored by Fermilab) is a CentOS-like rebuild of RedHat Enterprise Linux and might also be worth a look. https://scientificlinux.org/
Fermilab discontinued work on Scientific Linux in 2019 in favor of using CentOS: https://listserv.fnal.gov/scripts/wa.exe?A2=SCIENTIFIC-LINUX...
It’s possible they could choose to restart work on Scientific Linux, but nothing has been announced yet.
It’s possible they could choose to restart work on Scientific Linux, but nothing has been announced yet.
To add, Fermi and Cern released a join statement
>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-...
>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-...
How did redhat kill centos again?
I appreciate the thought, but am still miffed at the "embrace, extend, extinguish" that caught me off guard here. I can't exactly pull out too many pitch forks because CentOS did let me enjoy some of their packaging labor for free.
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.
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.
Yeah, I'm not running anything with some weird contingent license if I'm running Linux. Completely defeats the purpose. Also, now more than ever, after last month's big hacks I think building things from source makes more sense.
I'll be sticking with gentoo for my mission-critical bare metal installs when I need Linux.
Shit you have time to compile everything from source. What is this a air gapped laptop?
I would not trust the community of volunteers that maintain Gentoo in their free time for anything mission critical. I would use Ubuntu or Red Hat, which are backed by companies.
I've got bad news for you - most of Ubuntu is repackaged Debian which is from a community of volunteers that maintains the packages. Besides that Ubuntu used to be sloppy in backporting important patches and doing some NIH here and there... not sure about Redhat but they source heavily from Fedora which is also community-based.
I’m not sure I can agree with this concern. All Linux distros work by repackaging upstream code, the majority of which is written by volunteers. For Debian, they’re repackaging directly from upstream. Ubuntu repackages from Debian.
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.
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.
> 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
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.
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.
Most Linux software is written by Red Hat. GNOME, Wayland, and systemd are all Red Hat projects. They are even a major contributor to the kernel itself.
[deleted]
> Most Linux software is written by Red Hat.. even a major contributor to the kernel itself.
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.)
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.)
There are consultancies that do that for Debian, the major ones have multiple engineers contributing to Debian and even more to upstream projects.
https://www.debian.org/consultants/
https://www.debian.org/consultants/
It's not a concern but just an observation that things in universe in Ubuntu get rarely if at all backports. It's okay. I agree about having a company especially regarding timely security updates.
Red Hat sponsors Fedora big time. I was part of the packagers team for Ruby. Next to us were sitting Perl guys (you would never believe how many Perl packages are still there...!) and somewhere else folks doing Python packaging.
Source: Formal Red Hat packager working on Fedora.
Source: Formal Red Hat packager working on Fedora.
It doesn’t matter that Ubuntu packages originally came from Debian. At the end of the day, Canonical employees are being paid to make sure they are up to date. I trust that over a bunch of volunteers who do it out of the goodness of their heart.
You just described just about every OS that isn't Microsoft of Apple. Good luck with that attitude.
That just shows a lack of knowledge of the quantinty of commercial OSes available out there.
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.....?
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.....?
Both PS Vita and Nintendo Switch have miles long credits listing all the licenses (mostly BSD) and authors of the many OSS software bits they use.
Hey, I like that I can play around with RHEL without too much of a hassle.
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.
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.
Honestly these seem like pretty generous and useful offerings. I appreciate the commitment they make to not use them as a sales channel as well. Will be interesting to see what else is offered in the coming February announcement.
It's generous as long as you ignore the fact that CentOS used to cover all of these usecases without any restrictions on what you could use it for or how many servers you could use it on, for free, with no licensing or registration.
But since we aren't entitled to any free product at all, it seems unkind to criticize someone for not giving as much for free as they once did. It's still generous, even if previously it was more so.
> But since we aren't entitled to any free product at all, it seems unkind to criticize someone for not giving as much for free as they once did.
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...
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...
Yes, I can understand being upset about it, but think such anger should be tempered by no fee being paid and no contractual obligation being breeched. It seems to me if you're in a situation where you truly depend on such a commitment, you should be paying for a contract with someone, not hoping for the best. Had Red Hat not been supporting CentOS for over 6 years, it may have fallen apart even sooner. Who knows.
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/
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/
It's not a matter of whether a contract was breached. People tend to get upset when trust is broken. I suppose your argument is that people shouldn't have trusted RedHat because no money was exchanged but that's not really how trust works in real life.
My argument is that people should have more reasonable expectations from a free project. That it is unreasonable for a free project that is shutting down to continue to operate until all EOL's are reached, especially til 2029. It's quite nice of them to keep things going for a full year in order that people can make other arrangements.
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.
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.
[deleted]
We are as entitled to it as we are to the Linux kernel on which it's based.
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.
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.
> We are as entitled to it as we are to the Linux kernel on which it's based.
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:
https://rockylinux.org/
Which was created by the CentOS founder.
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:
https://rockylinux.org/
Which was created by the CentOS founder.
> Are you claiming they are in violation of the GPL license?
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.
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.
>We are as entitled to it as we are to the Linux kernel on which it's based.
>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).
>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).
Very bean counter thought process here:
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.
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.
Given when this happened, I’d bet Red Hat knows, but IBM doesn’t care and just wants the extra revenue even if it costs them in the long run.
As someone not running these small to medium sized businesses, this is an honest question. I quickly looked at the pricing for RHEL. It didn't seem outlandish. Can anyone comment on this?
Its really not especially compared to Microsoft or even IBM itself. My problem has been really crappy ability of Red Hat to answer any questions and the general friction of the purchase.
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.
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.
It seems reasonable to me, I could sell management on the value of paying it. I would like to hear more from people with experience with Red Hat support.
In other news, farmer Bob announces that he's closed the barn doors and asks all the cows which left to please come home.
As a bit of a self taught sysadmin who only touches Ubuntu/Debian based systems due there ubiquity, could someone explain the benefits of using RHEL?
RHEL documentation is second-to-none. It's akin to old UNIX documentation, or the pre-10 offerings from Microsoft.
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.
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.
1. SELinux. It's configured for all packages in RHEL distribution and it works. It's an additional layer of defense and think that's the most important denominator from other Linux distributions. I saw recent Ubuntu distributions shipped with AppArmor, but I'm not sure that it's as good.
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).
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).
I second all of that.
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).
[0] https://deploymentfromscratch.com/
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).
[0] https://deploymentfromscratch.com/
I've gone back and forth on selinux (and a bunch of other in-house stuff that RHEL makes). Yes, it has improved over the years, but it still breaks a lot. The thing with RHEL is that you really need to be paying for the support to get any value out of it. With CentOS or this beggar subscription level, you are better off using Debian or Ubuntu, because when shit breaks, all you'll do is create a bug report in any OS. With Debian or Ubuntu, you have a slightly better chance at recovery. RHEL has a strict demarcation between support levels, features, release timelines, etc. So if you report a bug to RHEL, they may not backport the fix even if it fixed upstream. And then you are just stuck.
> RHEL has a strict demarcation between support levels, features, release timelines, etc. So if you report a bug to RHEL, they may not backport the fix even if it fixed upstream. And then you are just stuck.
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.
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.
Stream is a bit closer than Fedora, but the larger point of needing paid support remains. The slow cadence of RHEL means that unless you are paying for support, things get kind of frozen around the .5 release. After that, they just won't backport fixes, not even regressions, unless a) You are paying, b) It's really a critical security bug. I don't think that will change with Stream.
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.
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.
RHEL major releases are every 3 years now.
Matthew Miller (@mattdm) tweeted out the "Fedora->RHEL formula": https://twitter.com/mattdm/status/1349037318200561665
Matthew Miller (@mattdm) tweeted out the "Fedora->RHEL formula": https://twitter.com/mattdm/status/1349037318200561665
Support for enterprise-type products.
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.
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.
The main benefit for me was that systems I stood up in 2011 received security updates until last month.
Enterprise support. Most enterprise hardware and software vendors don't have Ubuntu or Debian as a supported OS.
Additionally the length of support, Ubuntu LTS gets close but RHEL will sell you support FOREVER.
Additionally the length of support, Ubuntu LTS gets close but RHEL will sell you support FOREVER.
> 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)
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)
There's absolutely an argument that, for many companies, if you're dependent on a long-term stable release for everything (especially in the absence of actual paid support) you're probably doing it wrong.
in my experience, systems such as Debian and Gentoo for servers have an entirely different market than RHEL, z/OS or SUSE: the former seems to be more so used by i.t. companies themselves that of course also need to run an i.t. infrastructure, and the latter more so by companies whose primary services are not i.t., but that need such infrastructure nonetheless.
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.
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.
A ton of compliance stuff is already done for me if I use RHEL. For example:
https://nvd.nist.gov/ncp/checklist/811
https://nvd.nist.gov/ncp/checklist/811
The big difference to me is that Red Hat family distros have been a lot better suited to managing a large fleet of servers that I want to treat as cattle, not pets. I've finally managed to get away from Debian derivatives a few years back, but here are some specific complaints I can remember from my last job, managing about 1k Ubuntu servers.
- 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.
- 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.
I think you can use apt install ./file.deb instead of dpkg -i file.deb, in order to check and install dependencies.
That's relatively new. I believe that was introduced in 2016-ish? It definitely didn't work in older Ubuntu LTS releases...
Other then what has been already mentioned (chiefly commercial 3rd party software support), I enjoyed the set-up time. Now there are better provisioning methods, particularly when setting up hundreds of hosts, but when doing it naïvely for a single or few hosts using the interactive installation software, I preferred RedHat/CentOS. That got me to a booting system in some ten, fifteen minutes, while the dreaded installation in Debian used to take easily 1.5h. Once installed, I found Debian easier to maintain and upgrade in place, but initial installation was a time-sink for many years.
To also comment here: every red hat system boots from dracut. There's no separate PXE for netboot: provisioning is consistent whether your boot medium is local, LAN, or ephemeral. It ships netboot-capable out of the box, and this is huge.
I am not a linux guy but had the same question and found out by googling a bit that it was because of software support. Major Linux vendors support only enterprise distros (like Redhat, CentOS and Suse)
Don't know if this is still true but Oracle only had installs for the RHEL/CentOS family, which of course included Oracle Linux.
Last i checked (2 years ago), when it comes to linux, Oracle Database officially supported only RHEL and OEL. I don’t think CentOS ever made it to the various support matrices, although of course its close compatibility with RHEL meant it likely worked just fine.
As a formal Red Hat packager, I am quite happy to see this change. Before I could not use RHEL to run my side project, but now I can!
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).
[0] https://deploymentfromscratch.com/
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).
[0] https://deploymentfromscratch.com/
The production licenses for RHEL are certainly expensive, but it's not my job to decide whether they are worth it. My job is to develop and ship software to customers that used to run Ubuntu, CentOS, and sometimes RHEL. To compile/build/package that software we use docker containers, which provide nice isolation and hygiene and also guarantee user-space ABI compatibility to the target system. What I'd like to know: How can I user containers to develop for RHEL now? Is there some "short-lived" clause I could depend on or do I have to buy a license for every container I might want to spin up?
Look into the RHEL Universal Base Image.
https://www.redhat.com/en/blog/introducing-red-hat-universal...
https://developers.redhat.com/articles/ubi-faq#introduction
re: licensing, the FAQ says:
Accessing non-UBI content does require a Red Hat subscription.
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.
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.
https://www.oracle.com/linux/
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.
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.
https://www.oracle.com/linux/
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.
>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.
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/
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/
I did say "track record on Linux OS platforms," but I will grant you that Solaris has contracted under Oracle.
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.
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.
> I will grant you that Solaris has contracted under Oracle.
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.
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.
The $350 license has some real limits to it
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.
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.
My previous employer from 2017 was paying around $68 per license from Red Hat and it didn't include support. It wasn't a massive volume deal either, had less than 50 RHEL servers in the environment.
We shifted a bunch of Red Hat licenses to a hosting provider, and Red Hat auditors showed up.
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 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 has a larger range of tiers. The "no support" license is $120/year.
> 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?
> 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?
I have a SOX requirement that all of our corporate software is licensed.
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).
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).
How about no-cost no-registration self-support RHEL for unlimited number of systems?
Someone need to pay for a service, not everything is free as in beer.
What would be the service on this case? Redhat already is open source and is being compiled anyways.
So grab the source and compile it yourself.
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.
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.
There has been a freely downloadable Red Hat available for the past 20 years, either in the form of CentOS, or before it good old classic Red Hat Linux. That got them this far, where they are now. So you can understand how people feel bit miffed, especially now that they have Big Blue backing them they should be financially more stable than before.
I can certainly understand people being "miffed", but that was a risk when choosing to base your infrastructure on RedHat. Again the handling was extremely poor. Had they announced this new program along with the changes to CentOS, I don't think as many would have been upset.
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.
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.
I mean although this sounds like an absolutely outlandish ask for a company this was very literally what we had with CentOS so I'm surprised at all the comments saying it's impossible.
As convenient as all of that would be just removing the registration would make this a lot easier regardless of the number of systems.
That is an interesting move. But with more and more organizations moving to dockerized services the real servers operating system is no longer that relevant.
I do know that rhel provides free access to a subset of rhel packages for docker image building but so many packages are missing that you can‘t reslly use it.
So next step for rhel, allowing dockerized rhel images would be nice. That is a real hurting point you created by your centos change!
So next step for rhel, allowing dockerized rhel images would be nice. That is a real hurting point you created by your centos change!
That's already a thing https://www.redhat.com/en/blog/introducing-red-hat-universal...
As someone who started testing things with UBI images, I have found them to not be that great in terms of predicting how things behave installed under CentOS or RHEL. There are a lot of seemingly minor packaging differences that cause annoying issues when you go to deploy the same stuff on a real RHEL box.
And as i said the rhel images for docker and supported packages in the registry is very very limited, you will miss a lot of packages.
I had to wade through a bunch of modals, and then the page kept jumping around...
Doesn't engender a bunch of trust.
Doesn't engender a bunch of trust.
After their killing of CentOS, I hope anyone who reasonably can avoids RHEL. I'm positive they're going to change policies again in the future and fuck over people who decided to go with this zero monetary cost RHEL offering.
> 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.
> 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.
>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 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.
You've obviously made the choice to hate, but for anyone else reading this comment, the CentOS announcement specifically mentioned at the time that an announcement like this was coming regarding expanded RHEL options. Not sure what more evidence is needed that it was the plan. If you're a conspiracy person go look at archive.org's version. If you believe archive.org is in on the conspiracy, well, I'm not sure what to tell you.
Not the OP, and I have no doubt they had plans to "expand" RHEL options
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...
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...
RH was under time pressure to announce the CentOS 8 EOL dates. Because we did not want more people to move to CentOS 8 during the holidays. The programs weren't ready and we felt it was important to get the CentOS Linux announcement out as soon as possible. We had many long discussions about this in the Red Hat internal memolist when CentOS news were announced. Please search the internet for Red Hat's memolist. It takes a lot of time to come up with free programs like this, thats the simple truth. You can choose not to believe this and wait for few years to see how these turns out. It is not about immediate revenue growth but how to make RHEL evolve as the next generation OS. If RHEL does not change it will be become obsolete sooner or later.
Cmon, drop the requirement to activate it with an account already, what year is this? No one is going to use this over Ubuntu, even if it is free, if there’s that extra step in there.
Works for my current use case. Will still keep my eye on Rocky.
If a developer gets a hold of a RHEL copy[legally] regardless of its subscriptions terms, he have all the rights to re-distribute it due to the nature of GPL2 licensing, only thing is he cannot claim to be IP/copyright owner of redhat assets like logo.
Red Hat has provided free RHEL downloads and licences for development use through their developer programme for nearly five years now. They do require that you sign up for an account on their website.
https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-d...
https://developers.redhat.com/blog/2016/03/31/no-cost-rhel-d...
While they are at it if they can also stop the shitty practices of requiring support account to see content on access.redhat.com for solutions to known problems that'd be great. This mostly affects their paying customers so there's that.
Possibly the login wall works as a gateway drug for CentOS users to register RHN account (and hopefully they could sell RHEL)
meh if you don't want to use centos stream then I would just switch to openSUSE Leap. Zypper is very similar to yum/dnf, so it's not like your switching to apt/apt-get or alpine apk and learning completely different package manager.
Thumbs up for OpenSUSE, RH should have taken an example from how closely SUSE operates with the community, sadly I think Red Hat is too big and too corporate to give a damn now.
I wish OpenSUSE has more love, but it's important to realize some differences are still there. Namely:
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...
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...
You can also use DNF on openSUSE: https://en.opensuse.org/SDB:DNF
Is openSUSE Leap more stable than CentOS Stream?
I would say they are the same (LEAP and Centos (not stream)), you can change instantly to SLES if you need too. Leap15 = SLES15, Leap15.1 = SLES15sp1 and so on.
It’s worth noting that this is only phase one of the program expansion. There are future announcements regarding academic institution licensing and research institution licensing (e.g. CERN).
How does rhel count these „up to 16 systems“? So if i am using 16 physical servers with at least two virtual vmware vms on each machine.
Is that setup still 16 systems or do they count the number of virtual machines?
Is that setup still 16 systems or do they count the number of virtual machines?
I bet 98% of the use cases for CentOS 8 can be more than adequately handled by CentOS Stream. And Rocky Linux (and probably a few other clones) are on the way.
I love this change. Will probably run things on RHEL now.
If still you need to login to access repos, same stuff.
What is RHEL?
Red Hat Enterprise Linux. RHEL is a stable platform for businesses to run their apps on; they port upstream code fixes to their kernel and distribution and offer support for a price.
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.
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.
Red Hat Enterprise Linux.
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.
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'd love to support RHEL financially, both on the server and on the development laptop. But I just don't trust that any of this extra cash flow they may see will go towards anything but 5% IBM dividends, obscene executive and sales salaries, with nothing left over for R&D and especially continued American jobs (IBM is basically an Indian company, now).
I hope my large government customers ditch RHEL for something else - maybe a derivative that's home grown.
I hope my large government customers ditch RHEL for something else - maybe a derivative that's home grown.
Until they change their minds in a few months/years.
I really wish they would just go 100% paid and stop pretending they care about anything free at this point.
RH isn't the company that it once was anymore.
Edit: I'm sure this is not a popular opinion but it is what it is.
Edit: I'm sure this is not a popular opinion but it is what it is.
>I really wish they would just go 100% paid and stop pretending they care about anything open/free at this point.
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"?
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"?
>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...
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...
That was more a nod to the whole CentOS debacle and the way RH is doing business the last few years, plus this article relating to the free part. Not really related to opensource as i doubt they'll be able to escape that aspect, if they could they would have probably done that already as well.
To be honest it broke my heart a bit when they where sold to IBM. But hey there is SLES and in my opinion a much better option with the free tumbleweed, leap and the paid SLES and all the free services like OBS, openQA and Kiwi....and no i don't use BTRF...XFS all the way down ;) But if i have the freedom to choose the solution it nearly always choose is FreeBSD, one exception...OracleDB where i use OracleLinux.
Licensed under the GPL is one thing -- intentionally obfuscated to make actual compilation difficult is compatible in letter but not in spirit of the license. Red Hat's citizenship in the FLOSS community varies from "savior" to "nuisance" depending on the project...
I have been a Red hat employee for more than 8 years and we never ever intentionally made projects difficult to consume by users outside of RH. More people using the open source projects works better for us as it provides free mind share, testing and feedback. For RH selling subscription for a popular/stable open source project is a way easier problem than a project which has no mind share. That being said sometimes it is very difficult to maintain projects and branches for external contribution depending upon the scope of project and the development workflow we use for it. It is very common scene in open source projects where contributors does not maintain the documentation etc properly for easy on boarding. I can go on for long time why it is not easy to do and we should improve on it for sure.
True, then Oracle made his own UEK...and now on OL you can choose between two Kernels....good job RH.
[deleted]
Percent-wise I don't think there is any other company that contributes as much to open source software, I do think it was a dick move from them but let's not conflate the things.
My comment wasn't really related to opensource, but in general to their new way of doing business.
Nothing wrong with changing the company's direction and trying to go full profit mode, just don't try to pretend everything's the same as before.
The change in company culture is probably real. Just an anecdata but I feel like over the years radhatters are behaving more and more corporatish compared with how it was years ago, then again that can be just the "climate" of the Internet nowadays.
That's the side effect of a company getting bigger. When a company hires a lot more and trying expand it is very hard hire only upstream contributors.
I'm thinking this news is related.
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.
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.
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
https://rockylinux.org/