Eric SchultzMar 21

A small set of people are merging changes to various Linux components to make sure every application knows your birth date.

This is being done rapidly by people with questionable justifications and being merged with no youth and few marginalized people involved.

https://gitlab.freedesktop.org/accountsservice/accountsservice/-/merge_requests/176#0b07c0cc4d49be119f65cdb2037440f56eed647a

user: Add BirthDate with polkit-gated GetBirthDate and SetBirthDate methods (!176) · Merge requests · accountsservice / accountsservice · GitLab

Summary Add a BirthDate field to the user account interface. For non-homed users, the value is stored...

GitLab
Show threadk3ym𖺀Mar 21
@wwahammy wtf… these are current maintainers???
Show threadEric SchultzMar 21
@k3ym0 some are. systemd already merged a corresponding change from the same contributor.
Show threadk3ym𖺀Mar 21
@wwahammy can’t we fork it prior to that commit and maintain a separate fork?
Show threadEric SchultzMar 21

@k3ym0 could it be done theoretically? Sure. But on systemd, that'd be a huge task to maintain. And the systemd folks say "oh, this PR is just an optional part of the user account system, we're just making a common API for anyone who wants to add it for any reason".

They build the tracks and plead innocence as to what is in the trains.

Show threadLuke T. ShumakerMar 21

@wwahammy @k3ym0

So the age verification stuff is beyond terrible. But the systemd PR specifically seems like a weird one to get worked up about?

It does 2 things:
1) The schema-docs for the the userdb JSON, which already allows you to add arbitrary user-defined fields in addition to the pre-defined fields, now define an optional "birthDate" field to be to be a "YYYY-MM-DD" string.
2) Added a flag to `userdbctl` (edit: `homectl`, actually) to be able to set the field from that command, instead of having to edit the JSON some other way.

Like, I already deal with multi-user systems where "hobbies" is a field in there. I don't see the harm in saying "If you wanna add a birthDate field, it should be 'YYYY-MM-DD' and not seconds-since-epoch or something".

The polkit stuff? Makes my gut churn.

Show threadEric SchultzMar 21
@lukeshu @k3ym0 I don't think it's possible to separate them in the abstract. There is clearly a common intent and a belief that this doesn't work unless they're all merged.
Show threadLuke T. ShumakerMar 21

@wwahammy @k3ym0

So that's clearly (scumbag) Dylan M. Taylor's intent and belief. But I think it is valid to separate them for the purpose of evaluating folks-other-than-Dylan; I don't think bluca did anything wrong by merging it (nor poettering for lgtm'ing it). I don't think it's valid to say "welp, systemd added age verification, I have to switch to a non-systemd OS now to avoid age verification."[1] I think it's totally valid for bluca and poettering to look at the PR and think "the author's motivation is bad, but this specific change is fine."

"They build the tracks and plead innocence as to what is in the trains." I feel that way about a lot of stuff, but... this is even more removed than that? There's no policy engine. "They approved a standard for the width of train tracks."?

[1]: There are plenty of valid reasons to prefer other init systems, but I don't think "birthDate" showing up in a json schema is one of them.

Show threadLuke T. ShumakerMar 21

@wwahammy @k3ym0

As someone who was once noted on Wikipedia for maintaining a fork of systemd, I think this is a really silly reason for wanting to fork systemd.

Show threadEric Schultz
@lukeshu @k3ym0 I don't really see this as a case where forking would help anyways. The problem is that the default is supporting the system I oppose. If someone were to fork, which I agree would be kinda pointless anyways, that doesn't solve the original problem: soon, the default for the Linux desktop is for age-gating to be supported and that's bad.
Mar 21 at 5:49amWeb