Linux devs in general seem to be quite content with absolutely atrocious tooling.

Why use a propriety steam hammer when you can bash things with open source rocks?

Nah, there are plenty of newer open source tools that people either resist using or don't even know about.

this but unironically

Something something grug printf is all you need. People who LARP as Unix neckbeards rejoice in having nothing. Not content, actively seek out worse solutions.

Real Scottish craftspeople enjoy having amazing tooling. They even know how to use a debugger!

Your either deep in the shit amazed anything works and respecting the world about you, so happy any tool at all is trying to make things better…

Or you have the free time to be a loudmouth online and mouth off about how tech's x y and/or z are dumb and how a shitty bash script is more than enough.

Thankfully I think now Linux has some really great tooling now. But very few people have calls of duty where they are called to do super serious work. Mostly the job calls for pretty simple shit. Make the dumb app go. Throw more servers at the problem someday. The tension is real. It's unfortunate that the cutting edge is so spread out, is so far in advance of the main body of devs.

I agree, and thanks to AI we can scream debuggers at each other online, amazed that THAT actually works.

I don't get why tho.

The most useful performance tool on macOS is spindump, which is just a straightforward whole-system CPU sampler. Second most useful is MallocStackLogging.

Other OSes have those too, but they're harder to use and the interfaces aren't as good.

The most useful tool was dtrace... Until Apple killed it with M2.

That's overkill for most things since it relies on being able to patch running kernel code, which is also the definition of an RCE exploit.

I think it should work if you run `bputil -c`? Didn't try it though.

It just doesn't work at all since M2. I've got a bug report open and confirmed and Apple officially does not care anymore. If you try to run it, it will crash your whole system.

> That's overkill for most things since it relies on being able to patch running kernel code, which is also the definition of an RCE exploit.

The idea of dtrace is that you can do that, yes, but to that, you need to be authorized, and the things you can do are (supposed to be) limited to looking to see what’s happening in the system. You can read arguments, but can’t, for example, change the arguments of a system call or disable authorization checks on system calls.

The reason dtrace doesn't work by default is the kernel memory is locked down so nothing can write to it. There are no exceptions to this even if you're authorized.

(Or rather, the exception requires restarting the machine to turn the security off.)

Windows Performance Analyser is pretty amazing. Not the simplest tool to use, but not particularly hard. Bruce Dawson's blog (https://randomascii.wordpress.com) has lots of articles using it.

I was going to ask, isn't this basically callgrind? I used that a lot in grad school to optimise our group's code (on an iMac no less). Incredibly useful and there are some nice visualisation / inspection tools.