Maybe ask if he has ever exceeded the speed limit, or run a red light, or failed to signal a turn. All things that could be monitored by a smartphone and reported to the police automatically.
Have him publish his full name, date of birth, social security number, mother's maiden name, bank checking and routing numbers, credit card numbers + expiration dates + cvv numbers, nude photos of his wife, nude photos of himself, all of the search history from all of his browsers online, all visible to the public.
Surely he doesn't see any point in keeping any of that information private, he's a good guy and not doing anything wrong, therefore he has nothing to hide and no use for privacy.
Yes, of course. What I'm trying to communicate is that if you're just doing things locally you can get all the benefits (sin sessions) from modern terminal emulators. Most people are using panes and tabs but switching to another terminal emulator will get you these and much more. If you're using the default terminal emulator, you should probably switch (you're installing a program anyways, right?).
That said, I still use tmux. Almost every day in fact. Because all my work is being done on a machine I'm not sitting in front of. This even includes at home. My main desktop is connected to a TV for videogames and movies. When I want to do work on it there's no difference if I'm sitting in front of my laptop or it other than it sitting in my livingroom keeps it cooler and gives it better air flow.
Edit:
Locally: my terminal emulator (ghostty) can do everything tmux can. I can do sessions (windows), panes, tabs, and all that. But with ghostty I also get images, a lower memory footprint (than stock emulator), lower CPU usage (than stock emulator), ligatures, and everything else. It is strictly better.
But I can't do {widows,panes,tabs} with remote connections. Hence, tmux. Which in that case, I will frequently give up capabilities (like images) for that.
You don't mention the persistence of tmux sessions, which I find very useful for local development. Does ghostty have a client-server architecture too?
I mean having long processes(batch jobs, backups, compiling, etc...) or even your opened terminal apps like your code editor or claude code don't get interrupted/killed if you accidentally close your terminal, or you terminal/desktop environment crashes/freezes. While essential for doing dev on remote servers IMO cause of "networks", is useful for local stuff too.
Tmux is going to solve some problems that your standard emulator won't solve. I agree.
BUT
1) I'm unconvinced the things it solves that emulators don't do are common situations
2) tmux isn't "free". There are trade-offs that you have to make for tmux.
There's definitely edge cases where I do run tmux locally, but I find them rare and there's usually another solution (and I definitely do a lot more "weird things" than the average user will, so I run into more "edge cases").
But most users are turning to tmux for the {tabs,panes} feature (and then using sessions like anyone would use a window).
> interrupted/killed if you accidentally close your terminal
Sure, I get you, but I'm also not sure what tmux is doing for you in most cases. I'll give you that it's easier to kill your terminal pane than it is to kill the tmux server, but it is still easy to kill a pane or tab in tmux. I think there's better defenses here to prevent those mistakes. I mean you can just put a window in a different workspace and get very similar defenses as to what tmux is giving you. You're right, that isn't a reliable defense, but that's true about tmux here too.
If you have a process running that needs to stay alive for long periods of time then does it need to be running interactively? It is pretty rare that long running processes need be running interactively. Not rare in the sense that an average user is going to do this infrequently, but rare in the sense of few users are going to do this infrequently.
- You can always throw running jobs into the background by doing: <C-z> (suspend), `bg` (resumes program in background), and `detach` (so the process is not attached to the current terminal instance).
- If you're launching a job consider using `&`
- Remember, you can always reattach to a running process too. If you still have the terminal open it is trivial with `fg`. If you don't, then you can still attach with strace or gdb, but you'll probably need `sudo` and this isn't exactly trivial.
- If you know your job needs to be interacted with then there's better ways to handle that communication like by setting up a pipe. But that requires forethought.
- or the best option is to actually run it as a service since you'll get a lot more benefits and flexibility through that. It's pretty quick to turn anything into a systemd job.
- You can interact with systemd jobs if you set them up that way. Lots of fancy options here from ttys, pipe, sockets, or containerizations.
- systemd-nspawn or systemd-vmspawn. Containers are honestly the best option for long running but interactive jobs.
--- Aside ---
Batch jobs:
script and should run in the background. Are your batched jobs not scripted? Just copy paste your loop into a file and add the header. I typically add a few more lines for logging and stuff but yeah. I mean if I want that output I usually want that output longer than my session will be alive, so logs. That way they also are organized.
Backups:
unless you're doing a quick rsync then this really should be automated. A service is the solution. If you find yourself needing/wanting to manually run, you can also just call the systemd job. But yeah, if I have a one-time big sync, I'll pull up tmux (or caffeine). But that's different than always running in tmux.
Compiling:
I'll be honest, locally I rarely have long compiles (or anything over a few minutes). Anything that is long and repeated should be incrementally compiled. I mean this is a much more robust strategy anyways and in a long compile there's a lot of potential disruptions that are far more likely than me closing my terminal window. But in those rare instances I usually throw the process into the background (or start with `&`) or will turn on caffeine or whatever to keep my machine awake.
--- /Aside ---
> or you terminal/desktop environment crashes/freezes
This seems like a more complicated issue. Depends on the crash, right? But how often are you crashing? If frequently enough that you're going to default to running in tmux then I think you have bigger problems. Honestly, I don't think I can remember a time where only my DM or terminal crashed and the whole system didn't go down. Well... DM on a boot, but that's not the situation we're discussing. Maybe if I did something stupid like try to mess with the DM while the DM is running, but... I mean... tmux isn't going to fix the root problem... IDK if it will fix any problem there...
I'm not sure how often ghostty calls the window-save-state command but it looks like you should be able to call this frequently, though I haven't tried it and I'll give you this one because this definitely requires more work. Though ghostty will survive a reboot and you need a plugin for that with tmux. But either way, this is related to the lesson of backup often. Or commit frequently.
> While essential for doing dev on remote servers IMO cause of "networks"
If we're talking about remote, well that's why I use tmux every day. I didn't say there's no point to tmux, just that the vast majority of things it does *locally* can be accomplished without it.
I'm 100% supportive of tmux with remote connections.
If you're having that spotty connection then I think the better solution is using something like mosh or the best option is configuring better timeouts in ssh{,d}_config. Look at `TCPKeepAlive`, `ServerAliveInterval`, ServerAliveCountMax` (s/Server/Client/g for sshd_config)
I cannot phantom why anyone would write lengthy walls of text trying to convince people "no askhually, your workflow is invalid and theres a better way!11" after they've told you very directly and clearly several times that this works well for them. People have different preferences. People are telling you that this works well for them. They don't really don't need to be condescendingly "educated". Learn to listen.
Neural networks absolutely are designed. Network architecture is one of the primary innovations in NNs over the years, and transformer architectures are the biggest development that enabled modern LLMs.
In addition, behavior is designed indirectly through human reinforcement.
The individual weights aren’t designed themselves, but there is a ton of design that goes into neural networks.
I'm admittedly out of my depth, but think the point is the current state of architecture is one of rapid and volatile iteration. There isn't really a comprehensive "design" because each generation is building (and in some cases rebuilding) upon the previous generation.
I found that the "udm" trick disables all "rich content" in search results (ie: stuff that isn't a plain text search result link). But adding the following user rules in AdGuard for Safari does the job:
I use a cheap 75hz IPS from my office, though, ideally, I'd like to upgrade to a 240hz+ OLED w/ VRR since macOS now supports adaptive sync[0]; i've been waiting because I'm not satisfied w/ any of the OLED monitors currently on the market and my monitor upgrade request was denied by my employer.
Though I've used the Apple Magic Keyboard w/ Touch ID exclusively for awhile, I'm also thinking about upgrading to the new Wooting 80HE keyboard this fall since it has a 8kHz polling rate, analog hall effect switches, and is designed to be ultra low latency w/ tachyon mode enabled.
Very cool! I love 2D visualizations. I built https://pubg.sh many years ago; the telemetry format is quite similar actually. I know that professional PUBG teams use my tool for post-match analysis, I wonder if professional soccer teams have anything similar in-house, there's all sorts of things that you could track and visualize.
Next time ask him if he'd be OK living in a glass house, since, as he's not a bad guy, he has nothing to hide.