Live data from Hacker News

A Brief Goodbye to CentOS

clementchiew.me

31–40 of 163 posts

Re: A Brief Goodbye to CentOS

#31
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.

You want your server OS to be a mountain. It shouldn't move from under you as you build. Fedora is a river, it never stops moving.

For people who this doesn't make sense, it's the timeline of the stack on top that drives the OS stability requirements.

If you work in heavily regulated industries, systems migrations and software development can be order-of-years.

Having a mandatory OS upgrade mid-development/deployment is not desirable.

It's a terrible way to develop, but when changes need to be documented in excruciating detail and signed off on by legal... sometimes it's just the way things are.

Re: A Brief Goodbye to CentOS

#32
post #23
post #15

Earlier quoted context omitted.

How is it technical debt? How else do you handle software rollout and rollback, or canarying? Do you have a VM for every single version of your software?

Uhhh... backups?! Not all companies release daily, weekly, and sometimes not even monthly. Stage the rollout, do your testing, get your evidence, get your plan, perform the release.

So if you deploy a new release which turns out to be buggy, your only recourse is doing a full backup restore?

Re: A Brief Goodbye to CentOS

#33
post #23
post #15

Earlier quoted context omitted.

How is it technical debt? How else do you handle software rollout and rollback, or canarying? Do you have a VM for every single version of your software?

Uhhh... backups?! Not all companies release daily, weekly, and sometimes not even monthly. Stage the rollout, do your testing, get your evidence, get your plan, perform the release.

q3k, I can't reply to you at this depth. But yes. You're saying a "full backup / restore" but it's not the entire system.

Let's say you have an app, in a folder, that reads config files from 3 other locations on the machine. It talks to two databases. You back up two databases and 4 total folders. That's your backup. It's simple and straight forward to me.

Re: A Brief Goodbye to CentOS

#34
post #25
post #10

RedHat's goodwill will be spent down over the next decade or so, and eventually I fully expect to think of them the same way I do IBM. (Which is, roughly, the same way I think of Oracle.) All of the people I deal with there are the same as before the acquisition, so things have not changed much for me personally, yet. But I am looking at building replacements for certain tools we depend on; the writing is on the wall…

It's easy to want to do, but much harder to justify banging on public companies for trying to increase revenue.

[deleted]

Re: A Brief Goodbye to CentOS

#35
post #13

I wasn't clear what's changing that is so problematic, so to summarize this post[1] and various comments: CentOS Stream will track ahead of RHEL and thus will be more like a beta channel, losing the stability guarantees that CentOS users depended on. [1]: https://blog.centos.org/2020/12/future-is-centos-stream/

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

Re: A Brief Goodbye to CentOS

#36
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.

Previous product I worked on required a supported RHEL/CentOS environment on which to install our product. Even with the six years or so of support, our customers would piss and moan every time we'd tell them that RHEL/Centos5 was hitting EOL and they'd need to upgrade their servers to Centos 6 or 7 to stay supported. Most of them wouldn't even entertain the idea of "upgrading": for them, business as usual was holding on to the existing OS as long as possible, then buying an entirely new server with the latest-greatest CentOS release freshly installed on it, and doing a data migration.

I can't even imagine the amount of headache we would have gotten if they needed to upgrade every two years.

Re: A Brief Goodbye to CentOS

#38
I have noticed more companies adopting Amazon Linux when a few years back they would have used CentOS. I wonder how much this affected the decision.

Wish we would see more adoption of Freebsd and NixOS in the future.

For now I like my Debian :-)

Re: A Brief Goodbye to CentOS

#39
post #16

Earlier quoted context omitted.

The simple answer is you can choose not to. In many ways, a VM is a better abstraction than a container due to the simplicity of virtualising the hardware interface, as opposed to creating another abstraction layer in the kernel dealing with process isolation, permissions and system controls.

On the other hand, VMs are wasteful resource-wise (and $$$-wise) and have a much larger operational overhead (suddenly for every deployment you have a different Linux installation, with its own root /, with its own configuration drift, which you have to manage separately via CM).

That same issues exists with docker containers. You can also build a pipeline to deploy very barebones VMs that contain the kernel, a barebones userland and the application. Use KSM to minimise memory usage. What you get with containers is a shared page cache and reduced context switching.

Once upon a time in tech, the thinking was hardware is cheap, technical staff is expensive, hence we moved on to systems and programming languages that saved us time at the expense of efficiency on the hardware.

20 years on, the cost equation hasn't changed. In fact, its probably shifted drastically towards the extremes. We'd likely save more energy by eliminating crypto mining than moving all VMs onto containers.

Re: A Brief Goodbye to CentOS

#40
The server response on clicking the link lacks a "Content-Type" header. I just thought I'd mention that in case the admin would be here and interested.

It's causing a download extension in my browser to show a download dialog on clicking the link. I don't think it's a bug in the extension, but rather a required behavior because of the limitations of extensions. The extension has no sure way to know what my browser's treatment of the response will be after it inspects the body content to guess the type, so the safer thing to do in its case is to show the dialog.

I don't think Content-Type is required by HTTP, but it's pretty rare for servers to not include it. Might be good to add it if only in interest of the Robustness Principle[1].

[1] https://en.wikipedia.org/wiki/Robustness_principle

Post reply on HN