[HN Gopher] Bpytop: Linux/macOS/FreeBSD resource monitor
       ___________________________________________________________________
        
       Bpytop: Linux/macOS/FreeBSD resource monitor
        
       Author : pantalaimon
       Score  : 83 points
       Date   : 2021-12-05 15:27 UTC (2 days ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | taneliv wrote:
       | The same author has a newer version of the utility called btop
       | (written in C++): https://github.com/aristocratos/btop .
        
         | nhumrich wrote:
         | I would really love to read something about the limitations of
         | python and why he decided to redo the whole thing in c++
         | instead of say, cython, but I couldn't find any explanations as
         | to why.
        
           | mah3sh wrote:
           | I've used the python and bash versions and they both were
           | slow. If you keep on scrolling down list of processes, it
           | used to get stuck from time to time during cpu usage graph
           | updates. It was so annoying for me that I never really used
           | bpytop instead of htop which was much more responsive.
           | current c++ version feels really responsive like htop
        
             | johnisgood wrote:
             | So... performance was sub-optimal, hence the rewrite in
             | C++.
        
           | Gentil wrote:
           | Yeah, probably to scratch an itch. The monitoring tool was
           | first written in Bash, then rewritten in Python and now is
           | getting rewritten in C++. I am sensing a pattern now. I
           | really hope if he or somebody else maintain the Python
           | version though.
        
           | qalmakka wrote:
           | I personally much rather prefer using utilities written in
           | Go, Rust or C/C++ because they do not depend on a specific
           | version of an interpreter/module so they are quite easier to
           | install and it's way less likely to bork them. This happens
           | to me all the time with Python and Perl applications and it's
           | quite an hassle.
        
           | jjoonathan wrote:
           | I would too.
           | 
           | I have the intuition that system-related programs tend to
           | prefer C (and friends) for API compatibility: you can access
           | all the syscalls no matter the ABI or weird memory semantics
           | or even callback requirements. In theory, every language
           | should have a standard library that exposes almost all of the
           | system API surface, but in practice there's a long tail of
           | awkward to implement and seldom-used API surface that most
           | standard library writers just shrug their shoulders at.
           | 
           | But yeah, I'd be interested in hearing specifics.
        
             | jcranmer wrote:
             | On Linux at least, the relevant API for reading this sort
             | of data is... open up specific files in /proc and parse the
             | often poorly-documented textual output to get the
             | information you need. Which happens to be the kind of thing
             | that C/C++ don't do very well at all, at least in
             | comparison to languages like Python. Although I think Linux
             | is the outlier in this regard.
        
               | freedomben wrote:
               | well, you're not wrong, but there are lots of
               | libraries/wrappers around that interface that work pretty
               | well
        
         | jcelerier wrote:
         | would be interesting to know what was easier / harder since
         | it's one of the rare cases of writing pretty much the same
         | program in these two languages
        
           | aidenn0 wrote:
           | Writing something the second time is almost always easier;
           | the notable exception is when you try to also make it way
           | more general (second system effect).
        
           | sodimel wrote:
           | It isn't even just the same program in two languages!
           | 
           | He started it all with a bash version (named bashtop, here:
           | https://github.com/aristocratos/bashtop)!
        
       | anarcat wrote:
       | It's kind of hilarious to see hacker news discover the second
       | iteration in the series of three rewrites. This started with
       | bashtop, then bpytop, and now it's btop.
       | 
       | There are probably dozens of HN stories discussing those too.
       | 
       | Can I call this a dupe? :)
        
         | arglebargle123 wrote:
         | Should we start a betting pool on how long it'll take him to
         | rewrite it yet again in Rust? I give it a year.
        
           | johnisgood wrote:
           | Not sure why he would do that. Seems like the issue was more
           | or less bad performance, and that has been fixed by using
           | C++.
        
             | entropicdrifter wrote:
             | Memory management bugs are the only reason I could think of
             | to switch from C++ to Rust
        
           | seanw444 wrote:
           | x86 assembly re-write in 3.
        
           | smoldesu wrote:
           | Bottom exists[0], if you're looking for a rust-based resource
           | monitor it's pretty much the best in the biz.
           | 
           | [0] https://github.com/clementtsang/bottom
        
       ___________________________________________________________________
       (page generated 2021-12-07 23:03 UTC)