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

141–150 of 163 posts

Re: A Brief Goodbye to CentOS

#141

Post by teh_klev »

leotaku wrote: post #132
jmnicolas wrote: post #129

Earlier quoted context omitted.

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

Sorry to break this to you, but if the possibility of a problem is a no go for your servers, you will unfortunately have to pull the plug on them. All software has bugs, so does hardware.

What a supercilious and condescending response, and verging on snark. Sure all software is likely to have bugs, but some software is likely to have less bugs because there's more test coverage or the software is conservative about what features get added/updated.

See:

https://news.ycombinator.com/newsguidelines.html

Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

Re: A Brief Goodbye to CentOS

#142

Post by oblio »

dsr_ wrote: post #136
oblio wrote: post #122

Earlier quoted context omitted.

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.

Everyone makes mistakes, and having real testing infrastructure is the best way to catch it. Many mistakes are made against databases; maybe you can roll back, maybe you can't -- either way, it's cheaper in testing than production.

There are also state inconsistencies on servers. Configuration files are not updated correctly (maybe even with a silent failure), binaries are not updated correctly, temporary files left over interfere with the update, cached files do the same, etc.

There are many reasons why resetting the environment on deployment is a solid and cost effective solution to many issues.

Re: A Brief Goodbye to CentOS

#143

Post by cactus2093 »

peterangular wrote: post #75
cactus2093 wrote: post #60

Earlier quoted context omitted.

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?

> just curious why you blame that on containers and k8s? Crawl, walk, run sorta stuff. We had never just gotten the application/monitoring/everything humming on pure Linux hosts skipping that entirely because "K8s and containers!" When you haven't properly QA'd, vetted, whatever your stack throwing heavy abstraction at it (containers/K8s) is an anti-pattern. Most companies don't have the resources to run a competent…

Fair enough, I definitely can relate to that line of problems.

"Should we spend the time to do a thorough look at our monitoring needs, figure out where the gaps are, be more disciplined about using the tool consistently, etc.?"

"That'll take too long, I heard about this shiny new ops tool that claims to require zero configuration, let's just drop this in instead!"

Re: A Brief Goodbye to CentOS

#144

Post by [deleted] »

leotaku wrote: post #132
jmnicolas wrote: post #129

Earlier quoted context omitted.

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

Sorry to break this to you, but if the possibility of a problem is a no go for your servers, you will unfortunately have to pull the plug on them. All software has bugs, so does hardware.

[deleted]

Re: A Brief Goodbye to CentOS

#145

Post by pferde »

pelasaco wrote: post #74
pferde wrote: post #62

Earlier quoted context omitted.

It is untrue that SLES does not support upgrades between major versions: https://documentation.suse.com/sles/15-SP2/single-html/SLES-... It is, however, true that SLES is less conservative than e.g. RHEL when it comes to bumping software versions between their minor releases (service packs). I remember that they switched from 2.6 to 3.0 kernels sometimes in SLES10 days. Fun stuff.

openSUSE however doesn't support it https://en.opensuse.org/SDB:System_upgrade#Supported_scenari...

The link you posted only states that the upgrade is not supported for 64-bit ARM, and that 32-bit (x86) system cannot be upgraded to Leap. It doesn't say upgrade in general is not.

Re: A Brief Goodbye to CentOS

#146

Post by leotaku »

jmnicolas wrote: post #135
leotaku wrote: post #132

Earlier quoted context omitted.

Sorry to break this to you, but if the possibility of a problem is a no go for your servers, you will unfortunately have to pull the plug on them. All software has bugs, so does hardware.

Come on. Possibility of a problem is say Arch, rock stable is Debian / CentOS. There are certainly bugs in the later too, but I never experienced any in 15 years since I run a dozen Linux servers in production.

I understand, your comment simply rubbed me the wrong way, because it, in my mind, kind of ignores the main point of the parent, that nowadays the trade-off is less obvious than it used to be.

I also genuinely want to apologize if my comment came of as patronising. I wanted to express my genuine opinion in a fun way and it seems like I have missed the mark pretty badly.

Re: A Brief Goodbye to CentOS

#147

Post by leotaku »

teh_klev wrote: post #141
leotaku wrote: post #132

Earlier quoted context omitted.

Sorry to break this to you, but if the possibility of a problem is a no go for your servers, you will unfortunately have to pull the plug on them. All software has bugs, so does hardware.

What a supercilious and condescending response, and verging on snark. Sure all software is likely to have bugs, but some software is likely to have less bugs because there's more test coverage or the software is conservative about what features get added/updated. See: https://news.ycombinator.com/newsguidelines.html Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's…

Understood, I tried to be funny and failed. Will try to do better next time.

Re: A Brief Goodbye to CentOS

#148

Post by speedcoder »

milesvp wrote: post #114
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

To be fair, I truly thought MySQL was dead in the water when Oracle purchased them 12 years ago, but as far as I can tell MySQL continues to be well supported with new features being added. So I no longer know what to think about these kinds of acquisitions.

MelissaDB

Re: A Brief Goodbye to CentOS

#149

Post by ComputerGuru »

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?

I think it’s flawed to think that you can safely have multiple versions of the same app running (or even installed) simultaneously in the same “universe.” Whether you use jails, VMs, containers, or whatever you should not count on “I didn’t change anything between these two versions that would corrupt the other instance” to help you.
Post reply on HN