
My love-hate relationship with development on Macs - vectorbunny
https://rachelbythebay.com/w/2012/09/13/opt/
======
mietek
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...](http://dtrace.org/blogs/brendan/2011/02/23/dtrace-book-sample-
chapter-file-systems/)

DTrace also forms the basis for Apple's Instruments, which the author chooses
to casually dismiss:
[http://developer.apple.com/library/mac/#documentation/Develo...](http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/InstrumentsQuickStart/InstrumentsQuickStart.html)

~~~
jonhohle
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).

------
cwzwarich
The best way to use DTrace is by writing your own DTrace scripts rather than
using dtruss or another wrapper.

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
    

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.

~~~
lallysingh
dtrace's pid provider should do this as well.

~~~
cwzwarich
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.

------
hnriot
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.

~~~
FooBarWidget
> Building code is being a developer

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.

~~~
saurik
> 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).

~~~
igrekel
"you probably shouldn't have bought a Mac "in the first place" " Especially if
its to run it headless as mentioned in the latest post...

------
X-Istence
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.

------
suhailpatel
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)

------
adestefan
TL;DR OS X isn't Linux.

Just so you know, people that have developed on Unix systems for decades have
the same complaints about Linux.

~~~
sltkr
In fact, OS X is a certified Unix system (while Linux isn't, officially, but
close enough).

~~~
lallysingh
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.

~~~
jemka
>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.

~~~
lallysingh
Hacking, not cracking: [http://www.techrepublic.com/blog/security/hacker-vs-
cracker/...](http://www.techrepublic.com/blog/security/hacker-vs-cracker/1400)

------
purephase
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.

~~~
r00fus
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.

------
jensnockert
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.

------
rjzzleep
reminds me a bit of the gdb bugs they had for a very long time.

<http://reverse.put.as/2008/11/28/apples-gdb-bug/>

well it's lldb nowadays, but anyway

------
godisdad
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

~~~
RoboTeddy
vagrant + <http://saltstack.org/> is my favorite solution to this problem.
(<https://github.com/saltstack/salty-vagrant>)

I'm pretty new to devops; I tried chef first and found it horrible; then salt
came and saved me.

------
pi18n
For the record, I despise almost everything about Xcode, but it is still
usable and I think the llvm debugger and Instruments work fine enough.

