Live data from Hacker News

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

hisham.hm

21–30 of 98 posts

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

#23
post #19

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

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.

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

#24

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.

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.

chmod +i .htoprc?

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

#25

Earlier quoted context omitted.

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.

chmod +i .htoprc?

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 " chmod. I ". I think Google used to nail this back in 2007 but anyways, seing the snippet in the front page helps a lot.)

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

#26

Earlier quoted context omitted.

chmod +i .htoprc?

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

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

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

#27
post #15
post #14

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.

The problem is ncurses / terminals ... poor keyboard support, etc...

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

#28

> 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", and I overlooked it because I was looking for a disabled option. So htop was actually smarter than I was giving it credit for. However, it definitely wouldn't hurt to mention Shift+H on the help screen :)

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

#29

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.

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.

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.

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

#30
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.

> CLI is trending amongst dev's again

I don't know if that's as true as "GUIs are now unfashionable to devs". It is hard to blame them since GUIs have regressed so significantly ever since the iPhone.

Post reply on HN