A personal blog on software development and systems engineering
While diagnosing a non-determinism Bazel issue at work, I had to compare the dynamic libraries used by two builds of the same binary. To do so, I used
ldd(1) and I had to refer to its manual page to understand details of the output I had never paid attention to before. What I saw will surprise you:
ldd can end up running the binary given to it, thus making it unsafe against untrusted binaries. Read on for the history I could find around this issue and what alternatives you have.
Well, that was unexpected. I recorded a couple of crappy videos in 5 minutes, posted them on a Twitter thread, and went viral with 8.8K likes at this point. I really could not have predicted that, given that I’ve been posting what-I-believe-is interesting content for years and… nothing, almost-zero interest. Now that things have cooled down, it’s time to stir the pot and elaborate on those thoughts a bit more rationally.
To summarize, the Twitter thread shows two videos: one of an old computer running Windows NT 3.51 and one of a new computer running Windows 11. In each video, I opened and closed a command prompt, File Explorer, Notepad, and Paint. You can clearly see how apps on the old computer open up instantly whereas apps on the new computer show significant lag as they load. I questioned how computers are actually getting better when trivial things like this have regressed. And boom, the likes and reshares started coming in. Obviously some people had issues with my claims, but there seems to be an overwhelming majority of people that agree we have a problem.
To open up, I’ll stand my ground: latency in modern computer interfaces, with modern OSes and modern applications, is terrible and getting worse. This applies to smartphones as well. At the same time, while UIs were much more responsible on computers of the past, those computers were also awful in many ways: new systems have changed our lives substantially. So, what gives?
A couple of posts ago, I described why I built custom email subscriptions for this blog. I briefly mentioned that there is new automation that scrapes the RSS feed and sends new post notifications to you all. Today, it’s time to look into how this all works and how this is based on a new persistent task queuing service in Rust. The queue handles tasks to periodically scrape the RSS feed and schedule emails, all with various quota enforcers and retry policies in place. Read on for the design requirements and constraints of the task queue, how the client and worker Rust APIs look like, and how this all can be made to work inside the Azure Functions serverless runtime for minimal deployment hassle and cost.
In MVC isn’t MVC, which hit the Hacker News front page overnight, Collin Donnell describes how the MVC design pattern that we use today isn’t really what was originally envisioned in 1979 by Tyrgve Reenskaug. This prompted me to think about how this architecture, if tweaked even further, maps pretty well to today’s designs of other kinds of programs, and I want to explore two cases in this post: web services and CLI apps.
Fellow readers! The radio silence for the last two months has an explanation. I’ve been busy creating a custom email subscription service for this blog, all so that you can be notified about new posts without the noise added by intermediaries. This feature is built into a little Rust web service that already offered analytics, page comments and more, and that can be potentially integrated into arbitrary static websites. Read on for what was involved, stay tuned for a deep dive on the internals, and… upfront apologies if this first email does the wrong thing!
Here at Snowflake, the Developer Productivity organization (DPE for short) is tackling some important problems we face as a company: namely, lengthening build times and complex development environments. A key strategy we are pursuing to resolve these is the migration of key build processes from CMake and Maven to Bazel.
We are still in the early stages of this migration and cannot yet share many details or a success story, but we can start explaining some of the issues we encounter as we work through this ambitious project.
Over the last couple of years, I have developed two small web services in Rust: one for EndBASIC and one for this blog. Those two web services contained significant copy/pasted helper code, which always bothered me because small bug fixes in one rarely propagated to the other. But because this only impacted two inconsequential side projects, the hinderance wasn’t a big deal.
Until now. I now face the need to write two more web services (details TBA), and duplicating those foundations twice more felt just wrong. So I spent the last couple of weeks pulling the common code out of the existing services into a… you guessed it… framework, which I have called III-IV ("three four" if you read it out loud) and am ready to announce.