6 ms·

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 pro

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 it happen), but there's a bunch of ways to solve it from a UX perspective: * make threads collapsed by default * add a column showing the number of threads a process has * add the threads toggle to the bottom bar for easy discovery * add a prefix to all threads, e.g. [THREAD] All of these are a lot more obvious than the color green. The authors story of having users ask him why processes are green is simply an indication that the user interface is hard to understand.

mPReDiToR 6y ago
Keep a copy of .htoprc with your ssh keys. I have a skeleton /home on my keyring for using various machines with ease.
- turminal 6y ago
  And everytime one toggles any setting that's is retained over htop restarts like tree view, the file gets edited. And you get diverging files everywhere. Annoyed me very much. Had to write a custom patch to disable some of it.
  - voltagex_ 6y ago
    chmod +i .htoprc?
    - reitanqild 6y ago
      For the benefit of someone like me who only uses Linux and bash on behalf of myself and the companies I work for and haven't studied it extensively, can anyone here tell me what the i is for? I wasn't able to find it in man chmod on my machine, DDG failed me, as did Google. (positive feedback to employees of DDG and Google: whenever I get assigned to the experiment where you show the snippet you thing matches my query it brightens my day, - even if the snippet shows that the result was irrelevant like here "<something about> chmod. I <something about the author>". I think Google used to nail this back in 2007 but anyways, seing the snippet in the front page helps a lot.)
      - teddyh 6y ago
        Immutable. The reason you couldn’t find it in chmod(1) is because it’s the wrong command. The correct command (and manual page) is chattr(1).
        voltagex_ 6y ago
        Oops! Thank you.
    - simias 6y ago
      `chmod 440 ~/.config/htop/htoprc` did the trick for me. Still an unnecessary annoyance but I'll live.
    - voltagex_ 6y ago
      just replying to myself as I got it wrong, it's chattr +i, not chmod. Sorry! (and thanks to the response below correcting me)
  - simias 6y ago
    I agree. I like htop a lot but this behaviour is very hostile. Toggling an option at runtime shouldn't overide the static config without confirmation.
  - ninjin 6y ago
    Indeed, why oh why is there no way to provide configuration preferences apart from doing so interactively? I would gladly wrap the command to provide it using flags, but no. I would equally gladly edit a configuration file (even if the syntax was wonky), but no. Instead I am left having to remember to set (and reset!) my defaults across users and machines.
- vemv 6y ago
  Do you mean it's possible to cleanly auto-inject a .htoprc on whatever machine I SSH into? If so I'd like to learn about the technique
  - artificialLimbs 6y ago
    Same. Along with .vimrc and .tmux.conf
  - Fnoord 6y ago
    You can use rsync or Git for this purpose.
danmur 6y ago
I'm so sick of people telling me something is using some ridiculous GB of RAM because they've added up all the threads' memory in htop
- lathiat 6y ago
  We really need better tooling for this. It is possible but you have to parse snaps which I think is expensive ish. Would be great to get something useful info commonly used tooling though.
  - lathiat 6y ago
    typo: by "snaps" i meant /proc/PID/smaps
- stretchcat 6y ago
  Pointing out the error in their reasoning by noting their sum exceeds the RAM their computer actually has usually works well.
- worik 6y ago
  He he. I came within a hair's bredth of doing exactly that. Saw this article, installed htop, ran it - all in pre coffee morning fog OMG A dozen firefox threads each using 10%! .... Even in my 10% early morning function I realised, but I get your point.
- scubbo 6y ago
  Me too, I really hate that! I wish they'd stop making that very obvious and simple mistake in reasoning! ...just so that _I_ can know that you know what you're talking about, can you elaborate on what that obvious mistake (which I clearly know about) is? Dropping the joke - I assume it's that threads share memory in some way (so that the total consumed is not the sum of each consumption), but a. how and why, and b. why isn't it trivial for htop to represent that "correctly"?
  - garaetjjte 6y ago
Avshalom 6y ago
>some programs launch hundreds of threads I feel like that's the crux of it. If I'm reading htop right I'm at ~140 tasks* and ~1000 threads. The itch.io app that is hanging out in my system tray is currently sitting at ~200 threads by itself. It's not helpful or educational to have pages of identically named threads especially when everything is only getting more multithreaded. *and that's for my Cinnamon desktop, three firefox windows, thunderbird, steam, itch, a terminal and htop, lord knows if I was actually doing something with my computer.
loopz 6y ago
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 to all of us, that we might have very good reasons, but there's still a chance to be wrong about things.
- TeMPOraL 6y ago
  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 recover from having its random thread killed. Sure, I like to see threads - particularly in tree view - but I think the default should still be to hide them (with a more discoverable toggle than just Settings screen).
  - loopz 6y ago
    Yea, the reasoning isn't bad and try to be user-focused. It's just that the end result might not be real-life optimal, for most users or most use cases. You see this alot with UX. Sometimes it breaks new ground (iPhone), but it can also make things really hard to utilize properly (mobile interface for everything).
  - LargoLasskhyfv 6y ago
    While it doesn't happen nowadays, I did some really weird things to selfcompiled/patched Firefox in the past, including killing tabs via killing threads in htop. But it wasn't obvious which thread was a tab, or if it was a tab at all. But it worked about two thirds of the times :-)
  - SkyMarshal 6y ago
    Second this, killing processes is one of my main uses of htop. Having the interface be optimized for that by collapsing threads by default would be nice.
