Systemd already had its fair share of haters, but the emergence of 'Fake-ID' daemons that feed the OS and apps whatever 'biography' they're looking for is set to be the next big trend in software.
-
Systemd already had its fair share of haters, but the emergence of 'Fake-ID' daemons that feed the OS and apps whatever 'biography' they're looking for is set to be the next big trend in software.
-
Systemd already had its fair share of haters, but the emergence of 'Fake-ID' daemons that feed the OS and apps whatever 'biography' they're looking for is set to be the next big trend in software.
In systemd 260, nothing actually exists that could turn a computer into a IranOS. Essentially, just variables in userdb pointing to birth dates and a compatibility layer through a D-Bus API for age verification.
Currently, version 258 is installed on Fedora 43. Likely, 260 will arrive with Fedora 44. Not ruled out that GNOME might politely ask for a birth date during installation. Well, officially: plans are to become the oldest Rachel in the world. Born in 1800.
To turn this field into a real control tool, the system needs a Root of Trust. It must prove the date wasn't entered randomly but by an official body. Without ties to government digital signatures, crypto keys, or biometry — it's just a string of text in a local config, swappable with a single terminal command.
Besides, the community reacted instantly. The emergence of a systemd fork without this code is a direct signal: support will not happen. If distributions start forcing fields to be filled, they risk a massive user exodus to Devuan or custom builds.
Laws in Brazil and California demand verification but don't say how to do it in open software. Systemd developers simply rolled out an API to tell regulators: look, technical capability exists, law is not broken. Fake-ID daemons used for bypasses are not the OS developers' problem.
Classic paper tiger situation: law demands control, corporations paint a facade of control, while Linux users write a script that makes the facade... well, you get it.
-
In systemd 260, nothing actually exists that could turn a computer into a IranOS. Essentially, just variables in userdb pointing to birth dates and a compatibility layer through a D-Bus API for age verification.
Currently, version 258 is installed on Fedora 43. Likely, 260 will arrive with Fedora 44. Not ruled out that GNOME might politely ask for a birth date during installation. Well, officially: plans are to become the oldest Rachel in the world. Born in 1800.
To turn this field into a real control tool, the system needs a Root of Trust. It must prove the date wasn't entered randomly but by an official body. Without ties to government digital signatures, crypto keys, or biometry — it's just a string of text in a local config, swappable with a single terminal command.
Besides, the community reacted instantly. The emergence of a systemd fork without this code is a direct signal: support will not happen. If distributions start forcing fields to be filled, they risk a massive user exodus to Devuan or custom builds.
Laws in Brazil and California demand verification but don't say how to do it in open software. Systemd developers simply rolled out an API to tell regulators: look, technical capability exists, law is not broken. Fake-ID daemons used for bypasses are not the OS developers' problem.
Classic paper tiger situation: law demands control, corporations paint a facade of control, while Linux users write a script that makes the facade... well, you get it.
Well, there will almost always be a technical solution for a non-technical problem.
I think the key point is not about this specific field. The whole concern here is about the disturbing trend we see these days.
Let's make some subtle yet significant changes in your statements:
1. Essentially, **today it's** just variables in userdb pointing to birth **so far**
2. It must prove the date wasn't entered randomly but by an official body **and sooner or later, it'll become mandatory** -
Well, there will almost always be a technical solution for a non-technical problem.
I think the key point is not about this specific field. The whole concern here is about the disturbing trend we see these days.
Let's make some subtle yet significant changes in your statements:
1. Essentially, **today it's** just variables in userdb pointing to birth **so far**
2. It must prove the date wasn't entered randomly but by an official body **and sooner or later, it'll become mandatory**@alexanderniki There is always another solution. Sure, it might not be as smooth or convenient as Fedora. It could be something clunky and manual, like Arch. Convenience is great, but freedom is worth the extra effort. If Fedora gets too heavy on the surveillance side, it's just a matter of switching to something more raw.
-
R relay@relay.infosec.exchange shared this topic
