1) I've tried installing both Macports and homebrew, and some utils did not work, as whichever got put in the path first, confused the other. I suppose I could have made a seperate symlink directory, for just the binaries I wanted.

2) I found 'brew install coreutils' broke some build scripts , which expected proper mac tools, if I put them all in path.

3) I find about 10% of the time I try to install something from brew, it fails to build. g++ 4.6 failed just 20 minutes ago. That is a real pain.

I can't comment on the memory, except that I find my 4GB of RAM seems to go much further when I dual-boot my macbook into Linux. It might happen to be the programs that I run.

2) Don't put them in the PATH. They're prefixed with 'g' so you can make an non-prefixed alias for your interactive shell, and use the prefixed variant in your scripts if need be. If you write portable scripts you're either using common features or use some vars for those utils, aren't you?

3) g++? that's not in homebrew...

Honestly though, MacPorts is a real pain. That's why I worked with others to bring Arch's pacman on OSX (dubbed ArchOSX) some years ago, but binary hosting was proving being a chore, and then Homebrew started taking off, and in my case Just Works.

I'm the guy who implemented the feature and I am realising that as I didn't shout very loudly people don't realise that it exists.

For example Qt has a bottle: https://github.com/mxcl/homebrew/blob/master/Library/Formula...

The reason we aren't doing this for more packages is basically people power and hosting (as I'm not sure Sourceforge would be happy we hosting the number of binaries we'd want to have).

Hope that explains a bit. Feel free to comment if you think we're taking a good/bad approach here.

    3) g++? that's not in homebrew...

    Homebrew started taking off, and in 
    my case Just Works

In general Homebrew did a good job for me, but it did break on me a couple of times. And when it did, fixing it caused me a lot of stress, because in the end it's really not much better than "./configure && make && sudo make install".

What I don't understand is how come we can't have binary repositories, like Debian's. Certainly Debian has to handle much more architectures and the number of packages contained is really huge. So how come there isn't such an alternative for Mac OS X? Why are solutions like Homebrew and MacPorts insisting on compiling the packages locally?

    Homebrew started taking off, and in 
    my case Just Works

Here's another: it worked for me perfectly, in and of itself. I use pianobar, which frequently updates (due to Pandora changing protocol or keys), and I often have to do some recipe editing to get that latest update, but it seemed simple enough. Since the brew update list doesn't get fixes anything like as fast as the pianobar author updates when something breaks, it seems to me that having to wait for someone to actually compile pianobar elsewhere would mean that I'd have to wait days for the packaged version.

Unfortunately, building the packages and then keeping them current takes quite a bit of infrastructure which is why fink's binary packages are really outdated at times.

The other issue is with runtime-dependencies: Self-compiling packages gives you the freedom to, say, build vim without X11 support. With binary packages, the maintainer (or the packaging system) must create n packages for n possible combinations (if the project doesn't have some dynamic-library based plugin system) which is, again problematic from a resource-requirement perspective.

Apple are never going to provide Linux-style package management tools because the market for them is minuscule compared to Apple's real market: normal people. For normal people, there's the App Store.

It seems like the OP's point is pretty valid to me. I use an OS that gives me what I need to do my job.

No. They aren't. Developers have needs far greater than that of your average everyday user. Apple sells a machine that is the best possible for the greatest number of users, and doesn't really cater to niche markets. I don't get what's surprising about this.

Linux and Windows feel like they exist on opposite ends of the spectrum.

What they don't host is the source or compiled versions of any of the packages in the MacPorts repository - potentially for the same reason they include no GPLv3 software in their OS.

Its kind of like developing on windows, for windows, gota do what u gotta do.

So that an OS upgrade, in which Apple tends to include arbitrary upgrades to system libraries (or the Ruby/Python etc version), doesn't break whatever you installed with Homebrew/MacPorts.

This rarely fails. When it does, it's user error.

What do you mean? People are saying that about homebrew all the time. Have you read on blog posts on it?

It just worked for me too, and I have around 20-25 packages installed.

2) I am not talking about my own scripts, I am talking about other peoples. I could obviously go through and debug them, and then check I haven't broken them on a couple of linuxes, and a mac without macports/homebrew but... I don't want to.

3) You are right, it looks like gcc and gdb have both been taken out of homebrew, I assume because they didn't work. They were there previously.

