Gentoo is the best! Once you get the hang of creating a bootable system and feel comfortable painting outside the lines, it feels like Linux from Scratch just without needing to manually build everything. I automated building system images with just podman (to build the rootfs) and qemu (test boot & write the rootfs, foreign arch emulation) and basically just build new system images once a week w/ CI for all my hardware + rsync to update. Probably one of the coolest things I’ve ever built, at this point I’m effectively building my own Linux distro from source and it’s all defined in Containerfiles! I have such affection for the Gentoo team for enabling this project, shocking to discover how little they operate on I’m definitely setting up a recurring donation.
I think it is a great learning opportunity, but after using Gentoo for a decade or so, I prefer Arch these days. So if you want to learn more about Linux and its ecosystems, go for it, do it for a few months or years.
That said, I haven't tried Gentoo with binaries from official repositories yet. Maybe that makes it less time-consuming to keep your system up to date.
Been happily and very successfully using the official binpkgs, it works really well, sometimes there's a slight delay for the binary versions of the source packages to appear in the repositories, but that's about it. I guess it's kind of running Arch, but with portage <3! And the occasional compilation because your use flags didn't really match the binaries
Not what was mentioned by parent but I've been working on an embedded Linux build system that uses rootfs from container images: https://makrocosm.github.io/makrocosm/
The example project uses Alpine base container images, but I'm using a Debian base container for something else I'm working on.
Honestly this is just sorta a Tuesday for an advanced Gentoo user? There are lots of ways to do this documented on the Gentoo wiki. Ask in IRC or on the Forum if you can't find it. "Catalyst" is the method used by the internal build systems to produce images, for instance https://wiki.gentoo.org/wiki/Catalyst.
Gentoo is LFS but with the interdependence between packages mapped out for you (all hail the USE flags!) Or, alternatively, Arch with even more customization knobs to twiddle.
I have had Gentoo in at least one nearby system (physical and/or VM) since about 15 years ago. It's always a blast interacting with it.
It's still 100% pure Gentoo (and actually these days even vanilla Gentoo itself offers precompiled binaries) so you still can compile things in rare cases that binary isn't already compiled with use/config that you want.
That’s mostly why I build system images in CI; my slowest builds (qemu user mode emulation of aarch64 for e.g. raspberry pi boards) can take multiple days so I just declared myself a 1 week window between updates and then just pull in the changes via rsync. I even boot the images with qemu as part of the testing cycle. At some point I might try building and hosting prebuilt bins like gentoo does now, I don’t use those though because I explicitly want to build everything from source.
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 only scalable way to handle the explosion of hardware diversity we are seeing post 2025. If you are building an embedded platfrm or working on custom silicon, Gentoo is a top tier choice. You cross-compile the stage1 and portage handles the rest.
While I was always a sourced-base/personalized distribution personality type, this is also a big part of why I moved to Gentoo in early 2004 (for amd64, not Risc-V / other embedded per your example). While Pentium-IV's very deep pipelines and compiler flag sensitivities (and the name itself for the fastest Penguin) drove the for-speed perception of the compile-just-for-my-system style, it really plays well to all customization/configuation hacker mindsets.
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 herring. The ability to say "I do not want LDAP support in my mail client" and have the package manager actually respect that is cool. It respects the user's intelligence rather than abstracting it away.
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.
All distributions are source based and bootstrapped from source. They default to binary packages by default (while offering source packages) whereas Gentoo defaults to source packages (but still has binary packages). There's literally no advantage to Gentoo here. What you're saying doesn't even make logical sense.
Other distros don't support Risc-V because nobody has taken the time to bother with it because the hardware base is almost nonexistent.
> The Gentoo Foundation took in $12,066 in fiscal year 2025 (ending 2025/06/30); the dominant part (over 80%) consists of individual cash donations from the community. On the SPI side, we received $8,471 in the same period as fiscal year 2025; also here, this is all from small individual cash donations.
It's crazy how projects this large and influential can get by on so little cash. Of course a lot of people are donating their very valuable labour to the project, but the ROI from Gentoo is incredible compared to what it costs to do anything in commercial software.
This is, in a way, why it's nice that we have companies like Red Hat, SUSE and so on. Even if you might not like their specific distros for one reason or another, they've found a way to make money in a way where they contribute back for everything they've received. Most companies don't do that.
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.
Red hat certainly burns a lot of money in service of horrifyingly bad people. It's nice we get good software out of it, but this is not a funding model to glorify. And of course american businesses not producing open source is the single most malignant force on the planet.
This was exactly what I was going to comment on. Why are they not spending more money?? I don't even know what they should spend it on, but like.. it's Gentoo! I would have thought they'd pay the core devs something?
It would be interesting to have a more accurate estimate of the effective cost of maintaining Gentoo. Say 100 core developers spend 10h/week, and 380 external contributors 2h/week; that's well over 40 FTE, and at $150K per FTE that's $6 million a year.
The issue is that gentoo isn’t very popular in the industry. If it catches on with a few well funded tech companies, then it’s easy to get $10k or so from each one in sponsorships at conferences.
...is Gentoo large and influential these days? As far as I'm aware, its current cultural status is that of a punchline, but I'm open to being corrected.
Gentoo is often at the forefront of identifying and helping resolve integration issues between different software projects, particularly when it comes to compiler tech (e.g. fixing packages so they can be built properly with LTO, or with LLVM as well as GCC) or other backend-detail-minutia which makes the whole system better without always being visible to the end user.
Thanks for posting this! It's been a nice first year as a Gentoo developer. Everyone has been kind and helpful to me as I've been figuring things out.
I want to highlight something: Gentoo's developer onboarding system is EXCELLENT. Starting as an active member of the general community, you talk an existing developer into being your mentor and fill out an open book test ( https://projects.gentoo.org/comrel/recruiters/quizzes/ebuild... ) which later is graded/corrected in a couple of meetings which I'd equate to the "job interview". I wish more open source projects (including my own) had such well-documented, straightforward processes to gain commit access. I appreciated the process of doing the quiz as it helped me close gaps in my knowledge.
2025 I switched to nixos and will probably stay. I used gentoo for like 20 years. Its the distro of my heart.
With some notebooks, some of which were getting on in years, it was simply too resource-intensive to update. Only GHC, for example, often took 12+ hours to compile on some older notebooks.
I tried to list available packages on NixOS and nix-env consumed more than 6 GB Ram. Everyone told me not to use nix-env; everyone except NixOS manual. Trying to understand NixOS environment is a deep rabbit hole.
The Nix documentation is what drove me away from it years ago when I tried. I ended up landing on GNU Guix, where I have been for about 5 years now. I found the OS documentation to be much nicer (info pages!) and the decades of Scheme documentation makes the language easier to pick up too.
Yeah, it's in a weird state of officially being stuck to legacy channels/profiles and unofficially having moved to flakes. Excessive RAM usage with nix-env, which theoretically can be improved but requires deep design changes, was what driven me to flakes.
I used Gentoo for ten years (2005–2015), and I was very happy with it! Stable was not the word I would use, in that updating frequently broke and required manual intervention. But it was so flexible! The easily accessible options one has for choosing everything about the system is unparalleled in any system I have tried since. I would still use it if I had more tinkering time. These days I am on NixOS, mostly to have the same setup on every machine I use.
What Gentoo really needs is an official immutability mechanism like ostree used by Fedora Silverblue or ZFS/btrfs snapshots of the root/boot volumes. This way the ever-experimental nature of the distro would be compensated by having an easy mechanism to rollback to previous known-good builds.
Hah, same! NixOS is perfect for me; I love the declarative aspect. But Portage is far-and-away the best traditional package manager I've ever used. It's truly phenomenal.
I think Gentoo is very stable, but you have to make use of revdep-rebuild and know what you are doing (meaning: it is easy to shoot yourself in the foot).
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-nspawn containers for the different microarchitectures and mount their /var/cache/binpkgs and /etc/portage dirs over NFS on the target machines. The Thinkpad can now do an empty tree emerge in like an hour and leaving out the bdeps cuts down on about 150 packages.
Despite being focused on OpenRC, I have had the most pleasant experience with systemd on Gentoo over all the other distros I've tried.
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.
Readit News
That said, I haven't tried Gentoo with binaries from official repositories yet. Maybe that makes it less time-consuming to keep your system up to date.
The example project uses Alpine base container images, but I'm using a Debian base container for something else I'm working on.
I have had Gentoo in at least one nearby system (physical and/or VM) since about 15 years ago. It's always a blast interacting with it.
It's still 100% pure Gentoo (and actually these days even vanilla Gentoo itself offers precompiled binaries) so you still can compile things in rare cases that binary isn't already compiled with use/config that you want.
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 only scalable way to handle the explosion of hardware diversity we are seeing post 2025. If you are building an embedded platfrm or working on custom silicon, Gentoo is a top tier choice. You cross-compile the stage1 and portage handles the rest.
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 can speak for yocto being completely built from source and has a huge variety of BSPs, usually vendor-created.
Other distros don't support Risc-V because nobody has taken the time to bother with it because the hardware base is almost nonexistent.
It's crazy how projects this large and influential can get by on so little cash. Of course a lot of people are donating their very valuable labour to the project, but the ROI from Gentoo is incredible compared to what it costs to do anything in commercial software.
Back in the day when the boxes were on display in brick-and-mortar stores, SuSE was a great way to get up and running with Linux.
It is the Microsoft of the Linux world.
Gentoo also runs the backend infra of Sony's Playstation Cloud gaming service
Anecdotal evidence claims it used to also run the NASDAq
I want to highlight something: Gentoo's developer onboarding system is EXCELLENT. Starting as an active member of the general community, you talk an existing developer into being your mentor and fill out an open book test ( https://projects.gentoo.org/comrel/recruiters/quizzes/ebuild... ) which later is graded/corrected in a couple of meetings which I'd equate to the "job interview". I wish more open source projects (including my own) had such well-documented, straightforward processes to gain commit access. I appreciated the process of doing the quiz as it helped me close gaps in my knowledge.
With some notebooks, some of which were getting on in years, it was simply too resource-intensive to update. Only GHC, for example, often took 12+ hours to compile on some older notebooks.
Deleted Comment
[0] https://www.pcworld.com/article/481872/how_linux_mastered_wa...
I will say though that my valgrind is broken due to march native. :)
Deleted Comment
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-nspawn containers for the different microarchitectures and mount their /var/cache/binpkgs and /etc/portage dirs over NFS on the target machines. The Thinkpad can now do an empty tree emerge in like an hour and leaving out the bdeps cuts down on about 150 packages.
Despite being focused on OpenRC, I have had the most pleasant experience with systemd on Gentoo over all the other distros I've tried.
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
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