←back to thread

275 points pabs3 | 1 comments | | HN request time: 0s | source
Show context
3np ◴[] No.45147564[source]
Building the software you rely on from source by default is one way to reduce the impact these events have on you and shift the power dynamic. If you're installing binaries/images from a vendor (free or otherwise), transitioning to a fork may be an undertaking and a sweaty risk-assessment.

Switching your existing build-infra to sync sources from a new remote should be a snap.

Also no major need to hound maintainers to ship a release or merge that neglected bugfix or feature you desperately need - just cherry-pick it.

replies(3): >>45147791 #>>45147874 #>>45148870 #
ryukafalz ◴[] No.45148870[source]
This is one of the reasons I like Guix so much: its packaging system treats source builds as the normal case, with binary packages available via caching. So if you go to install a package and there's no cached binary, Guix will happily build it for you on the spot, with bitwise reproducibility if it can. You still get the benefits of prebuilt packages, but you always have that escape hatch.

This also means that it's trivial to install a patched version of a package through the same package manager as everything else. No dedicated build infra required (though of course if you're deploying to a large fleet you may want to set up some build servers to avoid the need for rebuilds on most machines).

replies(2): >>45149278 #>>45150538 #
Imustaskforhelp ◴[] No.45150538[source]
Isn't nix for the most part same in that sense though compared to guix?
replies(1): >>45151740 #
1. ryukafalz ◴[] No.45151740[source]
Probably! I just have more experience with Guix than Nix so I don't know what it feels like in practice on the latter.