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

81–90 of 163 posts

Re: A Brief Goodbye to CentOS

#81

Post by dralley »

masklinn wrote: post #35
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/

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

No, Fedora and CentOS Stream are very very different.

Fedora is where new and shiny lands, with a release schedule of every 6 months, and ~1 year of support per version, with minimal backporting of bugfixes and frequent package updates. Lots of packages (including the kernel) update freely. That would not fly in CentOS.

CentOS Stream is the next minor version of RHEL. There is lots of backporting patches, ABI stability, the works. And it is supported for as long as RHEL is supported (the standard tier anyways) because it is the next minor version of RHEL.

For a visual metaphor:

Fedora ---------------------------------------------> CentOS Stream --> RHEL

The development process works basically like this:

1) A new RHEL release is created from a rough snapshot of Fedora. It's not an exact copy of Fedora, a fair number of changes are made in the process.

2) Fedora keeps moving forwards quickly, RHEL stays put

3) CentOS Stream takes the most current RHEL release and starts layering updates on top of that

4) After a couple of months these updates from CentOS Stream are then pushed into RHEL as a new point release

5) Repeat steps 3 and 4

Re: A Brief Goodbye to CentOS

#83

Post by cactus2093 »

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 guess call me new fashioned, but I've never really understood how to use debian packages well. I recall vaguely looking into the dpkg and build commands many years ago, it felt kind of inscrutable and clunky and I didn't find good resources that made it easy to learn so I just gave up on it and kept using the shell script to install the thing I needed with its dependencies.

By contrast, docker build and docker run are super simple to get started with (at least at a high level, figuring out the right order of flags and options to mount volumes and expose ports can get a little cumbersome). And the docker registry is super simple to browse. It's so easy to get up and running with, and the model it promises of isolation and self-contained dependencies makes a lot of sense which I think is why it has taken off so much. Despite the fact, which I think is what you're pointing out, that there often end up being a lot of pitfalls lurking just around the corner.

Re: A Brief Goodbye to CentOS

#84

Post by dboreham »

ethbr0 wrote: post #24
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.

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

"support" doesn't mean reading man pages, it means diagnosing and fixing some intermittent bug in Intel's 10G NIC driver.

Re: A Brief Goodbye to CentOS

#85

Post by jolmg »

denimnerd42 wrote: post #59
jolmg wrote: post #52

Earlier quoted context omitted.

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.

I see. I understood "they" to be "fedora", so I thought you said "fedora forks fedora" i.e. "fork fedora to be the new fedora version". So, I thought you meant "fork RHEL to be the new fedora version". I see that's backwards now.

EDIT: "Fedora is like next major version" also adds to the confusion. If Fedora is like the next major version of RHEL, it makes sense that Fedora forks RHEL and not the other way around.

Re: A Brief Goodbye to CentOS

#86

Post by deng »

Pxtl wrote: post #53
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".

Maybe CERN will revitalize Scientific Linux.

Re: A Brief Goodbye to CentOS

#88

Post by darksaints »

The future of operating systems, at least from a non-GUI perspective, is going to look a lot like SeL4 + Nix. A rock-hard provably secure capabilities-oriented kernel, combined with reproducible declarative package management that can handle any combination of dependencies that you want.

Essentially this means that the idea of different distributions for LTS, stable, beta, alpha, bleeding edge, etc., goes away completely. You are never forced to update an old package, nor prevented from updating a new package. You get the best of all worlds.

And since the kernel is about as secure and performant as you can get, you essentially always have the latest kernel. Drivers get updated as necessary (defined by your policy, not the distribution's) in userspace, potentially as quickly as the moment they are released, with no downtime whatsoever.

Re: A Brief Goodbye to CentOS

#89

Post by zemo »

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?

each version of the project gets a directory and contains everything the project needs. put all of those into a parent directory. use a symlink to point to the currently active version. E.g.:

    /usr/local/thing/versions/thing-v1.3.7
    /usr/local/thing/versions/thing-v1.4.2
    /usr/local/thing/current -> /usr/local/thing/versions/thing-v1.3.7
Post reply on HN