Certainly I find homebrew very useful. Just now I noticed the one thing I used in fink in now in homebrew, so have removed fink which should also hopefully slove problems.

However, as time goes by, I find the OSX is getting slowly worse. In the days of OS X 10.1, the various command line tools were in sync between linux and mac os x, and now that is certainly not true, and I find the linux set more useful, especially in a default state.

Which is why the alias solution is nice, as it will only impact the interactive shell, not the scripts.

I've been using Homebrew for about a year and haven't ever had an issue like that.

I find it quite the contrary as it summons git power upon /usr/local. So the workflow is basically just editing live in /usr/local/Library/Formula ('brew create url' scaffolds in many cases, 'brew edit formula' gets you to an existing one), committing, and handling merges on pull (which is what 'brew update' does)

If you want to contribute back, fork on github and add your repo as a remote, then push and submit a pull request.

It's really different than apt (which it is normal as Debian packaging has a massively different scope) , but IMHO much, much simpler and efficient.

Bonus points for then using working, legal, VM's for the OSX moments. Or, if you like, just boot from a removable linux SSD for work, reboot for OSX.

I have a slight edge-case, where I would like to install Debian Mint onto a 32GB flash drive, and boot from that. I have a Macbook Air and disk space is at a premium.

Googling around has been to no avail.

If it's possible (though absolutely not necessary) – my OSX and Debian files could be shared when booted into either – that would be great!

You can but you'll have to share data on a non-journaled HFS+ partition for it to be writable from Linux. Watch out for UIDs/GIDs: https://wiki.archlinux.org/index.php/MacBook#Home_Sharing

ArchLinux has their img booting from usb, so I don't see why not.

Yeah, you could. Also, why install both? Anyway, welcome to software. It ain't perfect. You think it'll be better with Linux? I've had happen to me on Debian a few times, and lotsa times with RPMs. But even if it does not happen, there are several other software you cannot install on Linux, like, all Mac Cocoa Apps, from iWork to Photoshop. If you don't care about having access to those, then you don't need OS X in the first place.

I found 'brew install coreutils' broke some build scripts , which expected proper mac tools, if I put them all in path.

So, you generally wanted a Mac in order to install large quantities of third party unix software in the core system on top of same regular binaries???? Do you go install FreeBSD and then add a Linux userland? Do you install Debian/Ubuntu etc and then go change the system, say, Python? Because people that tried it also found it's a world of pain.

I can't comment on the memory, except that I find my 4GB of RAM seems to go much further when I dual-boot my macbook into Linux. It might happen to be the programs that I run.

You're doing it wrong.

Most software developers that use OS X just want a decent GUI on top of Unix. So yeah, they do generally want a Mac in order to install large quantities of third party Unix software.

Do you install Debian/Ubuntu etc and then go change the system, say, Python?

Yes. I have had no problems with it.

You're doing it wrong.

You're probably not doing enough to notice that memory usage absolutely sucks under OS X.

I use homebrew for almost all of the dependencies that I have, there are one or two that I compile by hand.

I've not had any issues. Best of all, I don't need the g* stuff to do my builds. I am perfectly happy with clang and the BSD tools available.

I don't understand why people purchase Mac OS X based computers then want to run GNU coreutils on top of it, or want to Linuxize their entire install. Off course something is going to break at that point, especially when build tools expect certain versions of certain tools to be available.

Because only Apple has figured out how to make and sell great laptops running Unix at a (relatively) reasonable price and where all the hardware and drivers just works out of the box. If I could have bought a computer as good as the macbook Air in every way, but with Linux instead of OS X and guarenteed zero driver or hardware comparability issues I would have. But I couldn't so I bought a Mac.

"Just works" is relative. Given that Apple controls both the Wifi card and the driver for their machines, and that it offers a limited range of such cards, it sure is better poised to "just work" than some obscure wifi card used in a PC alongside with some third-party open source driver for it. This is, pretty much, common sense.

So, as relativity goes, it's pretty much true, or Apple wouldn't hold the higher user satisfaction position of multiple years in a row, with over 20% distance from the second runner.

I wasn't making any statistical claims whatsoever. I replied to someone talking about "zero driver or hardware comparability issues".

