back
70 comments
It rubs me the wrong way that the person opening this PR says "we have decided not to implement OS-level age attestation" when they seem to have no prior involvement with systemd, and it's clearly not their call to make.

I wouldn't go so far as to call it astroturfing, but it's the same thing that's irksome about anyone claiming to speak on behalf of a group they actually have no involvement in. Feels like someone trying to score cheap points.

Age verification through the OS could make parental control much easier. Just set the age of your child on a given system with your own account, and apps and websites can signal what the minimum age is, and then the OS can decide to block it or not. Could be very privacy friendly compared to the current online methods, like what Discord did.

Of course, I'm not in favour of actual verification of the age attribute. And I've heard the slippery slope arguments. But if I were a parent this would be great.

Problem with setting up parental controls currently is that it takes some effort and knowledge of these tools, not every parent has that. I mean, even people who do, are usually chaotic in the digital domain, like for example, (re-)using very bad passwords. So why expect people to do better with parental controls?

What age should I put for my daemon accounts?
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.

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.
56 years and 81 days. If you get this reference I tip my hat.
Just 01-01-1970 :)
666 years. It's in the name :)
useradd —-system flag shouldn’t ask for one
Sure, as something parents opt into and where the local OS is the place where age and content rating are compared it could be a useful parenting tool. As something that lets big social media companies shift responsibility onto everyone else and opens the door for more user tracking and targeted advertising, it's not doing me or my kids any favors.
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.
Legislating it in the OS takes power away from parental controls.

What you actually described, however, is websites and apps reporting information about their content to the OS. That would indeed give more power to parental controls. But what's being legislated is reporting age range to platforms.

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.

Sure, if it's not verified then parental controls could skip the feature entirely and still do whatever blocking they want as normal. This is a terrible argument that it doesn't take anything away from parental controls. It's literally pushing the decision away from parental controls onto the platforms and legislators, with an opinion that it should be based on specific buckets and content that have been legislated, and now parents and developers have to think about both the local blocking and remote blocking matrix.

Maybe I actually like the defaults for some age range blocking and want to make an exception. So, what, parental controls that would like to support this now must implement lying to each app or website individually?

You probably shouldn’t have kids if you’re not prepared to look after them.
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.
ban the selling or providing of general purpose computing to children. we can already do it with alcohol and cigarettes.

any parents caught providing such things to their children go on a register and have mandatory courses on parenting.

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.

If Spotify doesn't give you the controls you want... Don't use Spotify?

If my local park had a series of rotating knives and the council refused to do anything about it, I wouldn't let my kids go down there, supervised or not.

I agree parenting in the digital world is harder. You either learn how to do it to your standard or you don't allow the child to be part of that world if you are incapable or don't want to.

If anything, the POSIX passwd specification should be updated to include age instead of introducing yet another dependency on systemd for something that affects the entire ecosystem.
No, do not poison passwd, let systemd choke on this.
If you have to have age, then I agree /etc/passwd is the best place.

But that means a user's birth date will be public viewable, for some people that would be an issue. In my opinion. bdate should not be stored anywhere in Linux or any UNIX type system. Linux and the BSD should ignore these laws completely and we move on from this.

I still do no understand why the Linux Foundation is not chiming in. By keeping quiet all the LF is doing is reinforcing the perception that LF is fully owned by "Big Tech".

Also a user account is not necessarily a person. Most of those on my machine, certainly aren't.
GECOS fields are mandatory. You may just ignore them for your daemons.
In what cases are they mandatory? I've been leaving them blank for decades.
I don't know about the similar bills, but the California one only applies to the accounts of children.
FreeDOS has no accounts. Neither hasn't Haiku, nor Amiga. And any OS from 8 and 16 microcomputers with FPGA's have no concept of that either and if they can run Frotz they can for sure play Interstatal Zero, (I-0.z5), both in English and a faithful Spanish translation (Interstatal Cero). Oh, you are now able to run a 18+ game even under a PSP, a PDA, an old phone with no concept of accounts at all (J2ME interpreter), classic Mac's, a Post Script file and even FreeDOS.

