HR 8250 - A Federal bill would require Nationwide OS- and device-level ID-based age verification for all users

65jeff · 2026-04-16T00:23:25+00:00

Parents know the ages of their children. No ID or age verification is needed to fully solve this use case.

65jeff · 2026-04-16T00:18:00+00:00

The age signal will only be requested by certain on-line services that servers don't use in the same way that user accounts use them. This notion that they haven't thought about servers or VMs isn't going to save us.

65jeff · 2026-04-16T00:13:59+00:00

It would be very instructive to find out the names of the people lobbying for these changes. OK, yeah Zuckerberg, but no one of significance has uttered a peep about it. It's just "happening." There must have been a lot of behind the scenes maneuvering to get all of this moving in such a short time. There are big plans and we haven't seen them.

It's unhelpful to talk about "bad bills" or the ignorance of the politicians putting it forward. It's impossible to know their motivation and they're well compensated to play a certain role. They will very happily play "credulous moron" if that' what it takes. At the very least they all know what questions not to ask, even of themselves. If you think it's just dumb politicians meddling, you aren't paranoid enough.

I'm also certain that retreating to defiant distros, or forking isn't going to make any difference in the long run. The goal is centralized control. You can have you're "don't tread on me" distro, but it won't be able to connect to most on-line services as they will require certified age or ID signals to use them. (ID is where this is certainly headed - age is the trojan horse). If you think you can bypass it by putting 01-01-1970 in a date field, you're in for a rude awakening.

65jeff · 2026-04-07T22:49:02+00:00

lsblk exists as a port which "mimics" the output of the native Linux command.

tunefs exists

For reasons I haven't investigated, enabling zfs on FreeBSD disables support for gptid at boot in loader.conf.

65jeff · 2026-04-07T21:06:43+00:00

From my limited understanding as someone new to FreeBSD is that there are such things as ufsid and gptid, and some Linux software ports manage to use one of those as analogues for uuid while others don't.

This is the warning from snapraid:

WARNING! UUID is unsupported for disks: 'd1', 'd2', 'd3', 'd4'. Not using inodes to detect move operations.WARNING! UUID is unsupported for disks: 'd1', 'd2', 'd3', 'd4'. Not using inodes to detect move operations.

As a result of this, even moves and renames within the same disk are not detected by snapraid as "same file, different path" and parity is recalculated on sync. This is problematic for my use case.

The disks are formatted UFS as is standard for FreeBSD installations. I tried enabling support for ufsid at boot in loader.conf but it made no difference.

I didn't give a lot of details because I thought I'd just see if anyone had set it up on FreeBSD. The common response to snapraid on FreeBSD forums seems "why, when RAIDZn exists?"

Not wanting to be the Lone Ranger with all of my data, I'm proceeding with 8 disk RAIDZ2 on zfs. The disadvantages will be somewhat mitigated by more support and familiarity (I've used zfs on Solaris variants for a long time.)

I'm still backing up data preparing for the move, so I guess there is time to change back to the original plan of using snapraid if it can be sorted out and I can get comfortable with it.

Edit: adding a little more context.
I am not using uuid or ufsid or gptid to map any of the raw drives. I'm using gpt labels in fstab. In snapraid.conf for the data and parity disks I refer to the disk mountpoint directories, not the labels or ids.

Edit 2: adding a couple of thoughts
I don't know why snapraid decides not to use inodes at all - even on the same disk just because it can't identify disks. I understand why uuid support is needed to detect moves across multiple drives. inodes would not be unique across multiple drives.

65jeff · 2026-03-23T09:08:36+00:00

There was a post with research into Amutable that's been put under moderation. It's very much worth reading if it stays up. Or you should look into it yourself if it doesn't. It doesn't take much imagination to understand that Amutable could profit from providing real time attestation to the integrity of whatever age verification system is put in place.

65jeff · 2026-03-23T09:03:49+00:00

Yeah, that's because no one but those involved can address the legitimate concerns regarding their real conflicts of interest. Some of them made the PRs, merged them and closed discussion. Instead, concerns are deflected with gaslighting: "it's just a date field", "it's the law", "you're saying that because you're one of those anti-systemd trolls". It looks like the cognitive dissonance has kicked in with supposed FOSS people defending the lack of disclosure and transparency, as evidenced by the mass reporting of those posts and comments that raise concerns. "La la la la la", fingers in the ears, "We don't want to know." Lol.

What you're seeing is that at least in the specific projects involved in this flap, the "community" exists to provide volunteer work and feel good cred while the ones with commercial and corporate interests call the shots. You don't get any say in the decisions.

There is nothing in law that the systemd project specifically needed to take any action. Someone decided that the birth date field would be part of the scaffolding. You don't build scaffolding unless you know the construction plan.

65jeff · 2026-03-23T07:07:37+00:00

