saulrh

I think one obvious approach would be to assign "roles" - one person is "operations" and is the only one allowed to read the instructions to you, one person is "research" and has access to the list of ingredients, etc. But that probably bottlenecks things too hard and you have to figure out a fast way to assign roles. You could just increase the difficulty by requiring more precise instructions? Ah, you split the list of instructions into four parts and put one list in each corner of the classroom, then randomly sort people into the corners - one corner has ingredients, one corner has operations, one corner has conditionals, one corner has goals, and the class has to communicate to build valid instructions. Maybe give the ingredients tongue-twister names and make them devise ways to communicate without getting things confused. And obviously the end of the demo is "so why didn't any of you just take a list of ingredients and walk over to the list of operations so you didn't have to shout?".

You know, looking back at this eight hours later, I realize that this post sounds way worse than I intended. I was attempting to signal my own epistemic uncertainty, not imply sarcastic dismissal. Sorry. :/

I believe the search keyword for what you're looking for is probably "IP KVM".

If you're starting over with a new backing store using jj's pluggable backends, can you give us a native lazily-materialized store for megarepos? It's a tragedy that the open-source world has no answer to piper.

I know someone who uses a Twiddler full-time, and I used mine for about a month when I broke my dominant hand about a decade ago. Works very well if your hand is the right size for it.

I have a tap strap, but I use it mostly as a remote control for my TV, not as a primary input device. It probably works, but I'm not good enough with it to have the kind of error rate I'd really like.

Android has a Morse input method which would be entirely suitable for one-handed text input and there are certainly solutions for using an android phone as a keyboard, but I don't know how it'd handle things like arrow keys.

I had those speakers for a few years before someone else noticed it, lol. The other tweeter worked just fine, and the speakers as a whole were so good that even without the dedicated hardware for higher frequencies it was still better in those ranges than what I'd been using.

I don't know how likely it'd be for something like that to turn out unsalvageable. I think that essentially everything at that level uses wooden enclosures, so it'd come down to whether the speaker bit is set into the wooden enclosure with screws or adhesive, and I don't know about the industry enough to know what the ratio is on that. Probably mostly screws. Then getting a compatible driver is probably guaranteed, at worst you have to replace both sides to keep them balanced.

Works even if you're not in a college town. I once pulled a $4000 set of speakers out of my building's trash room - Boston Dynamics floor speakers, Polk Audio subwoofer - and I was just in a random apartment building in the bay area. Turned out the tweeter on one of the speakers needed replacing but that was like a $40 part on eBay and ten minutes of work with a screwdriver, didn't even need a soldering iron. You can get some crazy stuff if you're in the right building. Really sucks seeing it go to waste when it isn't something you can take, I always have to fight myself to leave some things behind.

I'll point out some higher order impacts of this, since the article doesn't: Losing these forecasts will be catastrophic for American farmers. Crops literally live and die on weather forecasts; forecasts tell farmers what to plant, when to plant it, how to plant it, how to water it, and when to harvest it. Without these forecasts we will see negative effects on the entire American agricultural industry and all of the people it feeds, US citizens or not. I'm not a farmer myself, so I can't tell you exactly how severe the impact will be, but there will be an impact, whether it's an immediate crop failure and outright famine this year or "only" shockwaves bouncing through our entire economy as farmers plant the wrong crops and go out of business over the next few years. This is one of the scenarios I've been most worried about when it comes to the stability of human civilization, up there alongside the looming specter of nuclear war and the randomisation of US foreign policy.

Chronic traumatic encephalopathy and tax deductions, as far as I can tell.

Tramp is perfectly able to write, it's just that it does it by writing a temp file locally and then using ssh to transfer the file to the remote, rather than installing a copy of itself on the remote and acting through that. It only uses executables that it finds on the remote. So if make and gcc and sed and such are available it's basically transparent, indistinguishable from local editing except for network round trips, and the only changes it leaves behind are the files you edit.

The alternative is suggested by tramp, which from what I know treats the remote as a network filesystem instead of an execution host. I don't believe that tramp deploys any binaries: it reads and writes bytes over pipes and all meaningful execution happens locally. Notably, it does not achieve persistence, because there's a difference between "VSCode plugins have access while you're SSH'd in" and "VSCode plugins have access forever".

I guess I was thinking in terms of the patches you push up to github. `jj` is a joy to use and it absolutely enables me to implement workflows that I wouldn't even vaguely consider without it helping me; the big one I think of is the one where you work in a merged dir with like six parents and use `jj absorb` to instantly spread your changes out to the different PRs. I've been forced to do that in git. It was a nightmare and took me two days. Not impossible! Just utterly impractical. `jj` takes end results that were theoretically-possible-but-practically-infeasible and makes them usable. Which I suppose counts as a new capability from the UX perspective. :P

The thing about jj is that it doesn't actually enable any new capabilities. I tell people to use emacs or vim or vscode or whatever instead of notepad because it gives them new capabilities, things that are simply unavailable unless you're talking to an LSP or running a full-powered scripting engine. jj doesn't make anything possible the way going from notepad to a real editor does. What jj does do is it makes everything so much easier that you can now actually use all of those features that git theoretically gave you. Rebases? No more fiddling, no more wedges, no more digging through the reflog because you fat-fingered something, you just go `jj rebase` and... that's it. And if you get it wrong, you just do `jj undo` and... that's it. And if you just had a six hour manic coding marathon without committing anything and now you want to spread its batch of changes back down through your patch stack, you just do `jj absorb` and... that's it. It's not the difference between notepad and emacs where you're going from no LSP to LSP, it's the difference between emacs@2016 where LSP support is a week-long adventure and emacs@2024 where LSP support is five lines copy-pasted out of the info page.