I understand that the new law in California () requires "an operating system provider or a covered application store" to provide age bracket data about users to 3rd party applications that request it. I also understand that many, or perhaps all, linux distros that are maintained by some entity(person, company, or non-profit) in the US will have to deal with this law in some fashion, whether that is to comply, EULA, or whatever they come up with.

What interests me in this is what happens when say an entity from Sweden, or Japan, or somewhere that is not the US, and does not have a corresponding, or similar, privacy law(looking at you UK), decides not to comply with this law. In a manner similar to say

The particular enforcement mechanism in this law is fines, which means that someone in California, likely the AG, but possibly some government agency tasked with doing this, will have to at least file paperwork, but also have to convince banks, courts, or foreign governments that they have jurisdiction to do this. A Swedish company might simply say, "We are not violating the laws of Sweden and are entitled to host whatever code we like on our servers." And it is hard to see how California really gets to do anything about that.

I am curious about people's thoughts and ideas regarding this, or simply a pointer to a place that has this information or discussion.

Can I request a sticky?

Can we start a list of Distros regarding new age laws.

Need to keep track of if and or how they are complying with new laws.

Maybe base distros at the top like Debian, Ubuntu, Fedora, Arch. Because if they go on-board then they're child Distros may be directly affected too.

Edit:

The hope is to consolidate info, opinions are opinions i just want info, and possibly to help clean up alot of posts.

Here's a link to the bill:

The bill is poorly written, impossible to fully implement and worse, it becomes the framework for a more robust surveillance infrastructure pretending to help kids, but really focused on your phone, your desktop, your laptop... Am I misreading this?

Here's a link to a direct letter to the authors of the bill:

Edit:
Here's a video about how devious this law actually is:

(Thanks )

If you use Spotify on Linux you've probably noticed the ugly blue Windows-style title bar that completely ignores your system theme. It's been broken for a while now and Spotify hasn't done anything about it.

There's an active submission on Spotify's own community voting page to get this fixed. The more upvotes it gets, the harder it is for them to ignore.

👉

Takes 2 seconds. Please upvote and share!

Now that California is pushing for operating system-level age verification, I think it's time to consider banning countries or places that implement this. It started in the UK with age ID requirements for websites, and after that, other EU countries began doing the same. Now, US states are following suit, and with California pushing age verification at the operating system level, I think it's going to go global if companies accept it.

If we don't resist this, the whole world will be negatively impacted.

What methods should be done to resist this? Sadly, the most effective method I see is banning states and countries from using your operating system, maybe by updating the license of the OS to not allow users from those specific places.

If this is not resisted hard we are fucked

this law currently dosent require id but it requires you to put in your age I woude argue that this is the first step they normalize then put id requierments

Several people asked me to do a deeper writeup after my earlier post. I went through the enrolled bill text, lobbying disclosures, and financial filings. This is the full picture.

What's happening as best I can figure out so far

Age verification bills have been introduced in 25+ US states. They look bipartisan and independent. They aren't. There are two model templates being distributed to state legislatures by outside groups, and when you compare the actual statutory language side by side, you find identical invented terminology, matching multi-clause definitions, and character-for-character duplicate passages.

One template is funded by Meta. The other applies to every operating system — including Linux.

The two templates

Template 1: "App Store Accountability Act" — requires app stores (Apple/Google) to verify user ages and share age data with developers. Active in Utah (signed), Texas (signed, blocked by court), Louisiana (signed), plus Alabama, Alaska, Arizona, Hawaii, Kansas, Kentucky, and a federal version. Sponsors are mostly Republicans. Pushed by the Digital Childhood Alliance, a coalition of 50+ groups. Meta funds it.

Template 2: "Digital Age Assurance Act" — requires operating system providers to collect age at account setup and send age signals to apps via API. Active in California (signed), Illinois (filed), Colorado (introduced), New York (introduced). Sponsors are mostly Democrats. Pushed by Common Sense Media. This is the one that explicitly covers all OS providers — including Linux distributions.

Both result in universal age verification infrastructure. The difference is who builds it.

The copy-paste evidence

I pulled enrolled text from Utah SB 142, Texas SB 2420, Louisiana HB 570, California AB 1043, and Illinois SB 3977. Details with verbatim quotes are in the comments, but here's the summary:

Template 1 (UT/TX/LA): All three use identical invented age categories — "child" (under 13), "younger teenager" (13-16), "older teenager" (16-18), "adult" (18+). These aren't existing legal terms. The definitions for "app store," "significant change," "verifiable parental consent," and "mobile device" are the same sentences between Utah and Louisiana, with Texas as a light rephrase. The safe harbor clause — developers aren't liable if they relied on app store age data — uses matching language in all three.

Template 2 (CA/IL): "Operating system provider," "signal," and the core mandate language are character-for-character identical between California and Illinois. IL SB 3977 is CA AB 1043 with different dates.

Why Meta is paying for Template 1

This is where it gets interesting. It's not about engineering costs.

Under COPPA, collecting data from kids under 13 without parental consent costs $53,088 per violation — but only when a company has "actual knowledge" a user is under 13. Meta claims it doesn't. But a 2023 complaint by 33 state Attorneys General documented over 1.1 million reports of under-13 Instagram users since 2019. Meta closed a small fraction of those accounts.

The math: 1.1M violations x $53,088 = ~$58B in theoretical penalties. ACT | The App Association, a trade group, .

For scale, Epic Games got fined $275M for COPPA violations with 34.3M daily users. Meta had 2.96 billion.

The App Store Accountability Act fixes this for Meta. Under ASAA, app stores verify age and send a "flag" to developers. Meta responds to the flag — they don't determine age. The safe harbor clause (Utah §13-75-402): developers are "not liable" if they "relied in good faith on age category data provided by an app store provider." Meta's "actual knowledge" shifts to Apple/Google. Their COPPA exposure gets neutralized.

ACT estimates this transfers ~$70B in compliance costs onto every other app developer in the ecosystem.

The money trail

The front group: In Feb 2025, to push ASAA. The founding member list includes the Heritage Foundation, the Institute for Family Studies, and the National Center on Sexual Exploitation (formerly Morality in Media). The DCA's board chair, Dawn Hawkins, is also CEO of NCOSE. The DCA is registered as a 501(c)(4) — a structure that is not required to disclose donors. During a Louisiana Senate hearing, Sen. Jay Morris . She confirmed tech companies pay but refused to name them. : Meta is one of those funders.

The lobbying numbers:

• — all-time record, more than Snapchat, Apple, Microsoft, and Nvidia combined

• on child safety/privacy bills

• since 2009 across 63 quarterly filings

• on payroll (up from 65 in 2024), firms in 45 of 50 states

• 12 lobbyists in Louisiana, 13 in Texas, 14 in Ohio — all states with ASAA bills

• Meta of the Utah and Louisiana laws

• Meta lobbied against KOSA and the STOP CSAM Act — bills that put responsibility on platforms

Named lobbyists from Q3 filings: John Branscome and Christopher Herndon (both former Chief Counsel, Senate Commerce Committee), Sonia Kaur Gill (former Senior Counsel, Senate Judiciary). 40+ external firms retained.

A federal ASAA was introduced by Sen. Mike Lee (R-UT) and Rep. John James (R-MI).

Why Linux users should care

California AB 1043 and Illinois SB 3977 define "operating system provider" as "a person or entity that develops, licenses, or controls the operating system software on a computer, mobile device, or any other general purpose computing device." That covers Canonical, Red Hat, the Linux Foundation, Valve (SteamOS), and arguably anyone distributing a Linux ISO.

These bills require OS providers to collect age at account setup and provide age signals to applications via API. For Linux, that means someone has to build age verification into the OS account creation flow — and expose an API that apps can query for the user's age bracket.

The Texas version was on First Amendment grounds. The But California's law is already signed and takes effect in 2027.

TL;DR

