Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fermilab/CERN recommendation for Linux distribution

news.fnal.gov

Post reply on HN
Print view View original

71–80 of 144 posts

Re: Fermilab/CERN recommendation for Linux distribution

#71

Post by rahen »

karteum wrote: post #63
usr1106 wrote: post #37

Earlier quoted context omitted.

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

Lennard now works for Microsoft anyway. It clearly suits him better.

Re: Fermilab/CERN recommendation for Linux distribution

#72

Post by rahen »

acatton wrote: post #67
amelius wrote: post #51

Earlier quoted context omitted.

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…

> 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 least possible code to achieve something), this part gave me nightmares.

Nothing technically wrong with it, but the "let's just pile up layers" approach works well for maybe 10% of the workload where surface attack and resource efficiency can be traded for elasticity.

But then come the tradeoffs: complexity is multiplicative (this won't suffice, prepare to also manage an ingress, then a service mesh, a secret store...), which becomes a security nightmare, leads to technical debt, requires constant updates and manpower, is almost impossible to properly test and document, has high development costs and resource usage.

To make things worse, this behaves more unpredictably than a traditional 3-tier approach with Compose and Terraform, or nix-deploy.

Adding more complexity to solve complexity turns into a self replicating problem.

Re: Fermilab/CERN recommendation for Linux distribution

#74

Post by dotancohen »

liamnal wrote: post #30
dotancohen wrote: post #16

Earlier quoted context omitted.

As much as it pains me to say it, FOSS devs are a finite resource and it seems that being divided is just as if having been conquered. Neither Rocky nor Alma are progressing at the rate that a CentOS fork with a hostile RH upstream would progress if they were working together and not duplicating efforts. What is the philosophical schism between the two? Why can't they split the workload on a single distro and reunite…

It's just like with any distribution, each have their own philosophies and how they want to tackle something. Oracle Linux is still around for example, but we don't talk about them too often. Rocky seems to have mostly volunteers. Alma has people who are likely paid because they come from or likely still work for CloudLinux. Either way, you're getting a RHEL clone if you go with either. And that is keeping in mind th…

  > The thing to keep in mind is that more choices are better than just having one.
I disagree that this is universally true. If (as it seems) Rocky and Alma have similar philosophies then significant dev resources are being duplicated, at the expense of other functionality.

Re: Fermilab/CERN recommendation for Linux distribution

#75

Post by KronisLV »

flumpcakes wrote: post #55
bayesian_horse wrote: post #19

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

Ubuntu was/is by far the more popular distro to use outside of the corporate world. There's a lot more blogs, container base images, tutorials out there because it was popular for tinkerers. This is also the reason it has now become popular inside the corporate world. You may find it harder to find resources for AlmaLinux/CentOS/etc. if you are using the same methods for searching for resources as you would for a Ubu…

> You may find it harder to find resources for AlmaLinux/CentOS/etc. if you are using the same methods for searching for resources as you would for a Ubuntu (or even Debian) based OS.

Not only that, but as soon as you venture outside of the "happy path", you'll run into difficulties if others haven't also solved those problems ahead of time, which can be the case with many DEB distros but isn't always so with RPM ones.

For example, in many RPM distros you'd typically reach for using Podman for running container workloads, maybe even use something like OpenShift (their MicroShift project still being in the works).

In contrast, on DEB you'd at least sometimes go with Docker, because it's widely known, widely used and still has lots of market share - offering such lighweight orchestrators like Nomad or even Docker Swarm out of the box, which still is an okay choice for getting a dev environment running on a few boxes with 8 GB of RAM, when you don't have a separate node for managing the cluster.

Now suppose that you decide to go with Docker on RPM. It's definitely feasible and has gotten better, but I recall just a few years back Docker having issues with SELinux and also the container networking utterly breaking because of firewall configuration. You had to use the masquerade option if I recall correctly, which definitely fixed the issue but also meant that the software package ships broken by default, in a sense.

On an unrelated note, I recently ran into an issue with one of the RPM distros a week back, where if the node has swap enabled and it runs low on swap memory, it's going to have the kswapd process start eating a lot of CPU resources and basically bring everything else on the node on a standstill.

Not to say that RPM is worse, the LTS EOL cycle alone is amazing, so I wish Rocky and Alma (As well as other distros) the best of luck! But I can also definitely recognize why many would stick with Debian or Ubuntu (or other DEB distros).

Re: Fermilab/CERN recommendation for Linux distribution

#76

Post by jacooper »

1letterunixname wrote: post #17

I went through the Rocks Cluster cycles in 3, 4, and 5 with SLC and Scientific until those fell by the wayside. Rocky is the underdog you want to win. Alma is the leader except in terms of security update latency. 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. It's hard to convince corporate folks to use Alma when Cent is still…

Apperantly stream is the slowest. https://news.ycombinator.com/item?id=33905616

Re: Fermilab/CERN recommendation for Linux distribution

#77

Post by Conan_Kudo »

dapozza wrote: post #12
rurban wrote: post #11

Earlier quoted context omitted.

I have insights. Alma is done by professionals for professionals (the hosting industry). Those guys were behind CentOS, and are running 70% of the internet. Rocky is an unpaid community effort.

No. Rocky is done by the guy that started CentOS.

Strictly speaking, Greg Kurtzer didn't start CentOS. He started cAos, and people within cAos started CentOS to bootstrap cAos. When the CentOS and cAos people couldn't get along, CentOS left cAos to be its own thing. Lance Davis probably has more claim to being the founder than Greg Kurtzer, as he was the one that started actually creating the Red Hat Linux rebuild work the led to CentOS.

Re: Fermilab/CERN recommendation for Linux distribution

#78

Post by Conan_Kudo »

bclemens wrote: post #50
rurban wrote: post #11

Earlier quoted context omitted.

I have insights. Alma is done by professionals for professionals (the hosting industry). Those guys were behind CentOS, and are running 70% of the internet. Rocky is an unpaid community effort.

No. Alma Linux is done by CloudLinux, and still uses their infrastructure, secure boot certificate, etc (according to their page at https://web.archive.org/web/20221208102246/https://wiki.alma... ). They have never had anything to do with CentOS. Rocky Linux _is_ community oriented, and _is not_ beholden to a specific company, but it is not necessarily unpaid. The majority of the most active contributors to the proje…

AlmaLinux uses their own secure boot certificate, as noted in their last shim-review: https://github.com/rhboot/shim-review/issues/250

EDIT: actually link to the right shim-review ^_^;

Re: Fermilab/CERN recommendation for Linux distribution

#79

Post by tremon »

acatton wrote: post #41
qwerty456127 wrote: post #31

Obviously stability is the most important factor for the people running nuclear experiments so they choose RHEL. Nevertheless, if I were them, I would consider trying Nix or Guix to potrntially turn the configs/builds into comparably strict math and making these reproducible.

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.

Personally, I think the chase for silver bullets does more harm than good. I'd rather work with multiple configuration management tools that do one thing well, than to deal with new contenders that seem to want to do it all and spend little effort in being interoperable with other needs outside their use case.

As a single example: Guix does not support setting capabilities on binaries in the store; if you want to set CAP_NET_ADMIN on ping, or you want some service to run with CAP_NET_BIND_SERVICE, you're stuck. There is no way to make it happen inside Guix, so you're left with very ugly manual hacks (mount --bind /gnu/store /mnt ; setcap...; umount /mnt). Similarly, neither Nix nor Guix can be used as a deployment tool only, since they do not preserve post-deployment configuration changes (to the point that GuixSD even deletes user accounts if they're not in the system configuration).

Re: Fermilab/CERN recommendation for Linux distribution

#80

Post by flumpcakes »

rahen wrote: post #70
flumpcakes wrote: post #58

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

> Do your homework.

You assume I don't know what systemd is or why people have complained? This is frankly a rude comment to make and shows yourself in a very poor light.

I thought it was pretty common knowledge in 2022 that systemd is fine. It's the default in the vast majority of Linux distros. The vast majority of people have gotten over the drama of change. I was asking for a specific reason why someone was complaining about it now. I expected the reason to be new. Complaining alone doesn't add much to the discussion. You're dismissive comment also doesn't add anything to the discussion.

Post reply on HN