[HN Gopher] Red Hat Goes Full IBM and Says Farewell to CentOS
___________________________________________________________________
Red Hat Goes Full IBM and Says Farewell to CentOS
Author : vanburen
Score : 165 points
Date : 2020-12-12 18:19 UTC (4 hours ago)
(HTM) web link (www.servethehome.com)
(TXT) w3m dump (www.servethehome.com)
| qz2 wrote:
| IBM sure knows how to piss off its potential customers.
| josho wrote:
| The intersection of centos users and IBM customers is likely
| quite small.
|
| Even the tech teams inside large organizations aren't IBM's
| customer.
| spijdar wrote:
| While CentOS users might not represent that many IBM/RH
| customers, I suspect CentOS's availability has contributed to
| RHEL being so widely supported.
|
| If fewer people, even people who will never pay, use CentOS,
| then (potentially) fewer people will explicitly target
| RHEL/RPMs, and there's a weaker case for enterprises adoption
| RHEL over its competitors.
|
| CentOS led to people learning "how to use RHEL". While RH is
| going to try to bring developers and other non-commercial
| uses into free licenses, I'm not sure this will be enough.
| xony wrote:
| IBM goes oracle way , they want more money
| leokennis wrote:
| Goes? Went, a loooong time ago.
|
| An IBM mainframe is shipped in two boxes: a small one and a
| huge one. The first contains the computer. The second one the
| pricing table.
| fortran77 wrote:
| Now that you can run Amazon Linux 2 in a VM on your own machine,
| we're simply switching to that. It's nearly the same system.
|
| https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/amazon-l...
|
| (And there's pre-built boxes for Vagrant, etc. Search the Vagrant
| boxes to see it.)
| bassman9000 wrote:
| We have an internal RHEL vs AMZ Linux 2 battle, because of the
| RHEL support (would be a no brainer for AMZ otherwise). And
| it's tilting, because we run almost everything in Docker now,
| and we're not entering the OpenShift/podman ecosystem.
| em500 wrote:
| AFAICT, Amazon Linux 2 is largely based on RHEL 7, not 8. So
| not at all nearly the same system. If you're "simply switching"
| from CentOS 8 to Amazon Linux 2, prepare to put some serious
| work into it.
| kim0 wrote:
| Sure enough, the community started https://rockylinux.org/ as
| quick as redhat killed it!
| chasil wrote:
| It is a tribute to name the scion of CentOS after one of the
| (deceased) founders, Rocky McGaugh.
|
| If I might suggest a subtle variation on the name and branding,
| it would be this:
|
| RockOS: It Rocks.
|
| A hard look at Springdale Linux is due, similar to the White
| Box Linux assimilation into CentOS.
|
| Oracle also needs to get the converter script updated for
| CentOS 8, preferably in a manner that switches update streams
| fluidly.
|
| https://linux.oracle.com/switch/centos/
|
| The ship is sinking, get in the life boats.
| easton wrote:
| That page claims the script works on CentOS 8, is that
| incorrect?
| teddyh wrote:
| That's "Deceased".
| chasil wrote:
| Thanks, fixed.
| cbm-vic-20 wrote:
| From that page:
|
| """ Q: Wait, doesn't Oracle Linux cost money?
|
| A: Oracle Linux support costs money. If you just want the
| software, it's 100% free. [...] Yes, we know that this is
| Oracle, but it's actually free. Seriously.
|
| [...]
|
| Q: Why are you doing this?
|
| A: This is not some gimmick to get you running Oracle Linux
| so that you buy support from us. [...] """
| chasil wrote:
| Oracle started up the photocopier on rhel because Red Hat
| bought jBoss.
|
| Larry really wanted to punish Red Hat, and he did.
|
| Red Hat people are still hypersensitive on the subject,
| believe me.
| rodgerd wrote:
| The only people who hate JBoss more than Ellison are the
| WebSphere sales team.
| nickpeterson wrote:
| Wow, I've never thought of the people that have to go to
| work every day and try to convince people to use
| Websphere. What a soul crushing job that must be..
| secabeen wrote:
| I think they also liked that the abbreviation could be RKEL,
| which is delightfully close to RHEL.
| qz2 wrote:
| Next step they'll stop publishing the RPM spec files or change
| the license on them.
|
| Edit: why the downvotes.
| bonzini wrote:
| They (we, I work at Red Hat) would have no engineering
| department the second after.
| justapassenger wrote:
| People can be replaced. Especially at big corporation.
| qz2 wrote:
| Yes but to be clear the folk that may make that decision
| may not be aware of that. I've been in that situation
| before myself.
| bonzini wrote:
| They do (I know them, and I have talked to them since
| Wednesday). That's not to say this was not a screwup, but
| I would say that rumors around the death of free RHEL
| rebuilds have been greatly exaggerated.
| qz2 wrote:
| After a PR fuck up this large I am disinclined to agree.
| bonzini wrote:
| I would be too, but I know the people.
| ikiris wrote:
| you might want to ask them where they're going now that
| no one wants to touch red hat with a 10 foot pole?
| [deleted]
| themodelplumber wrote:
| > Rocky Linux is led by Gregory Kurtzer, founder of the CentOS
| project
|
| That seems about as auspicious as one could reasonably expect.
| Awesome news.
| aritmo wrote:
| And CloudLinux is doing the same,
| https://blog.cloudlinux.com/announcing-open-sourced-communit...
|
| edit: RockyLinux and CloudLinux are joining forces,
| https://www.reddit.com/r/RockyLinux/comments/kanvwb/cloudlin...
| jacobwilliamroy wrote:
| Goddammit! I was planning a whole CentOS-based encrypted web
| service. SHIT!
|
| At least we haven't bought any hardware yet... back to the
| drawing board.
| deadbunny wrote:
| Why are you tied to CentOS?
| jacobwilliamroy wrote:
| There's no particular reason. The OS layer is just another
| variable which needs to be accounted for in the planning
| stage, so pulling the rug out like this is a nuisance.
| ldng wrote:
| Look up Springdale. It is essentially the same concept.
| jacobwilliamroy wrote:
| Thanks for the recommendation.
| sitzkrieg wrote:
| if only there is some other linux based software out there!
| tannhaeuser wrote:
| That was to be expected for a long time. Embrace (financing most
| of Linux development, with SuSE historically a close 2nd), Extend
| (introduce Linuxisms such as systemd, containers), Extinguish
| (make putting together all the F/OSS amounting to a complete O/S
| an art, make changes for the sake of it, sell "support").
|
| What's not answered is why _now_ , in the middle of an active
| CentOS release cycle? Smells like IBM/RH doesn't see growth in
| new enterprise customers/startups coming to Linux (going to
| clouds/k8s instead and focusing on creating Docker images for
| workloads). RedHat surely must've been fully aware that
| discontinuing CentOS would create a giant backlash. I guess, like
| me, few people haven't used CentOS as base for new builds anyway;
| OTOH corporate clouds (OpenShift, k8s) for big customers seems
| like an attractive market for IBM/RH.
|
| Edit: a good outcome of this catastrophe might be to shift focus
| towards POSIX, LSB, and other means for portability which
| historically had strong following in the Linux and BSD
| communities
| senko wrote:
| Financing development of Linux is a bad thing?
|
| Introducing Linuxisms in ... Linux?
|
| And the only thing they're extinguishing is a free (as in beer)
| distro that they controlled anyway (and choose not to continue
| putting resources into).
| jsperson wrote:
| The most frustrating part of Linux for me is all the damn mental
| CPU cycle I have to spend keeping up with the naming and
| positioning of the various distros. Often it borders on drama.
|
| The other day I commented that I took my Pinebook Pro off the toy
| shelf and loaded up Manjaro. I commented on HN about how much I
| liked the user experience. The first reply I got was something
| about the drama with some dude named Phil. Alternatively I'll put
| my head down for a while and forget about the lineage of the
| various options and then something will crop up about this or
| that distro is going away, being repositioned or whatnot.
|
| Why does this matter? Because I want to use it for real work and
| I don't want to spend time planning a long term OS strategy.
| There are other things to worry about. I'm far from alone in
| this. That's why folks reach for Mac OS and Windows.
|
| Downvote away, but I really do want to love Linux. I just don't
| want it to be so hard to love.
| AntiImperialist wrote:
| No, we don't always reach for Windows and macOS. Ubuntu LTS has
| served us well for decades.
|
| If you don't want drama, use software maintained by people who
| have a life and don't have time or energy for drama.
| lagolinguini wrote:
| I think the point was that CentOS _was_ one of those distros
| maintained by people who had a life... Maybe Cannonical won
| 't be around in the future either.
| Spooky23 wrote:
| CentOS is just a red hat clone. There are a few iirc.
| Yetanfou wrote:
| > Downvote away, but I really do want to love Linux. I just
| don't want it to be so hard to love.
|
| Folks don't go for proprietary systems like Windows and MacOS
| because of theatrics around distributions, they just choose one
| of those stolid long-time favourites like Debian, Ubuntu or
| Mint and ignore the squabbling. Those who want to get a more
| hands-on experience might go for Arch, Slackware or even LFS.
| detaro wrote:
| > _and I don't want to spend time planning a long term OS
| strategy._ [...]
|
| > _That's why folks reach for Mac OS ..._
|
| A conservative Linux distro choice is way more stable than Mac
| OS is in regards to "sudden" changes you need to deal with. And
| on the time scales we worry about CentOS or Debian, Windows has
| its pitfalls too.
|
| In all cases, if you need a long-term strategy, it's always
| going to involve some level of preparedness to handle a change.
|
| If you want to keep up with all the distros and their
| individual going-ons, that's your choice. You can use Linux
| just fine without doing so.
| detaro wrote:
| EDIT-that's-too-late-for-an-edit: To make the Windows example
| specific, there's a lot of companies that built their
| products on Windows 7 Embedded that would _love_ to be on
| CentOS this week instead.
| indymike wrote:
| I've been using Debian or a Debian derivative for over 15
| years. At first, I wondered if it was a good choice because
| RedHat and SuSE were the "professional" distos. Debian was
| different and when Ubuntu came out, it was like Debian, but
| with some useful closed-source stuff. There's been drama, but
| it's not nearly so bad as some of the evolution that MacOS and
| Windows users have had to deal with. The security improvements
| on MacOS have really made doing simple things like a Zoom
| conference painful while Windows userspace is devolving to
| something that reminds me of Linux in 2005 or so where every
| window had it's own UI style and the userspace was a mess of
| competing ideas and ecosystems.
|
| Meanwhile over on Debian/Ubuntu/PopOS/Plasma, I can finally run
| the latest games (thank you Steam & Proton!), edit video with
| pro grade tools (thank you DaVinci) and I still have a great
| coding environment... Oh, and thanks to cloud based office
| software, that's no longer an issue.
| irateswami wrote:
| Ubuntu is seriously an amazing achievement and while I've
| used plenty of distros, nothing compares in terms of getting
| work done. I'm not an OS engineer and have no desire to get
| granular with my OS, I just want to be able to load it up and
| do stuff. The linux community, however, is loaded with OS-
| enthusiasts who don't understand the difference between using
| a tool and fetishizing it.
| bmurphy1976 wrote:
| How does MacOS make zoom conferences painful? That's a
| strange claim to make.
| redler wrote:
| I suspect they're referring to the fact that after the Zoom
| app is updated, you may find yourself in a meeting but
| unable to share a window because the updated app no longer
| has the "Screen Recording" privacy entitlement. Turning
| that on again requires quitting the app and therefore
| leaving the meeting.
| wtallis wrote:
| That does sound annoying. Though to be fair, Apple has
| plenty of reason to distrust Zoom updates. I'm a bit
| surprised there's no way for Zoom to re-try screen
| recording without re-launching the app. Is that a
| fundamental limitation of Apple's security model, or a
| failure of Zoom?
| indymike wrote:
| It is all Apple. When you change a permission, MacOS
| forces you to quit and re-launch the app.
| indymike wrote:
| This is exactly the issue. It's especially problematic
| when you are hosting a private meeting. When you exit, it
| will hang up on everyone, unless you hand control of the
| conference to a participant.
| indymike wrote:
| Not a strange claim. Having to exit the conference to give
| the Zoom app permission to share the screen is painful, and
| if the Zoom app updates, you have to do it again. That
| means you have to leave the conference to permission the
| app, and if you are the host, hand off control to a
| participant so the conference is not ended early.
| [deleted]
| symlinkk wrote:
| Are you like this with cars too? "Gosh there's just so many
| brands and models to choose from, I wish there was just one
| choice so I didn't have to think or make a decision"
| colejohnson66 wrote:
| With cars, they all do one thing good: drive. The other
| features are just that: features. With Windows vs macOS vs
| Linux, you're dealing with software incompatibility and
| having to find replacements.
| croh wrote:
| Copying my comment from other post -
| https://news.ycombinator.com/item?id=25395187
|
| > Recently I moved to Apple Macbook Pro 2019 (FYI before that I
| was using Linux Mint for years without any drama). But after
| using this very expensive MBP, I am not happy at all. Hardware
| is the best in class while keyboard is the worst in the class.
| But my biggest complain is keyboard layout. It is not ergonomic
| at all. In windows/linux, WINDOW key manages window manager
| while CTRL, ALT can be used to manage applications. On
| internet, many places it is mentinoed that, use apple COMMAND
| key as control key and OPTION key as alt key. Ok thats fine.
| But this behaviour is not consistent at all across apps. Many
| apps use CTRL key to control application additional to COMMAND
| key(e.g. in chrome/vscode, toggling tabs can be done using
| CTRL+TAB, not COMMAND+TAB). And this CTRL key is only one side
| of spacebar, very very unergonomic. Additionaly if you are a
| touch typer powered with mechanical keyboard, you can press
| CTRL key on windows layout using wrist. This is not possible on
| Mac as its first left key is FN.
|
| After using MBP for couple of weeks, my hand literally hurt
| like mentioned in video. I dont think I can operate MBP for
| hours without looking at keyboard. In Windows you can do
| everything with mouse only. In Linux you can do everything with
| keyboard only. In mac, you need both and your hand hurts.
| Talanes wrote:
| >Additionaly if you are a touch typer powered with mechanical
| keyboard, you can press CTRL key on windows layout using
| wrist
|
| You can do that? If I get my wrist anywhere near high enough
| to hit a key, my fingers are about two imaginary rows above
| the function keys.
| croh wrote:
| I can. I did little bit practice though initially. It saves
| pinky from strain greatly.
| gameswithgo wrote:
| yeah for people just wanting to do work and not have the os be
| the hobby it is trying at times.
| iso1631 wrote:
| I've used Ubuntu for 12 years, Debian for 9 years before that.
| Debian is still going fine. What drama?
| Spooky23 wrote:
| Distros are always full of drama. The stakes are low so the
| nonsense is high.
|
| It's easy to get sucked in.
| jancsika wrote:
| Is there a story of someone _actually_ getting sucked into
| doing, say, Debian maintenance within the past five years?
|
| I mean, they have a command line program to report a bug.
| That and their monstrously complicated packaging apparatus
| would make me think someone at Debian considered the
| sucking-in of people to be unethical and thus designed
| their maintenance polices to prevent it.
| tomc1985 wrote:
| > monstrously complicated packaging apparatus
|
| Huh?
|
| .debs are gzip'd tar file with predictable top-level
| folders and some manifest files. An APT server can be as
| simple as an FTP site, again with a predictable hierarchy
| and some manifest files.
|
| Keysigning gets a bit messy but it is still relatively
| simple.
|
| You can set up your own private package repository in
| minutes using nothing more than ftpd, gpg, mkdir, and
| vim.
|
| The documentation is clear, comprehensive, and relatively
| easy to read.
|
| How is this "monstrously complicated"?
| indymike wrote:
| There's a difference between software evolving and drama.
| I'm trying to remember an upgrade to Ubuntu or Debian that
| led to as much manual intervention as the latest update to
| MacOS or Windows 10.
| qz2 wrote:
| Never seen any drama in the freebsd camp. It's utterly
| boring. Which is how I like it.
| fortran77 wrote:
| Huh!? There was some amazing drama here, during the first
| ports of the early 90s.
|
| https://www.unixmen.com/freebsd-vs-openbsd/
|
| and then the lawsuits:
|
| https://www.freebsd.org/doc/en_US.ISO8859-1/articles/expl
| ain...
|
| https://klarasystems.com/articles/history-of-freebsd-
| part-2-...
| rnd0 wrote:
| Approximately 30 years ago.
|
| Mandatory must-care-about drama since then?
|
| No, not really.
| mnd999 wrote:
| There's always some drama. Maybe not of the must-care-
| about but there's always something.
|
| The ASLR patch comes to mind, as does the KSE / libthr
| thing.
|
| Equally there have been some very grown up moments. The
| Matt Dillon / DragonflyBSD fork comes to mind.
| rnd0 wrote:
| It's easy to avoid, too.
|
| I haven't had to deal with any drama using Debian or the
| BSDs, personally speaking. Which I have been since 2000 or
| so.
| Fnoord wrote:
| Theo from OpenBSD is known to cause controversy, and
| drama. Its how OpenBSD was _born_.
|
| That is the best example I can come up with. I do
| remember Debian libc being broken, as well as the
| cryptography, but I would not say that was drama.
| fartcannon wrote:
| Your complaints would make a great infomercial setup.
|
| "Are you tired of your Linux distro being bought out and
| crushed by IBM exactly one time in history?" Cut to a big dopey
| confused person shrugging. "Well then try Apple!" Dopey person
| smiles. Star wipe.
| Spivak wrote:
| I mean the writing seems to be on the wall that someone is
| going to buy Canonical and crush Ubuntu at some point in the
| medium-term.
| tobinfricke wrote:
| Just use Ubuntu
| nullsense wrote:
| Then what about the snap drama?
| monsieurgaufre wrote:
| My snap folder only has chromium in it. Like probably most
| users who don't (and shouldn't) care about snaps.
|
| The snap drama is a ideological purity contest by people
| who should know better (aka use something else than Ubuntu
| if that pisses them off that much).
| mceachen wrote:
| Don't use snap.
| xet7 wrote:
| Snap drama is just writing comments about it without
| action.
|
| It's not like OSS community would have rushed to provide
| alternative packages for Flatpak, AppImage, deb etc.
|
| Snap automatic updates are still the fastest way to update
| servers with latest security etc updates, keeping servers
| secure. That's the reason usage of Snap packages is
| increasing.
|
| With Docker, recent drama was Docker Hub rate limits, so I
| had to move Docker base images from Docker Hub to Quay.io,
| so that Docker images could be built successfully.
| autocorr wrote:
| That's an interesting perspective, I've found the opposite. I
| distro shopped a lot around ~2006, settled on Ubuntu then moved
| to Debian for project philosophy reasons. It's great because I
| haven't had to think about "how do I install this again?". Same
| web page, same link to netinstall image, same prompts to
| install.
|
| It's fun to try other things like NixOS and GuixSD, but also
| have the warm blanket of "just put Debian on it" to fall back
| to.
| hn_throwaway_99 wrote:
| You seem to be massively overcomplicating things. If you don't
| want to worry about the "distro drama", then don't. Just use
| one of the major distros (e.g. Debian or Ubuntu) and move on.
| nix23 wrote:
| Yeah true, the distro i had the longest time was arch and
| debian, then i changed to FreeBSD (because i can and i want),
| but on my laptop i need additionally a Linux...but installing
| arch when my main interests is *BSD..no, so i installed
| openSUSE tumble and that's it. The whole distro bs is just
| plain stupid, use what works and has a stable past...that's
| it.
| Macha wrote:
| CentOS was certainly a major distro and now we're involved
| with drama for it.
| pessimizer wrote:
| CentOS has been around for a decade and a half. It hardly
| qualifies as drama when your OS fails to remain completely
| stable and dependable for more than a decade and a half.
|
| With the number of changes that have happened with Apple's,
| Microsoft's and Google's various OSes over that period it's
| hard to say that GNU/Linux isn't being held to a higher
| standard here. CentOS being the trademark-stripped knockoff
| of a corporate OS _is the reason_ for the instability -
| when you deal in corporate OSes, you 're subject to the
| business strategies of their sponsors. Some would say
| (weasel words) that the strategies of the sponsor of CentOS
| have been the source of instability and conflict across
| Linuxen for a long time now.
| BossingAround wrote:
| > It hardly qualifies as drama when your OS fails to
| remain completely stable and dependable for more than a
| decade and a half
|
| Isn't stability and dependability the precise reason of
| CentOS popularity? Do you have any source on it not being
| stable and/or dependable?
| chefkoch wrote:
| Just check back in three months and there will be a drop in
| replacement for CentOS. No need to follow the news now
| every day, it's not an election.
| [deleted]
| rualca wrote:
| > If you don't want to worry about the "distro drama", then
| don't. Just use one of the major distros (e.g. Debian or
| Ubuntu) and move on.
|
| +1 on Debian. It's as drama-free as it gets. I mean, the
| distro is criticized for being too boring and too stable and
| too rock-solid and too unsurprising. Those descriptions are
| also used to describe power lines and sewer lines, i.e.,
| reliable infrastructure.
| doublepg23 wrote:
| Did you miss the systemd drama? There was a new distro
| created out of it...
| michaelmrose wrote:
| If you are a regular end user You can safely ignore it
| and just use systemd or not and not worry too much either
| way.
|
| Whats the worst case scenario? You find that you don't
| like the choice you made and spend 2 hours switching to
| the other option?
| rodgerd wrote:
| More like "oh hey encrypted LVM doesn't work and the
| package maintainer is refusing to allow fixes because he
| hates systemd and is indulging in maintainer terrorism to
| try and block it."
| deadbunny wrote:
| And I'm sure the 3 people using it really like it.
| qz2 wrote:
| No point in being popular and unhappy :)
| pessimizer wrote:
| The systemd drama is redhat drama. The pulseaudio drama
| was redhat drama. The glibc drama was redhat drama. This
| is redhat drama. It's not all redhat drama, sometimes
| it's Microsoft drama or Gnome drama, but it's funny: all
| of the sources have really good relationships with each
| other and commingle their drama until it's nearly
| indistinguishable. Get involved with one of them and you
| now have dependencies on all of them.
| Spivak wrote:
| The specific systemd drama the parent is referring to was
| really Debian drama and the requirements put on
| maintainers to support alternative init systems. If
| upstream drops support for non-systemd setups do the
| maintainers have patch in support? If upstream now has a
| hard dependency on systemd do maintainers have to patch
| it out?
|
| Red Hat wasn't involved in any of the drama outside of
| being the ones writing and funding OSS software for
| themselves.
| detaro wrote:
| But as a user I basically didn't have to care about the
| details and the "drama" aspects of that drama (I had the
| result to deal with of course)
| jasonjayr wrote:
| Redhat _was_ involved because they heavily maintain some
| of the upstream packages that put in a hard systemd
| /logind requirement (GNOME), thus forcing Debian into the
| uncomfortable position of taking on a large compatibility
| project, when upstream could have instead taken small
| patches to continue to maintain compatibility with non-
| systemd systems.
| kbenson wrote:
| Systemd in general makes me sad. It feels like the
| complete rewrite that happens only for the people doing
| to finally learn all the project needs at the end, and
| immediately need another rewrite, but _nobody_ has the
| stomach for it now.
|
| Don't get me wrong, I think the authors are and we're
| probably the best authorities on what is and was needed
| in an init system, but the problem space was so poorly
| documented and understood because of all the crazy custom
| she'll init scripts people were using that they just kept
| having to tack on weird directives in piecemeal ways,
| until were left with what we have now.
|
| What the world needs is for the systemd authors to take
| all that knowledge an apply it to a new init system in a
| sane way, but nobody had the will to go through that
| again, most likely especially them.
| shawnz wrote:
| Who is asking for a rewrite of systemd? From what I have
| seen, there are two camps: Either you believe systemd is
| fine, or you believe sysvinit never should have been
| replaced or should have been replaced with something
| totally different than systemd with a much smaller scope.
| michaelmrose wrote:
| There are 2 major problems cache invalidation, naming
| things and off by one errors.
| subhro wrote:
| /me meekly says
|
| Gentoo anyone?
| jancsika wrote:
| > The first reply I got was something about the drama with some
| dude named Phil.
|
| At least for Windows, can't you just quickly compare the
| ethical universes? I'm assuming that Phil didn't embrace-
| extend-extinguish other distros, Phil didn't secretly change
| Skype to break the encryption for LE, and Phil didn't upgrade
| the distro to do constant, inescapable telemetry and update
| arbitrarily downloading Gigs of data such that it interrupted a
| user's live broadcast.
|
| In other words, if your decision is between Phil's distro and
| Windows, Phil's distro wins so it's the end of the story. And
| if the HN trolls you're responding to aren't claiming a 1:1
| feature correspondence with "ethical" distro vs. Manjaro, who
| cares?
| a1369209993 wrote:
| > In other words, if your decision is between Phil's distro
| and Windows, Phil's distro wins so it's the end of the story.
|
| As the saying goes, Linux is like democracy: it's the second
| worst (widely-used) system ever, because all of the others
| are tied for first.
| Macha wrote:
| I don't think Mac OS and Windows are freer from long term
| maintenence, whether it's Apple doing stuff like phasing out
| APIs for OpenGL, migrating to M1, Gatekeeper requirements and
| noose-tightening, or whatever they'll expect you to keep up
| with next year.
|
| Likewise on the Windows side, the SKUs vary from release to
| release, group policies come and go, and generally they've
| increased their push into seeing Windows as a way to promote
| their other services and don't really care what you want from
| it.
| dleslie wrote:
| fwiw I am a fellow Pinebook Pro user who likes Manjaro. I use
| it daily for Emacs and C programming.
|
| Ignore the drama and the dramatists. The software works well,
| and better than the alternatives on that hardware.
| 29athrowaway wrote:
| Minor distros fit specific use-cases better but are more likely
| to disappear, major distros are here to stay. That's the
| tradeoff.
|
| But in the the Microsoft world, you at some point had Windows
| Mobile and Windows phone, and developing apps for those is the
| true meaning of being alone.
| Blikkentrekker wrote:
| > Downvote away, but I really do want to love Linux.
|
| This would be the problem; you treat _Linux_ as a platform that
| one is supposed to love or not love as a hole.
|
| _Linux_ is not a platform; it s a component shared between a
| great many different platforms that are often quite far apart
| from one another.
|
| These platforms often also share other things, or not, and
| don't _Windows_ and _FreeBSD_ also share several components?
|
| I've noticed a common belief that completely unrelated,
| independently started and operated platforms have an obligation
| to cooperate because they share a single component, which most
| of them also heavily patch and modify.
| acomjean wrote:
| Ars technica has a guide on where to go after CentOS :
|
| https://arstechnica.com/gadgets/2020/12/centos-linux-is-gone...
| doublepg23 wrote:
| The author of this article is on an excellent podcast called
| 2.5 Admins [0], highly recommended.
|
| [0] https://2.5admins.com/
| michaelmrose wrote:
| You don't have to evaluate every possible option before picking
| one any more than you have to read about every make and model
| of car or laptop but you probably ought to read about the one
| that you pick and manjaro is run by skeevy unprofessional
| people.
| marmot777 wrote:
| What happens to Fedora in all this? That project okay?
| xony wrote:
| Fedora was long dead ? haven't heard since 2008
| freedomben wrote:
| Fedora won't be changing at all. It's always been the upstream
| of the next _major_ version of RHEL. Now it will be the
| upstream of the next _major_ version of CentOS and CentOS will
| be the upstream of the next _minor_ version of RHEL. By the
| time stuff makes it to CentOS it will have had lots of time to
| bake, will have passed RHEL QA, CI, etc.
|
| If you want to read more details about the changes, I wrote a
| long blog here: https://freedomben.medium.com/centos-is-not-
| dead-please-stop...
| cutler wrote:
| I hope I don't end-up having to switch my servers to Ubuntu.
| yum/dnf is just so much easier than apt-get.
| CharlesW wrote:
| Question from someone who doesn't use Linux much: Are package
| managers distro-specific, then?
| Shared404 wrote:
| > Are package managers distro-specific, then?
|
| Technically no, effectively yes.
|
| You _can_ install and use different package managers on
| different distros, but with the exception of things like
| cargo it 's highly recommended to not, as you are likely
| going to break your system.
| inimino wrote:
| Yes. Package management is most of what a distro does.
| doublepg23 wrote:
| Package managers are one of the main things that define a
| distro. The big split is between packaging formats (DEB and
| RPM [0]) and then there are package managers for that for
| that (apt* for DEBs and yum, dnf, zypper etc. for RPMs [1]).
| You could run a foreign package manager on any distro, there
| even exist ones for that purpose [2], but it's ostensibly
| considered a defining feature for a distro.
|
| [0] There are more of course, but those are the big two.
|
| [1] I'm really only familiar with the Debian/Ubuntu space
| (Deb)
|
| [2] See flatpak, snap, and nix/guix. Also some distros like
| Bedrock Linux let you have completely foreign environments
| mixing together.
| deadbunny wrote:
| Kind of. When you hear people say they use a "Debian based"
| distro they'll be using apt as their package manager.
|
| You have 3 main "base" distros/package mamagers:
|
| Debian/apt
|
| RHEL/yum/dnf
|
| Arch/pacman/pkgbuild
|
| There are of course many more but these are the overwhelming
| majority.
|
| This means if I wanted to make my own distro I could do as
| little as take Debian stable as my upstream, rebuild a few
| packages with a s/Debian/MyDisro/g and change a few default
| packages and call it that.
|
| Or I could track a mix of packages from Debian testing and
| stable.
|
| Or I could decide I prefer to build everything my self but
| still use apt for my package manager.
|
| This is of course turtles all the way down eg: Mint is based
| of Ubuntu which is based of Debian.
| KyleJ61782 wrote:
| For all intents and purposes, yes. Besides making software
| easy to install, package managers figure out all the
| dependencies that a given package requires and install those
| as well. Can you install yum/dnf on Debian? I'm sure there's
| a way to do it. But good luck handling all the dependencies
| for a given package. Plus, there will be file conflicts when
| dnf installs a base dependency that apt already installed.
|
| In other words, nothing good comes from trying to install two
| different package managers on one system.
| aftbit wrote:
| What did CentOS offer that Debian did not? In other words, if
| you're not paying for RHEL support, why would you want to use
| RHEL?
| justahuman74 wrote:
| Some expensive software will demand you use particular distros
| for them to support you
|
| Example: https://www.synopsys.com/support/licensing-
| installation-comp...
| kdump_8 wrote:
| There is a lot of software that only officially runs on RHEL-
| likes. E.g. Oracle Database only supports on RHEL-likes and
| SLES.
| bluedino wrote:
| Vendor support. We have a couple software packages that we run
| that require CentOS/RHEL.
| freedomben wrote:
| Number one for me is familiarity since I have a long history
| with Fedora and CentOS.
|
| Secondly though selinux (once you learn to use it) is so
| powerful. I have seen it stop attacks in their tracks or render
| them inert (unable to call their C&C server for example because
| selinux blocks the socket attempt).
|
| 10 year support is also icing on the cake, although I typically
| upgrade a year or so after a new major release.
| syshum wrote:
| Our Reasons for CentOS over Debian
|
| 1. 10 year vs 5 year LTS
|
| 2. Vendor compatibility, many enterprises non-free software
| packages only offically support RHEL / CentOS
|
| 3. Familiarity with tooling, while it is all Linux Debian and
| CentOS do have ALOT of difference when it comes to
| administration of the system. Due to 1 and 2 outside of web
| development, in the US most enterprise users of Linux (ERP
| System, databases, enterprise Java Apps, etc) are a huge part
| of CentOS's user base
| xeeeeeeeeeeenu wrote:
| CentOS releases were supported for much longer (10 years vs 3+2
| years)
| joecot wrote:
| Let's say you run RHEL on your production servers. You pay for
| licensing those servers, which gives you Red Hat support, and
| also because you have proprietary software which is only
| supported on Red Hat.
|
| You pay a pretty penny for those production servers. But you
| also need development servers, and staging servers. For those
| servers, RHEL would be a gigantic waste of money. It's the
| production servers you need enterprise support for, none of the
| rest.
|
| CentOS was a downstream release of Red Hat, with the same
| packages from Red Hat compiled. It was, for the most part,
| identical to Red Hat without the support. This meant you could
| develop on CentOS Dev Servers and test deployment on CentOS
| Staging servers, and expect it to work exactly the same when
| you sent it to production. Lots of less licensing costs, same
| results.
|
| Now, CentOS Stream will be upstream of Red Hat. Instead of
| getting the same packages as Red Hat, now you're getting the
| testing packages of Red Hat. You can no longer expect to get
| the same results from CentOS stream as from RHEL. The end of
| life for updates for existing CentOS releases has also been
| moved up drastically. By all appearances, Red Hat and IBM are
| essentially forcing companies to license and use RHEL on their
| dev and staging servers, by making CentOS Stream unusable for
| it.
|
| Lucky for many, Canonical went and got Ubuntu certified for
| many of the same proprietary hardware and software systems that
| were previously only supported for proprietary linux distros.
| This means your dev, staging, and production can all be the
| exact same distro, and the only difference is which servers
| you're paying for Canonical support for. This is a recentish
| change though, so many companies locked into Red Hat / CentOS
| because of the clear path that was established between
| Development and Production. And certainly not every proprietary
| software/hardware is supported on Ubuntu, yet. Lots of
| companies won't switch (the structure of Red Hat to Debian is
| pretty drastically different), and IBM is counting on that.
| freedomben wrote:
| I mostly agree with you (minus the cynicism), although CentOS
| Stream for dev and staging is still a pretty reasonable
| approach, in fact a good idea as if the next version of RHEL
| will break your app, you'll find out in development.
|
| If you're already a CentOS/Red Hat shop there will be much
| easier options than Ubuntu (nothing against Ubuntu, I use it
| for some things and it's great, but it's pretty different so
| all your automation will have to be updated for the most
| part).
|
| If you don't want Stream then I expect Rocky Linux will be
| available long before end of 2021, and RHEL might be free for
| your use depending on what they announce in the next month or
| two.
| hrez wrote:
| The easiest path forward is to convert to oracle linux. You
| don't even have to reinstall centos for that. Being rhel
| clone it's already supported by many commercial apps and
| unsurprisingly by oracle apps.
|
| Given that's an option, this recent redhat announcement is
| really shooting themselves in the foot.
| elktea wrote:
| no random patches to software from debian maintainers
| AnssiH wrote:
| Familiarity with tooling, as I'm using Fedora as my desktop
| distro.
| freedomben wrote:
| This is the primary reason I use CentOS and RHEL as well. If
| you are a Fedora user especially I wouldn't write off CentOS
| stream so quickly as it might match your needs just fine. If
| it doesn't Rocky Linux seems quite promising as well (though
| very early days still). More info elsewhere on this large
| thread or in this blog post:
| https://freedomben.medium.com/centos-is-not-dead-please-
| stop...
| indigodaddy wrote:
| I'm a little surprised that Jim Whitehurst would let this happen.
| fanatic2pope wrote:
| The IBM bean counters have spoken and Red Hat is to be squeezed
| of every last drop of revenue. I bet they are demanding Red Hat
| employees apply for patents for everything they are working on
| too.
| jlgaddis wrote:
| I don't think it's fair to attribute this to IBM.
|
| An outcome like this was expected as far back as 2014 -- it just
| took longer than most of us expected.
|
| As I've said before, CentOS hasn't been a "community" enterprise
| operating system for a long, long time now.
| freedomben wrote:
| _Disclaimer: I work for Red Hat but I 'm here entirely with my
| own opinion_
|
| My God, it's been a long time (if ever) since I've seen so much
| misinformation out there. I mostly blame Red Hat for the very
| poor delivery, but tech people are not immune to the tendency for
| dramatizing, misrepresenting, and polarizing. Please stop
| spreading this. CentOS is _NOT_ dead. CentOS is changing, but not
| all that much (yes, really).
|
| I'll do my best to answer questions here, but I'm also going to
| rush a blog post to try and get it out ASAP that corrects a lot
| of this.
|
| Edit: Here's the blog post. Excuse typos and other things, I
| rushed this ;-)
|
| https://freedomben.medium.com/centos-is-not-dead-please-stop...
| qz2 wrote:
| It's a bit arrogant telling everyone that they're wrong when
| you're changing the entire purpose of a product. It's dead.
|
| It was accurately described already in the press release and
| that killed it.
|
| If there is backtracking it will make it more dead as it would
| break trust.
|
| It's dead. You killed it some more here by shouting down the
| community.
|
| Edit: to clarify I have over 100 CentOS boxes which will not be
| running CentOS or RHEL next year.
| 8organicbits wrote:
| > Edit: to clarify I have over 100 CentOS boxes which will
| not be running CentOS or RHEL next year.
|
| What distro(s) are you thinking of migrating towards?
| qz2 wrote:
| Ubuntu LTS at the moment.
| joecot wrote:
| Sure. Since you say this is not a big deal and CentOS is not
| dead but is just changing, I really only have 2 questions:
|
| 1) What in your opinion were the main use cases for CentOS
| before this change announcement?
|
| 2) How do you think CentOS Stream is still viable for those use
| cases?
| freedomben wrote:
| Great questions, thank you. It may take me a bit to answer,
| but I will :-)
| freedomben wrote:
| Ok ready to answer.
|
| 1) I obviously can't speak for anyone but myself here, but in
| my use case, which I think is pretty common, is to use CentOS
| for production deployments of various web apps and services
| where a person prefers the rock solid stability of RHEL
| without incurring the cost, and does not need support to go
| along with it.
|
| 2) I explain this in depth in this blog post which is up now
| ( https://freedomben.medium.com/centos-is-not-dead-please-
| stop... ), but the short version is that CentOS Stream is
| basically going where RHEL used to be. If RHEL was too
| bleeding edge for you, then CentOS Stream will be too, but
| otherwise it will be approximately the same as RHEL used to
| be. I consider RHEL and CentOS to be pretty equal, with
| CentOS lagging a bit behind. Now they will be pretty equal,
| with RHEL lagging a bit behind. Packages going to CentOS are
| packages that would have gone directly to RHEL previously.
| tehbeard wrote:
| > Before stuff goes to CentOS Stream it has passed RHEL QA
| and CI.
|
| Do we have an official word on that? Because it feels like
| QA could just as easily be priority tasked on the next
| point release RHEL and starve stream of QA while it carries
| on ahead. I guess this boils down to the workflow which
| there doesnt seem to be a simple guide of with this news.
|
| And no, I wouldn't agree that they just swapped places.
| CentOS stream is a rolling release. Unless I am mistaken
| that's not how RHEL is built right now.
|
| I can see a reason for swapping them in that adding RHEL
| goodies/licencing into the free version is easier than
| removing, but the release cycle change, dropping CentOS 8
| and as you admit, absolutely shambolic official press
| release, with lines that reek of a salesperson trying to
| squeeze out a bonus, do not inspire faith.
| cesarb wrote:
| > I consider RHEL and CentOS to be pretty equal, with
| CentOS lagging a bit behind. Now they will be pretty equal,
| with RHEL lagging a bit behind. Packages going to CentOS
| are packages that would have gone directly to RHEL
| previously.
|
| There will be another small difference: the number of
| updates. Just for fun, I started a centos:8 image in
| podman, installed the package which switches it to centos
| streams, and ran an update (which by the way partially
| failed with an error message, IIRC it tried to change /proc
| in a way podman doesn't like). Then I looked at the version
| of one of the updated packages before and after the update
| (IIRC it was bash), and looked at its changelog. There were
| several releases between these two versions, and I would
| expect each one of them to appear separately as an update
| within CentOS Stream.
|
| That is, packages that would have gone directly to RHEL
| previously will be going to CentOS, but not all packages
| going to CentOS will be going to RHEL; we will also be
| getting all the intermediate steps.
| kcb wrote:
| It's clear and literally self-described as a "development
| branch". To have anyone try to spin that as more stable
| and suitable for production is disingenuous.
| quietbritishjim wrote:
| I'm sure other commenters will put it much better than I could,
| but for those people that use CentOS for the purpose of a
| stable long term release, surely it is dead. The distribution
| now being called "CentOS" is almost at the opposite ends of the
| scale in terms of stability. The fact they've called this other
| thing the same name is purely marketing.
|
| If you destroy something then create something entirely
| different with the same name then the fact remains that you
| still destroyed the original thing. That's not dramatising or
| hyperbole.
| freedomben wrote:
| > _The distribution now being called "CentOS" is almost at
| the opposite ends of the scale in terms of stability._
|
| No, this is totally wrong (which is why I'm trying to correct
| it). CentOS will be where RHEL used to be. It is trading
| places with RHEL. It's not "the opposite end of the scale in
| terms of stability." CentOS will be roughly a single minor
| point release ahead of RHEL.
|
| Please read more about because that is super misleading and
| others are seeing things like this and propagating them:
| https://freedomben.medium.com/centos-is-not-dead-please-
| stop...
| ikiris wrote:
| Saying this repeatedly does nothing to make it actually
| true.
| freedomben wrote:
| I agree! Saying it's false repeatedly likewise doesn't
| make it false.
|
| Where am I wrong? Can you point out my error and make a
| case for your position? What makes you think RHEL is
| still "stable" but suddenly a distro a tiny bit ahead is
| now wildly unstable?
| wizee wrote:
| It's swapping places with RHEL beta, not RHEL. Not calling
| it a beta doesn't not make it a beta. It's directly taking
| the role that RHEL beta releases used to have (ie. be a
| point release ahead, and be for the public to test and
| report issues before going to stable RHEL).
|
| Using outdated packages doesn't make a distribution stable.
| It's stable when its combination of packages and
| configuration has already been tried by a bunch of people,
| and confirmed to work, or has had its issues thoroughly
| documented with effective workarounds.
| ghaff wrote:
| Rather than "stable long term release," I would phrase it as
| a "dot release frozen in time as much as possible modulo
| serious bugs and security fixes." Which is not the general
| direction that software is headed in. Changes going into
| CentOS Stream will have gone through both QE testing. So,
| yes, it is different but, increasingly, most of the software
| you use will be using this type of model. Certainly SaaSs
| don't let you choose a dot release for the most part.
| cesarb wrote:
| > Rather than "stable long term release," I would phrase it
| as a "dot release frozen in time as much as possible given
| serious bugs and security fixes."
|
| Which is exactly what we want.
|
| > So, yes, it is different but, increasingly, most of the
| software you use will be using this type of model.
| Certainly SaaSs don't let you choose a dot release for the
| most part.
|
| Not all of us are happy with having to follow the update
| treadmill. Software is a tool, like an electric drill; one
| doesn't update their electric drill every day, otherwise we
| would be wasting all our time updating and dealing with the
| fallout of updates, instead of drilling holes in wood. If
| you develop (or do anything) on top of software, you want a
| stable base, instead of one shifting all the time; one
| builds castles in rock, not in quicksand.
| detaro wrote:
| > _but not all that much (yes, really)._
|
| Cutting 8 years(I think? have something like 2029 in the back
| of my head) of support from the thing a bunch of people _just_
| moved to, with no publicized plan what they 'll have to move to
| instead in the next months(?), doesn't sound like "not all that
| much" for the kind of environments I've seen CentOS in. What's
| the plan for them?
| marmaduke wrote:
| > the thing a bunch of people just moved to
|
| Yep, if this had been for 7, it would've been just "meh" and
| move on to Arch BTW or something. But I just reinstalled new
| servers to move to 8 and now that was a waste of time.
| freedomben wrote:
| This is actually the big area where I think the criticisms
| are right and fair. Dropping 8 years was uncool.
|
| Moving to Stream is an option immediately (see post[1] for
| more information about how CentOS is NOT unstable or "the new
| Fedora" or whatever else everybody is saying), but there are
| also forthcoming announcements about new free RHEL subs for
| individuals and edu institutions and the like. I don't know
| anything about those. I personally think it was terrible to
| announce the CentOS changes without those to accompany, but
| hey if I ran things everything would be perfect :-D
|
| [1]: https://freedomben.medium.com/centos-is-not-dead-please-
| stop...
| ikiris wrote:
| Don't care. Nothing I run will ever run a red hat product
| again, and most of the people I've talked to feel similar.
| detaro wrote:
| Thanks. Luckily not my personal problem (or if it is nobody
| has told me yet...), but knowing how much hassle goes into
| any major upgrade (even if it's smooth sailing technically)
| in places with overly conservative processes, I hope those
| paths and changes get clearly communicated.
| freedomben wrote:
| Totally agree. This has the potential to be a nightmare
| of epic proportions. I strongly wish Red Hat hadn't done
| that.
|
| At the same time if you take _any_ piece of free (as in
| beer and speech) piece of software and don 't pay a
| vendor promising support, you are kind of taking a risk
| that whoever is doing work for you for free might decide
| to stop. In no way does that take Red Hat off the hook
| here, but it is something I consider.
|
| I've got a non trivial migration myself to handle before
| next December. Depending on how well Stream goes in my
| testing (so far it's been flawless but I'm not totally
| done with testing yet) and depending on what RH announces
| next month (or two), I may be cursing their names next
| fall ;-)
| cpncrunch wrote:
| For me, with a single production server, migrating to
| Ubuntu LTS on a new server seems a much less risky
| proposition to me than an in-place upgrade to either RHEL
| or Stream.
| helen___keller wrote:
| I appreciate the blog. I was pretty alarmed by the
| announcement, and I think as you mention a lot of it boiled
| down to that devilish-sounding line:
|
| > If you are using CentOS Linux 8 in a production environment,
| and are concerned that CentOS Stream will not meet your needs,
| we encourage you to contact Red Hat about options
|
| But, after reading your message I can partially see your point
| of view, in particular your gist seems to be that in the chain
| of development, CentOS Stream will sit where RHEL used to be,
| thus if you believed in RHEL as a boring, stable, reliable OS
| in the old world then so too should CentOS Stream be a boring,
| stable, reliable OS in the new one.
|
| This logic makes sense, with one exception: this assumes that
| the standard for release quality remains unhindered pre/post
| swapping the position of RHEL / CentOS.
|
| Before, Red Hat was incentivized to make sure RHEL releases
| were solid gold because _paying customers_ were on the
| receiving end. CentOS releases were downstream of solid gold,
| making CentOS solid gold as well.
|
| Now that the positions are reversed, what incentive does Red
| Hat have to make sure things are stable and low-risk before
| shipping to CentOS Stream? This is ultimately a matter of
| trust: if CentOS Stream gets a bad release, no paid enterprise
| server explodes. Quality no longer aligns with profit motive, a
| terrifying insight.
| freedomben wrote:
| Thanks for the response, and thanks for reading. You make a
| terrific point:
|
| > _This logic makes sense, with one exception: this assumes
| that the standard for release quality remains unhindered pre
| /post swapping the position of RHEL / CentOS._
|
| I don't really have an answer for that. It does seem like it
| would come down to "trust" and as a skeptical person I don't
| like that very much.
|
| As I think about it more, while we have realigned some
| economic incentives for the better, it does seem (in addition
| to your points) there might also be an "incentive" to break
| CentOS from time to time, just to remind enterprises who are
| using it that "RHEL" is the gold standard and CentOS is
| "unsupported" D-: Knowing Red Hat and many of the volunteers
| that work on these projects, I would be shocked (and indeed
| would quit my job immediately) if such a thing were to
| happen, although it would be hard to prove.
|
| That said such a thing would no doubt backfire. There would
| be outrage of course, and it would hurt the CentOS brand
| (which also hurts RHEL since these days the two are
| inextricably linked). We all fully expect another distro to
| "take the place" of old CentOS as a bug-for-bug rebuild (I'm
| excited about Rocky Linux personally) so not will there still
| be an option for that, but competition is great for quality
| of projects :-D
|
| Anyway, much appreciate the comment :-)
|
| I'll keep mulling it over as well.
| marmaduke wrote:
| This still seems a little sensational. Fedora would be the
| explosion here. If Stream is a release candidate they still
| have every reason to keep it stable so RHEL updates more
| quickly.
| cesarb wrote:
| > This logic makes sense, with one exception: this assumes
| that the standard for release quality remains unhindered
| pre/post swapping the position of RHEL / CentOS.
|
| There's another issue, which I haven't seen talked about so
| far. With CentOS downstream from RHEL, there were the Release
| Notes: before updating from CentOS 8.x to CentOS 8.y, you
| could read the CentOS release notes (and the voluminous RHEL
| release notes corresponding to it) to see if there was any
| breakage to expect for your use case. For the security
| updates within a release, you could follow
| https://lists.centos.org/pipermail/centos-announce/ (sadly
| non-working for CentOS 8) and/or the voluminous RHEL errata
| pages corresponding to it.
|
| With Fedora, before every update I glance at
| https://admin.fedoraproject.org/updates/ to see if there is
| any known issue with the update I'm about to do; this has
| saved me more than once (for instance, there was a broken
| selinux-policy update which would relabel the whole /home not
| long ago). I recall Debian had something similar (which shows
| you any release-critical bug recently filed for the packages
| you're about to install). Will CentOS Stream have something
| like that? If I run "dnf update" and see it's about to update
| bash, is there anywhere I can look to see what changed, and
| whether someone complained about the update?
| freedomben wrote:
| Great point also. I am going to pass your question to some
| people that I hope can answer it.
| ZWoz wrote:
| That probably depends, how strongly Stream and RHEL actually
| are going to be linked. If this relation is indeed similar to
| current situation, but centos and RHEL changing places, then
| there isn't much point holding QA until RHEL release.
| Actually, there is going to be good initiative: when you
| upstream is unusable, because too buggy and untested, then
| what? Whole point of Stream seems to be usable base to RHEL.
| syshum wrote:
| Sorry but yes CentOS is dead
|
| CentOS, is COMMUNITY ENTERPRISE OPERATING SYSTEM
|
| The community is dead, the Enterprise part of the Operating
| system is dead
|
| Sure the CentOS name will be still around, but is clear that
| CentOS is now a Dev focused operating system not designed or
| targeted for Stable Enterprise operations with a community of
| Enterprise SysAdmins around it
|
| If you believe the changes are "not all the much" then you are
| clearly not in touch with the user base of CentOS, outside of
| Devs that is
|
| The changes are GREAT for devs, and Appliance Manufacturers.
| Maybe even for Cloud customers
|
| But for us Old School, OnPrem sysadmins running CentOS for
| Stability, and Long Term Support, CentOS is most certainly dead
| freedomben wrote:
| > _is clear that CentOS is now a Dev focused operating system
| not designed or targeted for Stable Enterprise operations
| with a community of Enterprise SysAdmins around it_
|
| This is absolutely not true. Would you have described RHEL
| this way? If not, then you shouldn't describe CentOS this way
| either. CentOS took RHEL's place in the chain. Instead of
| Cent being downstream of RHEL, the two were swapped around.
|
| > _If you believe the changes are "not all the much" then you
| are clearly not in touch with the user base of CentOS,
| outside of Devs that is_
|
| Say what you will. I've been using Cent since 2012 and
| currently run numerous workloads in production on it. I've
| shipped SaaS products on top of it and have been responsible
| for widespread maintenance. I've been a package maintainer
| for numerous packages as well.
|
| > _But for us Old School, OnPrem sysadmins running CentOS for
| Stability, and Long Term Support, CentOS is most certainly
| dead_
|
| I know plenty of old school on prem sysadmins who run CentOS
| for stability and LTS (I'm one of them. I have 3 bare metal
| machines in prod at the moment running CentOS). I may go with
| Rocky for one of those machines (it's a router/load
| balancer), I haven't fully decided yet.
|
| That said I agree with you somewhat, that is the one area
| where this change could be somewhat negative. However, with
| CentOS being week and months behind RHEL right now, do you
| see that as a good thing? Do you like having an unpatched
| system for days or weeks at a time when an embargoed security
| fix hits RHEL and has to wait for CentOS to build and
| distribute? I don't. Security patches are top priority for
| me.
|
| Edit: Blog post mentioned is now live:
| https://freedomben.medium.com/centos-is-not-dead-please-
| stop...
| syshum wrote:
| >>However, with CentOS being week and months behind RHEL
| right now, do you see that as a good thing? Do you like
| having an unpatched system for days or weeks at a time when
| an embargoed security fix hits RHEL and has to wait for
| CentOS to build and distribute? I don't. Security patches
| are top priority for me.
|
| This is absolutely a False dilemma fallacy, there is
| absolutely nothing technically or legally prohibiting
| RedHat from releasing patches for both at the same time.
| Nothing. It is a sales/marketing or a internal process
| choice to do it that way.
|
| Changes to do this process, even moving CentOS to be ahead
| of RHEL is not the problem. The "rolling release" or non-
| release, or what every model they are calling it now with
| CentOS Stream is the problem. The fact that it will no
| longer be Binary Complete with RHEL is the problem, the
| fact that CentOS will be used as a "beta" (and spare me the
| marketing BS claiming it is not that) is the problem
|
| > Would you have described RHEL this way?
|
| RHEL is a targeted, Released Enterprise Operating system
| with a 10 year support cycle
|
| CentOS was a targeted, Released Enterprise Operating system
| with a 10 year support cycle
|
| CentOS Stream is not a targeted, released Enterprise
| operating system with 10 year support cycle. CentOS Stream
| is pseudo-rolling release with no point releases, used to
| build a targeted, released enterprise operating system.
| freedomben wrote:
| > _the fact that CentOS will be used as a "beta" (and
| spare me the marketing BS claiming it is not that) is the
| problem_
|
| If you just want to vent, go ahead. I'm not going to
| engage with someone assuming bad faith. If you actually
| care to hear the argument about why saying "beta" is
| stupid, here it is: https://freedomben.medium.com/centos-
| is-not-dead-please-stop...
| Jonanin wrote:
| > RHEL is a targeted, Released Enterprise Operating
| system with a 10 year support cycle
|
| > CentOS was a targeted, Released Enterprise Operating
| system with a 10 year support cycle
|
| And you don't see the problem here? Why do you expect Red
| Hat to maintain a free OS which targets exactly the same
| use case as their paid OS? They are not a charity.
|
| It would be great to have a free alternative to RHEL, but
| you shouldn't feel entitled to Red Hat providing that for
| you.
| 1e-9 wrote:
| > Why do you expect Red Hat to maintain a free OS which
| targets exactly the same use case as their paid OS?
|
| Because they said they would.
|
| They could have made the change effective prior to
| releasing CentOS 8, or they could have made it effective
| for all versions after CentOS 8. Either of those paths
| would be understandable. Making the change after many
| have already migrated to 8 sends the message that Red Hat
| commitments are not to be trusted.
| chasil wrote:
| Easy problem to solve.
|
| https://linux.oracle.com/switch/centos/
|
| Similar to forcing Microsoft or Google to prompt the user
| for their desired browser or search provider, it would be
| interesting if rhel was forced to prompt for a repo
| provider.
|
| It would have been wiser to splash rhel support upgrades on
| CentOS gdm or cli cockpit than to threaten to kill a
| product.
|
| Really, what were you thinking? Nazgul indeed! Fork you!
|
| Old habits die hard.
| freedomben wrote:
| Ha! Red Hat is too evil so you move to Oracle :-D
|
| > _Really, what were you thinking? Nazgul indeed! Fork
| you!_
|
| Glad we were able to have a productive conversation
| kd913 wrote:
| I don't work for Red Hat, but I saw a post that was saying
| that there is something in the works to fill the niche that
| CentOS offered. It just wasn't ready yet so the announcement
| hasn't been made yet. However, they needed to send a
| statement out regarding CentOS so companies were aware of
| what would be happening with CentOS 8 and perhaps avoid
| migration right now.
|
| For a community that depends on LTS, the sysadmins seem to
| make some rash decisions/drama. I think the logical decision
| here would surely be to wait and see what happens and make a
| decision in a year when support ending would actually become
| relevant.
| freedomben wrote:
| Completely agree. I am critical of Red Hat for not
| announcing this all at the same time, but I likewise very
| much agree with you. We still have a full year and they've
| said to expect an announcement within a month or two (at
| least that's what I read elsewhere, nothing I've heard
| internally).
| kcb wrote:
| Still have a full year? You think replatforming is
| something that happens in a day?
| syshum wrote:
| Some of this is timing.
|
| Many many many companies, right or wrong, wait until the
| very list minute to upgrade their legacy systems.
|
| Many of us are either still in the process or worse just
| finish our migration from CentOS 6 to CentOS 8, only to
| have the rug pulled out from under us.
|
| The sheer impact this move will have on many organizations
| is what is driving this emotional reaction
|
| If they would have honored the LifeCycle for CentOS 8,
| there would not have been the reaction you have seen
|
| 100% of the emotion / drama is coming from the choice
| RedHat has made to cut the supported life of CentOS 8 by 7
| years. that is a DRASTIC action, and their belief that 12
| months is "enough time" shows a clear ignorance of how the
| product is used in enterprise or they fully understand and
| are banking on the desperation of enterprise to sell RHEL
| licenses.
|
| either way it drastic choice by RedHat.
| freedomben wrote:
| Well, we mostly agree! I agree with everything until:
|
| > _their belief that 12 months is "enough time" shows a
| clear ignorance of how the product is used in enterprise
| or they fully understand and are banking on the
| desperation of enterprise to sell RHEL licenses._
|
| There's another explanation, and I think it makes a
| little more sense than yours which would require Red Hat,
| literally the company whose core job it is (which they
| are damn good at, enough so that you use it) to provide
| an enterprise distribution to some of the most
| conservative companies on the planet, to not understand
| how the product is used in enterprise.
|
| The suggestion that RH is "banking on the desperation of
| enterprise to sell RHEL licenses" at least makes sense
| given the facts, and that's kind of what I thought too
| when I first saw the news (the way they worded it sure
| made it seem like this was a money grab).
|
| It is possible however (and indeed this is my belief)
| that Red Hat doesn't consider Stream to be _that_ big of
| a change, and they 've given a full year to migrate.
| Indeed if you read my blog post[1] I don't think it's
| that big of a deal.
|
| I have zero inside info on this but I would bet highly
| that sales of RHEL were a factor in this decision for
| sure. I don't see how they couldn't be. But given _how
| long_ Red Hat has been providing all their sources
| publicly (which they DON 'T have to do) and acquiring and
| open sourcing companies, you don't give them even a tiny
| benefit of the doubt here that maybe their not just one-
| sided evil capitalists trying to squeeze nickels out of
| the CentOS community for short term gains?
|
| [1]: https://freedomben.medium.com/centos-is-not-dead-
| please-stop...
| justahuman74 wrote:
| The 'not all that much' is too much for most
| chasil wrote:
| If you have great ability to correct misinformation, then I
| would like you to bring back Red Hat 9 from 2003, fully updated
| with the latest RPMs.
|
| Red Hat demonstrated then exactly what it intended to do now.
| ikiris wrote:
| Good luck with that position that your customers are wrong and
| you didn't just fuck them all over (even the paying ones). You
| might want to update your linkedin.
| freedomben wrote:
| We call that "shooting the messenger." I didn't do anything
| to anyone lol. I was as surprised as everybody else when I
| saw the news (and I know you didn't read my blog post now btw
| because I discuss that in there).
|
| If shitting on some person on the internet makes you feel
| better, by all means take it out on me.
| rrauenza wrote:
| Since Centos Stream is upstream of RHEL, is it possible for an
| organization downstream to just manage a set of repositories (or
| whitelists) so that it only releases the Centos Stream versions
| that reached RHEL?
| freedomben wrote:
| I need to be careful of what I say so I'm going to be
| annoyingly cryptic, but others have had this thought and are
| looking into it. Stay tuned :-)
| xony wrote:
| mint OS community welcomes you :)
| meddlepal wrote:
| Article kind of hints at it but I suspect RHEL is going to get a
| new licensing model to capture the CentOS crowd under the RHEL
| umbrella. Once that's done it will be easier to upsell support
| contracts since they'll have the users in their license DB.
| Spivak wrote:
| I'm honestly surprised they don't just make RHEL free and take
| the CentOS market for themselves. Gate the current RHEL
| specific features behind support contracts and call it a day.
| Why make your customers have to migrate to pay you?
| bonzini wrote:
| There are no RHEL specific features.
| Spivak wrote:
| Au contraire, there are and they're quite valuable their
| enterprise customers. The most important is the detailed
| security errata published along side their RPM packages
| which are necessary to do things like "only install
| security updates" or "check if any packages have upatched
| vulns."
|
| RHEL but not CentOS also come with security/regulatory
| profiles like STIG which are necessary to run in certain
| environments like the DoD.
|
| Red Hat also has a license to distribute Oracle Java that
| CentOS lacks and so it's not available in their repos. They
| also ship with the Cisco network drivers that CentOS again
| doesn't have a license to distribute.
| cesarb wrote:
| There's also the extended support for minor releases.
| With RHEL, it's possible to stay in a minor release for
| longer while in CentOS you always have to migrate to the
| next minor release. For instance, according to the
| graphic at the middle of
| https://access.redhat.com/support/policy/updates/errata
| with Extended Update Support one can stay at RHEL 8.2
| until the middle of 2022 (so RHEL 8.2 has a full 2 years
| of support), while with CentOS, you had to migrate to
| CentOS 8.3 this month if you want to keep receiving
| updates (so CentOS 8.2 had only 6 months of support
| before being replaced with CentOS 8.3).
| josephcsible wrote:
| This is what Oracle Linux already does, so Red Hat is only
| hurting themselves by not doing so, since anyone who wants
| this can just go to Oracle. (Notwithstanding the fact that
| Oracle is evil.)
| pixl97 wrote:
| Yea, going to Oracle is always a bad idea and they'll find
| a way to get money out of you.
|
| It's pretty common for me to convert customers from Oracle
| JRE/JDK to OpenJDK/JDE when Oracle says they need to pay
| millions for no good reason.
| Spivak wrote:
| Look I just did an Oracle to OpenJDK transition for the
| same reason but I don't really think Java SE licensing is
| an example of Oracle being particularly Oracle. It's just
| that Oracle Java isn't free and they're doing what every
| company is doing switching from one-time license fees to
| subscriptions.
| josephcsible wrote:
| But here's the kicker: the worst thing Oracle can
| possibly do is to say "yeah, that whole Linux distro that
| we used to give you for free? We're not doing that
| anymore." So even if you do move to Oracle Linux and they
| go full evil, you're no worse off than you are on CentOS
| right now.
| freedomben wrote:
| Yeah I really wonder if this is coming. It's wishful thinking
| on my end so maybe isn't reasonable, but man it'd be neat. I
| get annoyed when people point out "you can already get a dev
| license for free." Sure, but there are hoops to jump through
| and you can't run it "in production" (which I think is mostly
| a meaningless claim, but still not something I like).
|
| Nevertheless I'm optimistic and hope they announce it sooner
| rather than later. Hopefully the current blowback will move
| things along ;-)
| syshum wrote:
| If this is their plan they have screwed up pretty bad and shows
| a clear mis understanding of enterprise customers
|
| We like stability, if they were going to change RHEL licensing
| to capture CentOS enterprise customers they should have
| announced those changes ahead or in tandem with the CentOS
| Announcement
|
| The CentOS Announcment as is read was "Hello Enterprise Users
| of CentOS, we know we promised to support CentOS 8 until 2029,
| April Fools, now we are going to cut support at the end of
| 2021, and maybe we will have some options for you early 2021 so
| call us"
|
| This uncertainty and betrayal of trust is going to be hard to
| come back from
| ikiris wrote:
| Yep exactly. This is outright refusal to use anything they
| produce going forward, as they've shown that long term
| commitments mean absolutely nothing.
| acomjean wrote:
| It doesn't surprise me. CentOS usage is huge. If they can turn
| 20% into paying customers it would be a huge revenue win for
| IBM.
|
| One hopes this newfound revenue goes toward making Linux
| better, but we will see. Red hat employees work on a lot of
| core things.
| ikiris wrote:
| Doesn't matter, they poisoned the well with this.
| fiddlerwoaroof wrote:
| So, what I don't understand is that I thought the whole point of
| CentOS was that RedHat didn't control it? I guess I missed the
| acquisition announcement, but a RedHat-owned CentOS makes a lot
| less sense to me.
| pushrax wrote:
| The whole point was that it was free. I'm not aware of anyone
| choosing CentOS over RHEL because of the governance structure.
| The feature set of CentOS directly depended on decisions by Red
| Hat anyway.
| fiddlerwoaroof wrote:
| I would be suspicious of running essential business
| operations on a free version of a product the company also
| sells licenses for: I'd always be wondering if they're going
| to change strategy on me.
| wmf wrote:
| Beggars can't be choosers and I don't know of another free
| distro providing 10 years of updates.
| bombcar wrote:
| CentOS was dying and RedHat was a no-brainer to take over
| maintenance.
|
| Dying as in lacking resources and developers - not users. They
| err really starting to lag upstream.
| marcinzm wrote:
| The point as I saw it was that CentOS didn't require a
| licensing fee. RedHat decided to make them into an official
| free version whose users they could then upsell onto licenses.
| IBM seems to have decided that they'd make more money in this
| segment by squeezing licenses out of existing users and killing
| the product.
| freedomben wrote:
| IBM had nothing to do with it, unless you think every Red Hat
| employee would lie about it. I would think if anything RH
| would like to blame IBM :-)
|
| They legitimately believe this is better. Maybe not for
| everybody, but for most. And for those who it's not better
| for they are announcing options in the next month or two for
| free RHEL access.
|
| I just blogged about it if you are interested. There's a lot
| of inaccurate info out there as a result of poor initial
| messaging. I attempt to clear things up here:
| https://freedomben.medium.com/centos-is-not-dead-please-
| stop...
| bonzini wrote:
| CentOS was never officially an "official free version". After
| Red Hat acquired CentOS, they positioned as a base for open
| source projects to develop on RHEL (which was what Red Hat
| needed and why they hired the developers in the first place).
|
| Of course, users that just needed a free RHEL kept using it
| that way with the added bonus of corporate backing, so much
| that Scientific Linux said "screw it we'll just use CentOS".
| znpy wrote:
| I wonder why the CentOS people agreed to this and did not walk
| away.
|
| Does red hat own the CentOS brand?
| kcb wrote:
| Most of the "CentOS Governing Board" are Red Hat employees.
| IceWreck wrote:
| Yes. RedHat bought the CentOS brand afew years ago
| marcinzm wrote:
| >I wonder why the CentOS people agreed to this and did not
| walk away.
|
| Cynical answer of money aside, someone else mentioned the
| project was running into resource issues so they may have
| chosen RedHat over a slow inevitable death.
| chasil wrote:
| Many years ago, I fondly used and documented the free and open
| Red Hat distribution, which ended with release 9 in 2003. I still
| have a hard drive with the original Red Hat 6 based on System V
| init, not the later v6 based on Upstart.
|
| There was a great feeling of abandonment then that is nostalgic
| in the death of CentOS now.
|
| In the years that have passed, I saw a few licenses purchased in
| my workplace, then support suddenly stopped by corporate sources
| who instructed all license holders to convert our installs to
| Oracle Linux support.
|
| I remembered my feeling of abandonment by Red Hat, ran the script
| without complaint, and all was well.
|
| In later years, focus returned to Red Hat licensing, and I was
| strongly encouraged to reinstall my Oracle Linux systems (which
| had grown greatly, as they were free). I resisted vehemently,
| objecting to an inferior kernel (compared to the UEK), reduced
| hardware support, and the pointless inconvenience of license
| keys, activation, and renewals for a product of generally lower
| quality.
|
| Fortunately, I have avoided this inconvenience.
|
| In light of the decades of Red Hat's behavior, I will say one
| thing: you reap what you sow.
___________________________________________________________________
(page generated 2020-12-12 23:01 UTC)