Daniel has been on Linux desktops for twenty years. Ubuntu mostly, Fedora for a stretch, a few others in between. And in all that time there's one distribution he has never once seriously tried.
Gentoo.
Gentoo. And the interesting part isn't that he hasn't tried it. It's why not. He says it's always seemed more intimidating than Arch, which is saying something, because Arch has a reputation of its own. Source-based package management, an install that assumes you know what you're doing, a level of control over the system that cuts both ways.
And then the practical pull in the other direction.
Right. He keeps coming back to Ubuntu because when commercial software vendors support Linux at all, Ubuntu and Debian get there first. Sometimes Fedora after that. So he ends up in this spot where the distribution that gives him the most control is the one most likely to make his life harder, and the one that makes his life easiest is the one that decides the most for him. His question, underneath all of it, is whether that trade still looks the way it did ten years ago. What is Gentoo actually like as a daily desktop in twenty twenty-six, has it gotten more approachable without sanding off what made it what it is, and what would he realistically give up and gain by switching.
That's the whole episode.
Let's do it.
So the reputation is the place to start, because the reputation is what Daniel is actually asking about. Gentoo got its name in an era where you hand-compiled your kernel, you spent a weekend on the install, and if you got the flags wrong you found out three hours later when something didn't link.
Was that era as long as people remember, or is it one of those things where the myth outlives the reality?
Both, honestly. The myth outlived the reality, but the reality was real for a long time. And the thing that makes this conversation worth having is that the distribution has quietly gone through its biggest change in twenty years, and most of the reputation people carry around is from before that change.
The binary packages.
December twenty twenty-three, Gentoo announced official binary packages. Twenty gigabytes of them for amd64 and arm64. LibreOffice, KDE Plasma, GNOME, Docker, the big heavyweight stuff that used to be the reason a full system upgrade ate your Saturday. By this year that repository is eighty-nine gigabytes.
Eighty-nine gigabytes of prebuilt software sitting on a distribution whose whole identity was not doing that.
And they were careful about it. The announcement explicitly says Gentoo still remains a source-based distribution and they are not aiming for a full binary-only install. That's not marketing hedging, that's the actual position. The binaries only match if your USE flags happen to line up with the profile defaults. The moment you deviate, Portage goes back to compiling from source.
So the binaries are the default path, not the only path.
And before we go any further, there's a measurement problem we have to be honest about, because it shapes how you read every number for the rest of this episode.
Which is that nobody knows how many people use it.
Nobody. Gentoo has no telemetry by design. Michał Górny, who's one of the developers, says it plainly: they still fail to get any telemetry on how Gentoo is used. That's not an oversight, it's a principle. They don't want to know.
Which is admirable and also makes this whole conversation a pile of proxies.
A pile of proxies. So here's the arc. We look at what the numbers actually say about the community, including the ones that go the wrong direction. We figure out whether the difficulty reputation survives contact with modern Gentoo. We walk through what a day with Portage actually looks like. Software compatibility, because that's Daniel's real anxiety. The performance argument, which has an interesting ending. And then who actually chooses this and why.
Start with the numbers that go the wrong direction.
Gentoo publishes a year in retrospect every January, and the one for twenty twenty-five is unusually blunt about itself. Commits to the main repository in twenty twenty-five were a hundred and twelve thousand nine hundred and twenty-seven. The year before was a hundred and twenty-three thousand nine hundred and forty-two.
Down about nine percent.
External contributors, three hundred and seventy-seven of them, which sounds healthy until you look at the other side of it. Four new developers joined the project all of that year.
Four.
Four. The user-curated repository, GURU, fell from roughly seventy-five hundred commits to fifty-eight hundred. The bug tracker went from twenty-six thousand one hundred and twenty-three filed in twenty twenty-four to twenty thousand seven hundred and sixty-three filed in twenty twenty-five, and resolved dropped from nearly twenty-six thousand to twenty-two thousand four hundred.
Gentoo's own framing of that is that it's closer to twenty twenty-three.
They say exactly that, and they're not lying, twenty twenty-three was similar. But the direction across every single one of those metrics is the same direction.
Four new developers is the one that sits with me. Commits can fluctuate with how much refactoring is going on, but four people deciding to join a project in a year is a different kind of number.
It's a recruitment number, not an activity number, and recruitment is the one you can't refactor your way out of. Now, the counterweight, because it's real and it matters. That same report says the project maintains thirty-one thousand six hundred and sixty-three ebuilds covering nineteen thousand one hundred and seventy-four packages. It builds a hundred and fifty-four distinct installation stages every week. Eighty-nine gigabytes of binaries on the mirrors.
That is not a project running on fumes.
That is a project the size of a small country running on a shrinking population. And those two things can both be true. Gentoo isn't dying, it's consolidating, and whether that's fine or a slow problem depends entirely on how long the consolidation runs.
What about the outside measurements? The website share trackers.
Weak, and worth saying why. W3Techs has Gentoo under a tenth of a percent of websites. That same tracker showed it at two point one percent in twenty fifteen, so it's a real decline. wmtips puts it at about a tenth of a percent of operating system share, below Fedora and Oracle Linux. But both of those measure web servers, and almost nobody runs a Gentoo desktop and also points a public web server at a tracker.
So the tracker is measuring the wrong room.
Measuring the wrong room entirely. The people who run Gentoo are not the people running publicly visible fleets of web servers. So the honest answer to Daniel's market share question, and I want to say this clearly because it's the actual answer, is that Gentoo's desktop adoption is unknown. Not small, not declining, unknown. The internal numbers show slow decline, the external ones are proxies that may as well be measuring a different country.
There's a funding angle on this too, isn't there.
There is, and it's the one I keep coming back to. The Foundation took in about twelve thousand dollars in the last fiscal year, plus eight thousand four hundred and seventy-one routed through SPI, with a hundred and four thousand in the bank as of the middle of last year. Then this October they posted a call for infrastructure sponsors, because several long-running sponsors were unable to continue.
That's a strange thing to read. A distribution with that scope putting out a call for help with the hosting bill.
Twelve thousand dollars a year is not a budget you can plan infrastructure on. And the Foundation is being wound down in favour of SPI. So you have a project whose institutional form is actively simplifying, whose sponsors are lapsing, and which is still shipping a hundred and fifty-four installation stages a week.
The volunteers are the load-bearing wall and the wall is not getting thicker.
That's the community picture. Now the thing that surprised me when I went through this, because it contradicts the reputation and it contradicts the code counts at the same time.
Which is that the comment section on Górny's why Gentoo post is full of twenty-year veterans and brand new converts at the same time.
Exactly that. The commit counts are down, the bug reports are down, GURU is down, and the people who are actually on the thing are the most loyal users in the ecosystem. Which is itself a data point. A shrinking project with unusually sticky users is a different animal from a shrinking project with indifferent ones.
Let me put the uncomfortable version of that to you. A lot of things are unusually loyal right before they're not.
That's the risk, and I'm not going to pretend the risk isn't there. But loyalty that survives the departure of the casual users is loyalty you can build on, and the four new developers number is the one that determines whether it holds.
So the community is shrinking but real. What does a day actually feel like in it.
So the binaries are the headline and we talked about them, but the part that changes daily life most is that Portage mixes the two.
Explain what mixing means practically.
You run emerge, which is the install and update command, and it decides per package whether it has a binary that matches your configuration or whether it needs to build. One command, no ceremony, and it tracks which method installed each package so updates go the same way next time.
And that's a contrast with how other systems handle it.
A returning user describes FreeBSD, which also has ports and packages, as not handling the mixing well. It's one or the other in practice. Gentoo treats it as a single continuum, and that turns out to be the whole ergonomic story.
What about the kernel? Because that used to be the initiation rite.
Gone, mostly. There's what's called the distribution kernel, dist-kernel, which is a prebuilt kernel with a configuration the project maintains. So the baseline Gentoo install no longer involves sitting with a menu of a thousand options deciding whether you need support for a network card from 1998.
I like menuless.
One blogger put it as kernel installs being a far cry from manually copying the kernel and initrd. That's a fair description of the change. You can still hand-compile if you want. The point is you don't have to in order to have a working system.
Compile times. Because the objection everyone has in their head is that a system update takes three days.
That was true, and on modern hardware it mostly isn't. One user reports a full rebuild of the entire world set, every package on the system, in under an hour on a Zen 5 machine. Someone with a Ryzen AI 395 reports the kernel compiling in about a minute. A blog that timed it carefully put a kernel at twenty-three to twenty-five minutes.
That's all three different numbers and they're all about a minute to under an hour.
Because the hardware range is enormous. On a decent modern machine it's a coffee break. On a 2014 laptop it's still an overnight job, and there are still people running Gentoo on 2014 laptops.
The maintainer of the distribution kernel does that on a laptop that predates the dist-kernel.
Probably. Now security, because that's the piece that actually matters for a daily driver and it's the part people never talk about.
Security updates on a distribution that compiles everything is a real question. You can't just get a patch and be done.
Gentoo ships advisories, GLSAs, and the workflow is that you sync, you see what's affected, and you re-emerge. The interesting part is that compiling is sometimes faster than patching, which sounds backwards.
Say more.
In May this year there were kernel privilege escalation issues going around, and Gentoo shipped the fixes for one of them from day one while upstream was still exposed. Because they control their own kernel builds, they could just rebuild with the fix rather than waiting for a vendor to push a binary.
That's the compile advantage showing up in a place nobody expects it.
It's an interesting inversion. The thing people think is the cost turns out to be a latency advantage in the one moment where latency matters. But there's a caveat, and they said it themselves: only three kernel packages are security-supported. If you're rolling your own kernel configuration outside those, you're on your own for security backports.
What about the new requirement on the signing side?
As of May, Portage requires valid OpenPGP signatures for any remote binary host by default. So if you're pulling prebuilt packages from somewhere other than the official mirrors, the signature checking is on unless you deliberately turn it off.
Which is the right default for something that installs software.
It's the right default. Now, the install itself, because this is where the reputation actually lives and this is the bit that hasn't changed as much as the rest.
The Handbook.
The Handbook is excellent. One returning user calls it ten out of ten, no notes. How-To Geek calls it invaluable. It's step by step, it explains why each step exists, and it's the reason the install is learnable.
But.
But it still fails people. How-To Geek's author has years on Ubuntu, Red Hat, Mint, and he botched a virtual machine install and never finished it. There's a blog from someone who abandoned the third attempt on two circular dependencies in the dependency resolver.
Two circular dependencies.
That's a resolver problem where package A needs package B and package B needs package A, and the tool can't order them. It's the kind of thing that will stop you dead for an afternoon if you don't know what you're looking at.
So the handbook is a good teacher and the subject is still hard.
That's the honest read. Easier than the reputation, not easy. And the comparison to Arch is that Arch's install is now scripted, you run a guided installer and you're done in ten minutes. Gentoo's install is not scripted in the same way, because the things it's asking you to decide are the things you'd have to decide anyway.
The install is the point, not the obstacle.
For the people who like it, yes. For everyone else it's a very long obstacle. Both descriptions are accurate depending on who's holding it. What's the first thing you'd actually hit as an Ubuntu user, do you think?
Software. Every conversation about switching distributions ends at software, and Daniel said so himself.
So the ecosystem is bigger than the reputation suggests, and there are four layers to it. The official repository is nineteen thousand packages, which is not small. Then overlays, which are community repositories you can add, and that's the PPA and AUR comparison. Then GURU, which is the reviewed community repo, and this is where it gets interesting.
Reviewed.
Górny makes the point directly, comparing it to what happened with Arch's AUR in June. He says the unlimited ability to upload packages was always the AUR's weakness by design, and that's what GURU avoids by requiring review before a package goes in.
So the trade is you get fewer packages but less chance of installing something someone uploaded at two in the morning.
That's the trade. Slower to grow, harder to poison. And then the last layer, which is the one that actually resolves Daniel's worry.
Distribution-independent packaging.
Flatpak works, and it's used. A commenter who moved to Debian says flatpak can provide up to date versions of so much desktop software that there is very little point switching back. AppImage works. And Gentoo can consume packages built for other distributions entirely, RPMs included, without converting them.
So the thing he was worried about is basically solved.
Basically. The official corporate support is still the missing piece, and that's real and we should say it. If a vendor only tests on Ubuntu and Debian, that doesn't stop you installing their RPM, but it does mean when it breaks, the vendor says the distribution isn't supported and you're debugging it yourself.
The distribution stops restricting what you can install and starts restricting what you can get help with.
That's the accurate version of that worry. And it's the same worry Daniel already has with Fedora, so it's not new information to him, it's the thing he'd continue to live with.
I want to go back to the performance argument, because I think it's the most interesting piece of this, and it ends somewhere unexpected.
It ends with Gentoo's own developer conceding the point. Górny writes that he suspects your average Ubuntu package with generic optimizations may be no slower than the equivalent Gentoo package fine-tuned for your CPU, and if it's not slower, it probably doesn't make a real difference anyway.
The distribution's own developer saying the flagship argument is dead.
That's the headline of the whole episode, honestly. And the wider consensus agrees. There's a widely cited figure that you won't see a fifteen percent speed increase from compiling from source, and the same source says they'd be reluctant to put it even as high as five.
Five percent as an optimistic ceiling.
Five percent as something they wouldn't commit to. And Ubuntu has moved in the same direction, with the architecture variants they shipped last year rebuilding a couple of thousand packages with more aggressive optimization out of the box. So the gap that used to justify the whole exercise has narrowed from the other side.
Which raises the question of why anyone still compiles.
And the answer people give is not speed. It's flexibility. The example that keeps coming up is building a mail client without a browser engine dragged along behind it. That's not a performance claim, that's an attack surface claim.
And a resource claim. A lighter binary on the same hardware is a different machine in practice.
A different machine, and one with fewer things that can go wrong. Górny's own pitch for the distribution isn't speed at all. He says it might not be the easiest distribution to start with, but once you set it up, it's surprisingly stable.
Interesting that the man selling the distribution is selling stability.
It's the pitch you'd give if you were honest about what it's for. One long-time user describes compiling everything as overkill but points out that it's unattended time, and that actual compile failures are extremely rare, less than once a year. Another says it's a good feeling knowing the system was built with exactly as much functionality as it needed and no more.
And the counterexample.
A user who moved to Debian in twenty twenty-two because his older CPU had become too slow for the language toolchains. Hours and hours of brutal grind, he calls it. So it holds exactly as long as your hardware does, and then it stops holding.
Which is a nice thing to be able to say about a distribution. It works and then your laptop gets old.
That's the whole story in one sentence, and I don't think any distribution survives it forever. So the motivations have shifted. In the mid two thousands the reason was speed. Now the reasons are flexibility, stability, and independence.
Independence meaning what.
Independence meaning there is no company behind Gentoo that can change the terms, no telemetry phoning home, no product decision made in a boardroom that ships to you whether you want it or not. It's a volunteer project with a governance model and no owner.
And a stance on what they will and won't accept as contributions.
They banned LLM contributions two years ago and said they've never regretted it, and Górny's line on it is that if they got left behind, it's only for the better. That's a value statement about what the project is for, and it's exactly the kind of thing a person choosing Gentoo is choosing.
So for Daniel, the honest trade is control versus convenience.
You gain fine-grained control, a system built with exactly the functionality you asked for, and independence from corporate priorities. You give up the gravity that pulls commercial software toward Ubuntu and Debian first, and you take on maintenance that Ubuntu does for you. And you take on four new developers a year worth of schedule uncertainty about where the project is in five years.
I'm going to test that against the thing he actually said, which is that he wants a desktop that works reliably and has the widest software compatibility.
Then the answer is that Gentoo now clears the compatibility bar and the reliability bar for a certain kind of user, and the thing it doesn't clear is the maintenance bar, because it's designed to be maintained rather than to maintain itself.
And the person who doesn't want to maintain anything should stay exactly where he is.
The person who doesn't want to maintain anything should definitely stay where he is. The person who finds himself reading about USE flags at eleven at night out of curiosity, that person is already halfway there.
There's someone here who has been waiting to correct something about those binary packages.
They're built with march equals x86-64. Not your machine. Nobody's machine.
The lowest common denominator deliberately.
Conservative flags so the binary runs anywhere. Which is correct, and it's the right call, and Górny's right that the speed difference is nothing. I agree with him. I'm not arguing with him.
What are you arguing with.
Nothing. I want the record straight on why people still compile. It isn't speed. It's that you can build a system with exactly the functionality you need and nothing else.
What did you build.
A mail client. No browser engine in it. No rendering stack, no scripting runtime dragged in behind it because some dependency decided to render HTML for an email that was never going to have HTML in it. Most satisfying thing I've ever done on a computer.
That's not a performance claim, that's a footprint claim.
It's a footprint claim. And I ran one Gentoo system for eleven years without a single failed compile. One failure, ever, if we're counting the whole run. And that one was my fault.
What was it.
I set a USE flag I didn't want because I was curious what it would do, and it pulled in a dependency I had no use for. Took me an evening to unwind. I consider that a personal failure, not Gentoo's.
Eleven years with one failure.
Eleven years. I still have the install notes from that machine. Legal pad, handwritten, every decision and why I made it. They're in the fireproof safe next to my passport.
In the fireproof safe.
Along with a printed copy of the Handbook. Annotated. Three colours of ink. I haven't needed to open it since twenty fourteen.
Three colours.
Red for things that would break the install, blue for things that depended on order, green for things I got wrong and had to do twice. The green is the thickest section.
And that's the whole system. Nobody's touched that Handbook in twelve years, and it sits in a safe next to his passport.
Which is, I have to admit, the most accurately Gentoo thing I have ever heard.
The safe, or the green ink.
The safe.
The safe is a fireproof safe. It's a reasonable place for documents.
So the binaries are generic by design, the speed argument is dead, and the real reason to compile is to leave things out.
Which is where I'd land too, and I think it's the honest pitch. The advantage isn't that it's faster. It's that it's exactly what you asked for.
Which for most people is a very expensive way to get something they wouldn't have asked for anyway.
For most people, yes. For the person who wants to leave the browser engine out, no.
Which brings up the question I don't have an answer for. If the contributor base is shrinking while the binary repository is growing, what does this look like in five years? Is it a smaller, sharper project that knows exactly what it is, or is it a binary distribution that happens to still support source?
The thing Hilbert said about the green ink, honestly, is where I keep landing on that. The people who stay are the people who care about the specific thing, so a smaller project might be the sharper one. But the trajectory of everything is toward binaries because binaries are what people actually install.
A binary distribution that still lets you build the mail client without the browser engine.
That might be the whole answer, and if it is, it's a fine thing to be.
So the short answer for Daniel. Gentoo is no longer the demanding, highly specialized distribution of its reputation. It's more approachable than it's ever been, without having sanded off the philosophy. Whether the control is worth the convenience is the only question left, and that one's his.
Thanks to our producer, Hilbert Flumingtop.
If this was your kind of episode, go back for episode fifty-nine sixty-five, Compiling From Source. This has been My Weird Prompts, the human-AI collaboration podcast.
If you like the show, leave us a review wherever you're listening. It helps.
We'll be back soon.
