[TUHS] Unix taste (Re: terminal - just for fun)

[TUHS] Unix taste (Re: terminal - just for fun)

[Norman Wilson]

Larry McVoy:

  Looking at git like that is sort of like looking at the size of
  a dynamically linked app.  Ya gotta add in libc and all the extensions
  people use to make it not suck.

=====

In which case one should also add the size of the kernel, or at
least the code paths exercised by a given program.

Not to mention the layers of window systems, networking, desktops,
message buses, name-space managers, programs to emulate 40-year-old
terminal hardware, flashy icons, and so on.

I say all this to underscore Larry's point, not to dispute it.

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).
Some reflects the more-complex world we live in (networking).
But a lot of it seems, to my mind that felt really at home when
it first settled into UNIX in 1981, just plain tasteless.

There are certainly legitimate differences in aesthetic taste
involved, though.  I think taste becomes technically important
when it can be mapped onto real differences in how easily a
program can be understood, whether its innards or its external
interface; how easily the program can adapt to different tasks
or environments; and so on.

Norman Wilson
Toronto ON

[TUHS] /proc - linux vs solaris

[Larry McVoy]

On Mon, Aug 04, 2014 at 05:24:39PM -0500, A. P. Garcia wrote:
> 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.

I come from SunOS background and have had more than a few /proc discussions
with Roger Faulkner (who I believed did the System V /proc at Bell Labs?).

I get the arguments above but I don't buy 'em.  linux really got /proc
right in terms of usefulness.  Digging binary blobs out of the kernel
and translating them sucks.  I've done, I've written kmem drivers for
ps, I understand how it works.  I far prefer the pure ascii model that
Linux has.

I also get that Linux turned /proc into /whatever/I/think/I/need/today
and that makes purists grit their teeth.  None the less, if you give
me a choice I'll take the linux way.  Want to see what files you have
open?

	ls -l /proc/$$/fd

Etc.  Really easy to poke around and figure stuff out as needed and no
rats nest of header files to decode the structures.

--lm

[TUHS] Unix taste (Re: terminal - just for fun)

[A. P. Garcia]

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]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140804/54f140ed/attachment.html>

[TUHS] /proc - linux vs solaris

[Larry McVoy]

Seem like even Roger liked it:

https://lwn.net/lwn/1998/0226/sunproc.html

On Mon, Aug 04, 2014 at 03:23:25PM -0700, Larry McVoy wrote:
> On Mon, Aug 04, 2014 at 05:24:39PM -0500, A. P. Garcia wrote:
> > 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.
> 
> I come from SunOS background and have had more than a few /proc discussions
> with Roger Faulkner (who I believed did the System V /proc at Bell Labs?).
> 
> I get the arguments above but I don't buy 'em.  linux really got /proc
> right in terms of usefulness.  Digging binary blobs out of the kernel
> and translating them sucks.  I've done, I've written kmem drivers for
> ps, I understand how it works.  I far prefer the pure ascii model that
> Linux has.
> 
> I also get that Linux turned /proc into /whatever/I/think/I/need/today
> and that makes purists grit their teeth.  None the less, if you give
> me a choice I'll take the linux way.  Want to see what files you have
> open?
> 
> 	ls -l /proc/$$/fd
> 
> Etc.  Really easy to poke around and figure stuff out as needed and no
> rats nest of header files to decode the structures.
> 
> --lm
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs

-- 
---
Larry McVoy            	     lm at mcvoy.com             http://www.mcvoy.com/lm 

[TUHS] /proc - linux vs solaris

[A. P. Garcia]

On Aug 4, 2014 6:56 PM, "Larry McVoy" <lm at mcvoy.com> wrote:
>
> Seem like even Roger liked it:
>
> https://lwn.net/lwn/1998/0226/sunproc.html

:-) There are a few different issues here. Linux exports a lot of
interesting info that Solaris doesn't. It's hard not to like that. Where
they put it, who cares. The unix filesystem hierarchy wasn't exactly
planned out by neat freaks.

