Unfortunately I have some bad news for you about random device drivers on linux. I guess with AI you can now fix the driver upstream yourself though.

You're then brining an entire MS tech stack from the mid 2000s just to achieve something that has been solved by virtualization with a lot less caveats a long time ago.

root/non-root split is almost entirely used as a "don't let people accidentally shoot themselves in the foot" mechanism these days. Like you don't want your point-of-sale operator to accidentally disable the network or mess up the firewall rules effectively bricking the machine. Requiring an IT person to make the trip to fix it for them. But you would never "trust" the separate user profile on that POS machine as something keeping a purposefully malicious employee out of a secure system. The entire machine, regardless of the user profile, is the same security context. The uid/gid concept is an antique from the 80s that stopped working a long time ago. It's just an organizational primitive now for the most part.

I remember the fun days of the 90s and early 2000s when there were shared machines that a ton of people would ssh or rdp into with different user account and "share compute". It was fun, but absolutely no bueno for a long time now.

Those “special workstations” are mostly about lack of features they view as potential attack vectors (external or internal motherboard ports, replaceable/non-soldered components, thunderbolt, anything extensible or “repairable”) and mandate certain hardware features (hardware tpm, locked secure boot, locked UEFI). Other than that, those workstations are Lenovo, Samsung, or Dell machines running typical chips. They may pick certain CPU models or chips but that’s mostly about avoiding new or “cool” features that may not have matured enough yet. Most of them are moving to thin clients though. Where you use that “special workstation” to remote into an VM that can access production systems. And that part is partially about controlling the software running in the VM and making sure updates can be forced “offline” on the VM even if you haven’t connected to it in few weeks.

[0] https://grapheneos.social/@GrapheneOS/116159602850585685

[1] https://www.reddit.com/r/GrapheneOS/comments/1rik0np/motorol...

I think I get what it's trying to say, but there is so much roundabout thinking.

Just say "Focus more on the user experience and trying to distinguish yourself from the frontier lab product you're trying to copy. Your users won't tolerate a clone-with-model-selector for too long"? I think

Does it? To me it seems reasonable for OpenAI to argue they did try to be careful evident by the sandbox, they just made a mistake. Almost every 0day is categorized by something like that. We haven’t had a long history of establishing a negligence charge to security bugs. Could you be sued because you didn’t demonstrate “carefulness” and used Linux which is not written in a memory safe language and has had multiple CVEs before? How complicated should the chain of an exploit be to demonstrate “carefulness” to the courts?

> training

OP was the one suggesting that training could be controlled because massive gpu clusters could be regulated the way a nuclear power plant could. If you assume training costs won’t drop, then it’s feasible I guess. However, unlike a nuclear reactor, the final training result isn’t a radio active material, but rather an ordinary file that anyone can load and use for inference.

Not to mention having no way to network isolate such service as every single service in every single network boundary needs to be able to contact such service, and every service needs (more or less) same auth permissions on all user accounts it’s running.

Again, solvable problems with enough code, but not simple problems by any means if you operate at a large scale.

Not necessarily, but it should probably inform that public policy. I think the problem is no one knows what the public policy should be assuming that scenario is true. Even if you, somehow, regulate away massive GPU cluster training making such future training impossible, existing models are already here. Further already training smaller models for things like images, speech, and other specialties is cheaper than the bigger models.

I agree that we need some regulations like everything else, but it’s not clear to me what the right policy should be. I think the European ai act is a fine start, but it’s clearly not enough nor does it necessarily limits the training portion just the application portion. Not to mention that the requirements there can be summarized into something like “you have to be careful, and show evidence you tried to be careful”.

Suddenly a database, a storage service or a computer service needs to be aware of the billing situations and make behavioral decisions based on the billing status. Again, not impossible, but something that suddenly promotes billing from an async/non-crucial background service that can be paused, replayed, adjusted by account teams etc, into a crucial hot-path service.

I don't think anyone would care about "hand made software", arguably no one ever did. You need a tool to do X. The enjoyment of the person producing that tool is entirely incidental. You don't care if the corn you're eating was hand picked by a person who loved manual farm labor or by a combine harvester. Just like you wouldn't care if someone enjoys driving a combine vs a self-driving combine nor if someone enjoys directing self-driving harvesters or if they are self-directing.

Further limiting the actual domains, URLs, and/or Methods a model can call on a given endpoint is also possible. It does get more complicated, but it is possible. It has the benefit of having these agents work with the actual services and tools everyone is using right now. Expecting every service to implement federated IAM permissions through an IdP like google or okta before a model can begin to use it is a losing battle. It’s like asking if the whole internet can change to fit a fine-grain access permissions.

Any system offering actual fine-grain access permissions (AWS IAM, Azure Entra, Google OAuth, even GitHub fine-grain tokens) is a pain in the ass to manage. You are then left with the “Connectors” companies that offer a proxy between you and the actual service you want to call with their own APIs and permission structure. Now you don’t call eBay APIs directly, you call a “Connector” that exposes a set of eBay functionality for you.

The scope of startup would be basically the “internet”. Just make sure you support the internet with a federated identity layer on top. It’s not impossible, and I’m pretty sure that’s Cloudflares current mission statement, but it’s hardly a simple task. If you want a fast go-to-market approach, you do the secret vault approach and piecemeal an http policy per scenario. They you can run the scenario in a “learning” mode, then come up with the list of allowed urls/domains/methods and deliver the thing. As opposed to (quite literally) re-writing the “internet”

In my experience the main hurdle was getting developers on the team onboard with go’s way. It felt like swimming upstream for my 6 year stint in go. I was in a very Java heavy “enterprise” but we were writing a kubernetes operator and I pushed to use golang because (a) I liked it, and (b) it was 2019 and the entire kubernetes ecosystem was primarily go.

To me golang was very simple and I drank Rob Pike’s and Google’s narrative of how easy it’s to get a competent “compute science major in college”-person to pick up go. What I experienced was a form of “you can’t teach an old dog new tricks”. Lazy (and I hate to use this word) developers who gotten so used to frameworks and IDEs doing all the heavy lifting for them in Java or C# had 0 appetite forgetting all the questionable patterns they learned over the years and adopt Go’s simplicity. It was very frustrating at time, yet gave me a good eye for the actual skilled talent in the organization vs the average enterprise developer persona.