And for all the whining about how "but DNSSEC doesn't do anything!", this is exactly an attack scenario which DNSSEC protects, and which it has protected since the very first RFC describing it. The client can check for itself whether the IP address in the response has been correctly signed by the (sub-)domain owner (and recursively whether the (sub-)domain has been signed by the parent domain, all the way back to the root).
As for "but how will I redirect hosts to my captive portal?", that's what DHCP option 114, DHCPv6 option 103 and IPv6 Router Advertisement option 37 are for. https://developer.apple.com/news/?id=q78sq5rv
So failed look at archaic miss transliterations, kind of reminiscent of the entire theme of the article. The example map being built on an argument from a bad assumption (a historical error as a pretext for argument).
Perfect irony.
As was common for Chinese romanization systems from before the 20th century, it used 't' for unaspirated /t/ (which we would use use 'd' for today in systems like Pinyin for Mandarin or Peng'im for Teochew), and used 'th' for aspirated /tʰ/ (which we sould use 't' for today in systems like Pinyin or Peng'im).
This isn't an archaic miss transliteration, it's just an alternative transliteration strategy. In many languages that primarily use the latin alphabet, the phonemes associated with 't' and 'd' are /t/ and /d/, primarily distinguished by voice instead of aspiration (where aspiration is allophonic), so it's logical that the creators of earlier romanization systems focused on preserving that voice distinction, even if it's less common today for a variety of reasons.
400 megabytes of memory usage is probably worth more than 400 megabytes of storage. It may not be a make-or break thing on it's own, but it's one of the reasons Linux can run on lower-end devices.