> On Mon, Aug 04, 2014 at 03:23:25PM -0700, Larry McVoy wrote:
> > On Mon, Aug 04, 2014 at 05:24:39PM -0500, A. P. Garcia wrote:
> > > 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.
> >
> > I come from SunOS background and have had more than a few /proc
discussions
> > with Roger Faulkner (who I believed did the System V /proc at Bell
Labs?).
> >
> > I get the arguments above but I don't buy 'em.  linux really got /proc
> > right in terms of usefulness.

> Digging binary blobs out of the kernel
> > and translating them sucks.  I've done, I've written kmem drivers for
> > ps, I understand how it works.  I far prefer the pure ascii model that
> > Linux has.

Part of the argument was more or less that the binary model allows a richer
set of tools to be built on top of it, and that those tools provide a
better interface to the info. Does Solaris have a richer set of tools than
Linux in this regard? I think so, but I don't know how much of this is owed
to the difference between binary and text interfaces in /proc.

Last time I checked, Linix had no pcred(1), for example. top(1) doesn't
provide nearly as much info as prstat(1) -- for example, prstat -mL. Why
that is, I don't know. Plus, prstat is marginally less resource intensive.
Anything as sweet as (k)mdb in linux? Forget it. Maybe that's because Linus
was so resistant to having a debugger in the kernel for so long? DTrace?
Well, sort of -- a port of dtrace! But I'm really at an unfair disadvantage
here. *Why* Solaris has such better tools, you would know better than me. I
only know that it does. As for the second part, that writing the tools that
use the binary interface is unpleasant, again I have to defer to you. I've
never done that.

> > I also get that Linux turned /proc into /whatever/I/think/I/need/today
> > and that makes purists grit their teeth.  None the less, if you give
> > me a choice I'll take the linux way.  Want to see what files you have
> > open?
> >
> >       ls -l /proc/$$/fd

I think this would work in solaris, maybe linux too: pfiles $$

> > Etc.  Really easy to poke around and figure stuff out as needed and no
> > rats nest of header files to decode the structures.

Again, that's what the tools are for. If a tool doesn't give me the info I
need in Solaris, I guess I'm SOL. In Linux, *maybe* I'd have a chance of
finding it in /proc.  :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140804/2a6cf51a/attachment.html>

[TUHS] Unix taste (Re: terminal - just for fun)

[Andy Kosela]

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

[TUHS] Unix taste (Re: terminal - just for fun)

[Warner Losh]

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>

[TUHS] procfs on FreeBSD (WAS: Re: Unix taste)

[Dario Niedermann]

Andy Kosela <akosela at andykosela.com> wrote:

> 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.

It wasn't, IMO. It's a departure from "everything is a file".

