6 ms·

My love-hate relationship with development on Macs

68 points by vectorbunny 14y ago

jensnockert 14y ago
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.
suhailpatel 14y ago
Just to point out something on the bit about installing GNURadio, Homebrew (http://mxcl.github.com/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 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)
purephase 14y ago
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 14y ago
  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.
adestefan 14y ago
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 14y ago
  In fact, OS X is a certified Unix system (while Linux isn't, officially, but close enough).
  - lallysingh 14y ago
    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 14y ago
      >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 14y ago
        Hacking, not cracking: http://www.techrepublic.com/blog/security/hacker-vs-cracker/1400 http://www.techrepublic.com/blog/security/hacker-vs-cracker/...
      - jeremyjh 14y ago
        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.
      - chimeracoder 14y ago
        He's using hacking to mean 'messing around with one's own system', not 'gaining unauthorized access to another person's system.' 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.
cwzwarich 14y ago
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 14y ago
  dtrace's pid provider should do this as well.
  - cwzwarich 14y ago
    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.
X-Istence 14y ago
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.
godisdad 14y ago
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 14y ago
  vagrant + http://saltstack.org/ http://saltstack.org/ is my favorite solution to this problem. (https://github.com/saltstack/salty-vagrant 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.
hnriot 14y ago
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.
- dchichkov 14y ago
  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.
  - ryannielsen 14y ago
    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).
    - dchichkov 14y ago
      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 :(
- jedbrown 14y ago
  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.
rjzzleep 14y ago
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/ http://reverse.put.as/2008/11/28/apples-gdb-bug/ well it's lldb nowadays, but anyway
mietek 14y ago
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-sample-chapter-file-systems/ http://dtrace.org/blogs/brendan/2011/02/23/dtrace-book-sampl... DTrace also forms the basis for Apple's Instruments, which the author chooses to casually dismiss: http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/InstrumentsQuickStart/InstrumentsQuickStart.html http://developer.apple.com/library/mac/#documentation/Develo...
- deleted 14y ago
  [deleted]
- jonhohle 14y ago
  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).
pi18n 14y ago
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.

68 points by vectorbunny 14y ago

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.

suhailpatel 14y ago

Just to point out something on the bit about installing GNURadio, Homebrew (http://mxcl.github.com/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 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)

purephase 14y ago

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 14y ago
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.

adestefan 14y ago

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 14y ago
In fact, OS X is a certified Unix system (while Linux isn't, officially, but close enough).
- lallysingh 14y ago
  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 14y ago
    >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 14y ago
      Hacking, not cracking: http://www.techrepublic.com/blog/security/hacker-vs-cracker/1400 http://www.techrepublic.com/blog/security/hacker-vs-cracker/...
    - jeremyjh 14y ago
      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.
    - chimeracoder 14y ago
      He's using hacking to mean 'messing around with one's own system', not 'gaining unauthorized access to another person's system.' 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.

cwzwarich 14y ago

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 14y ago
dtrace's pid provider should do this as well.
- cwzwarich 14y ago
  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.

X-Istence 14y ago

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.

godisdad 14y ago

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 14y ago
vagrant + http://saltstack.org/ http://saltstack.org/ is my favorite solution to this problem. (https://github.com/saltstack/salty-vagrant 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.

hnriot 14y ago

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.

dchichkov 14y ago
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.
- ryannielsen 14y ago
  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).
  - dchichkov 14y ago
    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 :(
jedbrown 14y ago
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.

rjzzleep 14y ago

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/ http://reverse.put.as/2008/11/28/apples-gdb-bug/ well it's lldb nowadays, but anyway

mietek 14y ago

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-sample-chapter-file-systems/ http://dtrace.org/blogs/brendan/2011/02/23/dtrace-book-sampl... DTrace also forms the basis for Apple's Instruments, which the author chooses to casually dismiss: http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/InstrumentsUserGuide/InstrumentsQuickStart/InstrumentsQuickStart.html http://developer.apple.com/library/mac/#documentation/Develo...

deleted 14y ago
[deleted]
jonhohle 14y ago
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).

pi18n 14y ago

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.