
Linux: still better for coding - r11t
http://antirez.com/post/linux-better-for-coding.html
======
vegai
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.

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

~~~
vegai
> and if you've been using Linux since 1996

Not exclusively.

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

~~~
pedrocr
_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:

<http://en.wikipedia.org/wiki/Ubuntu_Software_Center>

------
Zev
_Valgrind_

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.

    
    
      bash:~ Zach$ gcc -arch i386 foo.c -o foo
      bash:~ Zach$ file foo 
      foo: Mach-O executable i386

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

~~~
Zev
_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.

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

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

------
wooster
Things I would miss if I moved from OS X to Linux:

* Shark

* Instruments

* dtrace

* leaks

* TextMate

* Spin Control

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

~~~
biotech
This article is about Linux vs. _Mac_ for coding, not Linux vs. Windows.

~~~
blueben
It's also about available suites of tools to support development, not IDEs.

Gotta figure someone was going to chime in with the Microsoft IDE love though.

------
pkulak
Maybe coding C. I never use C. For dynamic languages, Objective C (obviously),
and web development, Macs work great for me.

------
shpxnvz
Better title...

Linux: still better for coding _in C_

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

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

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

------
dnaquin
this is why i run ubuntu in a vm and do all my serious development there.

------
onewland
I'd like to add that for web-related Ruby stuff, OS X is definitely the first
class platform, with Linux/other Unixes coming in second.

TextMate is considered the canonical rails editor for a reason.

~~~
iamaleksey
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/>).

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

------
davidw
Linux is a system by, and for hackers. That pretty much sums it up.

------
omouse
Should read GNU/Linux especially since one of the tools mentioned is GCC.

------
wglb
Er, might i recommend macports? It has valgrind and who knows what else.

And if you dig a little, can't you find most of the stuff that is in /proc?

I suggest digging a little more.

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

------
blasdel
_API stability._

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!

~~~
sid0
> The only way Win32 stays as stable as it is is by just not changing anything
> or even adding new APIs.

What the hell are you talking about? Vista (and to a lesser extent Windows 7)
have tons of new APIs.

Apple does not have a 64-bit version of Carbon. Name one Win32 API that is
similarly broken.