Two model bills are being distributed to state legislatures. One (App Store Accountability Act) shifts age verification from Meta to Apple/Google, neutralizing Meta's ~$50B COPPA exposure. Meta funds the coalition distributing it, spent a record $26.2M lobbying in 2025, and has lobbyists in 45 states. The other (Digital Age Assurance Act) requires all OS providers — including Linux — to build age verification into account setup. The bill text across states contains identical invented terminology and copy-pasted passages. Evidence and verbatim bill quotes in comments below.

Detailed evidence with verbatim bill text comparisons, lobbying filings, and additional sources in the comment chain below.

I've been using Linux distros exclusively on my computers the last 10+ yearrs, work and play. I thought I knew, but really, I did not know how good I had it.

There was an emergency last week where I had to buy a new laptop asap just so I could get work done .This sub's rules (I read them) reedirected me to Linux noobs. Fair. Yet I think my perspective, rather than just a problem, is to be heard here.

It was such a tizzy, honestly, with my like 3+ long term gigs on the line, I got some cheapass laptop so I could get work done for a few weeks, give it away/sell it in on after, never thinking, oh this is not complicated.

I ASSUMED - things were like (or better) they had been 5 or so years before when I got my previous laptop.

Long story now short: Are you, non-support people here, aware that Microsoft/OEMs are making it more diffiult than ever (in my long experience) for "budget" users to switch to Linux? I sure was not.

This asshat of a machine came preinstalled with Windows 11 ("Home")! I don't know how to get rid of itt. I knew it in 2013. I don't now now.

My Ubuntu USB won't boot, there's not even an option in bios to change boot order. When I switched off "secure boot" or whatever that's called, something called BITLOCKER, refused to recognize my Ubuntu USB, and asked for a 48-number digit ID from Windows. just to proceed???

All I want is to wipe this poison off this machine for my own sake and for the sake of who I give it to next. The point of my post being - How in the world will any actual noob, even try to do any of this? They won't, imo.

Of course I'll figure it out. But I'm - just shocked honestly..I can't see the average user getting a laptop with all these NEW hurdles to get rid of whatever preinstalled OS is, and have the right to use that hardware any way they want.

I had not been exposed to Windows in over a d3cade and it's such a - culture shock now I guess. Going from full control of my system, to MCAFEE in system tray. I'm just - disgusted.

I was thinking that most distros are just a compilation of different software. What if we do a Linux From Scratch, and distros change to just being installation scripts or lists of software components and configuration files?

With that model, there is nothing to enforce because there is no OS, the same way that you if you buy a motor, some tires a bike frame and build your own bike, there is no manufacturer that has to ensure the bike passes any safety standards. And as an added point, if the bill requires users of OS' to report their age to the OS manufacturers, under this model you are the OS manufacturer, so just report your age to yourself.

Edit

I didn't know anything about the state of the bills or what they said before posting this, so now I went and check for other post like this on and found the following that are very insightful:

I maintain the open-source SC0710 Linux driver — the community project that brings Elgato 4K60 Pro MK.2 support to modern kernels. While working on that project I found something that needs to be out in the open.

Yuan High-Tech, the ODM manufacturer behind the Elgato 4K60 Pro MK.2, distributes a compiled Linux kernel module called LXV4L2D_SC0710.ko. When you run modinfo on it, the first thing it tells you is license: GPL. That's not a choice they made — they had to declare GPL to access kernel symbols via EXPORT_SYMBOL_GPL(). The module literally cannot load on a modern kernel without that declaration. Fine. Except GPLv2 Section 3 means that the second you distribute a GPL binary, you're legally obligated to provide the source code to anyone who asks.

So I asked. On January 25, 2026 I emailed Yuan requesting the source for Build V1432 (compiled January 7, 2026). Their response? They wanted photos of my hardware and asked where I was from. When I pointed out that neither of those things have anything to do with GPL compliance, they stopped responding. I then escalated to Corsair's legal team — Yuan's North American distributor — outlining their shared liability. Complete silence.

