I’ve said before that wlroots is a “batteries not included” kind of library, and one of the places where that is most apparent is with our approach to input handling. We implemented a very hands-off design for input, in order to support many use-cases: desktop input, phones with and without USB-OTG HIDs plugged in, multiple mice bound to a single cursor, multiple keyboards per seat, simulated input from fake input devices, on-screen keyboards, input which is processed by the compositor but not sent to clients… we support all of these use-cases and even more. However, the drawback of our powerful design is that it’s confusing. Very confusing.
The single most important quality in a piece of software is simplicity. It’s more important than doing the task you set out to achieve. It’s more important than performance. The reason is straightforward: if your solution is not simple, it will not be correct or fast.
git 2.18.0 has been released, and with it my first contribution to git has shipped! My patch was for a git feature which remains disappointingly obscure: git send-email. I want to introduce my readers to this feature and speak to the benefits of using an email-driven git workflow - the workflow git was originally designed for.
Let’s Encrypt makes TLS much easier for pretty much everyone, but can still be annoying to use. It took me a while to smooth over the cracks in my Let’s Encrypt configuration across my (large) fleet of different TLS-enabled services. I wanted to take a quick moment to share setup with you.
I’m not terribly concerned about Microsoft’s acquisition of GitHub, but I don’t fault those who are worried. I’ve been working on my alternative platform, sr.ht, for quite a while. I’m not about to leave GitHub because of Microsoft alone. I do have some political disagreements with GitHub and Microsoft, but those are also not the main reason that I’m building sr.ht. I simply think I can do it better. If my approach aligns with your needs, then sr.ht may be the platform for you.
Today’s is another blog post which has been on my to-write list for a while. I have hesitated a bit to write about this, because I’m certain that my approach isn’t perfect. I think it’s pretty good, though, and people who work with me in FOSS agreed after a quick survey. So! Let’s at least put it out there and discuss it.
Quick blog post today to introduce a new tool I wrote: koio. This is a small tool which takes a list of files and embeds them in a C file. A library provides an fopen shim which checks the list of embedded files before resorting to the real filesystem.
For a little over a year, I’ve been working with a bunch of talented C developers to build a replacement for the wlc library. The result is wlroots, and we’re still working on completing it and updating our software to use it. The conventional wisdom suggests that rewriting your code from scratch is almost never the right idea. So why did we do it, and how is it working out? I have spoken a little about this in the past, but we’ll answer this question in detail today.
A man page generator is one of those tools that I’ve said I would write for a long time, being displeased with most of the other options. For a while I used asciidoc, but was never fond of it. There are a few things I want to see in a man page generator:
During the KDE sprint in Berlin, Roman Gilg leaned over to me and asked if I knew how to redirect the stderr of an already-running process to a file. I Googled it and found underwhelming answers using strace and trying to decipher the output by reading the write syscalls. Instead, I thought a gdb based approach would work better, and after putting the pieces together Roman insisted I wrote a blog post on the topic.