lla by Mohamed Achaq:

At its heart, lla is more than just another ls replacement – it’s a thoughtfully crafted terminal file explorer that transforms how developers interact with their filesystem. Built with Rust’s performance capabilities and designed with user experience in mind, lla strikes a careful balance between power and simplicity.

Our journey began with a simple observation: the daily ritual of file management often requires juggling multiple terminal commands to gather the information we need. Inspired by Raycast’s revolutionary approach to application management on macOS, we envisioned a unified solution that could bring the same level of integration and convenience to the terminal.

The result is lla – a tool that starts with familiar file listing capabilities but expands into a comprehensive file management platform through its extensible plugin system.

lla joins a slew of other alternatives to ls implemented in Rust, such as exa (unmaintained), eza (exa fork), and lsd. Most of these improve ls with more human friendly default output and additional features like icons and built-in tree views.

lla takes the ideas of these other tools and turns ls into a full blown application with features including:

• Long, tree, table, and grid views
• Git Integration
• Timeline view
• Storage analysis
• Smart search
• A plugin system

lla publishes releases for Linux and macOS, which suggests it should work on most POSIX systems. In contrast, lsd and eza also support Windows.

Personally I have ls aliased to lsd. I used exa for a long time, but switched to lsd when exa became unmaintained. I like that the lsd command line interface is pretty true to ls, which keeps my decades of muscle memory happy.

Manuel Rego Casasnovas:

As many of you already know, Igalia took over the maintenance of the Servo project in January 2023. We’ve been working hard on bringing the project back to life again, and this blog post is a summary of our achievements so far.

Nothing sums it up better than this chart:

I sometimes see people wishing there was a browser that was independent of advertising companies and big tech, implemented in a language that doesn’t result in a constant stream of CVEs. Servo could be that. The project exists, and is already a long way along. It just needs the support of more people and organisations. They’re aiming for US$10,000 per month and are currently sitting at US$4291. Mozilla won’t let us fund Firefox, but it is easy to donate to Servo, which I’m doing each month.

Antranig Vartanian:

Initially, when I heard about freebsd-rustdate I was very skeptical. I have a fear of “Written in <new hip language>”. I thought, however, I’ll wait, and when the time comes, I will try and see how it works.

For the last couple of days I’ve been updating hosts and jails for my customers and my company, and one of the best resources I found was the FreeBSD Update page on FreeBSD’s Wiki, specially the “ freebsd-update Reverse Proxy Cache” section. It has saved me hours when updating the hosts. For some hosts we even did an NFS mount of /var/db/freebsd-update/files directory.

But when it came to upgrading the jails, I realized that this is going to take a very long time. Each host has at least 15 jails, up to 50. There’s a host which has 100+ jails.

I arrived to my parent’s house, installed freebsd-rustdate on a host, and tested it on a single jail. Here is my initial reaction:

holy fuck freebsd-rustdate is fucking fast

freebsd-rustdate by Matthew Fuller is a compatible implementation of the freebsd-update tool used to update the base system of a FreeBSD installation. As the name suggests it’s implemented in Rust, in contrast to freebsd-update, which is implemented in shell script.

The freebsd-rustdate website includes a lot of information about the motivation for the tool, how it achieves its speed, and some differences from freebsd-update. Picking one example from the speed page:

OK, let’s get serious now. Add /usr/src into the mix. Again, going from 13.2-RELEASE to 14.0-RELEASE-p10, but now we have to touch the filesystem a lot more. North of 90k paths.

freebsd-update:

• -r 14.0-RELEASE upgrade takes a painful 5:51.
• install is a staggering 24:38.
• As above, these numbers are for 14.0-RELEASE-p9; it’s close enough.

freebsd-rustdate:

• upgrade -r 14.0-RELEASE takes 5 seconds.
• install -a takes 1:41.

Ash Wolf:

I’m a bit of a retro tech enjoyer, but I’m also pretty bad at it – I don’t have the space or the motivation to try and acquire actual old computers. Playing with 86Box/PCem is pretty fun, but it’s not quite the same.

So, instead, I make do with what I have. And the most ridiculous x86 machine I own is the Asus Eee PC 1000H, a netbook that I got in 2008 when that category was still new and exciting. It’s borderline useless nowadays (it can’t even run most up-to-date Linux distros due to its lack of x86_64 support), so sticking weird and anachronistic OSes on it is one way to keep it relevant!

I’d like to write a full-fledged blog post about these adventures at some point, but for now I’m going to focus on one particular side quest: getting acceptable video output out of the 1000H when it’s running Windows 3.11 for Workgroups.

Strap in this is a long one, but as with most technical deep dives into software and hardware of yesteryear it’s fascinating. Kudos to Ash for persevering with this project, making some sense of the situation, and finding some solutions to the issue. Extra kudos for writing it all up for us to enjoy—complete with screenshots and a nice site design.

Diana MacDonald:

What does it look like to retire a web project? I don’t hear about project endings as much as project beginnings. Even then, among endings I mostly hear about failures. People tend to share stories of the aftermath of train wrecks more than quiet, satisfied conclusions. So I wanted to contribute my little story of retiring a silly pet project: Label Your Icons.

I get a mention in this post, which covers a bunch of considerations for winding down a website without breaking links on the internet. There’s also a bunch of tips for making maintenance of side projects easier.

Personally I try to archive a site and use redirects where possible. Most recently I did this with decentralised.social, where I replaced a Pleroma instance with static HTML.

I needed to minimise the amount of effort required to maintain the site. Static sites are a lot easier than dynamic sites to update over time. Buildless projects are a lot easier to keep running than projects that use complex build systems.

You really can’t beat a static HTML and CSS. We’re spoiled for choice with static site generators nowadays too. If you pick your static site compiler carefully it’s likely to be very low maintenance. My personal favourite is Zola, which is just a single binary—no runtime or dependencies to manage.