Go try implementing accounts under FreeDOS or CP/M.

Now potentially a 18+ game can be showed to billions of native (and non-native) English speakers from nearly any OS sice 1979, even under a PostScript file (zmachine.ps), albeit it needs to be extended.

This law it's idiotic and it shows. Will they ban retrocomputing with Amiga OS 3.1 running on FPGA's or what? They can run the modern web with TLS 1.2/3 with AmiSSL. They can run IRC against Bitlbee and login into Steam, Jabber, Discord and Mastodon with relative ease. Gemini can access most JS-less webs at gemini://gemi.dev and Gopher clients for sure it might be some adult content referenced at gopher://magical.fish and gopher://sdf.org, even if it's just mildly NSFW, such as harsh language and sex references. The Javascript-less web, too. Usenet, more adult discussions and content, maybe with heated flame wars. And for sure they can run Frotz with that mentioned game game, at full speeds.

Systemd has gone from a technical cancer for Linux systems to a political one.

If only every major distribution didn't break backwards compatibility to play with the cool kids.

Time to get back to programs that do one thing and do it well.

Have fun debugging your brittle init scripts. All my systemd servers are working flawlessly, have done so for years, and will continue to do so.

The Linux ecosystem would be such a vastly more enjoyable place if you people would take all that energy you put into that petty fight over systemd into something productive.

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 already considered trying a BSD, but the GNU parts are the things I have no problem with and confound myself. So BSD might not be the answer, when it's the non-GNU parts of my GNU/Linux install that annoy me.
> The inferior technology stack

How so "inferior"? It's a proven techonology widely adopted by major linux distros that has been practical for everyone wanting to manage their system.

Give me your alternative of "superior" technology.

Trying to act superior with your oft-broken OS.

“Inferior technology stack”. Didn’t I just read a few days ago about pf queues just now breaking 4Gbps? Look me up, I’ve written a lot about high speed networking.

How are those containers working out for you? Have you heard about these things called VMs? Which I moved on from like 8 years ago?

Not to mention ole Theo likes to alienate you folks at every possible opportunity, even when it doesn’t matter to the core philosophy of openbsd.

I mean, you do you, but at least demonstrate an ounce of intellectual integrity about it.

9front user there. I don't care much for GnomeOS (flatpak+systemd+nonlibre Linux). I stopped caring long ago until Guix replaces that nonfree stuff with Hurd and does an actual modern clone instead of a crappy NT 2.0 with full of legacy stuff bolted in. Guix with Hurd and the rumpkernel porting all the libre Linux modules (ext2 has already been extended with something akin journaling; audio and networking drivers among Intel and MESA would be really great) would be a godsend for both Hurd and ironically GNU/Linux itself, as Hurd does far more for the user freedom, (no need for root to mount stuff and so on) as Plan9/9front does with namespaces.

As the so-called GNU+Linux libre software it's actually being drived by IBM and propietary modules, (the official tarball has already more blobs than GPL software) Guix and Hurd are the only non-trainted environments to develop non-corporate driven environments.

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.
They were absolutely brittle. sysvinit losing processes (it thinking a service is either dead or not incorrectly) is common
I think the init-replacement part of systemd is only a small part of the complaints.
Well said. systemd is against the UNIX philosophy and shouldn’t be the default.
sadly this is a revert. I wish they would go all in, and encourage everyone to move off.
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.

Richard Stallman stikes again about his statements on free and open systems. (With those you can fork and remove nonsense)
Poster failed to add that camelCase was obviously a bad call.
The "we have decided not to" in the initial post is weird. Was this somebody trying to, what, gaslight the maintainers into changing their mind?
It sounds weird because Claude wrote it
It would be a surprise to everyone if systemdb did the right thing.
Yep: they won’t.
While disappointing, Poettering is essentially a "wrong decision machine" so I don't know what anyone would expect.

And the author of the PR came in a little hot, which probably didn't help.