housel

I worked for him as well, from 1988 through 1990. He mentored me as I helped sysadmin various BSD machines the university was beta-testing (CCI Tahoe and Gould NP-1), and supervised my work fixing bugs in the Berkeley Pascal compiler. It was fun watching him put his early-model Motorola cell phone into service mode and tweak register values... while he was driving. And of course I enjoyed finding him in his office at all sorts of weird hours and listening to him rant about various technical topics.

The ADM3a was just a UART chip, RAM chips, character ROMs, and a bunch of 74LS chips to glue it all together. No CPU, and no way to generate graphics.

Given that it's an essential/definitional issue, I would have preferred that the author at least showed awareness of the differences between languages intended for marking up text and languages intended to represent data in a structured way.

Back when XML was first being developed, I was really anticipating having a standardized, easier-to-implement successor to SGML (which was hampered by its complexity and by the cost of the ISO standard) in the text markup space. It was that disappointing it ended up filling the vacuum in the space of serialized representations for for structured data, then getting rejected when it wasn't quite as suitable for that as alternatives such as JSON.

Yes, we overlapped around then.

I was a student part-time administrator/systems programmer at the Purdue Engineering Computer Network at the time. Our OS installs had enough local mods (and we had enough non-VAX, non-Sun architectures) that we were immune to some of the worm's modalities, but the sendmail debug mode exploit at least still caused a lot of consternation.

"clang -Xclang -ast-dump=json" will take you partway there.

Though "null pointer" and "null value" are correct, for bytes it should be "NUL byte", since ASCII code point 0 is NUL.

Depends on when "back in the day" was; even in the mid-to-late 80s, especially if you were on a multi-user system, on BSD 4.2/4.3 local and networked printer access went through the Line Printer Daemon (still available on the BSDs).

For PostScript printers, there was a filter application (provided by Adobe) that would turn plain text (without the %! magic) into PostScript.

At a previous employer we generated assemblers and disassemblers for various DSP cores based on an Excel spreadsheet that the software tools team shared with the processor architects. The spreadsheet cells described the layout of the various instruction fields; this was converted with a script to an architecture description DSL, from which the assembler, disassembler, and other tools could be generated. Another DSL described the pipeline stalls and hazards, and code generated from the combined descriptions drove instruction schedulers and code checkers.

Overall this is helpful, but it seems a bit ranty, and doesn't do as much as (for example) John Day's Patterns in Network Architecture to provide a positive alternative model.

A lot of Douyin content ends up on YouTube Shorts if you know where to look.

This is a serious criticism... even if it's not likely to catch on enough to have a real effect on the sea level, it is a complete waste of energy to accomplish something that could be done much more efficiently some other way, if it is indeed worth doing at all.

There's no special "bootstrap compiler"; you can download a binary release for your platform from the page you linked, and then use that to bootstrap a newer version from a source checkout. If it would help, we could provide a minimalistic build that was only useful for bootstrapping, but at present our builds are "batteries included" (with LLVM/Clang and the BDW garbage collector already provided in the tarball).