4 ms·

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 fir

by 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.

by loopz 6y ago

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.