Normies Learn Software Licensing

If you're a software person and at all plugged in to the world of video games, you might have watched in horror as Unity performed one of the most aggressive killing-of-the-golden-goose-s we have yet seen in the tech industry. Seeing people I follow online for their opinions on whether Armored Core 6 is good suddenly start talking about software licensing and the risks of closed-source threw me for a little bit of a loop. This crossover made me think about my own complicated feelings about software ownership as a concept.

I started out as a starry-eyed undergrad who was eager to have an ideology, where I bought in fully that "open source" is a necessary condition for a good piece of software to have. A kind of utopian way for people to write software for people.

After I graduated, I worked at an open-source vendor (not really motivated by that ideology, but it helped), where I started to suspect that it wasn't so clear. In fact, maybe open source is not the leveling force I thought it was. When Amazon of all organizations had a public spat about how their use of ElasticSearch was "the spirit of open source," it raised questions for me. It started to seem as though the people with the most capital are actually the ones who are most equipped to exploit "public good" software, rather than the underdog who needs a leg up.

VLDB just happened! And I have been going through some of the papers that caught my eye. As it turns out, this week is TUM week.

What Modern NVMe Storage Can Do, And How To Exploit It: High-Performance I/O for High-Performance Storage Engines

Paper.

I briefly met Viktor Leis at CIDR in 2019, and was very excited to tell him what an impression his paper How Good Are Query Optimizers, Really? had made on me, as far as giving me a base of intuition for how to think about query planning, which I had just started doing professionally. He told me that he was moving away from working on query planning to working on SSDs, which he thought deserved more attention than they had gotten. Luckily for me, my own professional journey of working on query planning to now working on storage has trailed his by a couple years, and this paper does a good job of giving me the same kind of intuition that one did (I'm less familiar with Gabriel Haas's work, but if he has more like this, I'll keep an eye out).

IN or OR

There was a very nice blog post from OtterTune [1] recently, digging into some of the quirks of the way Postgres executes a particular query:

Query best practices: When should you use the IN instead of the OR operator? | OtterTune

OtterTune uses AI to automate database tuning and solves configuration problems to optimize PostgreSQL & MySQL performance and lowers costs.

I really liked this post, not just because it's well written. I liked it because it highlights the uncomfortable truth at the heart of declarative query planning.

One lens I've found satisfying for "what is a query planner" is that it's a tool for "approximating domain knowledge."

By that I mean, someone who knows Python could probably write a pretty solid program to generate an end-of-month report for an airline company. But to write a good version of that program probably requires both knowledge of the distribution of flights, passengers, and the internal IDs used by the company. Such things (how many of each there are, how they're related to each other, etc.) influence lots of programming decisions, like how to order lookups or what data structures to use in various scenarios.

To put it simply, I'd say writing a program for this kind of problem requires:

1. general-purpose programming knowledge, and

2. domain-specific knowledge for the task at hand.

What if you had an isolation anomaly with yourself?

If you're receiving this as an email, thank you for entrusting me with your email address, I know that's a big ask and I am honoured to be gracing your inbox. If you're seeing this via RSS or just got linked to it, and thus didn't give me your email address, what are you, a coward?

Welcome to Null Bitmap, my newsletter. Not "newsletter" as in "a letter about things that are new," but "newsletter" as in, I don't know. The form factor is that it's an email, primarily, I suppose.

For this initial issue of Null Bitmap, I figured I'd start off with a classic, spooky database topic: The Halloween Problem [2].