And after all of that, dnf auto update still doesn't support auto restarts for kernel updates, amazing. Also no in-place upgrades since for ever.
Fermilab/CERN recommendation for Linux distribution
81–90 of 144 posts
Re: Fermilab/CERN recommendation for Linux distribution
#82What I didn't like about AlmaLinux so far is that it takes more effort to google solutions to problems than for Ubuntu. That may sound stupid or lazy, but there it is.
Re: Fermilab/CERN recommendation for Linux distribution
#83Earlier quoted context omitted.
Yes. It's too bad because they used to support Scientific Linux, but stopped because CentOS was so popular... Anyway, I'm glad I went with Alma over Rocky, albeit for the wrong reasons (my daughter's name is Alma...)
You probably know this, but Alma means “soul” in Portuguese. Is this why you picked the name? I like it. I went with Ada myself (after Lovelace - wife only found-out why years later).
ALMA is also a radio telescope in Chile (the Atacama Large Millimeter Array), which is somewhat closer afield to what I do.
Re: Fermilab/CERN recommendation for Linux distribution
#84Earlier quoted context omitted.
What do you mean growing your system? “How do you run more service?” Or “how do you handle more traffic?” Or “how do you handle more complexity of the application?” All of these can be handled with any or many of VM images, containers, home-built packages and configuration-management tools. If you're following the latest trend, you just run VM based on an image with pre-installed kubernetes. Want to run more services…
> Want to run more services? Just deploy more services on your k8s cluster. Want to scale horizontally to handle more traffic? Just boot up more VMs with the same image, and increase the size of your k8s pods. Want to handle multiple more complexity, split your job into micro services, and give responsibility of different namespaces to different teams. As someone who strives to keep things simple (as in running the l…
Re: Fermilab/CERN recommendation for Linux distribution
#85All this time I had thought that Rocky Linux was winning the fork war over Alma (in the fight to be the successor to CentOS), but this post might change that with a good chunk of the science community throwing their weight behind Alma. Do we have anyone else in the audience that has any insights over whether Alma is more prevalent over Rocky or is it the other way around? I know I can run Rocky Linux from DigitalOcea…
Re: Fermilab/CERN recommendation for Linux distribution
#86Earlier quoted context omitted.
> Want to run more services? Just deploy more services on your k8s cluster. Want to scale horizontally to handle more traffic? Just boot up more VMs with the same image, and increase the size of your k8s pods. Want to handle multiple more complexity, split your job into micro services, and give responsibility of different namespaces to different teams. As someone who strives to keep things simple (as in running the l…
Complexity is relative. I'm a ansible + packages kinda-guy, so of course k8s feels bloated. But Nix with "its compile everything and store the results in deep directories with sha256 hashe names, and if two programs depends on two different patch versions of sqlite, just compile and keep both in parallel like npm" feels really bloated to me.
This can make sense in the scientific environment where reproducibility as precise as possible (incl. precise speed and memory usage of every specific algorithm) is very desirable. But in IRL this (different apps ignoring the proper "Unix way" of sharing libraries and updating them independently to the apps, depending on specific versions instead) always is very annoying. Every time I have to run an old app that requires old libs non-existent in my distro version I just symlink the names to the new ones and everything works great. Every time I download a Python project with requirements set to specific versions I replace the requirements with "this or newer", update and everything works great. Theoretically I can imagine a situation when an SQLite version upgrade can break somethiong but practically I can't - I bet this will never happen to me and if it does I'll just pay my bet by fixing the problem manually.
Re: Fermilab/CERN recommendation for Linux distribution
#87I would prefer to use RedHat based distros but their lack of official non free repos annoy me - I don’t want to add a community repo, I want packages maintained by trusted core engineers. Sure the community repos probably have that, but I last I checked I couldn’t find any assurance on the security of the community repos. SBOMs don’t mean shit if you’re installing stuff from random no-assurance locations.
Re: Fermilab/CERN recommendation for Linux distribution
#88Not really interesting. Without any technical reasoning other than "we want red hat with extra perks".
Re: Fermilab/CERN recommendation for Linux distribution
#89Earlier quoted context omitted.
What is the problem with systemd?
Do your homework. This has caused enough wars, hatred, threats, splits and forks already over the years.
We got group of clowns that repeat stuff like "but sysV is simple, init scripts are simple to make" and we have (...had, after migrating off) thousands of lines of init script fixes to prove that they are not that simple to get right, all replaced by few lines of system.
Then there is another group of clowns repeating "but it's too complex, we don't need all of the unit features", then proceed to put that features in separate app that works badly (monit), separate app that is just different init system in disguise (supervise, which is entirely fine piece of software that does it thing well), or just don't do anything serious with their systems in the first place.
I have plenty of complaints about many things in systemd but I won't pretend it didn't save us thousands of lines of code thanks to some of those features and made running more complex stuff trivial.
For example one of our is "wait for network -> download key from key server -> decrypt partition -> mount encrypted partition -> start the services". init.d version of that was... gnarly at best, and pretty fragile, it was trivial under systemd with nearly no actual scripting needed.
Re: Fermilab/CERN recommendation for Linux distribution
#90Earlier quoted context omitted.
Yes. It's too bad because they used to support Scientific Linux, but stopped because CentOS was so popular... Anyway, I'm glad I went with Alma over Rocky, albeit for the wrong reasons (my daughter's name is Alma...)
You probably know this, but Alma means “soul” in Portuguese. Is this why you picked the name? I like it. I went with Ada myself (after Lovelace - wife only found-out why years later).
But we ended up not using it.