Reading https://codeberg.org/river/river/src/branch/master/protocol/river-layout-v3.xml it seems to me that what I want to do is actually not possible in river, even writing a custom layout manager…

IIUC the protocol works like this: river asks “how should I layout N windows in HxW screen?” and the layout replies “window1: H1xW1 at offset X1,Y1; window2: H2xW2 …”, so there is no way for the layout manager to identify specific windows and, in my use case, put all the text editors on the left side of the screen etc.

Did you have some other approach in mind when you suggested river? (I may very well be over-complicating things and not seeing a more straightforward solution)

TBH I really liked the idea behind river, but does it have tabs? Also… I would need to write my own custom layout, wouldn’t I?

BTW: are there other WMs that are modular like river?

Sorry to be a bother, but… how do I tell hyprland I want a window to be added to a specific group?

I was thinking of something like:

windowrulev2 = tag texteditor, class:(myfirsteditor)
windowrulev2 = tag texteditor, class:(mysecondeditor)
windowrulev2 = group XXX, tag:texteditor

but I can’t find what I should write instead of group XXX to tell hyprland/hy3 that I want the window to be added to a group on the left-side of workspace 1…

I would also be fine with some rule that could be added to exec or probably even some dispatcher, but I can’t find anything that allows to target (or define) a specific group.

Am I pursuing this from the wrong direction?

Philosophy aside, the practical issue with your terminal emulator having to support your shell is… that one does not use just one shell: what happens whenever you start a repl or an whatever program that has interactive sessions (say, for example, psql or parted)?

tightly integrated shell and terminal emulator support. There are just things you cannot do with these being separate things.

I can’t think of any, but I’m not the most creative person… what do you have in mind?

Having something that is like (say) tmux+fish could make sense, but only if it’s something that outweighs the lost flexibility of being able to combine <whatever shell you like> + <whatever terminal multiplexer you fancy>.

Might I add the idea that your terminal emulator must support your shell is utterly ridiculous?

https://docs.waveterm.dev/reference/faq#what-shells-does-wave-terminal-support

https://docs.warp.dev/getting-started/using-warp-with-shells

Also Wave might be FOSS but if you look at the footer in their website it says it’s backed by venture capital… how would you estimate the chances it gets closed, paywalled or otherwise enshittified?

That’s not something a terminal emulator should do - it’s a feature that belongs in your shell :)

Irrelevant: the goal is not preventing shootings (I mean, they would go for the obvious solution otherwise)

Why did they call them ‘gold’ and ‘silver pro’?

I hate them (seriously).

It’s basically a second distro inside your distro (try du -chs /var/lib/flatpak/) and if something breaks (eg. last year mesa with my graphics card) it isn’t easy to identify were the problem is (because all libs update at the same time), plus you can’t just try a newer (or older) version of some lib as you would in your distro.

Moreover, you can’t flatpak CLI tools (also servers and OS components, but I guess the ubuntu folks are the only ones who care about those).

btw :)

only dangerous for around 500 years

That “only” is just ridiculous :)

Just try to imagine the history of a nuclear waste storage site from the 1500s… how many budget cuts would have it seen? how much buck-passing when it changed hands as a result of war of revolution? how many times would it have been bombed? (and it’s not like we’ve had bombing for a very long time).

We are just not responsible enough to play around with nuclear. Hell, we are showing we are even not responsible enough for hydrocarbons.

(yes, I do know some amount of nuclear waste, from medical applications etc., is definitely worth it and unavoidable - let’s just keep it to a minimum)

AFAIK a sunken reactor is not as big of a threat to life as a one (marine or land-based) that releases nuclear material in the atmosphere, so the biggest issue should be what may happen before the reactor sinks.

Anyway IMHO the biggest issue with nuclear is not its safety, but rather that, even when it operates without the slightest of incidents, it produces waste that needs to be kept “safe” for periods of time that exceed the age of most nation states (let alone private companies).

I use just for that usecase - highly recommended

I fear I am not enough reverse (or Polish, for that matter) :)

Anyway, I have great esteem for you (if you actually use forth and are not just trolling)

Also you mentioned provisioning scripts, is that Ansible? If so python is already there, if you mean really just bash scripts I can tell you that does not scale well. Also if you already have some scriptsz what language are they on? Why not write the function there??

Currently it’s mostly nixos, plus a custom thing that generates preconfigured openwrt images that I then deploy manually. I have a mess of other vms and stuff, but I plan to phase out everything and migrate to nixos (except the openwrt stuff, since nixos doesn’t run on mips).

I don’t really need to run this specific synchthing-ID script except on my PC (I do the provisioning from there), but I have written scripts that run on my router (using busybox sh) and I was wondering if there is a “goto” scripting that I can use everywhere.

Elixir is quite big (yeah, it’s certainly smaller than something like java… sorry for not specifying what I mean by “small disk footprint”).

Thats basically what ansible does. Thats basically what ansible does. If you plan on doing this to multiple machines you should just use ansible.

Ansible requires python on the target machine (or a lot of extra-hacky workarounds) so… I could just use python myself :)

BTW getting ansible to do anything besides the very straightforward usecases it was meant for is a huge pain (even a simple if/else is a pain) and it’s also super-slow, so I hate it passionately.

Also how do you plan on ensuring the scripting interpreter is installed on the machines?

Ideally I’d just copy the interpreter over via ssh when needed (or install it via the local package manager, if it’s available as a package)

nim is great, but it is >200mb (plus AFAIK it is compiled… does it also have an interpreter?)

Installing node uses some 60MB (according to zypper on my current desktop). I’d rather have something small and possibly that consists of a single executable.

As a bonus, both support the vast and extensive NPM package repository

That’s not necessarily a feature :) Package repos are great if you are a developer (I am one) working primarily with that language, but are frustrating if you just want to run things.

Let alone the reliability, I somehow doubt my router would be able to run an LLM :)

Why aren’t python and bash be available in all your systems?

Among others, I run stuff on alpine and openwrt.

I don’t need to run these scripts everywhere (strictly speaking, I don’t need the homlab at all), but I was wondering if there’s something that I can adopt as a default goto solution without having to worry about how each system is packaged/configured.

As for python, I doubt the full version would fit in my router plus as said I don’t want to deal with libraries/virtualenvs/… and (in the future) with which distro comes with python3 vs pyton4 (2 vs 3 was enough). Openwrt does have smaller python packages, but then I would be using different implementations on different systems: again something I’d rather not deal with.

As for perl, it would be small enough, but I find it a bit archaic/esoteric (prejudice, I know), plus again I don’t want to deal with how every distro decides to package the different things (eg. openwrt has some 40+ packages for perl - if I were doing serious development that would be ok, but I don’t want to worry about that for just some scripts).