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.
Me too, I still think it's cool. But while indeed easier-to-implement compared to SGML, it could have been yet a bit simpler. :) I once attempted to write a conforming parser, I remember it being a _lot_ of work to even determine well-formedness.
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.
Diversity is security! I wish more people understood that. It may be more difficult to manage a bunch of diverse systems, but they are much more resilient to attacks.
I don't think that's proven out, like, at all; measure it against the returns on hardening mainstream platforms. The "monoculture" security thing has always been overblown, not least because you're never going to get an ecology where you have enough diversity to matter. Having 3 mainstream desktop or phone options is only marginally better than having just 1, and you're never going to have 20.
Put everything in MicroSoft Active Directory. Wait until it gets hacked. You will lose DNS, DHCP, Email, file servers, web servers, endpoints, etc. Obviously, running a mono-culture is a dumb thing to do if you want to keep your business running.
Maybe instead, run BIND on Linux servers, Apache on OpenBSD servers, have some Chromebooks, some Macs, etc. so everything doesn't go down together.
Really, it's not overblown... it's just common sense to diversify. Like we do with our diet/nutrition, with our financial investments, etc.
It sounds like common sense, but halfhearted diversification --- which is all that's available to mainstream users and enterprises --- can easily reduce security. That's because almost all real world security is logically perimeterized, with a single outward-facing attack surface that's given attention and an implicit premise that post-compromise persistence and pivoting is a given. Nobody survives an internal pentest, not even in 2025.
So by running BIND on Linux and Apache on OpenBSD and trying to tie it all into MSAD, what you're really doing is just expanding your attack surface, and once any of those are broken, attackers won't have to care about the state of the art in vulnerabilities to extend access from there.
The "monoculture" stuff is a product of a time when security pundits worried Microsoft was running the table on corporate IT. We're (generally) SAAS startup people here and very few of us run any Microsoft stuff. Almost all of us are better off extensively hardening a single Linux server environment than we are in deliberately trying to sprinkle NetBSD and Microsoft servers. That's doesn't improve security; it just turns your network into a CTF challenge.
The issue is to make sense of the incredibly detailed AST to answer various questions about the code base. For example, how to make an information flow graph that shows what functions read and write what variables in a set of C++ classes.
I had tried this with the previous versions of sonnet and gemini pro. Sonnet's context, back then, could not hold the full source I was working on. Reducing the context did allow it produce a graph. Both LLMs produced graphs with enough omissions and errors to make the result not useful. In the end, I wrote an interpreter based on libclang to provide the semantics I needed for my particular case. That was not trivial for me (I have decades of experience with s/w dev, working with graphs, etc - but not compiler development). And I used LLM's help to do the development. The new type of semantics would require hard-coding new AST interpreter and graph construction. Repeating that all today with the better LLMs and after more practice driving them might produce something with less effort / more flexibility.
In any case, this experience gave me a new appreciation for compiler developers!
In Unicode it's named "NULL", line one of UnicodeData.txt[1] is `0000;<control>;Cc;0;BN;;;;;N;NULL;;;;`. Unlike ASCII characters Unicode code point names can be more than 3 letters.
Bytes are not strictly ASCII. Even within the realm of ASCII, if you have a binary with strings terminated in 0x00, those aren't generally called "NUL-terminated strings".
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.
While I couldn't find any characters with more than three or four readings in this list, the Taiwan list (https://language.moe.gov.tw/files/people_files/%e5%88%9d%e7%...) has one character with five readings (著) and one with six (和). Still a long way from 15, though.
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.
