Live data from Hacker News

Gentoo Linux 2025 Review

gentoo.org

131–140 of 204 posts

Re: Gentoo Linux 2025 Review

#131
post #51

Earlier quoted context omitted.

> Red hat certainly burns a lot of money in service of horrifyingly bad people. Red Hat also has a nasty habit of pushing their decisions onto the other distributions; e.g. - systemd - pulseaudio (this one was more Fedora IIRC) - Wayland - Pipewire (which, to be fair, wasn't terrible by the time I tried it)

Pushing their decisions? This is comical. I guess Debian, SUSE, Canonical, etc get that email from Red Hat just go along with it. We better make the switch, we don’t want our ::checks notes:: competitor made at us.

systemd and friends go around absorbing other projects by (poorly) implementing a replacement and then convincing the official project to give up.

Re: Gentoo Linux 2025 Review

#132
post #9

For me, the most underrated takeaway here is the state of RISC-V support. While other distributions are struggling to bootstrap their package repositories for new ISAs and waiting for build farms to catch up, Gentoo's source based nature makes it architecture agnostic by definition. I applaud the risque team for having achieved parity with amd64 for the @system set. This proves that the meta-distribution model is the…

Fedora and Debian have been shipping RISC-V versions of stable releases for a while. I don't think anyone is really struggling.

Re: Gentoo Linux 2025 Review

#133
post #50
post #25

Earlier quoted context omitted.

I don't know that Red Hat is a positive force. They seem to be on a crusade to make the Linux desktop incomprehensible to the casual user, which I suppose makes sense when their bread and butter depends on people paying them to fix stuff, instead of fixing it themselves.

You don’t know they are a positive force? This, despite the fact that Rocky, Alma, Oracle Enterprise Linux, etc exist because of the hard work and money spent by Red Hat. And what are those companies doing to fix this issue you claim Red Hat causes? Nothing. Because they like money, especially when all you have to do is rebuild and put your name on other people’s hard work. And what exactly is incomprehensible? What…

Just a note: Rocky and Alma came out of CentOS

Re: Gentoo Linux 2025 Review

#134

Earlier quoted context omitted.

I expect people will stop yelling about Wayland when it works as reliably as X, which is probably a decade away. I await your "works for me!" response.

It’s very fair you can say “X works for me” but everyone saying otherwise is in the wrong.

I don't get your point. People regularly complain that Wayland has lots of remaining issues and there are always tedious "you're wrong because it works perfectly for me!" replies, as if the fact that it works perfectly for some people means that it works perfectly for everyone.

Re: Gentoo Linux 2025 Review

#135

Been using Gentoo since 2004 on all my machines. They won me over after I started playing around with their Unreal Tournament demo ISO. The game changer for me was using my NAS as a build host for all my machines. It has enough memory and cores to compile on 32 threads. But a full install from a stage3 on my ageing Thinkpad X13 or SBCs would fry the poor things and just isn't feasible to maintain. I have systemd-nspa…

I'm so interested to learn more about this. Do you still run all your emerge commands on the thinkpad? What's the benefit of mounting /etc/portage over nfs? I have this dream of moving all my ubuntu servers to gentoo but I don't have a clear enough picture of how to centralize management of a fleet of gentoo machines

Yes - still use emerge on the Thinkpad like I would on the host, like emerge -avuDN @world and such. This is the wiki article [1] I used to set up most the portage side of things, it covers NFS as well.

I use NFS to mount the container's /etc/portage to /mnt/portage and symlink the files to the Thinkpad's /etc/portage so I can cherry pick what I want to keep in sync with the build container. Don't have to mess with repos.conf either because portage will look to /var/cache/binpkgs by default.

make.conf is a directory on both machines and has files like 01-common-flags.conf and 02-binhost-flags.conf. The Thinkpad has 01-common-flags.conf and 03-target-flags.conf with EMERGE_DEFAULT_OPTS="--with-bdeps=n --usepkgonly" set, so running emerge -avuDN on the Thinkpad will only update with binaries from the mounted /var/cache/binpkgs. I keep the software in sync by using /etc/portage/sets instead of the world file. Then all the package.* dirs are symlinks as well.

The Thinkpad binhost is a znver3, so the build container has CFLAGS="--march=x86-64-v3 --mtune=alderlake" set. There's some SIMD extensions that two don't have in common and it has to build code that runs on both machines, otherwise you could use the target architecture in --march. Using the --mtune option in my case apparently sets the L2 cache size of the produced code to that of the Intel chip.

Systemd-nspawn containers are super easy to spin up, as you basically install Gentoo from stage3 and it works like a chroot but with a full init. I run updates irregularly, there's still some manual effort for maintenance, but it's mostly just kicking off emerge and letting it build in a tmux session.

[1] https://wiki.gentoo.org/wiki/Binary_package_guide

Re: Gentoo Linux 2025 Review

#136
post #52

Earlier quoted context omitted.

It’s even more pleasant when you use a distro that natively uses systemd and provides light abstractions on top. One such example is NixOS.

NixOS is anything but a light abstraction (I say this as a NixOS user). Tbh it feels like NixOS is convenient in a large part because of systemd and all the other crap you have to wire together for a usable (read compatible) Linux desktop. Better to have a fat programming language, runtime and collection of packages which exposes one declarative interface. Much of this issue is caused by the integrate-this-grab-bag-o…

How is it not a light abstraction? If you're familiar with systemd, you can easily understand what the snippet below is doing even if you know nothing about Nix.

    systemd.services.rclone-photos-sync = {
      serviceConfig.Type = "oneshot";
      path = [ pkgs.rclone ];
      script = ''
        rclone \
          --config ${config.sops.secrets."rclone.conf".path} \
          --bwlimit 20M --transfers 16 \
          sync /mnt/photos/originals/ photos:
      '';
      unitConfig = {
        RequiresMountsFor = "/mnt/photos";
      };
    };
    systemd.timers.rclone-photos-sync = {
      timerConfig = {
        # Every 2 hours.
        OnCalendar = "00/2:00:00";
        # 5 minute jitter.
        RandomizedDelaySec = "5m";
        # Last run is persisted across reboots.
        Persistent = true;
        Unit = "rclone-photos-sync.service";
      };
      partOf = [ "rclone-photos-sync.service" ];
      wantedBy = [ "timers.target" ];
    };
In my view, using Nix to define your systemd services beats copying and symlinking files all over the place :)

