Spent a couple years essentially building exactly that at BlueRock. We had a partially formally verified microkernel that we would insert between the hardware and OS to intercept system calls. Under 10,000 lines of code by design, deployed in some very high-security environments.
Funnily enough we had to pivot to securing agentic AI (with a few pit stops along the way) because it was an extremely hard sell. We needed access to bare metal and the pitch to teams to allow us to do that was excedingly hard. Now, we've pretty much come full circle.
I believe AI could push people to look at securing Linux structurally but its hard for me to imagine they overcome the inertia we faced. Does bring up other interesting questions about AI-assisted formal verification, which even saying sounds weird. If you can verify a narrow slice of the call chain cheaply, you don't need to solve the whole kernel.
One more thing in regard to AI, the deployment model is shifting. Running agents on laptops is increasingly the wrong pattern. As they move to server infrastructure with real credentials and network access, the relevant security question changes too. Perimeter controls don't follow the workload, which is what's needed. The kernel approach addresses that but so does living/enforcing inside the execution itself.
Agreed on the floor being raised. The part I'd push back on is "fixing issues is now basically free." That's true for the issues that surface in code review or a failing test. The new class of issue is good-looking code that does something unexpected at runtime, usually through chains of tool calls that each looked fine in isolation. Those don't fail your tests. They fail in prod, sometimes quietly.
This is great! Love the idea. You should send to some art programs, sure they would get a kick out of it. Also gives another use case outside of just digital design.
Fair, had someone at a conference mention to me that he's working on crating agents with "beliefs". Sounds incredibly similar and quite frankly very spooky
Someone mentioned this previously in thread about how piracy (at least for sporting events) are a price issue. If they didn't charge an arm and a leg to watch (thinking of the NBA/NFL tv packages) they wouldn't have a problem.
I feel like this is always the case with new technology. People had the same reaction to the invention of the printing press. New is scary. It doesn't mean there aren't valid concerns, but unfortunately this feels a bit like an inevitability. The focus shouldn't be on stopping it, but how to maximize the gains and minimize the losses to the local communities where these are being built.
You're not doing your side any favors by using the printing press of all things as your comparison. People very legitimately don't want things like fracking in their area even IF it brings a boatload of jobs due to the costs on communities.
Datacenters might not be as potentially destructive, but they're also a massive net negative for the community in many real world ways. If you want them to "maximize gains", then the answer is "tax them more" which, shockingly, turns into a functional ban because somewhere else is taxing them less.
> Datacenters might not be as potentially destructive, but they're also a massive net negative for the community in many real world ways
No they aren't. Datacenters are air conditioned buildings that consume a moderate amount of power and generate a moderate amount of tax revenue through a small number of middle class jobs. They use a negligible amount of water compared to golf and farming and produce a negligible amount of heat compared to cars.
<<If I just paint everyone who doesn't want to support my shitty AI start-up as a stupid Luddite, I can ignore everything they're actually saying and just demand I be allowed to do the thing I want the way I want, where I want! The people living in these communities I have never and will never go to are just too stupid to know what's good for them.>>
Data centers are hardly new technology... For the longest time, people had no idea where the cloud was because the footprint was pretty small. It's another golden goose moment where everyone is going to build DCs and we might end up like in the dotcom bubble where way too much fiber was deployed for what was necessary at the time.
I weirdly feel like this is a newer issue. Hadn't had a problem running queries/actions previously up until this past month where it seems I'm constantly get hit with rate limits while not increasing my usage
The default model is Opus 1M context, so autocompact doesn't run as frequently, and that just Devours your session budget if you're not careful. There are some env variables you can (ask claude to) set to lower your max context window and autocompact threshold.
Funnily enough we had to pivot to securing agentic AI (with a few pit stops along the way) because it was an extremely hard sell. We needed access to bare metal and the pitch to teams to allow us to do that was excedingly hard. Now, we've pretty much come full circle.
I believe AI could push people to look at securing Linux structurally but its hard for me to imagine they overcome the inertia we faced. Does bring up other interesting questions about AI-assisted formal verification, which even saying sounds weird. If you can verify a narrow slice of the call chain cheaply, you don't need to solve the whole kernel.
One more thing in regard to AI, the deployment model is shifting. Running agents on laptops is increasingly the wrong pattern. As they move to server infrastructure with real credentials and network access, the relevant security question changes too. Perimeter controls don't follow the workload, which is what's needed. The kernel approach addresses that but so does living/enforcing inside the execution itself.