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

121–130 of 163 posts

Re: A Brief Goodbye to CentOS

#121

Post by bachmeier »

dboreham wrote: post #84
ethbr0 wrote: post #24

Earlier quoted context omitted.

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.

Also, and this is why you pay Red Hat specifically: Having easy access to the developer that compiled a package, made a particular design decision for the OS, etc.

Re: A Brief Goodbye to CentOS

#122

Post by oblio »

dsr_ wrote: post #107
cactus2093 wrote: post #95

Earlier quoted context omitted.

> Debian plus an automation system like Puppet, Chef, etc works extremely well. Eh, it does until it doesn't. Sooner or later you run into pitfalls around the leaky abstraction of pretending your state is truly idempotent and path-independent. E.g. spinning up a new instance works fine, but the existing instances that need to uninstall a previous version to upgrade to the newer one end up breaking. Or vice-versa, exi…

If I don't understand what I'm doing, it doesn't matter what tools I'm using to fail to accomplish it.

Ah, the myth of the perfect programmer.

Everyone makes mistakes, and state resets such as VMs or containers are one of the easiest ways to revert these mistakes.

Re: A Brief Goodbye to CentOS

#123

Post by oblio »

cactus2093 wrote: post #83
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…

A deb file is just an ar archive of 2 tgzs, one with metadata and one with the actual files.

Now, the tools that build them are a whole different kettle of fish.

Plus some stuff is really old school, ar is an archive format that nobody has used on its own since 1996, it's a sort of transparent bundler/archiver à la tar, I think it was originally used to bundle .so file into a bigger package but still have the symbols inside visible. I don't really remember all the details, it's been a while since I looked into .deb packages.

I think the main problem is that Debian is not a commercial project and it shows sometimes. The tooling is kind of "hidden" (you have to poke around the distribution, mailing lists, etc. to figure things out) and the processes are kind of the same thing. The docs on the site are ok in some regards but they're far from complete and up-to-date.

Meanwhile the Dockerfile format is reasonably well documented and the tooling is also quite straightforward. You can see that a company made it for a while its raison d'être and wanted to make it easy to use.

Re: A Brief Goodbye to CentOS

#124

Post by nikolay »

Without being a free version of RHEL, nobody would have bothered with CentOS. There was White Box Linux back then. Maybe this would give another chance to that forgotten project.

Re: A Brief Goodbye to CentOS

#125

Post by oblio »

wirrbel wrote: post #101
Thaxll wrote: post #21

Earlier quoted context omitted.

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

IMHO we are in a phase of enthusiasm, but we can already anticipate the peak and the trough of disillusionment will come. In 10 years, the pendulum will ice swung a bit back and forth and we‘ll know better what works well. I bet it’s some form of lambda architecture. Let me say that I am not pro or against docker per se. I just happen to have started my career with a strong team pre-docker and a lot of the docker-ent…

> I bet it’s some form of lambda architecture.

Well: https://aws.amazon.com/blogs/aws/new-for-aws-lambda-containe...

Re: A Brief Goodbye to CentOS

#127

Post by yjftsjthsd-h »

cubano wrote: post #25
_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.

> but much harder to justify banging on public companies for trying to increase revenue

I assure you, it is very easy to be unhappy with a company for screwing over its users, even if they think it might net them more revenue (bonus points for this being a questionable assumption)

Re: A Brief Goodbye to CentOS

#128

Post by deng »

navanchauhan wrote: post #99
deng wrote: post #86

Earlier quoted context omitted.

Maybe CERN will revitalize Scientific Linux.

Scientific Linux[0] is still maintained ( Although, by Fermi National Accelerator Laboratory and not CERN ) [0] https://scientificlinux.org

Yes, maintained, but no new versions since they switched to CentOS.

https://lwn.net/Articles/786422/

Re: A Brief Goodbye to CentOS

#129

Post by jmnicolas »

bachmeier wrote: post #51

> 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…

> These days it's more "possibility of a problem" vs "absolutely rock solid".

CentOS is mostly a server distro, I bet 99% of installs are without GUI. So "possibility of a problem" is a no go for a server.

Re: A Brief Goodbye to CentOS

#130

Post by yjftsjthsd-h »

darksaints wrote: post #88

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 comple…

So there's 2 ideas here: kernel, and packages.

For the kernel, I'm curious how your suggestion is better than Linux is already. Linux, today, is already a performant, secure kernel with an incredibly stable userspace-facing ABI.

For packages, the problem isn't so much being able to install old and new packages (although that's certainly useful); the problem is maintaining a stable version while still fixing bugs and security issues. It's no good just having a packaging system that lets me run a 5-year-old glibc with a fresh-from-git application server if that ancient glibc has multiple known exploits in it. The work in an LTS system is carefully backporting fixes to your chosen old version while holding its ABI stable.

Post reply on HN