Why Linux wound up with system package managers

Chris Siebenmann wrote a nice article explaining some of the early reasoning behind Linux package managers:

The abstract way to describe why is to say that Linux distributions had to assemble a whole thing from separate pieces; the kernel came from one place, libc from another, coreutils from a third, and so on. The concrete version is to think about what problems you’d have without a package manager. Suppose that you assembled a directory tree of all of the source code of the kernel, libc, coreutils, GCC, and so on. Now you need to build all of these things (or rebuild, let’s ignore bootstrapping for the moment).

Building everything is complicated partly because everything goes about it differently. The kernel has its own configuration and build system, a variety of things use autoconf but not necessarily with the same set of options to control things like features, GCC has a multi-stage build process, Perl has its own configuration and bootstrapping process, X is frankly weird and vaguely terrifying, and so on. Then not everyone uses ‘make install’ to actually install their software, so you have another set of variations for all of this.

This is good, but it does miss the biggest reason package managers exist: dependency hell. In short, imagine you’re installing a Linux system in the late 90’s or early 2000’s. You’d like to play music from your CD player, so you download a package and try to compile it, but realize that it’s missing a library. So you download the missing library and realize that to compile the library, you’ll have to upgrade an existing library in your system, so you upgrade, compile the library, and compile the music player application. Great, now you’ve got your music playing in the background, but now your web browser won’t launch because it depended on a specific version of the library you upgraded.

I’ve had this happen, and it was maddening. Having a centralized place that manages all the dependencies of a system was a godsend.

On another note, Chris' blog is excellent, I’ve been following it for a while. But the styling is so minimal it almost looks like there’s no css at all. In fact, I had to right-click and view source to verify. Turns out, Chris is using his own publishing system he calls “Dinky Wiki”, which I quite like.

LLMs have made simple software trivial

I was out for a run today and I had an idea for an app. I busted out my own app, Quick Notes, and dictated what I wanted this app to do in detail. When I got home, I created a new project in Xcode, I committed it to GitHub, and then I gave Claude Code on the web those dictated notes and asked it to build that app.

About two minutes later, it was done…and it had a build error. 😅

But it was a simple fix, I fixed it, and the app was running on my phone. And you know what? It worked. The UI wasn’t perfect, but it was damn close. And I already had a product that achieved the goal I set out to achieve. All in all, I’d say it was about 10 minutes from idea to functioning MVP (and half of that was finishing my run).

If we could figure out how to do this without consuming the power equivalent of New England in the winter, I’d be all for it.

Jump to Post

How the hell are you supposed to have a career in tech in 2026? - Anil Dash

What you can control, though, are small iterative things that make you feel better on a human scale, in little ways, when you can. You can help yourself maintain perspective, and you can do the same for those around you who share your values, and who care about the same personal or professional goals that you do.

A lot of us still care about things like the potential for technology to help people, or still believe in the idealistic and positive goals that got us into our careers in the first place. We weren’t wrong, or naive, or foolish to aspire to those goals simply because some bad actors sought to undermine them. And it’s okay to feel frustrated or scared in a time when it seems to many like those goals could be further away than they’ve been in a long time.

I do hope, though, that people can see that, by sticking together, and focusing on the things that are within our reach, things can begin to change. All it takes is remembering that the power in tech truly rests with all the people who actually make things, not with the loudmouths at the top who try to tear things down.

Lovely essay by Anil Dash, and besides his abstractions he does include some very actionable advice. Like building expertise and investing in relationships.

Jump to Post

Accepting friction - listening without a streaming subscription

Kyle Raymond Fitzpatrick remembers the “homework” we used to do as music fans – reading reviews, seeking out the opinions of music critics – “all in the service of purchasing music.” Now there’s a pre-made playlist for every moment; we no longer need to spend hours curating playlists for ourselves if we want a different mix for working out, for writing, for cooking dinner. Streaming saves us a lot of work… but, ironically, people like things better when we have to work to find them. Being served music instead of seeking it out for ourselves makes us into consumers moreso than listeners. Fitzpatrick continues: “This passivity makes us as audiences, as people, less engaged with what we’re doing.”

