Hacker News new | past | comments | ask | show | jobs | submit login
My love-hate relationship with development on Macs (rachelbythebay.com)
68 points by vectorbunny on Sept 14, 2012 | hide | past | web | favorite | 46 comments

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

DTrace also forms the basis for Apple's Instruments, which the author chooses to casually dismiss: http://developer.apple.com/library/mac/#documentation/Develo...

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

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.

dtrace's pid provider should do this as well.

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

That line is incorrect. They author should have stated that "Mac OS X is like Linux, but some of the familiar Linux tools don't work."

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.

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

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

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

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.

Except that POSIX like all standards, has a tendency to have different quirks across implementations.

Most of these ports are maintained by volunteers. Would you pay for working tools?

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.

And many people don't realize that Oracle Studio is available for Linux as well.

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.

Maybe not, because they cannot seem to get Xcode working right all the time.

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)

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.

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

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.

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.

Solaris 11 is certified Unix and has ksh93, zsh, csh, and bash (I think others as well). Bash is also the default shell.

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.

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.

This is what many kids that only know Linux don't get.

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.

Your point seems rather self-evident then, since the author is complaining about the low-level functionality of the different platforms.

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.

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


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

The technical debt of level 1 will eventually kill you. Disclaimer: I am at level 1

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.

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.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact