A thing that I do not like about the world we live in is that you're given two options, Windows where any application at any time can and usually will just demand you give it 100% permission to install stuff in the kernel and you really have no choice but to proceed because that's the only way to run the software, and Apple where you're not allowed to do anything with your devices ever at all.
@mcc You're forgetting the wonderful world of Linux distributions. Nowadays, there are a lot of distros user-friendly enough for people who want it to "just work" out of the box. Just as an example - I switched to Pop!_OS almost a year ago and never had any serious issues since then, and also don't have to deal with intrusive adds/permissions/updates and similar nonsense
The thing that I really want— every application is running inside of a sandbox I fully control, such that all attempted OS-level changes are accepted from the app's perspective but actually logged and tracked, and then I'm allowed pijul-style to decide which "patchsets" of sandboxes are simultaneously active for any one piece of software— might be kinda hard to implement and implement efficiently. But it seems some third option must be possible
Like, "the app developer has complete control and the user is powerless" versus "the OS vendor has complete control and the user and app developers are both powerless" versus the good condition, "the user has complete control and the OS vendor and app developer must do what they say".
(And no, Linux is not that third thing. Windows is the OS where 168989f.msi "wants to make changes to your device" and Linux is the OS where you're being asked to run curl 16989f.sh > sudo sh)
@aeva@uint8_t@mcc ugh, no. Not for lack of blundering into it though. Today’s spelunking was into Apache Guacamole and why nobody has upgraded beyond Java 8.
@mcc
I’ve wanted this too, and have thought about it. I pondered for a while a layered file system in which the user controls which layers are readable and writable by each app, and was halfway to implementing a nonsense version of Nix-in-the-OS before I decided this was not actually an easy problem.
@inthehands Did you know the original Mach, the experimental microkernel that gradually turned into Mac OS X, originally had a feature where userland program 1 could launch userland program 2 in a special way, and then from program 2's perspective program 1 was the kernel. Program 2 would think it's sending syscalls to the kernel but the syscalls are all going to program 1 and program 1 is allowed to freely decide whether to forward them on to the real kernel or just like… lie
Add comment