Unix: An Oral History
princeton.edu
princeton.edu
For myself, I think the human element is what I find fascinating. Hearing other people's stories makes me think, I could do that. I also find it inspiring to read about great minds, and where we have come from.
There was only one interpreter I believe. It was called shell.
At some point, I started to notice that we're all showing up "in the middle of the story", so to speak, and stories about the past are immensely helpful for putting the current moment into context. This is true for what we think of as "textbook history", like the history of politics and war and the rise and fall of nations, to put current world events in context, but it's perhaps even more valuable for smaller things that matter to us more immediately in day-to-day life.
I have found that reading about the history of a scientific or mathematical field helps the ideas stick much better when trying to study. Learning about my parents' and grandparents' lives before I was born made some aspects of my childhood make a lot more sense. And reading about the history of the software and tools we use helps illuminate some of the design decisions and tradeoffs that were made.
For me, that shift didn't happen until I was well into adulthood, and I suspect that's common. I think once you reach a point where parts of your own life feel like "history", like a prelude for where you currently are, then it's a lot easier to notice the value of history in other areas.
In my day job I spend my time adding components to a company's website. It pays my bills and keeps a (comfortable) roof over my daughter's head but I'm under no illusion that going this route will accomplish anything that puts a dent in the universe like these legends of industry.
https://web.archive.org/web/20230509073604/https://www.princ...
Consider: a kernel and userspace written in a more memory-safe language (Multics was written in PL/I and had essentially zero buffer overflows); ring security; long/human-readable command names in addition to terse abbreviations; multiple entry points for programs; etc..
See also: https://multicians.org/myths.html
Even if not, by the time we reached 1980, with the pleothara from PL/I dialects, BLISS, Modula-2, Mesa, Object Pascal,..., it was more than possible to fix C.
Or 50 years later, where WG14 keeps ignoring the issue related to bounds checking aware types and fat pointers.
0x0A h e l l o _ w o r l d
But that limited the length of strings to 255 characters and using two bytes rather than one would add memory pressure. Dennis Ritchie then went with null terminated strings which has the advantage of allowing any size of strings and is consistent with the assembly they were used with. The drawbacks is decades of buffer overflows :)
Eventually I found an abstract on https://en.wikipedia.org/wiki/Null-terminated_string#History and there is a 2011 paper about it: Communications of the ACM - Volume 54 - Issue 901 - September 2011 - pp 42–44 - https://doi.org/10.1145/1995376.1995391 . Direct link to the PDF https://dl.acm.org/doi/pdf/10.1145/1995376.1995391
Eventually fat pointers were used instead.
Which even Denis himself proposed for WG14 during the C89 standardization, and wasn't accepted.
And it's not like C can't be memory-safe, as shown by CHERI/Morello (shameless plug). It depends on hardware.
Going to have to disagree here. PowerShell reminds me of Lisp Machines/Emacs in this regard. As long as the shell supports completions this isn't an issue and aids in habituation and discover-ability IMHO.
> Similarly, Kernighan believes that no one could be a programmer in Unix without being a user of the system.
There is something in this.
For those that may not have seen this, before, one of my favorite pages on UNIX history is:
https://multicians.org/unix.html
The name origin is, perfection.
Recently, there was a job posting with a typo that was posted to reddit - a request for a "full sack developer". This provided an extremely rare opportunity to make certain ... Multics / UNIX jokes ...
https://www.reddit.com/r/ProgrammerHumor/comments/11mi8wc/in...
(e.g., "u/AFreshTramontana" - "And I thought Multics1 was dead...
Let us have Caladonia do her highly erotic temple dance in praise of Eros..."
... rare opportunity, pretty good capitalization IMO)
Not Found
The requested URL /~hos/frs122/unixhist/finalhis.htm was not found on this server.
Apache/2.4.6 () Server at www.princeton.edu Port 443
"make is a Script"
Uh?
Really? file /usr/bin/make /usr/bin/make: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=3b0ddf3be104de4e5e023681f6db3c143c5ad798, for GNU/Linux 3.2.0, stripped make is a program, not a script. Maybe it was a script back then. What was the interpreter?
Every time I get with badly cooked Makefile a song comes to mind:
"I am the maker of rules Dealing with fools I can cheat you blind"
[1] https://github.com/dspinellis/unix-history-repo/blob/Researc...