> On Jun 13, 2015, at 12:25 PM, Marcel Moolenaar <mar...@xcllnt.net> wrote: > > >> On Jun 13, 2015, at 11:47 AM, Ian Lepore <i...@freebsd.org> wrote: >> >> On Sat, 2015-06-13 at 11:38 -0400, David Chisnall wrote: >>> On 13 Jun 2015, at 11:17, Ian Lepore <i...@freebsd.org> wrote: >>>> >>>> If you would have told me a year ago that you had a simple scheme that >>>> could make 30 years of experience maintaining code for unix-like systems >>>> completely worthless I would have been skeptical, but it seems we're >>>> well on our way. >>> >>> There is a lot of heckling and unhelpful hyperbole in this thread. Reading >>> the xo_emit format strings takes a little bit of getting used to, but the >>> same is true of printf - it’s just that we’re already used to printf. The >>> structured parts (xo_open_container, xo_close_container and friends) are >>> clear and descriptive. The changes are fairly invasive, but the benefits >>> are also very large for anyone who is wanting to automate administration of >>> FreeBSD systems. >>> >>> If you have suggestions for how the libxo APIs could be improved, then >>> please let us know - Phil is very reception to suggestions but objections >>> along the lines of ‘it’s not what I’m used to and changes sometimes break >>> things so we should never have changes’ are not helpful. >>> >> >> "This is a piece of crap that needs to be excised from the system and >> done a different way" is useful input whether you agree with it or not. > > Actually: no. > > Not only does one not demonstrate an understanding of the problem > by calling it “crap” and thus leaving the recipient to wonder whether > it’s worth his or her time to even respond; the sentence also lack a > concrete suggestion and, last but not least, is utter after this was > all discussed on arch@, making it very much one of “too little, too > late”. > > So, not useful at all.
My complaints have been specific: libxo conversion broke things, but didn’t fix them before going on to convert more things (which broke more things). This suggests a lack of competent testing as a standard operating procedure and pointing it out is helpful. And specifically about ls: it was already way overloaded. Overloading it further seemed to be unwise: a new program would have been better since it is a thin interface to fts(3). I didn’t recall seeing a specific discussion about ls, but the original thread in arch grew to be quite large and maybe I missed something. While I dislike libxo in general, I do understand why it is being done. I see the use in general, and the benefits. I have nothing better to offer. I object to the execution in small aspects. Warner
signature.asc
Description: Message signed with OpenPGP using GPGMail
