The filesystems of macOS are particularly opinionated, much more than most Unices which tend toward "anything is allowed [and usually preserved] except \0 and /".
macOS supports case-insensitivity[0] and performs unicode normalization[1] on filenames, and decomposes name data to an extent that the question "what does the fs see" is a bit moot.
With that said, the internal storage of filenames in APFS are a nul-terminated UTF-8 string[2], with (i'm pretty sure) colons as colons, which the Finder displays as slashes.
[0] if you make a file named "Makefile" then touch a file named "makefile", it'll touch the first file, instead of making a second file.
[1] if you make a file named "schön" (s-c-h-combining¨-o-n) and then search for (s-c-h-ö-n), you can find it, or vice versa. The particular normalization/canonicalization used is NFD.
I think it was due to voids in the hinge area causing localized plasma impingement and heating. The v3 design has a more continuous shape around the hinges.
The slide says something like "run the command `seq 2 10000000 | less` and check `ps`, notice that `seq` isn't running". But that isn't how the processes will behave, `seq` will continue running (albeit blocked) until `less` is dead or closes the pipe.
> If we pipe seq to less and look at the list of running processes using ps aux, we can see that the seq program is not running. ... This explains why the seq program is killed when it is piped to less.
This explanation isn't correct, since a running `less` would not close the pipe and is still a reader. Writes to the pipe would block until `less` fully consumed it, or until `less` was quit such as with the `q` command.
The text _is_ correct if you add a missing step to `q`uit out of the `less` program. I think this step must have been dropped along the way. Unfortunately the screen capture doesn't show this step either.
It's funny, I also read the book as a teen, and I came away from it amazed that IBM was dedicating entire team members to inter-/extra-team communication.
Before that I hadn't even considered how necessary a product manager or project manager were in software development.
But it was the "No Silver Bullet" essay added as a bonus in my copy that I think about the most. "Never again will we see a 10x productivity increase in a decade", this is self-evident now but must have been crushing to people who had experienced the first compilers, the first high-level languages, the first interactive terminals, and waited for the next incredible leap.
On older hardware such as this it could e.g. let you write a multitasking environment that supported shared libraries without use of an MMU (though you'd hit memory constraints pretty quickly on a Z80-era cpu!).
I'm not familiar with the instruction sets of the 6809 but I could also see more compact opcodes, e.g. a JMP with a relative offset can be encoded smaller than JMP with an absolute address.
In modern terms PIC is used for ASLR and is therefore a security requirement. Some arches (I'm most familiar with arm64) are entirely designed around PIC and you need extra hoops to do anything in absolute terms.
I wrote a Rabin—Karp implementation in ~2006 as part of the spam and threat scanning stack for the MX Logic mail service. It was incredibly performant, letting us test {n} bytes against an essentially unlimited number of string signatures in O(n) time.
I write about cryptography but not from any knowledgable position.
Retired.