Date: Sun, 14 Jun 2015 11:22:03 +0100 From: Bruce Simpson <bms@fastmail.net> To: Slawa Olhovchenkov <slw@zxy.spb.ru>, Craig Rodrigues <rodrigc@FreeBSD.org> Cc: Marcel Moolenaar <marcel@xcllnt.net>, "svn-src-head@freebsd.org" <svn-src-head@freebsd.org>, "svn-src-all@freebsd.org" <svn-src-all@freebsd.org>, Marcel Moolenaar <marcel@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org> Subject: Re: svn commit: r284198 - head/bin/ls Message-ID: <557D55CB.5050009@fastmail.net> In-Reply-To: <20150614100045.GF58397@zxy.spb.ru> References: <201506100127.t5A1RdX6051959@svn.freebsd.org> <20150612204309.11dd3391@kan> <20150613024916.GA98218@troutmask.apl.washington.edu> <1434208622.1415.57.camel@freebsd.org> <C88CB169-12FE-4692-92AA-5C7D41BB61DF@FreeBSD.org> <557C661F.8080104@freebsd.org> <860017ED-D754-450C-865D-2D81A30C2212@xcllnt.net> <CAG=rPVd93Q18aYnSGSf_QH4C08RCq5wsdKQSNYTgWQ2huTbUHQ@mail.gmail.com> <20150614100045.GF58397@zxy.spb.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On 14/06/2015 11:00, Slawa Olhovchenkov wrote: > On Sat, Jun 13, 2015 at 05:13:31PM -0700, Craig Rodrigues wrote: > >> The people I talk to use scripting languages like Python or Ruby, >> and devops frameworks like Ansible, Saltstack, Puppet, and Chef. >> They may do some quick prototyping and UI work with Javascript and HTML/CSS. >> Being able to generate JSON directly from system-level tools, >> and then analyze that in a Python script, > > You need JSON from system-level tools for analyze that in a Python > script? Realy? Not plain text? or tab/space separated? > So, I am broadly in favour of keeping libxo -- providing the problems with its introduction are fixed. I'm not even thinking of the "DevOps" space, but the R&D space, where Python and R are king. Man pages are small beer and can be dealt with easily. Control flow and regressions from previous functionality are another issue, and I am not for a moment going to duck out and suggest those responsible for introducing it aren't also responsible for fixing these specific issues. But I have yet to see a coherent argument here -- size(1) numbers, RSS figures etc. -- about how it allegedly adds bloat. Most of what I've seen so far is POLA, NIH resistance, and hand-wavery. If anything it helps to future proof the code as it stands, and make it easier for us to actually engineer the system for performance. I tend to look upon counter-arguments against that last point as "The more we obfuscate, the harder it is to get found out that the code isn't actually that good." So, if you read my previous response to this thread, I've clearly pointed out that: there are specific problems in parsing the output of these system tools as they stand. If you don't believe this, you can have my yesterday morning/afternoon, where I was post-processing the output of 4000 individual "vmstat -z" and "vmstat -m" reports. Another 1000 this morning, with more to follow. "Oh boy," I'd say to myself, "I wish I had libxo!" This argument is not limited to base system utilities. For example: iperf 3.x has had a similar reworking of its reporting format to include JSON. This is a massive improvement over iperf 2.x, which does not even clearly document its CSV fields; you have to read the source for that. JSON actually tags each field. This reduces the time from experiment to analysed result significantly, just because I can easily see what each god damned number means. Given, you need to read the source to understand why its naive sequencing algorithm breaks in multipath networking scenarios, but one should not have to do this just to get basic throughput results tabulated.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?557D55CB.5050009>