22
Good News! CERN is Migrating Over 2,200 Control Systems to Debian 13 (itsfoss.com)
submitted 2 months ago by to c/debian@lemmy.ml
1 comment fedilink hide all child comments

1 comment

sorted by: hot top controversial new old
[–] 2 points 2 months ago

Though this doesn't mean that the whole CERN IT infrastructure is being moved. The migration is specific to the accelerator control layer—the front-end computers that talk directly to the equipment running the beam.

Note that earlier reporting was wrong to suggest all of CERN was moving to Debian. People at CERN clarified that only a small part of CERN is switching.

  • permalink
  • fedilink
  • source
    •
    38 comments in c/linux@lemmy.world view that post
    [–] 64 points 1 month ago (7 children)

    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.

  • permalink
  • fedilink
  • source
  • hideshow 7 child comments
    •
  • [–] 20 points 1 month ago (2 children)

    Core 2 Duo, wow! Present day raspberry pi is likely faster and much more power efficient. Not to mention security considerations.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 2 points 1 month ago (3 children)

    Debian is also planning on raising the bar.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 4 points 1 month ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 3 points 1 month ago

    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.

  • permalink
  • fedilink
  • source
  • parent
    • [+] 30 points 1 month ago (12 children)
    [deleted]
  • permalink
  • fedilink
  • source
  • hideshow 12 child comments
    •
  • [–] 27 points 1 month ago (10 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 10 child comments
    •
  • [–] 9 points 1 month ago (3 children)

    I work manufacturing, any computer that isn't connected to the internet doesn't get upgraded. Windows XP on PLC touchscreens.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 1 month ago

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 2 points 1 month ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] -1 points 1 month ago (2 children)

    The older CPUs are incredibly inefficient

    They would probably cover a good amount of the upgrade cost in just power savings

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 1 month ago

    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.

  • permalink
  • fedilink
  • source
  • parent
    • load more comments (1 reply)
    • [–] 13 points 1 month ago

    Oh no, why not just pick omarchy instead?? /s

  • permalink
  • fedilink
  • source
    •
    [–] 11 points 1 month ago (1 child)

    Why not just hand them over to agentic AI in a flatpack running on a VM in Docker container in the cloud?

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
    • [–] -5 points 1 month ago (13 children)

    as a Debian user: I wish they had chosen a distro that didn't just decide to accept slop contributions.

  • permalink
  • fedilink
  • source
  • hideshow 13 child comments
    •
  • [+] 11 points 1 month ago (3 children)
    [deleted]
  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
    • load more comments (-1 replies)
  • [–] 0 points 1 month ago (3 children)

    They aren't accepting slop

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 1 point 1 month ago (2 children)

    They are. Their decision put the responsibility squarely in the hands of the submitter, with no need to even declare use of slop assistants.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] -1 points 1 month ago* (2 children)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 3 points 1 month ago* (last edited 1 month ago) (1 child)

    Could have but

    1. I somehow doubt they did
    2. patches flow back into stable, too.

    I had to freeze rsync because of that :(

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 1 month ago

    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.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 0 points 1 month ago (1 child)

    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.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
    • 16 comments in c/linux@programming.dev view that post
    [–] 17 points 2 months ago (7 children)

    tldr: their infra that interfaces directly with accelerator uses really old computers and they are unsupported in newer versions of rhel. Only those machines are affected by these good news.

    Personally, this looks weird, they are planning to run like 20 years old machines for another 10 to save money on replacing them while at the same time they are planning (or already in the process) migration to k8s?

  • permalink
  • fedilink
  • source
  • hideshow 7 child comments
    •
  • [–] 5 points 2 months ago (5 children)

    while at the same time they are planning (or already in the process) migration to k8s?

    What's the problem with running those 20 year old machines as kubelets?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 5 child comments
    •
  • [–] 4 points 2 months ago (4 children)

    It actually requires not an insignificant amount of resources for 20 y.o. machines?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 4 points 2 months ago (3 children)

    How much RAM do you think they have? I think a top-notch scientific machine from literally 20 years ago might have like 4GB RAM, maybe a bit more. I'm not sure about non-control-plane kubelet runtime overhead, I see online sources showing numbers as little as 30MB, and as big as 1GB. But even with 1GB you will still have 3GB for work.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 4 points 2 months ago (2 children)

    For regular k8s a few years ago (in my own tests) it hovered around 500-600 megabytes, and some cpu as well (can't say how much would it use on machines this old) so the thing that does nothing but controls what will run on a machine consumes like 1/8th of ram. Also their infra sounds as static as it gets and machines themselves are not pets - they are family members at this point, what would the benefits of k8s be?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 5 points 2 months ago* (1 child)

    what would the benefits of k8s be?

    Compared to what? Manually running software on machines? Automatic distribution of work, automatic networking, linking/transfer of resources, etc. I think their scenarios are often oneshot tasks that need to run somewhere and produce results that get used in other tasks or aggregated somewhere, etc.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 2 months ago

    oneshot tasks that need to run somewhere and produce results that get used in other tasks or aggregated somewhere

    There's decades of effort already done on this kind of software in science. Idk why Kubernetes would suddenly be needed for that.

  • permalink
  • fedilink
  • source
  • parent
    • [–] 10 points 2 months ago

    what a weird title. the actual article is fact base but the title is just weird. why is it good (or bad) news? why not just say "CERN moves over 2,200 control system to drbian 13 to support the older hardware"

  • permalink
  • fedilink
  • source
    •
    [–] 8 points 2 months ago (1 child)

    Weird. I thought CERN used alma linux; https://linux.web.cern.ch/almalinux/

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
  • [–] 15 points 2 months ago

    Almalinux is used for desktop computers (along with RHEL and windows). This is about the control system computers, which have dedicated hardware for various tasks. It was planned for them to also use almalinux, but they dropped support for a bunch of old hardware architectures. This made Alma unsuitable as some of these custom computers just would not be supported. The cost/risk of redesigning just would not make sense. Hence: plan B, which is Debian and its many supported hardware architectures.

  • permalink
  • fedilink
  • source
  • parent
    • [–] 4 points 2 months ago (1 child)

    Aside: I recently fired up a server with Debian 13 and the size was only 900MB compared to 2G of Debian 11, 12 and Ubuntu. Anyone knows what changed?

  • permalink
  • fedilink
  • source
  • hideshow 1 child comment
    •
    • [–] 7 points 2 months ago

    Supporting red hat costs 5.5 Mio for the next ~8 years, and the switch to debian? What would replacing the old hardware (~20 years old) cost?

    It's bad for red hat, good for debian and suse wasn't even considered?

  • permalink
  • fedilink
  • source
    •
    [–] 8 points 2 months ago* (last edited 2 months ago)

    CERN's Black Holes now will be based on debian 13)

  • permalink
  • fedilink
  • source
    •
    [–] 1 point 2 months ago

    Debian my beloved

  • permalink
  • fedilink
  • source
    •