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

21–30 of 163 posts

Re: A Brief Goodbye to CentOS

#21

Post by Thaxll »

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…

"Containers aren't quite there yet."

The rest of the world beg to differ, it's not a question of is it ready or not, it's "Am I going to use it or not".

We're way passed that question.

Re: A Brief Goodbye to CentOS

#22

Post by kijin »

q3k wrote: post #16
starfallg wrote: post #11

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).

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.

Re: A Brief Goodbye to CentOS

#23

Post by NDizzle »

q3k wrote: post #15
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.

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.

Re: A Brief Goodbye to CentOS

#24

Post by ethbr0 »

ThinkBeat wrote: post #7

If you are operating a billion-dollar computer paying IBM/Redhat is probably a good idea.

If you are operating a billion-dollar computer, not using IBM/Redhat is probably a good idea.

At that scale, hiring your own quality support and running open systems is a drop in the bucket.

If you want the full IBM/Redhat experience, then you can even afford to hire 5+ layers of middle management and PMs between you and your engineers.

Re: A Brief Goodbye to CentOS

#25

Post by cubano »

_jal wrote: 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.

Re: A Brief Goodbye to CentOS

#26

Post by ghshephard »

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…

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 kubectl and the orchestration around k8s (GKE, Prometheus, Sysdig, Grafana, ELK) - the "operating system" has moved up a stack.

Re: A Brief Goodbye to CentOS

#27

Post by pelasaco »

ben509 wrote: 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/

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

Re: A Brief Goodbye to CentOS

#28

Post by peterangular »

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…

I'm really considering doing this for a new spin-up myself... The stability of Debian tooling for large-scale, hyper scaleable solutions is outstanding. I just feel like the world balks at me every time I do something considered slightly "old fashioned" completely ignoring the finished product to shame me for not using buzz-word tooling.

Containerization is fantastic don't get me wrong, but I've had more success with old-school approaches to package management, deployment, optimization, debugging, etc. running thin Debian servers. Just... prod ops is easier and more stable at the end of the day. I really don't see the need to containerize everything outside of cross-platform development tooling. I also really prefer having a semblance of an OS/bash terminal when it comes to ops!

Also: this is purely anecdotal. And, to get ahead of the folks yelling "you just don't understand Docker and K8s" - yes I do. I still think they're great, I just am not fully sold on them for every use-case.

Re: A Brief Goodbye to CentOS

#30

Post by q3k »

kijin wrote: post #22
q3k wrote: post #16

Earlier quoted context omitted.

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).

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, unless you're regularly testing that.

[1] - Yes, Dockerfiles do not make for reproducible builds - but once an OCI image is built, its deployment going to be reproducible. And there's more ways to build images than via Dockerfiles - some of which solve this problem (using Nix or Bazel, for example).

Post reply on HN