We already asked ron for this on zulip…
1 Like
Yeah, I did mean systemd, thanks! I just assumed that at this point, we probably use more features than something like rustysd provided - it would be interesting to check though. If the gap’s small enough it might be easiest way to have an alternate init system in mainstream nixpkgs. One to add to the never-ending to-do list :)
Its not small enough by any stretch of the word small.
- Timers (Cron should do fine for 99% of usecases)
- Mounts (It is actually useful to have these as units but I don’t think the gains outweigh the added complexity)
- Device (Same argument as for Mount)
- Path activation (Might get included.)
- Scopes (Nope. If you start processes outside of rustysd you need to manage them yourself. Maybe a second instance of rustysd? ;))
- Slices (this might be added as it is fairly important if you are not running inside of a container)
We use every single one of these very extensively. So no we cannot migrate from systemd without halting the development of NixOS for at least one release cycle and rewriting a large part of it.
I suppose approaching from the other direction then might be to take sixos / finix / NixNG, adapt them to use rustysd, and then use its basic systemd compatibility to allow easy import / conversion of existing nixpkgs modules. But I appreciate this is all hot air until one of us tries :)
1 Like
Of all the takes in this thread I think this is the most misguided.
We already know the significant financial influence by meta that’s pushing lobbying of these laws.
I’d hardly say this is a conspiracy when so much evidence exists that mass surveillance is the goal.
I’m not generally a kool aid drinker but this much is obvious. In my opinion the only correct move is non-compliance in protest.
An NL foundation does not need to comply with non-NL laws. That’s it.
5 Likes
Proud paranoiac here! 
@rhendric I appreciate the generosity and good faith of you comments 
– just wanna say up front that I only intend to reciprocate and have huge respect for the maintainers and contribs here (all my snark aside). 
Now, that said…
I see what you’re saying that no one’s identified a specific attack vector in the software being discussed (NixOS or nixpkgs or systemd, I assume, or did you have one in particular in mind?) that would directly jeopardize anyone’s basic civil liberties. I’m not the most qualitifed person to say yea or nay, tbh, but in a general sense, I could concede that in their current state (whichever of those softwares you might have in mind), they at least present no greater threat than, say, the gcc (just as a random example). I will, h/e, flag that this as a fairly vague premise, since “freedom” and “threat” are purely subjective terms here; any and all software can be a deadly threat, imo, depending on who wields it and what they choose to do with it. Without the full user & deployment context it’s just so much unexecuted code.
I think there’s probably more than these two (or the one counterfactual, really), but okay, I get what you’re saying about patching, at least I think. Honestly, I’m willing to appeal to the expertise of others that there’s nothing to patch right now, because I’m a comparative noob. Fair nuff.
But it just doesn’t follow logically that – because there’s no library that can be patched, right now – there’s nothing else to be done. It’s such a totalizing outlook to rule out every other course of action and sit on the sidelines while the lawyers register their opinions, which might take years. Like, I may not be qualified to register a knowledgeable opinion on the inner workings of systemd or nixpkgs, but just because of that, I don’t abdicate all my political agency on the ways systemd or nixpkgs may effect me as a user or the people who entrust me to develop and administer the services that they use which might be impacted by changes to nix or systemd. I acknowledge that rage commenting in forums or signing online declarations is some pretty weak tea, but at least it’s not nothing. Plus there’s a lot of preliminary work that can be done, too, as software and infrastructure maintainers, all of which can go a long ways to make sure more people (regardless of expertise) know their options and can safely opt-out or migrate when the time comes, if needed.
I came to this forum topic after watching a really great video on Making [Artix] Linux Ungovernable With I2P, where the presenter wraps pacman so they can continue to get their Arch packages over I2P via mirrors or torrents in a (perhaps bug-prone, but) really imaginative way. Clearly, there’s ample room for improvement, but this actually seemed like a place where the unique strengths of Nix/NixOS might far exceed the capabilities of other distros and package managers to adapt quickly and evade these encroachments.
After watching that vid, I came straight to this forum to check the latest topics and saw this thread trending, but was disappointed in the lackluster responses, particularly compared to very different tone of the Artix maintainers on their forum, which I think has already had a pretty significant impact even so far as symbolic gestures go, jus sayin… 
1 Like
The cgroups part is not true. Cgroups v2 have a single writer principle and this means only Systemd May modify it. If two programs modify the same cgroup tree without them being aware this is a violation and things will go wrong.
Systemd is the only implantation of a cgroup manager and defacto the owner of the full tree. Things can be marked as delegated. But the whole tree is owned by systemd and you can’t have another cgroup manager co own it.
2 Likes
some might disagree with my take but:
I will keep monitoring this entire systemd situation going as I honestly don’t wanna leave NixOS (sometimes I keep eyeing Qubes but let’s not talk about that.)
I guess that, for the time people that are saying “oh it’s just an optional field you can simply not put anything there” are correct, but the question then becomes WHEN it’s not longer optional but mandatory and in a way you can’t just “lie” your age.
IF (once again, this is a IF not a WHEN) this happens, then I will see what I do (can anyone report me how SixOS is doing? I remember reading about it some months ago but never understood if it’s still in ongoing development or if it’s pretty much abandoned, I was never someone that had a pretty strong opinion on systemd but these recent days have certainly made me have a few more opinions on it.)
Also, maybe ignorance from my part but, it was said earlier here that NixOS doesn’t use userdb by default, but when I went to check I realized I’m using it and I’m wondering why that is since I don’t remember ever enabling it or anything (but again, I installed it like back in 24.11, I just won’t go after disabling it cause no clue if this would cause any conflicts with how my system is currently running)
You can be confident that this will never happen. The systemd upstream is also full of privacy-minded people, and even if it weren’t, nixpkgs is, and patching this out is trivial. I’d help with that effort.
Given that these laws don’t exist everywhere, it’s pretty unlikely that even if a good 3-4 separate open source projects decide that they have to offer this feature, it will ever be anything but opt-in.
That said, should a currently-hypothetical future arrive, it’s possible that you will not be able to browse certain websites or use certain software if that field is not filled (though currently real laws still allow you to lie).
If that happens removing systemd will not help. At best you would have to replace systemd with a different service that provides the same field.
I expect that many people currently outraged against this will fill the field once steam starts requiring it for shooters. In other words, the backlash is just social media doing its thing.
If you want to do something actually useful to prevent being impacted by this, go vote, complain to your government representatives, or should all the above be impossible where you live, consider emigrating.
4 Likes
If it’s not enabled in your config or a third party module you import, then it’s not enabled, because no first party module in NixOS enables it by default. How did you determine it is enabled? Note that the existence of the userdbctl binary in your PATH does not mean it’s enabled; the systemd-userdbd.service unit being active would indicate it’s enabled, or the config.services.userdbd.enable NixOS option evaluating to true in nixos-rebuild repl.
6 Likes
How difficult would it be to have the option to use openrc in nixpkgs? Llms say that nixos build around systemd, and it’s deeply rooted and sound impossible.
It would be very difficult. We’re very strongly tied to systemd, as the llms are telling you.
1 Like
Also, there are other components that will participate in this birth-date-storing stack, and at least one of them is going to fall back to file storage if systemd is absent. Removing systemd will achieve nothing. You’re being manipulated by people who had pre-existing grievances with it.
3 Likes
Falling back to file storage would guarantee root control over the thing, and there are things that systemd somewhat yanks from root control… except that even I don’t believe they will yank this one.
1 Like
I have been pro-systemd up until now - and have been on the receiving end of serious harassment for that position. I am however horrified by how easily they decided to “comply in advance”, and the way they have moved to shut down debate on the issue. The concurrent decision to start leaning on LLM-based workflows isn’t ideal either.
For all their (often serious) faults, none of the big noises in the free/OSS world of the 90s and 00s would have swallowed this. The corporate capture of even the core of the ecosystem suddenly feels terribly obvious. I guess I should have been paying better attention 
6 Likes
I think they are doing it wrong (they should have treated it as true parental control and allow root to specify and update the age bucket directly), but bad design decisions in systemd do not surprise me.
Compliance in advance with «you must give the system owner this access configuration tool» has all the old owner-rights-vs-user-rights issues (although we rather consistently take the owner-rights side anyway), but politically unlocks «our interpretation of California laws says we are not allowed to comply with thrid-party-permission-to-use-your-system laws in New York State» which might or might not work, but is probably the most corporate-legible tactics.
Or we can use different tools that don’t rely on this? This is nixos, the whole point is that you can patch out what you dislike and adjust it to your liking. If something adds age verification components then you either remove it or block it from doing so. You can use something else.
Spurring the community away from the systemd ecosystem and having better control over what goes on in the system isn’t a bad thing. It allows the users to have more control over what goes on without dealing with the issues that systemd brings onboard where the team behind systemd ignore and have ignored debate and criticism over their implementation time and time again.
If gouging out systemd doesn’t work, then you replace components until you’re not having age verification shoved down your throat. Whole point of having a system where you can swap components in and out. Whole point of open source where you can create solutions against things you disagree with.
systemd having a user monopoly was never a good thing for the health of the surrounding ecosystem.
2 Likes
I agree! NixOS is a library for you to write an operating system that does what you want, and it is and should remain possible for you to write an OS that doesn’t do age verification. In no way am I arguing that you should not have that freedom, and if at any point that freedom is actually threatened I will certainly be contributing to protecting it.
My whole point is that
while (isAgeVerificationBeingShovedDownYourThroat()) {
ripOutTheNextComponent();
}
is a loop that currently terminates with zero iterations, and if that changes, systemd isn’t even the most likely culprit for first component to get ripped out, so everyone who is talking about systemd and not that more likely next component is probably, assuming good faith, being misled by the negative vibes.
5 Likes
I doubt that its being misled by negative vibes. Consider the age verification laws, where did they start? They started with restricting and banning of adult media and escalated more and more until we’re now at the point where they’re trying to restrict operating system usage.
As systemd is implementing this ahead of time, this is simply one of the many steps. It’s like seeing your foot become infested with gangrene. You don’t let it fester until it travels up your leg. You cut it off so that you don’t lose your entire leg in the process.
At the moment it’s a “non-issue” but the precedent has been set, there’s plenty of evidence showing what happens when you set the initial precedent. Ridding ourselves of systemd is like cutting the foot off before the gangrene spreads. It’s less work down the line when another component becomes the issue, it’s less work than having to deal with everything at once.
It also is about the precedent. Cutting it off means that you refuse to accept ANY infringement on your personal privacy and your ability to use the computer.
The better notion is that age-verification isn’t being shoved down your throat yet. I’m not going to sit around waiting to see what happens if I sit around.
1 Like
The problem with this precedent-based argument is that there is a ton of software that you would have to cut off out of spite if your actual threshold for not using software is ‘something that could potentially in the future be used to restrict my freedom is present’. Every modern browser (yes, even the fork you’re thinking of), for example. The major desktop environments. Most productivity applications, I suspect. You’re not demanding that those be ripped out of NixOS, I presume. So you really should ask yourself, why are you focused on the systemd piece?
Gangrene spreads by itself, and can’t be removed once it takes hold. Age verification logic has neither property. A programmer has to add it, and once added, we can patch it out. It’s a terrible metaphor for communicating anything about the situation other than that it frightens you.
Fight the laws. The laws are bad and if they get worse, they will have real negative consequences instead of potential negative consequences. Fighting systemd is making a symbolic scapegoat out of the wrong target.
8 Likes