> hasn't been an explicit goal for the Linux desktop (pushed esp by the Gnome/Fedora folks) to have applications run in a sandbox?
Yes, and the article's author forgot to tell you that their rant doesn't apply to applications running in a sandbox, as their D-Bus access is filtered.
D-Bus has no concept of generic services. People are using D-Bus to get automatic startup of generic services even though it's not fit for this purpose. It's quite a different thing.
You could build a viable solution on top of D-Bus though, it's just that apparently nobody bothered so far.
Just from the top of my head that I've noticed as a user: several apps, such as Dolphin or Yakuake, use konsolepart; KWrite uses katepart, and Ark uses various parts in its file preview.
While there is some valid criticism to be held against D-Bus and its implementations (there's more than one in common use), this article never goes there. It appears to be just an incoherent rambling of someone with poor understanding of how systems work together.
Not really - that would only be true if far right and far left were far apart in anything other than superficial rhetoric. The structure and operation of power are virtually the same for both.
Though why bother if you can just put it into a namespace? Containers can be much simpler than what all this Docker and Kubernetes shit around suggests.
Uhm, pardon my ignorance... but wouldn't restricting an AI agent in a development environment be just a matter of a well-placed systemd-nspawn call?...
That's not the only stuff you need to manage. Having a system level sandbox is all about limiting the physical scope (the term physical in terms of interacting with the system using shell and syscalls) of stuff that the LLM agent could reach, but what about the logical scope that it could reach too, before you pass it to the physical scope? e.g. git branch/commit, npm run build, kubectl apply, or psql to run scripts that truncate your sql table or delete the database. Those are not easily controllable since they are concrete with contextual details.
Sure, but at least we can slow down that fat finger by adding safeguards and clean boundaries check, with a LLM agent things are automated at much higher pace, and more "fat fingers" can be done simultaneously, then it will have cascading effect that is beyond repairable. This is why we don't just need physical limitation, but also logical limitation as well.
I rarely need to configure something on my PCs, but rarely is not never, and when I do really need an option, it better be there. There's a gradient between unmaintainable multidimensional matrices of options and "one size ought to fit everyone" and both ends of it make the user miserable.
I think when it comes to config too people really underestimate its power.
On desktop, I often see people waste inordinate amounts of time on workflows that don't suit their use case. Little do they know - there's a config for that!
For example, I'll see people holding outlook like it's radioactive. They'll do the same busy-body work of manually pruning their inbox and sorting stuff and deleting stuff. The config can really help them there, but I think they either don't know it's capabilities or are scared of it.
Yes, and the article's author forgot to tell you that their rant doesn't apply to applications running in a sandbox, as their D-Bus access is filtered.
reply