-
The most obvious cause was forcing BDFL and creator Eelco to step down
https://lwn.net/Articles/970824/
The moderation team posted an open letter demanding he step down, among other reasons this accused him of jeopardizing the safety of people from "marginalized backgrounds" and allowing "fascists" in the community
I have tried very hard to find any examples of what this is a actually referring to and genuinely have no idea
https://github.com/save-nix-together/open-letter/blob/main/c...
-
Kargo
Stop Scripting Promotions. Start Shipping with Kargo. Kargo automates promotion across dev, staging, and prod with approval gates and verification. Open source, built by the team behind Argo CD. Download now.
-
Nix ran for many years with very little to no structure. This worked fine as long as the community has some cohesion around it being a FOSS project. But political divisiveness happened around 2021 and crept into the community. You're still seeing the fallout of https://github.com/NixOS/rfcs/pull/98
-
Updating causing a rebuild isn't really a Nix or even a build tool problem though, is it? cache.nixos.org can't provide everything for every architecture all the time.
With multiple types of machines involved, you want some sort of binary cache setup, ideally automated with CI. There's niks3 [0], celler [1] (a more active fork of attic [2]), hydra [3].
0: https://github.com/Mic92/niks3
1: https://github.com/celler-cache/celler
2: https://github.com/zhaofengli/attic
3: https://github.com/NixOS/hydra
-
Updating causing a rebuild isn't really a Nix or even a build tool problem though, is it? cache.nixos.org can't provide everything for every architecture all the time.
With multiple types of machines involved, you want some sort of binary cache setup, ideally automated with CI. There's niks3 [0], celler [1] (a more active fork of attic [2]), hydra [3].
0: https://github.com/Mic92/niks3
1: https://github.com/celler-cache/celler
2: https://github.com/zhaofengli/attic
3: https://github.com/NixOS/hydra
-
Updating causing a rebuild isn't really a Nix or even a build tool problem though, is it? cache.nixos.org can't provide everything for every architecture all the time.
With multiple types of machines involved, you want some sort of binary cache setup, ideally automated with CI. There's niks3 [0], celler [1] (a more active fork of attic [2]), hydra [3].
0: https://github.com/Mic92/niks3
1: https://github.com/celler-cache/celler
2: https://github.com/zhaofengli/attic
3: https://github.com/NixOS/hydra
-
Updating causing a rebuild isn't really a Nix or even a build tool problem though, is it? cache.nixos.org can't provide everything for every architecture all the time.
With multiple types of machines involved, you want some sort of binary cache setup, ideally automated with CI. There's niks3 [0], celler [1] (a more active fork of attic [2]), hydra [3].
0: https://github.com/Mic92/niks3
1: https://github.com/celler-cache/celler
2: https://github.com/zhaofengli/attic
3: https://github.com/NixOS/hydra
-
This was a talk geared specifically at a ROS audience so it's lighter from a general infra point of view but there may still be something useful: https://vimeo.com/767139940
At the time of that talk we threw up a lightly sanitized version of the tooling on github. The basic idea was that there were these two repos:
https://github.com/clearpathrobotics/nix-ros-base
https://github.com/clearpathrobotics/nix-ros
The first was the "toolkit" repo that had all the manual maintained dependencies and functions, while the second was a managed repo which would have tags pushed to it by the pipeline.
So basically all the repos had a push hook attached to them that would run this centralized dispatch workflow (on Jenkins, but it could be anything). The dispatch job would sanitize the branch name like joey-b/fancy-feature and attach it to the most recent "released version" + devel timestamp, so you'd end up with like 2.25+2026080-12345+joey-b-fancy-feature, and that would be pushed as a floating tag to the nix-ros repo with all the sources from the hundreds of participating repos either locked to the versions set in the top level 2.25 devel branches or to the specified feature branch, so that a given build could pull together multiple same-named branches from across repos. That would be sent off to Hydra, and nix2container outputs were also built that went to simulator based validation.
But the end UI was pretty nice, basically a nix configuration mapped the names to the those repos so after the build was done you could just pull it and "enter the workspace like:
nix build ros#2.25+2026080-12345+joey-b-fancy-feature -
AppSignal
AppSignal knows why the f*#k it crashed. Stop vibe-debugging. Every exception, every backtrace, grouped so you see patterns, not noise.
-
This was a talk geared specifically at a ROS audience so it's lighter from a general infra point of view but there may still be something useful: https://vimeo.com/767139940
At the time of that talk we threw up a lightly sanitized version of the tooling on github. The basic idea was that there were these two repos:
https://github.com/clearpathrobotics/nix-ros-base
https://github.com/clearpathrobotics/nix-ros
The first was the "toolkit" repo that had all the manual maintained dependencies and functions, while the second was a managed repo which would have tags pushed to it by the pipeline.
So basically all the repos had a push hook attached to them that would run this centralized dispatch workflow (on Jenkins, but it could be anything). The dispatch job would sanitize the branch name like joey-b/fancy-feature and attach it to the most recent "released version" + devel timestamp, so you'd end up with like 2.25+2026080-12345+joey-b-fancy-feature, and that would be pushed as a floating tag to the nix-ros repo with all the sources from the hundreds of participating repos either locked to the versions set in the top level 2.25 devel branches or to the specified feature branch, so that a given build could pull together multiple same-named branches from across repos. That would be sent off to Hydra, and nix2container outputs were also built that went to simulator based validation.
But the end UI was pretty nice, basically a nix configuration mapped the names to the those repos so after the build was done you could just pull it and "enter the workspace like:
nix build ros#2.25+2026080-12345+joey-b-fancy-feature -
At the time I was there we hadn't made it all the way to NixOS on the targets, so it was an Ubuntu "base" + Nix managing the app workspace as a kind of pseudo container, though able to bring more of its own system configuration with it (https://github.com/numtide/system-manager) than the more typical nuisance setup of container + separate outer config managed by ansible or a deb or whatever.
As a result of that, in "production" we still actually delivered full rootfs images just to be absolutely certain, and the delta upgrades were for smaller test fleets that could updated hourly just via simple push tooling.
If I was building it from scratch though, I'd probably just do NixOS + colmena, and do a push model forever. It's not worth the saved SSH connection to not have those logs and status messages coming back to the central coordinator immediately.