A tenet which - if anything - should be more widely embraced, rather
than discarded (I'm looking at you, X11 !)

In fact, that's a major FreeBSD peeve of mine.


-- 
Dario Niedermann.              Also on the Internet at:

gopher://retro-net.org/1/dnied/ , http://devio.us/~ndr/

[TUHS] /proc - linux vs solaris

[A. P. Garcia]

After sleeping on this, I realized that with DTrace, the extra goodies
exported by linux in /proc may be superfluous. Which would just mean that a
nice innovation was perhaps trumped by a more powerful one.

However, some of the missing commands in linux-ptools should be trivial to
add, and it's somewhat curious that no one has (pcred, pfiles). The one
possible exception to this is prstat.
 On Aug 4, 2014 8:26 PM, "A. P. Garcia" <a.phillip.garcia at gmail.com> wrote:

>
> On Aug 4, 2014 6:56 PM, "Larry McVoy" <lm at mcvoy.com> wrote:
> >
> > Seem like even Roger liked it:
> >
> > https://lwn.net/lwn/1998/0226/sunproc.html
>
> :-) There are a few different issues here. Linux exports a lot of
> interesting info that Solaris doesn't. It's hard not to like that. Where
> they put it, who cares. The unix filesystem hierarchy wasn't exactly
> planned out by neat freaks.
>
> > On Mon, Aug 04, 2014 at 03:23:25PM -0700, Larry McVoy wrote:
> > > On Mon, Aug 04, 2014 at 05:24:39PM -0500, A. P. Garcia wrote:
> > > > 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.
> > >
> > > I come from SunOS background and have had more than a few /proc
> discussions
> > > with Roger Faulkner (who I believed did the System V /proc at Bell
> Labs?).
> > >
> > > I get the arguments above but I don't buy 'em.  linux really got /proc
> > > right in terms of usefulness.
>
> > Digging binary blobs out of the kernel
> > > and translating them sucks.  I've done, I've written kmem drivers for
> > > ps, I understand how it works.  I far prefer the pure ascii model that
> > > Linux has.
>
> Part of the argument was more or less that the binary model allows a
> richer set of tools to be built on top of it, and that those tools provide
> a better interface to the info. Does Solaris have a richer set of tools
> than Linux in this regard? I think so, but I don't know how much of this is
> owed to the difference between binary and text interfaces in /proc.
>
> Last time I checked, Linix had no pcred(1), for example. top(1) doesn't
> provide nearly as much info as prstat(1) -- for example, prstat -mL. Why
> that is, I don't know. Plus, prstat is marginally less resource intensive.
> Anything as sweet as (k)mdb in linux? Forget it. Maybe that's because Linus
> was so resistant to having a debugger in the kernel for so long? DTrace?
> Well, sort of -- a port of dtrace! But I'm really at an unfair disadvantage
> here. *Why* Solaris has such better tools, you would know better than me. I
> only know that it does. As for the second part, that writing the tools that
> use the binary interface is unpleasant, again I have to defer to you. I've
> never done that.
>
> > > I also get that Linux turned /proc into /whatever/I/think/I/need/today
> > > and that makes purists grit their teeth.  None the less, if you give
> > > me a choice I'll take the linux way.  Want to see what files you have
> > > open?
> > >
> > >       ls -l /proc/$$/fd
>
> I think this would work in solaris, maybe linux too: pfiles $$
>
> > > Etc.  Really easy to poke around and figure stuff out as needed and no
> > > rats nest of header files to decode the structures.
>
> Again, that's what the tools are for. If a tool doesn't give me the info I
> need in Solaris, I guess I'm SOL. In Linux, *maybe* I'd have a chance of
> finding it in /proc.  :-)
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20140805/feb33982/attachment.html>

[TUHS] /proc - linux vs solaris

[Tim Bradshaw]

On 4 Aug 2014, at 23:23, Larry McVoy <lm at mcvoy.com> wrote:

> I get the arguments above but I don't buy 'em.  linux really got /proc
> right in terms of usefulness.  Digging binary blobs out of the kernel
> and translating them sucks.  I've done, I've written kmem drivers for
> ps, I understand how it works.  I far prefer the pure ascii model that
> Linux has.

I agree with this, with one caveat: there are things which exist in /proc which should be in a standard format (extensible if need be) but are not.  I forget the particular example but I've written patches for, I think, node.js which essentially came down to "add yet another special case for /proc/<whatever>", when there was just no reason that the thing should not have been in a standard format in the first place.

Certainly as a user of Solaris and Linux, Linux's /proc is just far more useful (though I like pmap).

[TUHS] /proc - linux vs solaris

[Steffen Nurpmeso]

 |> I get the arguments above but I don't buy 'em.  linux really got /proc
 |> right in terms of usefulness.  Digging binary blobs out of the kernel

 |I agree with this, with one caveat: there are things which \
 |exist in /proc which should be in a standard format (extensible \
 |if need be) but are not.  I forget the particular example \

Whereas unprofessional i missed the most any documentation; if
i recall correctly (i think i do) in at least the 2.4 series there
was a PROCFSENTRY() (or quite similar) macro which well did what
it says and i still don't understand why there was no, and may it
be optional, and may the final usage of it be optional in
addition, documentational string argument for this.  That is
i found, and again found some years ago when i first installed
Linux on this Notebook and tried to get the fans controlled, that
it is completely intransparent; how easy would it be if each entry
in proc had a xy.txt that simply expands to the the content of the
mentioned string argument?  Like it was it took hours to get the
fans right.  How nice it was once i switched over to (then Free)
BSD, which documents not not nil (as in [1]).

  [1] <http://netbsd.gw.com/cgi-bin/man-cgi?sysctl+7+NetBSD-current>

--steffen