The modinfo proof and email chains are here:

Now here's where it gets more interesting. The full alias table from modinfo shows the driver doesn't just support Yuan's SC0710 chip (12AB:0710) — it also aliases 13 Techwell/Intersil device IDs (1797:5864, 1797:6801 through 1797:6817). Those exact chip IDs have had open-source GPL drivers in the mainline Linux kernel since 2016 (tw5864, tw686x, tw68). Whether Yuan derived their driver from those mainline drivers or from Intersil's own SDK is something that requires binary analysis — but either way the closed-source distribution is indefensible, and the SFC now has the binary to investigate.

This also isn't just a streamer problem. This exact driver is being shipped in:

- 7StarLake AV710-X4 and NV200-2LGS16 — MIL-STD-810H certified military computers used in defense and intelligent automation

- JMC Systems SC710N4 — industrial HDMI 2.0 capture cards sold with explicit Linux support

Defense contractors are deploying undisclosed, closed-source kernel modules on production hardware. That's the actual scope of this.

Update: I submitted a formal compliance report to the Software Freedom Conservancy. They have already requested the binary and I've provided it. This is now an active enforcement process, not just a Reddit post.

For anyone saying the 4K60 Pro MK.2 being EOL changes anything — Yuan compiled Build V1432 on January 7, 2026, eight months after EOL. They're still distributing it. And GPLv2's 3-year written offer clause requires the offer to have been made at the time of distribution — Yuan never made one at all, not in 2022, not now.

Evidence:

Disclaimer: I used AI to help with formatting and writing clarity. The research, technical findings, and evidence are entirely my own work.

I'm a recent convert. I never took the plunge because I was too lazy, among other things.

I'm glad I switched for the most part.

I wanted to come here and express my gratitude to all the developers that are writing the software we use.

Without you, I'd be up a creek. You spend your time and effort creating programs we need to make Linux a viable system.

I don't have the skill (or likely the intelligence) to write software, so I rely on others to do it for me.

I just wanted to let you know you're appreciated, thanks for all your hard work.

I’m running Linux Mint on my HP Zbook Studio G7 laptop with Nvidia Quadro T1000. I just hooked up my PreSonus Studio 68c and searched for drivers. Surprisingly, my audio interface “just worked” without having to install any additional drivers. Gotta love Linux lol. But I noticed that the 590 Nvidia drivers are available (I’ve been using 580). It never notified me to update the driver though, which I thought was a bit odd. I did a quick google search and read that there were several issues with the 590 driver when it was released and it was recommended to stick to 580 for stability until they fix it. Just curious if the issues have been addressed yet, as I have PS3 and Nintendo Switch emulation, and local AI, running on my laptop beautifully and I don’t wanna screw it up. But if it’s stable and there’s performance to be had with a newer stable driver, I’ll update it.

Anyone thinking about putting Linux on the new Mac? As of now, I think Ubuntu is supported. I run Ubuntu in a VM on a Mac.
The price and specs look interesting.
I guess I have to keep adding words to get to 200 characters. High School?

It's written in a scheme/lisp called "guile", and configured using the same

(no, it isn't that complicated to configure, just a bit less pleasing compared to INI but nevertheless simple... scripting is complex but configs are simple)

Anyways, the advantages are the usual blah blah: powerful scripting, loading extensions, safer because it's not raw C code, and no scope creep.

Additionally, IF there is scope creep, it will be cleanly separated thanks to how guile works. You could easily use a shepherd-resolved (that is, of course, if the interpreter is efficient; I guess it is pretty much) without requiring shepherd as PID-1.

IF there ever comes a TPM library to be used in guile, systemd's TPM tools could be re-implemented (not that TPM too has it's own privacy concerns among the paranoid)

Pretty much the ONLY thing in shepherd not in systemd-INIT (the most basic build without bells and whistles like networkd blah blah) is well-indexed logging... And hopefully someone will come up with it once it gains traction (maybe me myself)

