edit: I guess lumped into this is the small market that seems to exist for colocated Mac Minis. Is there something about them that is better than renting commodity x64 hardware?
Yes, if you make software that runs on OS X (or iOS and you want to test on iOS Simulators) you need OS X machines for your build and test process. You need lots of machines so you and your fellow developers can run speed things up and run tests in parallel.
* Launchd is a massive improvement over the equivalent mess on Linux. This can't be understated if you are managing your own hardware. * You can develop on the same machine you are deploying to. * You have exactly the same toolchain as on Linux. * Lots of remote monitoring options that are unique to OSX e.g. OSX Server * The OS is stable and upgrades are safe enough to enable auto update. I could never do that on CentOS.
But really it comes down to hardware and resale value for me. 2 Mac Minis in 1RU is great value.
OS X doesn't have the same toolchain as Linux - notably, Apple doesn't ship anything licensed under GPLv3. This leads to OS X versions of common GNU tools being extremely outdated.
I do agree with the point about developing and deploying in the same environment. I do both in Linux for that exact reason; far fewer surprises when your deploy environment matches what you've already debugged.
Nobody uses what Apple ships by default. Homebrew or MacPorts and I have exactly the same setup as I have on my Linux server. Plus lots of amazing GUI wrappers which can simplify setup and ongoing maintenance.
My biggest problems with the above:
1. Neither Homebrew nor MacPorts (nor fink, for that matter) has a complete set of relevant packages
2. Compilation from source is ridiculously slow.
3. Certain utilities are best installed from .dmg files instead, and it's a pain to remember which was installed which way.
Man, if I subscribed to that belief, I might as well just use Gentoo!
Especially for socket/mach service activation. This feature is integral to both iOS and OS X, and is dead simple to configure.
1) It unifies several independent systems that shared a similar purpose:
- init
- crond
- atd
- inetd
- xinetd
2) It includes user-based daemon management.
- More structured than doing it in your shell's RC file.
3) Instead of writing a shell script, you set a series of properties in a plist (XML-based).
- It's parseable.
- Daemons can be interacted with programmatically using built-in tools like defaults, PlistBuddy, and launchctl.
4) It handles a lot of special dependencies:
- Network availability
- Disk or server availability
- Filesystem availability
- User Logins
- Kernel Extensions
5) It has built-in, live, event-based triggers with almost no overhead. It can watch for:
- Changes to a file or folder
- An item to appear in an empty directory (for queueing)
- A file system to mount
- A Mach message
- A connection to a stream socket
- Traffic to a datagram port
6) It manages respawn behavior. For example:
- Run when loaded and never quit.
- Run purely on demand
- Run once when loaded an on demand thereafter
- Run on demand based on a clean exit
7) Its strict conventions prevent processes from being disassociated from their parents.
- Easier to trace who did what (nice for security and troubleshooting)
- Easier for the OS to garbage collect.
- Centralizes a lot of daemon management
8) It has a defined separation of "execution contexts" based on:
- If it does something for the currently logged-in user or all users.
- If it will be used by one app or by multiple apps.
- If it needs to display a user interface or launch a GUI app.
For more info, checkout: http://developer.apple.com/technotes/tn2005/tn2083.html
EDIT: Formatting.
I don't quite understand the other points; you can certainly develop on Linux and there are lots of mature monitoring options.
The trick with auto-updates is, you're getting everything from the package manager. This forces you to keep everything up to date, not just some notion of the 'core system', which is what you're getting from Mac update. Of course, you have to have some discipline and stage major updates in a testing area before you actually update production servers, but I think you'll find key packages like OpenSSL should probably be kept up-to-date.
Personally, I maintain a system which consists of about 30 CentOS servers; not large by any means. But things like upgrades and monitoring are a non-issue; we test updates before we apply them, and we use Nagios for monitoring.
As someone downthread pointed out, you can get a SuperMicro 1U server with a hell of a lot more horsepower than a Mac Mini for an equivalent price; the motivation for Mac servers seems to be almost exclusively to test and build Mac-specific software. I'd be curious to know what your specific application is that motivates this?