NixOS Deployments | 1299 Members | |
| NixOS Deployment tooling | 313 Servers |
| Sender | Message | Time |
|---|---|---|
| 22 Nov 2024 | ||
| The time I have - it can wait a bit, the problem I think is I try to over-complicate things that I want to simplify. I want to move as much stuff as I can to nix because of it's declarative nature and that way I don't have to have some special backup for the config. Perhaps for this device it's easier and more cost efective to just use Unraid and have the config be backed up in another manner. Coz Unraid does everything I need: boots from usb 2 quite fast, runs in memory and does not use a lot of it so even those 2GB of ram available in here are mostly free for me to deploy some services. | 16:56:00 | |
| Side note: Since you mentioned using ZFS, IIRC that can use a lot of memory, especially when enabling deduplication. | 17:00:52 | |
| Yeah generally deduplication is not recommended unless you are in a very special circumstance | 17:02:05 | |
| Zfs without dedup eats memory because of ARC, the solution there is to tel zfs to keep minimum of X GB free, so that other software doesnt think its under constant memory pressure | 17:04:12 | |
| (ARC is the zfs equivalent of the page cache on linux) | 17:04:38 | |
| 18:10:33 | ||
| 18:47:46 | ||
| 20:14:30 | ||
| 23 Nov 2024 | ||
| 09:45:24 | ||
| Hi, I'm working on an automated update of my flake inputs and then remote switch of all my servers. I'm using a systemd service with a timer to run a script on my desktop workstation which i always leave on to update the input, test the builds using build-vm and then switching the config on the servers. I would also like to switch the config of my workstation but the switch stops the systemd service which then stops the switch, does anyone here have a similar setup and a solution to that problem? I'm thinking a cron job instead of systemd timer would maybe do it, but the wiki says it's recommended to use a systemd timer and I would prefer this for the journalctl logs. | 12:25:57 | |
| 20:48:52 | ||
| 24 Nov 2024 | ||
| 00:41:11 | ||
| 25 Nov 2024 | ||
| 07:12:52 | ||
| 07:44:04 | ||
| 08:54:54 | ||
| Hi 👋 How reliable is Nix for building release binaries targeting non-Nix systems? I try to use Nix inside my CI for building (and cross-building) release binaries. People who download such binaries are mostly non-Nix users. I'm facing issues and dilemna with both static and dynamic linking:
| 09:06:58 | |
| https://github.com/hsjobeki/nixpkgs/blob/migrate-doc-comments/pkgs/build-support/release/debian-build.nix https://noogle.dev/f/pkgs/releaseTools/debBuild https://wiki.nixos.org/wiki/Nixpkgs/Building_RPM_DEB_with_nixpkgs This one gets you pretty far in one direction, not sure if it's the direction you want to go to | 09:11:38 | |
| we have static-enough linking for macOS | 09:13:43 | |
libSystem will be dynamically linked, but that is true of all macOS binaries | 09:13:55 | |
| in general system frameworks are part of the OS and don't get statically linked | 09:14:05 | |
as long as you use a deployment target corresponding to the minimum macOS version you support, pkgsStatic should work just fine (if there aren't packages it's broken with that you use) | 09:14:35 | |
(current default minimum is 10.12 on x86_64-darwin and 11.0 on aarch64-darwin; in 25.05 it will be 11.3 across the board; in 25.11 it will be 14.x across the board) | 09:15:05 | |
with macOS you can do relative rpaths and stuff, but generally we use absolute ones. it's possible that install_name_tool will let you patch them up enough for it to work. there's various scripts out there for copying dylibs into .app bundles and rewriting the paths appropriately; perhaps you could use one of them | 09:15:57 | |
| @soywod:matrix.org as for windows, cross compiling to it using mingw is pretty painless. You do have to do what every windows does anyway, which is shipping a buttload of DLLs. I managed to cross compile Haskell too and disregarding the problems with GHC it was actually easy | 09:16:25 | |
| Thanks a lot for your answers, really helpful. So in conclusion static linking is reliable enough for deploying multi-platform releases, right? Regarding Windows I will dive a bit more, I may took a wrong direction. | 09:19:05 | |
| * Thanks a lot for your answers, really helpful. So in conclusion static linking is reliable enough for deploying multi-platform releases, right? Regarding Windows I will dive a bit more, I may have taken a wrong direction. | 09:21:12 | |
| For linux its reliable enough, for windows just go with dynamic and ship the DLLs, thats what everyone does | 09:22:04 | |
| I have written a blog post some time ago about cross-compiling and packaging with Nix Flakes, perhaps that's helpful for you: https://flyx.org/cross-packaging/ However this does not use Nix' cross-compiling capacities, instead it relies on Zig for providing a cross-compiling clang setup. OTOH it can build .deb packages with dynamic linking that depend on other .deb packages | 09:22:06 | |
for macOS, reliable enough insofar as if something builds on pkgsStatic, and it would hypothetically work if you move all the .dylibs around and rewrite them, then it should work with pkgsStatic | 09:22:52 | |
| YMMV, still nominally experimental, report bugs if you find them, but it's meant to work now | 09:23:05 | |