> In the past year I think I have finally come to understand the ideals of Unix: file descriptors and processes orchestrated with C. It's a beautiful idea. This

> In the past year I think I have finally come to understand the ideals of Unix: file descriptors and processes orchestrated with C. It's a beautiful idea. This is not however what we interact with. The complexity was not contained. Instead I deal with DBus and /usr/lib and Boost and ioctls and SMF and signals and volatile variables and prototypal inheritance and _C99_FEATURES_ and dpkg and autoconf. The next step is to understand that file descriptors and processes orchestrated with C are a substrate that would make everyone reimplement most of what they want from scratch each time. Part of the list describes system services that we have come to expect from an OS: DBus = interprocess communication; signals = process control; volatile variables and ioctl = hardware control; /usr/lib and dpkg = software packaging and distribution. There are more to be added. at+cron = scheduling. syslog/journald/systemd = monitoring; wall = alerting; cgroup = process and process group control; bash = orchestration from a repl; systemd = orchestration not from a repl; lots of stuff = security; every developer's own file format = configuration; every developer's own plain text protocol = data encoding for IPC. The list goes on from here. Even in the early days of Unix, mature systems like VMS had these capabilities. The problem is not that these exist. It's that they were all built piecemeal instead of being standard system services accessible from a programming language like processes and file descriptors. Except for bash. That's the result of an old mistake: the job control language on OS/360. That's when we got the idea of a command language distinct from a programming language, and we've been building it back towards a programming language ever since. Autoconf, though, is purely penance for the sins of the past.