The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: imp@bsdimp.com (Warner Losh)
Subject: [TUHS] Unix taste (Re: terminal - just for fun)
Date: Mon, 4 Aug 2014 21:32:13 -0600	[thread overview]
Message-ID: <5B476BA2-EA8F-4443-9DA9-A4AA231C28F4@bsdimp.com> (raw)
In-Reply-To: <CALMnNGgrKMX8GFG7AB+zRi3RvNvmAEVyBdDMzjpvmW3xchpvEw@mail.gmail.com>


On Aug 4, 2014, at 8:41 PM, Andy Kosela <akosela at andykosela.com> wrote:

> On Mon, Aug 4, 2014 at 5:24 PM, A. P. Garcia <a.phillip.garcia at gmail.com> wrote:
>> 
>> On Aug 4, 2014 3:22 PM, "Norman Wilson" <norman at oclsc.org> wrote:
>> 
>> <snip>
>> 
>> 
>>> Everything has gotten more complicated.  Some of the complexity
>>> involves reasonable tradeoffs (the move toward replacing binary
>>> interfaces with readable text where space and time are nowhere
>>> near critical, like the /proc and /sys trees in modern Linux).
>> <snip>
>> 
>> To digress from the main topic, I realize that's just one example, but
>> here's a counterpoint to it:
>> 
>> We in Solaris designed /proc as a tool for developers to build innovative
>> solutions, not an end-user interface. The Linux community believes that 'cat
>> /proc/self/maps' is the best user interface, while we believe that pmap(1)
>> is right answer. The reason for this is that mdb(1), truss(1), dtrace(1M)
>> and a host of other tools all make use of this same information. It would be
>> a waste of time to take binary information in the kernel, convert it to
>> text, and then have the userland components all write their own (error
>> prone) parsing routines to convert this information back into a custom
>> binary form. Plus, we can change the options and output format of pmap
>> without breaking other applications that depend on the contents of /proc.
>> 
>> [ https://blogs.oracle.com/eschrock/entry/the_power_of_proc]
> 
> Interestingly, we at FreeBSD got rid of /proc in favor of procstat(1)
> and ptrace(2).  I am still not too sure if it was the Right Thing(r)
> to do though.  The decision was more based on the premise that
> procfs(4) was neglected in recent years than on anything else[0].
> 
> [0] http://freebsd.1045724.n5.nabble.com/Why-is-procfs-deprecated-in-favor-of-procstat-td4028960.html

FreeBSD also chose to export most nuggets of data from the kernel that are
covered by /proc in linux via sysctls. This is one reason that /proc suffered
atrophy in the system: nothing was really using it. One could debate at length
the relative merits of each, but the long-term viability of both in their respective
system I think shows more that the parts that people use are made to work,
with warts well known and tolerated, rather than any one form being purer than
the other.

Warner

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140804/224198f7/attachment.sig>


  reply	other threads:[~2014-08-05  3:32 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-04 20:21 Norman Wilson
2014-08-04 22:24 ` A. P. Garcia
2014-08-04 22:23   ` [TUHS] /proc - linux vs solaris Larry McVoy
2014-08-04 23:11     ` Larry McVoy
2014-08-05  1:26       ` A. P. Garcia
2014-08-05 11:55         ` A. P. Garcia
2014-08-05 12:06     ` Tim Bradshaw
2014-08-05 12:37       ` Steffen Nurpmeso
2014-08-05  2:41   ` [TUHS] Unix taste (Re: terminal - just for fun) Andy Kosela
2014-08-05  3:32     ` Warner Losh [this message]
2014-08-05  9:48     ` [TUHS] procfs on FreeBSD (WAS: Re: Unix taste) Dario Niedermann
  -- strict thread matches above, loose matches on Subject: below --
2014-08-06 22:24 [TUHS] Unix taste (Re: terminal - just for fun) Norman Wilson
2014-08-06 22:19 Norman Wilson
2014-08-04  2:54 Norman Wilson
2014-08-04  3:11 ` Lyndon Nerenberg
2014-08-04  7:04   ` Dave Horsfall
2014-08-04  9:12     ` Steve Nickolas
2014-08-03 16:48 Noel Chiappa
2014-08-03 17:09 ` John Cowan
2014-08-03 11:49 Noel Chiappa
2014-08-03 12:14 ` Steve Nickolas
2014-08-03 16:26 ` John Cowan
2014-08-04 13:59 ` Tim Bradshaw
2014-08-04 14:53   ` A. P. Garcia
2014-08-03  0:48 Noel Chiappa
2014-08-03  8:00 ` A. P. Garcia
2014-08-02 21:18 Noel Chiappa
2014-08-02 23:44 ` A. P. Garcia
2014-08-02 16:47 Noel Chiappa
2014-08-02 18:51 ` Ian King
2014-08-02 14:28 Doug McIlroy
2014-08-02 14:00 ` Larry McVoy
2014-08-02 15:51   ` Steve Nickolas
2014-08-02 16:07     ` John Cowan
2014-08-02 17:28     ` Benjamin Huntsman
2014-08-02 19:50     ` Dave Horsfall
2014-08-02 16:04 ` Diomidis Spinellis
2014-08-02 16:03   ` Larry McVoy
2014-08-02 19:36 ` Dave Horsfall

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5B476BA2-EA8F-4443-9DA9-A4AA231C28F4@bsdimp.com \
    --to=imp@bsdimp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).