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

101–110 of 163 posts

Re: A Brief Goodbye to CentOS

#101

Post by wirrbel »

Thaxll wrote: post #21
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.

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-enthusiasm isn’t all that much addressing what was lacking in the operations space pre-docker.

Re: A Brief Goodbye to CentOS

#103

Post by j0057 »

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

There's no RHEL8 equivalent of Scientific Linux.

Re: A Brief Goodbye to CentOS

#104

Post by merb »

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

tumbleweed does or rather, tumbleweed does not have point releases. in my eyes tumbleweed is way better for cloud, IoT and desktops, as soon as you use transactional-update

P.S. I'm fallen in love with it.

Re: A Brief Goodbye to CentOS

#105

Post by spicybright »

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…

I think this too. Debian packages I'm sure are powerful but I never sat down and RTFM yet, which I think is a solid requirement. Docker is easier to understand and I picked it up pretty easily just running through a quick tutorial.

Definitely pros/cons to both depending on your situation. I can imagine debian packages being more useful in large scale multi-developer environments.

Re: A Brief Goodbye to CentOS

#106

Post by kkapelon »

g051051 wrote: post #90

> With containers, developers can develop, test, deploy, and rollback with blazing fast velocity. Wow, that has not been my experience with containers.

Can you elaborate?

Even the basic ability to just spin a container with all your stuff and start developing is an important advance. (especially for cases like python2/3, java5/8 etc)

Coupled with the remote containers feature of visual studio, working with containers is now a game changer.

Re: A Brief Goodbye to CentOS

#107

Post by dsr_ »

cactus2093 wrote: post #95
dsr_ wrote: post #80

Earlier quoted context omitted.

Debian plus an automation system like Puppet, Chef, etc works extremely well. It's just not sexy enough for people to write hundreds of posts about how to set up your own package repo, understand unattended-upgrades, and do monitoring.

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

Re: A Brief Goodbye to CentOS

#108

Post by AdmiralAsshat »

mixmastamyk wrote: post #92
AdmiralAsshat wrote: post #36

Earlier quoted context omitted.

Previous product I worked on required a supported RHEL/CentOS environment on which to install our product. Even with the six years or so of support, our customers would piss and moan every time we'd tell them that RHEL/Centos5 was hitting EOL and they'd need to upgrade their servers to Centos 6 or 7 to stay supported. Most of them wouldn't even entertain the idea of "upgrading": for them, business as usual was holdin…

When you update often it turns out to be less work, because more gets automated and changes are smaller. This is the CI/CD proposition anyway.

Except when the update brings some kind of massive change. RHEL 6->7, for example, was when systemd became the norm, and so right around the time our customers started upgrading, I suddenly had the hot potato dropped into my lap of needing to convert 20 years' worth of our software's init.d scripts into systemd services.

Re: A Brief Goodbye to CentOS

#109

Post by laurent92 »

dvfjsdhgfv wrote: post #50
cubano wrote: post #25

Earlier quoted context omitted.

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…

I’m deeply interrogated by Atlassian forcefully moving users to the cloud.

It’s as if, in 5 years, we developers wouldn’t have a safe Linux to deploy on, and then we’d be required to use Amazon Linux or GCP Linux, the other ones being not officially supported and therefore not insured in case of leak, or not approved for PCI or PII or GDPR or...

Re: A Brief Goodbye to CentOS

#110

Post by sickygnar »

zemo wrote: post #89
q3k wrote: post #4

Earlier quoted context omitted.

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

I do it similarly. I run multiple versions of a service at once with systemd service files. It gives me the same stuff as containers - cgroups, isolation, logging, service definitions and automation with ansible, but its easier on my feeble psyche.
Post reply on HN