[TUHS] UNIX of choice these days?

[clemc@ccc.com (Clem Cole)]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3052 bytes --]

On Sun, Sep 24, 2017 at 10:02 AM, ron minnich <rminnich at gmail.com> wrote:

> ptrace replaces procfs? Wow, that's a disappointing turn of events. It's
> also against the flow of thought in the Unix community I knew in 1980. If
> somebody has any of the old ca-1980 BSD manuals, you should find a BUGS
> section on ptrace advocating a move to a file-system-like interface. I
> always assumed ken wrote that little note when he was visiting UCB --
> anybody know?
>
​Need to check the UCB SCCS deltas, but I doubt it.  Ken was there before
​/proc appeared in Eight Edition.
ptrace was a hack, I don't think Dennis was particularly happy with it.  It
was sprt of considered a weak link.




>
> Plan 9 implements process debug via /proc, and several debuggers use that
> interface
>
​Yes, pretty much post Eight  Edition, /proc becomes the defacto interface.​
Looking back on the time, I think two things go in its way which were both
more political than technical.
By the time it appears in the Research kernel, there is still not an agreed
upon file system layering.   The vfs-layer would start to get argued about,
but it wasn't there [ more in a minute ].

So file systems (like /proc) were still more ad-hoc interfaces.

Second because either edition was not released the same way eailier
versions were, and AT&T was trying to use Summit as their IP release
mechanism; it got caught in the 'UNIX Wars.'    I really think as much as
BSD was making great strides, if the new features of Eight had been made
available to BSD, many of them (like /proc) would have been integrated and
if had been integrsated earilier, more of the BSD tools (like debugger, et
al) would have relied on it and if that had occured; it would have been
better integrated (like it is in Linux today).




> ​....
>
> The file system model is powerful. The strace based on /proc was a few
> dozen lines.
>
​Amen... ​



​To me, the really important thing SMI did by giving away NFS, was to start
the FS laying argument.   What we ended up with is not perfect, its a
compromise (I wish the stacking model was better), but we started to have
the discussion.​   But because of NFS, we ended up getting a lot of
different file system options; which previously we did not have.   It made
us really think through what were 'meta' functions that were FS
independant, 'virtual' functions what span all FS implementasions, and what
were 'physical' (implementation) specific file system functions.

NFS really should be credited for forcing that clean up.

Similarly, a few of us tried (and failed) to have the process layer
discussion -- consider the Locus vprocs work.   It's really too bad, we
don't have that layer in any of the UNIX kernels today, it really make
process control, migration, etc a lot cleaner; just as adding a file system
layer did.

But that's a war, I fought and lost....
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170924/cb4aa21c/attachment-0001.html>