i frequently think about how much better off the world would be if UNIX was thrown away, and how Docker has stunted progress on throwing away UNIX by at least a decade
14
18
161
Conversation
Replying to
You realize I come at this from an opposite perspective: how much better off the world would be if everything gratuitously anti-posix were thrown away, and how much progress has been stunted by extra abstraction layers & shims pretending there's not already a portable target API.
1
1
8
Replying to
i don't really think we come at it from terribly different perspectives: we both want "POSIX, the good parts," and to get rid of legacy design.
1
4
the main difference i think is that i see POSIX as a starting point, but think that revisiting some design choices in POSIX is not a terrible thing. then again, dealing with the austin group standards process is quite tiring, so I can see why one might be hesitant
2
2
when I complain about "UNIX," I am complaining about "POSIX, as it is done *today*," not necessarily POSIX at large. basically, the question is, how do we revise POSIX to reduce legacy bloat?
1
3
for example -- the stuff Fuchsia is doing with capabilities instead of the traditional UNIX-style ACL is amazing, and we should want this to be in POSIX.
1
1
4
I've followed the whole "capabilities" thing for decades and never found any value in it besides "lets just pretend we're not root despite having complex interacting powers that are hard to reason about and almost always root-equivalent".
2
1
1
It's not at all the same kind of thing as *nix capabilities but rather FreeBSD Capsicum. It's an object capability system for associating rights with objects. It's not something bolted on to an existing system but rather what it's based around in the first place though.
1
1
6
fuchsia.dev/fuchsia-src/co is a nice overview of how file access works, which is just one example of a FIDL protocol implemented on top of object handles.
Namespaces are an inherent part of the basic way of using it. You simply make a little filesystem object out of other objects.
yep, in this way, you make use of namespacing, and that namespace is a tree of capability references. a large part of the problem is that OCAP people have their own vocabulary for things that we are already doing in various ways in real-world systems.
1
2
Part of the problem is that object caps are subtle. I also haven't been shown a second motivating "killer app" beyond solving the confused deputy problem (I've heard it's the only "decidable" privilege system but never had a chance to study this, I'm no more a 100% academic)
I skimmed through that and I love how they have some of the basic concepts from my vaporware kernel (fs being provided by a userspace process, only visible to procs attached to it) but then botched a lot to make that happen s.t. mmap is read-only. 🤦🤦🤦
3
yeah, your vaporware kernel design is very OCAP-style, actually :P
1