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
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.
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.
> 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.
They absolutely are! I actually originally just wanted a base container image for running services on my hosts that a.) I could produce a full source code listing for and b.) have full visibility over the BoM, and realized I could just ‘FROM scratch’ & pull in gentoo’s stage3 to basically achieve that. That also happens to be the first thing you do in a new gentoo chroot, and I realized that pretty much every step in the gentoo install media that you run after (installing software, building the kernel, setting up users, etc) could also be run in the container. What are containers if not “portable executable chroots” after all? My first version of this build system was literally to then copy / on the container to a mounted disk I manually formatted. Writing to disk is actually the most unnatural part of this whole setup since no one really has a good solution for doing this without using the kernel; I used to format and mount devices directly in a privileged container but now I just boot a qemu VM in an unprivileged container and do it in an initramfs since I was already building those manually too. I found while iterating on this that all of the advantages you get from Containerfiles (portability, repeatability, caching, minimal host runtime, etc) naturally translated over to the OS builder project, and since I like deploying services as containers anyways there’s a high degree of reuse going on vs needing separate tools and paradigms everywhere.
I’ll definitely write it up and post it to HN at some point, trying to compact the whole project in just that blurb felt painful.
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.
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.
> The ability to say "I do not want LDAP support in my mail client" and have the package manager actually respect that is cool.
I tried Gentoo around the time that OP started using it, and I also really liked that aspect of it. Most package managers really struggle with this, and when there is configuration, the default is usually "all features enabled". So, when you want to install, say, ffmpeg on Debian, it pulls in a tree of over 250 (!!) dependency packages. Even if you just wanted to use it once to convert a .mp4 container into .mkv.
I also liked the idea when I used Gentoo 15 years ago but you quickly realise it doesn't make much sense.
You are trading off having a system able to handle everything you will throw at it, and having the same binaries as everyone else for, well, basically nothing. You have a supposedly smaller exploitable surface but you have to trust that the Gentoo patches cutting these things out don't introduce new vulnerabilities and don't inadvertently shut off hardening features. You have slightly smaller packages but I'm hard pressed to think of a scenario where it would matter in 2026.
To me, the worst debuggability and the inability to properly communicate with the source project make it a bad idea. I find Arch's pledge to only ship strictly vanilla software much more sensible.
> 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 _really_ stable, and unstable is still mostly usable without major hiccups. My maintenance burden is limited nowadays compared to 10y ago - pretty much running `emerge -uDN @world --quiet --keep-going` and fixing issues if any, maybe once a month I get package failures but I run a llvm+libcxx system and also package tests, so likely I get more issues than the average user on GCC.
For me these days it's not about the speed anymore of course, but really the customization options and the ability to build pretty much anything I need locally. I also really like the fact that ebuilds are basically bash scripts, and if I need to further customize or reproduce something I can literally copy-paste commands from the package manager in my local folder.
The project has successfully implemented a lot of by-default optimizations and best practices, and in general I feel the codebases for system packages have matured to the point where it's odd to run in internal compiler errors, weird dependency issues, whole-world rebuilds etc. From my point of view it also helped a lot that many compilers begun enforcing more modern and stricter C/C++ standards over time, and at the same time we got Github, CI workflows, better testing tools etc.
I run `emerge -e1 @world` maybe once a year just to shake out stuff lurking in the shadows (like stuff compiled with clang 19 vs clang 21), but it's really normally not needed anymore. The configuration stays pretty much untouched unless I want to enable a new USE for a new package I'm installing.
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:
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.
gcc 3.3 to 3.4 was a big thing, and could cause some issues if people didnt follow the upgrade procedures, and also many c++ codebases would need minor adjustments.. this has been much much less of a problem since.
Additionally gentoo has become way more strict with use flag dependencies, and it also checks if binaries are depending on old libs, and doesnt remove them when updating a package, such that the "app depends on old libstdc++" doesnt happen anymore. It then automatically removes the old when nothing needs it anymore
I have been running gentoo since before 04, continously, and things pretty much just work. I would be willing to put money that I spend less time "managing my OS" than most who run other systems such as osx, windows, debian etc. Sure, my cpu gets to compile a lot, but thats about it.
And yes, the "--omg-optimize" was never really the selling point, but rather the useflags, where theres complete control. Pretty much nothing else comes close, and it is why gentoo is awesome
I'd say "the fastest" is a side effect of "allowing one to tune their systems to their utmost liking." -march=native, throw away unused bits and pieces, integrate modules into the kernel, replace bits and pieces with faster -- if more limited -- bits and pieces. And so on.
To be fair it was not that difficult to set create a pure 64 bit binary distro and there were a few of them. The real issue was to figure out how to do mixed 32/64 bit and this is where the fight about /lib directories originated. In a pure 64 bit distro the only way to run 32 bit binaries was to create a chroot with a full 32 bit installation. It took a while before better solutions were agreed to. This was an era of Flash and Acrobat Reader - all proprietary and all 32 bit only so people really cared about 32 bit.
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.
Red Hat contributes to a broad spectrum of Linux packages, drivers, and of course the kernel itself [1].
One example is virtualization: the virtio stack is maintained by Red Hat (afaik). This is a huge driver behind the “democratization” of virtualization in general, allowing users and small companies to access performant virt without selling a kidney to VMware.
Also, Red Hat contributes to or maintains all of the components involved in OpenShift and OpenStack (one of which is virtio!).
Why should Red Hat be expected to contribute to Gentoo? A distro is funded by its own users. What distro directly contributes to another distro if it’s not a derivative or something?
Red Hat primarily contributes code to the kernel and various OSS projects, paid for by the clients on enterprise contracts. A paying client needs something and it gets done. Then the rest of us get to benefit by receiving the code for free. It’s a beautiful model.
If you look at lists of top contributors, Red Hat (along with the usual suspects in enterprise) are consistently at the top.
As others mentioned, Red Hat (and SUSE) has been amazing for the overall Linux community. They give back far more than what the GPL requires them to. Nearly every one of their paid "enterprise" products has a completely free and open source version.
For example:
- Red Hat Identity Management -> FreeIPA (i.e. Active Directory for Linux)
- Red Hat Satellite -> The Foreman + Katello
- Ansible ... Ansible.
- Red Hat OpenShift -> OKD
- And more I'm not going to list.
Okd was a mess when i tried to use it years ago. The documentation was just a 1:1 copy-paste of openshift docs despite significant differences in installation. It really wanted you to use OLM but the upstream operators like maestra (the istio based upstream of redhat service mesh) were often very out of date in the catalog to the point of being incompatible with the current version of okd. I raised the issue on GitHub and a redhat employee replied that they were not happy with the situation at the time but to keep asking to show there was interest. I switched to talos instead for a more vanilla k8s where i could actually get a service mesh installed.
Not really comparable to the experiences i have running keycloak where the upstream documentation is complete or freeipa where it’s identical to idm and you can just use the redhat docs. Those are both excellent pieces of software we are lucky to have.
It looks like they're second to Intel, at least by LF's metric. That said driver code tends to be take up a lot of space compared to other areas. Just look at the mass of AMD template garbage here: https://github.com/torvalds/linux/tree/master/drivers/gpu/dr...
Intel has long been a big contributor--mostly driver stuff as I understand it. (Intel does a lot more software work than most people realize.) Samsung was pretty high on the list at one point as well. My grad school roommate (now mostly retired though he keeps his hand in) was in the top 10 individual list at one point--mostly for networking-related stuff.
SuSE/openSuSE is innovating plenty of stuff which other distros find it worth to immitate, e.g. CachyOS and omarchy as Arch-derivatives felt that openSuSE-style btrfs snapshots were pretty cool.
It's a rock-solid distro, and if I had a use for enterprise support, I'd probably look into SLES as a pretty serious contender.
The breadth of what they're doing seems unparalleled, i.e. they have rolling release (Tumbleweed), delayed rolling release (Slowroll) which is pretty unique in and of itself, point release (Leap), and then both Tumbleweed and Leap are available in immutable form as well (MicroOS, and Leap Micro respectively), and all of the aforementioned with a broad choice of desktops or as server-focused minimal environments with an impressively small footprint without making unreasonable tradeoffs. ...if you multiply out all of those choices it gives you, it turns into quite a hairy ball of combinatorics, but they're doing a decent job supporting it all.
As far as graphical tools for system administration go, YaST is one of the most powerful and they are currently investing in properly replacing it, now that its 20-year history makes for an out-of-date appearance. I tried their new Agama installer just today, and was very pleased with the direction they're taking.
...so, not quite sure what you're getting at with your "Back in the day..." I, too, remember the days of going to a brick-and-mortar store to buy Linux as a box set, and it was between RedHat and SuSE. Since then, I think they've lost mindshare because other options became numerous and turned up the loudness, but I think they've been quiety doing a pretty decent job all this time and are still beloved by those who care to pay attention.
SUSE has a lot of ex-Red Hatters at high levels these days. Their CEO ran Asia-Pacific for a long time and North America commercial sales for a shorter period.
SUSE has always been pretty big in Europe but never was that prominent in North America except for IBM mainframes, which Red Hat chipped away at over time. (For a period, SUSE supported some mainframe features that Red Hat didn't--probably in part because some Red Hat engineering leadership was at least privately dismissive of the whole idea of running Linux on mainframes.)
I'm sorry but this is just completely disconnected from reality. Wayland is being successfully used every single day. Just because you don't like something doesn't mean it's inherently bad.
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.
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.
Maybe. The background of my comment: in the end of 90's I worked in a company doing professional audio in windows. We had multiple cards, with multiple inputs and outputs, different sampling frequencies, channels, bits per sample... The API was trivial. I learned it in 1 hour.
FF to last year, I was working with OpenGL (in linux), I thought "I will add sound" boy... I was smashed by the zoo of APIs, subsystems one on top of another, lousy documentation... Audio, which for me was WAY easier as video, suddenly was way more complicated. From the userland POV, last year I also wanted to make a kind of BT speaker with a raspeberry pi, and also was terrible experience.
So, I don't know... maybe I should give a try to pipewire, at the time I was done after fighting with alsa and pulseaudio, the first problem I killed it.
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.
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 exactly is it that they’re doing to the Linux desktop that make it so that people can’t fix their own problems? Isn’t the whole selling point of Rocky and Alma by most integrators is that it’s so easy you don’t need red hat to support it?
I think it's fair to say that Red Hat simply doesn't care about the desktop--at least beyond internal systems. You could argue the Fedora folks do to some degree but it's just not a priority and really isn't something that matters from a business perspective at all.
Can you name a company which does care about the linux desktop? Over the years i’m pretty sure redhat contributed a great deal to various desktop projects, can’t think of anyone who contributed more.
Well Red Hat did make a go at a supported enterprise desktop distro for a time and, as I wrote, Fedora--which Red Hat supports in a variety of ways for various purposes--is pretty much my default Linux distro.
So I'm not being critical. Yes, Red Hat employees do contribute to projects that are most relevant to the desktop even if doing so is not generally really the focus of their day jobs. And, no, other companies almost certainly haven't done more.
Certainly, Ubuntu used to be friendlier to new would-be Linux desktop users for a variety of reasons. (And we could get into some controversial decisions/directions it's taken but I won't.) I'm sure lots of people still run Ubuntu although Canonical is less prominent these days. My impression is that Canonical was sort of a passion project of Mark Shuttleworth's and they're just a lot lower key at this point.
It's not just systemd, though. You have to look at the whole picture, like the design of GNOME or how GTK is now basically a GNOMEy toolkit only (and if you dare point this out on reddit, ebassi may go ballistics). They kind of take more and more control over the ecosystem and singularize it for their own control. This is also why I see the "wayland is the future", in part, as means to leverage away even more control; the situation is not the same, as xorg-server is indeed mostly just in maintenance work by a few heroes such as Alanc, but wayland is primarily, IMO, a IBM Red Hat project. Lo and behold, GNOME was the first to mandate wayland and abandon xorg, just as it was the first to slap down systemd into the ecosystem too.
The usual semi conspiratorial nonsense. GNOME is only unusable to clickers that are uncomfortable with any UI other than what was perfected by windows 95. And Wayland? Really? Still yelling at that cloud?
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.
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.
These days Wayland is MUCH smoother than X11 even with an Nvidia graphics cards. With X11, I occasionally had tearing issues or other weird behavior. Wayland fixed all of that on my gaming PC.
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-of-tools-someone-made approach to system design, which of course also has upsides. Redhat seems to be really helping with amplifying the downsides by providing the money to make a few mediocre tools absurdly big tho.
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.
NixOS let you build the abstraction you want, and mix them with abstractions provided by others, and this single line illustrates this point extremely well as `sops` is not yet part of NixOS.
Other package managers also provide some abstraction over the packages, and would likely see the same systemd configuration abstracted the same way in post-install scripts. Yet, the encrypted file for `rclone.conf` would come as a static path in `/etc`.
You could resume NixOS as having moved the post-install script logic before the installation, yet this tiny detail gives you additional abilities to mix the post-install scripts and assert consistency ahead of making changes to the system.
Hah I just wrote something similar today to periodically push backups to another server from my NAS.
I agree the systemd interface is rather simple (just translate nix expression to config file).
But NixOS is a behemoth; Completely change the way how every package is built, introduce a functional programming language and filesystem standard to somehow merge everything together, and then declare approximately every package to ever exist in this new language + add a boatloat of extra utilities and infra.
I was referring to working with systemd specifically on NixOS. But yes, the Nix ecosystem is not easy to learn, but once it clicks there is no going back.
Not easy to learn is a bit of a red herring imo. Its also a disproportionate amount of stuff to hold in your head once you have learned it for what it is.
An OS is first of all is a set of primitives to accomplish other things. What classic worse-is-better Unix does really well is do just enough to make you able to get on with whatever those things are. Write some C program to gather some simulation data, pipe its output to awk or gnuplot to slice it. Maybe automate some of that workflow with a script or two.
Current tools can do a bit more and can do it nicer or more rigorously sometimes, but you loose the brutal simplicity of a bunch of tools all communicating with the same conventions and interfaces. Instead you get a bunch of big systems all with their own conventions and poor interop. You've got Systemd and the other Redhat-isms with their custom formats and bad CLI interfaces. You've got every programming language with it's own n package managers.
A bunch of useful stuff sure, but encased in a bunch of reinvented infrastructure and conventions.
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.
Seconded! I really liked Nix, but found the language and some of the tooling inscrutable. With (non)Guix I got all the Nix goodness, but in a form I understood much better. If Guix wasn't so good I'd be on Gentoo or Arch.
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.
Gentoo has many smart people. Having said that, I can't help but feel that ever since the rise of Arch, Gentoo lost a lot of grounds. This may not be primarily due to Arch, but it kind of felt that way to me. I feel that the Gentoo devs should really look at its main competitors such as Void or Arch, IMO. These seem to be more like a modern Gentoo, even if they are different and have a different focus too.
Neither Void or Arch are a "modern Gentoo". Gentoo is it's own thing. If anything, Gentoo's closest "competitors" in terms of OS customisation would be NixOS or Guix, not Void or Arch, but Gentoo is forging it's own path, it doesn't need to follow any other distro.
Arch is the reason I didn't choose Gentoo for my latest build. It's convenient and "good enough" for all my use-cases. Gentoo gives you the feeling of being fully connected to the computer like no other OS - the kind that leaves you nostalgic - but it also requires a time commitment.
I used Gentoo from 2006 for a decade or more and loved it. Later I got more into embedded systems and low compute hardware and flirted with other distros. Gentoo is still running on my server but desktop and notebook are now on more conventional distros.
I used to run gentoo like 14 years ago! It remains one of the fastest distros I've seen for the specific hardware it was running on (high core count 4-socket AMD opteron servers) and I mostly attributed that to the fact it was compiling everything (even the base os in this case!) for that specific CPU at install time... emerge would build/compile and if you set your USE flags correctly it produced heavily tailored and optimized binaries. I feel like a staged/graduated (downloading/running precompiled initially while a flag-optimized compile runs in the background) would be a good way to get around some of the downsides here (namely that it takes 45 minutes to install firefox with emerge/pacman and that builds fail more often than packages fail to install).
Very cool to see that it's still going strong - I remember managing many machines at scale was a bit of a challenge, especially keeping ahead of vulnerabilities.
Reading this while doing emerge @world on my personal workstation, and preparing a fresh annual portage cut for our IT infrastructure (some 600+ VMs, 400+ bare metal servers), running Gentoo.
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. :)
I used Gentoo back in 2003. It’s nice to see that it’s still going strong. I don’t have as much free time now it’s not the distro for me, but perhaps when I retire I will come back to it.
Impressive recap! The work on RISC-V images, Gentoo for WSL, and EAPI 9 really shows how adaptable Gentoo is.
I’m curious about the trend of fewer commits and bug reports—do you think it’s just natural stabilization, or are contributors slowing down? Also, the move from GitHub to Codeberg is bold; how is the community reacting to that change so far?
Would love to hear more about how new contributors are finding the transition and onboarding with these updates.
I haven't used it in years, but when I was first using Linux I used Gentoo for a long time. Building Gentoo from scratch really helped me learn a lot and probably more quickly than dual-booting a system like I had been. I'll always have a soft spot for Gentoo.
I have not directly used Gentoo in years. It was chosen so I could learn, maximize system performance, and have proper AMD64 support before the other distros supported the new CPU specs. Gentoo also had the best documentation in those years.
Id Software provided a Doom 3 Linux client when the game was first released. I found Doom 3 ran better on a custom built Gentoo Linux system compared to Windows XP.
Are you look at Gentoo to maximize performance with compiling everything with custom build parameters and kernel configuration versus pre-built binaries and a generic kernel loaded with modules?
Custom Gentoo just adds more time with having to wait to install software upgrades. It is like having all your Arch packages only being provided by AUR. There is also a chance the build will fail and the parameters might need to be changed. Majority of the time everything compiles without issue once the build parameters are figured out. It was rare when something did not.
Tecnically with just a kernel optimized for your CPU, realtime patches, NTSync and a custom MESA build (with -O2 and -march set to your CPU) would give a good boost instead of trying to recompile verything.
General administration is similar to Arch or any other regular distro. Package updates necessarily take longer because of recompiling but that's just CPU time. There are precompiled versions of big popular binaries (open office, Firefox, etc) that allow you to save a lot of time if you want.
Where you lose time is in trying to optimize your system and packages using the multiple switches that Gentoo provides. If you're the OCD twiddler type, Gentoo can be both extremely satisfying and major time sink.
I don't understand the time sink. Isn't spending time knowing intricate details about your system a good thing? You know better than most if you've gone that deep.
It's good for learning for sure but It's very easy to go too deep and spend time on pointless optimizations and customization instead of doing actual work.
In my experience (this was about 5 years ago mind you) it was no more complex than an arch installation, but with a smaller community and less documentation.
TLDR: Installation is a pain, initial configuration is a pain and there's always something more to tweak, update is a lesser pain, but still a pain. But it's fun, BDSM-style...
Installation is done by booting a liveCD, manually partitioning your storage, unpacking a Gentoo STAGE3 archive, chrooting in it, doing basic configuration such as network, timezone, portage (package manager) base profile and servers, etc., compiling and installing a kernel and then rebooting into the new system.
Then you get to play with /etc/portage/make.conf which is the root configuration of the package manager. You get to set CPU instruction sets (CPU_FLAGS), gcc CFLAGS flags, MAKE flags, video card targets, acceptable package licenses, global USE flags (those are simplified ./configure arguments that usually apply to several packages), which Apache modules get built, which qemu targets get built, etc. These are all env vars that portage (the package manager) uses to build packages for your system.
The more you use Gentoo, the more features of make.conf you discover. Never ending fun.
Then, you start installing packages and updates (same procedure):
1) You start the update by reviewing USE flags for each added/updated package - several screens of dense text.
For example, PHP has these USE flags: https://packages.gentoo.org/packages/dev-lang/php - mouse hover to see what they do. You get to play with them in /etc/portage/package.use and there's no end to tweaking them.
If you have any form of OCD, stay away from Gentoo or this will be your poison forever!
2) Then the compilation begins and that takes hours or days depending on what you install and uses a lot of CPU and either storage I/O or memory (if you have lots of memory, you can compile in a tmpfs a lot faster).
I'm not sure it is OK to compile the updates on a live server, especially during busy hours, but Gentoo has alternatives, including binary packages (recently added, but must match your USE flags with theirs), building packages remotely on another system (distcc), even on a different arch (crossdev). You could run an ARM server and build packages for it on a x86 workstation. I didn't use "steve", so I can't tell you what wonderful things that tool can do, yet.
3) Depending on architecture, some less used packages may fail to compile. You get to manually debug that and submit bug reports. You can also add patches to /etc/portage/patches/<package> that will automatically be applied when the package is built, and that includes the kernel.
I recommend you to run emerge with --keep-going to have the package manager continue after an error with the remaining packages.
4) When each package is done compiling, it's installed automatically. There are no automatic reboots or anything. The files are replaced live, both executables and libraries. Running services continue to use old files from memory until you restart them or reboot manually - they will appear red/yellow in htop until you do.
There were a few times, very very few, when I had crashes in new packages that were succesfuly built. It only happened on armv7, which is a practically abandoned platform everywhere. In those cases you can revert to the old ones and mask the bugged version to prevent it from being updated to next time.
5) Last step is to review the config changes. dispatch-conf will present a diff of all proposed changes to .ini and .cfg files for all updated packages. You get to review, accept, reject the changes or manually edit the files.
With Red Hat, Anaconda is the installer.
With Ubuntu, ubiquity.
etc ...
With Gentoo -- YOU are the installer. This means you have to be ready to perform -- more or less manually -- many of the tasks automated in other distributions. I sorta see this as the same as a tutorial level in a video game: you learn how to read and follow the wiki which is essentially the key to success in Gentoo.
And it's literally yes, yes, next, next - the defaults are pretty good.
1) Calculate Linux is 100% Gentoo with more profiles (e.g. server, desktop-kde, desktop-gnome ...etc) and after switching from vanilla Gentoo to Calculate - I didn't need to tweak any use flags of any packages.
Profiles are so good that everything works nicely together
2) There are prebuild binaries for your profile use-flag combo - can't recall last time I had to wait for something to compile
3) Much less likely to happen since you get binaries for everything - but there's additional cl-xxx tooling that makes even that easier
4) I don't think that's a bad thing. Though sure I could agree that having option to automatically restart services would be nice.
5) Yes - and you can also archive and basically have git-log on conf changes.
> Calculate Linux is 100% Gentoo with more profiles (e.g. server, desktop-kde, desktop-gnome ...etc) and after switching from vanilla Gentoo to Calculate - I didn't need to tweak any use flags of any packages.
If that's your thing, sure. I find even Gentoo too automated for my preferences. I'm using the most basic from the available profiles and tweak everything manually in package.use. I stopped using openrc and switched to just sysvinit/inittab.
But then, if you want binary packages and such, why use Gentoo or a fork?
I used to use Gentoo, it helped me learn Linux and I loved it. Waiting for things to compile took a while, but I learned about distcc and set up another machine to help the compiling! I don't use Gentoo anymore, since I don't really have the time anymore to deal with it - like having to fix compile issues - but it did feel really cool to have my system custom-tuned just for me.
"Mostly because of the continuous attempts to force Copilot usage for our repositories, Gentoo currently considers and plans the migration of our repository mirrors and pull request contributions to Codeberg."
I saw a comment in a "I moved from Windows to Linux" thread implying Windows has more configuration potential than Linux. I wonder what that commenter would make of Gentoo.
I wish I had more time I could dedicate to maintaining my system, I'm marooned on Arch due to lack of time, such a shame.
It’s so crazy to me that there are languages whose maintainers don’t make it absolute #1 priority to always have a clean golden path for bootstrapping.
As a kid 25+ years ago, it was fun tweaking use flags, compiling with Intel cc, diving into every menu in that blue kernel configuration screen. System recompiles I think took 4 hours back then. Learned so much back then and it can even be useful to this day, I don't think I'd even know what a glibc is without tweaking out it's use flags just for kicks.
Now I am happily gaming on arch Linux and while generally developing on a Mac, need to jump into debian in docker and such. But I do hope kids these days end up trying Gentoo, the hacker skillset it builds is priceless. No offense to adults still using it! I just hope there aren't as many "my system doesn't build anymore" situations as I remember.
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
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.
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.
> 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.
They absolutely are! I actually originally just wanted a base container image for running services on my hosts that a.) I could produce a full source code listing for and b.) have full visibility over the BoM, and realized I could just ‘FROM scratch’ & pull in gentoo’s stage3 to basically achieve that. That also happens to be the first thing you do in a new gentoo chroot, and I realized that pretty much every step in the gentoo install media that you run after (installing software, building the kernel, setting up users, etc) could also be run in the container. What are containers if not “portable executable chroots” after all? My first version of this build system was literally to then copy / on the container to a mounted disk I manually formatted. Writing to disk is actually the most unnatural part of this whole setup since no one really has a good solution for doing this without using the kernel; I used to format and mount devices directly in a privileged container but now I just boot a qemu VM in an unprivileged container and do it in an initramfs since I was already building those manually too. I found while iterating on this that all of the advantages you get from Containerfiles (portability, repeatability, caching, minimal host runtime, etc) naturally translated over to the OS builder project, and since I like deploying services as containers anyways there’s a high degree of reuse going on vs needing separate tools and paradigms everywhere.
I’ll definitely write it up and post it to HN at some point, trying to compact the whole project in just that blurb felt painful.
Thanks for sharing! Definitely interested in reading further about the project.
I would also be very interested in reading that blog post!
same here! very interesting :)
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.
After driving Gentoo for a while back in 2004, I decided I don't really want to wait compiling for everything.
For those that don't want to wait compiling for everything - https://www.calculate-linux.org/
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.
> The ability to say "I do not want LDAP support in my mail client" and have the package manager actually respect that is cool.
I tried Gentoo around the time that OP started using it, and I also really liked that aspect of it. Most package managers really struggle with this, and when there is configuration, the default is usually "all features enabled". So, when you want to install, say, ffmpeg on Debian, it pulls in a tree of over 250 (!!) dependency packages. Even if you just wanted to use it once to convert a .mp4 container into .mkv.
I also liked the idea when I used Gentoo 15 years ago but you quickly realise it doesn't make much sense.
You are trading off having a system able to handle everything you will throw at it, and having the same binaries as everyone else for, well, basically nothing. You have a supposedly smaller exploitable surface but you have to trust that the Gentoo patches cutting these things out don't introduce new vulnerabilities and don't inadvertently shut off hardening features. You have slightly smaller packages but I'm hard pressed to think of a scenario where it would matter in 2026.
To me, the worst debuggability and the inability to properly communicate with the source project make it a bad idea. I find Arch's pledge to only ship strictly vanilla software much more sensible.
> 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 _really_ stable, and unstable is still mostly usable without major hiccups. My maintenance burden is limited nowadays compared to 10y ago - pretty much running `emerge -uDN @world --quiet --keep-going` and fixing issues if any, maybe once a month I get package failures but I run a llvm+libcxx system and also package tests, so likely I get more issues than the average user on GCC.
For me these days it's not about the speed anymore of course, but really the customization options and the ability to build pretty much anything I need locally. I also really like the fact that ebuilds are basically bash scripts, and if I need to further customize or reproduce something I can literally copy-paste commands from the package manager in my local folder.
The project has successfully implemented a lot of by-default optimizations and best practices, and in general I feel the codebases for system packages have matured to the point where it's odd to run in internal compiler errors, weird dependency issues, whole-world rebuilds etc. From my point of view it also helped a lot that many compilers begun enforcing more modern and stricter C/C++ standards over time, and at the same time we got Github, CI workflows, better testing tools etc.
I run `emerge -e1 @world` maybe once a year just to shake out stuff lurking in the shadows (like stuff compiled with clang 19 vs clang 21), but it's really normally not needed anymore. The configuration stays pretty much untouched unless I want to enable a new USE for a new package I'm installing.
> so likely I get more issues than the average user on GCC.
its been years since I had a build failure, and I even accept several on ~amd64. (with gcc)
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:
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. /sI 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.
gcc 3.3 to 3.4 was a big thing, and could cause some issues if people didnt follow the upgrade procedures, and also many c++ codebases would need minor adjustments.. this has been much much less of a problem since.
Additionally gentoo has become way more strict with use flag dependencies, and it also checks if binaries are depending on old libs, and doesnt remove them when updating a package, such that the "app depends on old libstdc++" doesnt happen anymore. It then automatically removes the old when nothing needs it anymore
I have been running gentoo since before 04, continously, and things pretty much just work. I would be willing to put money that I spend less time "managing my OS" than most who run other systems such as osx, windows, debian etc. Sure, my cpu gets to compile a lot, but thats about it.
And yes, the "--omg-optimize" was never really the selling point, but rather the useflags, where theres complete control. Pretty much nothing else comes close, and it is why gentoo is awesome
True words.
I'd say "the fastest" is a side effect of "allowing one to tune their systems to their utmost liking." -march=native, throw away unused bits and pieces, integrate modules into the kernel, replace bits and pieces with faster -- if more limited -- bits and pieces. And so on.
To be fair it was not that difficult to set create a pure 64 bit binary distro and there were a few of them. The real issue was to figure out how to do mixed 32/64 bit and this is where the fight about /lib directories originated. In a pure 64 bit distro the only way to run 32 bit binaries was to create a chroot with a full 32 bit installation. It took a while before better solutions were agreed to. This was an era of Flash and Acrobat Reader - all proprietary and all 32 bit only so people really cared about 32 bit.
Embedded usually uses yocto or buildroot or whatever it’s called. Never seen anyone use gentoo.
I can speak for yocto being completely built from source and has a huge variety of BSPs, usually vendor-created.
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.
Fedora and Debian have been shipping RISC-V versions of stable releases for a while. I don't think anyone is really struggling.
arch is, but arch also has some woes making even amd64_v3/v4 builds, arm64 aside.
> 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.
Contribute back how and where? Definitely not to Gentoo if we look at the meagre numbers here.
Red Hat contributes to a broad spectrum of Linux packages, drivers, and of course the kernel itself [1].
One example is virtualization: the virtio stack is maintained by Red Hat (afaik). This is a huge driver behind the “democratization” of virtualization in general, allowing users and small companies to access performant virt without selling a kidney to VMware.
Also, Red Hat contributes to or maintains all of the components involved in OpenShift and OpenStack (one of which is virtio!).
[1] https://lwn.net/Articles/915435/
Why should Red Hat be expected to contribute to Gentoo? A distro is funded by its own users. What distro directly contributes to another distro if it’s not a derivative or something?
Red Hat primarily contributes code to the kernel and various OSS projects, paid for by the clients on enterprise contracts. A paying client needs something and it gets done. Then the rest of us get to benefit by receiving the code for free. It’s a beautiful model.
If you look at lists of top contributors, Red Hat (along with the usual suspects in enterprise) are consistently at the top.
Presumably, contribute to the entire ecosystem in terms of package maintenance and other non-monetary forms.
As others mentioned, Red Hat (and SUSE) has been amazing for the overall Linux community. They give back far more than what the GPL requires them to. Nearly every one of their paid "enterprise" products has a completely free and open source version.
For example:
Okd was a mess when i tried to use it years ago. The documentation was just a 1:1 copy-paste of openshift docs despite significant differences in installation. It really wanted you to use OLM but the upstream operators like maestra (the istio based upstream of redhat service mesh) were often very out of date in the catalog to the point of being incompatible with the current version of okd. I raised the issue on GitHub and a redhat employee replied that they were not happy with the situation at the time but to keep asking to show there was interest. I switched to talos instead for a more vanilla k8s where i could actually get a service mesh installed.
Not really comparable to the experiences i have running keycloak where the upstream documentation is complete or freeipa where it’s identical to idm and you can just use the redhat docs. Those are both excellent pieces of software we are lucky to have.
Red Hat contributes a huge amount to the open source ecosystem. They're one of the biggest contributors to the Linux kernel (maybe the biggest).
https://insights.linuxfoundation.org/project/korg/contributo...
It looks like they're second to Intel, at least by LF's metric. That said driver code tends to be take up a lot of space compared to other areas. Just look at the mass of AMD template garbage here: https://github.com/torvalds/linux/tree/master/drivers/gpu/dr...
Intel has long been a big contributor--mostly driver stuff as I understand it. (Intel does a lot more software work than most people realize.) Samsung was pretty high on the list at one point as well. My grad school roommate (now mostly retired though he keeps his hand in) was in the top 10 individual list at one point--mostly for networking-related stuff.
They contribute a lot to GNOME, libvirt, firewalld and other linux systems that I take advantage of even as a gentoo user.
Red Hat employs a significant number of GCC core devs.
Yes, that would be nice but when I look at their Grub src.rpm for instance, some of those patches would look original but came from Debian.
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.
The OpenSUSE Tumbleweed installation on my desktop PC is nearing 2 years now and still rolling. It is a great and somewhat underrated distribution.
SuSE/openSuSE is innovating plenty of stuff which other distros find it worth to immitate, e.g. CachyOS and omarchy as Arch-derivatives felt that openSuSE-style btrfs snapshots were pretty cool.
It's a rock-solid distro, and if I had a use for enterprise support, I'd probably look into SLES as a pretty serious contender.
The breadth of what they're doing seems unparalleled, i.e. they have rolling release (Tumbleweed), delayed rolling release (Slowroll) which is pretty unique in and of itself, point release (Leap), and then both Tumbleweed and Leap are available in immutable form as well (MicroOS, and Leap Micro respectively), and all of the aforementioned with a broad choice of desktops or as server-focused minimal environments with an impressively small footprint without making unreasonable tradeoffs. ...if you multiply out all of those choices it gives you, it turns into quite a hairy ball of combinatorics, but they're doing a decent job supporting it all.
As far as graphical tools for system administration go, YaST is one of the most powerful and they are currently investing in properly replacing it, now that its 20-year history makes for an out-of-date appearance. I tried their new Agama installer just today, and was very pleased with the direction they're taking.
...so, not quite sure what you're getting at with your "Back in the day..." I, too, remember the days of going to a brick-and-mortar store to buy Linux as a box set, and it was between RedHat and SuSE. Since then, I think they've lost mindshare because other options became numerous and turned up the loudness, but I think they've been quiety doing a pretty decent job all this time and are still beloved by those who care to pay attention.
SUSE has a lot of ex-Red Hatters at high levels these days. Their CEO ran Asia-Pacific for a long time and North America commercial sales for a shorter period.
SUSE has always been pretty big in Europe but never was that prominent in North America except for IBM mainframes, which Red Hat chipped away at over time. (For a period, SUSE supported some mainframe features that Red Hat didn't--probably in part because some Red Hat engineering leadership was at least privately dismissive of the whole idea of running Linux on mainframes.)
I've found openSUSE MicroOS to be a great homelab server OS.
SuSE slowroll is news to me, thanks.
Red Hat pushing for the disaster that is Wayland has set the Linux Desktop back decades.
It is the Microsoft of the Linux world.
Why is Wayland a disaster? Most of the Linux community is strongly in favor of it.
[flagged]
I'm sorry but this is just completely disconnected from reality. Wayland is being successfully used every single day. Just because you don't like something doesn't mean it's inherently bad.
[dead]
And that's fine! No one cares! Keep using it!
[dead]
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.
It's difficult to infer what kind of nuts is going on here.
If we're going to socialize production, let's do it properly.
> 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.
Pipewire rocks. Wayland it's half baked and a disaster on legacy systems. SystemD... openrc it's good enough, and it never fails at shutdown.
I don’t know where they come from, but I try to avoid all in that list. To be fair, audio is a train wreck anyway.
Eh, pulseaudio got a lot better, and pipewire "just works" at this point (at least for me). Even Bluetooth audio works OOTB most of the time.
Maybe. The background of my comment: in the end of 90's I worked in a company doing professional audio in windows. We had multiple cards, with multiple inputs and outputs, different sampling frequencies, channels, bits per sample... The API was trivial. I learned it in 1 hour.
FF to last year, I was working with OpenGL (in linux), I thought "I will add sound" boy... I was smashed by the zoo of APIs, subsystems one on top of another, lousy documentation... Audio, which for me was WAY easier as video, suddenly was way more complicated. From the userland POV, last year I also wanted to make a kind of BT speaker with a raspeberry pi, and also was terrible experience.
So, I don't know... maybe I should give a try to pipewire, at the time I was done after fighting with alsa and pulseaudio, the first problem I killed it.
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 exactly is it that they’re doing to the Linux desktop that make it so that people can’t fix their own problems? Isn’t the whole selling point of Rocky and Alma by most integrators is that it’s so easy you don’t need red hat to support it?
Just a note: Rocky and Alma came out of CentOS
Of course -- but CentOS' upstream was RHEL, no?
I think it's fair to say that Red Hat simply doesn't care about the desktop--at least beyond internal systems. You could argue the Fedora folks do to some degree but it's just not a priority and really isn't something that matters from a business perspective at all.
Can you name a company which does care about the linux desktop? Over the years i’m pretty sure redhat contributed a great deal to various desktop projects, can’t think of anyone who contributed more.
Well Red Hat did make a go at a supported enterprise desktop distro for a time and, as I wrote, Fedora--which Red Hat supports in a variety of ways for various purposes--is pretty much my default Linux distro.
So I'm not being critical. Yes, Red Hat employees do contribute to projects that are most relevant to the desktop even if doing so is not generally really the focus of their day jobs. And, no, other companies almost certainly haven't done more.
Off the top of my head System76 jumps to mind with their hardware and Pop!_OS.
Canonical. at least they used to, although not a fan of the recent (last ten years) Canonical.
Certainly, Ubuntu used to be friendlier to new would-be Linux desktop users for a variety of reasons. (And we could get into some controversial decisions/directions it's taken but I won't.) I'm sure lots of people still run Ubuntu although Canonical is less prominent these days. My impression is that Canonical was sort of a passion project of Mark Shuttleworth's and they're just a lot lower key at this point.
> Can you name a company which does care about the linux desktop?
To some extent Valve. They have to, since the Steam Deck's desktop experience depends on the "Linux desktop" being a good experience.
Fedora is probably the best out-of-the-box desktop experience. Red Hat does great things, even if the IBM acquisition has screwed things up.
I find systemd pleasant for scheduling and running services but enraging in how much it has taken over every other thing in an IMO subpar way.
It's not just systemd, though. You have to look at the whole picture, like the design of GNOME or how GTK is now basically a GNOMEy toolkit only (and if you dare point this out on reddit, ebassi may go ballistics). They kind of take more and more control over the ecosystem and singularize it for their own control. This is also why I see the "wayland is the future", in part, as means to leverage away even more control; the situation is not the same, as xorg-server is indeed mostly just in maintenance work by a few heroes such as Alanc, but wayland is primarily, IMO, a IBM Red Hat project. Lo and behold, GNOME was the first to mandate wayland and abandon xorg, just as it was the first to slap down systemd into the ecosystem too.
The usual semi conspiratorial nonsense. GNOME is only unusable to clickers that are uncomfortable with any UI other than what was perfected by windows 95. And Wayland? Really? Still yelling at that cloud?
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.
My point was the exact same sentiment applies to X. It lacks things Wayland does. So X is only fine for some people.
These days Wayland is MUCH smoother than X11 even with an Nvidia graphics cards. With X11, I occasionally had tearing issues or other weird behavior. Wayland fixed all of that on my gaming PC.
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-of-tools-someone-made approach to system design, which of course also has upsides. Redhat seems to be really helping with amplifying the downsides by providing the money to make a few mediocre tools absurdly big tho.
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.
In my view, using Nix to define your systemd services beats copying and symlinking files all over the place :)The value brought by NixOS is on line 6.
NixOS let you build the abstraction you want, and mix them with abstractions provided by others, and this single line illustrates this point extremely well as `sops` is not yet part of NixOS.Secret management would likely come in NixOS in the future, but in the mean time you can add either use https://github.com/Mic92/sops-nix or https://github.com/ryantm/agenix to make it possible to manage files which have content that should not be public.
Other package managers also provide some abstraction over the packages, and would likely see the same systemd configuration abstracted the same way in post-install scripts. Yet, the encrypted file for `rclone.conf` would come as a static path in `/etc`.
You could resume NixOS as having moved the post-install script logic before the installation, yet this tiny detail gives you additional abilities to mix the post-install scripts and assert consistency ahead of making changes to the system.
Hah I just wrote something similar today to periodically push backups to another server from my NAS.
I agree the systemd interface is rather simple (just translate nix expression to config file). But NixOS is a behemoth; Completely change the way how every package is built, introduce a functional programming language and filesystem standard to somehow merge everything together, and then declare approximately every package to ever exist in this new language + add a boatloat of extra utilities and infra.
I was referring to working with systemd specifically on NixOS. But yes, the Nix ecosystem is not easy to learn, but once it clicks there is no going back.
Not easy to learn is a bit of a red herring imo. Its also a disproportionate amount of stuff to hold in your head once you have learned it for what it is.
An OS is first of all is a set of primitives to accomplish other things. What classic worse-is-better Unix does really well is do just enough to make you able to get on with whatever those things are. Write some C program to gather some simulation data, pipe its output to awk or gnuplot to slice it. Maybe automate some of that workflow with a script or two.
Current tools can do a bit more and can do it nicer or more rigorously sometimes, but you loose the brutal simplicity of a bunch of tools all communicating with the same conventions and interfaces. Instead you get a bunch of big systems all with their own conventions and poor interop. You've got Systemd and the other Redhat-isms with their custom formats and bad CLI interfaces. You've got every programming language with it's own n package managers. A bunch of useful stuff sure, but encased in a bunch of reinvented infrastructure and conventions.
OTOH, not having money also comes with upsides, like not having overpaid CEOs, managers, marketing people, or distracting side projects.
That’s a 20 million dollar problem, but plenty of projects would be better with a few hundred thousand to pay staff and infra.
Our society at its current state will not allow that, however, as it is seen as more important to do stock buybacks and increasing executive pay.
Yeah, especially when a CSS library makes $1M a year. I guess they have no incentive to improve funding.
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?
What money? Doesn't sound like they have anything extra?
The $104k balance
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.
ChromeOS uses Gentoo as a base. That doesn't seem to have helped get them any Google money.
...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's Portage build system is (or at least was?) part of Google's ChromeOS
Gentoo also runs the backend infra of Sony's Playstation Cloud gaming service
Anecdotal evidence claims it used to also run the NASDAq
Yep. Gaikai.
Highly unlikely that PSN runs Gentoo. They're using AWS.
I've no idea if Sony uses Gentoo or not, but you can definitely run Gentoo on AWS
Not PSN. Sony's Cloud Gaming service. Where they stream an entire PlayStation console to you
OP's statement matches my understanding; parts were gentoo-based at one point.
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.
ChromeOS is based in Gentoo.
Yes, Gentoo is like NixOS, sort of a meta-distribution.
Being the base of ChromeOS makes it highly influential.
ChromeOS market share is >5% in many countries, sometimes around double digits.
Also curious of Gentoo's influence in 2026.
A small amount of money goes a long way when not wasted in DEI programs.
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.
This is a remarkably small number given that Gentoo Portage is load bearing infrastructure under ChromeOS.
And the NASDAQ[0]
[0] https://www.pcworld.com/article/481872/how_linux_mastered_wa...
just typical corporate open source bloodsucking
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.
Seconded! I really liked Nix, but found the language and some of the tooling inscrutable. With (non)Guix I got all the Nix goodness, but in a form I understood much better. If Guix wasn't so good I'd be on Gentoo or Arch.
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.
Would it not be sufficient to use the official binary packages?
They only added the binary packages at the end of 2023.
Really hope I can return to Gentoo soon. It was just the most stable and most hacker friendly distro Ive ever used. Hats off to all the contributors!
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.
[dead]
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).
I've been on Gentoo for my gaming desktop for like 2-3 years now and I don't think I've ever had an update break anything.
I will say though that my valgrind is broken due to march native. :)
If anyone can help adding AVX512 (and other CPU features) support then that would be most welcome. It’s a major task though.
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.
[1] https://wiki.gentoo.org/wiki/Binary_package_guide
I really have loved the binary packages now I can install gentoo on my laptops.
Thanks! A lot for me to learn here
Gentoo has many smart people. Having said that, I can't help but feel that ever since the rise of Arch, Gentoo lost a lot of grounds. This may not be primarily due to Arch, but it kind of felt that way to me. I feel that the Gentoo devs should really look at its main competitors such as Void or Arch, IMO. These seem to be more like a modern Gentoo, even if they are different and have a different focus too.
Neither Void or Arch are a "modern Gentoo". Gentoo is it's own thing. If anything, Gentoo's closest "competitors" in terms of OS customisation would be NixOS or Guix, not Void or Arch, but Gentoo is forging it's own path, it doesn't need to follow any other distro.
Arch is the reason I didn't choose Gentoo for my latest build. It's convenient and "good enough" for all my use-cases. Gentoo gives you the feeling of being fully connected to the computer like no other OS - the kind that leaves you nostalgic - but it also requires a time commitment.
" There is just one branch that all Arch users use"
I have heard rumors that at one point in time gentoo lost its forum - basically a catastrophic strike such as deleting Arch Linux wiki
Not its forum, there was an unofficial wiki that disappeared due to issues with the hoster in 2008. There is an official wiki nowadays.
I used Gentoo from 2006 for a decade or more and loved it. Later I got more into embedded systems and low compute hardware and flirted with other distros. Gentoo is still running on my server but desktop and notebook are now on more conventional distros.
I used to run gentoo like 14 years ago! It remains one of the fastest distros I've seen for the specific hardware it was running on (high core count 4-socket AMD opteron servers) and I mostly attributed that to the fact it was compiling everything (even the base os in this case!) for that specific CPU at install time... emerge would build/compile and if you set your USE flags correctly it produced heavily tailored and optimized binaries. I feel like a staged/graduated (downloading/running precompiled initially while a flag-optimized compile runs in the background) would be a good way to get around some of the downsides here (namely that it takes 45 minutes to install firefox with emerge/pacman and that builds fail more often than packages fail to install).
Very cool to see that it's still going strong - I remember managing many machines at scale was a bit of a challenge, especially keeping ahead of vulnerabilities.
45 minutes hah, it used to take us three days to build kde ;)
Reading this while doing emerge @world on my personal workstation, and preparing a fresh annual portage cut for our IT infrastructure (some 600+ VMs, 400+ bare metal servers), running Gentoo.
All the VMs run Gentoo? That's really interesting, what do they do?
Interesting name for the jobs erver: “steve”
Thanks, steve!
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. :)
I used Gentoo back in 2003. It’s nice to see that it’s still going strong. I don’t have as much free time now it’s not the distro for me, but perhaps when I retire I will come back to it.
Impressive recap! The work on RISC-V images, Gentoo for WSL, and EAPI 9 really shows how adaptable Gentoo is. I’m curious about the trend of fewer commits and bug reports—do you think it’s just natural stabilization, or are contributors slowing down? Also, the move from GitHub to Codeberg is bold; how is the community reacting to that change so far? Would love to hear more about how new contributors are finding the transition and onboarding with these updates.
Been running it for over 20 years:
https://blog.nawaz.org/posts/2023/May/20-years-of-gentoo/
Prior HN discussion: https://news.ycombinator.com/item?id=35989311
Edit: Curious, why the downvote?
I'm more amazed you run the same machine for 20 years. Another 20+ years user, but I've reinstalled 5-6 times when I change laptops.
No, I changed the machine, but just installed Gentoo every time. I merely kept the emerge.logs from each machine.
> why the downvote?
I can see no reason for it.
I haven't used it in years, but when I was first using Linux I used Gentoo for a long time. Building Gentoo from scratch really helped me learn a lot and probably more quickly than dual-booting a system like I had been. I'll always have a soft spot for Gentoo.
Odd this came up as I am considering revisiting Gentoo. I might have to take this as a sign.
Try https://www.calculate-linux.org/ - it's 100% Gentoo, with prebuilt binaries ;)
Doesn't Gentoo itself offer binary installation now?
How easy is it to administer gentoo servers? Is it on-par with nix/arch or harder?
I have not directly used Gentoo in years. It was chosen so I could learn, maximize system performance, and have proper AMD64 support before the other distros supported the new CPU specs. Gentoo also had the best documentation in those years.
Id Software provided a Doom 3 Linux client when the game was first released. I found Doom 3 ran better on a custom built Gentoo Linux system compared to Windows XP.
Are you look at Gentoo to maximize performance with compiling everything with custom build parameters and kernel configuration versus pre-built binaries and a generic kernel loaded with modules?
Custom Gentoo just adds more time with having to wait to install software upgrades. It is like having all your Arch packages only being provided by AUR. There is also a chance the build will fail and the parameters might need to be changed. Majority of the time everything compiles without issue once the build parameters are figured out. It was rare when something did not.
Tecnically with just a kernel optimized for your CPU, realtime patches, NTSync and a custom MESA build (with -O2 and -march set to your CPU) would give a good boost instead of trying to recompile verything.
General administration is similar to Arch or any other regular distro. Package updates necessarily take longer because of recompiling but that's just CPU time. There are precompiled versions of big popular binaries (open office, Firefox, etc) that allow you to save a lot of time if you want.
Where you lose time is in trying to optimize your system and packages using the multiple switches that Gentoo provides. If you're the OCD twiddler type, Gentoo can be both extremely satisfying and major time sink.
I don't understand the time sink. Isn't spending time knowing intricate details about your system a good thing? You know better than most if you've gone that deep.
It's good for learning for sure but It's very easy to go too deep and spend time on pointless optimizations and customization instead of doing actual work.
In my experience (this was about 5 years ago mind you) it was no more complex than an arch installation, but with a smaller community and less documentation.
TLDR: Installation is a pain, initial configuration is a pain and there's always something more to tweak, update is a lesser pain, but still a pain. But it's fun, BDSM-style...
Installation is done by booting a liveCD, manually partitioning your storage, unpacking a Gentoo STAGE3 archive, chrooting in it, doing basic configuration such as network, timezone, portage (package manager) base profile and servers, etc., compiling and installing a kernel and then rebooting into the new system.
Then you get to play with /etc/portage/make.conf which is the root configuration of the package manager. You get to set CPU instruction sets (CPU_FLAGS), gcc CFLAGS flags, MAKE flags, video card targets, acceptable package licenses, global USE flags (those are simplified ./configure arguments that usually apply to several packages), which Apache modules get built, which qemu targets get built, etc. These are all env vars that portage (the package manager) uses to build packages for your system.
The more you use Gentoo, the more features of make.conf you discover. Never ending fun.
Then, you start installing packages and updates (same procedure):
1) You start the update by reviewing USE flags for each added/updated package - several screens of dense text.
For example, PHP has these USE flags: https://packages.gentoo.org/packages/dev-lang/php - mouse hover to see what they do. You get to play with them in /etc/portage/package.use and there's no end to tweaking them.
If you have any form of OCD, stay away from Gentoo or this will be your poison forever!
2) Then the compilation begins and that takes hours or days depending on what you install and uses a lot of CPU and either storage I/O or memory (if you have lots of memory, you can compile in a tmpfs a lot faster).
I'm not sure it is OK to compile the updates on a live server, especially during busy hours, but Gentoo has alternatives, including binary packages (recently added, but must match your USE flags with theirs), building packages remotely on another system (distcc), even on a different arch (crossdev). You could run an ARM server and build packages for it on a x86 workstation. I didn't use "steve", so I can't tell you what wonderful things that tool can do, yet.
3) Depending on architecture, some less used packages may fail to compile. You get to manually debug that and submit bug reports. You can also add patches to /etc/portage/patches/<package> that will automatically be applied when the package is built, and that includes the kernel.
I recommend you to run emerge with --keep-going to have the package manager continue after an error with the remaining packages.
4) When each package is done compiling, it's installed automatically. There are no automatic reboots or anything. The files are replaced live, both executables and libraries. Running services continue to use old files from memory until you restart them or reboot manually - they will appear red/yellow in htop until you do.
There were a few times, very very few, when I had crashes in new packages that were succesfuly built. It only happened on armv7, which is a practically abandoned platform everywhere. In those cases you can revert to the old ones and mask the bugged version to prevent it from being updated to next time.
5) Last step is to review the config changes. dispatch-conf will present a diff of all proposed changes to .ini and .cfg files for all updated packages. You get to review, accept, reject the changes or manually edit the files.
That's all. Simple. :)
That's a very well painted picture for what to expect. I am gonna try it soon, since it's been on my task list for too long. Thanks :)
I always tell people this:
With Red Hat, Anaconda is the installer. With Ubuntu, ubiquity.
etc ...
With Gentoo -- YOU are the installer. This means you have to be ready to perform -- more or less manually -- many of the tasks automated in other distributions. I sorta see this as the same as a tutorial level in a video game: you learn how to read and follow the wiki which is essentially the key to success in Gentoo.
No, I don't agree. That would be Slackware. I guess you never used that one before... It doesn't even do dependency management.
Portage/emerge is very much automated and once you set it up it runs updates with just a confirmation, unless you feel the need to tweak something.
Slackware has no package manager or installer. It's just an extra step removed.
I didn't say Gentoo has no package manager (it does; and it's great!)
Download image from https://www.calculate-linux.org/ - put it on USB flashdrive.
And it's literally yes, yes, next, next - the defaults are pretty good.
1) Calculate Linux is 100% Gentoo with more profiles (e.g. server, desktop-kde, desktop-gnome ...etc) and after switching from vanilla Gentoo to Calculate - I didn't need to tweak any use flags of any packages.
Profiles are so good that everything works nicely together
2) There are prebuild binaries for your profile use-flag combo - can't recall last time I had to wait for something to compile
3) Much less likely to happen since you get binaries for everything - but there's additional cl-xxx tooling that makes even that easier
4) I don't think that's a bad thing. Though sure I could agree that having option to automatically restart services would be nice.
5) Yes - and you can also archive and basically have git-log on conf changes.
> Calculate Linux is 100% Gentoo with more profiles (e.g. server, desktop-kde, desktop-gnome ...etc) and after switching from vanilla Gentoo to Calculate - I didn't need to tweak any use flags of any packages.
If that's your thing, sure. I find even Gentoo too automated for my preferences. I'm using the most basic from the available profiles and tweak everything manually in package.use. I stopped using openrc and switched to just sysvinit/inittab.
But then, if you want binary packages and such, why use Gentoo or a fork?
[dead]
I used to use Gentoo, it helped me learn Linux and I loved it. Waiting for things to compile took a while, but I learned about distcc and set up another machine to help the compiling! I don't use Gentoo anymore, since I don't really have the time anymore to deal with it - like having to fix compile issues - but it did feel really cool to have my system custom-tuned just for me.
(I use Fedora, btw)
"Mostly because of the continuous attempts to force Copilot usage for our repositories, Gentoo currently considers and plans the migration of our repository mirrors and pull request contributions to Codeberg."
I saw a comment in a "I moved from Windows to Linux" thread implying Windows has more configuration potential than Linux. I wonder what that commenter would make of Gentoo.
I wish I had more time I could dedicate to maintaining my system, I'm marooned on Arch due to lack of time, such a shame.
It’s so crazy to me that there are languages whose maintainers don’t make it absolute #1 priority to always have a clean golden path for bootstrapping.
As a kid 25+ years ago, it was fun tweaking use flags, compiling with Intel cc, diving into every menu in that blue kernel configuration screen. System recompiles I think took 4 hours back then. Learned so much back then and it can even be useful to this day, I don't think I'd even know what a glibc is without tweaking out it's use flags just for kicks.
Now I am happily gaming on arch Linux and while generally developing on a Mac, need to jump into debian in docker and such. But I do hope kids these days end up trying Gentoo, the hacker skillset it builds is priceless. No offense to adults still using it! I just hope there aren't as many "my system doesn't build anymore" situations as I remember.
Any more information on the Github move (away)? While the AI features of github are annoying, I've so far been able to completely ignore them.
I still send PR’s for ::gentoo to their github mirror, I would be surprised if they shut this off.
So Google says Bye Bye to Gentoo as ChromOS mutated into AluminumOS??
Amazing project, great people behind it, but it is a time sink.
[dead]
[dead]
[dead]
[dead]
[dead]
[dead]
From the announcement it’s a lot of unnecessary philosophical moves and less innovation moves. I like innovative Linux, but that’s just my opinion.