- cross-posted to:
- privacy@lemmy.dbzer0.com
- cross-posted to:
- privacy@lemmy.dbzer0.com
The latest changes implemented in the Systemd repo, related to or prompted by age-verification laws, have made many people unhappy (I suppose links about this aren’t necessary). This has led to a surge in Systemd forks during the last days (“surge” because there have always been plenty of forks). Here are some forks that explicitly mention those changes as their reason for forking (rough time ordering taken from the fork page):
-
paramazo/systemd “The systemd System and Service Manager without age verification”
-
ganitam/systemd “Systemd fork just before the Age Verification addition. Hoping more capable developers and maintainers do same…”
-
GSYT-Productions/systemd-fork “The systemd System and Service Manager, without the stupid Age Verification”
-
speedythesnail/unret arded-systemd “The systemd System and Service Manager, without the ret arded age-verification commits”
-
ta13579/systemd “The systemd System and Service Manager WITHOUT THE FUCKING AGE CHECKS”
-
r4shsec/systemd-no-age-verification “This is systemd but without the age verification made via pull request https://github.com/systemd/systemd/pull/40978”
-
Pingasmaster/fightthesystemd “Systemd without the nonsense: no age verification, no lighthouse built-in.”
-
Jeffrey-Sardina/system “Liberated systemd – no surveillance. Ever.”
-
HaplessIdiot/systemd-saneagecheck “The systemd System and Service Manager with age verification bypass and polling rate options for said feature”
-
Queer-Coded-LGBTQ/systemd-fuck-california “The systemd System and Service Manager, but without age bs added in.”
-
Codiak540/unshitted-systemd “A fork of systemd aiming to strip the Age verification. Sue me california.”
Hopefully the energy of this reaction won’t be scattered among too many alternatives, although some amount of scattering is always good.
How do you see this depriving anybody of freedom? It’s an optional field. There’s no logic connected to it. Even if you were to put your date of birth into that optional field how do you see this technically connects with external consumers let alone for regulatory purposes?
You see that’s the inches part.
No, we won’t invade freedom
Well, we won’t invade freedom, but we’re just going to put this field in so that someone can comply easily if they want to
Well, not all the distros require you to log your age
Well, you can cheat or lie
History is absolutely full of people taking the temperature of the water they’re in and going, well, it’s not boiling yet…
The road to hell is paved with good intentions, yes. And I agree this could become a slippery slope towards enabling something we, as privacy concerned citizens, despise. It could also turn into enabling Linux as a solution for governments that require this. So from my PoV the question is whether it’s better that Linux will be prohibited for noncompliance or that SystemD enables a persistence layer for DoB to be used for yet to be clarified mechanisms? So far SystemD has been exceedingly good at designing this init system but maybe this is the exception and a wrong turn. I’m still curious to learn more arguments for exactly why they chose as they did.
That’s the same slope.
It it better that systemD add a column?
Is it better than ubuntu starts enforcing it?
Is it better that they just outlaw software that doesn’t comply?
For me, that line starts back at the very beginning. There’s no room for FOSS for Authoritarianism. I’m not interested in giving them a few inches of rope so that they can hang us with it later. If governments want to use Linux, they can, they can even fork it and make their own changes. They don’t get to demand how our own software tracks us.
You’re right. All PI data should be tokenised to ensure a proper abstraction between the user and their identity. And then a tool a bit like Flatseal to allow granular access to that data.
This feature isn’t depriving anyone of anything. Neither is the guillotine in my front yard. It hasn’t been used to decapitate anyone. It’s just sitting there in case it’s needed at some point in the future.
Oh, those cameras in the elementary school bathroom? Yeah, those aren’t actually hooked up. They don’t have any power, let alone a network connection to the security camera system we just ordered. Those cameras are there just in case they are needed later.
This date field is a Checkov Gun hanging on the wall in the first act.
So Lennart didn’t have a problem with systemd being prepared to comply with some local legislation , then refused the revert because “don’t bring this conversation here”. I am calling bullshit
He also didn’t have a problem working for Microsoft, like (as was reported to me) the two who merged this “feature”.
Yeah. I don’t know what all the fuss is about. It’s only the camel’s nose that’s in the tent. :P
Complying in advance.
It is not complying in advance, it is beeing prepared for when the law becomes active and binding.
“it’s not complying in advance! it’s just exactly what complying in advance is”
In advance of what? The law is already enacted, and the time until it gets active is exactly there for preparation and development.
It would be in advance if he had done it when the law was still in the plan phase, but that is way done.
the law is not enacted. even in your prior comment you said this was being prepared for when the law is active and binding. no one told SystemD they had to do this. they voluntarily complied with a state law in colorado and two state laws in draft phase in other states
Governor Gavin Newsom signed the California Digital Age Assurance Act (AB 1043) into law on October 13, 2025.
It is a valid law, it only has a postponed start date of January 2027 to give everyone time to get their Systems ready.
So… in advance.
Yes! That’s how compliance works. Otherwise it would be like “Excuse me for speeding officer. I’m going to adhere to the speed limit tomorrow. I promise!” Anyway, what’s your point ?