I believe there is a lot of room for TUI tools like this. Modern terminals and TUI libraries are advanced enough to support splits, colors, clicks etc.
Why run a 600mb electron app when a small TUI app will do just fine. Even if it’s a 30mb jar file that needs the jvm to run.
I also believe that constraints boost creativity and the fixed amount of rows/colums in a terminal and limited set of colors is great for that.
It’s not because some of these TUIs run full screen that they need to completely drop the unix philosophy. Apps like Mutt, Tig etc frequently delegate to $EDITOR, diff, w3m and others.
I love ncurses and I appreciate every moment I can do my work / some task with a super-fast TUI app instead of using one of these bloated electron-apps or web ui's.
I want to add:
* newsbeuter (rss aggregator)
* nmtui (network manager)
BTW I don't think that the constraints you are talking about just have to be constraints - I like to think of them as a measure to standardize software. Also the keybindings play a big role which is another feature of many unix tools I love ('e' for edit and 'q' for quit is just crystal-clear no matter where you come from).
> I also believe that constraints boost creativity and the fixed amount of rows/colums in a terminal and limited set of colors is great for that.
I agree and it's similar for web vs mobile apps. It would be great to come up with design constraints for web apps, but more like Jupyter where you have a way to mix text and graphics. Perhaps a web framework for creating admin tools that can include graphs?
Another favourite of mine is mpsyt – a terminal interface for youtube-dl. I stream music for hours without ever getting ads or even having to have Youtube open in the browser.
ncurses had its support written in September 1995. SysV4 curses had support earlier. I haven't been able to point exactly when xterm gained mouse support to send the data to terminal programs, but definitely before September 1995.
One oddity, not sure if I have just not read the docs enough - but if I start it within the directory of a docker-compose project, it comes up completely blank. But running outside that directory shows all my containers / services (including running images inside the docker-compose project).
They're more practical: ssh into the server. start the tool. [do your stuff]... close the tool. close ssh session.
With a web UI: ssh into the server. find out you want to check your containers statuses. ssh again while binding some local port to a remote port. start the web UI service. open a browser window. enter the URL. [do your stuff]... close the browser window. go back to the terminal. close the web service. close ssh session.
The WebUI port forwards can be made a bit more tolerable by using LocalForward in your ~/.ssh/config [1] assuming you're okay with the forwards being set up every time you log in. I agree that it's still clunky though; in-terminal tooling is generally preferable.
I tried that in a different context... The problem if you're managing many servers is that you'll have to setup a different local port for each server. When I needed it, I had to go check the .ssh/config each time to figure out which port was bound for this server. Did not save any time.
FWIW `DynamicForward` turns on a SOCKS5 proxy, so a dedicated Firefox profile[0] that has its proxy set to the dynamic forward port will be able to browse as if running on the remote machine. I believe remote DNS resolution, works, too. It still could clash ports if you have the same DynamicForward port for multiple ssh configs, but it can drastically reduce the number of port-collisions
0 = you are of course welcome to try running Chrome with `--proxy-server` et al, but I find Firefox a ton easier to use in that situation
I have an alias to a .sh script that launches Portainer (Docker web UI) on the remote host, sets up an SSH tunnel from the remote exposed portainer port to some <local port> and then launches my web browser at localhost:<local port>.
Instant remote Docker GUI. Really snappy too.
Web doesn't have to be slow and messy if you manage it right.
The Portainer UI could use some improvement but that's beside the point
I really wish there would be some easy way to make browsers talk http over stdin/out of a process. Port forwarding can be so messy, you need to allocate ports and multi-hop forwarding (eg bastion hosts) can be a problem etc.
Thanks :) As for TUIs vs web UIs, I believe so. The closer the UI is to the command line, the shorter the feedback loop and the more options for customisation. I'm someone who struggles to context switch so if I can do something without having to leave my terminal it helps keep me focused
yes, they are. For operation thing, console > web interface >> gui applications
Thou, there is 1 big advantage of web interfaces and that you can send a link to it to other person (that can make it better than console for some things).
I believe there is a lot of room for TUI tools like this. Modern terminals and TUI libraries are advanced enough to support splits, colors, clicks etc.
Why run a 600mb electron app when a small TUI app will do just fine. Even if it’s a 30mb jar file that needs the jvm to run.
I also believe that constraints boost creativity and the fixed amount of rows/colums in a terminal and limited set of colors is great for that.
It’s not because some of these TUIs run full screen that they need to completely drop the unix philosophy. Apps like Mutt, Tig etc frequently delegate to $EDITOR, diff, w3m and others.
Some of my favourite TUI apps:
* Tmux : windows/panes multiplexer
* Tig : git log/status/blame/stage
* Mutt : email
* Fzf : fuzzy finder
* Irssi : IRC