3 ms·
> I think the Nix in particular supports really good integration so the whole BSD "we're tighter-knit than a distro, don't call us that" argument shouldn't just
by ori_b 6y ago
> I think the Nix in particular supports really good integration so the whole BSD "we're tighter-knit than a distro, don't call us that" argument shouldn't justify the duplicated effort.
That's an inaccurate representation: The difference is that BSD evolves the whole system in lockstep, userspace and kernel at the same time. When userspace wants new capabilities like pledge(2), then the kernel is updated to expose it. When the kernel adds new features like routing domains, then userspace is updated to use it.
There's no coordination across a bunch of different projects: The same commit just changes things, across all the bits at once.
Nix doesn't offer that.
- Ericson2314 6y agoNothing you said Nix precludes. If I were to make a Nixified BSD, there's no requirement that I have to split things into multiple repos. I can continue to use a monorepo for the core userland and kernel. If I want to add a feature to a widely used package, I can still vendor the package like BSD, or I can bump the kernel and package srcs in one commit, adding the feature in both, like Nixpkgs today. In no way am I now at the mercy of coordinating upstream devs---Nix allows any user to integrate anything they want, unilaterally, whether a monorepo is used ot not. The benefit of Nixpkgs is not to replace the core of BSD, but to replace ports. Nobody, least of all the BSDs, has the time to bespoke integrate every single package. There is always a long tail of stuff that is budgeted minimally----this isn't Linux distro ideology, put simple economics. Nixpkgs allows multiple disparate groups to better cooperate on that long tail.