For starters, you are not. You are just buying the equivalent of top-tier machines from other brands. If you compare the equivalents hw specs AND build quality (from the external design to the materials like aluminum used, to the extra cost for an unibody construction, to the extra engineering effort and cost to pack things lightly and thin, to the thunderbolt ports, to the display quality etc), you either end up same price, or cheaper or the thing doesn't exist at all in the PC side. Even worse with iPads and iPhones, which have competitors struggling to compete on price.

I expect to have driver issues fixed in short order

Well, I guess you can go to an Applestore and have the machine changed if it doesn't work, or get your money back.

But in general "X issue fixed in short order" is not how it works, even when buying mainframes for top dollar. Sometimes you just have to wait until the engineers find the root of the problem and come up with a solution. Sometimes it even takes the next generation of machines for the problem to be fixed, if it's a HW bug. Sometimes it never does, if it affects some small percentage of machines with some strange setup (e.g with that brand of router, when set to those settings, etc).

I replied to someone talking about "zero driver or hardware comparability issues".

If anyone claims "zero driver or hardware comparability issues, he is clearly delusional or just speaks for himself. iBooks circa 2003 even had their logic boards fail multiple times, for example. Or G5's had strange goo coming out from their cooling system. I had a failed DVD on a Macbook Pro. Still, the same kind of things happen to PC runs all the time (I've had too many such cases from '91 to '05), they are just so fragmented as a platform that you never get to hear from them.

A Macbook run is 10 million machines of the same* specs. How much is an Asus 105-SH/i-mkII run? Or a Dell run, considering it offers 2,000 build to order configuration combinations? 1% of a Macbook run in hundreds of thousands of people, 1% of those runs is like nothing, so you don't get to hear much. Not to mention that they don't have forums and sites dedicated to the machines, anyway, just broad websites for all PCs.

So when I said "I'm paying double what I would pay for other brands" I meant it literally, including the "I". The set of machines that meet my requirements includes machines from the likes of Toshiba that cost less than half of Apple's cheapest offering.

The reason why I still bought from Apple is that I need a Unix system and I hate dealing with driver issues. So having to deal with unfixed driver issues is the quickest way to drive me away.

(I did not downvote you by the way)

Then there are minor things like that there are no stores anywhere around here that sells them, meaning I'd have to buy one without playing with it first. Also it's basically impossible to buy one without a Swedish keyboard layout in Sweden, while Apple will happily let me choose any keyboard layout I want. None of these are deal-breakers in them selves but they're things that kind of add up.

You bring up good points and my article would need some clarification on some parts, I agree on that. I'll just write quick replies back to you, and try to format something on the article itself later.

Purge really did free memory and quite a lot. I'm not too expert (as you probably can tell) how the OS X memory management works, but I mostly settled with solutions that seemed to help my problem. Maybe there was some third party software that messed things up.

The problem with the inactive memory is that it is not freed, it is swapped. So when hitting memory limits of my system, the computer started swapping. Just freeing the memory, in my case, would have been much quicker. Practically my machine was constantly swapping when the memory limit came up. As you said, repair disk permissions caused all this to happen due to filling memory with disk cache. So that was a nice solution to my problem; a way to force swapping on inactive memory.

Python point is bit wrong, I was indeed trying to argue that installing python packages is impossible through homebrew. However, I did use a lot pip+virtualenv, so that's at best a bit vague argument on the OS X side. However, in production I always rely on the packages provided by the OS, not pip + venv, unless really necessary. This is mostly because it makes it easier to keep system up-to-date.

I'm sorry if this showed up as uninformed rant, but I just wanted to share how I felt using OS X and Macbook for a year as my primary computer.

That's just not true. If inactive memory is something that's already backed by disk (like a memory mapped file), it'll be discarded. Only if it's read-write memory that's /currently held allocated by a running process/ will it be swapped out to disk. Unless you're doing something pathological (like suddenly allocating lots of RAM and forcing paging - what purge utilities do...), the architecture /speeds things up/.

If it's really true that, without doing anything special, things were always being swapped out to disk for you, it necessarily means that there was a process that had allocated (lots, it sounds like) of RAM and written to it, so that stuff had to be paged out to disk to free up RAM without losing data.

