Nix Hackers | 940 Members | |
| For people hacking on the Nix package manager itself | 195 Servers |
| Sender | Message | Time |
|---|---|---|
| 10 Apr 2026 | ||
| 13:57:04 | ||
| 20:57:29 | ||
| 13 Apr 2026 | ||
| 01:10:58 | ||
| 01:47:21 | ||
| What is the easiest way to know what is in a new nix minor release? One should check the commits 2.34.5..2.34.6? | 07:51:25 | |
| * What is the easiest way to know what is in a new nix minor release? One should check the commits eg 2.34.5..2.34.6? | 07:51:42 | |
| Okay I guess it is just a single fix this time | 07:53:39 | |
In reply to @juhp:matrix.orgFor major stuff we do try to have release notes, but minor bug fixes sometimes just get yeeted | 07:53:59 | |
| Okay | 07:54:38 | |
| 14:18:42 | ||
| 👍️ on moving the perl bindings out of the nix repo | 15:44:08 | |
| OK thanks Eelco | 15:45:43 | |
| but uhm, I thought the whole thing was being rewritten in perl? | 15:52:56 | |
| *rust | 15:52:59 | |
| I don't think the web bits have been touched yet | 15:53:49 | |
| too bad | 15:54:28 | |
| I'd much rather see the perl stuff replaced than the C++ stuff | 15:54:38 | |
| 14 Apr 2026 | ||
| 00:26:04 | ||
| 00:27:42 | ||
| 15:58:25 | ||
| 15 Apr 2026 | ||
| 06:49:32 | ||
| 16 Apr 2026 | ||
| 17:07:34 | ||
| 17:16:13 | ||
| 17 Apr 2026 | ||
| 08:36:44 | ||
| 08:41:40 | ||
| 18 Apr 2026 | ||
| 16:56:41 | ||
| Eelco: I wanted to say thank you for creating nix, btw. I'm building something huge on it - already working large parts of it. I'm building the next gen package distribution | 17:00:50 | |
| * Eelco: I wanted to say thank you for creating nix, btw. I'm building something huge on it - already working large parts of it. I'm building the next gen package distribution on it. Walrus / Sui / Nix / IKA and the stuff I'm building. I'm very confident that with this system, we can prevent dependency chain attacks and many other problems :) | 17:01:50 | |
| Super exciting times for fully decentralized, bulletproof systems. Especially using IKA with its mpc-2pc (multi party computation - 2 party) - ground breaking crypto that allows us the have the signing key split in a way that a contract needs to properly evaluate and you have to sign the second part. Part of my workflow system is building a smart contract that evaluates to true when multiple parties build the same artifact, checked the source code with all dependencies against malware loaders or other bad code like unicode malware (glassworm), .... By using SUI frozen objects I can guarantee that releases can't ever be manipulated afterwards. Walrus blobs also can't be manipulated and quilt encoding allows us to nicely cache and re-consolidate unused storage. We (me and chatgpt 5.4 pro) are currently discussing/designing an optimized data structure to start with. I already have git on SUI/Walrus backend I'm polishing currently, before I publish it in testnet. Hosting nixpkgs sources on this should cost ~4$ / year on storage. Very curious what commits will cost on mainnet :) The cool thing is, that release tags can be frozen and therefore never ever be changed. Like the axios hack in the last weeks where a maleware on the developer machine overwrote the release tag and added malware dependency. I fear the day github gets hacked and half the CI they provide get compromised compilers that build a sleeping worm that goes haywire after some month. | 17:30:58 | |
| The workflow engine I have built already creates signed digest files of all build outputs and has native nix build step. I want to combine this build artifacts then with a LSM module to allow super secure systems that only run code that got signed by this chain. the linux current xattr based system does not work due nix store compression, but with a LSM (maybe ebpf) and a small daemon this will work. | 18:16:03 | |