[TUHS] UNIX of choice these days?

[Clem Cole]

On Mon, Sep 25, 2017 at 8:07 AM, Norman Wilson <norman at 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),

​+1​



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

​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170925/89194585/attachment.html>