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? 

Plan 9 implements process debug via /proc, and several debuggers use that interface -- including, in harvey, gdbstub so we can remote gdb processes. I also implemented an strace-like command by extending /proc/pid/ctl with a few extra commands. In so doing, I made it possible to write strace with a shell script, which was kind of fun. 

I always felt the /proc/pid/ctl model in Plan 9 implemented what we hoped to see implemented in Unix to replace ptrace. ptrace, even the new ones, are clunky in the best times.

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

On Sun, Sep 24, 2017 at 6:47 AM Andy Kosela <> wrote:

On Saturday, September 23, 2017, Steve Mynott <> wrote:
On 23 September 2017 at 10:17, Dario Niedermann
<> wrote:
> Il 20/09/2017 alle 02:39, Dave Horsfall ha scritto:
>> Definitely FreeBSD, because it's solid, has thousands of ports,
>> and well, is BSD...
> I have been a user in the past, but I just can't forgive FreeBSD for
> abandoning the proc filesystem  :-(

procfs still exists in FreeBSD and can be added to fstab but isn't
mounted by default after an install.

Generally the BSDs (and OS X) don't seem to actively maintain procfs
and it has been remove from OpenBSD.

4096R/EA75174B Steve Mynott <>

This is not true.  Procfs has been deprecated in FreeBSD since at least 2012.

And replacement for procfs is not sysctl, but rather ptrace(2).

I am one of those that also did not like that.  There is some magical simplicity in the way procfs is implemented -- it spells real UNIX to me.