Re: Gentoo Linux 2025 Review

#137
post #29

Earlier quoted context omitted.

That is a fantastic historical parallel. The early amd64 days were arguably Gentoo's killer app moment. While the binary distributions were wrestling with the logistical nightmare of splitting repositories and figuring out the /lib64 vs /lib standard, Gentoo users just changed their CHOST, bootstrapped and were running 64-bit native. You nailed the psychology of it, too. The speed marketing was always a bit of a red…

> Since you've been on the ride since '04, I'm curious to hear your thoughts. How do you feel the maintenance burden compares today versus the GCC 3.x era? With the modern binhost fallback and the improvements in portage, I feel like we now spend less time fighting rebuild loops than back then? But I wonder if long time users feel the same. I'm another one on it since the same era :) In general stable has become _rea…

I am replying here as a kind of "better place to attach".

Anyway, to answer grandparent, I basically never had rebuild loops in 19 years.. just emerge -uU world every day or sometimes every week. I have been running the same base system since..let's see:

    qlop -tvm|h1
    2007-01-18T19:50:33 >>> x11-base/xorg-server-1.1.1-r4: 9m23s
I have never once had to rebuild the whole system from scratch in those 19 years. (I've just rsync'd the rootfs from machine to machine as I upgraded HW and gradually rebuilt because as many others here have said, for me it wasn't about "perf of everything" or some kind of reproducible system - "more customization + perf of some things".) The upgrade from monolithic X11 to split X11 was "fun", though. /s

I do engage in all sorts of package.mask/per-package use/many global use. I have my own portage/local overlay for things where I disagree with upstream. I even have an automated system to "patch" my disagreements in. E.g, I control how fast I upgrade my LLVM junk so I do it on my own timeline. Mostly I use gcc. I control that, too. Any really slow individual build, basically.

If over the decades, they ever did anything that made it look like crazy amounts of rebuilds would happen, I'd tend to wait a few days/week or so and then figure something out. If some new dependency brings in a mountain of crap, I usually figure out how to block that.

Re: Gentoo Linux 2025 Review

#139
Looking forward to using Gentoo in WSL more easily. I currently use Ubuntu for some scripting but would switch as I also use Gentoo on the desktop. Also good to see the Rust toolchain and BLAS packaging improvements.

What has kept me on Gentoo since the first Opteron days (20+ years ago) is that once you do an install, you also learn in part how to fix the things you installed, which can be helpful later on. I also do world rebuilds often which I think is just the equivalent of testing an OS backup for a source based OS. :)

Re: Gentoo Linux 2025 Review

#140
post #66

Earlier quoted context omitted.

Did you document this somewhere? I'm interested to know more

Nah, first time I’ve mentioned it anywhere. Happy to answer questions, if there’s interest maybe this could be my reason for a first blog post.

I would encourage you to write about it as well. It seems interesting and unconventional.

I used to tinker a lot with my systems but as I gotten older and my time became more limited, I've abandoned a lot of it and now favor "getting things done". Though I still tinker a lot with my systems and have my workflow and system setup, it is no longer at the level of re-compiling the kernel with my specific optimization sort of thing, if that makes sense. I am now paid to "tinker" with my clients' systems but I stay away from the unconventional there, if I can.

I did reach a point where describing systems is useful at least as a way of documenting them. I keep on circling around nixos but haven't taken the plunge yet. It feels like containerfiles are an easier approach but they(at least docker does) sort of feel designed around describing application environments as opposed to full system environments. So your approach is intriguing.

Post reply on HN