I feel compelled to reply, because a lot of this contradicts my experience. I use wezterm + tmux on linux, iterm + tmux on mac. (Already an advantage there, tbh)
> vim bindings should already be available in your emulator, without the need for tmux
They may mean things like the vim-tmux navigator plugin, which makes it so if you hit e.g. the left-most window in vim and hit your go-left keybinding, it will go one tmux pane to the left. It's pretty crazy how seamless it is, and it's made possible by the fact that you can query tmux outside of the process and run commands on your running sessions, which I'm not sure you can do with any of the standalone terminals?
Tmux also doesn't prevent you from using c-x e. I'm aware of the vim terminal, but I'm very picky about my multiplexing and have not been satisfied by any built-in terminal in any editor.
> You just have to remember that a session is the same thing as a window.
A session is certainly NOT a window. It is a buffer. There is a difference, and that difference matters and comes with advantages that are separate from the advantages of windows.
> First off, switch because your emulator is probably more resource intensive
I'm not entirely sure if this is true, but it's utterly uncompelling to me. Holding my binding for 'switch window' will switch through n windows faster than I can mentally digest, and the lag is lighter than any gui app I've used.
> It may also be missing modern features like being able to view images (see sixel, chafa, or the kitty graphics protocol), ligatures, and a lot of other features
I'm not sure why you'd assume this? My setup (wezterm or iterm + tmux + fira code) indeed has ligatures and sharp image viewing passed through the multiplexer
> Second, tmux lacks many of these modern features. Doing a passthrough can help but dealing with images is not a great experience. I have found no configuration where I can reliably view images and never have been able to produce images of the same quality. I always drop out of my session if I am entering a file browser like yazi or fzf
Yazi is exactly what I use, and it works great with iTerm + tmux or wezterm + tmux.
I really don't want my terminal to do that much for me to be honest. I change terminals every couple years, and it's nice to not have to fuss around with them whenever that happens. I haven't changed my tmux config in about 15 years
Curious what kind of flours you're getting, and which ones you object to. I make sourdough fairly regularly and just use 30% whole wheat, 70% standard bread flour and have never thought twice about it?
I've lived my whole life in the southeastern US, and the comments online about this always make me feel like an alien. Everyone here always seems to imply that it's meaningless because "You have to say 'good', and if you don't say that people get upset," but I've just never once had that experience.
I almost never say 'good' in response to that question, even to a coworker I don't know well. In my friend groups, usually people will be straightforward about how they're doing as well. Maybe people don't know how to say 'bad' without following up with a story? It's easy once you start doing it. "Not great, but it's fine" or "I'm just keeping along / taking it day by day" is a fairly common response to get from me, especially lately, and it's always honest. Sometimes I will just say "TBH this week completely sucks for me" before continuing with what the conversation was about originally. If things are going well I will be effusive in my (still short) response ("I'm doing awesome actually"). And I do care about how the other person is doing when they respond. I've even gone so far as to ask, after finding out about bad news later in the conversation, "Damn, why'd you say you were doing well?".
I find it to be a deeply useful way to start a conversation. If you ask how I'm doing and you don't know me well, and I say something to imply I'm not having a good day, it completely changes the way the conversation should be conducted. Same goes for the other person's response. You always start every conversation on the same page ('how impatient / stressed is the other person right now?' is one of the most important pieces of context you can have). Over time, I've even found that it has the benefit of making me reflect on a regular basis on how I feel in the moment vs how I'm actually doing on a longer-term scale.
This is kinda similar to something I'm trying to setup. I have most of my self-hosted infrastructure running in docker containers, but I want to put some stuff on a nixOS ec2 instance. Mostly services I want to never go down or be affected by my local network (uptime kuma) and chat stuff (irc bouncer, conduit, soju, etc etc).
I use nixOS on my laptop but don't make many nix projects, and TBH I have no idea how to test this setup locally before deploying it. I have some nix stuff setup that spins up a VM and exposes the ports on localhost, but it's brittle and rapidly spaghettifying. Do you have any tips for testing this stuff as part of a local project?
On my NixOS laptop I you can setup services I'm interested in trying, but just run them locally. So I don't setup things like SSL (you can, it sometimes just makes getting a new SSL cert for that same domain take some time). I just update my /etc/hosts to the local IP and can give that a go
For trying out the more complicated setup parts, like SSL, Tailscale, etc, I created a NixOS VM that I setup the same way I wanted for my "production" use case. Once I have the config file the way I wanted, it's as simple as moving it to my non test VM (baring previous mentioned SSL issues). And I only tested one part at a time, adding them together as I went
But also, one of the great things about NixOS is it's really easy to incrementally try things and rollback. Once I got the skeleton of the setup working, I've mostly done my testing on my "production" server without issue
> That said, Nix-the-language also suffers from all the same birth defects that manifest themselves in frontend development
That must be it. The GP's comment really resonated with me, in that learning scheme felt like no task at all whereas I STILL feel uncomfortable with the nix programming language and ecosystem despite using nixOS exclusively on my personal laptop for two years and on my work machine for about half a year now. I've always fumbled over frontend / javascript development though, and avoid it as much as I can at work although I still end up working in it every year or so.
Nix only won out for me because of the mac compatibility, without which I can't really use it at work
I think nix-the-language is pretty simple and easy to learn language. It's visually hard to parse and a lot of syntax decisions make you wonder, but it's not the worst.
The problem is that you're very rarely exposed to it directly. You are always multiple layers of abstractions away from it. Most of these layers are completely undocumented.
This is an interesting project. So the whole thing is hosted at gemini://station.martinrue.com, with no way to host other instances? Stuff like this that leverages the default TLS nature of gemini is pretty exciting. I'm going to have to set up an account later to check it out.
Edit: Checked it out and this is definitely a cool idea. Is there any way to change the unicode emoji next to your name?
I don't see anything about carbonated beverages in those comments? I've had good results with some of the exercises mentioned there, but since then have been in a rut unable to make it stop (my only symptom of GERD is a small persistent cough, which sucks more than it sounds like). I drink a lot of sparkling water though. Do I need to give that up too?
The stuff I'm working on never feels worth sharing, but I am doing a lot of computer stuff lately. It's kind of the year of moving towards declarative setups for me.
- Migrating to Niri on my laptop and re-evaluating my literate config approach, switching from xkb configs to kanata and a few other QOL changes to make my tooling more composable and expressive
- Shoring up my blog / media sharing infrastructure (migrated to a landing page on an s3 bucket, with different prefixes for several different hugo deployments for different purposes, still need to get better about actually posting content)
- Preparing to migrate a bunch of my self-hosted services to a k8s cluster which can can be fully deployed locally for testing and defined in code. All this is managed through argo and testable with localstack and crossplane for some non-local resources
- Attempting (somewhat unsuccessfully) to setup a nixos config for a bunch of services that just don't feel right to run in containerized stack that I want to live in ec2 and have as close to 100% uptime as possible (uptime kuma, soju/weechat relay/bitlbee, conduit, radicale, agate, whatever else I think of that is small and has a built-in nixOS service module. Thinking about some kind of RSS aggregating solution here as well)
- Experimenting with vibecoding by trying to get an LLM to do the legwork to build a TUI interface to ynab using rust (which I don't know how to write)
I'm hoping that by the end of this summer most of the tooling I use for most things will be way more concrete and seamless. I also want to get my workflows down and get on top of converting at least a few the ~100 draft blog posts I have laying around into something I can actually post. Ditto for my photography albums, which are not yet organized into coherent groupings or exported for web.
Building a TUI for ynab is pretty compelling, so I wouldn't say that's not worth sharing. If you could pull the data on terminal startup and get a budget snapshot each time you open a terminal-- cool.
So far that experiment is going pretty well! I haven't worked much on it but the tooling I'm using has made a great base for the project. My goals (in order of priority) are:
- Get it so that you can categorize transactions quickly in a keyboard-driven way
- Similarly have a quick, improved option for dealing with overspending / underfunding
- Add some additional reporting that I'd like to see (as well as the ability to drill down in a more fuzzy way than currently supported in ynab)
- Finally (and most importantly but also most ambitiously) develop a view with some simple tools that helps users figure out WTF is wrong when a reconciliation isn't working out. This is much harder than the other things I'm trying to do here
Luckily YNAB's API is very open and I think I can do all the things I'm looking to achieve here. If I'm successful, I plan to spin off a sister TUI project for making handling import edgecases easier in beancount, which I also use but for different reasons
Edit: but your idea of having CLI command options for printing reports on a regular basis / on opening the shell is also neat, I do plan to have some CLI options that don't require you to open the full TUI
I felt like it was a weird hangup too until I realized that the lifespan of my phones has dropped to a third since that damn jack disappeared. Every single phone since then the point of failure has been a worn out / chewed up USB port.
Turns out, when you have to use the same port for all music streaming as well as charging, you end up using that port (in my case) something like 1000% more often, and it absolutely demolishes the phone.
> vim bindings should already be available in your emulator, without the need for tmux
They may mean things like the vim-tmux navigator plugin, which makes it so if you hit e.g. the left-most window in vim and hit your go-left keybinding, it will go one tmux pane to the left. It's pretty crazy how seamless it is, and it's made possible by the fact that you can query tmux outside of the process and run commands on your running sessions, which I'm not sure you can do with any of the standalone terminals?
Tmux also doesn't prevent you from using c-x e. I'm aware of the vim terminal, but I'm very picky about my multiplexing and have not been satisfied by any built-in terminal in any editor.
> You just have to remember that a session is the same thing as a window.
A session is certainly NOT a window. It is a buffer. There is a difference, and that difference matters and comes with advantages that are separate from the advantages of windows.
> First off, switch because your emulator is probably more resource intensive
I'm not entirely sure if this is true, but it's utterly uncompelling to me. Holding my binding for 'switch window' will switch through n windows faster than I can mentally digest, and the lag is lighter than any gui app I've used.
> It may also be missing modern features like being able to view images (see sixel, chafa, or the kitty graphics protocol), ligatures, and a lot of other features
I'm not sure why you'd assume this? My setup (wezterm or iterm + tmux + fira code) indeed has ligatures and sharp image viewing passed through the multiplexer
> Second, tmux lacks many of these modern features. Doing a passthrough can help but dealing with images is not a great experience. I have found no configuration where I can reliably view images and never have been able to produce images of the same quality. I always drop out of my session if I am entering a file browser like yazi or fzf
Yazi is exactly what I use, and it works great with iTerm + tmux or wezterm + tmux.
I really don't want my terminal to do that much for me to be honest. I change terminals every couple years, and it's nice to not have to fuss around with them whenever that happens. I haven't changed my tmux config in about 15 years
reply