I love tmux. I don't think this is a replacement for it. At most, for `screen`. I use tmux locally for my day to day work. I have different named sessions for different things I'm doing (switching back and forth) and I have multiple windows and panes. The best thing is that I can switch terminal emulators without having to learn any new keyboard shortcuts.
Show HN: Shpool, a Lightweight Tmux Alternative
161–170 of 201 posts
Re: Show HN: Shpool, a Lightweight Tmux Alternative
#162This is awesome! I hate the way tmux hijacks so much of my terminal's behavior (scrollback, seaching with escape-/, etc.) and I've been looking for something like this that will manage persistent sessions without any extra nonsense. BTW I think your readme shouldn't just characterize it as a resumeable ssh tool. I often need to start a long running process that I want to reconnect to later, or I want to put some alwa…
Do you know mobile shell (mosh)? [1] Seems like most of the features you need are what mosh offers. I've been using it for a decade, probably, and it is pretty awesome for latent mobile connections (read as: throttled 2G @16kBit/s with interruptions). https://github.com/mobile-shell/mosh
https://www.youtube.com/watch?v=XsIxNYl0oyU
> If you want to have 10 concurrent connections, you have to open 10 ports.
That is a problem in most environments.
Re: Show HN: Shpool, a Lightweight Tmux Alternative
#163screen is lightwight tmux alternative
Re: Show HN: Shpool, a Lightweight Tmux Alternative
#164Re: Show HN: Shpool, a Lightweight Tmux Alternative
#165Earlier quoted context omitted.
I think you would love zellij[1]. Go check it out, it is awesome. 1: https://zellij.dev/
I just started using this and it is indeed awesome. Only thing I need to figure out how to do is make a tab truly full screen. It's much nicer, more intuitive, has more built in support for things and is super lightweight. It's great.
The most fullscreen it can do:
- CTRL-p, f (regular fullscreen)
- CTRL-p, z (zoom/remove borders)
Re: Show HN: Shpool, a Lightweight Tmux Alternative
#166Earlier quoted context omitted.
Rust executables generally compile to static binaries. No you don't need to install Rust on the server, just compile once locally and copy the binary.
That is exactly the problem. Debian prefers the dynamic linking approach, where libraries can be updated individually. The problem usually comes down to having all the cargo dependencies packaged inside the debian repo. Which is doable, a similar thing happens for pip and other tools. But still kinda messy
I'm confused why that's a problem. Just because Debian prefers dynamic linking doesn't mean it's incapable of running static binaries.
Re: Show HN: Shpool, a Lightweight Tmux Alternative
#167This seems to suffer the same problem as abduco, which is, you better be reconnecting from the same terminal (don't change your termcap). Fine if working from a single machine. I did notice they have a vt100 emulator, but it's only used for screen restore? It seems the focus of the tool is for reconnecting from the same machine.
Yeah reconnecting from different terminals is a pretty tricky problem to solve (and in fact can't be solved in general because of potential skew between the terminfo db on the client machine and the remote machine). The big problem is that once you launch a shell, there is no great way to change environment variables from outside that shell, so you can't change the value of TERM for a running shell. I have thought about trying some LD_PRELOAD tricks to try to be able to call setenv() from within the shell process itself, but this always struck me as something that would require a pretty big hack.
Re: Show HN: Shpool, a Lightweight Tmux Alternative
#168Earlier quoted context omitted.
On that front: I've been using wezterm which includes a built-in tmux+mosh functionality, and it works quite well. It gives you first-class scroll/copy/paste management and multi-windows, plus session re-attachment. Probably 50% of my use of my mac is just SSHing in to my Linux box, and wezterm works great for that.
Last I tried there’s 2 major limitations, one is that the version on both ends has to be compatible, another is that it seems the wezterm at the host must be available in the system default PATH. This makes it hard to adapt to arbitrary remote systems that you have limited control of. Tmux+mosh doesn’t have these limitations (well I’m sure the mosh client and server must be compatible to each other but given it is so…
Yes, the versions between client and server do need to be in lock-step. As far as needing to be in the system default path, I haven't run into that: when I initially started using it, I had dropped the executable into ~/bin and that seemed to work (that is in my shell path).
Re: Show HN: Shpool, a Lightweight Tmux Alternative
#169Not sure, if it's a bug, but it eats 1.4G memory after running find for a few seconds, detaching, re-attaching and running find again.
Active: active (running) since Fri 2024-06-14 19:26:55 +05; 27s ago
Invocation: d84b9281e0f64a798c4e555836815036
TriggeredBy: ● shpool.socket
Main PID: 3895609 (shpool)
Tasks: 15 (limit: 154377)
Memory: 1.4G (peak: 1.4G)
CPU: 6.566s
CGroup: /user.slice/user-1000.slice/user@1000.service/app.slice/shpool.service
├─3895609 /usr/local/bin/shpool daemon
├─3895629 -fish
├─3895719 systemctl --user status shpool
└─3895720 pagerRe: Show HN: Shpool, a Lightweight Tmux Alternative
#170Earlier quoted context omitted.
Last I tried there’s 2 major limitations, one is that the version on both ends has to be compatible, another is that it seems the wezterm at the host must be available in the system default PATH. This makes it hard to adapt to arbitrary remote systems that you have limited control of. Tmux+mosh doesn’t have these limitations (well I’m sure the mosh client and server must be compatible to each other but given it is so…
Yes, the versions between client and server do need to be in lock-step. As far as needing to be in the system default path, I haven't run into that: when I initially started using it, I had dropped the executable into ~/bin and that seemed to work (that is in my shell path).
It depends how the rc files are initialized though. I remember last I check I couldn’t get it work on one system (that I don’t have control over those in /etc and those set in my home is not initialized at that stage.)
Mosh implemented a flag to include in the client side: —server=… which solves this problem.