4 Aug
2014
4 Aug
'14
10:21 p.m.
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
5 Aug
5 Aug
12:24 a.m.
New subject: Unix taste (Re: terminal - just for fun)
On Aug 4, 2014 3:22 PM, "Norman Wilson" <norman(a)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]
12:23 a.m.
New subject: /proc - linux vs solaris
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
1:11 a.m.
New subject: /proc - linux vs solaris
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:
--
---
Larry McVoy lm at mcvoy.com http://www.mcvoy.com/lm
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(a)minnie.tuhs.org
https://minnie.tuhs.org/mailman/listinfo/tuhs
3:26 a.m.
New subject: /proc - linux vs solaris
On Aug 4, 2014 6:56 PM, "Larry McVoy" <lm(a)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. :-)
1:55 p.m.
New subject: /proc - linux vs solaris
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(a)gmail.com>
wrote:
On Aug 4, 2014 6:56 PM, "Larry McVoy" <lm(a)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. :-)
2:06 p.m.
New subject: /proc - linux vs solaris
On 4 Aug 2014, at 23:23, Larry McVoy <lm(a)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).
2:37 p.m.
New subject: /proc - linux vs solaris
|> 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
4:41 a.m.
New subject: Unix taste (Re: terminal - just for fun)
On Mon, Aug 4, 2014 at 5:24 PM, A. P. Garcia <a.phillip.garcia(a)gmail.com> wrote:
On Aug 4, 2014 3:22 PM, "Norman Wilson" <norman(a)oclsc.org> wrote:
<snip>
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-p…
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] 
5:32 a.m.
New subject: Unix taste (Re: terminal - just for fun)
On Aug 4, 2014, at 8:41 PM, Andy Kosela <akosela(a)andykosela.com> wrote:
On Mon, Aug 4, 2014 at 5:24 PM, A. P. Garcia
<a.phillip.garcia(a)gmail.com> wrote:
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
On Aug 4, 2014 3:22 PM, "Norman Wilson" <norman(a)oclsc.org> wrote:
<snip>
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-p…
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] 
11:48 a.m.
New subject: procfs on FreeBSD (WAS: Re: Unix taste)
Andy Kosela <akosela(a)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/
3757
days inactive
3758
days old
10 comments
8 participants
participants (8)
-
A. P. Garcia -
Andy Kosela -
Dario Niedermann -
Larry McVoy -
Norman Wilson -
Steffen Nurpmeso -
Tim Bradshaw -
Warner Losh