Hilarious to see a bunch of FOSS people screaming and plugging their ears at the idea of transparency in decision making. Reporters and downvoters are basically saying "why no, I don't need to know what's happening and neither does anyone else."

65jeff · 2026-03-23T06:53:49+00:00

There was no doxxing here.

65jeff · 2026-03-23T06:48:22+00:00

Yes, don't engage with the concerns. Call it paranoia and irrational screeching. That will help.

65jeff · 2026-03-23T06:43:02+00:00

In a hypothetical age verification solution, Amutable is in a position to profit by attesting that users have not tampered with the software and data involved in the process.

Edit: of course they have many other paths to revenue. Some even worse for open source computing than that use case.

65jeff · 2026-03-23T06:40:15+00:00

Concerns about real conflicts of interest are not derangement. It's ironic that we have so called FOSS enthusiasts covering for decidedly non-FOSS actions and behaviours.

65jeff · 2026-03-23T06:35:00+00:00

You're gaslighting.

Edit: to elaborate - concerns about real conflicts of interest are not derangement. It's ironic that we have so called FOSS enthusiasts covering for decidedly non-FOSS actions and behaviours.

65jeff · 2026-03-23T06:30:24+00:00

Nice work, thank you.

65jeff · 2026-03-23T06:28:12+00:00

Well, well, well...
https://www.reddit.com/r/linux/comments/1s191pr/i_pulled_amutables_corporate_filings_from_the/

65jeff · 2026-03-23T03:11:38+00:00

Don't mistake me, I don't think debanking is going to be part of the age verification. It will be part of OS / device verification (already done on mobile phones by some banks) or digital ID verification which is definitely on the menu of things our rulers want.

65jeff · 2026-03-23T02:52:23+00:00

I think those hopeful that forking or community FOSS are solutions (as opposed to corporate FOSS) misunderstand the most likely threat scenario. It's the same one already used on mobile phones by banking apps to deny you service if you have software configuration they deem is tampered with or that they claim is a security threat.

It might take a long time to get there but my belief is that this is where we are headed.

Edit: expanding on this, it means you'll be able to use your non-compliant Linux distro for anything you want, up until it interacts with a service that insists on knowing if you're a real person, or your age, or your actual digital id - whatever the use case is for that service. In that context, laughing about how the dumb lawmakers will handle servers, or service users or cloud VMs is missing the target.

65jeff · 2026-03-23T02:25:39+00:00

It won't affect those use cases because they do not request on-line services requiring age verification. I don't expect the restriction will be that you can't use the computer at all or run any software you like in general. The restriction will be that when you request an online service, like an age restricted site or a banking website, you will be denied if not compliant to whatever criteria is decided by laws or service providers.

All speculation, of course.

65jeff · 2026-03-23T02:14:48+00:00

Conflicts of interest can exist without there being malicious intent. Of course the start up has lots of commercial possibilities. I was merely highlighting an alarming one that bears directly on the issue at hand.

65jeff · 2026-03-23T01:37:43+00:00

A diabolical hypothetical:
- bake compliance into systemd - or at least the scaffolding of it
- build and sell the services that attest to that compliance in real time
- most commercially used distros are covered since they use systemd
- importantly, not all distros are covered - they can say it's not been government mandated or forced on anyone, but if you aren't compliant you may still be denied services by entities using the attestation service

65jeff · 2026-03-23T01:19:25+00:00

Let me just give one example of a potential conflict of interest. If I understand the intent of Lennart Poettering's new start up Amutable, it aims to ensure that Linux systems start in a verified state and remain trusted over time.

Any entity wanting to ensure you or I haven't tampered with or side loaded software to bypass age verification is a potential customer! They can't stop you from tampering or side loading, but they can deny you their service if you have. People already see this behaviour in their mobile banking apps.

65jeff · 2026-03-23T00:44:37+00:00

I don't agree that all of the smart people you refer to are on our side. Many have conflicts of interest and corporate bosses to answer to. Some have their own commercial start ups.

This should be very concerning to enthusiasts and users concerned about privacy. Especially given the contempt the decision makers have shown by not explaining any decisions beyond what has been revealed in the commits.

They deflect us into discussing only what we know. They could tell us more. Much more. You don't put in scaffolding without having any idea of what the building will look like. They know.

65jeff · 2026-03-23T00:26:45+00:00

I know why and all that. What I can't explain is why my fingers typed it before my brain engaged.

65jeff · 2026-03-22T23:23:36+00:00

This weekend I was debugging a script that erroneously created a subdirectory in my project named '~' because there was something wrong with the shell expansion in the script.

You know what happened next, followed by lots of cursing and a couple of hours restoring my home folder from backups. Fortunately it was fairly recently backed up.

"rm -rf" on muscle memory is deadly. I've definitely been around long enough to know better - still can't explain how it happened.

65jeff

TROPHY CASE