Date: Mon, 16 Nov 2015 19:39:12 +0200 From: Dan Partelly <dan_partelly@rdsor.ro> To: Allan Jude <allanjude@freebsd.org> Cc: freebsd-current@freebsd.org Subject: Re: libXO-ification - Why - and is it a symptom of deeper issues? Message-ID: <7644107F-8C34-431D-9367-680A609BE7F5@rdsor.ro> In-Reply-To: <564A0F71.7060700@freebsd.org> References: <0650CA79-5711-44BF-AC3F-0C5C5B6E5BD9@rdsor.ro> <564A0DD4.7030505@interlinked.me> <564A0F71.7060700@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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=20 to never hear again of anintegration, or an evaluation of that code, = and possible integration.=20 One which directly interests me: what happened to the BSD libctf code = from GSoc ? Was the resulted code evaluated ? If=20 it falls short, where it does ? Can it be salvaged ?=20 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=20 =20 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=20 initiated and sponsored object.=20 > On 16 Nov 2015, at 19:16, Allan Jude <allanjude@freebsd.org> wrote: >=20 > On 2015-11-16 12:09, Elizabeth Myers wrote: >> On 15/11/15 06:54, Dan Partelly wrote: >>> Hi all, >>>=20 >>> 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 answer. Ill outline what I think: >>>=20 >>>=20 >>> 1. Undoubtedly, it makes base code slightly harder to understand and = maintain.=20 >>> 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=E2=80= =9D 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.=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, 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. >>>=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 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. >>>=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 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.=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 = 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 ? >>> =46rom 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=20 >>> 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.=20 >>>=20 >>> Note: >>>=20 >>> this message is serious and it is not intended to start flame wars, = religious 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 = the >> 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 >=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. >=20 > 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. >=20 > 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. >=20 >> -- >> Regards, >> Elizabeth Myers >>=20 >>=20 >> _______________________________________________ >> freebsd-current@freebsd.org <mailto:freebsd-current@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@freebsd.org = <mailto:freebsd-current-unsubscribe@freebsd.org>" >>=20 >=20 >=20 > --=20 > Allan Jude
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7644107F-8C34-431D-9367-680A609BE7F5>