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.

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

This is still true from what I see, but in both families of distributions this is not a big requirement anymore. In my Debian based systems, libx264 is the only thing which requires multiple versions needs to be installed from what I remember.

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.

> .deb is a really good package manager, and is arguably more sophisticated than RPM.

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.

I don't know the reasons behind the design decisions of apt. I know its workings up to a point, but not the history behind them.

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.

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"

The birds remained part of the schengen zone and have freedom of movement :)

Always been a bit jealous of birds for their freedom. It comes at a cost of course, but so does being human.

Freedom and brains.

Reminds me how "bird brain" is sometimes used as an insult, when they're some of the smartest animals with very densely connected brains. https://www.dhanishsemar.com/writing/bird-brains

Didn't know Uri Geller was an investor now.

It's a mere imitation but they do deform the target using their own mentality so there is that.

Don't do it Fedon!

I had to look that up, dear god

Site down, maybe they need port it to use Rust...

They use wordpress

A lot of infrastructure is going to be ported to Rust.

It's fantastic for websites and servers, and LLMs are very good at generating it.

The primary downside of Rust is the long compile times, especially with macros (serde, etc.) If that can be fixed, it will be sublime.

I like Rust a lot but I'm not sure it would come very high up my list for web applications.

Axum and Actix are phenomenal web frameworks.

The type system and error handling ergonomics make it easier to write defect-free code than, say, Go or Java.

Simple servers are request scoped and mostly feature linear request handling, so you're writing simple vanilla Rust without the complex pointer semantics that you would use for systems programming. The async pieces aren't difficult either.

Serde-annotated structs are the best serialization/deserialization story anywhere. It integrates super ergonomically into Axum and Actix to make writing request handlers a breeze. They're super easy to read, too.

> Axum and Actix are phenomenal web frameworks

Compared to what? I see ASP.NET Core and Quarkus very competitive. The virtual threads in Java are great, paired with structured concurrency IMHO.

If I have to go microservice or API, I would choose FastAPI for fastest delivery and if I have to rewrite, Go, unless it is massive scale and scaling horizontally becomes a headache I would not consider Rust/C++ for this.

All the backend, etc. for the company I have been working for is C++ for the fast parts but all tools around are Python (with NiceGUI and Flask mostly).

I think the combination is quite powerful, btw.

Say more. I need me proper rust in the browser.

At work we're moving almost everything to Rust on our backend. Massively reduced memory usage and significant latency improvements relative to our Typescript codebase. Even for code that you'd expect to work well in TS, a near 1 to 1 port to Rust has considerably improved our best case and, in particular, our worst case latencies. And the memory we get back is huge, we may even drop our instance size down with the 800MB of RAM we're likely going to save.

To be fair, it's not that hard to get an improvement compared to running TS in the backend.

I agree, but I think most people actually don't think that's true when it comes to services that primarily do IO.

First compile. Every another will be significantly faster since compiler is incremental

What is wrong with wordpress exactly?

there are a lot of really bad plugins that are used. Also there are a lot of really bad admins who have out of date versions that are misconfigured.

And even if a plugin is disabled, the code can still be called.

Matt Mullenweg

wordpress

How many contraction/expansion cylces do you normally see in a DC setting, generally? Is there a measure for that to baseline against?

IIRC it's thousands per day on these systems, mainly due to high power density and low mass, even small lapses in computation (100-500ms) rapidly change the temperatures of stacked die.

So even a GPU averaging 98% utilization may have thousands of cycles per day.

Compared to a regular server blade it may be dozens or barely any at all.

Naive question, but could this not be fixed by a scheduler? If it's only idle 2% of the time, give it busy work for that 2%

the easier answer would be to remove the ability to idle