- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
You must log in or # to comment.
Oh no, why not just pick omarchy instead?? /s
Why not just hand them over to agentic AI in a flatpack running on a VM in Docker container in the cloud?
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?
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 slow 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.
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.
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.
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.
Debian is also planning on raising the bar.
They killed off 32bit machines but that is the existent of it for now
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.
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
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.
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 older CPUs are incredibly inefficient
They would probably cover a good amount of the upgrade cost in just power savings
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…?
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.
I have doubt about this
