Fish shell project:

About two years ago, our head maintainer @ridiculousfish opened what quickly became our most-read pull request: #9512 - Rewrite it in Rust.

Now that we’ve released the beta of fish 4.0, containing 0% C++ and almost 100% pure Rust, let’s look back to see what we’ve learned, what went well, what could have gone better and what we can do now.

We’re writing this so others can learn from our experience, but it is our experience and not an exhaustive study. We hope that you’ll be able to follow along even if you have never written any rust, but experience with a roughly C++-shaped language should help.

“Rewrite it in Rust” (RIIR) is often a joke or unwelcome suggestion from uninvested bystanders. However, when it does happen it’s great to get a detailed first-hand retrospective like this to inform others considering something similar. Overall it seems like the rewrite was a success with a few of the usual missteps that come along with a rewrite.

Chimera Linux founder q66:

At the point of entering alpha, the cports tree had roughly 1000 templates, most of them in main. There was a single large desktop (GNOME) and a single major web browser (Firefox) and an assortment of other software.

At this point, the tree contains ~2800 templates, i.e. almost 3x more. We have all major desktop environments, all major browsers, and overall much larger collection of both small and large programs.

The repo was also at ~6000 commits at the time, by 11 authors; now it’s almost 20000 commits, by over 100 authors.

Significant under-the-hood improvements have been made in service management, our build infrastructure, the cbuild build system which is now significantly more powerful and has much better UX, global switch to the mimalloc allocator, stateless /var and progress towards stateless /etc, improvements in core userland, introduction of libdinitctl, introduction of sd-tools, and a lot more.

My favourite up and coming Linux distro continues to mature. I’ve been running it since the alpha release in June 2023. I’m now running it on three servers (the ones powering this website), as well as in WSL on my laptop (where I’m writing this post), and dual booting my desktop.

If you haven’t encountered Chimera Linux before, the project aims to build a Linux distribution that sheds some legacy baggage, and is smaller and easier to understand. To achieve this it combines the Linux kernel, LLVM toolchain, musl libc, FreeBSD userland, dinit init, apk package manager, and home grown cports package build tooling. There’s more details on the about page.

Julio Merino:

One reason for this choice is NetBSD’s build system. Once you look and get past the fact that it feels frozen in time since 2002, you realize it is still one of the most advanced build systems you can find for an OS. And it shows: the NetBSD build system allows you to build the full OS from scratch, on pretty much any host POSIX platform, while targeting any hardware architecture supported by NetBSD. All without root privileges.

Good insight into the NetBSD build system, and how to use it to cross-compile a custom image for a Raspberry Pi. In particular how it achieves unprivileged builds without tools like sudo or fakeroot is quite neat.

Chris Holdgraf:

My guiding principle for using BlueSky (or any platform or SaaS product for that matter) is to assume that it will go away in three years. It’ll either go bankrupt, get bought, or change its strategy to enshittify the product. You can make an argument that BlueSky has some technical protections against this [..] but I think the heuristic above is still the right one to follow.

So I’m going to try treating BlueSky as a temporary place to make connections or share ideas, but do my best to direct attention, deeper thoughts, “real” value to places that I have more control over.

I’ve been banging the own your identity drum for a long time now and this post contains a lot of sensible suggestions. The ultimate in owning you content and identity is self-hosting but this post contains suggestions that don’t require that level of complexity.

In other words: don’t build your castle in a kingdom that somebody else controls, because they can take it away from you. Instead, build a castle on defensible land, and leverage platforms to bring more ideas, people, value, etc to your castle.

This is similar to the IndieWeb POSSE concept: Publish (on your) Own Site, Syndicate Elsewhere. See also micro.blog.

Rather than treating BlueSky content as persistent (and thus referenceable in things like blog posts or papers), I’ll try rendering conversations into a static form before including them in my writing.

This is a good point, I almost got bit by this with my self-hosted Pleroma instance when it came time to retire it. I was able to work around it by creating a static archive of my content.

Rather than sharing BlueSky links in “learn more about me” slides etc, I’ll lead with links to my website.

Not that I do slides very often, but a short personal domain (wezm.net) has turned out handy for this.

Not everything needs to be persistent over long timelines!

This is the pragmatic choice, but I think people are far too willing to break links on the internet. With a bit of care, redirects and static archives can keep links up for years to come.

Simon ‘icefox’ Heath:

In case you missed it, there’s a whole new generation of low-level programming languages being created right now. Rust demonstrated vividly in 2016 that there is a massive unmet need in this space, and it has spawned a bunch of successor languages, though none of them have really hit the relative big-time like Rust has. I’m one of those programmers that has spent 20 years or so asking “can we PLEASE do low-level code in anything besides C and C++?” so I wanted to take an actual look at the languages I know about and do a bit of compare-and-contrast.

This is an opinionated take, and honestly not a particularly deep one, since I don’t know most of these languages and I don’t want to spend months researching each one. I’m also not gonna quibble about what is and is not low-level. I’m moving long-distance soon, and my brain needed something interesting and productive-feeling but not terribly deep, so I’m gonna spend a max of a day or two on each language. I’m gonna give a little bit of history but confine my opinions to the actual languages rather than the whole ecosystem and tooling around them, and just go down the list in chronological-ish order. While very important, tools are far more mutable and easier to change.

Exactly what it says on the tin. If you’d like a quick, opinionated survey of languages in the systems language space, this post makes for a great read. Aside from the commentary it also serves as a good reference of languages to check out of you’re looking for a language for lower-level work.