Inactive memory is not an OS X specific, and it's actually implemented in a number of other OSes, including FreeBSD.
> when it's on disk, it definitely is not made active quickly.
If an application is unloaded then many operations need to be taken to initialize stuff, reading the disk for various stuff, processing some data, allocating memory (which will be zeored out, then initialized with whatever struct and data the program needs)
If an application memory is swapped, then reactivating that memory consists of:
1. paging memory back in RAM
2. there is no step two
Paging is key, as it means the data is in a format efficiently readable and that can be put back in memory at a very reduced cost. Compare this to reading random files entrenched in a filesystem and scattered on a disk, plus doing some more processing.
> First usually freed around 200MB of memory
Out of 4GB. Wow, what an incredible improvement! Pardon me while I go write a cron entry running that command every minute so that my system can stay in good shape!
> When arriving to work the first thing was to hit repair disk permissions
This is absolutely astonishing. Seriously, Repair Permissions is a glorified ch{mod,own} -R. Quiz time! Why do you thing it reduces the 'Inactive Memory'? Because it's hitting the disk. Hard. Actually every system file gets hit. And in doing so, those files make their way into the cache and the Inactive Memory gets properly evicted. So the supposedly non-functional memory management turns out to be perfectly functional after all.
> And of course this does not support installing Python, Ruby, Perl on any other software that has its own way of distributing software.
which is bullshit (although there's no Perl).
$ brew install python
even gives you a
distribute's
easy_install out of the box. You can install Ruby the same way (and since it's 1.9 it includes
rubygems) but I'd recommend using rbenv+ruby-build, which is also in the package list.
Apparently the author wants python/ruby/perl packages provided by the package manager, which might just be a bad idea given how bad the status of those packages is in Debian. One would be much better served with pip+virtualenv and rbenv/rvm+bundler.
There's a brew-pip if you really want to integrate
> And in case you mix up MacPorts and homebrew, you're deeply screwed.
How so? they live in completely different directory trees. As long as you don't screw up your PATHs or something they're oblivious to each other. I've had them living side by side for some time before dropping MacPorts without any issues.
> working command line tools
$ brew install coreutils
But I'd hardly describe BSD utils as non-working (hint: I did not install coreutils yet I spend my days on the command line).
As for compile time, it's hardly a problem as Homebrew mitigates that (contrary to MacPorts) by not duplicating every library already available in the OS. Besides, the system (much like ABS on ArchLinux) is made to make you writing your own packages or tweaking an existing one a straightforward affair. Compare to creating a .deb properly, which is, ahem, non-trivial. Yes, it would be faster not building stuff (like Arch which brings the best of both worlds together) but hosting binary packages has a cost that skyrockets as you have more users (plus one would need to make binary builds for the various OSX versions, a problem that simply doesn't exist). What's more, having software compiled from the 'original' source instead of third party is interesting in a number of ways, including running vanilla software instead of the heavily patched ones of Debian.
I'm glad the author has found a place for him but going on such an uninformed rant is unfair.