fanf2

The 1965 draft had _ https://dl.acm.org/doi/10.1145/363831.363839

The first standard edition with _ was 1968 https://www.rfc-editor.org/info/rfc20

The 1977 version is also available https://nvlpubs.nist.gov/nistpubs/Legacy/FIPS/fipspub1-2-197...

For “capabilities” and “A Language To Encourage Modular Monoliths”, I like the idea of a capability-secure module system. Something like ML’s signatures and functors, but modules can’t import, they only get access to the arguments passed into a functor. Everything is dependency injection. The build system determines which modules are compiled with which dependencies (which functors are passed which arguments).

An existing “semi-dynamic language” is CLOS, the Common Lisp object system. Its metaobject protocol is designed so that there are clear points when defining or altering parts of the object system (classes, methods, etc.) at which the result is compiled, so you know when you pay for being dynamic. It’s an interesting pre-Self design that doesn’t rely on JITs.

WRT “value database”, a friend of mine used to work for a company that had a Lisp-ish image-based geospatial language. They were trying to modernise its foundations by porting to the JVM. He had horror stories about their language’s golden image having primitives whose implementation didn’t correspond to the source, because of decades of mutate-in-place development.

The most common example of the “value database” or image-based style of development is in fact your bog standard SQL database: DDL and stored procedures are very much mutate-in-place development. We avoid the downsides by carefully managing migrations, and most people prefer not to put lots of cleverness into the database. The impedance mismatch between database development by mutate-in-place and non-database development by rebuild and restart is a horribly longstanding problem.

As for “a truly relational language”, at least part of what they want is R style data frames.

When I took over Cambridge University’s DNS, its code and configuration was still in SCCS, because that was what shipped with SunOS in 1991ish. I converted the SCCS archive via RCS and CVS to git – https://dotat.at/@/2014-11-27-uplift-from-sccs-to-git.html – which was a fairly entertaining exercise. (Sadly the links in that blog post are mostly broken.) I even used those conversion scripts more than once! https://dotat.at/@/2016-07-19-uplift-from-sccs-to-git-again.... (That repository ended up with at least three distinct root commits, one for the main DNS history, one for the Ansible setup that started with DHCP and later grew to handle DNS too, and later the separate vanity domain DNS setup.)

https://news.ycombinator.com/item?id=41781827

I like to use the term “nickname” for what they call “edge names” in the article: a nickname is not as personal as a petname, it’s a name you share with others.

An interesting thing that the article sort of hints at is that these kinds of systems have a fairly smooth range of operating points between globally unique and centralized vs decentralized petnames. The article’s example of the bizdir local business directory is somewhere in between these extremes. It sort of turns Zooko’s triangle into more like a fan, where the “human friendly” point is fixed and there’s an arc describing the tradeoffs, from personal through local to global.

How can a petname system function at the global+centralized point, so it could replace the DNS? It needs to pass the “billboard test”: I type in a name I saw on a billboard and I get to the right place. (It might be a multipart name like a postal address or DNS name, with an extra “edge name” or two to provide enough disambiguating context.) I imagine that an operating system supplier might provide a few preconfigured petnames (well, it probably includes its own petname so the software can update itself securely), a lot like its preconfigured PKIX CA certificates. These petnames would refer to orgs like the “bizdir”, or Verisign, or Nominet, that act as nickname registries. Your collection of petnames is in effect your personal root zone, and the preconfigured petnames are in effect the default TLDs. There would inevitably be something like the CA/Browser forum to mediate between OS suppliers and nickname registries: a petname ICANN.

I wrote an older iteration of these ideas over a decade ago (https://dotat.at/@/2012-02-28-path-names-in-a-rootless-dns.h...). Those notes have a bit too much DNS braindamage, but I included some curious anti-DNS discussion: How you might make use of reaching names by multiple paths? What might it look like to have a shared context for names that is not global but is national or regional or local?

The citations for password hashing need to include Roger Needham, who invented it in the late 1960s, as reported by Wilkes in 1973. https://onlinelibrary.wiley.com/doi/10.1002/spe.4380030404

Password cracking took off in a big way with Alec Muffett’s `crack` in 1991 https://en.wikipedia.org/wiki/Crack_(password_software) which was written to do the research on password strength that Stuart Schechter wanted. It became obvious right away that many passwords were weak.

Stuart’s suggestion to encrypt passwords using RSA (so that they could be analysed by the holder of the private key) is cunning, but it would not have had the effect that Stuart expected. Crack was around and demonstrating the problem for decades before password policies changed.

It’s also not true that password hashing was universal after the 1970s. There were lots of systems that stored them in the clear, in particular to support challenge-response authentication (eg NETBIOS). There was a period roughly covering the 1990s where networks were unencrypted (so basic password authentication was very weak) and passwords were no longer stored in world-readable files on timesharing servers. It seemed reasonable then to keep passwords in the clear — but we soon learned that password database leaks are common despite our best efforts, and that was not widely recognised until years into this century.

So for those two reasons I think Stuart’s argument is wrong about the reason that password policies remained so boneheaded for so long. There was no lack of evidence of the ways in which passwords were weak — not just from `crack`, but also plenty of reports about how users react to password reset policies by making their passwords weaker — so hashed password storage was not preventing researchers from analysing the issue.

publish on your own site, syndicate elsewhere

They are proposing a tether that’s about 300,000 km long and 48,000 kg mass, so 0.16g/m

Which seems very small.

Density is about the same as water, so the diameter is about 0.12mm which (for fishing line) has a breaking strain of about 10N. UHMWPE’s strength is about 6 GPa, so (0.00012)^2 * 6e9 is about 100N.

Hmm.

The descriptions of how the CPL compiler worked (eg Strachey’s paper on GPM, Richards more recent retrospectives) all talk about writing the compiler in CPL and translating it by hand to macro assembly.

I have not yet managed to look at Richards PhD thesis which contains the first draft description of BCPL, which he sketched after working on the CPL compiler and shortly before moving to MIT where he first implemented BCPL.

https://gwern.net/doc/cs/algorithm/2001-scott.pdf

Cryptographic hash functions are usually designed to be fast since they are on the hot path for cryptographic signatures and for hash-based message authentication codes.

Password hashes are designed to be slow, but they are an entirely different beast.

The point about https in the conclusion is that the author’s PolyMur hash uses a polynomial construction related to GCM and poly1305, which makes it much harder to invert.

• program is lexed into preprocessing tokens; comments turn into whitespace

• preprocessor does its thing

• preprocessor tokens are turned into proper tokens; different kinds of number are disambiguated; keywords and identifiers are disambiguated

If you put an unclosed comment inside #if 0 then it won’t work as you might expect.