91–98 of 98 posts
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?
It's the same for me on macOS (htop version 3.0.2). Threads aren't displayed with a different color and I also can't hide them.
Earlier quoted context omitted.
I'm not aware of any other user scenario where launching htop and threads showing makes sense. Threads are details, while most people watch for OS processes first. That they are green doesn't help anyone if there's nobody to ask why or colours don't show properly. This is misguided newbie fixation that alienates those users who just need a reliable tool with sane defaults. Just another user feedback. This is a lesson…
While the author's reasoning mostly resonates, I agree with you and disagree with them on this particular point. For a typical user of htop, what matters is not "a process" or "a thread", but a killable unit . A piece of software that, should it misbehave, I can kill and possibly restart later. Killable units are almost always individual processes. Almost never threads - I can't think of a piece of software that can…
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.
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
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.
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.
Earlier quoted context omitted.
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).
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?
Earlier quoted context omitted.
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.