Re: libXO-ification - Why - and is it a symptom of deeper issues?

> 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 though


Then surely you will salvage something from a lot of GsoCs where people wrote code with various degrees of success, only 
to never hear again of anintegration, or an  evaluation of that code, and possible integration. 

One which directly interests me: what happened to the BSD libctf  code from GSoc ? Was the resulted code evaluated ? If 
it falls short, where it does ? Can it be salvaged ? 

Libxo might be a fine facility to have for some corner cases, but it doesnt solve the problem of binary code reuse in general. Might have solved it fast for Juniper.  It is yet another stick into a scaffolding of shell scripts which should have been replaced years ago with proper libraries, services and IPC, opening the road towards modern service management, service frameworks , fault management , fault response and transactional OS databases 
  
I continue to believe this is or will become shortly an issue of utmost importance , one which is worthy of the status of a FreeBSD 
initiated and sponsored object. 





> On 16 Nov 2015, at 19:16, Allan Jude <allanjude_at_freebsd.org> wrote:
> 
> 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 “ Ok, this is funny , but why ? “ And I couldn't find a real answer. Ill outline what I think:
>>> 
>>> 
>>> 1. Undoubtedly, it makes base code slightly harder to understand and maintain. 
>>> 2. I have seen the idea that this makes the information dumped by utilities in the base easily accessible programatically. OK, maybe it does , but
>>> it doesn't fit with the current paradigm of "tool | filter | tool” at all. There are no tools able to accept JSON and filter it in any meaningful 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 possibility in a world where too much choices already result in too much splits and incompatible APIs. 
>>> 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, much 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 solaris does.
>>> 
>>> 5. A port of partial OS config data to UCL …. would induce yet induce another orthogonality violation. What makes UCL better than the bestiary of ad hoc databases already existing in BSDs ? Programatic readability, 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 , transactional, 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 to 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 point, 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 errors which bite as all from time to time.
>>> 
>>> 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 insight offered by Windows :P) , then inventing more adhoc solutions and ad-hoc databases, which do not address the real issues we have , like binary code reuse, service management issues,  lack of a system wide published -subscriber bus ( not kdbus :P ) fault detection and reaction, fault reporting, all much needed parts of a modern OS. 
>>> 
>>> And now thee questions
>>> 
>>> 1. Why lib XO ? Why burden the OS for some corner cases where it may be useful ?
>>> 
>>> 2. Was there any real talk on how to bring FreeBSD up to speed regarding those issues ?  A period of research on what exists, on what can be done , 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 years , but it would be well worth it, and in my opinion it would be also worthy of 
>>> the freeSBD foundation sponsorship for several years in a row. The features I touched upon became very important parts of oder OSes, and rightly so. 
>>> 
>>> Note:
>>> 
>>> this message is serious and it is not intended to start flame wars, religious crusades, or offend anyone. 
>>> 
>>> _______________________________________________
>>> freebsd-current_at_freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>> 
>> It seems to boil down to the golden rule: he who has the gold, makes the
>> rules. Juniper wanted it, they're a non-trivial donor to the FreeBSD
>> foundation and employ many devs, so they got their way.
>> 
>> That's all there is to it.
>> 
> 
> 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 though.
> 
>> --
>> Regards,
>> Elizabeth Myers
>> 
>> 
>> _______________________________________________
>> freebsd-current_at_freebsd.org <mailto:freebsd-current_at_freebsd.org> mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current <https://lists.freebsd.org/mailman/listinfo/freebsd-current>
>> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org <mailto:freebsd-current-unsubscribe_at_freebsd.org>"
>> 
> 
> 
> -- 
> Allan Jude