From owner-freebsd-hackers@freebsd.org Tue Jan 12 18:11:02 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7CC96A6CDF3 for ; Tue, 12 Jan 2016 18:11:02 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from mail.rdsor.ro (mail.rdsor.ro [193.231.238.10]) by mx1.freebsd.org (Postfix) with ESMTP id 17335173E for ; Tue, 12 Jan 2016 18:11:01 +0000 (UTC) (envelope-from dan_partelly@rdsor.ro) Received: from email.rdsor.ro (ftp.rdsor.ro [193.231.238.4]) by mail.rdsor.ro (Postfix) with ESMTP id ADE14120FD; Tue, 12 Jan 2016 20:11:00 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Date: Tue, 12 Jan 2016 20:11:14 +0200 From: dan_partelly To: Konstantin Belousov Cc: Hubbard Jordan , FreeBSD Hackers Subject: Re: relaunchd: a portable clone of launchd In-Reply-To: <20160112174819.GL3625@kib.kiev.ua> References: <5687D3A9.5050400@NTLWorld.com> <817860B6-5D67-41A3-ADD7-9757C7E67C35@gmail.com> <07D83705-D89F-4125-B57B-920EDEBC8A85@rdsor.ro> <70975696-3E07-48B9-BFD1-3C2F51E715BB@icloud.com> <76E6AF2A-917B-41EB-883A-C27AB2BB9F71@ixsystems.com> <20160112125948.GH3625@kib.kiev.ua> <1D6BDF3C-28E7-40C4-A8A2-3A914A3CC76B@ixsystems.com> <20160112174819.GL3625@kib.kiev.ua> Message-ID: X-Sender: dan_partelly@rdsor.ro User-Agent: RoundCube Webmail/0.4-beta X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2016 18:11:02 -0000 On Tue, 12 Jan 2016 19:48:19 +0200, Konstantin Belousov wrote: > On Tue, Jan 12, 2016 at 07:59:11AM -0800, Hubbard Jordan wrote: >> >> > On Jan 12, 2016, at 4:59 AM, Konstantin Belousov >> > 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. On Tue, 12 Jan 2016 19:48:19 +0200, Konstantin Belousov wrote: >>2. most people do not care anyway, and already use less ambitious >> but more practical alternatives. Oh, ppl do care. Perhaps someone which enjoys building Rupe Goldberg contraptions from shell scripts will not care, but the rest will do. Why else do you think kd-bus exists, and that those developers continue to poor significant effort into it, even full redesigns , after the failed attempts to integrate it in the kernel ? >> story of Mach IPC being convenient or nice is not quite right but you cannot deny that it so far it did the job well for Apple so far. Even if Apple will roll a new IPC in the next years, so far Mach ports where useful for them. So it is not like NextBSD guys just pulled something unused from 80s from naphthalene. > >> >> ???*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???? >> >> >> >> 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. > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"