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.


this message is serious and it is not intended to start flame wars, religious 
crusades, or offend anyone.

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.

freebsd-current@freebsd.org mailing list
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