A reasonable implementation of this would make the age field optional, and only set it on interactive user accounts. An app that requests the age field and gets no response grants access. i.e. it's not set up to restrict access unless a user is explicitly set up as a child, in which case you're obligated to deny access to sensitive content.

Just yesterday I finally got tired of all the browser security warnings and decided to buy a domain name and set up SSL in my local network. I spent like 10 minutes flummoxed by why my reverse proxy couldn't get a new cert from Let's Encrypt until I looked in the logs to see that Let's Encrypt refused because the account my reverse proxy had been using since I set it up had the email address as "admin@hostname" because this was all for my own personal use and my local reverse proxy doesn't need an actual email address, it just needed some value for some entry in some database.

This is my long-winded way of saying, "Who cares?" Give it whatever age you want. When people object to these type of initiatives for political reasons, they should state the political argument for why they are bad. But rebelling against them for practical technical reasons always seems a little silly to me and can end up being counterproductive when it shifts the conversation away from the central issue.

56 years and 81 days. If you get this reference I tip my hat.

useradd —-system flag shouldn’t ask for one

666 years. It's in the name :)

Just 01-01-1970 :)

We could set some sort of standard, eg using the <meta> tags on web pages to set an age bracket? (or better, include actual fine grained content warnings like PEGI provides?) , now the parents can control what the kid sees; or even the kids themselves at times, which is probably much closer to what is desirable.

Doesn't make much of a difference, the former is just slightly more privacy friendly than the latter. Which is preferable of course, but no big difference compared to reporting an age bracket to platforms.

I also don't see how it takes anything away, you could still set stricter policies with those tools, or more mild ones if you set the age to 18.

I would agree when it comes to the most basic real-world skills, but even then you cannot prohibit it. When it comes to digital skills, no, you cannot expect everyone to understand it. Even when it comes to GUI tools. It's just not realistic.

There's really a wide range between "not looking after kids" and "watching them every second." Unlike the physical world, digital items allow kids to transition from a totally safe space to an unsafe space within seconds.

For example, I can have my kid do whatever he wants in his room. I know what's in there and while he may have the occasional stupid idea, it's all fundamentally safe.

But even a tablet breaks that barrier. It's entirely safe for him to listen to music and stories and I want him to be able to do that unsupervised. But solid control over content on Spotify isn't a thing. The catalog contains things that I consider not appropriate for him. And they've lately been adding vidoes to the feed and while I know he tries hard to resist, they deliberately push videos further and further up. So we're back to "I can turn on the story for you and you can listen.", which is super stupid and could be much better if I had solid controls that I can trust.

Yes, I know I can talk to him about not watching the videos. How can an 8 year old compete with the combined effort of the Spotify team paid to make him watch videos? That's just not feasible.

Also a user account is not necessarily a person. Most of those on my machine, certainly aren't.

I'm on OpenBSD.

Seeing Linux drama at this point is just entertainment.

The inferior technology stack pushed by big tech and defended by people who know better has been something else.

You'll take my software freedom from my cold dead hands.

I think the init-replacement part of systemd is only a small part of the complaints.

The original rc-style sysvinit scripts of arch were neither brittle nor buggy. Everything could be configured with "rc.conf" and writing own services was dead simple. All of this was possible with many orders of magnitudes of less complexity.

It is a rejection of a revert.

From the comment closing the revert by Poettering:

>It's an optional field in the userdb JSON object. It's not a policy engine, not an API for apps. We just define the field, so that it's standardized iff people want to store the date there, but it's entirely optional.