From owner-svn-src-head@FreeBSD.ORG Sun Jun 14 10:22:14 2015 Return-Path: Delivered-To: svn-src-head@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 89431942 for ; Sun, 14 Jun 2015 10:22:14 +0000 (UTC) (envelope-from bms@fastmail.net) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4814D68A for ; Sun, 14 Jun 2015 10:22:14 +0000 (UTC) (envelope-from bms@fastmail.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 959632038E for ; Sun, 14 Jun 2015 06:22:06 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Sun, 14 Jun 2015 06:22:06 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=fastmail.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=UrS3lFugXI8NV5Hn4okW2O0vvpA=; b=MKtopW E3lZOTtvJo8SrVW82h16zeWEP7x+km5m7ACWsfIys+f4RxQ1EJysg8gYY7rx1m7Q BLrxnfvn6vnBtYWav3gjnxDLZP62tmNvESCf35DbI0VuKsKIK1njDIlaE2x9EvvQ OGLL28NWMPStiNHju9Q59ocgVrZwvN1x7VqkE= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=UrS3lFugXI8NV5H n4okW2O0vvpA=; b=WZ3d4tUCw5Cg/bKM6gnn84oA6rUTPQUazRUcAbaTM43arY0 /8CpsjRK3khzhi45IAw5K35cmMi48txhVDeftyBbytPw9ahNTgcShekis9Zxkyq0 LlcJ6lM1zs+d1gxaJxZI/Yt66Uu7yd9OqdWhFE2AYeHa8cdQoa5Z/t1LZr7U= X-Sasl-enc: lHB5cJBSW8xKiw9pl3utxMj7OPQMAWG6wwsbNDKopU3X 1434277325 Received: from [192.168.1.87] (unknown [94.194.112.103]) by mail.messagingengine.com (Postfix) with ESMTPA id A350EC00017; Sun, 14 Jun 2015 06:22:04 -0400 (EDT) Message-ID: <557D55CB.5050009@fastmail.net> Date: Sun, 14 Jun 2015 11:22:03 +0100 From: Bruce Simpson User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Slawa Olhovchenkov , Craig Rodrigues CC: Marcel Moolenaar , "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , Marcel Moolenaar , "src-committers@freebsd.org" Subject: Re: svn commit: r284198 - head/bin/ls References: <201506100127.t5A1RdX6051959@svn.freebsd.org> <20150612204309.11dd3391@kan> <20150613024916.GA98218@troutmask.apl.washington.edu> <1434208622.1415.57.camel@freebsd.org> <557C661F.8080104@freebsd.org> <860017ED-D754-450C-865D-2D81A30C2212@xcllnt.net> <20150614100045.GF58397@zxy.spb.ru> In-Reply-To: <20150614100045.GF58397@zxy.spb.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jun 2015 10:22:14 -0000 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.