hisham hm

🔗 htop 0.9

Today I announced version 0.9 of htop, after a week of release candidates posted to the htop-general mailing list.

I had a number of changes committed to SVN for a few months but I wanted to take some time to clean up some rough edges and make sure everything was okay for a release. So I decided to take some time last Saturday to work on htop again and run through the bug tracker to check any pending issues, and I ended up spending the whole day from 2PM to 1AM working on it. It was a long time since I last coded non-stop for that long, and it was really fun.

(By the way, why doesn’t sf.net send me an email whenever someone posts a bug? If this feature is available, I never found it — in fact, their interface keeps changing; I admit it took me a while today to find how to release a file. Granted, the new procedure is much much simpler than the old one.)

The tool is pretty stable now and I don’t want to spend a lot of time on it, so it’s natural that the time between releases is growing. For this reason, it’s especially important to make good releases. The series of release candidates was great to catch silly bugs (inserted during Saturday’s coding rush, of course) — for that I’m thankful to the folks from htop-general.

This release brings a feature I wished for a long time: the ability to collapse and expand subtrees. I don’t know if I’ll actually use it that much, but for some reason I always missed it. Another improvement is that it now displays cmdlines of arbitrary length (actually, up to 4096 bytes, which is the kernel’s limit). No more truncated argument lists.

I think the only annoyances left in htop now, as long as I’m concerned, are the lack of search and save in strace view and the lack of history in process search. I think when I get all these done I’ll call it 1.0. Don’t hold your breath, though: it took me one and a half year to go from 0.8.3 to 0.9… :-)

On the subject of stability, I did catch one ridiculous off-by-one error in an array access which may be the cause for the random segfaults that were reported by a few users over the years. Amazing that it sat there for so long, but well, so is life coding in C.

  1. Jasper

    Sunday, January 30, 2011 - 03:44:08

    Thank you for htop. I use it with Lucid Puppy v 5.1.

    When I load Lucid Puppy from a live CD (with a size of some 120 MB)and then eject the CD and run htop it shows RAM usage of only some 40 MB.

    When I asked asked on the Puppy forum how the RAM usage could only be about one third of the CD in memory one forum member said that htop does not report the usage accurately.

    It would be very much appreciated if you would be so kind as to explain to me the true reason why the RAM usage is so small.

    My regards

  2. hisham

    Tuesday, February 1, 2011 - 01:51:25

    htop gets its statistics from the /proc filesystem. The FAQ at the project’s webpage details some of the differences in calculation from top.

  3. Jasper

    Tuesday, February 1, 2011 - 13:23:31


    Thank you very much for your prompt response. However, as an inexperienced user,I would like to ask a final supplementary question.

    Does that mean that the /proc filesystem RAM is totally inaccuracte in the particular “puppy pfix=ram” instance I enquired about?

    My regards

  4. hisham

    Tuesday, February 1, 2011 - 14:26:44

    I don’t know, I have no experience with it. But you can check out the results of /proc/meminfo for yourself and see if they make sense. If you care to make a deeper investigation, check the /proc/ /stat file for the different processes (`man 5 proc` has information about the meaning of the various fields).

    Tmpfs-style drivers tend to play some unusual tricks with available memory, so reports can me misleading in LiveCDs and the like. Not to mention other complexities like page sharing, etc, which often make it impossible to boil memory use down to a single number.

Add comment

Fill out the form below to add your own comments.

CAPTCHA imageReload imageAudible version of CAPTCHA-image