Why not just hand them over to agentic AI in a flatpack running on a VM in Docker container in the cloud?
That probably would finally give us HalfLife 3.
The reason is old hardware support:
The reason for all that was a compiler flag. When Red Hat builds RHEL, it picks a minimum CPU generation the software will run on. RHEL 9’s cutoff already excludes CERN’s oldest boards, the kind running chips like Intel’s old Core 2 Duo, which comprises about 47 percent of their fleet.
RHEL 10 raises that cutoff again, and this time even newer Ivy Bridge-generation boards, another 17 percent, fall on the wrong side of it.
Core 2 Duo, wow! Present day raspberry pi is likely faster and much more power efficient. Not to mention security considerations.
Yes, but unlikely to support what CERN needs to do.
Like sitting in the form factor of a laptop from 2012 that can rest between these two cabinets
Debian is also planning on raising the bar.
Yes, but not yet, which is all CERN needs for now.
They’ll undoubtedly switch to something else in a few years if they continue to favour hardware retention over software compliance.
Spiralling off into rampant speculation, I can imagine they might end up finding some way to create their own in-house Linux distro that supports old hardware if all the stock distros raise the bar out of the reach of what they have, but I’m sure they hope that’s a way off yet.
But it could be a good thing for folks outside CERN with old hardware if that ever comes to pass.
Also they are sponsoring the maintenance to match their needs.
Either path depends on Debian’s LTS and ELTS programs staying healthy, which is part of why CERN has started sponsoring Freexian, the Debian-focused services company behind those support programs.
They killed off 32bit machines but that is the existent of it for now
chips like Intel’s old Core 2 Duo, which comprises about 47 percent of their fleet
That’s just a crazy number and I was not aware how dated their systems were. On the other hand, never touch a running system.
The LHC was completed in 08. That chip was sold from 06 to 12. This means basically half the pc’s they bought ~15 years ago are still meeting their needs.
Honestly, this is the way it should be. The only reason most enterprises upgrade their computers is because Microslop, and all the other proprietary software they’ve allowed themselves to grow dependent on, require it; not because a 20 year old computer isn’t snappy on Debian, or isn’t powerful enough for email, docs, and browsing. The LHC requires supercomputers and server farms for primary operations. These pc’s are basically just thin clients to access those resources.
There are still a shocking amount of Windows XP and 7 systems in production, because the software stack doesn’t need to be updated. If those systems had been deployed on linux 20 years ago, they would still be fully capable of receiving security updates.
I work manufacturing, any computer that isn’t connected to the internet doesn’t get upgraded. Windows XP on PLC touchscreens.
Yeah, maybe your CISO should read a book about Stuxnet lol
I’m not sure he can read :( Or fix a landline phone connection, apparently.
Yeah, and that’s generally fine if it isn’t critical infra that could be targeted by bad actors, and they don’t have wifi or uncontrolled interfaces. The risk and damage of someone pulling apart an ATM to get at a USB port is negligible.
The main problem with it is the longer things don’t get upgraded the less people know how to fix or service them, which adds extra friction and cost to change anything with each passing year. After 10-20 years of zero updates, major projects are required because the OS and software stack need a complete overhaul to make even the smallest software change, and the software becomes a major bottleneck to organizational change or operations.
You are saying that to someone who recently bought a Lenovo T420 with a new battery pack, installed Debian with Xfce. An amazing work horse.
The only reason most enterprises upgrade their computers is because Microslop
Honestly - not true. It’s compliance. Compliance says you need to be insured, insurance says you need to have vendor support, vendor says sorry, your old shit is out of support.
Good job, now remind us who the os vendor was again…?
The older CPUs are incredibly inefficient
They would probably cover a good amount of the upgrade cost in just power savings
We use measurement systems where the data aquisition runs absolutely fine on an IBM AT.
Keep in mind that they’re talking about hardware control systems and not compute nodes. On these machines, the savings would probably not be too big (no/few consolidation gains). It also sounds like the decision was less about the upgrade cost and more about avoiding failure risks.
I also ran the numbers for fun. They estimated the cost to be 5.4MCHF for 2200 machines. Assuming 0.2CHF/kWh, they would need to save 140W per machine for 10 years to offset the upgrade cost. So, yes, it could indeed offset a good part of the upgrade cost over time.
I have doubt about this
Oh no, why not just pick omarchy instead?? /s
as a Debian user: I wish they had chosen a distro that didn’t just decide to accept slop contributions.
Enjoy BSD then, because Linus Torvalds also uses LLM’s
Torvalds losing his marbles is not new, sadly.
He’s not making slop patches to the kernel.
So you are implying the Debian maintainers are adding “slop”?
No dawg that’s a whole new sentence. I have no knowledge nor complaints about what Debian is doing, I’m just saying the wording used previously in this thread isn’t a fair characterisation of Linus.
How exactly are you defining “slop” here?
They aren’t accepting slop
They are. Their decision put the responsibility squarely in the hands of the submitter, with no need to even declare use of slop assistants.
The rest of the Debian policies didn’t magically disappear. Debian only accepts code that meets a certain standard.
in theory. Need reviewers for that, though.
I mean if you want something that’s stable and you really don’t have to think about upgrading similar to Debian there’s always NixOS. wee bit of a learning curve but once you have it configured you can pretty much forget about it. can even run stuff without installing it if you wanted.
As a programmer, I can always run stuff without installing ;) As a user, however, I wish to have 3D acceleration capable graphics drivers for the occasional game.
I mean they could have just picked Debian 12… I doubt Debian will make retroactive slop updates to older versions of the distro. At least that’s what I’m doing on the systems I administer: set up a custom package that conflicts with base-files >= 13 and with some already-known slopified version numbers (thanks to Open Slopware) to keep things a bit more under control.
Could have but
- I somehow doubt they did
- patches flow back into stable, too.
I had to freeze rsync because of that :(
Thanks to how Debian versions packages, numero 2 is solved with a package solution like mine (liberal use of
>for package version comparison), so that you can’t install the updates that come with slopification.
