I wanted to write a module that generates multiple systemd services and timers to scrub some zfs pools at certain intervals. The default scrub config does not support individual scrub intervals for each pool.

I want the config to look like this:

{
  services.zfs-auto-scrub = {
 tank = "Sat *-*-* 00:00:00";

See how a minor change to your commit message style can make a difference.

Some time has past (three years!) since I last wrote about API specifically about coroutines style APIs so I thought why not write another one about a different API type I encounter relatively often. The builder API.

Now first let me take a step back and put this into 20,000 feet view on where builder APIs are located in the grant scheme. In general everything in computing is separated into input, processing and finally output. In its most basic form I am currently typing on my keyboard. All pressed keys are processed from the OS up to the browser I am writing this in and finally rendered and displayed on the screen as output. Of course this example is very user centric

I am currently dealing with a lot of libraries at work. Both third party as well as libraries written or being currently in process of being written by me. I absolutely love writing and working with libraries. Especially if they present or bring me to either a new or different approach to solve a problem. Or at least provide a different view.

Over time I noticed however that quite regulary we had to decide that we cannot use a third party library. Often it is the usual reason.

Last time I wrote a little bit about my current GUI research progress. There are some things that were misunderstood so I want to clarify some fundamental design decisions and finally write up some current problems and their solutions.

First up I want to clarify a component is not another term for what is usually refered to as widget. Instead wigets in this implementation are made out of n >= 1 components. Components themself are just rectangles with attributes left, right, top, bottom, center_x, center_y, width and height some behavior flags and an optional surface to draw into. For example a scroll regions is made up out of at least three

For the last few weeks I spend some time coding, writing and cleaning up my notes from almost a year since I published nuklear.

Basically this is a possible implementation for a graphical user interface builder backend with support for an immediate mode style API. So it provides a way to define non-mutating UI state, an immediate mode style API for dynamic UI components (lists,trees,...) and a combination of both.

The core implementation is ~800 LOC without any kind of default widgets or extensions. At first this seems quite counter intuitive. However since the inherent design allows for lots of different ways to define any widget like buttons it does not make sense to provide a specific default implementation. The way this code was architectured furthermore removes the need for style/skinning configurations used in Nuklear since widget painting is just calling a small