Lessons from maintaining an open source tool:

1. Simplicity is a feature
2. Real users reveal problems
3. open source is a marathon

Yet through all these changes, the need for efficient HTML delivery remains constant. That's perhaps the most interesting lesson: fundamental problems persist even as technologies evolve.

Building an independent web browsers. It's technically feasible and could cost 50-70 millions per year. In comparison, the national space agency costs 7-8 billions and the European union planned 300 millions in digital architecture over the next years.

The Europe rely currently heavily on US technologies, even Firefox is in the US.

Servo is an example of web browser built with 5 engineers, funded by a small company and individual donations.

The core challenge isn’t technical; it’s institutional. It can work though: CERN, European Space Agency, the Internet Engineering Task Force.

Success here would demonstrate that democratic societies can coordinate effectively on complex technical infrastructure and pass the first hurdle. Failure would reveal institutional gaps that need addressing before attempting more ambitious digital sovereignty goals.

And each use case required an own alternative to be found, set up, evaluated and decided. That was just tedious because each alternative came with its own challenges.

but there were the KeePass database, OneNotes and share links.

A script

Hacker news thread: https://news.ycombinator.com/item?id=46092338

(via https://shaarli.zoemp.be/shaare/xtCl-Q)

Landlock shines when an application has a predictable set of files or directories it needs. For example, a web server could restrict itself to accessing only /var/www/html and /tmp.

The author reminds Linux has security issues on most major distributions and each tools trying to improve the state of securit on Linux has drawbacks: Containerization, Flatpak, Firejail, seccomp, SELinux, AppArmor and Landlock.

Landlock fills a major gap: a simple, self-cotnained unprivileged sandboxing tool.

Read more on the landlock.io

How to serve typescript file?

Using a proxy mounted on a route that did a passthrough to a vite front-end app And in production we switched out that proxy for a StaticDir.

I use vite. In development vite dev server proxies requests to (axum) backend, for production vite compiles the frontend bits into a bundle that can be served by axum in a specific route. I'm sure ServeDir would work with this setup, but I actually include the bundle in my executable with a small macro which makes deployments stupid simple.

How to optimize a rust program to squeeze maximum performance and as little RAM as possible

We performed an empirical study to investigate whether the context of interruptions makes a difference. We found that context does not make a difference but surprisingly, people completed interrupted tasks in less time with no difference in quality. Our data suggests that people compensate for interruptions by working faster, but this comes at a price: experiencing more stress, higher frustration, time pressure and effort. Individual differences exist in the management of interruptions: personality measures of openness to experience and need for personal structure predict disruption costs of interruptions. We discuss implications for how system design can support interrupted work.

The devlog
https://plok.sh/harmoneer/taman

Taman is a TUI Pomodoro productivity app where your focus sessions literally grow plants!

• Amazon to build massive data center for the government: https://www.theregister.com/2025/11/25/aws_federal_investment/
• Google wins AI and security management contract for NATO: https://www.computerweekly.com/news/366634759/Google-wins-multimillion-pound-contract-to-supply-sovereign-cloud-services-to-Nato

Maybe there is more to come

Testing sucks because you try to test implementation details. This results in you writing tests to pass your code. That’s not useful, because…

Instead, you should…

1. Write an empty test, with one comment for each external behavior your code should display.
2. Write the code to test each comment below it.
3. Then write the actual code to make it so.