Path: csiph.com!weretis.net!feeder9.news.weretis.net!panix!.POSTED.spitfire.i.gajendra.net!not-for-mail From: cross@spitfire.i.gajendra.net (Dan Cross) Newsgroups: alt.folklore.computers Subject: Re: Don Norman: The Truth About Unix Date: Wed, 15 Apr 2026 16:11:14 -0000 (UTC) Organization: PANIX Public Access Internet and UNIX, NYC Message-ID: <10rodb2$aae$1@reader1.panix.com> References: <10lb6d7$3she5$1@dont-email.me> <10rnsi2$t8c$1@reader1.panix.com> Injection-Date: Wed, 15 Apr 2026 16:11:14 -0000 (UTC) Injection-Info: reader1.panix.com; posting-host="spitfire.i.gajendra.net:166.84.136.80"; logging-data="10574"; mail-complaints-to="abuse@panix.com" X-Newsreader: trn 4.0-test77 (Sep 1, 2010) Originator: cross@spitfire.i.gajendra.net (Dan Cross) Xref: csiph.com alt.folklore.computers:234678 In article , Scott Lurndal wrote: >cross@spitfire.i.gajendra.net (Dan Cross) writes: >>In article , >>Anthk wrote: >>>On 2026-01-27, Lawrence D’Oliveiro wrote: >>>> [snip] >>>> The truth about Unix: The user interface is horrid >>>> Donald A. Norman >>>> Department of Psychology and Program in Cognitive Science >>>> Center for Human Information Processing >>>> University of California, San Diego >>>> La Jolla, California 92093 >>>> >>>> [snip 500+ lines of quoted text] >>> >>>9front tried to fix consistency on commands, everything it's a file (yes, >>>no ioctls), and far less syscalls. >>> >>>Plan9/9front killed Unix for the good. >> >>It is true that the number of system calls Plan 9 exposes is >>smaller than anything in the Unix family, and there is no >>`ioctl`. But regardless of that, the system Plan 9 interface is >>deceptively wide: each driver synthesizes a small filesystem >>for userspace programs to interact with it, and usually exposes >>a `ctl` file that takes free-form text to direct a device or >>other program to do something; these must be parsed, in the >>kernel. Fortunately, there are some library routines to help >>with this. But as a result, the system interface is arguably >>less coherent than `ioctl`. > >SVR4 picked up some of this when they replaced 'ptrace' with >the /proc file system as the debugger-kernel interface for >application debugging. > >With /proc, the interfaces were binary, not text, however, >so the kernel wasn't required to parse strings. > > STRUCTURE OF /proc/pid > A given directory /proc/pid contains the following entries: > > as Contains the address-space image of the process; > the file can be opened for both reading and writing. > lseek is used to position the file at the virtual > address of interest and then the address space can > be examined or changed through read and write. > > ctl A write-only file to which structured messages are > written directing the system to change some aspect > of the process's state or control its behavior in > some way. The types of control messages are > described in detail below. Individual LWPs also > have associated lwpctl files. A control message may > be written either to the process's ctl file or to > a specific lwpctl file with operation-specific > effects as described. The effect of a control > message is immediately reflected in the state of > the process visible through appropriate status and > information files. > > status Contains state information about the process and one > of its LWPs (chosen according to rules described > below). > ... > Yeah, that was the original procfs; Killian did it in 8th Edition Research Unix (which was, itself, basically a "re-port" of 4.1BSD). Faulkner did procfs2 for Solaris (wikipedia says Sol2.6), which follows the binary-only model of the original.. Linux's /proc was modeled after the Plan 9 code. Norman Wilson said that after everything was switched over to the FS-based model, he glued the (facing) pages for `ptrace(2)` together in the UPM in the Unix Room. :-D - Dan C.