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

81–90 of 98 posts

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

#81

Post by rablackburn »

rakoo wrote: post #9
shaicoleman wrote: post #4

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

I didn't know you could click in htop until today; it even works through tmux in mosh without any special configuration. I think there's a lot to learn in the design philosophy of giving the power to users by default, but if you don't give your users the tools to learn this power they're going to have to ask questions if they want to yield it

This was my biggest take-away from the article too. It never occurred to me to even try interacting with a CLI application with my mouse.

I'd appreciate it if more developers considered 'discoverability' as a core part of their design philosophy. I think the author is close, but when you need to ask someone/search 'why is this green?' that's enough of a barrier that most people won't bother asking (or it'll be a small enough issue that they don't consciously notice it).

There's even a generally accepted solution for explaining semantic colours, a legend. Might be nice to have one down with the F-keys.

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

#82

Post by jolmg »

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.

> In an ideal world the concept of TUI would not exist.

I have a hard time imagining that ideal world. TUIs have their own advantages that can't really be met with GUIs without restricting them and giving up some features of GUIs.

1. Being able to use it through SSH and other sorts of connections like a serial connection through the headphone jack on the PinePhone.

2. All text can be copy-pasted, guaranteed. Devs don't have the option to prevent that.

3. Its use is very simple to automate.

3.1. Don't need random sleeps while the interface is updated, just read and write to the terminal and let those calls hang if they need to.

3.2. No need to guess pixel coordinates of inputs to emulate clicks on them because the interface wasn't thought for keyboard use.

3.3. Sometimes you can even encode interactions in a stream of bytes that you can then paste into the terminal to execute on the TUI.

3.4. It's very simple for a script to pull text data from a TUI, but it's near impossible to pull it from a graphical window.

4. Terminal features like rectangular selection or keyboard-navigated copy-paste can be used for all TUIs.

5. Encourages more efficient use of screen real-estate.

6. Simpler themes, controlled by terminal settings. Simple to set the use of favorite font for everything.

7. More consistent look across TUIs because of terminal restrictiveness.

8. Can call a subprocess to take control of the terminal to do something and just come back when it finishes. This allows for simple ad-hoc multitasking through the terminal connection without special support of something like termux which requires foresight.

9. The fact that the application doesn't need to handle frivolous things like re-rendering after the window is moved or handle every mouse movement over it, makes figuring out what it actually is doing that matters quite simpler. I'm referring to the output of strace. It's largely more readable on TUIs than GUIs because TUIs don't need to do the frivolous things GUIs do.

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

#83

Post by mywittyname »

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…

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.

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

#84

Post by SAI_Peregrinus »

scubbo wrote: post #80
garaetjjte wrote: post #79

Earlier quoted context omitted.

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

For most operating systems, threads each have their own stack space, and (if supported) thread-local storage, but share heap, constants (.bss), and static variables (.data). It's impossible to say exactly what resources a given thread is using from those shared resources, so htop just includes them all, for every thread.

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

#85

Post by 1996 »

zokier wrote: post #40
simias wrote: post #36

Earlier quoted context omitted.

Sometimes less is more. Having access to more features sometimes leads devs to bloat their applications and make them subjectively less usable. A pathological example for me would be gvim. I tried using it for a while but I kept running into weird performance issues and general lagginess. Meanwhile from a terminal it Just Works. So I don't bother with it anymore, I always run Vim from a terminal and I never looked ba…

I do think that we are missing a good gui library that would direct developers to create lean applications (both from ux and resource consumption points of view) somewhat similarly as ncurses.

Check jexer for TUI

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

#86

Post by lathiat »

lathiat wrote: post #23
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

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.

typo: by "snaps" i meant /proc/PID/smaps

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

#87

Post by Too »

Kototama wrote: post #3
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.

> CLI is trending amongst dev's again Did it ever stopped being useful?

There seems to be a trend last few years where many of even the most traditional CLIs are getting questioned by modern replacements that provide a richer experience without compromising on the old values of simplicity. For example ripgrep, bat or exa instead of grep, cat and ls.

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

#89

Post by ganafagol »

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…

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.

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

#90

Post by saagarjha »

apple4ever wrote: post #88
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?

I thought I was the only one who had never seen green threads.

You should try Go.
Post reply on HN