Polson - NoSlop

it was right in front of you :)

Hey, it's 99.9 if you look at it upside down.

6.66% uptime? Give github a few years they'll get there

Uptime of the Beast

How many rollingupdate pods does it take to change a lightbulb?

Eventually.

Oh nice, not aware of this. We're opentofu on GCP, so could be a good addition to ci

That's by design.

Well they could have used Debian from the start. I get why, but it's such a strange argument, the way it's posited.

If I remember correctly, the reason why Scientific Linux was RHEL based instead of Debian because RedHat was a company and can pay them for services.

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.

Yea, long time user of both here (I even supported ATLAS workloads running on our public UK cloud). Debian long-term is the right choice

We might have exchanged some mails back in the day probably, then. :D

I'm in this for a couple of decades now.

Quite possibly! It was always a pleasure to see the ATLAS jobs running in a process list on an OpenStack hypervisor. We supported Lancaster University for compute (amongst others!).

We ran and still run things bare-metal. If you remember the site names, we had quite a few TR-XX sites. I hailed from some of those.

Now a colleague of mine is handling these. I'm more on the OpenStack & HPC side for other stuff.

You can pay companies just fine to support Debian.

> 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

Ironically back around 2007 we had to use RHEL to get DRBD setup for the Redhat HA / Pacemaker things

RedHat has a bad habit of dropping support for things not because they need maintenance but because they're just old.

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.

> You can pay companies just fine to support Debian.

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.

A quick reference shouldn't require me to have to check the quick reference for hallucinations.

Maybe originally, I'm sure their larger market share is now the embedded market. The whole compute module thing.

The salt caves were only designed to be used a few times and to be used for maximum draw down, weren't they?

Been many an MIR that I've seen where after initial assessment, the next log entry was "service restart attempted"