Zürich 25.05 ZHF hackathon report

Announcements
1

On the last weekend of May 2025, the Zürich Friends of Nix hosted the sixth two-day event at Eastern Switzerland University of Applied Sciences (OST) right next to Lake Zürich. These events are designed to encourage people to get to know each other, hack on everything Nix, and shape the future of open source together.

This time we were slightly surprised by the NixOS release team around @leona doing a particularly great job and actually releasing NixOS 25.05 in May 2025. At the size of Nixpkgs, luckily there were still enough build failures waiting to get fixed to fuel a wholesome hackathon.

1920×1279 384 KB

Background and preparations

Preparations started two months after the previous hackathon, by continuing the tradition of publishing an extensive report, evaluating feedback, and coming up with ideas for how to make the next one still better.

This time, apart from identifying and repeating what worked particularly well in the past, we tried to focus even more on enabling people to get together and collaborate, and beginners to get guidance and help.

Event

The event took place in two large classrooms and the hallway connecting them, on Saturday 9:00-17:00 and Sunday from 10:00 to 17:00. There were around 35 attendees on Saturday and more than 20 on Sunday, arriving from Switzerland and all over Europe.

We were excited to welcome numerous people new to either Nix or the Zürich crowd, and had happy reunions with regulars @infinisil @imincik @gefla @Nebucatnetzer @das-g and many more. We especially appreciated having as first-time guests @lassulus @ibizaman @avocadoom @kiara.

On Saturday there was a flurry of impromptu lightning talks:

1920×1279 70.2 KB

Having everyone equipped with NixOS T-shirts, Saturday’s hacking ended with the customary group photo after barbecue at the lake. On Sunday the hacking continued with a smaller but not any less motivated group, and another round of barbecue (complemented by a vegan fried rice option).

Over the weekend, the group created 22 and closed 16 issues or pull requests. Over the entire event series we’re currently at 133 created and 123 concluded contributions.

1920×1279 243 KB

NixOS landing page design

On Saturday a crowd gathered around @avocadoom to unpack what’s there to be done around improving the design of the nixos.org website. We rehashed results of past UX workshops – especially the elaboration on user types and conclusions from the 2024 survey – to converge on a general direction and implementation strategy.

@fricklerhandwerk and @avocadoom followed up in the evening:

  • We generally agreed on the assessments from the past workshops, especially user types and their different needs and roles in the ecosystem.

  • We want to take an incremental approach that shouldn’t disrupt existing workflows, and pick a narrow focus where we can show results in reasonable time.

    It’s always been a serious challenge to figure out where to even start when we’re constantly getting everything at once into scope. We’ll leave the landing page as it is for now, and put new user stories side by side.

  • For an initial deliverable, build user stories for one user type in a way that doesn’t overlap with other user journeys so that it’s easier to keep untangled from unrelated concerns.

On Sunday @steveej joined @avocadoom and @fricklerhandwerk to develop an outline of the “decision maker” journey, which we deemed to have the best ratio of implementation effort to impact at the moment. We stress-tested the proposal with @gefla, who brilliantly played all user personae at once and provided invaluable feedback. The plan is to continue collaborating on the subject asynchronously.

1920×719 120 KB

@avocadoom also fixed a number of small usability and accessibility issues.

NixOS module interfaces

As a kind of follow-up to the deployment systems exchange half a year ago, @ibizaman @fricklerhandwerk @kiara @lassulus came together to distill a pattern encountered in multiple efforts revolving around NixOS:

The idea is illustrated in @ibizaman’s pre-RFC proposal to decouple NixOS service components and was presented at NixCon 2024: Try being more clever with the modules’ type system by adding what amounts to a “modular” function type. This would allow separating interfaces from implementations when computing configuration values.

And it’s an important thing to get right! All of these projects are promising to substantially improve both user and contributor experience for NixOS:

  • Modular services and Vars are concrete examples where specifying the interfaces more explicitly would help with both code readability for maintainers and reduce effort for implementation authors.
  • Fediversity and NGIpkgs will both soon run into the acute need to provide multiple implementations in order to enable deployment variants and manageable integration tests.
  • SelfHostBlocks is building an entire collection of modules that are composed using such interfaces, but so far was lacking a concise, reusable implementation of its underlying idea.

Two half-afternoons of intense hacking, agonizing over inscrutable stack traces, infinite recursion encountered, and plain-dumb typos later, we’re proud to present module interfaces:

It’s enabled by @nbp’s original genius and (among a few others) @roberth’s thoughtful maintenance of the dark magic that is The Module System: Equipped with its unique combination of global merge semantics and dependent types, it is now complemented with its own, worthy notion of type-safe function application.

Check the example to get a feeling for how it’s used. The consumer-input-provider-output-interface terminology still borrows from @ibizaman’s proposal, but may be more appropriately framed with apply-argument-function-value-type. We already sketched a way to address @Atemu’s comment on accommodating provider-specific parameters.

The next step would be to implement the module system equivalent of effects. That would be required to support the Vars use case, where the consumer would input parameters, the provider would return the path to a secret as a pure value, but also generate an activationScript entry as a side effect. Idea: config, from the module argument of the consumer, acts as the context passed through together with the input to the provider, and is retrieved together with the output to be attached as the config attribute of the consumer which contributes to the final evaluation result.

50 years of programming language theory research into pure languages and type theory have not been in vain. Pull requests welcome!

Acknowledgements

This event was made possible by Prof. Dr. Farhad Mehta (@fmehta), professor of informatics at the OST, by accommodating us in a large, modern computer room with a beautiful lake view.

This event wouldn’t be possible without the amazing event team around @ners and @john-rodewald and @das-g tending to the venue.

Tweag, the Modus Create Open Source Program Office lead by Mathieu Boespflug (@aherrmann), and Antithesis, thanks to their ongoing sponsoring, enabled @fricklerhandwerk and @infinisil respectively to participate as part of their work on the Nix ecosystem.

Thanks to all the participants for making this such a memorable event.

And last but not least, many thanks to NixOS 25.05 release managers @leona and @rosscomputerguy for another great edition of our favorite Linux distribution!

Looking ahead

The next ZHF hackathon in Zürich is already on the horizon, save the date:

Saturday 29th and Sunday 30th of November 2025

We hope to meet all of you again, but only after NixCon 2025 September 5-7 at the same venue!

For up-to-date information, check the Nix Zürich user group website.

You can also follow news shared on these channels:

Find more Nix events in the NixOS Discourse Events category.

34 Likes