Honestly, I won't be sad if this means appliance and VM image providers (for on-prem / private cloud application hosting) switch to Debian en masse. I only use CentOS where Debian is not an option.
A Brief Goodbye to CentOS
151–160 of 163 posts
Re: A Brief Goodbye to CentOS
#152The 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…
The CVE database and Linux Kernel Self Preservation project beg to differ in regard to security.
Re: A Brief Goodbye to CentOS
#153Earlier 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…
In 2000, I had HP-UX Virtual Vault (aka containers) and CGIs (aka lambda functions).
Everything old is new again.
Re: A Brief Goodbye to CentOS
#154> 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.
Maybe for very small projects. But the scale of things I work on doesn't lend itself to that sort of thing.
Re: A Brief Goodbye to CentOS
#155> With containers, developers can develop, test, deploy, and rollback with blazing fast velocity. Wow, that has not been my experience with containers.
A lot of this depends on your CI/CD environment. In ours, every single push to every branch on the remote repo ends up building a testing/building a full container environment that is ready for deployment in the cloud - with no differentiation between production/development in terms of completeness. It's fast enough, that some (obv not most) developers don't even set up their local docker environment, and just use th…
They want to implement that sort of thing, but it just doesn't work for very large projects.
Re: A Brief Goodbye to CentOS
#156As others have noted, something like this was expected once IBM purchased RedHat. Looking forward, I’m excited for the future of Rocky Linux.
Rumor is RH was planning this from before merger. Supposedly they wanted to do it before C8 release. It was handled in a very hamfisted way. Permitting entities to rebase from C7 -> C8 and then pulling the plug has caused tremendous ill will.
> Rumor is RH was planning this from before merger.
I fully believe this. Like I noted in another comment https://news.ycombinator.com/item?id=25358847, they have done this exact similar thing in the past with the JBoss application server community edition.
Re: A Brief Goodbye to CentOS
#157Earlier quoted context omitted.
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.
Honestly I thought it was fine and I completely agree. It’s not like parent is a moderator and his/her interpretation is de facto/de jure
Re: A Brief Goodbye to CentOS
#158The 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…
The kernel isn't super secure. There are way too many CVEs, and the kernel now has 28 million lines of code. That is a massive surface area for bugs and exploits. Even with LTS kernels, you can still expect to update your kernel a couple times per year with security patches. Each time that happens, you're gonna need to reboot.
You're right that LTS work doesn't go away...bugfixes will still need to be backported to old software versions. But that work is actually quite a bit easier when it is not so tightly coupled to kernel versions and repositories that are unique for each distribution and release version and architecture.
That complexity is a combinatorial explosion. Instead of having a different codebase for each (PackageVersion,KernelVersion,Distribution,Release,Architecture) combination, you would only need to maintain a codebase for each (PackageVersion, Architecture) combo...and maybe for packages which are trivially cross-compiled, even fewer.
Re: A Brief Goodbye to CentOS
#159The 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…
I think it's going to be more like hypervisor + vms + containers.
A proper analogy is probably a city block in NYC. Lots of buildings of various eras with the only commonality being utilties in and out plus the ground they sit on.
Although periodically buildings are knocked down and rebuilt, this is an exceptional circumstance.
Re: A Brief Goodbye to CentOS
#160Earlier quoted context omitted.
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
MariaDB?