I cannot take the author seriously, as there's no mention of DTrace — which isn't even OS X-specific, as it originated on Solaris, has a good FreeBSD port, and even some rumored-to-have-once-been-working Linux port attempts. (Didn't work last time I tried them, which was half a year ago.) There's a useful book covering all supported platforms:
<a href="http://dtrace.org/blogs/brendan/2011/02/23/dtrace-book-sample-chapter-file-systems/" rel="nofollow">http://dtrace.org/blogs/brendan/2011/02/23/dtrace-book-sampl...</a><p>DTrace also forms the basis for Apple's Instruments, which the author chooses to casually dismiss:
<a href="http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/InstrumentsQuickStart/InstrumentsQuickStart.html" rel="nofollow">http://developer.apple.com/library/mac/#documentation/Develo...</a>
The best way to use DTrace is by writing your own DTrace scripts rather than using dtruss or another wrapper.<p>Also, OS X does have a command similar to 'strace' called 'trace'. The simplest way to use it is like this:<p><pre><code> $ sudo trace -L <filename>
<terminate with ^C>
$ trace -R <filename> /usr/share/misc/trace.codes
</code></pre>
That will print out a formatted list of events with timestamps, etc. BSD system calls are formatted with the 'BSC_' prefix, and Mach system calls are formatted with the 'MSC_' prefix.<p>If you run 'trace -h' it will tell you about more options for filtering, tracing for a fixed period of time, etc.
I have a hard time being overly sympathetic here. complaining about building from source and can't get profiling tools running? Building code is being a developer, and osx is no different that any other unix variant, it has its own toolsets, like dtruss, shark etc. I don't get why gprof doesn't work for you, it works fine for me on osx.<p>this just seems like a lot of whining. If I wanted to debug a process that would occasionally get into a tight loop I'd run it under the debugger and break into it when it was peaking on the watt meter. A developer isn't just a programmer, the difference is that a developer can program and work the system, use the tools, debug the code, tune the kernel, etc etc.
I have used Instruments.app for my programming and I've used Valgrind, and there have already been two cases that dtrace (the provider that Instruments uses) has found memory leaks in my programs that Valgrind did not complain about, nor care about.<p>As for tracing system calls, dtrace is extremely powerful, and I much prefer it over strace where I a lot of times get a lot of garbage and have a hard time slimming down the output. I bet it comes down to what you are used to, and this guy is used to his Linux developer tools, whereas someone like myself would feel lost without dtrace, ktrace (trace on Mac OS X), sample, and various other tools that I use on a regular basis.
Just to point out something on the bit about installing GNURadio, Homebrew (<a href="http://mxcl.github.com/homebrew/" rel="nofollow">http://mxcl.github.com/homebrew/</a>) is really a great alternative for MacPorts and someone has already made a Homebrew Package for GNURadio (<a href="https://github.com/titanous/homebrew-gnuradio" rel="nofollow">https://github.com/titanous/homebrew-gnuradio</a>) which uses 3.6.1 (3.6.2 is the latest version but i'm sure you can update it easily)
I never bother. I find it much easier and much less hassle to use VMs. With Fusion, you can create snapshots, try something out and revert back if it doesn't work out.<p>This way my primary OS stays as clean as possible (text editor, browser, fusion) and my VMs can be my messy playground.<p>Don't get me wrong, brew and ports are great but their very existence makes we wary of venturing too far down the rabbit hole of development directly on OSX.
I think as many developers have been waiting for dtrace on Linux, which imho is a lot nicer.<p>It is mostly a question of what you're used to. To some extent the raw dtrace interface is a lot more powerful than Instruments though, so unfortunately you have to learn it before you can take advantage of most of the power of dtrace.
reminds me a bit of the gdb bugs they had for a very long time.<p><a href="http://reverse.put.as/2008/11/28/apples-gdb-bug/" rel="nofollow">http://reverse.put.as/2008/11/28/apples-gdb-bug/</a><p>well it's lldb nowadays, but anyway
level 1: futs around with OS X / brew / macports / whatevever package manager you pray to for hours to setup a dev env
level 2: virtualize your target platform with vmware fusion
level 3: vagrant + chef your target platform and rebuild them at will<p>The technical debt of level 1 will eventually kill you.
Disclaimer: I am at level 1