Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

User power, not power users: htop and its design philosophy

hisham.hm

Post reply on HN
Print view View original

61–70 of 98 posts

Re: User power, not power users: htop and its design philosophy

#61

Post by nitsky »

volta87 wrote: post #49
nitsky wrote: post #45

When I first started using htop, I had the opposite misunderstanding to what the author describes. I spent a long time trying to understand why there were over a dozen instances of the same process, when I thought I launched just one! When I discovered that htop was showing threads instead of processes, I hit ctrl-h to hide threads and committed .htoprc to my dotfiles so I wouldn’t have to see them again.

And then every time you change a view option at run-time, your `.htoprc` gets modified.....

Yeah it’s annoying, but I find I rarely change view options.

Re: User power, not power users: htop and its design philosophy

#62

Post by LargoLasskhyfv »

TeMPOraL wrote: post #53
_y5hn wrote: post #48

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…

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 :-)

Re: User power, not power users: htop and its design philosophy

#63

Post by rob74 »

bmn__ wrote: post #58
rob74 wrote: post #28

Earlier quoted context omitted.

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"…

It is on the help screen. Look again. Left column, 10th item.

Ah, I swear I looked at the list three times until I finally found it. It's not listed under "Shift+H", it's under "H" (capital H = Shift+H). If they had a shortcut "Shift+1", they would probably rather look up the keyboard mapping to find out what character that is rather than writing "Shift+1". I still think htop is a great little tool, but sometimes it's really too clever for its own good...

Re: User power, not power users: htop and its design philosophy

#65

Post by yrro »

fredsted wrote: post #12

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…

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

Re: User power, not power users: htop and its design philosophy

#67

Post by leephillips »

herpderperator wrote: post #50
leephillips wrote: post #22

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?

F2 -> Display options -> [x] Display threads in a different color

That was it. Thanks.

Re: User power, not power users: htop and its design philosophy

#68

Post by hinkley »

fredsted wrote: post #12

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

Re: User power, not power users: htop and its design philosophy

#69

Post by rabidrat »

ClumsyPilot wrote: post #32
1996 wrote: post #15

Earlier quoted context omitted.

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.

Lets call them what they are: a workaround to display graphical content in a terminal windows. We need them because SSH, because we linux UI is a mess, because UI is hard, in embedded, etc. In an ideal world the concept of TUI would not exist.

This is like saying that books made out of text are a workaround for the movable type printing press, and with high-DPI laser printing in an ideal world the concept of text books would not exist.

Re: User power, not power users: htop and its design philosophy

#70

Post by stretchcat »

danmur wrote: post #19
fredsted wrote: post #12

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

Pointing out the error in their reasoning by noting their sum exceeds the RAM their computer actually has usually works well.
Post reply on HN