On Tue, Nov 17, 2015 at 10:04 AM, Julian Elischer <jul...@freebsd.org>

> On 11/15/15 8:54 PM, 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.
> Amen.
> I have stated before that I believe this is a mistake... actually, no, not
> "mistake" actually.. let's say "suboptimal and aesthetically dipleasing".
> It has every hallmark of "the wrong answer" in my gut feeling.
> I believe it is being pushed by Juniper to make it easier to make
> appliances, but I'm not sure I remember correctly.
> I remember that there was a set of slides somewhere that give the
> justifications and thinking behind it.
> But  quick look failed to find it.. As a 'currently mostly inactive (kids
> + $JOB ) I feel iti sn't my place to argue against it too much if currently
> active deveelopers want it, but it doesn't ring quite right to me..  The
> ifconfig issue is a separate issue, but yes that could be a good library to
> have.
> Personally I would have liked it if in '91 we had followed one very
> serious suggestion,
> and implemented every user command as  a base 'library', and a tcl wrapper
> script that gave the external behaviour. then every command could have been
> made extensible to output various formats etc. by having an alternate tcl
> script  to run in that case.
> I for one find this really really promising. I think it will really
simplify adopting https://github.com/clicon/clicon to make a slick cli.

UCL also has it's place in that vision. If the daemons should read from
config files or query a "database" is a good question, where I see pros and
cons for both approaches.

Best regards

>   _______________________________________________
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
>> "
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to