Category: Computing

Another look at (old) Distributed Systems

Remember watching this talk by Michael Bernstein many years ago, and some good things are worth revisiting, so I re-watched it today.

It’s backed by some reading material too.

Part 1

These days I’m re-reading a lot of earlier papers, and this added some items to my list.

Licklider’s story has, in the years since this talk, become part of a book by Stripe Press, The Dream Machine

Minsky’s Society of the Mind has also, since this talk, become freely available online

However, “ Viewing Control Structures as Patterns of Passing Messages” was new to me, and is probably worth re-reading along with the classic actor paper.

Ye Olde Linux

An account of “Linus-as-Martin Luther” from an article in Salon, 25 years ago:

Linus Torvalds is an information-age reformer cut from the same cloth. Like Luther, his journey began while studying for ordination into the modern priesthood of computer scientists at the University of Helsinki — far from the seats of power in Redmond and Silicon Valley.

Also like Luther, he had a divine, slightly nutty idea to remove the intervening bureaucracies and put ordinary folks in a direct relationship to a higher power — in this case, their computers.

Dissolving the programmer-user distinction, he encouraged ordinary people to participate in the development of their computing environment. And just as Luther sought to make the entire sacramental shebang — the wine, the bread and the translated Word — available to the hoi polloi, Linus seeks to revoke the developer’s proprietary access to the OS, insisting that the full operating system source code be delivered — without cost — to every ordinary Joe at the desktop.

While the rise of Linux no doubt played a central role in the last two decades, the “programmer-user distinction” hasn’t gone away as the author’s (or an early SVLUG zealot’s) giddy excitement would suggest. In fact “free software” was largely co-opted by the cloud giants of today — they wouldn’t exist without it.

Language comparison

Came across this pros/cons table recently (some un-named company, when deciding on micro-service language-of-choice):

Mostly agree, except that

  • We do have generics in Go (as of 1.18) and “… unfamiliar with the language” is true for any language
  • The Python cons will remain as they are (though they should matter much less when not doing cpu-intensive tasks)
  • The Rust cons will reduce as (1) it becomes less ‘new‘, and (2) the ecosystem becomes more ‘strong‘, and (3) async/await has been standardized now, but yes, the memory model will always take time to learn.

Given this, and admitting a lack of Kotlin knowledge, IMO Go seems like a safe default choice (or Rust/Python where appropriate).

On Urbit

(content here copy-pasted from this HN thread, because I thought it was a good summary)

What is Urbit?

Urbit is a virtual machine OS for server-side applications. If you imagine a future in which it is common for non-technical people to rent cloud server space on which to host server-side applications (say, a small blog, a mastodon node, a minecraft server, etc), Urbit aspires to be a good platform on which to host them.

Urbit features:

  1. All input events (http request to an urbit-based api, signed message from another urbit, keystroke from console, etc) are transactions which change the OS state (or don’t, if they fail). As a result, it should be impossible for a transaction to fail halfway through and leave the urbit instance hosed.
  2. Exactly-once messaging between nodes. This is possible because nodes have persistent connections; disconnection is indistinguishable from long latency. This may sound minor, but it is a huge part of what makes urbit novel and (theoretically) stable and secure.
  3. Built-in identity and auth. An urbit instance can’t boot without an identity, which serves as username, network-routing address, and also as the public key with which all outgoing messages are encrypted. In practical terms, this means no urbit app or service needs to deal with logins or passwords or crypto.
  4. There are only 2^32 first-class identities, which makes urbit a de facto reputation network. This is to minimize malicious behavior; if an identity costs $5, and you can only make $2 from spamming before that identity is blacklisted, no one will spam.
  5. The urbit network is hierachically federated, and hence resistant to censorship. (Of course, this is a misfeature if you want to be able to censor people off of the networks you participate in)
  6. It’s not there yet, but the urbit kernel aspires to be so small and simple and formally-provably-correct that at some point it’s done. As in, done done – no features to add, no bugs to fix, done. A lot of the design decisions (some of which are wildly unperformant) make no sense unless you take this goal in to account. More on that here: https://urbit.org/blog/toward-a-frozen-operating-system

