You need tmux to be able to resume the same session from anywhere, mosh-server to make ssh resilient to sketchy mobile connections, and blink shell https://blink.sh/ to have a high quality iOS shell with a mosh and ssh client built right in to resume at any time.
Far more resilient and performant than a web client.
yes but I've never seen a terminal interface embedded in a browser that is as good as a native terminal app interface, and blink shell has been well worth the upfront cost to me (way better than Termius, which was suggested in the writeup)
I usually pair Claude with tmux, so you can move the cursor around the Claude output and copy, scroll, etc. that buffer is definitely the way to go. And within the chat box, Claude respects known eMacs/GNU shortcuts for cursor movement, so I like that more than Copilot.
It's not. When using Claude Code (or similiar)you get a lot of problems in every shell about flickering, not being able to copy, not being able to move text cursor and so on. It's bad UX
If using TMUX you can "ctrl + b [" to enter copy mode and then you can move cursor as you wish. I wrote about this stuff too on https://mjqs.blog/meta/
> and blink shell https://blink.sh/ to have a high quality iOS shell with a mosh and ssh client built right in to resume at any time
I really like Termius, have you tried it? I think I tested out Blink when I was trying various SSH/shell apps and
chose Termius over it, but it’s been so long now that I completely forget why.
EDIT: does Blink give you a local shell as well like vs only SSH/mosh?
Yes, Blink gives you a local shell with some tools (not extendable), including Vim. It is even possible to mount a remote repository (we call it a Bookmark), and edit locally.
Give it another chance if you want to, I’m always happy to help.
Is Blink’s shell different from something like iSH which gives you a local shell inside an Alpine Linux VM? Is it some kind of native iOS shell or is it also a Linux VM of some kind?
Yes, but you can't leave it running and working on something and then resume from wherever that left off that way from wherever you are.
Or are you saying you can resume a conversation that is still open in another terminal? What happens to the old terminal if you accidentally type into it? Will it overwrite the conversation?
Very anecdotal but for me this model has very weak prompt adherence. I compared it a tiny bit to gemini flash 3.0 and simple things like "don't use markdown tables in output" was very hard to get with m2.1
Took me like 5 prompt iterations until it finally listened.
But it's very good, better than flash 3.0 in terms of code output and reasoning while being cheaper.
Installing Valetudo stops any firmeware updates forever from the OEM. [1]
I wouldn't consider it a hack. It's an alternative way to run your vacuum, with yes potentially less features if the OEM makes a lot of future updates, but Valetudo also comes with their own set of updates.
CloudFront has quotas[0] and they likely just hit those quota limits. To request higher quotas requires a service ticket. If they have access logs enabled in CloudFront they could see what the exact error was.
And since it seems this is hosted by Atlassian, this would be up to Atlassian.
A new language feature is released, you cannot apply it to old code, since that would make a big PR. You need to do super slowly over time and most old code will never see it.
A better static type checker, that finds some bugs for you, you cannot fix them as your PR would be too big, you instead would need to make a baseline and split it up endlessly.
In theory yes, maybe a bit safer to do it this way, but discouraging developers to make changes is bad IMO.
Obviously depends on your usecase, if you develop software that is critical to people's literal life, then you'll move more carefully.
But I wager 99% of the software the world produces is some commerce software, where the only thing lost is money.
> A new language feature is released, you cannot apply it to old code, since that would make a big PR.
Good. Don't change code for the sake of shiny new things syndrome.
> A better static type checker, that finds some bugs for you, you cannot fix them as your PR would be too big,
Good. Report each bug separately, with a suggested fix, categorised by region of the code. Just because you ran the program, that doesn't mean you understand the code well enough to actually fix stuff: those bugs may be symptomatic of a deeper issue with the module they're part of. The last thing you need is to turn accidentally-correct code into subtly-wrong code.
If you do understand the code well enough, what's the harm in submitting each bugfix as a separate (independent) commit? It makes it easier for the reviewers to go "yup, yup, yup", rather than having to think "does this part affect that part?".
You can create venvs wherever you please and then just install stuff into them.
Nobody forces the project onto you, at work we don't even use the .toml yet because it's relatively new, we still use a python_requirements.txt and install into a venv that is global to the system.
> [...] at work we don't even use the .toml yet because it's relatively new, we still use a python_requirements.txt and install into a venv that is global to the system.
Unless your `python_requirements.txt` also carries checksums, like uv's lock files or poetry's lock files, that is. Though of course things get spicy and non-reproducible again, if you have then multiple projects/services, each with their own `python_requirements.txt`, all installing into that same global venv ...
- ships with web server that has a UI you can open in your browser, even access remotely with tailscale or so
- the server has an API to do almost all things allowing you to build on top of it, the people at ramp build a very advanced internal agent on top of OpenCode https://builders.ramp.com/post/why-we-built-our-background-a...
reply