[TUHS] UNIX of choice these days?

[Larry McVoy]

On Mon, Sep 25, 2017 at 10:16:11AM -0400, Clem Cole wrote:
> 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.

Linux's /proc was hugely different than the AT&T /proc, in a good way in
my opinion.  It's sort of Tcl like :-), everything is a string.  So you
can look at the files with cat.  I think plan 9 went this way as well.

And the Linux /proc did and does so much more than AT&T /proc.  You 
can tune the system, debug the system, here's an example.  You know
something is holding something open, you want to know what.  

	$ ps 
	  PID TTY          TIME CMD
	 2668 pts/8    00:00:00 bash
	14153 pts/8    00:00:00 ps
	$ cd /proc/2668/fd
	$ ls -l
	total 0
	lrwx------ 1 lm lm 64 Sep 23 21:16 0 -> /dev/pts/8
	lrwx------ 1 lm lm 64 Sep 23 21:16 1 -> /dev/pts/8
	lrwx------ 1 lm lm 64 Sep 23 21:16 2 -> /dev/pts/8
	lrwx------ 1 lm lm 64 Sep 23 21:39 255 -> /dev/pts/8

Now isn't that pleasant?  (Yes, I know about lsof).

One could make an argument that for debugging you need a lighter weight
way to get the info, and maybe ptrace is lighter, I dunno.  But for most
stuff the Linux /proc (it's really /system because it's about way way
more than processes) is super pleasant.

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

Yeah, I don't see the two being compat.  They could overlap but when you get
into specific tuning variables they won't match.

I suspect that no /proc in BSD is simple, there wasn't anyone who wanted to
put in the time to evolve it and maintain it.