On Mon, Sep 25, 2017 at 8:07 AM, Norman Wilson <norman@oclsc.org> wrote:

...

I too am saddened to see such a retrograde step, but perhaps
I'm biased. When I arrived in 1127, the kernel had /proc but
still had ptrace as well. Why? Because no one was brave enough
to wade into sdb and adb.

...

I can sympathize with FreeBSD excuse someone cited elsewhere,
that nobody used the code so it should go--I'm always in favour
of improving programs by chopping sutff out--but I think the
decision here was backwards. The proper answer would have been
to teach ps et al to use /proc, not to invent a new complex of
system calls.

+1 that was my point. If the application code had been available @ UCB earlier before the proliferation,

I think and /proc has been part of 4.2 or at least 4.3 not 4.4, I think there would have been a better chance

of it being used.

I also agree about garbage collection, but this is a case where the right solution would have been to try to get people to use the new interface. The problem was ptrace was 'good enough' and there was no incentive so no one did it.

Mark Litton's thesis was DBX which was being written when 4.2 was being developed. If Mark had had /proc the simplicity would have been compelling. But once the code was written, it was hard to justify switching.

It's my same observation about why Fortran still is #1 in the high end of the business. It's just not interesting to replace it.

So what I'm asking us to try to do, is not just look at the technology in a vacuum. Why was it not interesting to /proc for BSD. Clearly, Linux added it (differently than Eighth Edition of course and the 4.4 implementation was much more like V8 that Linux would settle). People did do the work to use it.

So why did *BSD not bring those versions of the utilities back?

My >>guess<< while they had added some things (like /proc) it was different again and we got into the BSD != Linux stuff - which has been the UNIX war all over again.

Sigh....

I dislike how Linux has tossed information about processes and
other system-related data into the same namespace (and now that
there is /sys as well as /proc, I wonder whether it's time to
divorce them, or even to move /proc into /sys/proc), but the
general direction of moving things into the file system makes
sense.

I agree, but let's just create a /sys/proc namespace and try to be consistent. Here is a case where I wish *BSD would just pick up the Linux solution and be done with it. It's not worth arguing.,

I have some qualms about adding more and more code to
the kernel that just does string processing (making the kernel
bigger and more complicated, and widening the attack surface
for bad guys),

though; maybe most of that stuff belongs not in
the OS proper but in a user-mode program that reads /dev/mem
and presents as a file system.

Agree although, I would love to see consistency and moving towards one namespace & associated API that we all used.