Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I am currently using a cluster of Mac Minis as a server platform. Some benefits:

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



Most modern Linux distros use systemd now, which is a pretty good unified platform for starting services.

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?


I don't have extensive experience with Launchd, but what makes it better?

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.


Upstart, Systemd, and SMF have many of these features now, but here's what launchd brings to the table:

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.


Everything. It is all in one place, very simple to use, has process monitoring like Monit and well supported.

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.


>Homebrew or MacPorts and I have exactly the same setup as I have on my Linux server.

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.


MacPorts, at least, is starting to provide pre-built binary packages now.


Homebrew has some pre-built binaries too. From the FAQ: "Homebrew does provide pre-compiled versions for some formula that take a long time to compile (such as Qt which can take many hours to build). These pre-compiled versions are referred to as bottles and are available at: http://sf.net/projects/machomebrew/files.


1. Name your package manager, and I can list the missing packages, or missing flags which have made my life a pain at some point in my career. 2. Yup, and the only way, should you need to set any flags. 3. True. Which is why it's nice that you can mount dmg's and install pkg's via the command line.



Yea, I like Archlinux a lot; it's been my favourite linux distro for a while now.


> 2. Yup, and the only way, should you need to set any flags.

Man, if I subscribed to that belief, I might as well just use Gentoo!


what has caused you pain with APT?


> It is all in one place, very simple to use

Especially for socket/mach service activation. This feature is integral to both iOS and OS X, and is dead simple to configure.


How is remote management for these systems? I'm a big Mac fan, but for server infrastructure I've often wondered if Software Update and related things could be more trouble than it's worth.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: