Btop++ is a power resource monitor for Linux(github.com)
github.com
Btop++ is a power resource monitor for Linux
https://github.com/aristocratos/btop
65 comments
Quick word of warning, if you download it: The release archive doesn't create a directory, just untars into $CWD. So do this:
mkdir btop
cd btop
tar xjvf ~/Downloads/btop.....tbz
./install.sh
I use atool (https://www.nongnu.org/atool/) for unpacking random archives - it abstracts away all formats including zip/rar/7z, compression and also guarantees that nothing is ever extracted into $CWD.
I use `unp` for the same thing. `-u` extracts into a directory.
Since unp is a stock ticker, it's a little harder to find:
https://github.com/mitsuhiko/unp
Looks like it might be in standard Ubuntu repositories:
https://manpages.ubuntu.com/manpages/xenial/man1/unp.1.html
Looks like it might be in standard Ubuntu repositories:
https://manpages.ubuntu.com/manpages/xenial/man1/unp.1.html
i use unar/lsar
https://theunarchiver.com/command-line https://github.com/MacPaw/XADMaster
in difference to unp and atool, unar does not depend on other tools to unpack the actual archive
https://theunarchiver.com/command-line https://github.com/MacPaw/XADMaster
in difference to unp and atool, unar does not depend on other tools to unpack the actual archive
Gotta check that out, thanks for the tip!
This is why I have trust issues when github pulling or exploding a tar.
Maybe it's just me, but this seems like the more obvious behaviour? Personally I'd typically extract in /tmp/relevant-name, and sometimes that results in /tmp/relevant-name/relevant-name.
Doesn't seem a big deal or require/cause trust issues to me.
(And when I create one, I always have to check/look up what happens, so it doesn't surprise me that a variety of things get done at all.)
Doesn't seem a big deal or require/cause trust issues to me.
(And when I create one, I always have to check/look up what happens, so it doesn't surprise me that a variety of things get done at all.)
It's been common convention for decades that if you distribute a source tarball of something, that everything inside is inside a directory named foobar-1.0 where 'foobar' is the project name and 1.0 is the version.
Not everyone does this, of course, but it's nice when they do. Because it means you can just wget the file into a dir and untar it without worrying about it messing up whatever is already there. Also handy for putting different versions of the project side-by-side.
Not everyone does this, of course, but it's nice when they do. Because it means you can just wget the file into a dir and untar it without worrying about it messing up whatever is already there. Also handy for putting different versions of the project side-by-side.
Ok, but like you say it's a mixed bag - I 'wget the file into a dir and untar it without worrying about it messing up whatever is already there', because nothing is, it's a mktemp -d or manual equivalent.
That was typical on DOS/Windows when distributing ZIP archives, for a long time.
But on *nix systems, the idiom for tarballs usually includes a directory containing all of the contents.
> (And when I create one, I always have to check/look up what happens, so it doesn't surprise me that a variety of things get done at all.)
True - I usually do a `tar tf foo.tar.xz |head` to get a quick peek at the archive. This generally avoids the problem of dumping a bunch of files into the current directory.
But on *nix systems, the idiom for tarballs usually includes a directory containing all of the contents.
> (And when I create one, I always have to check/look up what happens, so it doesn't surprise me that a variety of things get done at all.)
True - I usually do a `tar tf foo.tar.xz |head` to get a quick peek at the archive. This generally avoids the problem of dumping a bunch of files into the current directory.
I always check the contents with -t before extracting.
One could always run "tar tv[z]f" on the archive first, and then choose whether or not to explode it in the current directory.
The first thing I do with a Linux installation it's always add htop, and this it's the first time I feel the need to try something new in my routine.
htop and multitail are always tied for me.
https://linux.die.net/man/1/multitail
I never heard of this one before. What's the benefit instead of doing this with Tmux?
I never heard of this one before. What's the benefit instead of doing this with Tmux?
Biggest thing is if you’re doing a streaming tail with an * pattern, it figures it out and filters them into proper groups instead of a single blob stream.
I didn’t know you could something like that we tmux though. I’ll have to check it out. :)
I didn’t know you could something like that we tmux though. I’ll have to check it out. :)
You can't, I was just talking about tailing multiple files in Tmux splits.
> multitail
You just made my day. I always open multiple ssh sessions just to display various logs at the same time.
Seems like you can even docker-compose logs -tf | multitail -j.
edit: I never took the time to learn tmux but after just watching a use case video, seems like you could achieve the same result with tmux indeed, as the other comment suggested.
You just made my day. I always open multiple ssh sessions just to display various logs at the same time.
Seems like you can even docker-compose logs -tf | multitail -j.
edit: I never took the time to learn tmux but after just watching a use case video, seems like you could achieve the same result with tmux indeed, as the other comment suggested.
If you're open to new tools, the latest version of the Logfile Navigator (lnav) supports remote hosts over ssh:
https://lnav.org/2021/05/03/tailing-remote-files.html
The main advantages of lnav over multitail is that it collates log files by time and does syntax highlighting. There are many other features as well -- https://lnav.org/features
https://lnav.org/2021/05/03/tailing-remote-files.html
The main advantages of lnav over multitail is that it collates log files by time and does syntax highlighting. There are many other features as well -- https://lnav.org/features
tmux or gnu screen work fine (screen is sometimes installed when tmux is not)
htop and ncdu
For me, it's been bottom https://github.com/ClementTsang/bottom and dua https://github.com/Byron/dua-cli for a while
I've found some other cool CLIs written with rust at https://github.com/TaKO8Ki/awesome-alternatives-in-rust
I've found some other cool CLIs written with rust at https://github.com/TaKO8Ki/awesome-alternatives-in-rust
I like htop+dstat as nice compliments, but sadly dstat isn't universally available like htop and it's unmaintained
That terminal UI is a work of art...
Agreed. I thought gotop was cool but wow
It’s really nice. That main main screen is giving me flashbacks to Doom.
It’s giving me some pretty heavy mid-90’s BBS vibes. Even the menu with the big BTOP++ logo reminds me of a main menu on a BBS.
Now if we can just slow it down to 240 characters/second to simulate the real experience. It won’t be authentic unless it also slows down when you’re changing colors because of the ANSI escape codes.
Now if we can just slow it down to 240 characters/second to simulate the real experience. It won’t be authentic unless it also slows down when you’re changing colors because of the ANSI escape codes.
Author: please make your program name an acronym for
Bower Tesource Onitor for Pinux
Bower Tesource Onitor for Pinux
I have been using glances for a terminal sysmon but I don't like that it eats so much RAM. Can someone please recommend a system monitor that is easy to comprehend and less resource hungry?
I am also curious about below [0] since it came up recently.
[0] https://github.com/facebookincubator/below
I am also curious about below [0] since it came up recently.
[0] https://github.com/facebookincubator/below
Maybe bottom[0]? I use bpytop but probably wouldn't recommend it on account of how heavy it is. I remember bottom being pretty lightweight when I used it, without sacrificing readability.
[0] https://github.com/ClementTsang/bottom
[0] https://github.com/ClementTsang/bottom
Kinda depends on what you want to know and how much memory you think is too much. Implementations range from sar to atop to netdata and many others.
'nmon' doesn't get much attention, but it feels lightweight (I haven't tested if it really is) - https://en.wikipedia.org/wiki/Nmon
ytop is nice rust based one if you like the rust ecosystem, it's still good even if you don't but I think you need to install cargo/rust in most cases to build it, I don't think anyone packages it. "cargo install ytop" -> .cargo/bin/ytop
That's the prettiest 'make' I've ever seen. I wish I had something more useful to contribute but I'm still staring at its beauty.
This looks very nice, but the compiler version requirement is very painful for those of us working on machines installed more than a year ago... GCC 10, ouch. I mean, newer versions are great, but when you don't control your machine's OS distribution, installing GCC 10 is not the most trivial thing to do.
You can just use a GCC docker image to build: https://hub.docker.com/_/gcc
No I can't... without an appropriate installation of docker and/or dependencies of docker.
See: https://docs.docker.com/engine/security/rootless/#prerequisi...
See: https://docs.docker.com/engine/security/rootless/#prerequisi...
You don't control your device OS or otherwise have access to a machine you do, your OS does not offer modern packages, and you don't have the ability to otherwise pull in development toolchain resources.... yet it's supposed to be the projects problem you can't compile something started in 2021 from source on your older setup?
I get your current situation is less than ideal for you but at some point you have to accept the project is not the source of painfulness associated with you trying to compile new apps from source, it's just the trigger.
I get your current situation is less than ideal for you but at some point you have to accept the project is not the source of painfulness associated with you trying to compile new apps from source, it's just the trigger.
You have the implicit assumption that I'm working on an individual project. Imagine a large company which settles on an OS for some product that goes into the field for 10 or 20 years. That's the OS you're stuck with. And yes, that's painful in itself.
Now, I _can_, with some effort, pull/build a development toolchain. But it would be much nicer if I could have access to this utility on machines with older toolchains, that's all.
Now, I _can_, with some effort, pull/build a development toolchain. But it would be much nicer if I could have access to this utility on machines with older toolchains, that's all.
You can install the binary on your device and don't need to compile from source for using the application.
It seems unfair to both developers and other users of the project to expect it to be compatible with older toolchains given the benefits of the newer builds.
It seems unfair to both developers and other users of the project to expect it to be compatible with older toolchains given the benefits of the newer builds.
This. In the github readme it says static binaries are supplied. Thinking of linux and linux tooling as just something distros supply limit the imagination. Pull down the correct static and you're done. If you still want to compile it, it's easy.
From linux from scratch to muslcc to buildroot to yocto you can get nice new compilers and run them in docker or in a simple chroot. Requiring new compiler versions is a good thing and any disto related impediments are a distraction from just getting simple toolchain tooling going.
From linux from scratch to muslcc to buildroot to yocto you can get nice new compilers and run them in docker or in a simple chroot. Requiring new compiler versions is a good thing and any disto related impediments are a distraction from just getting simple toolchain tooling going.
> You have the implicit assumption that I'm working on an individual project.
There is no such implication.
There is no such implication.
That link says "Known to work on Ubuntu 18.04, 20.04, and 21.04", although maybe Ubuntu is just the default selection when the page loads... still, I guess you won't be testing much new software if they don't allow you even using Docker!
If you don't even have the right to install docker on your own machine what makes you think that your sysadmins are ok with you compiling this random software from the internet anyways ?
Maybe download Miniforge and install gcc_linux-64, then you get GCC 11, all without sudo, on (probably) any Linux distro
Wow, this is a very nice fully featured, with mouse support, terminal application! Just installed from the AUR and hopefully will remember it to replace htop in my mind!
Suggestion:
Create an htop alias for btop. Then you'll never have to worry about forgetting it.
Create an htop alias for btop. Then you'll never have to worry about forgetting it.
For me it’s enough iotop + bpytop + htop
The readme for bpytop links to btop++
https://github.com/aristocratos/bpytop
It says:
> The Linux version of btop++ is complete. Released as version 1.0.0
My impression is that btop++ is the successor to bpytop. Or even if bpytop continues to be maintained that they intend for most people to use btop++ instead going forward.
https://github.com/aristocratos/bpytop
It says:
> The Linux version of btop++ is complete. Released as version 1.0.0
My impression is that btop++ is the successor to bpytop. Or even if bpytop continues to be maintained that they intend for most people to use btop++ instead going forward.
I recommend the C reimplementation of iotop btw, it has lots more features and is more efficient and is maintained. It is packaged as iotop-c in Debian and other distros.
https://github.com/Tomas-M/iotop
https://github.com/Tomas-M/iotop
It's the same person that wrote bpytop. He also wrote bashtop. 3 times implementation of the same thing. That's dedication!
Takes at least gcc-10 to compile, but other than that it was pretty easy to get going.
Looks almost identical to bpytop. Super neat!
Does anyone know where I can find that font?
Wow. That’s hot!
I'm sure you put a lot of work into it and it looks nice. But terminal just sucks for graphics layout.
But this is the kind of software that I would want to keep using. Will btop keep being supported? Is btop going to be available in practically all distros I use? Even currently on Arch its only in the AUR.
Its also concerning there is btop[0] and bpytop[1]? I don't understand the difference.
[0]https://github.com/aristocratos/btop
[1]https://github.com/aristocratos/bpytop