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

51–60 of 163 posts

Re: A Brief Goodbye to CentOS

#51

Post by bachmeier »

> With the advent of DevOps and SRE, businesses and startups are moving away from the old-school concept of traditional server clusters to running their applications on disposable containers. The trend is clear and true. Developers are increasingly less reliant on a tried-and-true Linux distribution that lasts for a decade. With containers, developers can develop, test, deploy, and rollback with blazing fast velocity.

As a user of Linux as my main OS since 2005, and using it partially for years before that, I think another issue is that the quality of software releases is just much higher than it used to be. There used to be a tradeoff between "trustworthy" and "recent". These days it's more "possibility of a problem" vs "absolutely rock solid".

And of course the general move to the web. Apps that run in your browser no longer need to run on a server. When I started in my current job in 2004, there was a Debian stable server used for teaching. (It might still be in use for all I know.) This semester I used CoCalc. That's one less use for an ultrastable server.

Re: A Brief Goodbye to CentOS

#52

Post by jolmg »

denimnerd42 wrote: post #45
masklinn wrote: post #35

Earlier quoted context omitted.

Isn't Fedora already the RHEL upstream? Why not just kill CentOS entirely?

Centos is going to be a beta for the next point release. Fedora is like next major version but I’m not sure if they actually fork Fedora to get that or if they just use it to preview the technology.

s/fork Fedora/fork RHEL/ I imagine you meant.

Re: A Brief Goodbye to CentOS

#53

Post by Pxtl »

SloopJon wrote: post #46

I somehow missed that Red Hat started sponsoring CentOS a while back, and owns the trademarks. I mean, money and cooperation is great and all, but how could anyone have expected CentOS Linux to continue for long when Red Hat has such a fundamental conflict of interest? Edit: here's the HN post at the time: https://news.ycombinator.com/item?id=7019914

Yeah, I assume this ends with somebody forking CentOS into another "redhat without redhat branding and license costs".

Re: A Brief Goodbye to CentOS

#54

Post by dvfjsdhgfv »

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.

Re: A Brief Goodbye to CentOS

#56

Post by pmontra »

q3k wrote: post #4
chmod775 wrote: post #2

Call me old fashioned, but I ship both my private projects and those at work as debian packages. Debian packages are trivial to put into a container, and we tried that, but honestly it's not half as nice to work with. With containers you have to do a ton of extra steps to get functionality and debugging on a level a default debian system provides you. Additionally the tools to automate the installation and configurat…

How do you handle multiple versions of the same project/software/deployment on the same machine?

On my development laptop: a mix of VMs, docker containers, language/package managers. It's a per project choice, either mandated by my customers or advised by me. To name a few technologies I'm using right now in three different projects open in different virtual desktops:

docker

vagrant

VirtualBox (even some scripts to mimic EC2's spawning of machines with VBoxManage)

asdf (really, my fingers didn't slip on the keyboard)

npm

rvm

python's virtualenvs

Re: A Brief Goodbye to CentOS

#57

Post by inetknght »

q3k wrote: post #30
kijin wrote: post #22

Earlier quoted context omitted.

To be fair, containers often end up being its own Linux installation with its own configuration drift. So many dockerfiles mindlessly pull in an entire Ubuntu system just to run a simple app.

But the image [1], once built, is still idempotent. You can deploy it and it will always contain the same configuration and code. Meanwhile, a month-long Ubuntu VM that has received regular CM pushes (including system updates) will likely vastly differ from a branch new Ubuntu VM and a single CM push. To the point, where you can't be sure anymore that your current CM config will even work on a brand new machine, unle…

> But the image [1], once built, is still idempotent. You can deploy it and it will always contain the same configuration and code.

VMs can be idempotent too. It's just that traditionally people attach storage to it. But VM snapshots are a thing.

> To the point, where you can't be sure anymore that your current CM config will even work on a brand new machine, unless you're regularly testing that.

The same can be argued about attached storage to a container.

Re: A Brief Goodbye to CentOS

#58

Post by rombert »

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.

Note that the gap between Leap and SLE will become quite small after Leap 15.3, with binary packages for SLE being reused for Leap.

It's interesting that while RH/IBM are moving away from the 'community rebuild' model SUSE are moving close.

https://en.opensuse.org/Portal:Leap/FAQ/ClosingTheLeapGap

Re: A Brief Goodbye to CentOS

#59

Post by denimnerd42 »

jolmg wrote: post #52
denimnerd42 wrote: post #45

Earlier quoted context omitted.

Centos is going to be a beta for the next point release. Fedora is like next major version but I’m not sure if they actually fork Fedora to get that or if they just use it to preview the technology.

s/fork Fedora/fork RHEL/ I imagine you meant.

Fork fedora to be the new rhel version. maybe there’s a technically better way of describing that.

Re: A Brief Goodbye to CentOS

#60

Post by cactus2093 »

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…

GKE is the container/kubernetes engine, but then you also mention Prometheus, Sysdig, Grafana, ELK.

Sounds like much of the problem was the monitoring stack, just curious why you blame that on containers and k8s? Wouldn't you still have needed a solution for that for 20-30 hosts regardless of how you're orchestrating/running the applications?

Post reply on HN