Live data from Hacker News

Fermilab/CERN recommendation for Linux distribution

news.fnal.gov

61–70 of 144 posts

Re: Fermilab/CERN recommendation for Linux distribution

#61
post #56

I’m out of the loop on RHEL forks. Can someone explain why it is important to be binary compatible with RHEL? Is there a lot of software whose binaries will only run on RHEL? Or is this more a case of wanting something free that can still make use of RHEL-specific skills and knowledge?

As soon as you use something like SAP or Oracle the number of offically _supported_ distributions quickly decreases. As example SAP HANA: RHEL and SLES or for example Oracle Database: RHEL, OEL (based on RHEL AFAIK) and again SLES.

So it is not only a question if it would theoretically/technically fail on another platform.

Re: Fermilab/CERN recommendation for Linux distribution

#62

Earlier quoted context omitted.

It's a RHEL clone, so no. However, you can install runit or OpenRC if you want.

That doesn't solve the problem, because systemd developers have insinuated dependencies on it into multiple unrelated system components.

That is interesting; can you point to specifics? I am generally a proponent of orthogonality in my system components, although I am not opposed to the core structure of systemd.

Re: Fermilab/CERN recommendation for Linux distribution

#63
post #37

Earlier quoted context omitted.

That doesn't solve the problem, because systemd developers have insinuated dependencies on it into multiple unrelated system components.

Linux developers have created dependencies on Linux. Portability is a lot of work and perfect portability does not exist. If you think you don't want systemd, why don't you use BSD?

There are cases where you might want to use Linux (for the hardware support, or for the userland) but without systemd: e.g. if you want to use musl libc, Lennard has said clearly he won't fix the incompatibility https://www.mail-archive.com/systemd-devel@lists.freedesktop... "we will rely on good APIs exposed in the generally accepted Linux API which is the one glibc exposes" (i.e. he won't integrate any required patch to make systemd work without glibc's nonstandard behaviors, and musl doesn't aim for a bug-for-bug compatibility with glibc).

Re: Fermilab/CERN recommendation for Linux distribution

#64
post #56

I’m out of the loop on RHEL forks. Can someone explain why it is important to be binary compatible with RHEL? Is there a lot of software whose binaries will only run on RHEL? Or is this more a case of wanting something free that can still make use of RHEL-specific skills and knowledge?

When I was working for the US government we had to obey rules against shipping "freeware," which RHEL wasn't because we payed for it. But it was cheaper and easier to do most of our development on CentOS systems and because the software was the same we weren't worried about compatibility issues.

Re: Fermilab/CERN recommendation for Linux distribution

#65
I 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

#66
post #20

Earlier quoted context omitted.

Correct. Although I don't think Rocky has nearly as much money, staff, or industry support as Alma does. The other issue is RH gets Cent 8/9 Stream CVE fixes out faster than either Alma or Rocky, at least so far.

> The problem is that Cent 8/9 Stream has quicker critical CVE patches because it's essentially the source and is closer to mirroring RHEL. This isn't entirely true, at least for embargoed CVEs (so the most critical vulnerabilities). RHEL will always get embargoed patches first. Once RHEL releases the patched packages, Alma/Rocky can rebuild them too. The patches may not be available in Stream yet at this point. This…

Hello fellow redhatter in the kernel engineering group ;)

Re: Fermilab/CERN recommendation for Linux distribution

#67
post #51
post #41

Earlier quoted context omitted.

Config can also be made reproducible with VM images, containers, home-built packages, configuration-management tools (ansible, puppet, …) or a mix of all or some of them. Nix/Guix is no silverbullet.

How do you grow your system, or do you suggest that you build your system as a bunch of microservices running inside containers?

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

If you're using a late 2000s, early 2010s model, you would just use VM, and boot them when necessary. You have a VM with HAProxy with dynamic backends.

Want to run more services? Just add more to the base image and route between them with a nginx local to your base VM image. Want to handle more traffic, just spin up more VMs with the base image. Want to handle more complexity? Use multiple types of VMs with different base images, depending on the service, and give the responsability to each team for configuring the base image.

I can go on and on for packages and/or configuration-management tools. But I think you get the idea.

Re: Fermilab/CERN recommendation for Linux distribution

#68
post #37

Earlier quoted context omitted.

That doesn't solve the problem, because systemd developers have insinuated dependencies on it into multiple unrelated system components.

Linux developers have created dependencies on Linux. Portability is a lot of work and perfect portability does not exist. If you think you don't want systemd, why don't you use BSD?

Because systemd is not the reason why people choose to use Linux over a BSD.

Re: Fermilab/CERN recommendation for Linux distribution

#69

All 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…

Rocky is "winning" if by "winning" you mean more widely used. Here are some graphs charting usage through EPEL statistics: https://rocky-stats.tiuxo.com . The source used to generate the graphs is available at https://github.com/brianclemens/rocky-stats , however please be kind to the Fedora servers and don't download the stats database too often if you use it. Also Rocky Linux is far larger in terms of community siz…

> Here are some graphs charting usage through EPEL statistics: https://rocky-stats.tiuxo.com.

As someone who has had to use Oracle Linux for quite a few projects due to requirements, those graphs are actually a sobering look on things.

Of course, all of those distros are reasonably similar at the end of the day, but it's pretty clear that the popularity of Rocky Linux, Alma Linux, and even CentOS Stream are all formidable.

Re: Fermilab/CERN recommendation for Linux distribution

#70

Earlier quoted context omitted.

That doesn't solve the problem, because systemd developers have insinuated dependencies on it into multiple unrelated system components.

What is the problem with systemd?

Do your homework. This has caused enough wars, hatred, threats, splits and forks already over the years.
Post reply on HN