Farid Zakaria

As a nix person, I like this a lot and could see myself using it. My only criticism would be I don't love this kind of thing:

"<!DOCTYPE html>\n" + html [ (attrs.lang metadata.lang) ] [ (head [ ] [ (partials.head context) ]) (body [ (attrs.classes [ "font-sans" "bg-white" ]) I understand that this is very flexible and powerful, but it immediately makes the templates highly non-portable and requiring of hand-authorship— fine for a personal blog by a code nerd, but a non-starter for when a designer is involved who will want to use visual tools. I see that right below that there's also a "normal string templating" option that's closer to conventional jinja2 or the like, but it's ultimately still pretty nix-ified.

It might be worth some ifd [1] to allow a step that pre-processes conventional html + tags template files into the form that can be consumed by nixtml.

[1]: or the still-experimental dynamic derivations: https://fzakaria.com/2025/03/10/an-early-look-at-nix-dynamic-derivations

"There's a video of the recovery here. It's only slightly over five minutes long, but then, UNIX V4 wasn't very big yet: for instance, the kernel was some 27 kB of code."

"It's very small: it contains around 55,000 lines of code, of which about 25,000 lines are in C, with under 1,000 lines of comments."

Yesterday, HN front page:

https://fzakaria.com/2025/12/28/huge-binaries

"Responses to my publication submissions often claimed such problems did not exist; however, I had observed them during my time within industry, such as at Google, but I couldn't cite it!

One problem that is only present at these mega-codebases is massive binaries. What's the largest binary (ELF file) you've ever seen? I had observed binaries beyond 25GiB, including debug symbols."

It's funny that he could not publish about the laughably large binary sizes at Google

Meanwhile employees at the company have often published papers portraying the company's problems as interesting, perhaps as a recruiting technique

Farid Zakaria recently gave a talk¹ (at NixCon 2022) where I think he put it better: Nix (and Guix) blur the line between dynamic and static linking.

I think this is true, because with Nix and Guix, you actually have an end result with the positive characteristics of both kinds of linking.

His talk, based on his work on shrinkwrap² and nix-harden-needed², called for the creation of a new executable format for the Nix world. Seems apropos as a reminder that there are other possibilities!

(I think these kinds of solutions are definitely within reach for Valve from a technical perspective. Other tools are using them today.)

--

1a: https://youtu.be/HZKFe4mCkr4

1b: https://youtu.be/lzk4sldexX4

2: https://fzakaria.com/2022/03/15/shrinkwrap-taming-dynamic-shared-objects.html

3: https://fzakaria.com/2022/09/12/making-runpath-redundant-for-nix.html

I was confused on what $ORIGIN means, so, macroexpanding the article a bit

https://fzakaria.com/2026/06/21/nix-needs-relocatable-binaries

> The loader in Linux however natively supports the variable $ORIGIN which translates to “the directory containing the executable.”

https://man7.org/linux/man-pages/man8/ld.so.8.html

But, if ld.so supports $ORIGIN already, why does the kernel needs to support it also? Or rather, why can't the kernel leverage ld.so and do this entirely on userspace?