It sounds like you were running purge commands or utilities to 'free up RAM'. That is counterproductive. It causes the system to release cached 'clean' (i.e. as already on disk - a mapped file, essentially) mapped RAM and swap read-write memory out to disk, only then have to re-read it all when you actually need it. In other words, using purge 'utilities' actually puts the system into the worst possible state.

I am one of the devs out there running a Macbook Pro with 8Gig of memory (I wish I could have more but I have a 2010 old model). For web development, I have at least Firefox/Chrome/PhpStorm/SmartGit/Mamp/Thunderbird/Terminal/Notational Velocity/Dropbox/Alfred/Sophos AntiVirus open at all times. Now, a long the way, I may open a few other apps that I use rarely, like Photoshop/CyberDuck/VMWare Fusion/iTune/iCal/iOS Simulator/Preview/LibreOffice/Skype. Now, pretty quickly 8Gig gets used up, and the system runs to the ground shortly after.

If I then have VMWare Fusion shutdown for awhile, and relaunch later, the system really just can't take it anymore. The last resort? purge&

At least, that's my day-to-day experience with OSX. Personally, I find the memory management really lousy, worse than other other OSes I used in the past (both Windows & Ubuntu/Fedora/Gentoo).

So why the heck I use Mac still? Because of the driver support is still far better than Linux. With Mac, you are less likely in need of blacklist of some drivers because of freeze up issues.

Either way, I am definitely not a happy camper with the current memory management system in OS X

Your explicit purging is changing the cost of writing dirty data out from an ongoing cost to a single, longer, upfront cost. Instead of writing only when more RAM is required, you're forcing it all to happen at once.

Incidentally, the OS does try to keep an area of free RAM so that some memory can be allocated instantly, it's not only swapping things out when RAM is absolutely full. It's possible though to outrun this process if an app tries to allocate huge amounts of RAM at once though (i.e. more than is kept free for this purpose).

For your specific case, presuming apps are behaving well (see below) you would be better off quitting apps and relaunching them when you need them later. This will free up app the dirty RAM they've allocated (just like when you purge), but the 'clean' inactive RAM will not be purged (because that's not necessary - as I said, it's free to purge that kind of memory when it's needed for something else).

You also want to run Activity Monitor when your system is in it's bad state and see if it's one of the apps you're using in particular that's allocating lots of memory (check out the "Real Mem" column). The OS can't do anything if it's an app that's really allocating and writing to memory, it's obviously not able to just discard this written-to memory.

Really though, if you want to do all those things at once, more RAM might be required. Remember, with VMWare and the iOS Simulator running, you've got two whole other OSes running at the same time, it's reasonable they'd require lots of memory to work well!).

By the way, the purge command was written to simulate /worst case/ conditions when performance testing. It's designed to flush out caches so that the system has to e.g. load all an app's code from disk when launching.

[Source: I worked analysing this kind of thing at Apple until a couple of years ago].

I feel like this is a stereotype that just won't die.

Yes, up till a few years ago you might have to do some poking in /etc to get things working, but as long as you spend a few minutes looking up basic background info before you buy those problems just don't happen these days. I haven't had to edit a config file to get hardware working since 2007.

On a laptop we have here at the office I had to disable a certain driver from loading before a different driver or else the two would squabble over the wifi card and it would never show up.

The other thing that is more software related than hardware is that it is a MS Windows shop, all of the local domains are machine.domainname.local. This conflicts with MDNS as you could imagine, so the Linux machines are unable to access any of the resources on the machines named machine.domainname.local because MDNS would respond with a failure. Had to modify /etc/nsswitch.conf to fix that issue.

Linux is not without its failures. Saying it just works is certainly not the case. Whereas the Mac OS X machines I deploy come out of the box, get configured and are ready to go. Drivers work, software works, don't need to go googling for hours trying to figure out why ping won't resolve a machine.domainname.local address but dig is doing just fine.

I said if you spend a little time scoping these kinds of things out up-front, it's very easy to get a machine on which it will work without issues. Obviously if you found a machine lying around the office and tried to load an OS on it, your chances of it working well are not going to be as good. You can't just load OS X on random hardware and expect it to work either.

Sorry, from my personal experience that still isn't true, as much as I wish it were.

To make a long story short: we could exchange anecdotes all day about the state of 'Just Works' on Linux, but at the end of the day, I think no one with enough experience using various Linux distros and OS X, can honestly and sincerely say Linux is even close to OS X in that aspect.