License to Share

Yes, tacky. Her Majesty’s GPL-enforcer.

I came across Drew DeVault’s essay on source code licenses, from a few years ago, and agreed with the first few lines:

I agreed with the first few lines of this essay:

I generally preferred the MIT license. I actually made fun of the “copyleft” GPL licenses, on the grounds that they are less free. 

Yes, so far so good.

… once I started using Linux as my daily driver, however, it took a while still for the importance of free software to set in. But this realization is inevitable, for a programmer immersed in Linux. It radically changes your perspective when all of the software you use guarantees these four freedoms. If I’m curious about how something works, I can usually be reading the code within a few seconds. I can find the author’s name and email in the git blame and shoot them some questions. And when I find a bug, I can fix it and send them a patch.

Okay, sure, don’t disagree. But then, the lede:

These days, on the rare occasion that I run into some proprietary software, this all grinds to a halt. It’s like miscounting the number of steps on your staircase in the dark. These moments drive the truth home: Free software is good. It’s starkly better than the alternative. And copyleft defends it.

Making the point clearer:

I’ve learned that the effort I sink into my work far outstrips the effort required to reuse my work. The collective effort of the free software community amounts to tens of millions of hours of work, which you can download at touch of a button, for free. If the people with their fingers on that button held these same ideals, we wouldn’t need the GPL.

The case being that we need the GPL because of human nature … or at least human society as it exists right now.

The GPL is the legal embodiment of this Golden Rule: in exchange for benefiting from my hard work, you just have to extend me the same courtesy. Its the unfortunate acknowledgement that we’ve created a society that incentivises people to forget the Golden Rule. I give people free software because I want them to reciprocate with the same. That’s really all the GPL does. Its restrictions just protect the four freedoms in derivative works. Anyone who can’t agree to this is looking to exploit your work for their gain – and definitely not yours.

As someone who’s oscillated between GPL & FSF and MIT/BSD, this is definitely something to chew on.

Cycles of threading

From this HN thread

I gotta say, as a programmer “of a certain age”, a lot of recent advances have an everything-old-is-new-again feel to me. When I first heard of “threads” in the 90s, the term specifically referred to a mechanism for intra-process concurrency that was “lightweight”, i.e. it didn’t have the heavy overhead of forking a new OS process. IIRC they weren’t even preemptively multitasked. Then preemptive “OS threads” became the new hotness and everything using cooperative threads was old and busted. Now a generation has passed and we have “virtual threads” or things like asyncio to solve the problems created by the thing that solved the problems of the thing before.

So now we’re in the position where it’s perfectly normal to run a program with several virtual threads running in a “real” thread in a Java virtual machine running inside a Docker container running on a VM instance in a hypervisor on some giant box somewhere. And if we’re all living in a simulation, then its’ probably turtles all the way down.

Flexibility vs consistency

The “tragic tradeoff” in programming languages:

I still remember a wonderful presentation by Damian Conway a number of years ago about all of the great ways Perl 6 could turn into whatever domain specific language you needed it to be. It was beautiful, I was awestruck. I’ve always enjoyed Perl as a language. But I walked out of that presentation thinking “That was so beautiful, and I don’t want it anywhere near my business.” Because the last thing I need is software written in a language I can’t hire anyone else to maintain.

At some level that’s what I think has happened to Perl in general. I never liked Python much, until I got forced to use it on a new team. Now I’m convinced that it has a really distinct advantage — there aren’t too many ways to write Python, so an experienced Python developer can figure out code pretty quickly. But Perl programs are frequently art pieces that take a lot of effort to truly grok.

From HN, “What happened to Perl 7“

Yield curves

Playing around with Wolfram Mathematica again for a bit:

Notebook is viewable here.