Matthew Ström:

Interfaces are becoming less dense.

I’m usually one to be skeptical of nostalgia and “we liked it that way” bias, but comparing websites and applications of 2024 to their 2000s-era counterparts, the spreading out of software is hard to ignore.

To explain this trend, and suggest how we might regain density, I started by asking what, exactly, UI density is. It’s not just the way an interface looks at one moment in time; it’s about the amount of information an interface can provide over a series of moments. It’s about how those moments are connected through design decisions, and how those decisions are connected to the value the software provides.

I’d like to share what I found. Hopefully this exploration helps you define UI density in concrete and useable terms. If you’re a designer, I’d like you to question the density of the interfaces you’re creating; if you’re not a designer, use the lens of UI density to understand the software you use.

This post could have been a long rant about the lack of density in modern user interfaces. Instead, Matthew calmly explores multiple dimensions of UI density and how contemporary trends and tastes may be met while respecting the user.

This post by Conrad Irwin on the Zed blog is about the roadmap for Vim features in Zed in 2025, but this section caught my eye:

People who switch to Zed from Vim are attracted by the “just works by default” aspect of Zed: language servers just work, and the advanced features (AI, collaboration). But, nothing is more frustrating than a Vim mode that doesn’t work exactly like Vim. We get a lot of VS Code Vim extension refugees, and the number one complaint is that “it just didn’t feel right”.

Zed is already much closer to Vim. We have extensive “side-by-side” testing where we run headless Neovim to ensure our keyboard shortcuts do exactly the same thing. That said, there’s always more to do, both to add the remaining minor motions zL/ zH come to mind, and fix edge cases in things like d]}.

I have been impressed by Zed’s mode, it did in fact just work™ for the most part when I started using the first Linux version of Zed¹. They clearly consider it a core part of the Zed experience and are dedicated to making it feel correct with that side-by-side testing. In many other editors the vim mode feels like an afterthought, tacked on to appease those vim weirdos. I’m glad that’s not the case here.

In a post on my own blog:

Stylus is an open-source browser extension for managing and applying “user styles”—custom snippets of CSS—to websites. It allows you to tweak sites you visit to tailor them to your preferences. In this post I list the ways I use Stylus to make my browsing experience nicer.

I set out to write this post to describe all the ways I use Stylus to mould the web to my will. It turns out that mostly boils down to setting max-width on sites that are too wide for comfortable reading, and replacing fonts with ones I think look better… it does include a rule to banish those awful “Sign in With Google” pop-ups though.

On the Fediverse Di replied with this great tip:

I’ve been using Stylus to hide pictures of a certain person that’s been in the news a lot lately:

img[alt*="nameOfPerson"] {
  visibility: hidden;
}

It has made my life much better.

Armin Ronacher:

But what about the socket? The solution to this problem I picked comes from systemd. Systemd has a “protocol” that standardizes passing file descriptors from one process to another through environment variables. In systemd parlance this is called “socket activation,” as it allows systemd to only launch a program if someone started making a request to the socket. This concept was originally introduced by Apple as part of launchd.

To make this work with Rust, I created two crates:

• systemfd is the command line tool that opens sockets and passes them on to other programs.
• listenfd is a Rust crate that accepts file descriptors from systemd or systemfd.

It’s worth noting that systemfd is not exclusively useful to Rust. The systemd protocol can be implemented in other languages as well, meaning that if you have a socket server written in Go or Python, you can also use systemfd.

For projects like Linked List I currently use something like

watchexec -w src -r 'cargo run --bin linkedlistd'

to restart the server when the source changes. As Armin points out in this post there is a window in which there server is down, so if you hit F5 to reload the page during that window you get a connection error. With the presented solution the systemfd tool always has the socket open and socket passing will hand it to the server when its back up—neat. I’ll have to incorporate this into the Linked List code.

Some folks from Cerebras were on the most recent episode of the Oxide and Friends podcast. I’d not heard of Cerebras before, but they’ve developed custom silicon for doing AI inference called the WSE-3. It takes up an entire silicon wafer, and has 900,000 cores and 44Gb of on die SRAM:

This gives every core single-clock-cycle access to fast memory at extremely high bandwidth – 21 PB/s.

Those are some pretty fun figures. All of this aims to make AI inference fast. You can try it out with a small selection of models at inference.cerebras.ai. For the couple of prompts I tried the responses were nearly instantaneous, which is mighty impressive. Of course, their table of comparative figures against the Nvidia H100 does not include power consumption, but I imagine it is possible that it’s better than a cluster of individual machines.