Sven Slootweg (soft-deprecated) @joepie91@pixie.town

@waweic@chaos.social @schratze Yeah but a low barrier to entry is still *a* barrier to entry, and there are lots of reasons why it might not be practical to get something in there. Maybe there are licensing issues, maybe it's internal software, maybe you and the people managing that repo don't get along, maybe it's something of your own that *you* want to package but not suggest to anybody else that it is ready for use yet, etc.

Nix/Guix solve this on a much more fundamental level, by pretty much removing the concept of a "repository" as some specially-privileged thing, and instead just defining your system as a collection of configuration, some of which happens to describe how to build packages.

It doesn't care whether that 'build configuration' comes from the nixpkgs maintainers (in the case of Nix), or some internal repo, or is even defined inline in your system configuration - it's all just code that evaluates to a pile of packages, and with transparent opportunistic binary substitution.

In other words: nixpkgs, which is conceptually more or less equivalent to an "official" repository for Nix, uses the *exact same tools* that you use in constructing your system configuration, there is no privileged anything involved.

And you don't need to "build your packages against dependencies in nixpkgs" either (treating nixpkgs as strictly authorative and even third-party things have to de facto play by its rules); because of how the evaluation works, dependencies are just references to other packages, and version conflicts don't exist, so you can totally use dependencies from wherever.

So in other words: instead of having a model where there's one authorative source controlling the system and you just have to hope it leaves room for your requirements, you get an "authority-agnostic" system where you don't need *anybody's* permission to package something with the same degree of integration and reliability as in nixpkgs.

@schratze Honestly this is one of the biggest issues I have with most package management systems - there's "distro maintainers packaging software" and then there's "third-party packages" and there's usually a *huge* wall between them in terms of tooling, and quality of integration, and so on, where the moment you use the latter, reliability goes to shit.

And then flatpaks/appimages/snaps/etc. try to "fix" that by introducing a new packaging format that basically just vendors all the dependencies, and is *still* a completely separate system from the *actual* system package manager, so the wall is still there...

And honestly Nix/Guix are the only ones I've seen that have a convincing answer to this problem by erasing the wall between those two categories on a structural level, and I *hate* that this model is not more widely adopted by other distros and package managers. I don't even care if it's Nix/Guix themselves being used. But the solution is just left on the table...

Grumble

@schratze Ah I know *exactly* where this page is from

@schratze Also don't forget the Ehlers-Danlos Syndromes which co-occur an awful lot with neurodiversity

@kim That seems to match my experiences to some degree yeah

@schratze This might also be helpful on this topic: http://cryto.net/~joepie91/a-conversation-about-anarchism.html

@schratze Also yes, the dichotomy between "a hierarchical society" and "an egalitarian society" indeed *is* the crucial distinction in political ideology, the problem is that in most political discourse, a hierarchical society is simply *assumed*, as if the only thing about which there can be disagreement is exactly how that hierarchy is constructed and arranged.

I'm not convinced that this is accidental.

@schratze Egalitarianism? That's the term I've been using for this mostly, to explicitly encode the "no hierarchy of power" component

(This *is* a crucial component of anarchism, but unfortunately a lot of people who call themselves anarchists have a sorely lacking understanding of power dynamics)

@kim Far as I can tell, most implementations *do* call this hashing (often something like "object hash" or "structural hash"), it's just not *cryptographic* hashing