My love-hate relationship with development on Macs

The pid provider is for probing calls and returns of userspace functions (the fbt provider serves a similar role for kernel functions). The closest things to this functionality would be the syscall and mach_trap providers. For the scheduling information that trace gives you, you could also use the DTrace sched provider. There are lots of events that trace captures that don't have any DTrace analogue, e.g. the CPU power state events.

DTrace is better for setting up targeted scripts that probe a relatively small number of events, especially when the precise events you want to capture depend on dynamic conditions, or for cases where you need backtraces. If you just want a firehose to analyze later, trace is better and has lower overhead. DTrace is also handy because of the builtin aggregation, which often saves you from having to write an awk or perl script to analyze trace output.

That line is incorrect. They author should have stated that "Mac OS X is like Linux, but some of the familiar Linux tools don't work."

> Why do you think people buy Macs in the first place?

I feel like the answer you are expecting to this question is also incongruous with the argument you are making: the Mac is not a platform for developers... if you want to spend less time messing around with software and have everything "just work", as a developer, you should be using a Linux distribution such as Ubuntu, not Mac OS X.

Different systems make different tradeoffs in simplicity, and Mac OS X is simply not optimizing for you: you probably shouldn't have bought a Mac "in the first place" if you expected to do a lot of development on your local system (unless, of course, you like messing around getting all of your tools working; some people surely do ;P).

Seriously: even installing something as basic as "gcc" is awkward (bunch of graphical steps to download gigabytes of stuff you didn't need, or a mysterious path through a website to get just command line tools, and in the end you have an ancient version anyway (or Clang, which isn't always going to compile whatever random other libraries or code you need to work with).

The point is that it's "no different than any other unix variant" in that none of them share a common toolset once you get beyond the basics. Go and try to develop on AIX or HP/UX with your Linux knowledge and you won't get very far.

Most of these ports are maintained by volunteers. Would you pay for working tools?

I'd love to see citations on clang bugs that persist without good reason (e.g. clang's adhering more closely to a standard, or refuses to implement a rarely used gcc extension).

Because you shouldn't be using gcc on a modern (post full 64-bit transition) OS X system. The llvm/clang/dtrace toolset is far superior.

Honestly, the gcc tools were never that great. On Sun systems, the Sun Studio set was always far superior and the other vendors had their own equivalents. Linux has just been "stuck" with gcc and the related Gnu tools since no one ever made anything better.

Or they have other tools that they feel are as good or better. e.g. Instruments, clang, dtrace. Valgrind is powerful, and it would be nice if it was perfectly supported on OS X, but it's not the end-all-be-all of runtime analysis and profiling.

And have you hit any issues with gdb that can be attributed to Apple's negligence? I think Apple's investment in clang, lldb and lld demonstrate they feel it's worth investing time and resources in having outstanding low-level development tools.

Maybe not, because they cannot seem to get Xcode working right all the time.

But the fact remains, almost every other platform is less hackable than linux.

Officially Certified Unix --> Officially Certified Dinosaur. Great ksh88 compatability? Motif? Thanks, I'll actually leave the 1990s alone and come back to the now.

My point had nothing to do with OS X being Unix (TM). It's just that OS X is a different platform than Linux and it shouldn't be surprising that things don't work the same way even though they're both Unix-y.

When Linux started to take over for old Unix workstations around the 2002-2004 time frame a lot of the old Solaris people would complain that "Linux doesn't have truss" or that "Linux's RPC headers are completely FUBAR." I would imagine they'd say even more vile things about OS X even though it has some fancy stamp of Unix approval.