[HN Gopher] Zellij - A Terminal Workspace and Multiplexer
___________________________________________________________________
Zellij - A Terminal Workspace and Multiplexer
Author : ibraheemdev
Score : 317 points
Date : 2021-04-22 13:22 UTC (9 hours ago)
(HTM) web link (zellij.dev)
(TXT) w3m dump (zellij.dev)
| syrusakbary wrote:
| The idea of using WebAssembly for their plugins is really
| impressive (they are using Wasmer!). It allows to have fully
| sandboxed code that interact with their code safely and fast.
|
| I think more projects will start following the same direction
| soon!
| bitbo wrote:
| I'm confused. Zellij uses wasmer and wasmer-wasi. Wasmer may
| use cranelift for compilation (dont know if Zellij does).
|
| "Fast & Safe. Wasmer runs WebAssembly at near-native speed in a
| fully sandboxed environment."
| (https://github.com/wasmerio/wasmer)
|
| But ...
|
| "Cranelift does not yet perform mitigations for Specter or
| related security issues, though it may do so in the future." (h
| ttps://github.com/bytecodealliance/wasmtime/tree/main/crane...)
|
| Will the wasmer runtime handle specter / meltdown / rowhammer
| attacks?
| maxmcd wrote:
| I feel like in this case those kinds of things are up to
| Zellij. If you run wasmer within the same process and share
| memory with the main Zellij process then yes
| wasmer/cranelift/wasmtime/wasm doesn't protect you from
| various speculative execution attacks. However, Zellij could
| run plugins in separate processes and apply things like
| seccomp to get further protections provided at the operating
| system level.
|
| This is still not a complete security story and would not
| provide the same kind of protection as a VM, but I think the
| charitable take here is that this is a good sandboxing tool
| and a step in the right direction for something like a plugin
| system.
|
| edit: I also disagree with the "fully sandboxed" wasmer line,
| but wasmer is a venture-backed for-profit org that will start
| selling something at some point and they might have a
| motivation to blur the lines a little. I appreciate
| cranelift's more honest disclaimer.
| chc4 wrote:
| WASM and Wasmer are not intrinsically anymore secure,
| except for simplicity, than any other editor plugin system.
| Vimscript and Emacs-lisp basically have the same security
| characteristics as using WASM for plugins. It's not a step
| in any direction, except for whatever environment Zellij
| exposes to the plugins by default.
| maxmcd wrote:
| I'm not sure how this is true. I don't know anything
| about vimscript and emacs-lisp plugin systems, but at a
| cursory glance it looks like plugins might be able to do
| things like launch shell commands?
|
| Zellij seems to be using WASI, a standard set of
| syscalls. Currently, wasi syscalls (or at least the
| version of wasi that is running in wasmer) can't really
| access the network, can't fork/exec, can provide a chroot
| view of the filesystems (without root access), can limit
| access to certain types of functionality. These kind of
| secure defaults seem like an improvement to me compared
| to most plugin systems I'm familiar with.
|
| Maybe vimscript/emacs-lisp has these things.
| tedunangst wrote:
| Can you elaborate on the threat model that requires your
| terminal multiplexer to have rowhammer mitigations?
| maxmcd wrote:
| I think OP is just arguing and saying "fully sandboxed"
| might imply that kind of security.
| bitbo wrote:
| Yes, maybe Zellij using Wasmer is great, don't know. I
| commented because as someone who don't follow the rust
| ecosystem I was curious if there was something not as big
| and complicated as google's v8 engine for running
| sandboxed code.
|
| But it seems you should not use wasmer for running
| untrusted code or binaries.
|
| I also don't know enough about rowhammer, or security
| exploit of any kind really, to answer the question about
| how you could use them against a terminal multiplexer.
| [deleted]
| chc4 wrote:
| It doesn't, nor does it use seccomp to mitigate against
| language VM security issues.
| j16sdiz wrote:
| What terminal does it support? Historically, different terminal
| color, Unicode font wide
| qwerty456127 wrote:
| What's the point of fitting multiple terminals in a single text-
| mode screen when everybody is using GUI terminal emulators and
| tiling window managers?
|
| I remember good old pure text-mode days with warmth but doubt
| there are many people actually doing it nowadays. So I imagine
| this (thesubject) is going to be ran inside a GUI terminal
| emulator window and I don't understand how is that better than
| just having more windows.
| 002445 wrote:
| I use tmux locally even though I run i3 as my window manager.
| Mostly because I configured tmux to show the current directory
| and git branch (if in a git directory) so I can keep my prompt
| a clean "$".
| earthboundkid wrote:
| My trick is all the directory, date, git junk in my prompt is
| separated by a newline and then $, so when I copy and paste
| my shell somewhere, I can just drop those lines easily
| without having to do fine selection.
| 002445 wrote:
| That seems like a lot of wasted space to me. The benefit of
| putting it into tmux is it only shows in 1 place. I don't
| need to see the git branch and folder of the location where
| I ran my previous commands, I just need to see where I am
| at right now.
| _jal wrote:
| > but doubt there are many people actually doing it nowadays
|
| I use tmux almost as much as bash. And if you use a Mac with
| Iterm2, you can use tmux the way you're imagining.
|
| The primary advantage is the same reason I still use vim a lot
| - speed and efficiency. There is just no comparison to GUI
| tooling. But I readily admit a lot of it is familiarity - I
| know and like my tools, and there's no advantage gained by
| changing.
| eschneider wrote:
| I do most of my work (embedded development) ssh'd into a few
| linux boxen at the office which can reach my test devices and
| various other bits and bobs.
|
| I'm pretty happy running full text mode editing in emacs (-nw,
| ftw :) and a few other shells for tasks I haven't incorporated
| into emacs yet. Speed is nice, even over a vpn, which running
| anything graphical is somewhat grim.
|
| Still, the killer feature with screen multiplexers (in my case,
| tmux, but this isn't unique to tmux) for me is the fact that
| the tools preserve state, so I can start a long job and it
| won't be interrupted, even if the connection drops. I just log
| back in and reattach and everything is just like it was.
|
| Sure there are other ways to do that, but having it neatly
| wrapped up and always on is really a game-changer for me.
| kleiba wrote:
| emacs -nw and screen is all you need.
| _pmf_ wrote:
| I'm a heavy terminal user, and I cannot understand how people
| use something like tmux that constantly causes full screen
| refreshes and hangs due to one part misbehaving.
| Pawka wrote:
| Are you saying that tmux feels slow on the terminal? If that
| is the case maybe using different terminal might help. I'm
| fan of `st` terminal because of its speed. And haven't
| noticed any slowness of tmux.
| dljsjr wrote:
| Remote sessions. Unless you want to use X forwarding, or create
| multiple SSH sessions, it's way more ergonomic to do it this
| way. I currently use tmux for this and when you combine it w/
| the tmux command mode (-CC) and iTerm 2 you get the best of
| both worlds, but even without iTerm 2 integration I still
| prefer panes to be handled by the multiplexer because then I
| know I can get my consistent and comfortable environment on any
| arbitrary remote box.
| nitnelave wrote:
| You can multiplex your SSH session and have several ssh
| commands running on the same connection (without having to
| type the password/check the security key again). Check the
| ControlMaster option for SSH.
| whimsicalism wrote:
| And this is better than tmux... Why?
| _jal wrote:
| I use both. The primary reason for ControlMaster in my
| case is we use 2FA, and this way I only have to auth one
| connection.
|
| Tmux is the UI for switching between ssh sessions sharing
| the connection.
| otachack wrote:
| That's a good question and I think it depends on the developer.
| One recent day I became fed up managing my three separate
| terminal windows with each having a few tabs. I thought
| "alright, now's a great time to jump into a multiplexer" and it
| worked well as a catalyst. I downloaded Tmux, set a Tmux
| shortcut browser window for easy reference, and mimicked my
| setup in Tmux.
|
| It's immensely a cleaner solution than toying around with
| separate windows for me. Switching sessions and consoles is
| seamless and it's all in one window. Eventually something will
| bite me regarding Tmux getting in the way of something and
| causing headaches but the momentum I have is great.
|
| I suggest trying one out sometime, it may open a whole new
| world of tooling for you! Otherwise there's no sweat if you got
| something working sans multiplexer.
| tyingq wrote:
| Not having to touch the mouse. I can't do it myself, but I've
| watched ops folks using tmux in a productive way that I think
| would be difficult to reproduce if you involved a window
| manager.
| busterarm wrote:
| You don't have to use the mouse with tiling window
| managers...
|
| /s heavy tmux user that left it for xmonad.
| alex_smart wrote:
| Can you select and copy some text from your terminal
| emulator without using tmux? Copy-mode is one of the killer
| features of tmux for me.
|
| The only terminal emulator that supports selection with
| keyboard afaik is rxvt with plugins. I would be interested
| to know if there are other terminals that support this.
| Please don't say emacs XD
| busterarm wrote:
| You can use any terminal emulator you want with tiling
| window managers...I don't see the issue.
|
| Run rxvt if you like.
| ibraheemdev wrote:
| Yeah, I think that the main benefit of tmux is session
| management. Tiling window managers can replace tmux panes.
| busterarm wrote:
| Aye. Occasionally I'll pop tmux open in a tile for this
| purpose.
|
| It's been reduced to merely being a replacement for
| screen for me.
| alpaca128 wrote:
| Tiling window managers cannot replace a multiplexer's
| knowledge about the session.
|
| I use a multiplexer because it lets me instantly open a
| new terminal in the same directory I'm currently working
| in. Furthermore it can open the terminal's buffer in Vim,
| letting me select and copy text using all features and
| shortcuts I'm used to. Doing the same by scrolling
| around, selecting snippets using the mouse and pressing
| Ctrl-Shift-C cannot compete with that.
|
| Yes, there are a few terminal emulators with integrated
| tabs and window splitting and all that which offer
| similar features, but then they also have countless other
| things I don't need and in return take ten times longer
| to open a new window.
| ibraheemdev wrote:
| > I use a multiplexer because it lets me instantly open a
| new terminal in the same directory I'm currently working
| in.
|
| You can add a keybinding for this with alacritty:
| { key: N, mods: Command, action: SpawnNewInstance }
|
| > Furthermore it can open the terminal's buffer in Vim,
| letting me select and copy text using all features and
| shortcuts I'm used to
|
| alacritty has vi mode which gives you all of those
| keybindings without having to open vim
| (ctrl+shift+space).
| alpaca128 wrote:
| > alacritty has vi mode which gives you all of those
| keybindings
|
| It doesn't give me access to my custom keybindings or the
| plugins I have setup in Vim. Also I can't select or
| annotate terminal output and then save it directly into a
| file in one step.
|
| The multiplexer is both more powerful and flexible by
| actually doing less and just passing tasks like selection
| and copying to other proven tools. I appreciate that more
| than terminals trying to do everything.
| ibraheemdev wrote:
| Well, I'm not sure why you need vim plugins for copy-
| pasting from the terminal, but I agree that it is more
| powerful. My point is that a lot of people don't need
| tmux/zellij because their terminal emulators provide much
| of the useful functionality.
| cmrdporcupine wrote:
| About 90% of my work is remote sessions.
| bennyp101 wrote:
| I use a tiling window manager and use tmux - just because I can
| tile windows doesn't negate my use of tmux.
|
| I have a single window that is all of my terminals - which to
| me is much easier to manage than a load of random terminals all
| over the place. Sessions are named, and windows are named, and
| I have F1-F8 mapped to load the corresponding window, F10
| brings up a list of sessions, and F9 toggles between the last 2
| sessions.
|
| Mine is based on https://github.com/gpakosz/.tmux but
| customised for F keys, status bar, mouse etc
| mcjiggerlog wrote:
| Anecdata:
|
| I don't want to tile all my windows, only terminals, so I'm not
| interested in tiling WM.
|
| I also jump between OSs and appreciate being able to have the
| same terminal multiplexing behaviour on both linux and macOS,
| without needing to learn the keyboard shortcuts and
| idiosyncrasies of two different GUI terminal multiplexers.
|
| As another commenter pointed out, being able to multiplex in
| the exact same way for remote sessions is a massive bonus.
|
| Lastly, tmux has a lot of features and customization and once
| you learn those you really come to appreciate them. Tmux can
| also look really quite nice, it doesn't need to look as boring
| as it does out of the box: https://i.imgur.com/MgUx0U2.png.
| doix wrote:
| I use tmux/screen when I am working via SSH for some reason.
| It's nicer to create the layout in a terminal multiplexer
| rather than having multiple SSH sessions, because if you ever
| lose connection or your laptop dies, everything is like you
| left it.
|
| Locally, I don't bother and just use i3.
| jacobsenscott wrote:
| gui terminals crash. tmux is forever.
| pkilgore wrote:
| Is there a good reason for a multiplexer to be a separate tool
| from a terminal? Or a window manager? Or is this just GNU/Unix
| philosophy (do one thing well and compose).
|
| The reason I ask is that while I never used a multiplexer like
| tmux, I use the layout features of kiTTY every day and I can't
| quite see beyond that common use case (split this terminal into X
| windows with Y layouts).
| necrotic_comp wrote:
| persistence and the ability to run it on a remote machine are
| the big draws. I can set up a tmux session on a remote box,
| have multiple connections to it, and close my terminal without
| losing my work.
| marti-oss wrote:
| cvb
| yjftsjthsd-h wrote:
| What?
| marti-oss wrote:
| cvbvbc
| mkhnews wrote:
| Looks cool. I wonder how it handles the clipboard ? with Wayland
| ?
| j16sdiz wrote:
| What TERM does it support?
|
| In my experience, true color support, Unicode width and RTL
| language are very problematic.
| ahepp wrote:
| I see a lot of projects on here where the tagline is that they're
| written in Rust.
|
| Shouldn't that be _completely_ opaque to the user? I don 't have
| any idea what programming language most of the software I use is
| written in.
|
| If it's faster or more stable than tmux, shouldn't that be what's
| advertised, rather than implementation details? Reading the page,
| what catches my eye is the webasm plugin system (although it's
| not immediately obvious to me what I'd use that for).
| OhSoHumble wrote:
| It's a technical post on a technical forum filled with
| technical people. We aren't just users, we're programmers. It
| makes sense to include broad implementation details in the
| title.
| ahepp wrote:
| Maybe a fair point, I guess it's ambiguous because technical
| people are both the users and developers of terminal
| multiplexers.
|
| I do still question what it means if the coolest thing to say
| about it is it was written in Rust, whether that's intended
| for developers or for users
| emteycz wrote:
| The coolest thing to say about it is "Terminal Workspace
| and Multiplexer" which precedes "Written in Rust". What
| more would you add? I think that's cool enough!
| mtrower wrote:
| In addition to what others have posted, it matters if you ever
| expect to read or modify the source. Assuming my capability
| requirements are met, I'm going to prefer a program written in
| a language that I'm comfortable with (such as C or lisp) to a
| program written in a language foreign to me (such as Go).
| dang wrote:
| I've de-Rusted the title so hopefully the thread can stay on
| topic (i.e. specific, not generic: https://hn.algolia.com/?date
| Range=all&page=0&prefix=true&sor...).
| ex_amazon_sde wrote:
| I feel like this stuff should be posted in a Rust-specific
| site, not on HN.
| mariusmg wrote:
| >Shouldn't that be completely opaque to the user?
|
| No necessarely, because app being written in Rust and Go is
| actually a feature for the user, it means the entire app is a
| single executable with a decent runtime performance.
| nodelessness wrote:
| Not something most developers who may use a tmux equivalent
| would know about.
| dataangel wrote:
| lol no, using tmux is a strong sign you would.
| serverholic wrote:
| I think advertising the language is important. Rust is fairly
| strict which improves stability. It also means that I'm not
| downloading some bloated electron crap.
| KajMagnus wrote:
| > Shouldn't that be completely opaque to the user?
|
| That would have been nice indeed. However many languages use
| lots of memory and are a bit slow, or are security-dangerous
| like C. It's nice to know, then, that this app likely uses
| barely any memory at all, and is as fast & keyboard-responsive
| as it can be, and harder to hack -- Rust. (Assuming it is
| implemented in a good way :- ))
| fwip wrote:
| The implementation matters a good deal more than the
| programming language.
| door101 wrote:
| The programming language is a pretty substantial part of
| the implementation, though, if not the most substantial
| one. Rust is qualitatively different than a language like C
| (in that it is memory safe) or Python (in that it is
| compiled and fast).
| ahepp wrote:
| If it's faster or uses less memory, that's something that can
| be easily measured.
|
| If it's more secure, that's harder to measure. But that's not
| even the tagline, just that it's written in Rust.
| door101 wrote:
| Some would argue that Rust's advantages over C (or other
| languages) are so great that it constitutes a crucial feature
| of the software, and that while it doesn't necessarily indicate
| quality, it makes building quality software substantially
| easier.
| ahepp wrote:
| Then shouldn't there be some observable (better yet,
| measurable) side effects?
| door101 wrote:
| True -- one can certainly write terrible software in Rust,
| but in my view, being written in Rust is a notable enough
| aspect to a project to point it out
| Skunkleton wrote:
| Advertising the language could attract contributors to the
| project. Especially true for a newish language that is just
| starting to gain widespread traction.
| Arnavion wrote:
| It's people interested in Rust advertising to people interested
| in Rust. The programming language is as much the point as the
| program's purpose.
| curun1r wrote:
| It depends whether you've been burned by memory safety/data
| race CVEs in the past. For better or for worse, some people
| actively search out software written in Rust specifically
| because the choice to use C/C++ is not opaque to the user.
| HaoZeke wrote:
| This is fantastic! Love the customization. I think for this level
| of complexity YAML is fine. Are there any plans to incorporate
| the plug in system which tmux has through tpm?
| uses wrote:
| I've been using tmux for quite a while, though at a fairly casual
| level.
|
| The first thing I noticed is that this interface is discoverable
| - it shows me what I can do, which is incredible and makes me
| want to use it. The main reason I've been a casual tmux user and
| not an advanced one despite using it for years, is because every
| time I want to try something new I have to google if it's
| possible.
|
| The second thing I noticed is that it uses ctrl-r as a core
| shortcut. Mega problem: ctrl-r is a built-in bash feature which I
| use every day to recall previous commands. This makes me think I
| can't use this tool at all.
|
| I would suggest to consider taking a page from tmux's book. Just
| use a global modifier key. Ctrl-b is what tmux uses, so you know
| it's safe. Other software being developed knows they should avoid
| it, because tmux uses it. By also using it, you'd no longer have
| to dance around the global space of what shortcuts every software
| in existence is using. Additionally, if you use ctrl-b to enable
| your commands, you can minimize your interface. Currently you're
| using two entire lines to display your menu. That's going to
| become tiring as I use zellij 8 hours a day for years. I'll have
| to hide it eventually. Instead, what if you reduced it to zero
| lines? Put "ctrl-b: menu" in the upper right of your title bar.
| Pressing ctrl-b now enables commands and shows what your next
| keypress will do. You have now (1) avoided breaking existing
| shortcuts, (2) aligned with established standards (3) given some
| familiarity to welcome tmux users (4) expanded visible screen
| space and (5) simplified your menu system. You can also now
| remove ctrl-g since the interface is "locked" by default until I
| want to start interacting with it.
|
| Anyway that's my 2 cents. Thanks for this exciting demo.
| yjftsjthsd-h wrote:
| > The second thing I noticed is that it uses ctrl-r as a core
| shortcut. Mega problem: ctrl-r is a built-in bash feature which
| I use every day to recall previous commands. This makes me
| think I can't use this tool at all.
|
| In fairness, ctrl-a (screen default) and ctrl-b (tmux default)
| are also super useful readline shortcuts in bash (c-a = go to
| beginning of line, c-b = back one character).
|
| EDIT: Sorry, I just realized - ctrl-r isn't a _prefix_ , it's a
| _shortcut_ , isn't it? And they have lots more? Yeah, that's
| ... a pretty questionable approach; it'll interfere with lots
| of things.
| Skunkleton wrote:
| Oddly enough, almost nothing binds the space bar. I've been
| using ctrl-spc as my tmux prefix for years without a single
| conflict. I think this is because there is somewhat limited
| support for ctrl-space on older terminal emulators.
| smabie wrote:
| Also C-space sets the mark on Emacs.
| Skunkleton wrote:
| I have been exposed as someone who doesn't use emacs :)
| imsnif wrote:
| You can lock the interface with ctrl-g and then all keys pass
| through.
| uses wrote:
| See that's also interesting, thanks for the heads up. I saw
| "lock" previously and pressed it, and it did something
| besides what I expected. When I think lock, I think it's
| literally locking the interface in some way so someone can't
| interact with the software, including myself unintentionally.
| That's what it means in Windows, MacOS, and even tmux. I
| would consider just starting out "locked" but change the
| paradigm. It's not locked, it's just that the menu isn't
| active. "Unlocking" now becomes enabling the menu/interface -
| until you disable the menu.
| imsnif wrote:
| Keybindings are a hard problem. Doubly so when you're a
| wrapper that has to also not collide with everyone else's
| keybindings. :)
|
| The idea was that users should spend most of their time in
| "normal" mode, deferring to "locked" mode only for cases
| like you mentioned (ctrl-r in bash or in vim). The modal
| ergonomics are built on that.
|
| I'd ideally like to find one word that describes locked
| mode better than "locked", which I agree is not ideal. I
| spent quite some time thinking about it and asking others,
| but most of us are not native English speakers - so maybe
| there's something obvious we're missing. :)
| ehsanu1 wrote:
| ctlr+r is a very heavily used shortcut for some people.
| Perhaps that can be configurable?
| imsnif wrote:
| All of the shortcuts are configurable:
| https://zellij.dev/documentation/keybindings.html
| neurocline wrote:
| Wouldn't the word "passthrough" be the right word for
| this feature?
| imsnif wrote:
| That's a cool idea! I'll run it by some old/new users,
| see how they react. Thanks!
| mikevin wrote:
| I think ctrl r is used frequent enough to warrant a single
| keychord instead of having to chain though.
| hnarn wrote:
| I've only used it for a few minutes, but here's my first
| impressions.
|
| What I really liked: I didn't have to read any documentation to
| understand how to do the things I'm used to in tmux, the
| CTRL+[KEY] menus with hints are really helpful and well designed.
|
| What I didn't like so much: The interface doesn't feel as snappy
| as tmux over a remote connection, and I couldn't find any way in
| the "CTRL-menu" to detach (like tmux CTRL+B,D)
|
| Looking forward to future releases!
| semi-extrinsic wrote:
| From the webpage, it seems ability to detach is planned for
| future work.
| firstSpeaker wrote:
| how does it differs from iTerm2?
| diehunde wrote:
| Totally different tools. You could run this inside of Iterm
| totallymike wrote:
| A better comparison would be tmux. iTerm2 is a terminal
| emulator, where tmux is a multiplexer.
| sanity31415 wrote:
| You have a problem and you need a configuration language, so you
| pick YAML. Now you have two problems.
|
| Take a leaf out of Rust's book and use something simple and sane
| like TOML, YAML is a mess.
|
| See: https://github.com/cblp/yaml-sucks
|
| Otherwise this looks like a great project, please don't ruin it
| with YAML.
| infogulch wrote:
| Configuration language seems to be a hot topic at HN today, as
| every day. "Don't use X, use Y instead" has spawned this thread
| with everybody putting in their favorite configuration language
| in the hat for consideration. Lets list the ones that have
| appeared so far:
|
| YAML, TOML, Lisp, Dhall, JSON, EDN, JSON5, HOCON, Lua, HCL,
| XML, HJSON, Starlark, strict yaml
|
| About a third of which I'd never heard of. And because I can't
| help myself (the dogpile is so _enticing_!), I have to say that
| the one that I 'm most interested in is: Dhall.
| jupp0r wrote:
| If you don't like it, just generate the YAML from something
| else: https://github.com/dbohdan/remarshal
| bit-rot wrote:
| This feels like a bit of a bikeshed. There are problems with
| many configuration languages. I don't see anything related to
| yaml on their issue tracker.
| sanity31415 wrote:
| > bikeshedding
|
| > Futile investment of time and energy in discussion of
| marginal technical issues
|
| I don't see how the choice of configuration file format is a
| marginal technical issue. It makes a big difference to the
| ergonomics of a tool.
|
| It's one of the things I like most about Rust over my main
| programming language Kotlin. Rust has Cargo which uses TOML,
| which is nice and simple. It's so much more pleasant to use
| than Koltin's Gradle.
| whimsicalism wrote:
| HN on ShowHN posts is almost always a series of bikesheds
| hctaw wrote:
| I think the biggest problem with YAML is not YAML itself but
| what people use it for. It's very flexible and readable for
| smaller files (much more than TOML - which is awful for
| hierarchical data).
|
| A bigger problem is that so many things are using config files
| that should be proper DSLs or libraries, but no one wants to
| maintain a library (or create RCE as a service by accident) and
| no one wants to write a parser/interpreter.
|
| Most of the "YAML sucks" issues would go away if we stopped
| treating LowCode as something desirable (we do actually need to
| write code sometimes, as it happens) and if we had better
| sandboxing/parser generators along with less animosity towards
| DSLs.
| nsm wrote:
| There is now a good parser/interpreter already written for a
| proper configuration DSL in Rust -
| https://github.com/facebookexperimental/starlark-rust
| vinceguidry wrote:
| My beef with YAML is that configuration should be flat, not
| hierarchical. There should be at very most one layer of
| nesting, to facilitate categories. INI files are fine.
|
| People do unholy things with it like nest bash scripts in it
| that should never be done. Text files should never have more
| than one syntax needing parsing. It's bad enough, say,
| embedding SQL into some python. But doing that with YAML is
| just the worst.
|
| You should be able to use regexes to deal with non-code text
| files. JSON, YAML, the whole motley crew require parsing.
| Don't get me started on JSON log files.
| donio wrote:
| YAML sucks but so does TOML, especially when it comes to nested
| data structures like the layout.yaml shown on the front page.
|
| There are no good configuration languages in existence and
| there never will be. We have rejected Lisp/sexp so now we must
| suffer endlessly.
| brundolf wrote:
| I think JSON would be perfect if it a) allowed comments, and
| b) had multi-line strings.
|
| It has exactly five data types, each with very clear and
| distinct notation that nests consistently (the top level
| isn't somehow "special" and there's no messing with
| significant whitespace). Only two collection types: keyed,
| and unkeyed. In some sense it feels like the apotheosis of
| untyped data-modeling.
| sammorrowdrums wrote:
| a) reminds me so much of this classic
|
| https://thedailywtf.com/articles/the-inner-json-effect
|
| "Tell us what you did to JDSL," one of the VP's asked.
|
| "I don't think I did anything," Jake answered. "I've only
| been here two weeks, trying to learn JDSL and how the
| customer portal works. I don't even know how to deploy it!"
|
| "You made a few commits to Subversion!" Tom shouted.
|
| "Well, yes. I added a few code comments, trying to-"
|
| "You can't use comments in JDSL!" Tom shouted. "THAT'S WHAT
| BROKE IT!!"
| aniforprez wrote:
| That 100% has to be fake. I NEED it to be fake. Are there
| production systems that work like this? Du they have one
| "rockstar" developer who does stuff like this?
| fwip wrote:
| Most of TDWTF is a kernel of truth surrounded by about
| three pages of fiction.
| xxpor wrote:
| I just wish JSON had fixed decimal numbers, a timestamp
| type, and a binary blob type :/
| [deleted]
| IshKebab wrote:
| I agree that TOML sucks for nested structures.
|
| JSON5 is probably the best option at the moment.
|
| https://json5.org/
|
| * Instantly obvious what the structure is (unlike YAML or
| TOML).
|
| * Everyone knows JSON already. This just makes it a bit
| nicer.
|
| * No noob security mistakes or type confusion caused by
| underquoting like YAML.
| somethingwitty1 wrote:
| Don't forget the truncation problem with YAML/TOML. A
| partially read/transmitted YAML/TOML file is often still
| considered valid.
| dflock wrote:
| That also makes it really easy to concatenate them,
| either `cp a.yaml + b.yaml c.yaml` or just `cat a.yaml >>
| b.yaml` - which is quite nice, compared to trying to do
| this with JSON etc... files.
| nine_k wrote:
| I would say that Dhall is fine, just from a parallel
| universe.
|
| JSON is close to sexps, but it sucks when comments are not
| allowed.
| nathell wrote:
| Which is why EDN is so much better for config.
| sysbot wrote:
| Have you looked at Cuelang [1] as a configuration language or
| source of truth?. It's still new but it's a superset of JSON
| but attempted to combine data/schema into one and reject
| inheritance and replace with validation instead.
|
| [1] https://github.com/cuelang/cue/tree/master/doc/tutorial/b
| asi...
| rch wrote:
| Take a look at HOCON (Human-Optimized Config Object Notation)
|
| https://github.com/lightbend/config/blob/main/HOCON.md
| KajMagnus wrote:
| Yes! I logged in just to mention HOCON, then I noticed you
| have mentioned it already :- )
|
| So, the project you linked to is Java / Scala:
| https://github.com/lightbend/config
|
| And there're also (basic? complete?) HOCON parsers in
| Javascript and Rust -- I investigated this a while ago,
| because I want to use HOCON everywhere in my projects:
|
| https://docs.rs/hocon/0.5.1/hocon/ (Rust)
|
| https://www.google.com/search?q=hocon+javascript (Js, a few
| different)
|
| The Rust version:
|
| > _This implementation goal is to be as permissive as
| possible, returning a valid document with all errors
| wrapped in `Hocon::BadValue` when a correct value cannot be
| computed_
|
| How nice :- ) (it seems to me)
| nsm wrote:
| If your Rust program needs a more complicated configuration
| (conditionals, access to APIs and so on), also look at
| Facebook's Starlark parser and tooling[1]. Starlark is a subset
| of Python used by Bazel, Buck and a few other projects.
|
| [1]: https://github.com/facebookexperimental/starlark-rust
| mixmastamyk wrote:
| Search up "strict yaml" it is a pretty good alternative to
| both.
| earthboundkid wrote:
| There are a million good alternatives. The question is why
| would you deliberately choose YAML for a new project when we
| now have a lot of real world experience about how it sucks.
| It's like deliberately choosing SOAP for a new API...
| bschwindHN wrote:
| For hierarchical data I've found JSON5 to be much more
| enjoyable to work with than YAML or TOML.
| petters wrote:
| Yes, TOML is great for some things but not hierarchical data.
| intricatedetail wrote:
| I get the yaml hate - I used to do that too. But as I worked
| more with it I can say I have not had any problems. I think
| toml feels actually more complex
| smrtinsert wrote:
| same comment, different config format, year after year after
| year...
| ralmidani wrote:
| Non-rhetorical questions: why not use the language itself so
| people can leverage features like autocomplete, type-checking,
| linting, and intuitive error handling in an IDE? Is there
| anything about Rust that makes it impractical for representing
| config/dependencies/etc?
| ibraheemdev wrote:
| That is one thing people love about xmonad, you write your
| config in haskell.
| jamamp wrote:
| Another option is JSON with the "$schema": "..." item[0].
| Most editors seem to pick that up automatically and provide
| autocomplete and type-checking.
|
| [0] https://json-schema.org/
| anon_tor_12345 wrote:
| how do you imagine this working? should the binaries for this
| ship a rust compiler?
| ralmidani wrote:
| You could, for example, compile AOT to a JSON file and
| build everything deterministically from there. Tell devs to
| not edit that JSON directly. I believe NPM and Yarn do
| something similar.
| anon_tor_12345 wrote:
| i have no idea what you're saying
|
| >compile AOT to a JSON file and build everything
| deterministically from there
|
| you want the dev that develops zellij to AOT compile all
| settings (that they set using rust as you imagine) to a
| JSON file that is then... what by end users? inspected
| but not edited? how would settings change then?
| goldsteinq wrote:
| Yep. Rust is a compiled language with monomorphized generics.
| It's slow to compile, and also you'll need to carry rustc
| everywhere. rustc is huge.
| jhgb wrote:
| Or, one could embed Chez Scheme, the compiler of which is
| like 800 kB in size and compiles stuff very quickly.
| alpaca128 wrote:
| The point of config/scripting languages is to make the user's
| life easier. I assume nobody wants to deal with the Rust
| borrow checker and lifetime annotations while tinkering with
| their configuration. So it depends - should it be an
| unchanging set of options/flags the user can switch around
| and then recompile? Probably fine though it'll never be as
| quick as e.g. recompiling programs from the suckless project.
| Want to expose interfaces for users to expand and modify the
| program's code? Not so much.
|
| Rust is a fantastic language, but it's probably not the kind
| of language you want for this purpose. Same reason why game
| engines often have scripting languages; so people don't have
| to deal with C++ where it's not required for performance.
|
| Imho the best compromise is embedding something like Lua
| which is simple and still flexible enough to allow more than
| JSON-style declarations.
| keymone wrote:
| YAML is the worst, kill it with fire. Whether TOML is decent
| alternative is debatable though, i'd prefer EDN.
| lsaferite wrote:
| I feel like I read almost the exact same comment after the
| honeymoon of every new file format used for configuration.
| keymone wrote:
| EDN is not new. Just not familiar to enough people. It's
| incredibly powerful and ticks all the right boxes.
| zestyping wrote:
| YAML is the worst choice. Please use something else!
| outworlder wrote:
| > You have a problem and you need a configuration language, so
| you pick YAML. Now you have two problems.
|
| So much debate could have been avoided if we stuck with
| S-Expressions from the beginning.
| akavel wrote:
| Or, to avoid sooner or later falling into Greenspun's Tenth
| Rule, just go immediately to Lua, which actually evolved out of
| a configuration language (https://www.lua.org/history.html), so
| it has syntax & features that are quite friendly for writing
| configs.
| fit2rule wrote:
| Lua is the best.
| rendaw wrote:
| I'd never heard of Greenspun's tenth but that's good to know!
| I had a personal theory that all program configuration
| interfaces eventually become programming languages (poorly)
| and maybe this fits in there.
| dimitrios1 wrote:
| > I had a personal theory that all program configuration
| interfaces eventually become programming languages (poorly)
| and maybe this fits in there.
|
| This is absolutely true. Another recent high profile
| example I can think of is HCL with terraform.
| akavel wrote:
| I actually just stumbled upon an article where someone
| went through HCL and finally landed at Lua:
| http://dnaeon.github.io/choosing-lua-as-the-ddl-and-
| config-l...
| lenkite wrote:
| Lua tables are great for nested configurations like layouts.
| earthboundkid wrote:
| > It's fashionable to hate XML because it was used in a lot of
| places it was a bad fit in the 00s, but at least it's a pretty
| good document language.
|
| > YAML though is always a bad fit. If you want machine readable
| config, use JSON; human readable, use TOML. When does YAML ever
| fit?
|
| https://twitter.com/carlmjohnson/status/1372224080749993988
| forgotpwd16 wrote:
| The human readable part is a bit subjective. I find YAML more
| human readable than TOML.
| j1elo wrote:
| I never got this stance; JSON sucks for config files, because
| as a user, if there is anywhere that I need and am more
| thankful for comments, is in a configuration file. And TOML
| is maybe a good substitute for INI formats, but it doesn't
| really support nested data like JSON would, so suggesting to
| use TOML instead of JSON is misleading except for the
| simplest and most basic needs.
|
| If replacing JSON is the objective, I'd very much rather
| recommend HJSON [1] than TOML.
|
| [1]: https://hjson.github.io/faq.html
| dreamer7 wrote:
| Could your problem be partially resolved by having a key
| called description or comments where you could provide some
| clarification?
| outworlder wrote:
| But now that's part of the data and the parser doesn't
| know any better. Comments are more useful if they are
| close to the thing being talked about.
| mikey_p wrote:
| What about HOCON?
| https://github.com/lightbend/config/blob/master/HOCON.md
| j1elo wrote:
| I guess why not? I mean, there are lots of options here.
| I prefer HJSON, also it helps a lot that its website does
| a very good job at convincing other fellow devs to try
| it...
|
| But there is also JSON5, among the most popular
| alternatives. Then HOCON you mention, and probably a
| myriad more.
| 2bluesc wrote:
| One of the most painful things about using tumxp is modifying
| the YAML to make it useful.
|
| Was hopeful this would leverage TOML as it's built using rust.
| freedomben wrote:
| You can find absurd behavior during corner cases in nearly any
| non-trivial language. YAML is a great language when you need to
| represent objects in something universal and human
| readable/writable. Not perfect of course, but TOML's
| limitations can turn stuff into a monstrosity with it's
| limitations. Ansible inventory files come to mind here.
| eptcyka wrote:
| One can find absurd behavior in corner cases of any non-
| trivial language, but one can find absurd behavior in YAML
| without even looking for it.
| whimsicalism wrote:
| Such as? All these cases with no and norwegian or whatever
| but I haven't run into major problems and use it
| frequently.
|
| e: And, AFAIK, I believe the latest YAML 1.2 spec (from
| 2009) has addressed these issues.
| metrix wrote:
| I use it frequently too, but there's some terrible edge
| cases:
| https://stackoverflow.com/questions/53648244/specifying-
| the-...
| whimsicalism wrote:
| ? I don't think these are issues with Yaml 1.2, the spec
| since 2009.
| eptcyka wrote:
| What about `thing: 1.0` and `thing: 1.0.0`?
|
| Parser implementations have also been buggy. The ruby one
| in particular being a source of RCE's. Of course, these
| are implementation issues, but surely a simpler
| specofication would be easier to implement. And the
| current specification is anything but simple, clocking 84
| pages in the PDF flavour.
| sanity31415 wrote:
| The "no"/"norwegian" thing is emblematic of very sloppy
| thinking in YAML's design, and it's far from the only
| example.
|
| It's possible to avoid these pitfalls - like people do
| with PHP - but why burden users with that in a new
| project when better options have been available for
| years?
|
| They obviously like Rust, why not just follow their lead
| with TOML?
| whimsicalism wrote:
| That "feature" regarding "no" hasn't even been present in
| the YAML spec since 2009.
| renewiltord wrote:
| Thanks for being clear about this and repeating it. I
| didn't know. I think I will only use YAML 1.2 as
| configuration language.
| coldtea wrote:
| The NO alone should give you pause...
|
| It's a language that coerces basic strings...
| parhamn wrote:
| A few months ago, I swapped my iTerm with Alacritty (another Rust
| based project) and have been really happy with how snappy it is.
| I highly recommend it. Looking forward to trying this as a
| replacement for my tmux setup. I like the idea of being able to
| hack on wasm modules. Will there be matching key bindings for
| Tmux?
| 0xbeefeed wrote:
| I personally can't stand not having multiple tabs. Plus, it is
| fast, but it is not the "fastest" as it falsely claims. I
| prefer MacOS's default terminal.app over it.
| ikornaselur wrote:
| Interestingly, about an hour ago, I was looking into Alacritty
| to replace iTerm (because of how slow it feels!). I use tmux as
| well and seeing this project made me wonder if I should test
| out Alacritty + Zellij!
| alpaca128 wrote:
| Alacritty is great, it feels very snappy and it can auto-
| reload the configuration(with a few exceptions), so you can
| quickly try out different settings without restarting the
| program all the time.
|
| I switched to st because Alacritty still has no ligature
| support, but aside from that limitation it's definitely my
| favorite.
| zmmmmm wrote:
| Looks amazing!
|
| Unfortunately it doesn't implement the feature that keeps me
| stuck on Terminator: disabling of line wrapping. After using that
| I could never use a different terminal. But perhaps this could
| inspire me to try and learn enough Rust to implement it :-)
| lolive wrote:
| To me, tmux is unbeatable. Except for 2 things: - session-in-
| session is not built-in (but running a tmux from inside tmux does
| work) - resurrect (I.e rebuilding a complete multiplexing session
| out of nowhere, with running pieces of software, history, etc).
| pkghost wrote:
| I'll be proving the point that tmux is a batteries-not-included
| program with my solution to your "resurrect", but it's probably
| fine for (and unsurprising to) anyone who doesn't mind writing
| a few lines of bash:
|
| I have a bash script by the name of .tmux inside of every
| workspace folder. Its contents are typically a single multiline
| tmux command that creates a new tmux session with all the
| screens and processes relevant to the project (usually: emacs,
| shell for git, ssh to staging + prod, prompts in various
| databases, and several entr-driven screens for automatically
| running migrations, tests, etc).
|
| Separately, I have a shell function that runs every time I
| change directories that checks for the existence of said file,
| and then either runs the file, attaches to the existing tmux
| session associated with the folder, or does nothing (in the
| case that the shell is already in a tmux session).
|
| In short, I setup my workspace once per project.
| bennyp101 wrote:
| This looks pretty cool, I use tmux extensively, and having a
| WebAssembly plugin system could be pretty cool!
| rektide wrote:
| Tab-rs is another rust terminal multiplexer[1].
|
| [1] https://github.com/austinjones/tab-rs
| ktpsns wrote:
| I love that the UI can be explored by the user, since it shows
| available keyboard shortcuts. This is something where GNU screen
| or tmux suck, because you really have to lookup how to operate
| these tools. In some manual or with google.
| edoceo wrote:
| I had to print this
|
| https://tmuxcheatsheet.com/
| des429 wrote:
| fwiw, if youre in tmux you can hit <prefix>-?, so for me it's
| ctrl+w+? and itll show all available tmux commands.
| arunc wrote:
| ctrl-w is a very commonly used key to control vim windows.
| How do you manage with that? I have my tmux leader key
| mapped to ctrl-z as we hardly use it these days.
| nsm wrote:
| Yes, I think more than "written in Rust", what is attractive
| about these tools (and other Unix replacements like Ripgrep,
| FZF) is more their attitude of "we have a lot more computing
| power and higher resolution/larger screens now. let's have
| saner defaults, intuitive UIs or larger search spaces (in case
| of FZF) to actually take advantage of that."
| 29athrowaway wrote:
| The latest version from cargo does not build for me.
|
| edit: After running "rustup update" it does install. I am liking
| Zellij so far.
| alpaca128 wrote:
| It's the typical Rust problem and my biggest gripe with the
| Rust ecosystem: many libraries are using unstable/nightly
| features, making development needlessly frustrating for people
| using the stable Rust release.
|
| Rust devs, please don't. Not every Rust developer uses rustup
| or knows how to solve this issue, not everyone is willing or
| able to use the nightly build just so dependency 21/63 doesn't
| throw errors.
| steveklabnik wrote:
| It doesn't appear that this uses any nightly or unstable
| features. The parent didn't say _why_ this doesn't compile,
| it's probably something else. Maybe they have an older rustc.
| 29athrowaway wrote:
| Nice suggestion. I had not updated my rust installation in
| a couple of months.
|
| After doing rustup update now it installs correctly. Thank
| you.
| WA9ACE wrote:
| I'm not sure I could untrain all my muscle memory I've built up
| over the years with my TMUX configuration, but I truly believe in
| the next 10 years all of my current command line tools will be
| slowly replaced with rust equivalents (with the exception of
| neovim). ripgrep and fzf are already a large part of my workflow,
| and I love seeing WebAssembly becoming the universal plug and
| play standard.
|
| > Build a web client to allow users to connect to a running
| Zellij daemon through the browser (on a local or remote server).
|
| That's the future feature I'm most interested in over TMUX.
| Scarbutt wrote:
| FZF is written in Go though.
| ibraheemdev wrote:
| > I'm not sure I could untrain all my muscle memory I've built
| up over the years with my TMUX configuration
|
| You could quite easily configure Zellij's keybindings [0] to
| mirror your tmux config.
|
| [0]: https://zellij.dev/documentation/keybindings.html
| WA9ACE wrote:
| That's great! As soon as it supports detaching a running
| session I'll take a look at migrating.
| ComputerGuru wrote:
| You can use abduco for that part (but I'll just keep using
| tmux).
| Pawka wrote:
| I believe you could. I can share the story from a bit different
| field. I was using a split keyboard with staggered layout and
| just built an Ergodox because wanted to try vertically
| staggered layout. Another differences are thumb clusters of
| keys on Ergodox and different firmware. So the layouts of both
| keyboards are very different and different customisations can
| be made.
|
| The main thing which I was afraid of was the same as you've
| said - that I won't be able to change my muscle memory. Another
| thing - I won't be able to switch back the old keyboard (I
| expected to use it at the office) or even won't be able to use
| laptop keyboard anymore.
|
| Surprisingly even after getting comfortable with Ergodox with
| totally different layout (different firmware is being used
| between keebs) I'm still able to jump between those easily.
| Maybe the first 5 mins are a bit harder but that is it. This
| surprises me what human brain is capable to do. Of course I
| still need to switch between keyboards regularly to not forget
| the layouts.
|
| Not the same thing but we often are afraid of unknown.
| breuleux wrote:
| > I'm not sure I could untrain all my muscle memory I've built
| up over the years with my TMUX configuration
|
| I assume you can customize your keybindings so that they're
| mostly the same as your TMUX configuration.
|
| But even if you couldn't, based on my own experience changing
| editors/OS/other tools, if you commit to it, retraining should
| take a couple weeks at most. It'll be super annoying for that
| couple weeks but it's really not all that ingrained.
| [deleted]
| _jal wrote:
| I'm curious, why is in-browser use so appealing to you?
| rektide wrote:
| Why not have your software be universally accessible &
| online? What is the appeal in having software that is
| attached to a single system, single OS, & offline?
| ahepp wrote:
| This seems like a very baroque alternative to tmux and ssh
| rektide wrote:
| Let's consider: I'm at my parents, or a friends house. I
| need to log in to do something. My options are:
|
| A) download a terminal emulator + ssh application onto
| their computer & run that, flooding the screen with some
| unknown terminal application.
|
| B) opening a web page & logging in to a Zellij or TermKit
| or whatever session.
|
| Which do you think will seem more baroque to them? The
| web is an obvious, much improved way to do almost all
| software. It's online, universally accessible. A lot of
| stuck, old-fashioned-thinking in this thread. I'm a ssh +
| tmux (or more often ssh + dtach/vim) user myself, but
| it's clear to me this has serious disadvantages, that
| it's not nearly as accessible, as on tap as it could be.
| [deleted]
| WA9ACE wrote:
| Personally I have a TMUX session on a pi4 I keep up that just
| monitors various services and there's times I'd like to be
| able to open it not unlike a dashboard on my phone or tablet.
| Using a session via the web is not a big use case for me, or
| something I'd want to operate exclusively in, but it'd be
| nice to have.
| oblio wrote:
| Where do they mention in-browser use? WebAssembly is used for
| extensibility, but not necessarily for access from a browser.
|
| Am I misreading their blog post?
| WA9ACE wrote:
| It's at the very bottom of the page under "What's next?"
| really easy to miss.
| [deleted]
| dhagz wrote:
| If you're already spending a lot of time in the browser
| looking at stuff (AWS Console, Stack Overflow, etc), I can
| see the convenience of just switching tabs to your terminal
| rather than pulling up a window.
|
| So far I've solved that problem with keyboard shortcuts or
| other macros to pull up a terminal when I need it.
| ahepp wrote:
| Conceptually, I don't think the solution to "switching
| windows is too hard" ought to be "make the terminal part of
| the browser". Although it does seem like perhaps the least
| immediately painful way to solve the problem.
|
| Using Lynx in the terminal might be another way to do it.
| dhagz wrote:
| Yeah, I tend to agree. But I know that there are some
| people who really, really, really like doing stuff in the
| browser.
| jmakov wrote:
| Looks like a cool Byobu alternative.
| xfalcox wrote:
| Do you plan on supporting mouse shortcuts? I currently use byobu,
| and it's useful to start scrollback mode on mousewheel up
| sixstringtheory wrote:
| Lots of mentions of tmux but none yet of tmuxinator:
| https://github.com/tmuxinator/tmuxinator
|
| Lets you predefine layouts and what will run in each pane.
| cassepipe wrote:
| I would love to see a small screen ready made option mode that
| uses tabs as default instead of panes because panes don't make
| much sense on a small screen.
| CodeIsTheEnd wrote:
| The resizing algorithm looks cool: panes are no longer in a
| grouped hierarchy of vertical and horizontal splits, as in tmux
| or vim, and pretty much every other customizable layout tool. In
| a grid of four squares, a corner can either be resized in either
| direction and only modify one other pane. (It's hard to explain;
| it's shown in the demo gif.) I wonder if you can make "holes"...
|
| Rearranging a layout with more than 3 panes in tmux or vim is
| always difficult. In tmux it's at least easy to swap panes
| (C-prefix '{' or '}'), but vim doesn't have any simple way to do
| something similar. I wonder if Zellij's approach makes it any
| easier. Maybe it's a UX pattern that is made easier with a mouse.
| leshow wrote:
| I think the vertical resize of the "before" is the wrong one.
| Shouldn't it be also resizing the window next to it?
| DangitBobby wrote:
| I think you're right, I was wondering the same thing.
| tlaundal wrote:
| The first illustration shows how this works in tmux. The
| illustration first has a split in left and right half (vertical
| split?) and then a split in top and bottom (horizontal split?)
| of each of the halves. So if you resize one of the panes
| vertically, it only affects the other pane in the same half of
| the window, while if you resize horizontally all the panes will
| be resized. Basically vertical resizing only resizes the inner
| split, while horizontal resizing resizes the outer split.
|
| It seems Zellij somehow makes the order of the splits
| irrelevant.
___________________________________________________________________
(page generated 2021-04-22 23:00 UTC)