mactop(github.com)
github.com
mactop
https://github.com/context-labs/mactop
30 comments
Purely subjective of course, but is this prettier than htop in your opinion? I actually felt like it was pretty typical if not a tad ugly, mainly because the color bars seem way to vertically long (i.e. tall/high) to me. It does convey information at a glance, but less vertical space would be an improvement IMHO. I do like the colors chosen though.
My honest first impression was that it's kind of ugly... It also doesn't seem to have a process list??
For a traditional process viewer I'd use htop and for a more complicated TUI ill use btop.
For a traditional process viewer I'd use htop and for a more complicated TUI ill use btop.
You can get most of the info also on btop (https://github.com/aristocratos/btop), just without the ANE and annotating the cores. It's cross platform though.
Shameless self promotion:
If you’re interested in high level disk activity with the feel of old school blinking lights, check out DriveLight[0].
0 - https://apps.apple.com/us/app/drivelight/id6446650999
If you’re interested in high level disk activity with the feel of old school blinking lights, check out DriveLight[0].
0 - https://apps.apple.com/us/app/drivelight/id6446650999
Hahaha, I actually didn't post this, but thank you to whoever did! mactop ftw!
Does anyone have recs for doing really low level performance tuning on Apple Silicon? Xcode Instruments isn’t very easy to use or interpret. Things like what % of time is spent on memory stalls, simd units, etc
I believe that macOS still ships with DTrace; Xcode Instruments was originally built on top of it.
https://dtrace.org
(Some people find it easier to write a one-line script that reports the timings that they need; I don't know if it helps you.)
https://dtrace.org
(Some people find it easier to write a one-line script that reports the timings that they need; I don't know if it helps you.)
Very nice, an instant addition to my $PATH. In particular I like having the ANE usage displayed, as this is typically invisible in other top-like tools.
I gave it a try for the past few hours on a worker Mac and it's nice, but its own CPU usage is very high and proportional to the size of the terminal. With a fullscreen terminal (271x63 for me) it pegs an entire CPU continuously.
Tried to install via brew on an M2 and got:
mactop: The arm64 architecture is required for this software. Error: mactop: An unsatisfied requirement failed this build.
mactop: The arm64 architecture is required for this software. Error: mactop: An unsatisfied requirement failed this build.
Is your homebrew still running as intel under Rosetta?
Why does this require elevated privileges to run? Seems ridiculous for a top-like tool.
Tools like these need to be able to read various counters and other registers in the hardware. Note that powermetrics existed in MacOs since the Intel days and mirrors a lot of the x86 information provided by the Intel tool on Linux (the name of which escapes me at the moment).
You really don't want to give unprivileged code access to this data (check out the man page to see all of the information it can give you).
If you want to understand a lot of what this stuff means on Apple Silicon, you should (oddly) check out the Intel x86 documentation: https://www.intel.com/content/www/us/en/developer/articles/t...
You really don't want to give unprivileged code access to this data (check out the man page to see all of the information it can give you).
If you want to understand a lot of what this stuff means on Apple Silicon, you should (oddly) check out the Intel x86 documentation: https://www.intel.com/content/www/us/en/developer/articles/t...
The Linux tool is called Intel powertop.
How do Activity Monitor and AlDente get detailed power data? They don't prompt me to elevate privileges.
tyvm for the docs links! I still don't have any specifics in mind for useful attacks one could carry out using the data mentioned in `man powermetrics`. I assume the worry is that this stuff could play a role in some kinds of side-channel attacks but idrk much about low-level OS stuff. :-\
How do Activity Monitor and AlDente get detailed power data? They don't prompt me to elevate privileges.
tyvm for the docs links! I still don't have any specifics in mind for useful attacks one could carry out using the data mentioned in `man powermetrics`. I assume the worry is that this stuff could play a role in some kinds of side-channel attacks but idrk much about low-level OS stuff. :-\
I don't think that Activity Monitor is getting detailed info and thus doesn't need root. You can also get the same kind of info from powermetrics without root.
(it's been a while since I've messed with this stuff, I could be missing some details)
(it's been a while since I've messed with this stuff, I could be missing some details)
Nice. Similar to asitop, but looks a little more feature full.
This is awesome!
The sudo permission should be added by brew at install time (see how the dotnet SDK handles installation on macs), it's poor ergonomics to have to invoke it manually.
The sudo is for the runtime permissions, not the installation, of the program. dotnet requires (does it? it's been a while since I touched it but I vaguely recall this) sudo for installation, but not for execution.
Regarding .NET:
• .NET installers install to systemwide locations and therefore typically require elevated privileges.
• Microsoft supplies both install scripts (dotnet-install) and .tar.gz/.zip archives to support unprivileged installation to arbitrary locations on all supported platforms.
• The SDK and self-contained .NET executables run from anywhere, but certain SDK functionality may require elevated privileges on some platforms (e.g., installing a trusted self-signed developer certificate).
• Framework-dependent executables use the DOTNET_ROOT environment variable to locate runtime components installed in a non-default location.
• .NET installers install to systemwide locations and therefore typically require elevated privileges.
• Microsoft supplies both install scripts (dotnet-install) and .tar.gz/.zip archives to support unprivileged installation to arbitrary locations on all supported platforms.
• The SDK and self-contained .NET executables run from anywhere, but certain SDK functionality may require elevated privileges on some platforms (e.g., installing a trusted self-signed developer certificate).
• Framework-dependent executables use the DOTNET_ROOT environment variable to locate runtime components installed in a non-default location.
poor ergnomics? yes? but u know what's worse? setuid root executables.
it's the same for htop
Top is such a useful sysadmin command for high level sys info, and the new Macs are so quiet I rarely know if a processes has gone out of control, this will be a fun way to investigate that.