Well they could have used Debian from the start. I get why, but it's such a strange argument, the way it's posited.
We used to run it on our Grid nodes, and while it was not bad, it was not that smooth, either. It was a little kludgy but worked if you didn't diverge from the happy paths much.
Now Debian has Extended Long Time Support via Freexian, I believe CERN has enough confidence to use Debian instead of RH family, and that will make lives of some people way easier. Debian is still easier to manage than RH based systems, and .deb is a really good package manager, and is arguably more sophisticated than RPM.
I'm in this for a couple of decades now.
Now a colleague of mine is handling these. I'm more on the OpenStack & HPC side for other stuff.
> Debian is still easier to manage than RH based systems, and .deb is a really good package manager, and is arguably more sophisticated than RPM.
It's so bad. Coming back to RHEL (new client requirement) after sitting mostly on Debian for years is such a bizzare experience.
You want to install a PostgreSQL database, it doesn't even initialize it, you need to manually do DB init and the rest of the dance.
You want to run DRBD, sorry, we didn't bother to pick that kernel compile option, you can add extra repository for that. But hey, it's the kernel module, which means now you have to enroll cert in Secureboot, and that requires actual KVM access to the VM for someone to confirm it so now I'm on meeting with customer's IT just so they click some buttons in VM's boot process.
Even some common utilities are not in main repos but need EPEL
Yes, but this sentence didn't convince who was making these decisions back at CERN, approximately 20 years ago! I'm not even convinced that it was that possible and painless 20 years ago.
We agree about the rest of us, but I still ask why about EPEL stuff while writing salt recipes.
Update system, install EPEL, update system, install creature comforts is a such a bizarre dance to make while I can just write a one long apt command and get a better system in 30 seconds.
...and aptitude. Yes, that TUI thing. It's magnificent.
I once installed a Sun workstation with AMD processor (Athlon64?) and nForce (4?) chipset. The ethernet card was there but it didn't initialize, why? Because RedHat EOLd the kernel module. Why? Because.
Reinstalled the thing with Debian after fighting it for 30 minutes or so, and the thing worked happily ever since.
I realize I'm veering a bit off-topic :), but I've used Debian for a long while, but I do wonder how is that deb is more sophisticated than rpm?
The one feature I remember (a long time ago) rpm being able to install the different versions of the same package, although I suppose this in practice would only work for packages made for this, and libraries would usually be such packages. With debs this means the version number needs to be embedded to the package name with some developer-chosen precision.
On the other hand, RPM still doesn't know about reverse dependencies, automatically/manually installed packages, version holds, etc.
Either one is advanced enough to handle a big distribution and have their advantages w.r.t. each other, but I still prefer .deb as a person who works with both. Also, .deb can encode much more information about the software package it contains.
Perhaps. I wouldn't argue either way, but dpkg still maintains its "data base" of installed and available packages/files as plain text files rather than using a DB format like sqlite (which one might chose for such today) or Berkeley DB (back when). The performance difference is negligible today on fast hosts with NVMe backed storage, but fairly annoying when using lesser machines with slower storage, e.g. RPi with root fs on a SD card.
On the other hand, I have been using Kingston Canvas Go SD cards on my Raspberry Pi boards for a fairly long time now, and these cards' random access speed is above and beyond of other, older cards while not being expensive.
Now apt works like it's running on an SSD.