Another thing I am planning to write is an "extension" for shepherd, which supports systemd-like cgroup hierarchies (NOTE: "extension", i.e. loading a separate script INTO the same process, so it's pretty separable yet integrated)

Same thing applies for ALL of systemd's provided facilities. I guess the only reason nothing was done is "it's already there" and systemd-specific interfaces.

Things like sysexts can be written in SHELL scripts! Guile even better. tmpfiles is already re-implemented multiple times in bash (though also dropped due to further changes and incompatibilities)

PS I know systemd has done many good things, am not against it. But shepherd seems to provide a lot more.

DESIPTE HAVING NO SOILD BACKING, any logical mind gets some anxiety seeing a m$ employee developing a major component in linux, especially when the designing patterns resemble windows philosophies and ideas,

whether it's arbitrary scoping, excessive emphasis on "vendor OS images blah blah", and the mAsSiVe problem of signing ever silly component tamper-proof, and the mAsSiVe drive to sign and lockdown every component, make everything "pure".

I keep seeing people saying ID for age verification isn't a thing. It is a thing, and while the law is about app stores, and currently being blocked by the courts, Texas passes such a law last year. It's the same "protect the kids" mantra we are seeing with the OS laws in other states. If it gets past the courts other laws will follow.

Many groups and politicians have been pushing to do away with anonymity on the internet. I'll let you research that for yourself.

Texas App Store Accountability Act (SB 2420)
The Texas App Store Accountability Act, effective January 1, 2026, requires app stores like Apple’s App Store and Google Play to verify the age of users before allowing app downloads.  This applies to all apps, including weather, sports, and social media apps, not just adult content. 

• Age Verification: Users must be verified as under 13 (child), 13–15 (younger teenager), 16–17 (older teenager), or 18+ (adult) using a commercially reasonable method (e.g., ID scans, facial recognition, or third-party tools). 

• Parental Consent: For users under 18, parental consent is required for every app download, purchase, and in-app purchase—even free apps.  One-time or bundled consent is not allowed.

• Developer Obligations: App developers must use data from app stores to verify user age and ensure parental consent is obtained. They must also assign age ratings to apps and in-app purchases. 

• Enforcement: Violations may result in up to $10,000 per violation under Texas’s UDAAP law. The law is currently enjoined by a federal court, meaning enforcement is paused while legal challenges continue.

Hey ,

I've been building MailVault — a free, open-source desktop app that backs up your IMAP emails locally. It stores everything as standard .eml files on your machine, so your emails are safe even if your provider goes down or deletes them.

What's new in v2.0:

• Native Linux support (.deb packages for x86_64 and aarch64)

• Built with Rust + Tauri — lightweight, ~200 MB memory usage

• IMAP with CONDSTORE delta sync, COMPRESS=DEFLATE, connection pooling

• OAuth2 for Gmail and Microsoft (plus app passwords)

• Email threading, search, full offline access

• Maildir format — your data, no vendor lock-in

Download: Source:

Would love feedback from Linux users — this is the first Linux release so let me know if anything's off.

EDIT: For non-Americans, I am talking about this California law:

There's actually a very simple fix for the California law (probably too late) and the very similar Colorado bill (not yet too late).

This part:

(b) (1) A developer shall request a signal with respect to a particular user from an operating system provider or a covered application store when the application is downloaded and launched.

and the subsequent sections referring to "a developer" are the only problematic parts. First, because they require a developer (an actual person) to request the age-bracket signal rather than the application, and second because they apply to all applications. The fix is to reword it as follows:

(b) (1) An age-sensitive application shall request a signal with respect to a particular user from an operating system provider or a covered application store when the application is downloaded and launched.

We need one more definition:

An "age-sensitive application" is an application that, in the normal course of usage for which it was designed, can provide access to age-restricted material.

And finally, we change "developer" to "age-sensitive application" in the sections following the one I exerpted above.

So for example, a Web browser would be an age-sensitive application, but rsync and PostgreSQL would not.

Hi everyone!

I'm thrilled to announce that penguins-eggs, the console tool that allows you to remaster your system and generate redistributable live ISOs, has officially landed on RISC-V.

Specifically, it is now fully capable of operating on the Spacemit K1 chip. I've been testing it extensively on the MuseBook X1, and the results are solid. This opens up the possibility for the community to create customized, "ready-to-go" images for RISC-V laptops and boards.

What's new in this release:

• Broad OS Support: You can now remaster Bianbu OS, Debian Trixie, and the upcoming Ubuntu 26.04 directly on RISC-V hardware.

• FDT (Flattened Device Tree) Support: This was the missing piece. I've added full support for DTB files. You can specify the path to your Device Tree Blob, and eggs will ensure it's correctly included in the generated image so the hardware is properly recognized at boot.

Why this matters:

RISC-V is evolving fast, but "distro hopping" or creating customized appliances is still a bit more cumbersome than on x86. With penguins-eggs, you can configure your perfect RISC-V environment once, "egg" it, and share the image with others or use it as a backup/deployment base.

GitHub:
Documentation:

I'd love to hear your thoughts or if anyone else is experimenting with the MuseBook X1!

I do understand that issues with PRNG quality in glibc in particular and C standard library are widely known. But it was surprising for me that man page for rand actually contains incorrect quality assessment. Here is the citation:

The versions of rand() and srand() in the Linux C Library use the same random number generator as random(3) and srandom(3), so the lower-order bits should be as random as the higher-order bits. However, on older rand() implementations, and on current implementations on different systems, the lower-order bits are much less random than the higher-order bits. Do not use this function in applications intended to be portable when good randomness is needed. (Use random(3) instead.)"

Another citation:

The function rand_r() is supplied with a pointer to an unsigned int, to be used as state. This is a very small amount of state, so this function will be a weak pseudo-random generator. Try drand48_r(3) instead.

I've tried to test these functions without advanced frameworks, just by messing around with custom C code. Here is the code:

It is not nearly as complicated as TestU01 or PractRand, but it catches very serious issues with uniformity by custom modifications of birthday spacings and gap test. Such issues can cause flawed results in simulations. But man pages don't just silent about it, they include dangerous misinformation about the quality (that some of these functions are good). Why they cannot be accurate and just write something like: "Warning! This generator uses a deeply flawed algorithm that doesn't obey a uniform distribution. It is left only for compatibility reasons! All computations made by means of this function must be considered as invalid by default!" I see double standards: flawed implementation of sin in glibc will cause a scandal, flawed rand - is ok. Why?

I'm aware that the situation is still unfolding, and we don't quite know where things are going to settle. But, does anyone have a good sense for what a good mid-term or long-term plan might be? Is there a list of distros which are likely to be safe vs. ones that are aggressively adopting? (eg: Ubuntu seems to be one to avoid) Do we have any sense for whether we'd be able to restrict per-app access to the API? My wife is in Ubuntu, and I'd like to switch her this weekend, but I'm not sure if we know enough about the situation to pick another distro so soon.

Okay I get it personal computers have personal accounts. They are used by individuals. But what if I don't have a Personal Computer But a Workstation/Server with a server like Linux like Alma Linux, OpenSUSE etc? They aren't your usual distros. They are server things. Managed by company. How can a company have an Age? How can company be a User? Laws would be inapplicable. Will Cern machines also put in their age? No right? So why should servers.

So servers are free from this typa shi bcuz company isn't an individual which means they don't have an age to put in. This marks ServerOS as a separate from this Age Verification/ID grabbing bullshi.

Just had this genius bathroom idea. 🙂

Getting back to Linux after 20 years of Windows and macOS I usually find it less interruptive and often faster to just do file manipulation, move, rename rat, encrypt, edit, etc from a couple terminal windows.

Some tasks that have a readily accessible GUI path I leave to the desktop.

20 years ago I played with AIX and Linux, it seems that muscle memory lingers in the subconscious.

Microsoft's UEFI Secure Boot certificates expire in June 2026. Your motherboard manufacturer almost certainly hasn't updated their BIOS defaults. When those certs expire, your Secure Boot is going to break.

So I built , a bootable Buildroot image that audits and updates your UEFI Secure Boot variables (PK, KEK, db, dbx). Looking for feedback, testers, and people who enjoy living dangerously. Issues and PRs welcome. So far I have tested this on a couple machines, and it worked well enough to release as alpha.

The problem:

• Microsoft's certs in many machines' Secure Boot keystores expire in June 2026

• OEMs are largely not shipping BIOS updates with refreshed defaults, especially for older motherboards

• Many OEMs (especially for budget motherboards or small OEMs -- I'm looking at you MaxSun) are shipping BIOS with AMI default PK entries whose private keys have been leaked. In this scenario, you may appear to be in "Secure Boot" mode but still vulnerable to bootloader viruses.

• Manually updating PK/KEK/db/dbx is a nightmare of arcane efitools invocations, cert file type conversions, etc.

How to use it:

• Flash the image from the releases page to USB with Rufus, dd, or tool of your choice

• If you use BitLocker encryption in Windows, make sure you have your recovery key handy as resetting Secure Boot may trigger BitLocker recovery.

• Enter Secure Boot Setup Mode in your BIOS (removing your Platform Key).

• Boot the USB stick and log in as root (no password). Latest images will auto-login for you.

• sb-enema will tell you what's stale and if your machine is 2026 ready

• Optionally select the menu option to customize a name for your certs if you're going to generate your own PK/KEK/DB entries.

• Select a menu option to start the process (strongly suggest just running #2 for "Full Colonic" or #3 for "Microsoft Colonic" for this release) and it will create/load in fresh certs.

• Note that "MS Colonic" option to use all MS certs has been tested and works but may be problematic on some firmware as it loads the PK unsigned. This process has worked on regular hardware but fails in QEMU for whatever reason.

What sb-enema does:

• Boots a minimal Linux image from USB

• Audits your current Secure Boot variable state

• Stages Secure Boot payloads and writes them with safety checks (Setup Mode preflight, per-variable preview before commit)

What is my recourse if this doesn't work?

• Just enter your BIOS and restore Secure Boot default entries, which will restore things to what they were before unless you've run a similar process yourself (and you would know if you have).

• On Windows you may need to re-run a Windows Update also to restore DBX entries that are routinely published by MS. But if you're in a situation where you need to run this utility, you probably aren't going to be worse off from just restoring defaults.

Should I trust this?

• All code is public on GitHub under

• The image is built on GitHub runners so the supply chain can be fully verified, including the MS certs which are pulled directly from Microsoft's repo.

• The build is using the latest buildroot (2026.02) and Linux Kernel version 6.19.5 with HW random support for improved entropy on cert creation for PK and user KEK.

This release is alpha quality -- please don't run this on your production server and then @ me. For the alpha release, I suggest just running the "Full Colonic", which will create new user PK, KEK, and DB entries (stored unencrypted on the USB drive) as well as load the Microsoft KEK entries, DB entries, and DBX. These are all sourced directly from Microsoft's repo at the latest tag v1.6.3.

Known Issues:

• MS PK enrollment mode ("Microsoft colonic") may not work on some firmware.

• The tool may also remove your motherboard vendor or OEM's certs, which may cause their custom boot utilities to break. Future version will try to persist these from the BIOS Secure Boot defaults.

• The tool will try to sign its own boot kernel so you can use it again after initializing Secure Boot, but this is probably broken right now as EFI partition isn't auto-mounting. If you mount the EFI partition on /efi it should try to do this so you can boot the USB Key even in regular Secure Boot mode after updating, which may be useful for refreshing your MS certs or DBX later on.

• The cert private keys generated for PK, user KEK, and user DB entries will be stored unencrypted on the USB device. Please back them up encrypted if you care to use them again for signing your own kernels. If you're only ever going to use Microsoft-signed / SHIM kernels or boot Windows, you may not care about this at all and can simply wipe the image and private keys.

• Although I've used Linux for 30+ years, my bash programming is trash and AI was heavily involved in the creation of this utility.

TL;DR: Your Secure Boot certs are expiring -- flash this utility to a USB drive and give your UEFI a colonic before things get impacted in June 2026.

I get that the bill states a fine will be issued per effected child but who would they fine with Linux?

Since Linux is open source and owned by the community there isn't one singular person they can fine. Maybe they'll try and go after Linus but he only technically owns the name Linux.

Would they go after every single person that contributed to the kernel instead? Or is the plan for them to go after the more "semi closed" distros instead since there's a company to hold accountable?

I really don't see this working out the way CA plans for it to and I'm glad it hopefully won't.

, also known as the Child and Adolescent Digital Statute, requires Operating Systems and Application Stores to:

1. Implement means to assess the age or age group of its user

2. Allow parents or legal guardians to configure parental controls and to supervise, in an active manner, a child's access to applications and content

3. Allow, by the means of a secure and private Application Programming Interface (API), the provisioning of age verification signals to internet application providers

This is a broader law that regulates a lot of things related to the protection of children and adolescents in digital environments. Including social networks, loot boxes, data privacy, age verification, gambling, advertising, etc...

Here is more info about the other effects of this law:

Edit: The Law stipulates a fine of 10% of last year's revenue or, absent revenue, between R$10 (~$2) and R$1000 (~$200) per registered user, with a limit of R$50.000.000 (~ 10 Million dollars) per infraction

Or at least, I think so, since the two serve basically identical roles. You get dumped into a prompt on login, where you can execute commands immediately, which you need to know how to do because it's the standard UI of Linux. If you want to do more complex things, it can also be used as a basic (ha) and somewhat jank programming language, although it's slower than a "real" language because it's interpreted and not compiled. If you want to interface with your computer's hardware, you can do it

The only major difference between the two that I can think of if that BASIC is a programming language that happens to work pretty well as a UI, while Bash is a UI that happens to work pretty well as a programming language. Beyond that, I think that Bash is the closest thing we have to a modern BASIC equivalent!

Hello ,

I have open-sourced a new project called MachineState. It is a standalone, single-binary Linux system state reporter designed to run without background agents or external dependencies.

Development Process: Specs to Code

The primary motivation for this project was an experiment in AI-driven development. I created strict markdown specifications (spec/) for the system state reporter and fed them into Claude Opus. The goal was to have the AI generate the exact same functionality from scratch in two very different languages: Go and Zig.

This provided an opportunity to compare both the AI's ability to handle different languages based on identical requirements, and the final performance of the generated code.

Go and Zig Implementations: The Results

Both implementations output identical data formats (ANSI Terminal, standalone HTML, Markdown, and streaming JSONL) but differ in their internal architecture:

• Go Version: Built using the gopsutil library. It handles concurrency well and results in an ~11 MiB binary with a ~4.0ms startup time.

• Zig Version: Built using std.posix for manual /proc and /sys parsing. It utilizes an arena allocator for memory management, resulting in a ~4.6 MiB binary with a ~0.79ms startup time.

Configuration for thresholds (like RAM usage, CPU load, and disk/inode limits) is handled via a single ~/.config/MachineState/config.yaml file.

Native MCP Server Integration

MachineState operates not only as a standard CLI but also includes a built-in Model Context Protocol (MCP) server (--mcp).

This allows you to connect the binary directly back into AI development tools like Claude Code via an stdio transport. The MCP integration provides LLMs with 14 distinct endpoints to autonomously query your system data when you ask it debugging questions.

Tools exposed to the AI include:

• get_docker_info: Checks container states and scans for dangling images.

• get_gpu_info: Directly interacts with nvidia-smi and rocm-smi, or falls back to lspci.

• get_log_info: Analyzes journalctl for kernel panics, OOM events, and segfaults.

• get_issues: A heuristic engine that flags problems like >90% inode usage or load averages that are critically high relative to the machine's specific CPU core count.

GitHub Repository: