relaunchd: a portable clone of launchd

[Hubbard Jordan]

> On Jan 12, 2016, at 7:08 PM, Mark Heily <mark at heily.com> wrote:
> 
> I've gone ahead and created a general-purpose IPC library that is a
> plausible alternative to Mach IPC. Here's the code:
> 
>   https://github.com/mheily/libipc

Kudos for creating something for review, at least.  It beats the usual discussion-without-code and I won’t argue with the notion of creating something new, though I would like to push back on at least a few of the points you make about Mach IPC because they’re important in understanding the full picture.

>> Separate namespace for services (doesn't rely on file system naming or
>> permissions)
> 
> This is generally a bad thing, IMHO. Filesystem permissions are a
> good way to apply security rules to an object, and they are a highly
> standard and well understood concept.

I think this is pretty subjective.  Speaking as someone who has used a services namespace for a long time, I would argue the exact opposite with probably equal amounts of conviction and justification.  I come down firmly on the side of the argument that says it's a good thing and Filesystem permissions are a terrible way of applying security rules to an object, particularly as they only provide very limited semantics.  All of the ACLs in the world won’t help you to create an extensible security trailer that identifies multiple clients of a single server in a unique way (pid/uid/gid is practically useless for this).  However, I can’t force you to walk in the shoes of an OS X internals developer (or even offer you that opportunity) so we’re back to subjective and dueling opinions on this again.

> Using the filesystem as a way to coordinate activity is a perfectly
> natural thing to do, and only has a disadvantage in a small corner case
> (where the system is in the process of booting up and the filesystem
> is not mounted).

That’s actually not a corner case on the software appliances we’ve been creating lately.  That’s the usual case. :)   You start out with a bootstrap MFS and then selectively mount ZFS datasets and such on top of various locations that would like to have more storage (like /var/tmp or /var/db).  This makes locating your Unix domain sockets a bit tricky.  Again, this is not just hypothetical - we’ve run into multiple problems where we wound up covering up our own mongodb / syslog sockets and hilarity ensued until we realized the problem and sorted it out. 

Again, I clearly can’t convince you otherwise, but a service discovery mechanism built-in to the kernel is awesome and to say “you don’t need it” is a bit like someone telling you that you don’t need to make whatever amount of money you’re making but should be happy working as a night clerk at 7-11.  Who is anyone to make that kind of assertion without background? :)

> Not true. You have to provide your own semantics for finding
> the message boundaries, but it is totally possible to send messages
> across Unix-domain sockets.

Of course you can send messages over Unix-domain sockets.  You can send messages using a morse-code key and a Marconi spark-gap transmitter, for that matter, but that doesn’t mean you don’t want something else to take care of that for you.  Mach IPC does, and that’s all I meant on that slide.

>> Kernel as peer
>> 
> 
> This is true, but not there are other ways for userspace to communicate
> with the kernel, such as syscalls and ioctl.

Yes, and they all suck and/or are implemented completely ad-hoc on a case-by-case basis (the routing socket comes to mind) rather than having an architecture make them conform to some common design patterns, both for existing and for new mechanisms.  I dunno, but it sure seems to me like you’re going to such lengths to hate on Mach IPC that you’re willing to essentially argue against architecture, clean abstraction boundaries, and pretty much anything anyone finds valuable in order to hold such a strong position.   It’s sort of reminiscent of various arguments I’ve had with assembly bigots that high level languages are just a waste of time and CPU cycles and there’s absolutely nothing worth doing that can’t be done in assembly.  I mean sure, they’re not out-and-out WRONG, but the entire argument seems silly in the extreme.

- Jordan