Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Brief Goodbye to CentOS

clementchiew.me

Post reply on HN
Print view View original

61–70 of 163 posts

Re: A Brief Goodbye to CentOS

#61

Post by viccuad »

Lendal wrote: post #9

I'm still relatively new to Linux. My question is why wouldn't Fedora Server be considered an alternative for the CentOS diaspora? It seems a better fit than Debian to me.

Why would it be a better fit, because of the package management?

Package managers are irrelevant. The relevant part is the quality, methodology of testing, existing written policy and technical requirements for the software. That you at the end deliver it in a deb, rpm or what have you, amounts to little.

Debian Stable (with its quality, Debian policy, testing, and stability of package major versions) is closer to CentOS. Fedora would be, as Debian Unstable, too fast moving for CentOS usecases.

Re: A Brief Goodbye to CentOS

#62

Post by pferde »

viccuad wrote: post #43
pelasaco wrote: post #27

Earlier quoted context omitted.

so will it be basic the same as openSUSE Tumbleweed for SUSE Linux?

Debian Unstable -> Testing -> Stable -> Oldstable -> Oldstable with LTS Fedora -> Centos Stream -> RHEL -> RHEL with LTS Opensuse Tumbleweed -> Leap -> SLES -> SLES with LTS Debian supports upgrades with major versions, and doesn't bump package major versions between minor versions. SLE/Leap don't support upgrades between major versions, and bump package major versions between minor versions.

It is untrue that SLES does not support upgrades between major versions: https://documentation.suse.com/sles/15-SP2/single-html/SLES-...

It is, however, true that SLES is less conservative than e.g. RHEL when it comes to bumping software versions between their minor releases (service packs). I remember that they switched from 2.6 to 3.0 kernels sometimes in SLES10 days. Fun stuff.

Re: A Brief Goodbye to CentOS

#63

Post by NDizzle »

peterangular wrote: post #44
ghshephard wrote: post #26

Earlier quoted context omitted.

Re: Containers aren't quite there yet. I think they've been there for 12-14 months. It's no longer a question of "If" but "When" a company decides on its container strategy (and its more than just k8s - see https://blog.coinbase.com/container-technologies-at-coinbase... ) I work for a company that is 100% k8s. Base linux of the containers is Debian 8- but honestly doesn't really matter that much - the OS is more kube…

When I was working in a stack like this I found people spending outstanding amounts of time not actually working to improve the stability/performance of the application. The reason you triggered that memory was "GKE, Prometheus, Sysdig, Grafana, ELK" - that's exactly what we were dealing with. The support infrastructure/compute needs for it far exceeded the 20-30 hosts that actually needed to be there to operate the…

"outside of a couple bitter/broken ops guys who didn't deserve what the team had done to them"

Hey, that's me.

Re: A Brief Goodbye to CentOS

#64

Post by fractal618 »

No mention of Fedora? Is it not feasible that those currently using CentOS, and don't wish to use the supported Red Hat, will gradually migrate to the CoreOS, IoT or Server version of Fedora?

I would think that would be easier than migrating to a different package management system.

Re: A Brief Goodbye to CentOS

#66

Post by pelasaco »

viccuad wrote: post #43
pelasaco wrote: post #27

Earlier quoted context omitted.

so will it be basic the same as openSUSE Tumbleweed for SUSE Linux?

Debian Unstable -> Testing -> Stable -> Oldstable -> Oldstable with LTS Fedora -> Centos Stream -> RHEL -> RHEL with LTS Opensuse Tumbleweed -> Leap -> SLES -> SLES with LTS Debian supports upgrades with major versions, and doesn't bump package major versions between minor versions. SLE/Leap don't support upgrades between major versions, and bump package major versions between minor versions.

> Opensuse Tumbleweed -> Leap -> SLES -> SLES with LTS

Almost right :)

Leap is the fixed point release, based on SLE. SLE is rebased on Tumbleweed every 3-4 years.

Re: A Brief Goodbye to CentOS

#67

Post by [deleted] »

pferde wrote: post #62
viccuad wrote: post #43

Earlier quoted context omitted.

Debian Unstable -> Testing -> Stable -> Oldstable -> Oldstable with LTS Fedora -> Centos Stream -> RHEL -> RHEL with LTS Opensuse Tumbleweed -> Leap -> SLES -> SLES with LTS Debian supports upgrades with major versions, and doesn't bump package major versions between minor versions. SLE/Leap don't support upgrades between major versions, and bump package major versions between minor versions.

It is untrue that SLES does not support upgrades between major versions: https://documentation.suse.com/sles/15-SP2/single-html/SLES-... It is, however, true that SLES is less conservative than e.g. RHEL when it comes to bumping software versions between their minor releases (service packs). I remember that they switched from 2.6 to 3.0 kernels sometimes in SLES10 days. Fun stuff.

[deleted]

Re: A Brief Goodbye to CentOS

#68

Post by rhodysurf »

ehayes wrote: post #47

Am I the only one who doesn't get the "risk using CentOS Stream" stuff? Isn't it going to be slightly-less stable RHEL? I actually worked at Red Hat a few years back and almost all work was released upstream-first. The one time I fixed something security-related, the fix was still made upstream first, but just embargoed until the fix was made and released for downstream versions. If I recall correctly, we pushed the…

I worked in defense for a while. Every DoD contractor is locked to RHEL version that their DoD targets use as end users. But they don’t need to pay for RHEL support currently because they all just use CentOS instead. This forces all of those companies to finally pay up, which they will def not be happy about.

Re: A Brief Goodbye to CentOS

#69

Post by rhodysurf »

dvfjsdhgfv wrote: post #54
ehayes wrote: post #47

Am I the only one who doesn't get the "risk using CentOS Stream" stuff? Isn't it going to be slightly-less stable RHEL? I actually worked at Red Hat a few years back and almost all work was released upstream-first. The one time I fixed something security-related, the fix was still made upstream first, but just embargoed until the fix was made and released for downstream versions. If I recall correctly, we pushed the…

It's not about risk; many vendors produce software for a specific version of RHEL - we want to use exactly that version, but we don't want to pay through the nose for the support we don't need.

Exactly this. You can produce software that is compatible with a RHEL version without paying for RHEL if you’re not even using it

Re: A Brief Goodbye to CentOS

#70

Post by twic »

cortesoft wrote: post #18
ComputerGuru wrote: post #8

Earlier quoted context omitted.

Isn't that a sign of technical debt? Not OP, but for development/testing: in a VM.

What? Deploying new software is technical debt?

In a real sense, yes. Once it's deployed, it incurs costs, like a debt.

Reminds me of:

> My point today is that, if we wish to count lines of code, we should not regard them as “lines produced” but as “lines spent”: the current conventional wisdom is so foolish as to book that count on the wrong side of the ledger.

-- Edsger W. Dijkstra

Post reply on HN