Date: Mon, 16 Nov 2015 12:16:33 -0500 From: Allan Jude <allanjude@freebsd.org> To: freebsd-current@freebsd.org Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? Message-ID: <564A0F71.7060700@freebsd.org> In-Reply-To: <564A0DD4.7030505@interlinked.me> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <564A0DD4.7030505@interlinked.me>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --N9tRqgCf96cJra1M5duEPwiT6cDo2pxgb Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2015-11-16 12:09, Elizabeth Myers wrote: > On 15/11/15 06:54, Dan Partelly wrote: >> Hi all, >> >> I was looking at the new facility of dumping JSON,XML from many utils = in 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: >> >> >> 1. Undoubtedly, it makes base code slightly harder to understand and m= aintain.=20 >> 2. I have seen the idea that this makes the information dumped by util= ities in the base easily accessible programatically. OK, maybe it does , = but >> 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= =2E 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= =2E It is only an expression of the need of a mechanism aimed at binary c= ode reuse. But it does not solve the problem, it only adds yet another po= ssibility in a world where too much choices already result in too much sp= lits and incompatible APIs.=20 >> 4. This whole effort would have been IMO much better served by portin= g the bulk of ifconfig(8) , route(8) and wpaclient(8) to a library API, m= uch like the libs for geom, zfs , etc , ready for reuse of 3rd party code= =2E Eventually writing network control daemons in time over it , much lik= e solaris does. >> >> 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 b= estiary of ad hoc databases already existing in BSDs ? Programatic readab= ility, yes. but it does not add any real much needed functionality such a= s *transactional databases* for system tools. Why not research a proper= solution - easily accessible by other programs ,orthogonal , transaction= al, and ACL protected solution which can be used all over the place , = from OS boot, to ABI management, service management, network management, = user management. I hope this day will come, a day when I will not have t= o edit a single config file manually, yet I would have access to all the = config and system state easy with wrapper APIs. In the light of this poi= nt, why go with UCL ? It is not orthogonal, it is not transnational, and = editing the config files directly would result in the same old human erro= rs which bite as all from time to time. >> >> 5. It is my opinion that Solaris addressed some of those issue. Solari= s FMRI and SMF are lightyears ahead of the very tired models we keep usin= g on BSDs. Why not build on the insight offered by those (or even on the = insight offered by Windows :P) , then inventing more adhoc solutions and = ad-hoc databases, which do not address the real issues we have , like bin= ary code reuse, service management issues, lack of a system wide publish= ed -subscriber bus ( not kdbus :P ) fault detection and reaction, fault r= eporting, all much needed parts of a modern OS.=20 >> >> And now thee questions >> >> 1. Why lib XO ? Why burden the OS for some corner cases where it may b= e useful ? >> >> 2. Was there any real talk on how to bring FreeBSD up to speed regardi= ng those issues ? A period of research on what exists, on what can be do= ne , and ensure important things are not showed in background and replace= d with yet another ad-hoc config database which lacks modern features ? >> From where I am standing, this could be a project spawning multiple ye= ars , but it would be well worth it, and in my opinion it would be also w= orthy of=20 >> the freeSBD foundation sponsorship for several years in a row. The fea= tures I touched upon became very important parts of oder OSes, and rightl= y so.=20 >> >> Note: >> >> this message is serious and it is not intended to start flame wars, re= ligious 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.= org" >=20 > It seems to boil down to the golden rule: he who has the gold, makes th= e > rules. Juniper wanted it, they're a non-trivial donor to the FreeBSD > foundation and employ many devs, so they got their way. >=20 > That's all there is to it. >=20 As Simon pointed out, many more people than Juniper wanted it. Juniper had a less generalized version of this in their own tree, and would have happily kept it to them selves, but they went to the extra effort of generalizing it and cleaning it up to commit it to base, because at a FreeBSD Vendor Summit, a number of other companies wished for the same functionality. Even my small 3 person company greatly desires this functionality, and this is why I have been helping to convert additional utilities to use libxo. How big of a donor you are to the FreeBSD Foundation does not affect the committable of your code. Having code ready to commit, vs just a vague plan, does help your solution win out over another proposed solution thou= gh. > -- > Regards, > Elizabeth Myers >=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 --N9tRqgCf96cJra1M5duEPwiT6cDo2pxgb 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) iQIcBAEBAgAGBQJWSg9xAAoJEBmVNT4SmAt+NMYQAOHihxbSOB2AsEv7OCynVijn XyEzQcIwWDKYgzdMAusGJuEpyQouqzNZgfHFVfCidJw4YcP+7kna99hB8UQAyJEx nRh217YtmxOKA3XCEuBV79co7uXs+MKgz5lol6veiVcVPKkYN3Kvtl2xkIQb9Vvm OUz8OQ22mTDASocxBjZFFcTGpJ9hD1COlZejbrPUVk3bjrsiksUkmwOWoC7/uot3 /9nioHT5gEt/uIgcmTtfj2WcPHD6kraWI9MxsMMgQlKBoYo0OtTeRs+bC7tMJRES GhKtaPsoYDVNJfz0HpM+HWVbCnsgcalzwvl5j5TALd1D+1xRuBvVrjiKldIP0WA6 qaq7fD2IAvzRIe+WAPtJctgTXC6j6i0B2OarQiE6jh56KPqaCWqNI8wprv1e/YC5 p31CrgM+QSV665h/x3gAX0Cqi+gHAZhQq5XWfJe4WxtHJNYVHuOXqHWTdwb6F7fi An3u/e81+A0WwuikhEE22lvxsZoUkVRAy25fy/tEuD0jcF+MEBz/9Mn8+r2d0iTl tCjQ3Q+RHizZ+ybTI3QetAZ4wR7y6tSY5aghqa/ciNoPYRj8Vm779ri60zFuSU2p jtKQ4dLFV+//BZu/oFprfm8bd6kIlWJICuOn18gFCZa5YWztV3XDIcDR3dNvoWPi Ms6qjwCrnjOwK1RzTB6I =YYP4 -----END PGP SIGNATURE----- --N9tRqgCf96cJra1M5duEPwiT6cDo2pxgb--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?564A0F71.7060700>