Date: Tue, 12 Jan 2016 12:20:02 -0500 (EST) From: Daniel Eischen <deischen@freebsd.org> To: Dan Partelly <dan_partelly@rdsor.ro> Cc: Konstantin Belousov <kostikbel@gmail.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, Hubbard Jordan <jkh@ixsystems.com> Subject: Re: relaunchd: a portable clone of launchd Message-ID: <Pine.GSO.4.64.1601121151560.6849@sea.ntplx.net> In-Reply-To: <B11FEEF6-DE75-4DAC-A0EE-52B047C3F7B7@rdsor.ro> References: <5687D3A9.5050400@NTLWorld.com> <CAGfo=8kXzNVKy9gx0jkME4iRRyrgrsfpPnW3nYrZC0gysapPcg@mail.gmail.com> <817860B6-5D67-41A3-ADD7-9757C7E67C35@gmail.com> <alpine.BSF.2.20.1601081020270.34827@nog2.angryox.com> <07D83705-D89F-4125-B57B-920EDEBC8A85@rdsor.ro> <70975696-3E07-48B9-BFD1-3C2F51E715BB@icloud.com> <E85C42D4-963B-4632-9182-E591A80D1306@rdsor.ro> <76E6AF2A-917B-41EB-883A-C27AB2BB9F71@ixsystems.com> <20160112125948.GH3625@kib.kiev.ua> <B11FEEF6-DE75-4DAC-A0EE-52B047C3F7B7@rdsor.ro>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 12 Jan 2016, Dan Partelly wrote: > Verbose is not bad , Konstantin . I actually prefer verbose source.=20 > It is easy to read and understand. It is preferable all day long to=20 > clever hacks and obfuscated ways of writing code > > Ill tell you one thing. Years ago, when Ms Leaked on their site=20 > ntoskrnl.exe symbols with private debug information , I dint had too=20 > much trouble understanding a lot of the implementation details from=20 > the kernel , exactly because MS is verbose. And that .. in WinDbg=20 > assembly. The source would have been much much more easier to read. > > Yeah, MS=E2=80=99s APIs are not the best I give you that. But regarding= =20 > *readability* , Windows is leaps and bounds ahead of any Unix I seen.=20 > It is extremely easy to figure out what a certain function does, how=20 > they use data structures, and what the members of said data structures=20 > represent. > > I like verbosity. Makes figuring things easier, makes maintenance=20 > easier. I frankly hope to spend as little of possible of my life=20 > reading terse source code. This is also why I like Ada language. Its a=20 > joy to read Ada source. Ok, speaking as a software engineer for 31 years and has been developing and maintaining Ada programs for the last 25 of those years... Ada is just a language, I've seen both bad design and good design in it, as well as in C and Java. I've seen massive over verboseness in Ada and it makes maintaining it a nightmare. When your coding guidelines have a maximum line length of 132 or greater characters, and lines _routinely_ go _well_ over 80 characters, because of package hierarchy, and package and subprogram (methods) names being very long, you know something is wrong. It depends on how you define what is a good level of verboseness, and you can have that in pretty much any language. You just need to herd cats to follow the guidelines. I echo the sentiments about CORBA. Being forced to use bloated middleware to do something simple... I have to stop thinking about it because it makes me angry ;-) --=20 DE From owner-freebsd-hackers@freebsd.org Tue Jan 12 17:48:25 2016 Return-Path: <owner-freebsd-hackers@freebsd.org> 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 9FB67A6C17A for <freebsd-hackers@mailman.ysv.freebsd.org>; Tue, 12 Jan 2016 17:48:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47EE21361 for <freebsd-hackers@freebsd.org>; Tue, 12 Jan 2016 17:48:25 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id u0CHmKno084606 (version=TLSv1 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 12 Jan 2016 19:48:20 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua u0CHmKno084606 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id u0CHmJKm084605; Tue, 12 Jan 2016 19:48:19 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 12 Jan 2016 19:48:19 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Hubbard Jordan <jkh@ixsystems.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: relaunchd: a portable clone of launchd Message-ID: <20160112174819.GL3625@kib.kiev.ua> References: <5687D3A9.5050400@NTLWorld.com> <CAGfo=8kXzNVKy9gx0jkME4iRRyrgrsfpPnW3nYrZC0gysapPcg@mail.gmail.com> <817860B6-5D67-41A3-ADD7-9757C7E67C35@gmail.com> <alpine.BSF.2.20.1601081020270.34827@nog2.angryox.com> <07D83705-D89F-4125-B57B-920EDEBC8A85@rdsor.ro> <70975696-3E07-48B9-BFD1-3C2F51E715BB@icloud.com> <E85C42D4-963B-4632-9182-E591A80D1306@rdsor.ro> <76E6AF2A-917B-41EB-883A-C27AB2BB9F71@ixsystems.com> <20160112125948.GH3625@kib.kiev.ua> <1D6BDF3C-28E7-40C4-A8A2-3A914A3CC76B@ixsystems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1D6BDF3C-28E7-40C4-A8A2-3A914A3CC76B@ixsystems.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on tom.home X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Technical Discussions relating to FreeBSD <freebsd-hackers.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers/> List-Post: <mailto:freebsd-hackers@freebsd.org> List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, <mailto:freebsd-hackers-request@freebsd.org?subject=subscribe> X-List-Received-Date: Tue, 12 Jan 2016 17:48:25 -0000 On Tue, Jan 12, 2016 at 07:59:11AM -0800, Hubbard Jordan wrote: > > > On Jan 12, 2016, at 4:59 AM, Konstantin Belousov <kostikbel@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.64.1601121151560.6849>