As a Linux users from 1996, Macs seem all the time more enticing. But, but... the interface still sucks -- in comparison to modern X11 window managers such as awesome and xmonad -- and what's worst, it's not so easily replaceable.
Besides, if I would replace the OS with Linux anyway, what's the point of buying an Apple?
It's still lightyears above any Windows setup, of course. Especially for the common guy.
> It's still lightyears above any Windows setup, of course.
I'm not looking for an OS-fight, but why make silly claims like that? There are a lot of smart and highly productive people who choose Windows, and if you've been using Linux since 1996 you probably don't know much about modern windows dev setups.
I think it would be nice if additional memory checkers and profilers worked on Mac OS X, but the article doesn't mention the (extremely powerful) suite that does come with the OS: Instruments.
API stability is a question of the framework, I suppose. Objective-C as a language isn't really in the same league as C as far as API stability, because it's fairly easy to deal with evolving parts in a semi-dynamic language. Perhaps that is why Apple is more careless when it comes to changing things.
Package management has a place in my heart, too, though. I have seen many attempts to do this that fall far short, and not just on Mac OS X. I suppose what I'd really like is something as powerful as apt-get, but merged with some kind of App Store; and I hope that Apple is working on such a thing.
Package management has a place in my heart, too, though. I have seen many attempts to do this that fall far short, and not just on Mac OS X. I suppose what I'd really like is something as powerful as apt-get, but merged with some kind of App Store; and I hope that Apple is working on such a thing.
Ubuntu is creating this. It's called the Ubuntu Software Center:
Works with OS X nowadays. Plus, Xcode has the benefit of Clang's Static Analysis being built right in. You really can't beat checking one box and having it automatically scan over your code when you build to point out a lot of mistakes (like leaks or logic that's never hit). True, different purposes. But, you can install Valgrind. And in the meantime, Clang will catch some things for you, before you have to find them with Valgrind.
// edit: Whoops, I was wrong: Valgrind doesn't work on Snow Leopard yet, like I initially thought.
Apt-get
If you're targeting another Mac system, do you really want to ship your own version of Tck/Tk? Do you really want to use a custom library for your own development and another for shipping? Or do you want to use the one the system provides? Hint: The latter allows for much smaller downloads. Lets the user start using your software much quicker.
API stability
Theres applications out there that work on PPC and 32/64bit Intel, on any OS from Jaguar on. 7 year old applications that still work perfectly fine, across OS's that have had major changes, seems to be pretty stable API-wise to me. Not to mention, there are API's that have been deprecated since 10.3, but can still be used (even though you really shouldn't use them) in 10.6.
/proc filesystem
See the `sysctl` command instead. Bonus: You can access all this information with a sysctl() call in code too!
Compiler
Given Xcode ships with gprof, I'd be highly surprised if it doesn't actually work. And theres always Shark, that can be run without having to add special profiling flags when compiling. Or Instruments (ie: DTrace).
As for -arch i386 not working? Thats just not true.
Hello. Valgrind for Snow Leopard was broken and in the latest weeks got a patch that's just an initial support. Don't know if things improved in the last week or so, but last time checked it was not ready for prime time.
About -arch i386, sorry my English is poor, what I mean is, gprof is not working even with binaries compiled with -arch i386.
Edit: forgot to mention that there are things in Mac OS X that are missing on Linux and I like a lot. For instance dtrace and leaks. Leaks is really cool since it can check memory leaks at run-time with a standard executable, and works very well.
About -arch i386, sorry my English is poor, what I mean is, gprof is not working even with binaries compiled with -arch i386.
Thats still wrong:
247:~ Zach$ gcc -pg -arch i386 foo.c -o foo
247:~ Zach$ file foo
foo: Mach-O executable i386
247:~ Zach$ ./foo
hello
247:~ Zach$ gprof foo
call graph profile:
The sum of self and descendents is the major sort
for this listing.
function entries:
[rest of the output snipped, I can pastebin if you want.]
Though, you should really look at Shark (`man shark`, or Developer/Applications/Performance Tools/Shark.app), as an alternative to gprof.
However, you are right about Valgrind not working on Snow Leopard yet. I had thought it was working by now. Whoops, on my part. I edited my first post.
Yep with -arch i386 it appears to work but the profiling info it returns is all zeroed. There are the functions but mostly 0% everything. Don't know what's the problem. With 64 bit target it's worse than this (some error printed on screen at startup).
Thanks for the hint about Shark, I'm playing with it and it seems cool indeed.
> Yep with -arch i386 it appears to work but the profiling info it returns is all zeroed.
That's the story of OS X since from when it was first released. For example, you'd have some functionality advertised as being in the system libraries (like, oh, certain important pthread functions) so they'd pass the configure checks, but they would be in reality just stub functions that mean nothing. So your program would subtly fail.
That particular problem was fixed in 10.1, but it seems like every release has a few things like that: something from UNIX that looks like it's there, but actually amounts to no-ops. It's maddening.
Or do you want to use the one the system provides? Hint: The latter allows for much smaller downloads. Lets the user start using your software much quicker.
This is certainly what I try to do, as well. However, it is not for the faint of heart. For instance, I had to be extremely creative in order for my app to use the system Python, and yet work correctly (it was bound to C++) on Mac OS X 10.3.9 through 10.6.
I developed for Linux in C++ for about 8 months recently. We did all of our development from Windows with Visual Studio and Visual Assist X because Linux doesn't have anything even close to the same quality (Qt Creator is only about a year away from catching up, and is brilliant software, but isn't there yet).
Boost's unit test library has memory leak detection built in, and Intel's performance analysis tools integrated into Visual Studio utterly trounce Valgrind. ICC embarrassingly outperforms GCC.
Linux development is still way the hell behind, and if the article's to be believed, apparently blissfully unaware.
[EDIT] To clarify, the article is specifically discussing issues with developing native programs on OSX which do not apply to developers in many other languages.
Indeed many points are about C, but the point about apt-get is really about configuring a web development environment with any language and apache module in minutes.
I did notice the point about apt-get as being broadly applicable. However, thanks to Fink I have apt-get on OSX which works dandy for almost everything I've tried to install.
You wouldn't have mentioned it if you hadn't run into problems, so I would imagine there are probably some pretty rough edges around native libraries. As such, I considered that those comments must also be specific to native programming.
Sure, and that reason is that it was used in the canonical screencast.
Nowadays vim (or MacVim) seems to be the preferred editor, at least among the top rails blogging crowd. It's hard to beat tpope's rails.vim (http://rails.vim.tpope.net/).
Canonical is canonical. How many great Rails coders would you guess DON'T have Agile Web Development with Rails?
Agreed on the preference of vim, but I wouldn't knock de facto standards. I bet most people use the idiomatic NULL=0 in conditionals [if(possiblyNullPtr)] just because K&R did it.
Hello, I explained in the article that all the stuff in /proc are exposed by Mac OS X as well, just I like more the /proc interface that allows to work in "discovery mode".
About macports, I specifically mentioned find and homebrew, but just this are not the same quality of apt-get and many things are missing.
What the fuck are you smoking? Mac OS X has by far the most stable APIs of any modern development environment. They change existing APIs and add with every major release -- but they do so in a new SDK. Apps that were linked against the 10.4u SDK use the 10.4u libraries, even on 10.6. This is fucking amazing.
The only way Win32 stays as stable as it is is by just not changing anything or even adding new APIs.
For instance I compiled nmap yesterday for snow leopard, and guess what, it was not working, unable to open the interfaces. The compiled binary I downloaded from insecure.org worked against the loopback interface but not against the wifi one. The interface to capture raw frames from the airport extreme changed again with snow leopard, breaking valuable programs like Kismac. It's not an open platform so this changes are even worse.
Now you're effectively complaining about Kernel ABI compatibility!
Besides, if I would replace the OS with Linux anyway, what's the point of buying an Apple?
It's still lightyears above any Windows setup, of course. Especially for the common guy.