OP is certainly right that a lot of this legislation is written in ways that are hard to interpret and that often seem like they would have undesirable side effects even under the assumption that the basic idea is good (whether that's actually true is a whole different question).
In the specific case of CA AB1043: (1) Systems are required to ask the user for their age and just trust whatever they say (2) Applications are required to query the system for the user's age range. Other enacted and proposed device-based age assurance mandates have different properties.
I think this legislation is as dumb as everyone else does, but it also seems like the cheapest way for everyone to agree that we did something about the moral panic without actually giving up anything. It doesn’t do anything with ID or privacy or even actual verification. There’s no complicated auth dance to do with government services to verify our age tokens or whatever the latest Rube Goldberg machine “zero knowledge” age check proposal is.
I’ve been shocked at how many HN comments always come out in favor of age related legislation and heavy government regulation when the topic comes up. The pro-regulation commenters always seem to assume the age checks would never apply to them because they don’t have use TikTok or Facebook or other services, yet few realize that there aren’t going to be laws written in a way that only apply to a couple named companies you don’t use anyway. If we age verification laws then they’re going to be everywhere.
I personally hope this legislation dies and we can be done with this silly exercise, but if we’re stuck with age verification moral panic than a simple OS-level switch that we set once and then forget about seems like the least intrusive form of “age verification” we can get away with.
I think the writing has both intentions. Both implicate companies to comply as well for the mass to not defend. If it was not, there wouldn't be a guy on TV saying that there are 5000 possible pedo cases that are not being investigated and that's why they need it.
Anyone with more than 2 brain cells can put it together
> I personally hope this legislation dies and we can be done with this silly exercise, but if we’re stuck with age verification moral panic than a simple OS-level switch that we set once and then forget about seems like the least intrusive form of “age verification” we can get away with.
Just for clarification. CA AB1043 was signed back in 2025 and takes effect January 1 2027.
I disagree with your overall sentiment that this is benign because it's ineffectual in its current state. If anything, this is going to warm people up to the idea of government mandated prompts gathering personal information in their OS, and legislators in 2030 (or whenever) are going to say: "this isn't working, lets build on top of that prompt we already have and make it verify IDs"
In other words, I think this first bit of legislation had to be watered down to not receive too much backlash. This is the governments first plunge into mandating things on the frontend.
You're on the right path, but the "something" politicians want to do is specifically "regulate Facebook's patent harms to children". Facebook's counter-argument is: "we don't have a legally ironclad way to check user age, it should be Apple and Google's job". So the politicians want to write a law to make it Apple and Google's job to check age.
In other words, all of these age verification laws are here predominantly to indemnify Facebook from a growing wave of child endangerment lawsuits in a way that will ensure Facebook doesn't have to kick off even a single teen from their platforms. That's why the "verification" is just a date and an age range bucket.
My personal opinion is that these laws are stupid, but not harmful to Linux users, and that everyone angry at systemd for complying is shooting the wrong guy. Your real target is Facebook and you should be yelling at your local representative to make this bill not target Linux distros.
No, we can also be mad at the systemd guys for their very mid attempt at complying with an idiotic and unenforceable law, when the default of doing nothing was objectively the best option for them AND their end users.
> Systems are required to ask the user for their age and just trust whatever they say
If you're going to do anything like this, this is the thing they actually get right. It removes the inconvenience, privacy invasion, forced use of corporate verifiers with perverse incentives, etc. Meanwhile if the user is actually a child then their age is set by their parent.
> Applications are required to query the system for the user's age range.
This is classic legislative stupidity. Applications are required to query the user's age range even if they contain no age-restricted content? Brilliant.
>> Systems are required to ask the user for their age and just trust whatever they say
>
> This is the thing they actually get right. It removes the inconvenience, privacy invasion, forced use of corporate verifiers with perverse incentives, etc. Meanwhile if the user is actually a child then their age is set by their parent.
Well, maybe. For instance, if a child buys their own device they could
set the age to whatever they want.
>> Applications are required to query the system for the user's age range.
>
> This is classic legislative stupidity. Applications are required to query the user's age range even if they contain no age-restricted content? Brilliant.
Note that AB1043 doesn't actually impose much in the way of requirements about age restricted content. Rather, the way it works is that the developer is then assumed to have "actual knowledge" of the user's age (See 1798.501(b)(2)(A)) and then has to behave accordingly in other age-restricted contexts.
> For instance, if a child buys their own device they could set the age to whatever they want.
If a child has the money to buy a device without the parent knowing about it then they could just buy a used device that has already been configured with an account or pay a high school senior to set one up on their new device.
> Rather, the way it works is that the developer is then assumed to have "actual knowledge" of the user's age (See 1798.501(b)(2)(A)) and then has to behave accordingly in other age-restricted contexts.
How is mkdir or python3 supposed to "behave accordingly in other age-restricted contexts"? And if the answer is that its behavior is entirely unmodified, why is it required to do something without effect?
Also, who is the "developer" of a thirty year old project with thousands of contributors and multiple forks? All of them? None of them? The last one to make a commit, even if they're outside the jurisdiction?
> > For instance, if a child buys their own device they could set the age to whatever they want.
> If a child has the money to buy a device without the parent knowing about it then they could just buy a used device that has already been configured with an account or pay a high school senior to set one up on their new device.
Yes, agreed. I'm just describing how it works.
> > Rather, the way it works is that the developer is then assumed to have "actual knowledge" of the user's age (See 1798.501(b)(2)(A)) and then has to behave accordingly in other age-restricted contexts.
>How is mkdir or python3 supposed to "behave accordingly in other age-restricted contexts"? And if the answer is that its behavior is entirely unmodified, why is it required to do something without effect?
> Also, who is the "developer" of a thirty year old project with thousands of contributors and multiple forks? All of them? None of them? The last one to make a commit, even if they're outside the jurisdiction?
Then the law can make it illegal to sell smartphones or computers to 12 years olds or we could just ask the parents to do a bit of work and ensure their children is not buying devices behind their backs.
The idea is to make it easy for responsible parents to give a device to their children and make it easy for legal websites to block minors from adult content. We can't get perfect results but good enough could shut upo the complainers and maybe we get them do things like educating parents on how to proceed when they gift a device to a child.
People need to understand the difference between age indication and age verification. Two very different things. Age indication is a completely private and realistically as-effective alternative to the invasive age verification.
Age _indication_ means that when you set up your device or create a user account, you enter a date of birth for the user. The OS then provides a native API to return a user's age bracket (not full date-of-birth). If the user is a minor, the OS will require parental authentication in some way to modify the setting again. This can all be done completely offline. It works because parents almost always buy the devices used by children, and can enter the correct date-of-birth during setup.
Age _verification_ means that some online service has to verify your age, and collects a bunch of (meta)data in the process. This is highly problematic for privacy, security, and the open internet.
If I may nitpick, the conventional term for systems which attempt to determine the user's age is "age assurance". This covers a variety of techniques, which are typically broken down into:
* Age estimation, which is based on statistical models of some physical characteristic (e.g., facial age estimation).
* Age verification, which uses identity documents such as driver's licenses.
* Age inference, which tries to determine the user's age range from some identifier, e.g., by using your email address to see how old your account is.
These distinctions aren't perfect by any means, and it's not uncommon to see "age verification" used for all three of these together but more typically people are using "age assurance".
The issue though with "age indication" is that it creates an additional flag that can be used to fingerprint users. But it is infinitely preferable to any sort of age verification or age assurance.
It's interesting that the package managers become choke points that can be used for government overreach. Luckily Linux is open source so I expect there will be options that just don't do this from principle.
Otherwise my Intel NUC server with Debian is 2 years old, so I expect the honest age would be 2 years? I may have parts for some old PCs to put together that could get adult software I guess...
For me, the big issue is going to be mobile devices (phones, and tablets to a lesser degree)
I've already had it up to my back teeth with Google arbitrarily updating things such that the on/off button was hijacked, preventing me from switch the device off, instead triggering an interaction with freaking Gemini (what sort of IDIOT thought doing that to a device was a good idea)
I'm seriously trying to find a way to no longer run Apple or Google OS based phones - which puts me in the "Linux" or "Graphene" market
It seems incredibly silly to me that this is being rushed into systemd and other linux components. I understand Apple making changes, and even Canonical, but systemd is not run by one corporation and there is no reason to adhere to a badly written law. Why play along with the charade? If root is root, the "age verification" field does not make any sense.
Why are these changes being made on a worldwide basis when the laws that have been introduced are a relatively small fraction of the world? California isn't going to go after individual systemd maintainers. Will California go after Torvalds? I doubt it. Apple? Surely, but this is, quite frankly, a ridiculous thing to even suggest for inclusion into these setups.
Open source is driven by contributions. Most of the time, if someone wants a feature, implements the feature, and submits a reasonable PR to a project, that project will have the feature. In this case, the PR appears to have been written by someone who is not a regular SystemD contributor, and (through a bit of Googling) works for a FinTech company with no obvious interest. I can't comment on why that individual wanted to add support.
However, once someone added support, the question for SystemD is not if it is worth implementing, but if it is worth merging. At this point, it becomes a simple case of "the most intolerant wins". For people who care about complying with CA style laws, this feature is critical. For people who don't care, this feature is fine. I doubt it will even make it on mosts lists of SystemD feature bloat that most people don't care about.
This is the same reason a bunch of the food in your pantry is certified kosher. No one is going to not buy something because it is kosher. But if paying a thousand dollars a year to put a small circle-u symbol on the back of your box can increase sales by 1% among observant Jews, most companies are going to do it.
> No one is going to not buy something because it is kosher. But if paying a thousand dollars a year to put a small circle-u symbol on the back of your box can increase sales by 1% among observant Jews, most companies are going to do it.
Contrary to perceived politics, many Muslims will eat kosher food because it's a superset of halal rules (excl. alcohol).
It's a globally consolidated certification through organizations like the Orthodox Union. This is unlike halal which is local and has many scammers offering to pencil whip compliance. This means many Muslims will prefer kosher to "halal" food to avoid due diligence on the certification agency.
To tie this into age-verification, companies and ecosystems will use the strictest method that makes them globally compliant. Consumers will prefer that convenience even in the presence of intense political beliefs.
A bank that uses seamless OS-level age checks everywhere will win against one asking manually in the jurisdictions it isn't required.
I hope everyone’s bank knows how old they are— what with all the documentation we have to cough up to keep us safe from Terrorism , patriot act, 9/11, never forget, etc
Two corporations, e.g. Canonical and Red Hat, might suffice.
I hope everybody remembers how systemd was thrust upon the community by having Gnome largely depend on it. This was mostly done by efforts of Red Hat, and that sufficed.
California has both vendors and clients that are big enough to warrant immediate compliance. A very measurable chunk of Linux is from corporations, most major advancements are corporate backed in some way.
the simple fact you sending the same signal over and over again, with all other signals your browser send, it will be another key to make you apart.
They don't care if you lie. Important that you lie the same story every time.
And after having your dob, who could easily be a flag if you are less than 18, they could easily request your name, or a document number, but I think it will be much better, it will have some ISP and/or Device ID.
It actually is more like a flag in most cases. Specifically, in the case of AB1043, you enter your age or your DOB but then the OS provides an age range (<13, 13-15, 16-17, 18+).
Also, while some bills do seem to require browsers to promulgate age data to websites (e.g., NY SB102A [0]), AB1043 does not. Rather, it requires the browser
to read the age range just like any other app, but does't say anything about providing it to sites.
This is a no win situation and I think systemd is making this change too early. But I have read that field is optional.
But my main concern with this is applications like Firefox will eventually require this systemd age specific field and a standard systemd function to call. That means this age field will need to be populated and thus locking out the *BSDs and non-systemd Linux.
If that happens, this makes the systemd critics 100% right, systemd is being forced upon all distros by various upstream applocations.
My gaming machines that I do not browse the web with have systemd (CachyOS) but my daily drivers do not. Should a website lock me out because I don't have some age API then in my view the problem has solved itself. The website has effectively blocked itself without me having to given the one and only correct way to age gate a site in my view is with the RTA header [1] that would trigger parental controls if optionally enabled on ones device. Every other path that involves exchanging data whether verified or not, anonymized or not can only lead to future evil shenanigans.
>But my main concern with this is applications like Firefox will eventually require this systemd age specific field and a standard systemd function to call. That means this age field will need to be populated and this locking out the *BSDs and non-systemd Linux.
The risk is real, and the solution is to move away from systemd now, not wait until it's too late. Whatever conveniences it brings over other init systems are certainly not enough to justify giving up online anonymity forever.
If these laws come in in their current form, it might be worth archiving ISOs like 9front because I'm sure at least one project will just close its doors
This is actually nuts. You can't even constantly implement "age verification" at the system level in a way that makes sense across world cultures.
The only sane way to do this is you were playing along with arbitrary legislative age-gaters would be to add a generic "additional user info" blob to the account fields, if it didn't already exist.
> Will my system believe me? And how about their system, whoever “they” are? If not, then what else will I need to do to prove my birth date and age? Who will check if root can’t be trusted? How will they check?
If they ever seize your computer, they can probably also tack on computer fraud charges
>This systemd change is absurdly overdiscussed. It's a field for a number, no verification, no enforcement for anything.
> And no, I do not accept the slippery slope fallacy.
aka:
$OBVIOUSLY_DUMB_OVERREACHING_EASILY_ABUSED_POLICY is absurdly overdiscussed. It's $ABSURDLY_REDUCTIONIST_VIEW. And no, I do not accept $HISTORICALY_VERY_LIKELY_OUTCOME fallacy.
OP is certainly right that a lot of this legislation is written in ways that are hard to interpret and that often seem like they would have undesirable side effects even under the assumption that the basic idea is good (whether that's actually true is a whole different question).
In the specific case of CA AB1043: (1) Systems are required to ask the user for their age and just trust whatever they say (2) Applications are required to query the system for the user's age range. Other enacted and proposed device-based age assurance mandates have different properties.
This post goes into quite a bit of detail about the various points of concern: https://educatedguesswork.org/posts/device-based-age-assuran...
I think this legislation is as dumb as everyone else does, but it also seems like the cheapest way for everyone to agree that we did something about the moral panic without actually giving up anything. It doesn’t do anything with ID or privacy or even actual verification. There’s no complicated auth dance to do with government services to verify our age tokens or whatever the latest Rube Goldberg machine “zero knowledge” age check proposal is.
I’ve been shocked at how many HN comments always come out in favor of age related legislation and heavy government regulation when the topic comes up. The pro-regulation commenters always seem to assume the age checks would never apply to them because they don’t have use TikTok or Facebook or other services, yet few realize that there aren’t going to be laws written in a way that only apply to a couple named companies you don’t use anyway. If we age verification laws then they’re going to be everywhere.
I personally hope this legislation dies and we can be done with this silly exercise, but if we’re stuck with age verification moral panic than a simple OS-level switch that we set once and then forget about seems like the least intrusive form of “age verification” we can get away with.
I think the writing has both intentions. Both implicate companies to comply as well for the mass to not defend. If it was not, there wouldn't be a guy on TV saying that there are 5000 possible pedo cases that are not being investigated and that's why they need it.
Anyone with more than 2 brain cells can put it together
> I personally hope this legislation dies and we can be done with this silly exercise, but if we’re stuck with age verification moral panic than a simple OS-level switch that we set once and then forget about seems like the least intrusive form of “age verification” we can get away with.
Just for clarification. CA AB1043 was signed back in 2025 and takes effect January 1 2027.
I disagree with your overall sentiment that this is benign because it's ineffectual in its current state. If anything, this is going to warm people up to the idea of government mandated prompts gathering personal information in their OS, and legislators in 2030 (or whenever) are going to say: "this isn't working, lets build on top of that prompt we already have and make it verify IDs"
In other words, I think this first bit of legislation had to be watered down to not receive too much backlash. This is the governments first plunge into mandating things on the frontend.
You're on the right path, but the "something" politicians want to do is specifically "regulate Facebook's patent harms to children". Facebook's counter-argument is: "we don't have a legally ironclad way to check user age, it should be Apple and Google's job". So the politicians want to write a law to make it Apple and Google's job to check age.
In other words, all of these age verification laws are here predominantly to indemnify Facebook from a growing wave of child endangerment lawsuits in a way that will ensure Facebook doesn't have to kick off even a single teen from their platforms. That's why the "verification" is just a date and an age range bucket.
My personal opinion is that these laws are stupid, but not harmful to Linux users, and that everyone angry at systemd for complying is shooting the wrong guy. Your real target is Facebook and you should be yelling at your local representative to make this bill not target Linux distros.
No, we can also be mad at the systemd guys for their very mid attempt at complying with an idiotic and unenforceable law, when the default of doing nothing was objectively the best option for them AND their end users.
> Systems are required to ask the user for their age and just trust whatever they say
If you're going to do anything like this, this is the thing they actually get right. It removes the inconvenience, privacy invasion, forced use of corporate verifiers with perverse incentives, etc. Meanwhile if the user is actually a child then their age is set by their parent.
> Applications are required to query the system for the user's age range.
This is classic legislative stupidity. Applications are required to query the user's age range even if they contain no age-restricted content? Brilliant.
>> Systems are required to ask the user for their age and just trust whatever they say > > This is the thing they actually get right. It removes the inconvenience, privacy invasion, forced use of corporate verifiers with perverse incentives, etc. Meanwhile if the user is actually a child then their age is set by their parent.
Well, maybe. For instance, if a child buys their own device they could set the age to whatever they want.
>> Applications are required to query the system for the user's age range. > > This is classic legislative stupidity. Applications are required to query the user's age range even if they contain no age-restricted content? Brilliant.
Note that AB1043 doesn't actually impose much in the way of requirements about age restricted content. Rather, the way it works is that the developer is then assumed to have "actual knowledge" of the user's age (See 1798.501(b)(2)(A)) and then has to behave accordingly in other age-restricted contexts.
> For instance, if a child buys their own device they could set the age to whatever they want.
If a child has the money to buy a device without the parent knowing about it then they could just buy a used device that has already been configured with an account or pay a high school senior to set one up on their new device.
> Rather, the way it works is that the developer is then assumed to have "actual knowledge" of the user's age (See 1798.501(b)(2)(A)) and then has to behave accordingly in other age-restricted contexts.
How is mkdir or python3 supposed to "behave accordingly in other age-restricted contexts"? And if the answer is that its behavior is entirely unmodified, why is it required to do something without effect?
Also, who is the "developer" of a thirty year old project with thousands of contributors and multiple forks? All of them? None of them? The last one to make a commit, even if they're outside the jurisdiction?
> > For instance, if a child buys their own device they could set the age to whatever they want.
> If a child has the money to buy a device without the parent knowing about it then they could just buy a used device that has already been configured with an account or pay a high school senior to set one up on their new device.
Yes, agreed. I'm just describing how it works.
> > Rather, the way it works is that the developer is then assumed to have "actual knowledge" of the user's age (See 1798.501(b)(2)(A)) and then has to behave accordingly in other age-restricted contexts.
>How is mkdir or python3 supposed to "behave accordingly in other age-restricted contexts"? And if the answer is that its behavior is entirely unmodified, why is it required to do something without effect?
I agree this is undesirable. See: https://educatedguesswork.org/posts/device-based-age-assuran...
> Also, who is the "developer" of a thirty year old project with thousands of contributors and multiple forks? All of them? None of them? The last one to make a commit, even if they're outside the jurisdiction?
This unspecified in the current text.
One could interpret the age verification operation must run for every command executed in interactive or non-interactive mode.
It sounds like you want to automate the invisible purposeless no-op. Is that allowed?
> For instance, if a child buys their own device
Then the law can make it illegal to sell smartphones or computers to 12 years olds or we could just ask the parents to do a bit of work and ensure their children is not buying devices behind their backs.
The idea is to make it easy for responsible parents to give a device to their children and make it easy for legal websites to block minors from adult content. We can't get perfect results but good enough could shut upo the complainers and maybe we get them do things like educating parents on how to proceed when they gift a device to a child.
People need to understand the difference between age indication and age verification. Two very different things. Age indication is a completely private and realistically as-effective alternative to the invasive age verification.
Age _indication_ means that when you set up your device or create a user account, you enter a date of birth for the user. The OS then provides a native API to return a user's age bracket (not full date-of-birth). If the user is a minor, the OS will require parental authentication in some way to modify the setting again. This can all be done completely offline. It works because parents almost always buy the devices used by children, and can enter the correct date-of-birth during setup.
Age _verification_ means that some online service has to verify your age, and collects a bunch of (meta)data in the process. This is highly problematic for privacy, security, and the open internet.
I like the term "age indication". Thank you.
If I may nitpick, the conventional term for systems which attempt to determine the user's age is "age assurance". This covers a variety of techniques, which are typically broken down into:
* Age estimation, which is based on statistical models of some physical characteristic (e.g., facial age estimation).
* Age verification, which uses identity documents such as driver's licenses.
* Age inference, which tries to determine the user's age range from some identifier, e.g., by using your email address to see how old your account is.
These distinctions aren't perfect by any means, and it's not uncommon to see "age verification" used for all three of these together but more typically people are using "age assurance".
The issue though with "age indication" is that it creates an additional flag that can be used to fingerprint users. But it is infinitely preferable to any sort of age verification or age assurance.
It's interesting that the package managers become choke points that can be used for government overreach. Luckily Linux is open source so I expect there will be options that just don't do this from principle.
Otherwise my Intel NUC server with Debian is 2 years old, so I expect the honest age would be 2 years? I may have parts for some old PCs to put together that could get adult software I guess...
For me, the big issue is going to be mobile devices (phones, and tablets to a lesser degree)
I've already had it up to my back teeth with Google arbitrarily updating things such that the on/off button was hijacked, preventing me from switch the device off, instead triggering an interaction with freaking Gemini (what sort of IDIOT thought doing that to a device was a good idea)
I'm seriously trying to find a way to no longer run Apple or Google OS based phones - which puts me in the "Linux" or "Graphene" market
Quite spooky imaging that apple might create by that a fully verified pii database for half of gen z and every coming gen users
It seems incredibly silly to me that this is being rushed into systemd and other linux components. I understand Apple making changes, and even Canonical, but systemd is not run by one corporation and there is no reason to adhere to a badly written law. Why play along with the charade? If root is root, the "age verification" field does not make any sense.
Why are these changes being made on a worldwide basis when the laws that have been introduced are a relatively small fraction of the world? California isn't going to go after individual systemd maintainers. Will California go after Torvalds? I doubt it. Apple? Surely, but this is, quite frankly, a ridiculous thing to even suggest for inclusion into these setups.
Open source is driven by contributions. Most of the time, if someone wants a feature, implements the feature, and submits a reasonable PR to a project, that project will have the feature. In this case, the PR appears to have been written by someone who is not a regular SystemD contributor, and (through a bit of Googling) works for a FinTech company with no obvious interest. I can't comment on why that individual wanted to add support. However, once someone added support, the question for SystemD is not if it is worth implementing, but if it is worth merging. At this point, it becomes a simple case of "the most intolerant wins". For people who care about complying with CA style laws, this feature is critical. For people who don't care, this feature is fine. I doubt it will even make it on mosts lists of SystemD feature bloat that most people don't care about.
This is the same reason a bunch of the food in your pantry is certified kosher. No one is going to not buy something because it is kosher. But if paying a thousand dollars a year to put a small circle-u symbol on the back of your box can increase sales by 1% among observant Jews, most companies are going to do it.
> No one is going to not buy something because it is kosher. But if paying a thousand dollars a year to put a small circle-u symbol on the back of your box can increase sales by 1% among observant Jews, most companies are going to do it.
Contrary to perceived politics, many Muslims will eat kosher food because it's a superset of halal rules (excl. alcohol).
It's a globally consolidated certification through organizations like the Orthodox Union. This is unlike halal which is local and has many scammers offering to pencil whip compliance. This means many Muslims will prefer kosher to "halal" food to avoid due diligence on the certification agency.
To tie this into age-verification, companies and ecosystems will use the strictest method that makes them globally compliant. Consumers will prefer that convenience even in the presence of intense political beliefs.
A bank that uses seamless OS-level age checks everywhere will win against one asking manually in the jurisdictions it isn't required.
I hope everyone’s bank knows how old they are— what with all the documentation we have to cough up to keep us safe from Terrorism , patriot act, 9/11, never forget, etc
> systemd is not run by one corporation
Two corporations, e.g. Canonical and Red Hat, might suffice.
I hope everybody remembers how systemd was thrust upon the community by having Gnome largely depend on it. This was mostly done by efforts of Red Hat, and that sufficed.
California has both vendors and clients that are big enough to warrant immediate compliance. A very measurable chunk of Linux is from corporations, most major advancements are corporate backed in some way.
IIRC all that's been done is a field has been added to store the user date of birth and a protocol that can be used to retrieve said date.
That's it.
NO, DO NOT COMPLY WITH FORCED SPEECH
Might seem harmless now but it won’t next time, and you will have already capitulated
I've been running NixOS for awhile, which is very firmly integrated with systemd.
I wonder if it's time to try something like sixos or Guix SD.
Artix (Arch) and MX Linux (Debian) are very nice
Oh I only use distros that are declarative like NixOS.
I've run Arch in the past and I liked it just fine, but they are ultimately different than how I like running my computer.
I think you miss the point (But who am I)
the simple fact you sending the same signal over and over again, with all other signals your browser send, it will be another key to make you apart. They don't care if you lie. Important that you lie the same story every time.
And after having your dob, who could easily be a flag if you are less than 18, they could easily request your name, or a document number, but I think it will be much better, it will have some ISP and/or Device ID.
It actually is more like a flag in most cases. Specifically, in the case of AB1043, you enter your age or your DOB but then the OS provides an age range (<13, 13-15, 16-17, 18+).
Also, while some bills do seem to require browsers to promulgate age data to websites (e.g., NY SB102A [0]), AB1043 does not. Rather, it requires the browser to read the age range just like any other app, but does't say anything about providing it to sites.
[0] https://www.nysenate.gov/legislation/bills/2025/S8102/amendm...
Carry permit to operate a compiler is in our near future.
Richard Stallman's "Right to Read" is worth reading again, because it portrays a very similar scenario.
This is a no win situation and I think systemd is making this change too early. But I have read that field is optional.
But my main concern with this is applications like Firefox will eventually require this systemd age specific field and a standard systemd function to call. That means this age field will need to be populated and thus locking out the *BSDs and non-systemd Linux.
If that happens, this makes the systemd critics 100% right, systemd is being forced upon all distros by various upstream applocations.
My gaming machines that I do not browse the web with have systemd (CachyOS) but my daily drivers do not. Should a website lock me out because I don't have some age API then in my view the problem has solved itself. The website has effectively blocked itself without me having to given the one and only correct way to age gate a site in my view is with the RTA header [1] that would trigger parental controls if optionally enabled on ones device. Every other path that involves exchanging data whether verified or not, anonymized or not can only lead to future evil shenanigans.
[1] - https://news.ycombinator.com/item?id=46152074
>But my main concern with this is applications like Firefox will eventually require this systemd age specific field and a standard systemd function to call. That means this age field will need to be populated and this locking out the *BSDs and non-systemd Linux.
The risk is real, and the solution is to move away from systemd now, not wait until it's too late. Whatever conveniences it brings over other init systems are certainly not enough to justify giving up online anonymity forever.
> Whatever conveniences it brings over other init systems
You see people rave about the greatness of systemd, then they turn to deploy their applications using Docker and some s6 config.
[dead]
Is 9front impacted?
If these laws come in in their current form, it might be worth archiving ISOs like 9front because I'm sure at least one project will just close its doors
The story reads like an april fool.
For root to manage privileges in an OS, isn't a group the most straitforward way?
Can't flatpak read the groups of an user?
This is actually nuts. You can't even constantly implement "age verification" at the system level in a way that makes sense across world cultures.
The only sane way to do this is you were playing along with arbitrary legislative age-gaters would be to add a generic "additional user info" blob to the account fields, if it didn't already exist.
Fellow software engineers, what are we doing here? Why are we letting the EU / UK define the future of software?
1. The UK and EU are rather large markets that they don’t want to miss out on.
2. There are software engineers in the UK and EU.
3. This specific implementation by Apple is not actually required by any UK or EU law, to my knowledge.
4. This specifically is or will be required by the laws of some US states and other countries.
Maybe carefully read TFA - the age verification came from a Californian law
> Will my system believe me? And how about their system, whoever “they” are? If not, then what else will I need to do to prove my birth date and age? Who will check if root can’t be trusted? How will they check?
If they ever seize your computer, they can probably also tack on computer fraud charges
[dead]
This systemd change is absurdly overdiscussed. It's a field for a number, no verification, no enforcement for anything.
And no, I do not accept the slippery slope fallacy.
Why does it exist?
Because some implementers will need or want to use it.
> And no, I do not accept the slippery slope fallacy.
Well, you can never delete this comment.
>This systemd change is absurdly overdiscussed. It's a field for a number, no verification, no enforcement for anything.
> And no, I do not accept the slippery slope fallacy.
aka:
$OBVIOUSLY_DUMB_OVERREACHING_EASILY_ABUSED_POLICY is absurdly overdiscussed. It's $ABSURDLY_REDUCTIONIST_VIEW. And no, I do not accept $HISTORICALY_VERY_LIKELY_OUTCOME fallacy.
[flagged]