Being more mindful, present, and engaged with whatever I’m doing is in line with this year’s theme of Getting Real1. I’ve been thinking more about my personal music collection, and how important music used to be to me. I remember doing a presentation for one of my clases on how impactful music can be back in 8th grade. I’ve even started building up a vinyl collection, and have really enjoyed the ritual and intentionality of spending time “listening to music”.

I’m not ready to cancel my Apple Music streaming account, my entire family uses it. But, I think it might be fun to sign out on my MacBook and rebuild my personal, curated, and beautifully organized mp3 collection again.

Jump to Post


  1. Not to be confused with the Basecamp book of the same name. ↩︎

Lifting the Fog

To say that 2025 has been a hectic year would be an understatement. Even in my personal corner of the world, my work life has been chaotic, far more than I would have liked. I’ve lost one team member, brought on a new one, weathered changes and challenges at the company level, and overall become far more reactive than proactive than I’d like. Feels like I’ve been trying to steer a ship through the fog, with only the dimmest lighthouse to guide the way.

Part of that is my own confusion about where I wanted my professional life to go. Since being promoted from Staff Engineer to Engineering Manager (and seeing my old team dismantled and handed over to foreign contractors), I’ve been unsure about how much time I wanted to dedicate to maintaining my technical skills. Not only that, but the additional uncertainty present with the proliferation of AI tools and massive layoffs in tech has also caused me to question my place in the industry for the next part of my career.

Am I still an engineer? Was I ever? Am I now just a manager?

I think the answer for the foreseeable future is going to be both… and more.

I’ve been what I would describe as a competent programmer. My history with Objective-C, and experience with Python and other languages along the way, has given me a good foundation for understanding the concepts and syntax needed to build applications. However, most of my professional experience has been focused on scripting and DevOps-centric tasks. Building pipelines, setting up system automations, etc. From time to time, I’ve dabbled in other languages, but I haven’t gone all in on any of them. I’d like to change that. One of the things I’m going to focus on in the new year is learning Rust. I’m not one for making resolutions; instead, I create yearly themes, with a few ideal outcomes for the year. I’m not “resolving” to learn Rust this year, but I am focusing on it as part of my overall theme.

As a sysadmin, and later a DevOps engineer, I’ve always focused on deep technical expertise. That meant understanding filesystems at the kernel level, tracing TCP packets through the system, and occasionally spelunking through the Linux kernel source code. Over the past few years of cloud automation, though, a lot of that has fallen to the wayside to make way for learning the AWS APIs. I’ve missed the low-level operating system work. I haven’t had to manage a RAID array in nearly 10 years, nor have I had to track down why a deleted file still has an open handle. However, I do now have an opportunity to dig back into some hard low-level problems, and I’m looking forward to seeing what new skills I can learn.

Taking on a management role has been one of the most challenging things I’ve done in my career. Not because of my plans for where I’d like the systems we’re responsible for to go, but because of all the other interpersonal tasks that are now my responsibility. Last year I hired the first person on my team, and this year I had to let a person on my team go. Both decisions were difficult, and the second took far longer than it should have. That was a lesson learned, one that cost me months of productivity. There are other management tasks that are difficult, like deciding on metrics to gather, how to build reports that are worthwhile, and how best to accurately reflect the value of our team. Management has a lot of abstractions, time-consuming tasks that attempt to convey an idea, either to my team, to my boss, or to the rest of the company. Difficult, but interesting.

Thinking through these aspects of my career informs my position on AI. I’ve gotten to where I am by prioritizing expertise, technical knowledge, quick learning, and being able to get things done. What I’ve noticed using AI occasionally over the past couple of years is that it makes me intellectually lazy. When faced with a difficult problem, my first impulse isn’t to dig into the problem and discern a solution, it’s to hand the problem over to AI and see what it has to say. This unhealthy habit undermines the very thing my career has been built on, thinking clearly. When I offload a task to AI I’m offloading my own thinking, and that’s something I just can’t do. On top of that, AI has very real environmental problems and a questionable financial future, at least in its current form. I understand the usefulness of AI for many tasks, but for me, personally, I can’t risk my career on outsourcing my brain.

So, that’s 800 words or so on why I’m thinking my next yearly theme should be “The Year of Thinking Clearly”. My focus will be on building my expertise, communicating effectively, and, as an essential part of having a clear head, building and maintaining a consistent and challenging exercise program. Healthy body, healthy mind. I’m looking forward to 2026. I think it could be one of my best years ever.