User power, not power users: htop and its design philosophy
hisham.hm
hisham.hm
I appreciate the author wanting users to discover a program running amok and producing a bunch of threads (anecdote: I've never seen it happen), but there's a bunch of ways to solve it from a UX perspective:
* make threads collapsed by default
* add a column showing the number of threads a process has
* add the threads toggle to the bottom bar for easy discovery
* add a prefix to all threads, e.g. [THREAD]
All of these are a lot more obvious than the color green.
The authors story of having users ask him why processes are green is simply an indication that the user interface is hard to understand.
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 "<something about> chmod. I <something about the author>". I think Google used to nail this back in 2007 but anyways, seing the snippet in the front page helps a lot.)
If so I'd like to learn about the technique
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.
...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"?
> 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 :)
I feel like that's the crux of it. If I'm reading htop right I'm at ~140 tasks* and ~1000 threads.
The itch.io app that is hanging out in my system tray is currently sitting at ~200 threads by itself.
It's not helpful or educational to have pages of identically named threads especially when everything is only getting more multithreaded.
*and that's for my Cinnamon desktop, three firefox windows, thunderbird, steam, itch, a terminal and htop, lord knows if I was actually doing something with my computer.
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.
But it worked about two thirds of the times :-)
I've seen it in production. But the simple solution is to cap the number of threads to a reasonable value (ulimits, Kubernetes Pod Security Policy) and add observability for thread count.
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.
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).
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.
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.
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" / "Advanced" menu item on the bottom bar would help discover these option exists.
I also pressed some key, and some things turned purple, and there's no indication what view is shown, what the purple colour means, and what to do to turn it off.
For example, I missed that they use capital and non-capital letters: H (shift+h) toggles the threads, but i sat there opening/closing the help screen by pressing just h. Careful reading of the help screen would have prevented that. As none of the same lowercase/capital letters are next to each other, it is easy to miss.
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
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.
To be quite honest, I don't know any of the keys not mentioned in F-list at the bottom other than space and I think k, everything was always through Setup Menu.
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 :)
Left column, 10th item.
CLI is trending amongst dev's again, and we should take a lesson by htop how to design a good user interface.
Did it ever stopped being useful?
I just hope it doesn't swing back too far the other way as it has before (I've been around long enough to have seen the cycle previously!). I'm a big fan for command line, scriptable, tools and plain text pipe-able output, and have been since being introduced to pipes & redirection all those decades ago, but we need to avoid the holier-than-thou thing that seems to develop when our old timer ways get the lime-light for a while. It only serves to put people off learning that they are great tools for many jobs and definitively the right ones for a some.
Check out newsboat, nmtui, ranger, w3m, mikmod, slack-term/weechat/irssi/finch, sc, mps-youtube, micro (text editor) just to name a few... Seems to be very popular among people who use tiling window managers.
In fact, with a good terminal multiplexer, mpv and fbv, all you need X for is stuff like web apps and Gimp.
Today, even some of those tools are embracing CLIs.
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.
In an ideal world the concept of TUI would not exist.
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 back.
In general I find that the terminal imposes two generally good constraints to application makers: everything must exist within a single window and mouse interaction is very limited (and not supported everywhere) so it's important that everything must be achievable with keyboard inputs.
These constraints disincentivize pathological mouse-driven "click click" pop up dialog fests which are the bane of my existence.
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.
TUI also tends to have a certain aesthetic. I cut my teeth on computers where it was common for the UI to be made from ASCII text.
Another example is 'apt-get' vs aptitude. The earlier is inherently scriptable. The latter needs you to start the program, input a few keys, exit.
fdisk is another terminal program that's not command line.
no, ncurses is an implementation kit for screen-oriented TUIs. CLI, TUI, GUI are all separate things..
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.
htop has a GUI, not a CLI. Some people call it a "TUI" but in terms of UX and program architecture it's a lot closer to a GUI than a CLI.
Part of why the shell is gaining is that UIs are invariably becoming less efficient with rampant use of React and node for native apps.
I did not say node is slow.
For me the design philosophy worked quite well. I learned so much about my system just by using it and trying to understand all of its output. And I am still learning after years of using it.
I actually like to just sit and watch it sometimes, it's fascinating to me how much a computer does at all times, even when it is idle.
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.
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 :)
Having the ability to ruin my OS (all three floppy disks of it) made learning easier. Being protected from root level commands doesn't suit me on my personal machines. "Mistakes are proof you're trying".
How can you ever learn any responsibility without any power, great or otherwise?
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.
You can delete ~/.config/htop/htoprc to reset it to default settings in case it's a misconfiguration.
Shots fired at GNOME