> Zig doesn't have traits. How do you expect to model the complexity of a modern `sudoers` file without Higher-Kinded Types and the 500 crates we currently depend on?
> Also, `unsafe` in Rust is better than "trust me bro" in Zig. If you switch, the borrow checker gods will be angry.
That's a different flow control than what I'm talking about. tmux is just overwhelmed and cannot keep up with the output from tar whereas screen takes care of it and still responds to user input. Frankly I'm amazed there's only one or two posts about this on the internet as there's more than the pathological linux tarball extract where this problem will lock up tmux.
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
Some thoughts: VMs are an interesting case. Someone with the motive and means would have exploits to get out of the VM. This is probably easier if the guest is running something to accelerate (e.g. VMWare Tools / VirtualBox Guest Additions.) Once you get out, you have to account for the host OS. Assuming you could do it, how does one determine if the VM is part of a honeypot or the target?
Well, I was interested in actually testing it out in code. I got it working with the pyOpenSSL bindings (I had to expose struct ssl_method_st, SSL_get_ssl_method, ssl_write_bytes and rebuild cryptography for pyOpenSSL.) Fun times.
I know what you mean. I translated that to a python script a while ago for myself so I could stick it on other boxes without having to compile it. It's now a gist – https://gist.github.com/chirayuk/5377283
