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

41–50 of 163 posts

Re: A Brief Goodbye to CentOS

#41

Post by q3k »

NDizzle wrote: post #33
NDizzle wrote: post #23

Earlier quoted context omitted.

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.

(you have to wait until you can reply after a certain depth - this is HN's anti-flamewar system kicking in)

I understand you can restore from backups, but this doesn't seem simple to me - especially when you deal with situations where there's more than just one person deploying to production.

In comparison, my rollbacks are performed the same way rollouts/rollforwards are - by editing a single line in Git (ie. changing the OCI image string) and running `kubecfg update`. No need to access backups, no need for special procedures.

Re: A Brief Goodbye to CentOS

#42

Post by [deleted] »

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?

[deleted]

Re: A Brief Goodbye to CentOS

#43

Post by viccuad »

pelasaco wrote: post #27
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?

  Debian Unstable     -> Testing       -> Stable -> Oldstable -> Oldstable with LTS
  Fedora              -> Centos Stream -> RHEL   -> RHEL with LTS
  Opensuse Tumbleweed -> Leap          -> SLES   -> SLES with LTS
Debian supports upgrades with major versions, and doesn't bump package major versions between minor versions. SLE/Leap don't support upgrades between major versions, and bump package major versions between minor versions.

Re: A Brief Goodbye to CentOS

#44

Post by peterangular »

ghshephard wrote: post #26
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 kube…

When I was working in a stack like this I found people spending outstanding amounts of time not actually working to improve the stability/performance of the application. The reason you triggered that memory was "GKE, Prometheus, Sysdig, Grafana, ELK" - that's exactly what we were dealing with. The support infrastructure/compute needs for it far exceeded the 20-30 hosts that actually needed to be there to operate the application.

We either were using someone else's prebuilt orchestration for something like ELK (insecure, needs constant auditing to be OK) or rolling it ourselves (very expensive in engineer time). None of it was ever working 100% and that was because we were jumping at software packages no one had really taken the time to fully understand. The mentality was "it's containerized!" which many on my team took to mean "we don't need to really grok it, it's in a container!" That burnt us, both on our TIG and ELK stacks. I left that job because it became putting out dumb fires that were not business-justifiable.

All-in-all I'm not saying what anyone is doing is wrong, I'm just saying that if you're going for an orchestrated environment like this you have to have a very mature team. You have to really care about learning these services well, and you have to be careful to not let your own architecture take your time away from solving real problems for the business.

The team I was on did not have that maturity outside of a couple bitter/broken ops guys who didn't deserve what the team had done to them while buzz-word driven leadership gutted their very-proven and stable VMWare infra into a total cluster-f K8s setup because "that's what we're suppose to do in 2018! That's what the new engineers want to work in!"

> the "operating system" has moved up a stack

Splitting hairs: The OS is still the same. The "stack" is newly imposed abstraction on-top of already established paradigms where we are trying to abstract ourselves away from the OS. It's distributed compute more than it is the "OS moving up a stack".

Edit: Ha I think you may have edited your comment with the Coinbase article. That article is actually what I point people to when explaining that K8s isn't some golden bullet, I personally think Coinbase is a great compromise in leveraging containers without going off of the rails (as they write about, ex: talking about the need for dedicated "compute" teams etc).

Re: A Brief Goodbye to CentOS

#45

Post by denimnerd42 »

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?

Centos is going to be a beta for the next point release. Fedora is like next major version but I’m not sure if they actually fork Fedora to get that or if they just use it to preview the technology.

Re: A Brief Goodbye to CentOS

#46

Post by SloopJon »

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

Re: A Brief Goodbye to CentOS

#47

Post by ehayes »

Am I the only one who doesn't get the "risk using CentOS Stream" stuff? Isn't it going to be slightly-less stable RHEL?

I actually worked at Red Hat a few years back and almost all work was released upstream-first. The one time I fixed something security-related, the fix was still made upstream first, but just embargoed until the fix was made and released for downstream versions. If I recall correctly, we pushed the upstream fix the day the downstream patch was public.

Now I run CentOS in production for a small web app. I get wanting a decade of support for your OS, but at least for cloud-based web apps that seems pretty unnecessary.

What am I missing here?

Re: A Brief Goodbye to CentOS

#48

Post by jonfw »

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 make heavy use of both package managers and containers at my job, they solve different problems. Just because you don't have the problem that containers solve doesn't mean they aren't there yet

Re: A Brief Goodbye to CentOS

#49

Post by NDizzle »

q3k wrote: post #41
NDizzle wrote: post #33

Earlier quoted context omitted.

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.

(you have to wait until you can reply after a certain depth - this is HN's anti-flamewar system kicking in) I understand you can restore from backups, but this doesn't seem simple to me - especially when you deal with situations where there's more than just one person deploying to production. In comparison, my rollbacks are performed the same way rollouts/rollforwards are - by editing a single line in Git (ie. changi…

I look at it this way. I think it's simpler to do this kind of backup in case things go wrong (which, honestly, is not that often. Twice in 5 years that I can think of off the top of my head) than it is to set up kubernetes, manage kubernetes, and convert our applications to work correctly in kubernetes. All of that is required so that your single line edit becomes a possibility. That's a lot of work to enable that workflow versus copying 5 directories to one location, zipping it, slapping a version tag on the zip file, storing it in a couple of places.

Re: A Brief Goodbye to CentOS

#50

Post by dvfjsdhgfv »

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.

Well, if you ignore the history of Red Hat. It used to be "the" Linux company, a paragon of what you can achieve by combining business acumen of the corporate world with complete transparency of the open source process.

When the first clones of RHEL appeared, they received C&D letters about the use of "Red Hat" in the name, so they complied and started to replace the branding before recompiling. Who would expect that the only free-as-in beer RHEL clone we'll be able to use will be Oracle Linux.

Post reply on HN