Myself, I've been using Linux since Slackware 4 and have tried about 10 different distro's over time, alongside OS X for the last 5 years or so. Up to this day, I regularly run into problems that need fixing on Linux, particularly after upgrades, or when switching hardware. Whether it's Wifi cards, USB hardware, multi-monitor support, network configuration issues, software that stops working, system library problems: there's always something. OS X on 3 different machines, from OS X 10.4 through 10.7, I've only had one issue that required maintenance once, on a b0rked upgrade. It was pretty nasty, but fortunately OS X has Time Machine and target disk mode, so in no-time I was able to pull off any important data just to be sure, re-install the OS, restore my Time Machine backup, only to find out everything was back to normal, to the point I didn't even need the files I had to pull before the restore.

However, up to this date, it is not without issues, especially on laptop hardware. Remember that Lenovo ThinkPad T400 from a few years ago? Well, the level of stability from a popular distro, such as ubuntu, has been quite up and down. One release (like 11.04), I had trouble with it booting up and playing nice with dual graphics mode. Today, with 11.10, it is much better. How about that shiny Acer AspireOne 722 netbook? You should check the online thread. There are still discussions about how to prevent freeze up and etc. All these little quirks here and there are the reason why I would still run OS X.

I run half a menu-bar full of resident helper apps, like Dropbox (a big one), Fantastical, ScanSnap, Xmarks (another big one), Transmit (another big one), Evernote, and more. I also keep Apple Mail running, mapped to a half dozen Gmail IMAP accounts. I have "geek tool" updating my desktop with iCal appointments and various ps outputs.

I'm running a local MAMP stack and local Django stack. I run a Parallels Windows 7 VM for testing things in IE and testing from Windows in general.

Other running software is usually Safari, Terminal, Sublime Text 2, Codebox, Source Tree, Sequel Pro, Adium. I run and quit Office 2011 every time I need to edit a document. I run and quit Aperture and Photoshop.

Using this command line to see memory used by processes:

    ps -x -o rss,command | awk '{sum+=$1} END {printf "%9.3f %s\n", sum/1024, "MB" }'

Makes me wonder what you're doing to run out of memory.

Here's what I don't understand - why would anyone in their right mind purchase a $2000 laptop and then not spend the 20 minutes and 100 bucks to max out the memory on the thing? It's the easiest thing in the world to do, and basically means you never have to worry about memory usage again.

    jerf@jerfhom ~/tv $ uptime
     01:01:32 up 2 days, 23:45,  4 users, ...              
    jerf@jerfhom ~/tv $ free
                 total       used       free ...
    Mem:       3904192    3682400     221792 ...      
    -/+ buffers/cache:     740212    3163980
    Swap:      6297444      20584    6276860

This is with a respectable Linux dev loadout, but I'm not running my VMs, but that still tends not to strain my system any. $100 on RAM would just be a wasted $100.

My MBP has 8 GBs of RAM, and this is what Activity Monitor tells me:

   Free: 2.19 GB
   Wired: 1.01 GB
   Active: 3.70 GB
   Inactive: 1.08 GB
   Used: 5.80 GB

   2598.480 MB

Active is not like RSS, what Activity Monitor calls real memory is RSS.

