Full Width 
FOCUS MODE
Shortcuts 
Sign Up 
Log In 
Articles 
Reading List More from David Heinemeier Hansson
Omarchy 2.0 was released on Linux's 34th birthday as a gift to perhaps the greatest open-source project the world has ever known. Not only does Linux run 95% of all servers on the web, billions of devices as an embedded OS, but it also turns out to be an incredible desktop environment! It's crazy that it took me more than thirty years to realize this, but while I spent time in Apple's walled garden, the free software alternative simply grew better, stronger, and faster. The Linux of 2025 is not the Linux of the 90s or the 00s or even the 10s. It's shockingly more polished, capable, and beautiful. It's been an absolute honor to celebrate Linux with the making of Omarchy, the new Linux distribution that I've spent the last few months building on top of Arch and Hyprland. What began as a post-install script has turned into a full-blown ISO, dedicated package repository, and flourishing community of thousands of enthusiasts all collaborating on making it better. It's been improving rapidly with over twenty releases since the premiere in late June, but this Version 2.0 update is the biggest one yet. If you've been curious about giving Linux a try, you're not afraid of an operating system that asks you to level up and learn a little, and you want to see what a totally different computing experience can look and feel like, I invite you to give it a go. Here's a full tour of Omarchy 2.0.
The Danish flag is everywhere in Denmark. It's at the airport when parents greet their kids coming back from holiday. It's on the birthday cake when you invite people over. It's swinging from the flagpoles in house after house, especially in the countryside. It's on the buses on the monarch's birthday. It's everywhere and all the time. I love it. I love that the Danes are so proud of their country that the flag is the most common symbol for celebrating any momentous occasion. Even just returning from a trip! Because being a Dane means something to the Danish. It's a unique identity, separate from everyone else in the world. It's local, it's close, it's personal. It's not like that everywhere. It seems like the American flag, for example, has now been solidly right-wing coded. You don't see many progressives putting up big flags in their backyards anymore. And you certainly don't see them putting American flags on their birthday cakes, like the Danes. What a shame to feel such shame about the country you live in. Don't get me wrong, the Danes don't all love everything going on in Denmark either. It's a national sport to rag on politicians. To complain about municipal services. To want things to be better. Perfectly healthy for a country to wish to see improvement. But once that search for better tips over into disliking or outright hating the national symbols, you're off the rails, and much less likely to actually fix anything. Don't even get me started with the UK. It seems flying the English flag is now as transgressive as posting you're not a big fan of mass immigration on Facebook. And given that the latter is already likely to land you in trouble with the increasingly authoritarian state, it seems likely that the former might soon too. National pride is a cornerstone of building a high-trust society. It flows from a strong national identity that defines clear norms, values, and priorities. What better reason than that to raise the flag!
You can just change things! That's the power of open source. But for a lot of people, it might seem like a theoretical power. Can you really change, say, Chrome? Well, yes! We've made a micro fork of Chromium for Omarchy (our new 37signals Linux distribution). Just to add one feature needed for live theming. And now it's released as a package anyone can install on any flavor of Arch using the AUR (Arch User Repository). We got it all done in just four days. From idea, to solicitation, to successful patch, to release, to incorporation. And now it'll be part of the next release of Omarchy. There are no speed limits in open source. Nobody to ask for permission. You have the code, so you can make the change. All you need is skill and will (and maybe, if you need someone else to do it for you, a $5,000 incentive 😄).
One day, I got a chance. It just seemed to show up. It acted like it knew me, as if it wanted something. This is how Kobi Yamada's book What do you do with a chance? starts. I've been reading that beautiful book to the boys at bedtime since it came out in 2018. It continues: It fluttered around me. It brushed up against me. It circled me as if it wanted me to grab it. What a mesmerizing mental image of a chance, fluttering about. What do you do with a chance? is a great book exactly because it's not just for the boys, but for me too. A poetic reminder of what being open to chance looks like, and what to do when it shows up. Right now, Omarchy feels like that chance. Like Linux fluttered into my hands and said "let's take a trip to the moon". I joked on X that perhaps it was the new creatine routine I picked up from Pieter Levels, but I only started that a few days ago, so I really do think it's actually Linux! This exhilaration of The Chance reminds me of the 1986 cult classic Highlander. There's a fantastic montage in the middle where Sean Connery is teaching Christopher Lambert to fight for the prize of immortality, and in it, he talks about The Quickening. Feeling the stag, feeling the opportunity. That's the feeling I have when I wake up in the morning at the moment: The Quickening. There's something so exciting here, so energizing, that I simply must get to the keyboard and chase wherever it flutters to.
We're going all-in on Omarchy at 37signals. Over the next three years, as the regular churn of hardware invites it, we're switching everyone on our Ops and Ruby programming teams to our own Arch-derived Linux distribution (and of course sharing all the improvements we make along the way with everyone else on Omarchy!). It's funny how nobody bats an eye when the company mandate is to use Macs or Windows, but when the prescription is Linux, it's suddenly surprising. It really shouldn't be. Your ability to control your own destiny with Linux is far superior to what you'll get from a closed-source, commercial operating system. Of course it is! The code is literally all there! True, you might face more challenges, and there won't be a vendor to call (unless you hop into the Enterprise Linux camp, which doesn't appeal to me either). But I've never given a damn about that. I started using Ruby to build Basecamp when we could barely fill a room in American with professional Ruby programmers. This is what we do here! This also means giving up on MacBooks and choosing Framework laptops as the new standard-issue equipment. Along with desktop machines from Framework and Beelink both. PC hardware has gotten incredibly good over the last few years, as AMD in particular has managed to extract many of the same processor improvements from TSMC, as Apple did so well with the M series. At least in terms of performance. Again, true, there is still a gap on the efficiency front. Nobody can currently beat Apple on the wattage-to-power ratio (but the gap is fast closing!). So battery life on Linux using Framework is currently a bit less. I get about 6 hours of mixed use from my Framework 13, so whenever I suspect that might be a problem, I bring a small 20K mAh Anker battery in the bag, and now I have double the capacity. A small concession on a rare occasion, but nothing like the performance AND battery deficit we willingly endured for decades on the Mac before Apple switched to their own chips. Because we wanted to run OSX. It was worth sacrifice a few other concerns for. Just like Linux is today. On the flip side, we'll get a massive boost in productivity from being able to run our Ruby on Rails test suites locally much faster. For our HEY application, even the fastest Mac, an M4 Max, is almost twice as slow as a Framework Desktop machine running Linux, which can do Docker natively. It's an exciting new adventure for us. Omarchy is already by far-and-away my favorite computing environment. Right up there in joy and wonder with the old Amiga days or early OSX. It's been a blast learning that so many other early-adopters have found the same feeling. Very reminiscent of the excitement in the early Ruby days. Knowing you'd found something super special that wasn't yet widely distributed (but poised to be). I spoke about all of this with Kimberly on a bonus episode of The REWORK Podcast. Give it a listen if you're curious about the why, the how, and the inevitable objections.
More in programming
The first in a series of posts about doing things the right way
A deep dive into the Action Cache, the CAS, and the security issues that arise from using Bazel with a remote cache but without remote execution
(I present to you my stream of consciousness on the topic of casing as it applies to the web platform.) I’m reading about the new command and commandfor attributes — which I’m super excited about, declarative behavior invocation in HTML? YES PLEASE!! — and one thing that strikes me is the casing in these APIs. For example, the command attribute has a variety of values in HTML which correspond to APIs in JavaScript. The show-popover attribute value maps to .showPopover() in JavaScript. hide-popover maps to .hidePopover(), etc. So what we have is: lowercase in attribute names e.g. commandfor="..." kebab-case in attribute values e.g. show-popover camelCase for JS counterparts e.g. showPopover() After thinking about this a little more, I remember that HTML attributes names are case insensitive, so the browser will normalize them to lowercase during parsing. Given that, I suppose you could write commandFor="..." but it’s effectively the same. Ok, lowercase attribute names in HTML makes sense. The related popover attributes follow the same convention: popovertarget popovertargetaction And there are many other attribute names in HTML that are lowercase, e.g.: maxlength novalidate contenteditable autocomplete formenctype So that all makes sense. But wait, there are some attribute names with hyphens in them, like aria-label="..." and data-value="...". So why isn’t it command-for="..."? Well, upon further reflection, I suppose those attributes were named that way for extensibility’s sake: they are essentially wildcard attributes that represent a family of attributes that are all under the same namespace: aria-* and data-*. But wait, isn’t that an argument for doing popover-target and popover-target-action? Or command and command-for? But wait (I keep saying that) there are kebab-case attribute names in HTML — like http-equiv on the <meta> tag, or accept-charset on the form tag — but those seem more like legacy exceptions. It seems like the only answer here is: there is no rule. Naming is driven by convention and decisions are made on a case-by-case basis. But if I had to summarize, it would probably be that the default casing for new APIs tends to follow the rules I outlined at the start (and what’s reflected in the new command APIs): lowercase for HTML attributes names kebab-case for HTML attribute values camelCase for JS counterparts Let’s not even get into SVG attribute names We need one of those “bless this mess” signs that we can hang over the World Wide Web. Email · Mastodon · Bluesky
Greetings everyone! You might have noticed that it's September and I don't have the next version of Logic for Programmers ready. As penance, here's ten free copies of the book. So a few months ago I wrote a newsletter about how we use nondeterminism in formal methods. The overarching idea: Nondeterminism is when multiple paths are possible from a starting state. A system preserves a property if it holds on all possible paths. If even one path violates the property, then we have a bug. An intuitive model of this is that for this is that when faced with a nondeterministic choice, the system always makes the worst possible choice. This is sometimes called demonic nondeterminism and is favored in formal methods because we are paranoid to a fault. The opposite would be angelic nondeterminism, where the system always makes the best possible choice. A property then holds if any possible path satisfies that property.1 This is not as common in FM, but it still has its uses! "Players can access the secret level" or "We can always shut down the computer" are reachability properties, that something is possible even if not actually done. In broader computer science research, I'd say that angelic nondeterminism is more popular, due to its widespread use in complexity analysis and programming languages. Complexity Analysis P is the set of all "decision problems" (basically, boolean functions) can be solved in polynomial time: there's an algorithm that's worst-case in O(n), O(n²), O(n³), etc.2 NP is the set of all problems that can be solved in polynomial time by an algorithm with angelic nondeterminism.3 For example, the question "does list l contain x" can be solved in O(1) time by a nondeterministic algorithm: fun is_member(l: List[T], x: T): bool { if l == [] {return false}; guess i in 0..<(len(l)-1); return l[i] == x; } Say call is_member([a, b, c, d], c). The best possible choice would be to guess i = 2, which would correctly return true. Now call is_member([a, b], d). No matter what we guess, the algorithm correctly returns false. and just return false. Ergo, O(1). NP stands for "Nondeterministic Polynomial". (And I just now realized something pretty cool: you can say that P is the set of all problems solvable in polynomial time under demonic nondeterminism, which is a nice parallel between the two classes.) Computer scientists have proven that angelic nondeterminism doesn't give us any more "power": there are no problems solvable with AN that aren't also solvable deterministically. The big question is whether AN is more efficient: it is widely believed, but not proven, that there are problems in NP but not in P. Most famously, "Is there any variable assignment that makes this boolean formula true?" A polynomial AN algorithm is again easy: fun SAT(f(x1, x2, …: bool): bool): bool { N = num_params(f) for i in 1..=num_params(f) { guess x_i in {true, false} } return f(x_1, x_2, …) } The best deterministic algorithms we have to solve the same problem are worst-case exponential with the number of boolean parameters. This a real frustrating problem because real computers don't have angelic nondeterminism, so problems like SAT remain hard. We can solve most "well-behaved" instances of the problem in reasonable time, but the worst-case instances get intractable real fast. Means of Abstraction We can directly turn an AN algorithm into a (possibly much slower) deterministic algorithm, such as by backtracking. This makes AN a pretty good abstraction over what an algorithm is doing. Does the regex (a+b)\1+ match "abaabaabaab"? Yes, if the regex engine nondeterministically guesses that it needs to start at the third letter and make the group aab. How does my PL's regex implementation find that match? I dunno, backtracking or NFA construction or something, I don't need to know the deterministic specifics in order to use the nondeterministic abstraction. Neel Krishnaswami has a great definition of 'declarative language': "any language with a semantics has some nontrivial existential quantifiers in it". I'm not sure if this is identical to saying "a language with an angelic nondeterministic abstraction", but they must be pretty close, and all of his examples match: SQL's selects and joins Parsing DSLs Logic programming's unification Constraint solving On top of that I'd add CSS selectors and planner's actions; all nondeterministic abstractions over a deterministic implementation. He also says that the things programmers hate most in declarative languages are features that "that expose the operational model": constraint solver search strategies, Prolog cuts, regex backreferences, etc. Which again matches my experiences with angelic nondeterminism: I dread features that force me to understand the deterministic implementation. But they're necessary, since P probably != NP and so we need to worry about operational optimizations. Eldritch Nondeterminism If you need to know the ratio of good/bad paths, the number of good paths, or probability, or anything more than "there is a good path" or "there is a bad path", you are beyond the reach of heaven or hell. Angelic and demonic nondeterminism are duals: angelic returns "yes" if some choice: correct and demonic returns "no" if !all choice: correct, which is the same as some choice: !correct. ↩ Pet peeve about Big-O notation: O(n²) is the set of all algorithms that, for sufficiently large problem sizes, grow no faster that quadratically. "Bubblesort has O(n²) complexity" should be written Bubblesort in O(n²), not Bubblesort = O(n²). ↩ To be precise, solvable in polynomial time by a Nondeterministic Turing Machine, a very particular model of computation. We can broadly talk about P and NP without framing everything in terms of Turing machines, but some details of complexity classes (like the existence "weak NP-hardness") kinda need Turing machines to make sense. ↩
The 2025 edition of the TokyoDev Developer Survey is now live! If you’re a software developer living in Japan, please take a few minutes to participate. All questions are optional, and it should take less than 10 minutes to complete. The survey will remain open until September 30th. Last year, we received over 800 responses. Highlights included: Median compensation remained stable. The pay gap between international and Japanese companies narrowed to 47%. Fewer respondents had the option to work fully remotely. For 2025, we’ve added several new questions, including a dedicated section on one of the most talked-about topics in development today: AI. The survey is completely anonymous, and only aggregated results will be shared—never personally identifiable information. The more responses we get, the deeper and more meaningful our insights will be. Please help by taking the survey and sharing it with your peers!
