Not sorting based on CPU as expected

[sdarwin]

Hi,

htop is one of my favorite programs! Thank you so much for creating it.

I have noticed on many servers the initial sort based on CPU is broken. It says sort CPU however in the full list of processes those at the top show 0%.

For a while, I did not investigate, and it was just unknown.

Now I have checked, and think I understand what is happening.

• These are ubuntu machines which have been upgraded from 18.04 to 20.04 to 22.04 etc etc. That's not uncommon, so it probably should be supported.

• Re-setting the sort fixes it.

I will attach the htoprc file which caused the problem, and the newer htoprc that fixed it. Neither were manually adjusted.

htoprc.original.txt

htoprc.newer.txt

Since clicking a few buttons and resetting the sort will eventually fix it, you may decide this issue is not worth solving, and just close the issue which is ok with me.

[BenBE]

Based on the config files I see the tree view is off in both cases, which is a common source for confusion regarding the sort order (sorting with tree view enabled works per level of the tree). Had the tree view been active after the upgrade by chance?

Also looking at the old config this seems to be from an quite old version as newer versions (like can be seen in the updated config file) embed their version in the configuration. Do you by chance remember the version of htop before the upgrade?

Furthermore there was IIRC an issue with sort order inversion, that @fasterit can tell more about (IIRC it was PR #1479); though that one was fixed quite quickly after the release that issue was introduced came out.

Do you possibly have further information that might help to narrow down, what might have caused the issue you have seen?

[fasterit]

The "original" htoprc is ancient, it does not even have the "config_reader_min_version" introduced in 2021.

The default sort orders have been massively extended between htop 2.x and 3.x, we did not put in "upgrade" code at the time as the worst case would be a user having to click a column header or press I once. Nobody complained for four years either. Until @sdarwin 😄.

Just deleting such an old htoprc is a good idea, too. You'll be surprise, we have a default "IO" tab now for you. And you can make yourself more tabs.

[sdarwin]

Just checked Ubuntu 18.04. That installs htop 2.1.0.
And Ubuntu 20.04 installs htop 2.2.0.

Those htoprc files are identical to what I posted as htoprc.original.txt

what might have caused the issue you have seen?

This means if you start with Ubuntu 20.04 (not ancient) and upgrade to 24.04 the issue occurs. So it's a basic path to arrive at the situation.

tree view

Not modified. Tree view is off by default. No settings changed.

[sdarwin]

we have a default "IO" tab now for you.

I was about to repeat (well maybe) this issue is so trivial to close it.

But... the IO tab only appears if you delete htoprc?

At that point you should really consider dealing with "upgrades" as a real topic.

Because I'd never see that IO tab.

[fasterit]

But... the IO tab only appears if you delete htoprc?

Or if you create tabs yourself.

At that point you should really consider dealing with "upgrades" as a real topic.

We do. That's why we introduced the "config_reader_min_version" so we can upgrade where it makes sense.

Because I'd never see that IO tab.

You will never see anything new in most "Unix-y" software as they try to maintain your established work processes / configuration as good as possible. People would be annoyed (with good reason) if we put "nice to have" new columns in their views or change the color profile because we fixed stuff for yet another obscure terminal emulator and some people would profit.

We do maintain a good changelog and we have a mailing list if you want to get notified on releases ... https://htop.dev/mailinglist.html .

htop typically just works™. We try to maintain that and stay out of the way. When people need htop (outside the movie industry), they are usually happy that there are no bells-and-whistles and the Mozilla-wants-your-donations "new features" tab to go through. Or get rid of.

/DLange
(the guy that maintains htop on Debian which Ubuntu then copies for their releases)

[sdarwin]

they try to maintain your established work processes

Ok. For this reason I guess what's helpful to one user (updating all the settings) would bother the next, and so it's walking a fine line between the two.

There is a subset of users, which may be 50% or greater, who don't customize their settings at all. If you could determine this group (the htoprc is within a certain range of not being modified) then it's fine to show them every new bell and whistle. Otherwise not.

[BenBE]

If your defaults are suitable for most users, the percentage of users that don't touch any settings is even much higher. If your percentage of people who touch a certain setting is very high, this usually means your default for this setting is not optimal. OTOH there are some settings that are highly dependent on the user (e.g. user.name and user.email for git ;-)), where it is nearly inevitable that everybody needs to change them. With htop most settings fall in the first category and thus with most settings proper defaults lead to few people ever changing the defaults. And this is fine. What you don't want is people needing to adapt their settings because you changed things, which brings us back to the point that @fasterit made: Most unix utilities try to stay the way they used to work, as changing things tends to break things. You don't want grep to suddently require --no-silent to show you matches. This would break things and the mob carrying some pitchforks to your home would be more than justified about issuing some --no-silent protest in your front yard. And while few people ever read the Changelog (BTW: written by hand for each release), it at least reduces the number of surprises for those who didn't read it.
/walloftext

Regarding the migration part for the tabs: This was discussed at the time inside the dev team and the decision was made to not include migration code for this feature (apart from migrating the columns into a proper "Main" screen), because adding this extra screen would have been forcing a setting change onto users AND detecting if the settings for the screen were still at their defaults would have been different on each platform and for each base version. Much effort for very little gain; and on top a technical debt you'd have to keep carrying around. TL;DR: Nothing worth investing maintainer power into.