The rustls project:

Compared to previous reports, the benchmark tool can now perform the same benchmarks in many threads simultaneously. Each thread runs the same benchmarking operation as before, and threads do not contend with each other except via the internals of the TLS library.

As before, the benchmarking is performed by measuring a TLS client “connecting” to a TLS server over a memory buffer – there is no network latency, system calls, or other overhead that would be present in a typical networked application. This arrangement actually should be the worst case for multithreaded testing: every thread should be working all the time (rather than waiting for IO) and therefore contention on any locks in the library under test should be maximal.

A fantastic showing by rustls with much higher handshakes-per-second and low latency with little variance as well. Testing was performed on an 80‑core Ampere Altra ARM server against BoringSSL and two versions of OpenSSL.

Ernie Smith writing at Tedium:

In case you were not aware of this previously, fandom always finds a way. Whether in the form of video game translation mods that emerged from the late ’90s emulation scene or the impressive work that has been done to bring PC gaming to Linux via Proton, there have always been attempts to stretch the accepted definition of what our video came consoles allow us to do.

Now, we have a new addition to add to that list: After 39 years, console modders have begun to develop ways to use the Nintendo Entertainment System’s infamous expansion slot, a key example of vestigial manufacturing. In honor of this amazing feat, which is being used to add Bluetooth and Famicom Disk System support to the console, I thought it might be good to take a look back at this fascinating wrinkle of history. Today’s Tedium ponders the legacy of the NES Expansion Port, and where it’s going next.

It’s fantastic how accessible low volume PCB production is these days. There’s so many neat projects that hobbyists and small-scale professionals are able to design and build that previously were not possible—the NES Hub being one of them.

Diana MacDonald ¹:

You can use CSS print media styles to present your site’s content for print media, such as actual pages printing or for saving a page as PDF. This can let you write content once for the web and then format it differently for print. For an idea of what you could do with this power, you could:

• Let readers print your blog posts, recipes, or tutorials on paper.
• Add the ability to export reports in a SaaS product to PDF.
• Help customers print invoices, tickets, contracts, or other documents from your website.
• Convert web pages into a book.

Most resources I’ve found about print styles were written about a decade ago. In this post, I’ll share what I learned and what’s still relevant today.

Print CSS is the lesser known corner of the CSS specification, not often encountered by most web developers. A lot of it was specified in the early days of CSS and has remained stable since. While actual printing is one use case, the more common use these days is probably the generation of PDFs, something that I’ve had a lot of exposure to because I work at YesLogic on the Prince HTML to PDF tool.

Di’s post covers everything you need to know to get started using and developing print CSS in 2024.

Jim Nielsen:

With a search engine, fewer quality results means something. But an LLM is going to spit back a response regardless of the quality of training data. When the data is thin, a search engine will give you nothing. An LLM will give you an inaccurate something.

Rather than saying “I don’t know, there’s not enough on this subject to formulate a working answer” — which is what you could infer from an empty search results page — an LLM will give you something that looks right. Then you have to go shoot yourself in the foot to learn it’s not right, because you didn’t know enough to know it was wrong.

LLMs just making stuff up is one of their main issues. I have to imagine there is a lot of work going into improving this situation, the end result of which is surely use-cases where the response is simply “I don’t know”. Until then you have to take every answer-style response with a healthy amount of scepticism.

Alex Russell with a detailed and relatively pragmatic post on building websites in 2024. The tone is a bit ranty but there’s a lot of sensible advice underneath it for those willing to listen. It tackles some common counter-arguments as well. This one is a particular peeve of mine:

“But… we need to move fast”

This chestnut should always be answered with a question: “for how long?”

This is because the dominant outcome of fling-stuff-together-with-NPM, feels-fine-on-my-$3K-laptop development is to cause teams to get stuck in the mud much sooner than anyone expects. From major accessibility defects to brand-risk levels of lousy performance, the consequence of this sort of thinking has been crossing my desk every week for a decade now.

This shortsighted view pops up in all sorts of places, and I wish that there was less focus on development velocity and more on how usable, reliable, well-designed, and efficient software was.