That's not a solution, that's a workaround. I'm sitting here with a 4GB RAM machine running Arch Linux with XMonad. I usually run the following applications in day to day usage:

    - Firefox Nightly with 50-100 tabs (largest memory hog, 
      the rest doesn't even come close)
    - Thunderbird
    - Pidgin
    - XChat
    - smplayer, which I usually keep open
    - deluge
    - mpd + ncmpcpp
    - half to one dozen of terminator instances with zsh, 
      most running some text mode applications like vim, 
      htop or the aforementioned ncmpcpp

OSX is not doing anything "wrong".

I split my time between OSX/Linux and it's pretty obvious to me that Linux is vastly superior in terms of performance, in a wide-range of scenarios. I prefer to use Linux on older and/or memory-constrained systems.

So much bunk in that article.

> which is bullshit (although there's no Perl)

Last time i looked Perl could be installed via homebrew...

  $ brew install perl

  $ port install perl5

  # install perlbrew (normal user in ~/perl5)
  $ curl -kL http://install.perlbrew.pl | bash
  
  # install & switch to perl 5.14.2 via Perlbrew
  $ perlbrew install perl-5.14.2
  $ perlbrew switch perl-5.14.2
  $ perl -v   # (will show the perlbrew perl 5.14.2)

  #  Add cpanminus to perl-5.14.2
  $ curl -L http://cpanmin.us | perl - App::cpanminus

  # load Moose module into perl-5.14.2
  $ cpanm Moose

MacPorts is like FreeBSD ports and Fink is like apt-get. Brew is also dead-easy. While they're not perfect, there are some far more complicated systems in some Linux distros.

The easy'ness of a good linux-distribution is just not possibly with osx.

It is perfectly possible, as in nothing in OS X prevents it. It's just not happening/ed, because, well, not enough OS X users contribute to it, compared to the Debian/Ubuntu community.

Still, it's not that bad. I work with Ruby, Python, Node, C plus various web technologies, and use lots of unix stuff. I seldom have problems installing them with brew.

Also consider the alternative: I can install apps through the App Store or through a DMG image, that no Linux can run today (because they are native Cocoa apps). Stuff like Photoshop and Office, and Premiere, and Aperture, etc. The ease of installing industry standard proprietary apps lots of people need and a large number can't do without, is just not available in Linux.

I use a Mac laptop and would never have written this post. But I don't have to pretend that the package installation setup on OSX is remotely acceptable. It is horrible. Stuff breaks or won't install all the time. On mainstream Linux distros, stuff generally Just Works.

Also, have you seen any modern, user friendly Linux distros (e.g. Ubunutu)? You never have to dive into the command line there and yet it has nice package management that just works.

Well if you have been to any developer's conference, you'd have deduced that most developers are Apple laptop users.

It's just that they don't bitch about any package that breaks.

Some of us also use a virtual machine like Fusion for an isolated environment if we want to do development with a Linux userland, we don't pile one on top of OS X and its' BSD core, and don't expect a volunteer effort like brew with 2000+ packages all sub 20K people use to work perfectly.

(The guy in the other comments said he manages multiple Macs (a sysadmin guy) and had troubles with installing the same packages to all, etc. Presumably also different OS versions. That's a slightly different problem.)

Looking at the recent StackOverflow survey[1] (I think it's fairly representative of developers in general), we see that about 20% of the respondents used Macs, another 20% used Linux and the rest Windows, so mac users emphatically do not represent "most" developers.

[1]: https://www.surveymonkey.com/sr.aspx?sm=2RYrV_2bFw2aZ2RfedWH...

But my real point--which I realize was poorly worded--was not that no developers use macs but rather that the ones who do are not "Apple's users" in the sense calloc used.

Besides that, package management also offer an easy way to keep your system updated. On a Mac, App Store excepted, there is no central way to keep your system up-to-date - Software Update will update Apple's software (often by downloading huge packages) and you are on your own to update whatever is left. Red Hat and Debian mastered this in the early 2000's.

My Linux systems are always a headache. Last week I pulled a recommended patch from the system updater and it broke Xorg. I had to remove it by hand and reinstall it.

Breaking X is something you expect with Sid. And if you are running it, you re supposed to be able to fix it and submit a patch.

If you are breaking X, you are doing something wrong.

Tangentially that is why I moved to xubuntu from Arch, though I'm sure Arch is a bit nicer with regards to headaches now.

Fedora likes to break frequently though I don't know if packages as big as X are likely to fall through the cracks.

I think this is a great compromise, but it does mean you may have some issues with updates. That said, I have not had any issues on Fedora that weren't my doing.

I've been using Fedora for about a year. Earlier, I used OS X for about the same amount of time and I did have problems that weren't entirely my fault, largely with Java and Eclipse. Since all I was doing during that time was simple Java development for school, there just wasn't anything else that could have gone wrong.

If you want the free version of Xcode, you first need a mac. Now you need a mac with a recent OS. Ok, good, go to the web page, click on the "App Store" link. Make an account in "App Store" then hand over Your CREDIT CARD information. Great. Now it will download through the app store. Click on "Purchases" to see the status.

Microsoft doesn't need to know who I am and doesn't even care if I'm on Windows but Apple wants me on a newish mac and then hand over my credit card before I can get their IDE. Really? Ridiculous and almost intolerable.

But that's how they roll.