Erin đ˝â¨Everyone seemingly getting mad about systemd adding a completely optional date of birth field to user records that is, in reality, only ever going to be filled in on the machines of children administered by parents who want such restrictions enforced, perhaps on machines administered by schools, or by people who want their computer to wish them a happy birthday.
Seachaint@erincandescent I don't think cute happy birthdays needed to be handled by systemd, and this is all done in the context of laws being pushed that would criminalise computer use without age verification. So I think now, and not later, is the reasonable time to push back on it.
@seachaint systemd maintains a standard for a user database format, because /etc/passwd is incredibly limited and lacking many fields you might want to store on a modern system.
It contains optional fields like a userâs e-mail address, âreal nameâ, or details like identifiers of security tokens they might wish to use to unlock their account.
In this case theyâre adding a definition of a dateOfBirth fields to a JSON map, and nothing more. In particular you will not find any particular age confirmation method here; itâs entirely up to self reporting by the system administrator(s)
John Ripley@erincandescent @seachaint The fact that this surfaces whatsoever in systemd, and not some other fully independent subsystem, is damning of the architectural choices in systemd.
@jripley @seachaint it could be in a separate package called userdbd and youâd be complaining that Lenartâs 30 interconnected packages were taking over the Linux system đ¤ˇ
Itâs not even actually a user database, itâs a replacement/alternative for the NSS interface that lets you query various properties of a user that multiple backends can plug into including several external backends (Iâve written my own! Itâs trivial!) and several backends that e.g. provide synthetic users inside the systemd package itself.
@erincandescent If there were in fact 30 interconnected packages, which were fully disentangled, optional, and independent, I think youâd address the central issue everyone has with it. And this age verification nonsense would be an independent thing (or part of one of the above, which could easily be forked) and there would have been zero controversy.
@jripley the thing is that these things canât be disentangled. One of the userdb backends is provided by pid1 itself, for example (to support the DynamicUser feature)
Itâs very difficult to disentangle these things because so many of the things systemd touches are cross-cutting concerns that affect the whole system, and the reason it keeps touching them is that having them historically spread across so many packages has ossified so they are stuck in the 70s
witch_t *navi@erincandescent @jripley
except it doesn't need deep bidirectional integration for DynamicUser to work, as rose's gardenerdb (a userdb freestanding implementation) shows: https://git.pinkro.se/Rose/gardenhouse/gardenerdb.git/tree/examples
openrc, s6, and runit examples for dynamically allocated users
except it doesn't need deep bidirectional integration for DynamicUser to work, as rose's gardenerdb (a userdb freestanding implementation) shows: https://git.pinkro.se/Rose/gardenhouse/gardenerdb.git/tree/examples
openrc, s6, and runit examples for dynamically allocated users
kasia 
@navi @jripley which is exactly an example of how you can just take the userdb interface and reimplement it.
I donât know what point youâre making. They could have implemented it in a separate project? Sure, at the cost of circular dependencies (systemd -> userdbd or at least the protocol definition -> libsystemd), or you split it into more projects and now youâre continually having to do commits across 7 separate repositories to implement simple features, bumping dependencies all the way.
You donât like the implementation choices, you can reimplement it. Heck Iâm pretty damn sure that systemd would work perfectly with gardnerdb (as long as you let pid1 itself provide the io.systemd.DynamicUsers service as it needs to do)
@erincandescent @jripley
> I donât know what point youâre making. They could have implemented it in a separate project? Sure, at the cost of circular dependencies (systemd -> userdbd or at least the protocol definition -> libsystemd),
yes, the only reason gardenerdb exists is because userdb can't be used without systemd, at least not without incredible effort and we're all seeing the mess that is elogind breaking all the time
libsystemd is another nightmare, that is basically 5-ish different libraries in one, that who knows if it can work without systemd as pid1
having to reimplement thing after thing for the only reason that the project pushing for those things is hostile to alternate ecosystem is not sustainable
> I donât know what point youâre making. They could have implemented it in a separate project? Sure, at the cost of circular dependencies (systemd -> userdbd or at least the protocol definition -> libsystemd),
yes, the only reason gardenerdb exists is because userdb can't be used without systemd, at least not without incredible effort and we're all seeing the mess that is elogind breaking all the time
libsystemd is another nightmare, that is basically 5-ish different libraries in one, that who knows if it can work without systemd as pid1
having to reimplement thing after thing for the only reason that the project pushing for those things is hostile to alternate ecosystem is not sustainable
@erincandescent @jripley
consolekit existed before logind pretty much killed it, and it has been revived by freebsd folks
smaller Wayland compositors brought us seatd to use over logind as well
if asking me, the only reason I can give to why there's no one else pushing so frequently for those large api refactorings, is because it takes a ton of effort and time, and not a lot of other projects had the power back then of a dozen or so full time red hat employees hired to work on such things
systemd could've benefited the whole unix ecosystem so much if they had cared to not be one huge self-referential system layer, but to work with the ecosystems, so it's forever sad to me that this is the path it went down
consolekit existed before logind pretty much killed it, and it has been revived by freebsd folks
smaller Wayland compositors brought us seatd to use over logind as well
if asking me, the only reason I can give to why there's no one else pushing so frequently for those large api refactorings, is because it takes a ton of effort and time, and not a lot of other projects had the power back then of a dozen or so full time red hat employees hired to work on such things
systemd could've benefited the whole unix ecosystem so much if they had cared to not be one huge self-referential system layer, but to work with the ecosystems, so it's forever sad to me that this is the path it went down
@navi Even âPoettering himself denied the pushâ is the failure of systemd in a nutshell. Large scale system design should be with an understanding that itâs always going to invoke Conwayâs Law. The choices made in systemd result in a single person having veto power. A better result would have been, âThe community largely rejected inclusion of this pluginâ. But thatâs not a thing that was ever a consideration, from the start.