Comment by codethief
18 hours ago
People here are laughing of course but I do think there is a deeper truth behind this that's worth exploring:
> A Docker image is a piece of executable code that produces some output given some input.
The ideas behind containerization and sandboxing are rather closely related to functional programming and controlling side effects. If binaries always only read stdin and wrote to stdout, we wouldn't need sandboxes – they would be pure functions.
In the real world, though, binaries usually have side effects and I really wish we could control those in a more fine-grained manner. Ideally, binaries couldn't just do anything by default but actually had to declare all their side effects (i.e. accessing env variables, config, state, cache, logs, DBUS/Xserver/Wayland sockets, user data, shared libraries, system state, …), so that I could easily put them in a sandbox that's tailored to them.
Conversely, I'm waiting for the day when algebraic effects are so common in programming languages that I can safely execute an untrusted JavaScript function because I have tight control over what side effects it can trigger.
I'm sure that would work just like how phone apps asking for permission to do each thing has resulted in no phone user ever getting pwned and doxxed by their apps - phone apps are completely safe now, yay!
I think we're talking about fundamentally different things. :) You're talking about the UX of granting permissions, I'm talking about how permissions get implemented at the technical level, irrespective of how you arrived at them.
Surely your proposed solution is not "Don't implement a permission system to begin with"?
I too really want algebraic effects but the majority are panicans and exceptionauts. PL's will always cater to majority. We still don't have proper tail calls because the luddites want stack metaphors. Javanese & Gophers can't conceive of a world of pattern matching, sum types, and null/nil-safe code. Now we have machines writing code for us. It's over.