Alex Korban:

I was recently on a project where I chose to use React and TypeScript as part of the tech stack because of the existing skillset of my team. I myself managed to avoid both React and TypeScript until this year. So when I finally used them on a real project, I was looking at them as an experienced Elm & Elixir developer, coming from small niche ecosystems into the din of the real world. I think that’s an interesting perspective to share.

Reports like this based on real world experience are indeed often interesting. They can expose both positive and negative aspects of an ecosystem that go unnoticed if you’re already deeply invested, which can help drive improvements on both sides of the fence.

Perhaps unsurprising due to having already self-selected a preference for Elm, Alex found the TypeScript and React experience a bit underwhelming—although not only for technical reasons.

Louie Mantia lamenting the lack of standard UI in software these days:

Dan Counsell [on Mastodon]:

Can we please have the macOS X Lion UI back? 😍

Yes, I would also like that. I would welcome any standard UI that gives us back some tools we lost.

There’s a refined clarity to this version of Aqua. It evolved gracefully to this point, where every element was distinctly different and yet cohesive. Consider the search field alone. Now, search fields have the same appearance of every other field: squared. The pill shape distinguished itself. Removing that characteristic introduced a level of ambiguity that is unnecessary. The same can be said for so much in modern visual design (or lack thereof).

There really is a clarity to those controls. They have decent contrast, depth is used to help make it clear they are interactive, and there’s even some colour.

It’s a shame that the idea of standard UI seems to have been relegated to the history books with the move of more software to the web. Now every application needs to build its own component library more or less from scratch because the platform lacks a decent standard UI.

Design and fashion being cyclic, I wonder if in a decade or so we’ll see a return to interfaces with depth and character in the future instead of the grey flatland we have now.

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.