relaunchd: a portable clone of launchd

[Konstantin Belousov]

On Tue, Jan 12, 2016 at 07:59:11AM -0800, Hubbard Jordan wrote:
> 
> > On Jan 12, 2016, at 4:59 AM, Konstantin Belousov <kostikbel at gmail.com> wrote:
> > 
> > I highly recommend to Google for "Mach IPC sucks" if reader is really interested.
> 
> And here we return to the usual trap???
> 
> ???Mach IPC sucks!???
> 
> ???OK.  What do you propose that will address all of the same concerns????
> 
> ???dbus!???
I did not said this.

> 
> ???*Sigh*.  You haven???t even looked at the two technologies in any depth, have you?  Go read the dbus wikipedia page, at least!  Unix domain sockets underneath, no kernel<->userland communication path, no trusted IPC mechanism, no support for large messages??????

Is this directed at me, or just presents an imaginary dialog  between you
and some third party ?

> 
> ???OK, so something new!!  We should totally create an IPC for the New Millennium!???
> 
> ???That would be you then?  Where???s your white paper?  Where???s your reference implementation????
> 
> <crickets>
> 
> Sorry.  Been there, had this debate, and while it???s always extremely easy to fling poop at an existing mechanism, it turns out it???s so much harder to actually *create an alternative* that this kind of discussion only serves to throw cold water on evolution (???the perfect being the enemy of the good enough???) and the end-result is that evolution does not occur.
> 
> I also already covered how it???s very easy to layer something like XPC *on top* of Mach IPC such that you, the programmer, need never be exposed to the Mach IPC APIs (but still get to leverage the internal capabilities I???ve already covered).
> 
> Sorry, Konstantin, but yours is a non-argument.

What is a non-argument in my previous message ?  I made two points:
1. story of Mach IPC being convenient or nice is not quite right
   (as most other stories of the great older tech which did not survived).
2. most people do not care anyway, and already use less ambitious
   but more practical alternatives.

I did not suggested any substitution for Mach IPC, and I do not see much
point on spending energy on discussing its alternatives or even trying
to design new uber-IPC solution, mostly due to item 2.

Item 1 is what caused my reaction to your text.