dharmab 6y ago
> program running amok and producing a bunch of threads (anecdote: I've never seen it happen) 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.
yrro 6y ago
> * add a column showing the number of threads a process has FYI the column exists already, but it's not enabled by deault. It's called NLWP, which I assume is short for Number of LightWeight Processes. As for my own UI suggestions, I would hide threads by default, and stop displaying anything in all the columns of a thread where it's impossible for the cell to be different to its parent. Maybe in tree mode, have all of a process's threads grouped under an expandable [threads] pseudo-process as well.
hinkley 6y ago
I've only recently started using htop, and the last task I had to do in it was try to figure out a similar thread problem. The default UI did not tell me if the threads had 'run amok'. There aren't enough lines on the display to tell whether a process with 10 threads on a normal day is now running 50. So like you said, I had to turn off threads, then turn on the thread count column (which I never would have found without a search engine/stack overflow).
mywittyname 6y ago
A design decision that was perfectly appropriate in 2005 might not make so much sense in 2020. That's okay. Threading is much more prolific today than it was 15 years ago. Multicore processors are the norm today and there are plenty of great libraries out there which make threading easier, and less error prone than it used to be. It is common today for language libraries to keep thread pools available for executing small concurrent operations. In such a case, knowing what thread was consuming resources probably wouldn't help much in tracking down the issue. So yeah, I agree with your suggestions. I think they make a lot of sense today. In fact, I bet of the original author were creating htop in 2020, they would make these changes.
ganafagol 6y ago
The bikeshedding in this thread is astonishing. Everybody in the world seems to have a strong opinion about how threads are shown in htop, about the shortcut for them, the default for showing them and their color. Seems like that's easier to do than a thought about the actual substance of the blog post. Or being grateful that there is such a fantastic tool around, that there is a profound philosophy behind it, or that the original author shared it with us with some pretty good arguments. But sure, let's keep discussing why shift-H needs to be made into a more prominent entry in the htop option screen.

mPReDiToR 6y ago

Keep a copy of .htoprc with your ssh keys. I have a skeleton /home on my keyring for using various machines with ease.

turminal 6y ago
And everytime one toggles any setting that's is retained over htop restarts like tree view, the file gets edited. And you get diverging files everywhere. Annoyed me very much. Had to write a custom patch to disable some of it.
- voltagex_ 6y ago
  chmod +i .htoprc?
  - reitanqild 6y ago
    For the benefit of someone like me who only uses Linux and bash on behalf of myself and the companies I work for and haven't studied it extensively, can anyone here tell me what the i is for? I wasn't able to find it in man chmod on my machine, DDG failed me, as did Google. (positive feedback to employees of DDG and Google: whenever I get assigned to the experiment where you show the snippet you thing matches my query it brightens my day, - even if the snippet shows that the result was irrelevant like here "<something about> chmod. I <something about the author>". I think Google used to nail this back in 2007 but anyways, seing the snippet in the front page helps a lot.)
    - teddyh 6y ago
      Immutable. The reason you couldn’t find it in chmod(1) is because it’s the wrong command. The correct command (and manual page) is chattr(1).
      - voltagex_ 6y ago
        Oops! Thank you.
  - simias 6y ago
    `chmod 440 ~/.config/htop/htoprc` did the trick for me. Still an unnecessary annoyance but I'll live.
  - voltagex_ 6y ago
    just replying to myself as I got it wrong, it's chattr +i, not chmod. Sorry! (and thanks to the response below correcting me)
- simias 6y ago
  I agree. I like htop a lot but this behaviour is very hostile. Toggling an option at runtime shouldn't overide the static config without confirmation.
- ninjin 6y ago
  Indeed, why oh why is there no way to provide configuration preferences apart from doing so interactively? I would gladly wrap the command to provide it using flags, but no. I would equally gladly edit a configuration file (even if the syntax was wonky), but no. Instead I am left having to remember to set (and reset!) my defaults across users and machines.
vemv 6y ago
Do you mean it's possible to cleanly auto-inject a .htoprc on whatever machine I SSH into? If so I'd like to learn about the technique
- artificialLimbs 6y ago
  Same. Along with .vimrc and .tmux.conf
- Fnoord 6y ago
  You can use rsync or Git for this purpose.

danmur 6y ago

I'm so sick of people telling me something is using some ridiculous GB of RAM because they've added up all the threads' memory in htop

lathiat 6y ago
We really need better tooling for this. It is possible but you have to parse snaps which I think is expensive ish. Would be great to get something useful info commonly used tooling though.
- lathiat 6y ago
  typo: by "snaps" i meant /proc/PID/smaps
stretchcat 6y ago
Pointing out the error in their reasoning by noting their sum exceeds the RAM their computer actually has usually works well.
worik 6y ago
He he. I came within a hair's bredth of doing exactly that. Saw this article, installed htop, ran it - all in pre coffee morning fog OMG A dozen firefox threads each using 10%! .... Even in my 10% early morning function I realised, but I get your point.
scubbo 6y ago
Me too, I really hate that! I wish they'd stop making that very obvious and simple mistake in reasoning! ...just so that _I_ can know that you know what you're talking about, can you elaborate on what that obvious mistake (which I clearly know about) is? Dropping the joke - I assume it's that threads share memory in some way (so that the total consumed is not the sum of each consumption), but a. how and why, and b. why isn't it trivial for htop to represent that "correctly"?
- garaetjjte 6y ago

Avshalom 6y ago

>some programs launch hundreds of threads I feel like that's the crux of it. If I'm reading htop right I'm at ~140 tasks* and ~1000 threads. The itch.io app that is hanging out in my system tray is currently sitting at ~200 threads by itself. It's not helpful or educational to have pages of identically named threads especially when everything is only getting more multithreaded. *and that's for my Cinnamon desktop, three firefox windows, thunderbird, steam, itch, a terminal and htop, lord knows if I was actually doing something with my computer.

loopz 6y ago

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 to all of us, that we might have very good reasons, but there's still a chance to be wrong about things.

TeMPOraL 6y ago
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 recover from having its random thread killed. Sure, I like to see threads - particularly in tree view - but I think the default should still be to hide them (with a more discoverable toggle than just Settings screen).
- loopz 6y ago
  Yea, the reasoning isn't bad and try to be user-focused. It's just that the end result might not be real-life optimal, for most users or most use cases. You see this alot with UX. Sometimes it breaks new ground (iPhone), but it can also make things really hard to utilize properly (mobile interface for everything).
- LargoLasskhyfv 6y ago
  While it doesn't happen nowadays, I did some really weird things to selfcompiled/patched Firefox in the past, including killing tabs via killing threads in htop. But it wasn't obvious which thread was a tab, or if it was a tab at all. But it worked about two thirds of the times :-)
- SkyMarshal 6y ago
  Second this, killing processes is one of my main uses of htop. Having the interface be optimized for that by collapsing threads by default would be nice.

dharmab 6y ago

> program running amok and producing a bunch of threads (anecdote: I've never seen it happen) 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.

yrro 6y ago

> * add a column showing the number of threads a process has FYI the column exists already, but it's not enabled by deault. It's called NLWP, which I assume is short for Number of LightWeight Processes. As for my own UI suggestions, I would hide threads by default, and stop displaying anything in all the columns of a thread where it's impossible for the cell to be different to its parent. Maybe in tree mode, have all of a process's threads grouped under an expandable [threads] pseudo-process as well.

hinkley 6y ago

I've only recently started using htop, and the last task I had to do in it was try to figure out a similar thread problem. The default UI did not tell me if the threads had 'run amok'. There aren't enough lines on the display to tell whether a process with 10 threads on a normal day is now running 50. So like you said, I had to turn off threads, then turn on the thread count column (which I never would have found without a search engine/stack overflow).

mywittyname 6y ago

A design decision that was perfectly appropriate in 2005 might not make so much sense in 2020. That's okay. Threading is much more prolific today than it was 15 years ago. Multicore processors are the norm today and there are plenty of great libraries out there which make threading easier, and less error prone than it used to be. It is common today for language libraries to keep thread pools available for executing small concurrent operations. In such a case, knowing what thread was consuming resources probably wouldn't help much in tracking down the issue. So yeah, I agree with your suggestions. I think they make a lot of sense today. In fact, I bet of the original author were creating htop in 2020, they would make these changes.

ganafagol 6y ago

The bikeshedding in this thread is astonishing. Everybody in the world seems to have a strong opinion about how threads are shown in htop, about the shortcut for them, the default for showing them and their color. Seems like that's easier to do than a thought about the actual substance of the blog post. Or being grateful that there is such a fantastic tool around, that there is a profound philosophy behind it, or that the original author shared it with us with some pretty good arguments. But sure, let's keep discussing why shift-H needs to be made into a more prominent entry in the htop option screen.