A huge amount of thoughtful, often unpaid work goes into the Linux desktop. I think the people doing that work face a frustrating problem: making an interface feel good takes more effort than it should.

People who work across design and engineering tend to notice when software asks you to learn too many concepts or remember too many exceptions. Making it simpler means deciding which conventions to follow, which behaviors to change, and what to leave out. Every extra layer adds decisions to revisit later.

On Linux, you inherit those layers on day one. There’s GTK and Qt, different desktop environments and window managers, distro-specific choices, and old behavior people still depend on. Conventions change depending on where an app runs. Each choice has a reason behind it, but together they make even small design decisions hard to settle.

I can see why someone who cares about these details would choose to build for the web or mobile. Those platforms have their own problems, but a small team can usually control more of the experience, ship it, and see whether the changes help. On Linux, polishing one corner can expose several more that also need work.

My suspicion is that this makes it harder to keep people working on polish. If every improvement means another round of compatibility work, it’s tempting to build somewhere your effort goes further. Meanwhile, keeping Linux apps working across all those environments takes time that could have gone into making them easier to use.

I want to trust that what I learn in one Linux app will carry over to the next. That a familiar button will behave the way I expect. Getting there means making consistent interfaces easier to build and maintain, within the time contributors actually have.

I’m Han, a software engineer who mostly works with TypeScript and occasionally Rust. I enjoy building useful, focused software and learning from the small decisions that make products feel reliable.

This blog is where I’ll share notes from that work ideas I’m exploring, lessons from projects, technical walkthroughs, and thoughts on building software with care.

More soon.