pdw

That's the catchword, the first word of the next page. It helps with keeping the pages in the correct order when binding the book. It could also be an aid when reading aloud, to give the reader one word of "buffer" when turning the page.

Also worth checking out:

Jason Dyer's blog, https://bluerenga.blog/, where he's playing through all adventure games. So far he's made it to 1982.

Jeremy Parish's youtube channel, where he's going through the game libraries of the post-1984 consoles in chronological order.

And also that many of the stones are buried deep in the earth.

That's a great book. Its binary search is buggy though :)

https://ai.googleblog.com/2006/06/extra-extra-read-all-about...

That might have been Brian Harvey's _Computer Science Logo Style_. Downloadable here: https://people.eecs.berkeley.edu/~bh/

The other commenter said that it's a joy to read and that's certainly true. If you're interested in software folk tales and such, it's worth getting.

I still see it recommended as a practical book however and indeed the book bills itself as "the second book you need on C", the book that will cover topics that other C books don't explain or explain poorly. But it's much too outdated to serve that purpose. In practice it means chapters discussing differences between K&R C and ANSI C and deep-dives into details of SunOS and MS-DOS compilers.

Some of the material has become misleading because the C language has evolved. For example, there's a lot of discussion about pointers and arrays, as can be expected. But there's no mention of strict aliasing and pointer provenance (these rules existed in C89, but compilers at the time didn't exploit them yet for optimization). And of course no variable-length arrays (introduced in C99). So you're not going to learn what you need to know in today's world.

The book also has almost no discussion about safety. The Morris worm is mentioned, but just as a piece of historical trivia. Browsing it now, I don't even find any discussion about buffer overflows.

It was a brilliant book, but I feel it's too stuck in the early 90s to recommend today. It's a pity.

I'm confused. Which software is he talking about? I can't think of any program screwing up Ctrl-C in a bad way.

Code that does things like strcat(strcat(strcat(strcpy(...), ...), ...), ...)

Well, what did you do before intmax_t was added to C99?

- POSIX defines that in_port_t is equal to uint16_t, so for that type there's no problem at all ;)

- Don't use printf/scanf for this, roll your own

- Refuse to print/read uid_t that are outside intmax_t range

- Use an autoconf test

But all major C compilers promise that they won't make ABI changes. So I'd rather say that standardizing intmax_t was a mistake.

I think it's best to regard intmax_t as a failed experiment. E.g. GCC has long supported __int128, clang has _ExtInt, other compilers have similar extensions, but they refuse to increase intmax_t due to ABI concerns.

It was Dijkstra's article, but he submitted it with the title "A case against the Go To statement". Wirth was the journal editor and he choose to rename it to "Go To statement considered harmful".

Knuth ties into this because he published a response "Structured Programming with go to Statements", examining many situations where goto statements are hard to avoid in the standard structured programming paradigm.

He might have considered pattern matching a form of runtime type checking.

Out-of-order execution and pipelining date back to the 1960s. The paper calls out the similarity: "If one views the blocks of this scheme as very complex instructions, then this architecture devolves to a pipelined architecture for executing those instruction, and the interlocks to prevent inter-instruction dependency violations."

In the late 1980s it was a common belief that the limit of single-core CPU performance was very near. So there was intense research into multi-core systems, the holy grail was to find a way to efficiently execute ordinary sequential programs. That was what this paper was trying to achieve: "While we currently believe that this work will lead to an architecture which can achieve factors of 10-100 times the performance of uniprocessors on unmodified Lisp programs, we have no proof, even in simulation".

It's referring to the "Open Systems" hype of the 80s / early 90s. The term "open source" became popular only much later.

https://en.wikipedia.org/wiki/Open_system_(computing)

I never got deep into TeX, but I browsed the code at one time and some of what I found seemed utterly insane to me. For example, it includes an IEEE floating point implementation, based entirely on TeX string expansion [1]. I don't know if it is widely used, but I'm not surprised by slow LaTeX compiles anymore.

You say "TeX is already heavily optimized", but that's only true for the layout engine. The input language is entirely based on macros and string expansion. That's fine if you're only going to use it for a bit of text substitution. But as a programming language it's inherently slow. (To be fair, I believe Knuth expected that large extensions, such as LaTeX, would be implemented in WEB.)

[1] https://github.com/latex3/latex3/blob/main/l3kernel/l3fp-bas...

Well, congratulations, you now have a build dependency on Vim. (xxd is not a standard tool, it ships with Vim.)

It's also only suitable for tiny files: compile time and RAM requirements will blow up once you go beyond a couple of megabytes.

I always preferred Tank Wars over Scorched Earth

It's hard to differentiate between completely disabled JavaScript, some individual JavaScript files being blocked by an (overzealous?) ad blocker, and the browser not implementing some required JavaScript feature.

Such a comparison operator exists: IS (NOT) DISTINCT FROM.

You're perhaps under the impression that OpenSSH was the original implementation: it's not, it's a relative latecomer :) The original SSH was (and still is) commercial software, see ssh.com. You basically end up with three groups:

- The original SSH and it's commercial competitors. Some abandoned, some still surviving.

- Various open source implementations. OpenSSH and PuTTY were the winners (PuTTY actually was released first). But there were more attempts (e.g. lsh).

- Those early open source implementations were designed as stand-alone programs (clients and servers). So you have a later wave of library implementations. With of course at least one per language.

It must have been an early version of AAC. Bell was involved with that. And another message in the thread claims "the early versions of the audio compression stuff were not quite is good as the later versions (which became apples stuff)"

No, they own the trademark.

I think the copyright of the old Unix code ended up with Novell in the 90s, so it would now be owned by Micro Focus.

To be explicit, SQLite doesn't support concurrent writers. In WAL mode it can handle a single writer with concurrent readers. In "vanilla" mode, a writer requires exclusive access to the database.

I guess you weren't a Google Reader user. Join the club :)

This StackOverflow question references it: https://stackoverflow.com/questions/4292683/how-do-i-tell-au...

It took years for the GNU maintainers to publish a libtool that fixed this bug, and then years for libtool users to upgrade to the new version.

No, OP was referencing a long-standing bug where libtool would force Fortran checks even in projects that didn't need it at all.

"I can grab the kernel sources from 1997 and build them today."

Where would you be grabbing it from? ...From a website? "Websites shut down, large websites with big storage demands are especially vulnerable to attrition. Who wants to pay the mounting bill for keeping decades of revisions of historical Linux kernels online?"