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:
http://dtrace.org/blogs/brendan/2011/02/23/dtrace-book-sampl...
This. I've written several C programs against POSIX (primarily targeting linux, but OS agnostic) and compiled them in OS X just so I could use DTrace/Instruments (after valgrind and gprof in linux).
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.
If you run 'trace -h' it will tell you about more options for filtering, tracing for a fixed period of time, etc.
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.
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.
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.
It seemed more like warning than whining, if indeed it's any more than a simple story of something vaguely surprising to the author. There is no need for blog posts to be interesting or momentous, only well-written.
And "Mac OS X is like Unix, but some of the familiar Unix-like tools don't work" seems like a useful enough warning to me. After all, who wants to learn new tools? Nobody who has something to actually do...
Or, "Mac OS X _is_ UNIX, so all of the familiar UNIX tools work, but Linux is _like_ UNIX, so many of the familiar tools work differently." Where differently is generally a superset.
I want to build my code, not other people's code. I just want to use the tools, not spending lots of time making them work. Why do you think people buy Macs in the first place?
> and osx is no different that any other unix variant, it has its own toolsets, like dtruss, shark etc.
Except that Unix variants can be extremely different once you go beyond the basics (shell, cd, ls, cat, grep). Kernel interfaces, package managers, directory structures, dynamic linkers, authentication. "No different than any other unix variant" makes no sense.
> 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.
Learning, and forcing yourself to rely on the POSIX subset of utilities and libraries makes it significantly easier to not care which Unix-like operating system you're using.
It's just that on Linux open source development tools [and libraries] work out of the box. Sudo apt-get, and you are in business. Not the case on Macs. Apple tend to break things with every xcode/clang release. And things tend to stay broken.
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).
Well, aside from clang + boost + mac monstrosity [there is always something wrong with boost + clang + mac], I haven't seen any persistent problems with clang itself.
It's just that configure+build on mac is often a time sink... You try a default ./configure - it picks up legacy gcc4.2. Fail. You try forcing it to clang - there is something wrong with the switches/defines/gcc exts/etc. Easy to fix. But still sinks time :(
I've had issues with gprof and gcov. In particular, gcov doesn't seem to pick up functions called via function pointer on OSX, a task which it does fine on Linux.
As someone doing somewhat Serious C Development, I'm beginning to come to the conclusion that while OSX might be a good platform for developing higher-level languages, the C support just isn't there in the way I need it to be, which is quite ironic really.
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.
If Apple cared about developers writing low-level code, they would pay one developer to make sure that Valgrind, debuggers, and the like worked out of the box.
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.
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.
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 (http://mxcl.github.com/homebrew/) is really a great alternative for MacPorts and someone has already made a Homebrew Package for GNURadio (https://github.com/titanous/homebrew-gnuradio) which uses 3.6.1 (3.6.2 is the latest version but i'm sure you can update it easily)
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.
>But the fact remains, almost every other platform is less hackable than linux.
Was that a typo? If not, do you have any sources to show this? I don't know or have an educated opinion either way, but that statement does contradict common perception.
By almost every other, I think he means all the commercial distributions of UNIX, which really are not very interesting to most hackers. I don't think he meant the BSDs.
That's a strawman argument. The author says nothing about the Officialness of the Unix. His complaint is that he can't get at the guts of the system, nothing to do with branding.
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.
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.
This way my primary OS stays as clean as possible (text editor, browser, fusion) and my VMs can be my messy playground.
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.
Not to mention you can now run OSX within OSX using VMWare and the like - easy way to run multiple speculative profile branches and snapshot back to a known good state whenever you want.
I tend to use Linux while developing, however so I do OSX host, Linux guest -> deploy to fabric or cloud host for system/performance testing.
I think as many developers have been waiting for dtrace on Linux, which imho is a lot nicer.
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.
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
The technical debt of level 1 will eventually kill you.
Disclaimer: I am at level 1
DTrace also forms the basis for Apple's Instruments, which the author chooses to casually dismiss: http://developer.apple.com/library/mac/#documentation/Develo...