Avatar

IAm_A_Complete_Idiot

IAm_A_Complete_Idiot@sh.itjust.works
Joined
0 posts • 69 comments
Direct message

Yep! You can also get pretty far even without containers. At the end of the day containers are just sandboxing using namespaces, and systemd can expose that pretty trivially for services, and tools like bubble wrap / flatpak let you do it for desktop apps. In an ideal world every package would only use the namespaces it needs, and stuff like this would largely not be a concern.

permalink
report
parent
reply

The idea is malware you installed would presumably run under your user account and have access. You could explicitly give it different UIDs or even containerize it to counteract that, but by default a process can access everything it’s UID can, which isn’t great. And even still to this day that’s how users execute a lot of processes.

Windows isn’t much better here, though.

permalink
report
parent
reply

Containers don’t typically have inits, your process is the init - so no extra processes are started for things other than what you care about.

permalink
report
parent
reply

The proper way to handle issues like these is process level permissions (i.e. capability systems), instead of user level. Linux CGroups, namespaces, etc. are already moving that way, and in effect that’s the way windows is trying to head too. (Windows has its own form of containerization called AppContainers, which UWP apps use. Windows also has its own capability system).

permalink
report
parent
reply

As a third party, my understanding is that both the implementation and the protocol are really hard, if not next to impossible to iterate on. Modern hardware doesn’t work like how it did when X did, and X assumes a lot of things that made sense in the 90s that don’t now. Despite that, we cram a square peg into the round hole and it mostly works - and as the peg becomes a worse shape we just cram it harder. At this point no one wants to keep working on X.

And I know your point is that it works and we don’t need too, but we do need too. New hardware needs to support X - at least the asahi guys found bugs in the X implementation that only exists on their hardware and no one who wants to fix them. Wayland and X are vastly different, because X doesn’t make sense in the modern day. It breaks things, and a lot of old assumptions aren’t true. That sucks, especially for app devs that rely on those assumptions. But keeping around X isn’t the solution - iterating on Wayland is. Adding protocols to different parts of the stack with proper permission models, moving different pieces of X to different parts of the stack, etc. are a long term viable strategy. Even if it is painful.

permalink
report
parent
reply

manpages aren’t guides though - they don’t help much in learning new tools, especially complicated ones. They’re comprehensive references, some can literally span hundreds of pages. Useful when you know what you’re doing and what you’re looking for, not great for learning new tools.

permalink
report
parent
reply

In which case the -a isn’t needed.

permalink
report
parent
reply

Better have not created any new files tho - git commit -a doesn’t catch those without an add first.

permalink
report
parent
reply

This is good for precisely the single user case - potentially malicious services on your system can’t view things they otherwise would be able to, or access resources they don’t need. Even if it’s under the same user.

permalink
report
parent
reply