51–60 of 98 posts
In my htop, user threads are not green. The only difference in the display is some text at the top telling me "414 thr". Is my setup messed up?
One of the first things I do when launching htop on a new box is to disable threads. The current way of showing threads by default is untenable because some programs launch hundreds of threads, making it hard to get an overview of a system unless you make the terminal size very large. I appreciate the author wanting users to discover a program running amok and producing a bunch of threads (anecdote: I've never seen i…
Keep a copy of .htoprc with your ssh keys. I have a skeleton /home on my keyring for using various machines with ease.
If so I'd like to learn about the technique
One of the first things I do when launching htop on a new box is to disable threads. The current way of showing threads by default is untenable because some programs launch hundreds of threads, making it hard to get an overview of a system unless you make the terminal size very large. I appreciate the author wanting users to discover a program running amok and producing a bunch of threads (anecdote: I've never seen i…
I'm not aware of any other user scenario where launching htop and threads showing makes sense. Threads are details, while most people watch for OS processes first. That they are green doesn't help anyone if there's nobody to ask why or colours don't show properly. This is misguided newbie fixation that alienates those users who just need a reliable tool with sane defaults. Just another user feedback. This is a lesson…
This is what quality software looks like: It has power features around the corner , which can be turned on by experts. But is nevertheless accessible by novices. CLI is trending amongst dev's again, and we should take a lesson by htop how to design a good user interface.
> CLI is trending amongst dev's again Did it ever stopped being useful?
Today, even some of those tools are embracing CLIs.
Earlier quoted context omitted.
I'm not aware of any other user scenario where launching htop and threads showing makes sense. Threads are details, while most people watch for OS processes first. That they are green doesn't help anyone if there's nobody to ask why or colours don't show properly. This is misguided newbie fixation that alienates those users who just need a reliable tool with sane defaults. Just another user feedback. This is a lesson…
While the author's reasoning mostly resonates, I agree with you and disagree with them on this particular point. For a typical user of htop, what matters is not "a process" or "a thread", but a killable unit . A piece of software that, should it misbehave, I can kill and possibly restart later. Killable units are almost always individual processes. Almost never threads - I can't think of a piece of software that can…
> You have no idea how many times I was asked “hey, why are some processes green?” over these 15+ years — and no, it wasn’t annoying: each of these times it was an opportunity to teach someone about threads! That's because there isn't a easy way in htop to discover that. htop is great, I've used it for a decade, but I didn't know you could hide the threads (Shift+H) until I read this today. A "View options" / "Advanc…
Earlier quoted context omitted.
Htop is not cli, and ncurses is in general just poor emulation of gui.
It's ok if you don't like TUIs, but don't call them "poor emulations" of GUIs. They do different things differently, but they achieve great results in their own ways. The mc file manager or ranger more than stands the comparison against graphical file managers.
Another example is 'apt-get' vs aptitude. The earlier is inherently scriptable. The latter needs you to start the program, input a few keys, exit.
fdisk is another terminal program that's not command line.
> You have no idea how many times I was asked “hey, why are some processes green?” over these 15+ years — and no, it wasn’t annoying: each of these times it was an opportunity to teach someone about threads! That's because there isn't a easy way in htop to discover that. htop is great, I've used it for a decade, but I didn't know you could hide the threads (Shift+H) until I read this today. A "View options" / "Advanc…
Thanks for sharing that, now I know that I'm not the only one who has been using htop for years and didn't know that you could hide the threads with Shift+H. It's not even on the help screen, for crying out loud :D Plus, after looking through all the options, I couldn't find an option to hide threads by default. EDIT: later I realized that pressing Shift+H automatically sets the option "Hide userland process threads"…
Left column, 10th item.
One of the first things I do when launching htop on a new box is to disable threads. The current way of showing threads by default is untenable because some programs launch hundreds of threads, making it hard to get an overview of a system unless you make the terminal size very large. I appreciate the author wanting users to discover a program running amok and producing a bunch of threads (anecdote: I've never seen i…
I've seen it in production. But the simple solution is to cap the number of threads to a reasonable value (ulimits, Kubernetes Pod Security Policy) and add observability for thread count.
Earlier quoted context omitted.
Sometimes less is more. Having access to more features sometimes leads devs to bloat their applications and make them subjectively less usable. A pathological example for me would be gvim. I tried using it for a while but I kept running into weird performance issues and general lagginess. Meanwhile from a terminal it Just Works. So I don't bother with it anymore, I always run Vim from a terminal and I never looked ba…
I do think that we are missing a good gui library that would direct developers to create lean applications (both from ux and resource consumption points of view) somewhat similarly as ncurses.