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

11–20 of 98 posts

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

#11

Post by dspillett »

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?

No, but it became a bit of a victim of being unfashionable. I think partly because of an influx of new devs who weren't in the position of having little choice but to learn at least some of the non-GUI way, particularly in the web sphere. As things have matured (arguably) and become more complex, and those devs have gained experience, they've started seeing the benefits of other methodologies.

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.

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

#12

Post by fredsted »

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

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

#14

Post by zokier »

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.

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

#15

Post by 1996 »

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.

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.

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

#16

Post by mPReDiToR »

This philosophy is exactly what I had with PC Tools and XTree Gold. The utilities which made computers interesting for me.

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?

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

#17

Post by mPReDiToR »

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…

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

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

#18

Post by turminal »

mPReDiToR wrote: post #17
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…

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.

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

#19

Post by danmur »

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
Post reply on HN