DTrace also forms the basis for Apple's Instruments, which the author chooses to casually dismiss:
Also, OS X does have a command similar to 'strace' called 'trace'. The simplest way to use it is like this:
$ sudo trace -L <filename>
<terminate with ^C>
$ trace -R <filename> /usr/share/misc/trace.codes
If you run 'trace -h' it will tell you about more options for filtering, tracing for a fixed period of time, etc.
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.
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.
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...
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.
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).
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 :(
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.
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.
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.
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 so you know, people that have developed on Unix systems for decades have the same complaints about 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.
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.
In other words, he's saying that customizing/modding your own system and patching it (for yourself) is much more difficult than it is on Linux.
Yes it has motif for compatibility, but it also has Qt and Gtk. So I don't follow the implication that "certified Unix" means ancient platform.
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.
UNIX != Linux, and it is sometimes a real pain to use.
I had to visit customers with HP-UX installations that were a time travel to the 70's.
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.
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.
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.
well it's lldb nowadays, but anyway
The technical debt of level 1 will eventually kill you.
Disclaimer: I am at level 1
I'm pretty new to devops; I tried chef first and found it horrible; then salt came and saved me.