From owner-freebsd-current@freebsd.org Sun Nov 15 18:05:26 2015 Return-Path: Delivered-To: freebsd-current@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 45AF1A2F4E3 for ; Sun, 15 Nov 2015 18:05:26 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) by mx1.freebsd.org (Postfix) with ESMTP id 247651237 for ; Sun, 15 Nov 2015 18:05:25 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 7D288DBEA for ; Sun, 15 Nov 2015 18:05:25 +0000 (UTC) Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? To: freebsd-current@freebsd.org References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> From: Allan Jude Message-ID: <5648C964.2020405@freebsd.org> Date: Sun, 15 Nov 2015 13:05:24 -0500 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="tquaVwxoVS1qpQhDmhIFx023vRw0xvgrm" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 18:05:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --tquaVwxoVS1qpQhDmhIFx023vRw0xvgrm Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2015-11-15 07:54, Dan Partelly wrote: >=20 > Hi all, >=20 > I was looking at the new facility of dumping JSON,XML from many utils i= n base and after some funny minutes, I couldn't stop ask myself =E2=80=9C= Ok, this is funny , but why ? =E2=80=9C And I couldn't find a real answe= r. Ill outline what I think: >=20 >=20 > 1. Undoubtedly, it makes base code slightly harder to understand and ma= intain.=20 I am not sure that libxo actually makes the code any harder to understand and maintain. It might actually make it slightly better. replacing: printf("%s %s %d\n", foo, bar, number); with: xo_emit("{:foo/%s} {:bar/%s} {:number/%d}", foo, bar, number); it not really hurting much. > 2. I have seen the idea that this makes the information dumped by utili= ties in the base easily accessible programatically. OK, maybe it does , b= ut > it doesn't fit with the current paradigm of "tool | filter | tool=E2=80= =9D at all. There are no tools able to accept JSON and filter it in any m= eaningful way, and I > dont see too many ppl changing their code to read JSON instead of text.= I don't even see the base tools changing. This output may be useful in = corner cases only. > 3. The integration of libxo IMO only points at a much deeper issue IMO.= It is only an expression of the need of a mechanism aimed at binary code= reuse. But it does not solve the problem, it only adds yet another possi= bility in a world where too much choices already result in too much split= s and incompatible APIs.=20 > 4. This whole effort would have been IMO much better served by porting= the bulk of ifconfig(8) , route(8) and wpaclient(8) to a library API, mu= ch like the libs for geom, zfs , etc , ready for reuse of 3rd party code.= Eventually writing network control daemons in time over it , much like s= olaris does. >=20 > 5. A port of partial OS config data to UCL =E2=80=A6. would induce yet = induce another orthogonality violation. What makes UCL better than the be= stiary of ad hoc databases already existing in BSDs ? Programatic readabi= lity, yes. but it does not add any real much needed functionality such as= *transactional databases* for system tools. Why not research a proper = solution - easily accessible by other programs ,orthogonal , transactiona= l, and ACL protected solution which can be used all over the place , f= rom OS boot, to ABI management, service management, network management, u= ser management. I hope this day will come, a day when I will not have to= edit a single config file manually, yet I would have access to all the c= onfig and system state easy with wrapper APIs. In the light of this poin= t, why go with UCL ? It is not orthogonal, it is not transnational, and e= diting the config files directly would result in the same old human error= s which bite as all from time to time. >=20 > 5. It is my opinion that Solaris addressed some of those issue. Solaris= FMRI and SMF are lightyears ahead of the very tired models we keep using= on BSDs. Why not build on the insight offered by those (or even on the i= nsight offered by Windows :P) , then inventing more adhoc solutions and a= d-hoc databases, which do not address the real issues we have , like bina= ry code reuse, service management issues, lack of a system wide publishe= d -subscriber bus ( not kdbus :P ) fault detection and reaction, fault re= porting, all much needed parts of a modern OS.=20 >=20 > And now thee questions >=20 > 1. Why lib XO ? Why burden the OS for some corner cases where it may be= useful ? >=20 > 2. Was there any real talk on how to bring FreeBSD up to speed regardin= g those issues ? A period of research on what exists, on what can be don= e , and ensure important things are not showed in background and replaced= with yet another ad-hoc config database which lacks modern features ? > From where I am standing, this could be a project spawning multiple yea= rs , but it would be well worth it, and in my opinion it would be also wo= rthy of=20 > the freeSBD foundation sponsorship for several years in a row. The feat= ures I touched upon became very important parts of oder OSes, and rightly= so.=20 >=20 > Note: >=20 > this message is serious and it is not intended to start flame wars, rel= igious crusades, or offend anyone.=20 > =20 > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg" >=20 --=20 Allan Jude --tquaVwxoVS1qpQhDmhIFx023vRw0xvgrm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJWSMlkAAoJEBmVNT4SmAt+OI8QAJAiDDNMt/ww9ggGcTL6zVhh 2ABJrP+pNwBmnFjjShn5tn86L4pmk6l2xCo+cxUaApP6YlNnJcsrRigfLE6B+B/V rrZP+wFzYpdTFVoNRP8a07+MhhczVrIXc5tj6HsZTP2WvsYYdqNzEATJxBQNjmBn J3PNGrNTNpejIdcY2Ox5XqnzkXQ/bXCC4M6ZELPZ3uuyOVXHXBl+4lNZ2nCDG+kW YI9YJ5tDgYaveCH8A+rm9M3VZnH+5YGE10N7486ljiSbWU8HgJuaFN/lSSM7V9Hu 04WGQjuO+gME4us1J8P3Zv8bHt0BWDhqgK5DBmS4/ITY6BoKl8KtREWGhrfEev1O hQ4/f2rB5C3/wfbmLcRgD0xeUaU/IYsgjIi/TqRG4kdYoCn+RkCm71CZLLhBt8IM GV0CwsPB5hAN6IHBbiT7T9iRgIuILFqSLrnR8/Cnao3dlT7mpXKECqYByub46kGT hv6LT40Mik8BGuSZoXcFeU45uu8QV7p+UgN6iz9AhOazafYZTnzsD2b0GlC/rSPm guAZtjppzUIJr2hVGebaQi5IWhvuRgrV8MhyW5Ut5UFt3A8UHJAUt3VDUpeQfZKk KXvB5wLxbqNrcVWuF7UOTw0BGmpxoejP5O6jKyosrKpjVr4QcwtSLm3uaTmqsrPh /ig7kXLyZVSY6WdPaxJV =wv11 -----END PGP SIGNATURE----- --tquaVwxoVS1qpQhDmhIFx023vRw0xvgrm--