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

71–80 of 98 posts

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

#71

Post by worik »

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

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.

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

#72

Post by intrepidhero »

I'm 100% onboard with the author's design philosophy: "A good design leads a user to more powerful tools." I have not used htop but the screenshots show some things that I very much appreciate in a UI design such as the menu bar at the bottom with hot keys clearly displayed. There's no reason to make a user hunt for the hot keys or to guess at the possible function space.

Software, as I think of it, is a way to expose the "general purpose" nature of computers to users. Good software teaches users how to access that nature. Like a good teacher, that leading should be subtle and gentle and have the end goal of user empowerment.

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

#73

Post by parliament32 »

The only complaint about htop is that it starts numbering CPUs from 1, while in real life CPU numbers start at 0. When I see core 18 is pegged with system(red), I instinctively want to ask perf -C 18 what's up... but that's not right, is it 17 or 19 again? If you're going to do that, don't show CPU numbers at all, just the collection of bars.

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

#74

Post by cat199 »

zokier wrote: post #14
ktpsns wrote: post #2

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.

Htop is not cli, and ncurses is in general just poor emulation of gui.

> ncurses is in general just poor emulation of gui.

no, ncurses is an implementation kit for screen-oriented TUIs. CLI, TUI, GUI are all separate things..

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

#75

Post by Chickenosaurus »

hyperman1 wrote: post #21

htop is one of the best tools available in your linux toolbox. Thanks, author. While thinking about it, I'd like to inject htop in misbehaving kubernetes containers. Does anyone know if there is a static compile available somewhere or something.

You can use the kubectl debug command to add ephemeral containers to a running Pod. It's an alpha feature introduced in v1.18.

The ephemeral debug container can contain htop while the application container doesn't. This way minimal application containers aren't complicating debugging when something goes wrong :)

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

#76

Post by vonmoltke »

parliament32 wrote: post #73

The only complaint about htop is that it starts numbering CPUs from 1, while in real life CPU numbers start at 0. When I see core 18 is pegged with system(red), I instinctively want to ask perf -C 18 what's up... but that's not right, is it 17 or 19 again? If you're going to do that, don't show CPU numbers at all, just the collection of bars.

There is an option under "Display options" to change this.

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

#77

Post by scubbo »

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

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

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

#78

Post by artificialLimbs »

vemv wrote: post #52
mPReDiToR wrote: post #17

Earlier quoted context omitted.

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

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

Same. Along with .vimrc and .tmux.conf

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

#79

Post by garaetjjte »

scubbo wrote: post #77
danmur wrote: post #19

Earlier quoted context omitted.

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

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. w…

Threads usually share address space. There's no way to know particular thread memory usage, so htop just duplicates same information for every thread.

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

#80

Post by scubbo »

garaetjjte wrote: post #79
scubbo wrote: post #77

Earlier quoted context omitted.

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. w…

Threads usually share address space. There's no way to know particular thread memory usage, so htop just duplicates same information for every thread.

Got it, thanks.

> There's no way to know particular thread memory usage

This sounds like the sort of statement that is self-evident to folks with a CS education (I studied math, and all my CS/programming knowledge is self-taught). I'll add that to my _long_ backlog of things that I should research to get over my imposter syndrome :)

Post reply on HN