Hacker News Reader

Comment by Animats | Hacker News Reader

Stupid slowness keeps creeping in. About four months ago, "bash" on Linux started having visibly slow character echo. Some update to Ubuntu 20.04 LTS added something. No idea what. Spell check? LLM-based command completion? Phoning home?

View on HN

If it happens on a remote machine, maybe this:

https://man.openbsd.org/ssh_config#ObscureKeystrokeTiming

https://news.ycombinator.com/item?id=37307708

(I hope it is, there's something ironic in John Nagle complaining about network-induced latency in interactive sessions.)

Is there anything in UX that can't be ruined by security people?

Have you tried running it with strace attached? I wonder if that would reveal something weird happening with each keystroke.

+1 to strace

I'd wager some clunky autocomplete addon for bash is causing it.

I'd expect autocomplete to affect bash startup time rather than on every key press.

I installed some sort of nodejs plugin for zsh once and then forgot about it. One day, the shell became unusable (it was already slow when going to certain directories for the same reason). Luckily, zsh lets you trace what commands are being executed: https://unix.stackexchange.com/questions/565905/oh-my-zshs-p...

That showed that the stupid nodejs plugin was making network calls all the freaking time. Instant deleted it. That may be what's affecting you if you're a web developer.

I would be a bit more paranoid about that then you seem to be

Zomg, happened for me as well and I thought am going crazy.

Around February 2024?

No just a few weeks ago, but I update very infrequently on that workstation.

I once had a fancy bash prompt that displayed git status. Turns out that git status hits the network to check the state of the remote repo, and if you are having DNS issues, that's a 30 second timeout every time the prompt is displayed.

In other words, it may not be the OS at fault here. Make sure you've double-checked all your prompt customisations and autocompletes

I don’t think it is true that git status does any remote repo access. It doesn’t match the functionality of git and git status, as git status shows the difference between the working copy and the current commit - all of which is local information. From the man page:

  Displays paths that have differences between the index file and the current HEAD commit, paths that have differences between the working tree and the index file, and paths in the working tree that are not tracked by Git (and are not ignored by gitignore[5]).

Different story if the FS is a network FS of course.

Yes, my memory may be inexact as to the specifics. I'd hazard a guess the prompt ran a git fetch first so that status accurately reflected the state of the remote (rather than just the state of the local tracking branch)

Reply on news.ycombinator.com