[HN Gopher] Zellij New WASM Plugin System
___________________________________________________________________
Zellij New WASM Plugin System
Author : sbt567
Score : 135 points
Date : 2023-06-27 16:17 UTC (6 hours ago)
(HTM) web link (zellij.dev)
(TXT) w3m dump (zellij.dev)
| rychco wrote:
| This looks cool, I'll use it as an excuse to try zellij & writing
| some wasm.
| scarmig wrote:
| Hijacking this for a question I've been wondering about. For
| context, I'm a long-time tmux user who spends 90% of my time in
| remote shells.
|
| Ideally, I'd have my WM handle panes, layouts, etc. "Terminal
| multiplexing" seems to me to be misplacing client/UI concerns.
| Session persistence is the concern of the server, and
| multiplexing should be handled by ssh. However, getting the
| client terminals to coordinate nicely (e.g. reattaching to the
| appropriate sessions, opening new terminals in the same remote
| working directory) require more sophisticated clients than exist
| currently (to my knowledge).
|
| Does anyone feel similarly? Anyone have a setup that approximates
| what I'm looking for?
| JonChesterfield wrote:
| Emacs. Runs as a server, stays alive when clients drop. Window
| management on keyboard. Tramp mode is great. But I'm sure
| you've heard this already :)
| Szpadel wrote:
| I'm using resurrect tmux plugin configured to rerun ssh
| commands, it's not perfect as it's not restoring remote
| session, but at least you have session open to right host in
| pane that you expect with scroll history.
| IshKebab wrote:
| Does this use Extism?
| rodrigodlu wrote:
| Awesome! I will be sold forever when something similar to tmux
| ressurect is available.
|
| Also I want to point out the way this is being handled in GH
| issue 575.
|
| It's taking time, but the politeness of many people, specially
| @imsnif is out of this world.
|
| This will be killer and it's ready, because one can freely create
| the tabs and panes designs while working, then dumping and
| customizing more later.
|
| I'm learning rust myself now, and projects and people like this
| encourages me even more. (Even with the rust foundation issues
| that happened)
|
| Thanks all!
| renewiltord wrote:
| It looks pretty cool. Is there a plugin that is just "convert
| this program into a plugin"? i.e. say I'm doing some networking
| set up and I want to check whether what I'm doing is improving or
| reducing effective performance. I would like:
|
| 1. One pane with my UDP benchmark between two of my machines
|
| 2. One pane with my UDP benchmark between two other machines
|
| 3. One pane which is a normal terminal where I'm going to make my
| changes
|
| So what I'd do is make my changes in normal terminal, then switch
| over to #1 and hit Enter and it runs, then switch over to #2 and
| it runs. I don't want to write a specific plugin for my UDP
| benchmark tool. I want a plugin that takes a pre-baked command
| (with flags and arguments) and turns it into a pane that I can
| just switch to and hit Enter.
|
| Honestly, I currently use a tiling terminal emulator (iTerm2) and
| it's not bad, but I have to hit Up+Enter and then that's
| overlapping with the history of whatever shell is on that
| machine.
| imsnif wrote:
| Hi, Zellij has this feature. Please check out command panes:
| https://zellij.dev/documentation/zellij-run.html
|
| You can either open them through the cli with "zellij run --
| <your command>" when inside a zellij session, or set them up in
| a layout so it opens all of the ones you want in a new tab
| arranged the way you like.
| renewiltord wrote:
| Absolutely perfect, mate. Thank you.
| imsnif wrote:
| Sure thing! Btw, plugins can also open these command panes,
| this is how the multitask "mini-ci" plugin works.
| Szpadel wrote:
| I was checking it like a year ago and it was cool but lacked some
| functionalities that i relied on daily basis (in comparison with
| tmux). I'm sure that some of those could be already implemented
| but plugins could probably fulfill rest of those.
|
| For sure i see need for some kind of plugin "package manager"
| here. on one hand this would help with discoverability of
| plugins, but more importantly with updates. checking each of
| plugin every so often isn't convinient and in such systems i
| usually check once or twice a year if there is any update.
| kibwen wrote:
| Because it's not immediately obvious, Zellij is a terminal
| multiplexer like tmux or GNU screen, whose distinguishing feature
| is that it comes with more built-in functionality, has a more
| discoverable UI, and a more opinionated/modern default
| configuration while still being highly customizable (as
| demonstrated in the OP).
|
| https://github.com/zellij-org/zellij
| interlinked wrote:
| Too bad it isn't a drop in replacement for tmux because of
| memory usage. There are memory leaks and even without that the
| base memory uses is a couple hundred megabytes. Tmux on the
| other hand, consumes only tens of megabytes of memory.
| imsnif wrote:
| Hey, there are no memory leaks that I'm aware of (there were
| a few, but we plugged them in recent months). If you know
| differently, I'd appreciate an issue report.
| lfmunoz4 wrote:
| [dead]
| kseistrup wrote:
| If you run e.g. btop or bpytop in a separate zellij tab,
| zellij will eventually gobble up all your memory and die.
|
| In the beginning I wa very entusiastic and switched from
| tmux to zellij on remote machines, but as I usually have
| btop running in a tab it would die in a day or two, so now
| I'm back to using tmux on remote machines and reserve
| zellij for local (and make sure I don't run btop in a tab).
| imsnif wrote:
| I'm like 90% sure this was fixed - if you'd be willing to
| try with a recent Zellij version, that would be great.
|
| Otherwise, I'll try your reproduction myself and will fix
| if I can reproduce. Thanks.
| kseistrup wrote:
| I'm now running v0.37.2 on a remote machine with 3 tabs:
| a shell, syslog spooled by lnav, and btop. To me it looks
| like it grows by 2 kB RAM every minute. I am logging to a
| file with timestamps, and we will see the results
| tomorrow.
| kseistrup wrote:
| (Does HN have an indentation limit, I can't seem to reply
| to imsnif...)
|
| I'm always running the latest zellij, but I'll start btop
| in a tab right away and see what happens.
|
| I did mention it in https://github.com/zellij-
| org/zellij/issues/1625#issuecommen... and noticed the
| issue is still open, so I haven't tried btop in zellij
| since v0.36.0.
| imsnif wrote:
| Keeping track is hard sometimes, I saw it again in the
| issue as you mentioned. :)
| maximilianroos wrote:
| Yeah, and it does flicker a bit etc.
|
| But I still use it all the time now -- I found it so much
| easier to get up to speed with relative to tmux. And it's
| getting better all the time, so I'm happy to invest in it...
| v3ss0n wrote:
| Yeah and sudden unexplained crashed made me stop using
| [deleted]
| forrestthewoods wrote:
| With no support for Windows
| aae42 wrote:
| Works great in WSL in windows terminal....
| david2ndaccount wrote:
| I just tried it out and it apparently highjacks normal command-
| line editing shortcuts like ctrl-n, ctrl-p, ctrl-h, etc.
| imbnwa wrote:
| Its not tmux, are you sure you're engaging its binding which
| enables/disables its binding map, I belive Ctrl+G IIRC,
| unlike tmux which prefixes its bindings with a customizable
| chord
| david2ndaccount wrote:
| I see that now, but then you can't use the buffer
| navigation hotkeys. I'll just stick with tmux.
| Timon3 wrote:
| HOT DAMN! Over the last few weeks I've wished almost daily I
| was proficient in tmux, but it's annoying to get started in
| because you have to look up EVERYTHING. I just tried Zellij
| (they have a "try without installing" command on their website)
| and it's exactly what I wanted Termux to be. Thank you so much
| for this comment!
| imbnwa wrote:
| Indeed, for someone new to terminal multiplexing, its the
| superior UX, its just missing some advanced things tmux does,
| but which are being worked on
| colordrops wrote:
| Starting to look like a text based window manager from the early
| 80s.
| SpriglyElixir12 wrote:
| Why do terminal applications need a WASM runtime? I feel like I'm
| not really understanding something fundamental about WASM.
| voigt wrote:
| I do understand why people try this approach:
|
| First: wasm is the perfect plug-in language, as it provides a
| high level of isolation and therefore security for the host
| app.
|
| Second: the promise of wasm is that you can write it in any
| language. I think this is compelling for any application that
| seeks for extensibility.
|
| Wether all this is worth the effort is probably the actual
| question. Maybe we will be surprised by killer plugins that
| wouldn't be possible with regular plug-in systems...
| kibwen wrote:
| _> Maybe we will be surprised by killer plugins that wouldn't
| be possible with regular plug-in systems..._
|
| It's less "this wouldn't be possible" and more the fact that
| the existence of plugins that are sandboxed and access-
| permissioned makes me far more likely to seek out and install
| plugins in the first place, since it lowers the trust
| barrier. It's the same reason why I browse random websites
| freely while also being loathe to install random binaries on
| my computer. Being language-agnostic is just icing on the
| cake.
| Already__Taken wrote:
| Wasm has the promise to be a single target for your plugins
| that could be written in node/rust/python and the consumer
| won't have to have that specific version of python installed.
| That and the possibility to sandbox a plugin so my repl
| function can't also upload my ssh keys would be nice.
|
| WASM doesn't mean this has to be true, but it could be.
| da39a3ee wrote:
| You might be missing the fact that WASM nowadays doesn't
| necessarily have anything to do with web browsers. It was
| initially designed for running in web browsers, but in the last
| few years there's been a lot of activity surrounding embedding
| WASM runtimes in processes other than web browsers. Mostly the
| idea is for it to be a way to execute untrusted / customer code
| (e.g. "plugins") with sophisticated sandboxing, etc.
| baq wrote:
| Terminal is just UI. It's completely orthogonal to WASM.
| maximilianroos wrote:
| Big fan of Zellij!
|
| Here are my configs for anyone interested -- more modal than the
| default: https://gist.github.com/max-
| sixty/6be7225ddc0a9cecb7203d5f7f...
| [deleted]
| landr0id wrote:
| I tried Zellij a while ago (year+?) and wasn't a huge fan. After
| some major updates I tried it again and it's become my daily
| driver.
|
| Great application and I'm looking forward to seeing the plugin
| ecosystem grow. Thanks to the maintainers and contributors for
| their work.
| tux1968 wrote:
| It seems odd to distinguish between a plugin and a program
| running in a terminal pane. This seems to imply you must
| reimplement all such functionality as a new plugin, instead of
| just running your preferred tool, as usual, in a terminal window.
|
| For example, they have implemented a file explorer as a plugin.
| But this means you can only use it when Zellij is available, and
| not as a standard tool on another system. This reduces
| flexibility and means you need different tools in different
| contexts.
|
| I'd love to be corrected, but I can't think of any good reason
| why a special file explorer needs to exist, just to be coded to
| this plugin standard, instead of as a normal terminal program.
| mpalmer wrote:
| Maybe you're focusing too closely on the specific example. It's
| interesting to me in the large for sure.
|
| For one, since plugin permissions seem to be on the roadmap,
| users can expect to be able to write and run third-party code
| with a bit more confidence than if it were just another unix
| process.
|
| Looking further down the line, imagine a pluggable web/native
| frontend for Zellij. At its most basic level of operation, it
| would still serve as a full terminal multiplexer, but it would
| also have the potential to do anything the containing runtime
| supports (render images, play video, render rich
| inputs/controls).
|
| I wasn't imagining this before, but I kind of am now...
| imsnif wrote:
| Good question!
|
| A few reasons:
|
| 1. Ease of distribution - distributing a precompiled wasm blob
| is immensely easier than distributing an application
|
| 2. Sandboxing - both on the fs level and regarding special
| permissions, which brings us to
|
| 3. Stronger capabilities - you can use the terminal workspace
| around you by manipulating panes, tabs and other plugins,
| creating a workspace experience rather than a single app
|
| 4. More knowledge about the application - want to trigger when
| the user enters a certain folder? When a certain pane is
| focused? When certain text appears on screen?
|
| 5. Composability - integrate with other plugins to render a
| dashboard-like experience rather than a single app that a user
| needs to manually compose
|
| While some of these are also achievable with native apps, I
| have found that if you give users (developers in this case)
| opinionated defaults that make integration easier - you'll get
| more people building more interesting things. Even if they
| technically can implement them all on their own.
| ReleaseCandidat wrote:
| > 1. Ease of distribution - distributing a precompiled wasm
| blob is immensely easier than distributing an application
|
| The precompiled WASM blob could be the (console) application
| (which runs in e.g. Deno/Node or Wasmedge/Wasmtime/...).
| imbnwa wrote:
| More interested in when they'll implement concurrent, switchable
| sessions, one of the main reasons one would continue to use tmux,
| but this is nice development
| imsnif wrote:
| Very soon! We want to implement it as a default plugin and
| wanted to release this system first.
| nilslice wrote:
| Very cool! As a wasm fan, I'm excited to see this and really
| appreciate the detailed write-up. As a maintainer of Extism[0] (a
| wasm plugin system framework) I'm curious if our project came up
| in your research for this, and if so, what is missing or kept you
| from considering it as a solution?
|
| https://github.com/extism/extism
| imsnif wrote:
| I'm pretty sure our plugin system predates your project (it's
| been around since before our beta was released in 2021, we've
| just given it the attention it deserved right now).
|
| I'd definitely have wanted to outsource this though if we
| didn't have the infrastructure in place already. Extism seems
| solid.
___________________________________________________________________
(page generated 2023-06-27 23:00 UTC)