- Requiring people to write rulesets or explicitly list syscalls they want is complicated, so barely anyone will use it. We want it to be easy.
- tame is for OpenBSD. OpenBSD has many daemons that are already split up into sandboxes, often with common APIs (eg imsg) that use a small set of syscalls. tame will fit into and extend that. Often with relatively few source code changes so far, because we don't have to write lists of syscalls or much special processing. And if major changes are required - it is one project, we can change kernel and userland together.
- There has been no suggestion that I have heard that tame be considered a portable API, or something we would like others to adopt.
- Why not a library? Well, that was considered, but why not the kernel? There are advantages to both approaches.
- There is some talk of changing the way paths are handled, we will see where that goes. It is still early.
what do you mean session restore? we could restore the basic layout of sessions, windows, panes but we couldn't restore what was run in them (and it would be dangerous to try)
lots of people have contributed to tmux (on a quick grep through the logs, probably ~25 have made significant or multiple contributions, ~170 have made small contributions)
yes, this sucks but i have never myself been able to find a reliable case where screen reacts any better than tmux (for example, both behave similarly with yes(1))
the c0-* stuff is poor (i'm tempted to remove it) but it is not an easy problem to solve, people want tmux to be fast, except when they don't. it's also tricky remotely where ssh and the network stack are buffering too
it would probably be a relatively easy change to make this happen with key tables (which are in git), you would only need to change it so there is a way to permanently enter a key table (at the moment the key table is only entered until a command is run from it)
a couple of people have asked me about how true colour should look but none have sent code so far, it's not a very interesting feature to me so it'll need someone who cares about it to do it
- Requiring people to write rulesets or explicitly list syscalls they want is complicated, so barely anyone will use it. We want it to be easy.
- tame is for OpenBSD. OpenBSD has many daemons that are already split up into sandboxes, often with common APIs (eg imsg) that use a small set of syscalls. tame will fit into and extend that. Often with relatively few source code changes so far, because we don't have to write lists of syscalls or much special processing. And if major changes are required - it is one project, we can change kernel and userland together.
- There has been no suggestion that I have heard that tame be considered a portable API, or something we would like others to adopt.
- Why not a library? Well, that was considered, but why not the kernel? There are advantages to both approaches.
- There is some talk of changing the way paths are handled, we will see where that goes. It is still early.