Gentoo Ought to be About Choice
“Gentoo is about choice.” We’ve said it so often that it seems like we just don’t bother to say it any more. However, with some of the recent conflicts on the lists (which I’ve contributed to) and indeed across the FOSS community at large, I think this is a message that is worth repeating…
Ok, bare with me because I’m going to talk about systemd. This post isn’t really about systemd, but it would probably not be nearly as important in its absence. So, we need to talk about why I’m bringing this up.
How we got here
Systemd has brought a wave of change in the Linux community, and most of the popular distros have decided to adopt it. This has created a bit of a vacuum for those who strongly prefer to avoid it, and many of these have adopted Gentoo (the only other large-ish option is Slackware), and indeed some have begun to contribute back. The resulting shift in demographics have caused tensions in the community, and I believe this has created a tendency for us to focus too much on what makes us different.
Where we are now
Every distro has a niche of some kind – a mission that gives it a purpose for existence. It is the thing that its community coalesces around. When a distro loses this sense of purpose, it will die or fork, whether by the forces of lost contributors or lost profits. This purpose can certainly evolve over time, but ultimately it is this purpose which holds everything together.
For many years in Gentoo our purpose has been about providing choices, and enabling the user. Sometimes we enable them to shoot their own feet, and we often enable them to break things in ways that our developers would prefer not to troubleshoot. We tend to view the act of suppressing choices as contrary to our values, even if we don’t always have the manpower to support every choice that can possibly exist.
The result of this philosophy is what we all see around us. Gentoo is a distro that can be used to build the most popular desktop linux-based operating system (ChromeOS), and which reportedly is also used as the basis of servers that run NASDAQ[1]. It shouldn’t be surprising that Gentoo works with no fewer than 7 device-manager implementations and 4 service managers.
Still, many in the Linux community struggle to understand us. They mistake our commitment to providing a choice as some kind of endorsement of that choice. Gentoo isn’t about picking winners. We’re not an anti-systemd distro, even if many who dislike systemd may be found among us and it is straightforward to install Gentoo without “systemd” appearing anywhere in the filesystem. We’re not a pro-systemd distro, even if (IMHO) we offer one of the best and undiluted systemd experiences around. We’re a distro where developers and users with a diverse set of interests come together to contribute using a set of tools that makes it practical for each of us to reach in and pull out the system that we want to have.
Where we need to be
Ultimately, I think a healthy Gentoo is one which allows us all to express our preferences and exchange our knowledge, but where in the end we all get behind a shared goal of empowering our users to make the decisions. There will always be conflict when we need to pick a default, but we must view defaults as conveniences and not endorsements. Our defaults must be reasonably well-supported, but not litmus tests against which packages and maintainers are judged. And, in the end, we all benefit when we are exposed to those who disagree and are able to glean from them the insights that we might have otherwise missed on our own.
When we stop making Gentoo about a choice, and start making it about having a choice, we find our way.
1 – http://www.computerworld.com/article/2510334/financial-it/how-linux-mastered-wall-street.html
Rich0's Gentoo Blog 
I have been using Gentoo GNU/Linux as my main system for nearly eleven years now. I’m not a developer, but I’ve posted or contributed to a few dozen bug reports or enhancement requests of varying importance over the years, and I feel I’m a part of this fine community. While I’m sure trying to avoid systemd, like I have been trying to avoid many other pieces of software clearly making almost everything more complex and difficult as an advanced user, I do certainly understand how choice and empowering is important. And while it can stretch our capacities at times, it is also helping to gather more users and developers, with diverse interests. I’m proud to be a Gentoo GNU/Linux user, with these values.
Jacques
February 27, 2016 at 11:57 pm
For me its aside choice one importent fact : wanting just what i want, fast and not blown up. A minimal system fitting my needs and kind of philosophy. Where else than with Ge- or Fu-ntoo, Slackware, LFS is this – in an organized way – possible?
Shure it needs a lot more attention from the user, but he will get what he wants. Who ever tried to minimize a system like Ubuntu, Mint, Suse by deleting not wantded and not needed packages will in a short time know, what dependecies are. Even with USE-Flags or the so-called Mix-ins from funtoo it is still not perfect. There are many Flags switched on by default, and sometimes they dont cover the .whole lot of configure-possibilities. But no other distro gives me those choices to create “my” system.
And there is another effect not mentioned. Who ever “dares” to try Ge-Fu-ntoo will learn a lot about the logic of a system running linux, and the hell of a work the developers do for us. So beeing greatful and respectful is coming in a natural way.
Peter
February 28, 2016 at 9:59 am
Certainly agree, but in some sense fast and not blown up is just another choice. Recently there was a debate over udev vs eudev as a default udev provider, but the reality is that you can just choose a static /dev if you prefer. Obviously that choice comes with certain limitations, but it is a choice you can make all the same.
Mix-ins are actually something many are interested in and hopefully we’ll see some day. The reality is that our @system set forces some choices upon users which could be overridden but not in a natural way. For example, you don’t have the choice to install without a service-manager at all, or without openssh. In environments such as containers these components aren’t always necessary.
rich0
February 28, 2016 at 10:21 am
Very well stated. =:^)
Of course you know the following, but other readers, particularly those from other distros who might happen across this, may not, so…
One mistake a lot of folks make is in thinking gentoo is about building from source. Sure, that’s the default assumption for gentoo, but it’s very definitely a means to an end, not _the_ end in itself, which were it the case would, I’d agree with those making the mistake, be mostly useless.
Similarly, many think gentoo is about “ricing”.
What those folks miss is the simple fact that gentoo really is about choice, and that the fact that we generally build from source is simply one of the ways gentoo exposes that level of choice to the user — at a depth that simply isn’t possible with a binary distro, because a good portion of the choices we expose must be made at build-time.
The choice of systemd or not is a great example. In many cases, systemd support must be enabled at build-time to work properly. For a binary distro that defaults to systemd, even if they choose to allow users to choose other init and service managers, and even if they provide packages for those other managers, users choosing to use those other service managers still have to deal with both a bunch of systemd (to them) bloat in the packages they install themselves, and are forced to install various systemd related library dependencies because the various binaries link against them and won’t run without them. Of course it works the other way as well. If a binary distro defaults to something other than systemd, and in particular, if they don’t build in the systemd support, then they’ll have a very hard time providing the systemd choice to users who want it.
Of course this is what made the debian systemd debate so critical, since as a binary distro, defaulting to systemd meant building against systemd and pulling in all that (for users not choosing to use that default) bloat, even for users who wanted to use something else.
The same story is repeated over and over, with kde vs. gnome vs. whatever other DE default a binary distro may settle on being another big-deal example. Because the most integrated DE support options must be set at build-time for many packages, many binary distros will choose a default DE and build in “deep” support for it, while omitting that level of support for other DEs. Not only do other DEs on that distro not get the same level of integration, but people choosing to use them must still deal with that integrated support for something they don’t use bloating their packages and pulling in even more dependency packages they won’t use because they’re only used on the default DE, anyway. Other binary distros do their best to be even handed and provide as integrated a level of support for all DEs they can, but there’s two problems with this. First, that means even /more/ bloat for people using only one of those DEs. Second, in some cases it’s an either/or choice and all choices /cannot/ be supported at once.
On a from-sources distro (with flavors of a metadistro) that has exposed those choices to the user, as gentoo has via USE flags, the user can actually make those choices: Systemd support, or not? Kde or gnome support, or neither, or both, with which one taking priority when only one can be chosen? Which codecs do you actually want to support in your media player? All of them and pay the price of bloat and more packages to repeatedly build at each upgrade? Only what you know you’ll actually use, making for a smaller package with less chance that security vulns apply as you may not have actually built in that option, but at the expense of possibly having to rebuild with support for a new codec if you find a file that uses one you didn’t build in support for? On gentoo, you’re choice as a distro user and the admin of your own systems! =:^)
Oh, and for anyone reading this that might be worried about it, after the initial decisions and configuration of what you want, updates don’t generally take much more admin time than they do on other distros, and may in fact take less, due to gentoo’s configuration update automation tools. Sure, it takes time to build the packages, but that’s all automated, and in a modern world of fast multi-core processors, you just tell the package manager to do the updates in the background while you go about your normal business (on the computer or off), and then let it do its thing. When it’s done you run the config updaters and pick what bits of the new config you want to add to your old config, and _that_ is where you actually have to pay attention and do it right, but that’s precisely the same task you must do when updating _any_ distro to newer versions, and it’s going to take about the same time regardless, with the biggest difference being how well the config update tools work on your distro of choice, with gentoo’s actually being better at it than many I’ve dealt with. =:^)
Duncan
February 28, 2016 at 1:07 am
Nobody in Gentoo wants systemd. The “choice” is there, but nobody wants it. it’s been relegated to a “fringe” link in the handbook on purpose. But the people have spoken. the “choice” is available, and nobody’s using it.
Your project is an attack on both the GPL and GNU itself. Your propaganda campaign to force systemd on Gentoo has failed before, and it will fail this time as well.
Jason Oliveira
February 28, 2016 at 4:19 am
So, while I think your wording is unhelpful and not in line with our CoC, I wanted to include your comment for completeness so that you and others can be assured that replies aren’t being curated here. This isn’t a commitment to allow this sort of vitriol in the future.
If nobody in Gentoo wanted systemd there, it wouldn’t be there. None of the systemd maintainers are paid to maintain it (at least, not that I’m aware of), and in fact some of them are the same as some of the openrc/eudev/etc maintainers. The reality is that we all work together and share ideas/etc, with the goal of making all of these experiences smoother for the user.
The handbook being in the state that it is in is largely the result of inattention. I’ve been meaning to smooth things out, though the need for this will be lower in the future (stay tuned). The reality is that Gentoo has MANY possible configurations and it is a bit tricky to have an easy-to-read handbook that accomodates them all without turning it into a “Choose Your Own Adventure!”(TM).
Really, attitudes like the one you’re displaying were exactly the motivation for my post. The strength of Gentoo comes from our diversity. I don’t use uclibc but those who do use uclibc benefit from the packages that I maintain which are relevant to them. I don’t use openrc, but developers who exclusively use openrc maintain lots of stuff I use. Everything about Gentoo is designed to empower users to mix and match, so that we don’t have to pick winners.
The fact that a particular package is a default isn’t really an endorsement of that package. Our defaults reflect general preferences and are all configurations that a new user could use safely to establish a starting point that they can move on from.
rich0
February 29, 2016 at 10:07 am
Well said, err written!
Ronald Farrer
February 29, 2016 at 11:49 am
Most do not take exception to systemd, but, the linux kernel development folks should have insisted on it’s development in a venue that does not prejudice systemd over other init systems. In the world of clusters (the cloud if you are a customer), where the battle for the linux mind share is raging there are two main thrusts, the Container and the Hi-Performance-Computing venues. Most of the HPC folks are seeing the best results on bare-metal without systemd, imho. In the container world, it has most purveyors of clusters on systemd. But recently, with Alpine linux (openrc + eudev) being subsumed by docker (docker recently hired the chief dev of Alpine) it seems the container world is now directly on path to test the performance of systemd vs direct/custom cgroup management. I’m happy to be a gentoo aficionado for over a decade now, and gentoo rightly deserves to be in the middle of this performance battle-royal. 1-3% performance advantage may not be important on a small scale, but in the cluster/cloud world, it is everything. Uniquely on gentoo, one can build Container-clusters of openrc vs systemd with everything else being equivalent and publish results to shed some light as to what the HPC devs have known for quite some time. It also a great way to pit file systems against one another on a variety frameworks and problems. The next few years promises to wonderful for linux and the vetting of big ideas against tried-and-proven semantics of choice.
jon johnson
March 11, 2016 at 11:36 am
I could buy that in HPC environments it would be better to not have systemd running. Openrc just launches services and doesn’t really do anything to try to manage them. Systemd is more of an active service manager and while I doubt it uses multiple % of CPU it certainly uses some CPU to accomplish this.
I doubt there is any practical difference between eudev/udev/systemd for a udev provider though of course anybody is welcome to test this. The actual code that is running is nearly identical in all three cases. Most of the eudev changes are to some of the default rules and the build system, which shouldn’t impact runtime. But, I could be overlooking something. My sense is that you’ll find more impact on the service manager side of systemd, since that is the part that is always running.
Systemd doesn’t use much in the way of resources, but I won’t argue that it does use some and you can run containers without it.
rich0
March 11, 2016 at 12:25 pm
gentoo has been a part of my life over a decade and would not have it any other way. most breakages in my experience are due my own inattention, unwillingness to read documentation etc. systemd i m sure solves a problem, but i am happy with what i have so i have chosen not to pursue systemd until i have read about it in some detail == time i dont have. i am grateful for all contributions that foster a vibrant ecosystem that is gentoo (wish i could do more personally to that end) thank you for reminding me why i love gentoo so much!
zeleze
March 2, 2016 at 2:12 am
I’ll go ahead and admit that there are things I haven’t installed simply because I haven’t had the time to grok them as well. I don’t really have any philosophical objection to pulseaudio, but the box I’m typing this on predates it and I haven’t gotten around to enabling it. For what I do with it I don’t really have any need for it, so I might or might not ever get around to trying it. Perhaps I might try it and learn to dislike it, or wonder why I waited so long. And that’s all ok…
rich0
March 2, 2016 at 2:31 am
I’ve found it to be very helpful with USB Audio, since it can switch default output by itself (with the relevant module enabled), when the audio device is connected and disconnected.
ufoman
March 2, 2016 at 10:54 am
Great blog post mate. That’s the main reason why I started using Gentoo back in august 2015. No, it wasn’t because of “init” disagreement, but the plethora of choice and diversity that Gentoo provides.
Emo
March 5, 2016 at 6:59 am
Lately I’m feeling we are starting to miss out on one very important kind of choice.
The choice to have things work without spending time on endless tuning if you just don’t care in this instance.
Most prominently this seems to show with conflicting REQUIRED_USE statements and cases where you need to tune your package.use or global USE flags for USE dependencies on higher level packages, with per-package USE defaults or profiles not taking care of it for you. A bit also with having missing important functionalities at places when you don’t happen to enable some oddly named USE flag that often tends to express the name of some external dependency lib instead of the functionality, with that name being not really clear on what it does.
Mart
March 8, 2016 at 8:28 am
The sometimes-talked-about “lazy USE flags” feature combined with sensible USE defaults should help to address some of this, but ultimately the only choices we have are the ones people step up to create.
rich0
March 8, 2016 at 10:27 am
@rich0, thanx for the fine blog post. Writing you as a happy systemD user of Gentoo.
But: “ultimately the only choices we have are the ones people step up to create.”
is not true. The other people you would have and now have in the Gentoo forum are the ones who would like to engage more, but lack of knowledge.
So: Your other way to develop Gentoo further could be in the direction making the portages profile more accessible for ordinary user:
Why is the profile in the portage ebuilds directory?
Why in a recursive mode?
As Gentoo is a meta distribution the ways to handle profiles and distribute them should be addressed.
Ralph Ulrich aka ulenrich
March 9, 2016 at 6:03 pm
I’m pretty sure it is fairly trivial to create your own profiles in your own overlays. Ultimately it is just a directory you create a symlink to.
Improving profiles with mix-ins/etc is something many are interested in, and I don’t think anybody opposes. Somebody just needs to do the work to set it up.
rich0
March 11, 2016 at 12:22 pm
The part you are missing, is that certain “choices” preclude others.
khayyam has described this well, on the forums.
It is a shame developers choose to ignore their users, but that’s what leads to their projects’ eventual demise, so it’s an evolutionary effect.
OFC one must account for artificial selection, but that’s another discussion.
The essential point is that installing the Master Control Program, however well-meaning the schmo who does it, leads to vendor lock-in, since that is the design.
Hopefully that is sufficiently formal that you do not feel an expression of opinion to merit a Code of Conduct action, though you should of course acknowledge that such only apply to developers, since the Developers’ Code of Conduct has very little to do with the Community-endorsed Code of Conduct.
Again, another discussion, but one in relation to which you are, and were, very much privy.
Regards,
steveL
Steve Long
May 26, 2016 at 11:05 pm