I think there's a ton of misconceptions about what Nix/Guix are and I wanted to write an easy to understand proper introduction about the brilliant concept behind them.
The single biggest misunderstanding is what the hashing mechanism does. So forget everything you think you know about it and let me walk you through this.

First let's look at an example of why universal package management is difficult.
Imagine you want to install 2 programs that both use the same dependency called "libraryA-1.2". However, one of the programs needs libraryA-1.2 to be compiled with support for X and the other needs it compiled without support for X.
So if you only install 1 version of libraryA-1.2 then at least 1 of the programs will always be broken.

Now, this problem can be solved even with traditional package managers by simply creating 2 separate packages for libraryA-1.2, like: "libraryA-1.2-with-X-support" and "libraryA-1.2-without-X-support".
Then each of the 2 programs will link against the appropriate version and all is well. But notice that "-1.2-with-X-support" is now essentially a more robust version string than just "-1.2" alone.

[1/3]

[2/3]
So it's not that these issues can't be resolved with traditional package managers. The problem for universal package management is that the solution is not formalized, it can't be automated, and details about how software was compiled need to be manually researched when trying to fix problems.
Typical version strings simply lack enough information for a developer to state how everything was actually compiled on their machine when they tested it. Or to resolve breakage caused by moving software from one machine to another.
You may compile a version that seems to work, but will it truly behave the way the developer intended in all cases?

Therefore, to resolve these issues and have truly universal package management we would simply need EVERY detail of each packages build-chain to be recorded in the version string.
So what if our version string is more like:
>libraryA-1.2-with-X-support-and-dependencies-A,B,C,D,E-where-A-is-compiled-with-support-for-Z-and-C-depends-on-packages-F,G,H-and-F-was-compiled-against-glibc-version-2.3-.....
What if we go even further still, and include the full source code inside the version string, and the full source code of all the dependencies, and dependencies of dependencies of dependencies.
Your version string is now 10billion characters long, but it fully describes the EXACT build-chain of the software, contains the literal source code of the software and all its deps and their source code, and even the instructions for building the software and the instructions for building their dependencies, and their dependencies dependencies, all the way down to a bootstrap.

THAT is where the Nix/Guix hashing concept comes in. You take that 10billion character long version string and create a simple hash for it and use that hash as the packages version string instead.
So the hash has nothing to do with the compiled binary (that's a misunderstanding that keeps being propagated).

[3/3]
It's not a binary-based hash, it's a source-based hash. Nix and Guix are SOURCE-BASED package managers.
The hash is about the build chain itself (including source code, including build instructions, every single bit of information needed to build the software exactly as the developer intended).
Change a single build flag on a dependency of a dependency of a dependency, and you've changed the version of the library.

So the idea behind Nix/Guix is essentially just a method of creating robust version strings that encapsulates every single detail about how its built, thus basically solving all the major issues of universal package management.
This is not theoretical, its ability to create univeral packages is already put into practice. Guix (and maybe Nix? idk) literally comes with a feature to create re-locatable universal packages by compiling software to a tarball that can be unpacked and run on any Linux machine (even machines without Guix installed), like a flatpack.

The fact that Nix/Guix have a binary repo does not make them binary-based package managers. The primary repo does NOT provide binaries, it provides hashable build definitions. However, because this version-hashing method is so effective that you can expect BIT-FOR-BIT identical binaries compiled on different machines they offer a _secondary_ binary repo as a time-saving service. And when you request a specific version-hash from the binary repo you're essentially requesting that the software was compiled in an exact way.

This novel approach also creates a new security concept which is unique to Nix/Guix called "challenging". Any user can "challenge" the binary build in the repo to verify that it wasn't tampered with. You simply cannot do that with traditional package managers (e.g. there's no way to guarantee binaries in Ubuntu repos were actually compiled with unmodified versions of the source code). With Nix/Guix you can.

>>105523532
>SOURCE-BASED
How does it stop the equivalent of update world == Armageddon in portage?

>>105524001
Do you mean in the sense that you have a shitton of things to compile? Or in the sense that things can break (especially if it's been a long time since you last upgraded, or if you have highly customized USE flags)?

In the compiling sense, it's prevented by the _secondary_ binary repo, so you simply download the binary instead of compiling it (see the OP post [3/3] for why this is the same as compiling it yourself, and not the same as using a binary distro).

In the sense of things breaking, it's prevented because everything is compiled with absolute link paths to exact library versions (and as described in the OP those "versions" are exact build specifications). So there's no need at all for the package manager to juggle dependencies, literally any combination of software (even the same software with multiple outdated versions) can all be installed together without issue.

>>105524247
If I downloaded a Firefox binary what would happen when I updated it would it recompile from source or pull the newest binary from the repo?

I have looked into GUIX a little bit and Debian has a HURD iso. Not sure they're ready yet. I am intrigued though because I need an excuse to use LISP.

>>105524278
The binary is not considered to be a separate package like it is on Gentoo (i.e. firefox vs. firefox-bin).

So basically when you go to install firefox what happens is it looks at the build instructions and generates the hash (as explained in the OP the hash technically includes the entire source code, and the hashes of all the dependencies, etc. So it basically includes information about the entire build-chain for firefox).
Once it has the hash it's then ready to begin compiling, but before it compiles it just does a check to see if there's an already compiled version in the binary repo (with the exact same hash guix calculated, thus you know it was compiled in the EXACT same way). If a version of firefox with that hash exists in the repo then you just download it.
If it doesn't exist then guix proceeds to compile it.

The same thing will happen when you upgrade. It doesn't matter if you downloaded or compiled it last time, it will still download or compile again based on the availability of the hash in the binary repo.

Of course you can also customize this behavior. For example you can disable the usage of the binary repo altogether, and just always compile everything like on Gentoo. Or you can have it simply fail if there's no binary download so it won't compile.

>>105523518 (OP)
OpenGL is a bitch with Nix, especially on non-NixOS. Nix is also the king of wasted space, with unending duplicate packages taking up GIGABYTES and nixpkgs is a dump full of semi-broken packages. It is definitely not the solution to package management.

>>105524484
>It is definitely not the solution to package management.
Let me get this out of the way and say that I don't really care if anyone thinks the specific implementation of these ideas used by Nix or Guix are good enough.
What I'm more interested in advocating is that the core idea behind them is the solution. If you want to wait for some other future project to implement it in some other way that you find more appealing then fine.
But the more I think about it the more I'm realizing that any true solution to universal package management WILL have to look something like this.

The basic idea being that "versions" of packages must be fine-grained enough to encompass their entire build chain, such that changing a single build flag (even on a dependency of a dependency of a dependency of a dependency), then the softwares version changes.
That's basically a requirement for universal package management. Because any solution that doesn't achieve that will mean you're making assumptions about how things are compiled or even just outright limiting how much people can customize their software (which is unacceptable to me).

As for the space it takes up, I would point out that all source-based distros use significantly more disk space than binary distros. Portage uses up a lot more space than apt for example.
Also it doesn't have truly duplicate packages. What it has are the same package compiled in different ways, so they are technically different.
ANY perfect solution to this problem is also going to suffer from this same issue. How do you expect to run software from 5 different developers who've all compiled their libraries in different ways, without having 5 different versions of that library? You can't. Unless you do what most distros do, which is just get 1 version and pray for the best. But that's hardly a real solution.
But guix also makes use of hardlinks for duplciate files that saves space.

>>105524548
What about doing it the fucking windows and mac and android way and let devs supply and maintain the packages and dependencies themselves.
Linux is insane.

>>105524747
>What about doing it the fucking windows and mac and android way and let devs supply and maintain the packages and dependencies themselves.
This has obvious security vulnerabilities, it is unreasonable to expect every dev for every piece of software to stay up to date for all security vulnerabilities. Also usual arguments about meaningless duplication, etc.

>>105524484
>duplicate packages taking up GIGABYTES
it deduplicates though, if you dont want old versions then fucking clean up your generations nigger

>>105524808
Lolwut? As opposed to letting a handful of devs maintaining 50k+ packages by themselves?
Lol
Lmao even

>>105524873
>pacman -S firefox on a clean archlinux install
>Total Installed Size: 947.18 MiB
>apt install firefox-esr on a clean debian install
>After this operation, 801 MB of additional disk space will be used.
>apk add firefox on a clean alpine install
>OK: 356 MiB in 133 packages
>dnf install firefoxon a clean fedora install
>After this operation, 1 GiB extra will be used (install 1 GiB, remove 0 B).
>nix profile install nixpkgs#firefox, followed by a rollback and garbage collection
>1973 store paths deleted, 1184.34 MiB freed
nix is by far the most heavy of the bundle (with alpine being the lightest).

>>105523518 (OP)
>currently 507 build failure issues open on nixpkgs
Nix/Guix trash doesn't solve shit and just creates an overcomplicated mess

>>105524747
Wrong anon, this is not a Linux problem at all, this is a universal problem. Even Windows technically suffers from these same issues.
The real reason these problems have gone so long without solutions is because the problems are so poorly understood.

Windows appears to get around the issue only because Microsoft is the supreme authority on compiling core Windows libraries.
If Microsoft opened up their code and allowed anyone to compile it, then you would have developers making software that won't run on your machine anymore because they used libs with different compiler flags, and all the same issues that you're associating with Linux would arise.

So unless you're proposing that the entire open source world collectively decides on a single definitive version of every library, then this is not possible.
And by the way that could never happen because the very reason Linux is dominating every area of computing except for the desktop (because desktop users don't know anything about computers) is literally because of the ability to modify/compile software in different ways that is suitable to custom hardware.

You say Linux is crazy but literally every fucking website you visited today was hosted on it. And if you suggested they host on Windows they would laugh at your ignorance, because Windows absolutely does not solve any of these problems at all.

>>105524001
>Armageddon
lulwut

Good thread anon. Thx.

Bumping for a good effortpost. One thing I’ll add as someone who’s been using Guix for a couple years now, and this is by no means a problem unique to it: it would be nice if there was a way to include in the package definitions what executables it offers. guix locate kind of works but if you don’t have the package already built locally then it can’t do much. Aside from that it’s basically perfect

>>105527357
If you upgrade something you need to recompile everything that uses it. Guix mostly gets around that with what it calls grafting (basically patching binaries to point to the new version) but when it can’t it has to recompile. If you bump something like gcc then that means pretty much everything has to be checked because, you know, it’s a new compiler

>dependency hell
how the fuck haven't we solved this problem once and for all, why can't you just ship dependencies along with given package?
>muh file size
no one cares
>muh security
just make a standardised set of core libraries that will be be updated just as any normal package and every software piece that needs something from it will first check this core version is applicable and if not just fallback to file that was in its own package
windows does it since 1990 and it somehow works

>>105528039
See >>105525433. Also we already have “a standardised set of core libraries,” it’s called the linux kernel and header files. The problem is that you inherently don’t understand what freedom means

Why add useless complexity just because you fell for a meme? BLOAT BLOAT BLOAT

>>105524808
>This has obvious security vulnerabilities
I don't see Windows, Android or macOS having these problems you speak of.
>muh windoze viruses
Stopped being an argument in the 90s.

>>105528177
>freedom is when you can't run one barely year old ELF binary on current distro version because tree of liberty has to be watered with tears of users or something

>>105523518 (OP)
guix especially looks amazing, though a lot of the bootstrapping goes way over my head, I can certainly appreciate the beautiful ecosystem it creates especially if you are already accustomed to the emacs way of life. That being said, Nix core (which Guix also relies on) is quite a large C++ project and I think a more slimmed down varient of it would help with portability a ton. Guix also relies heavily on glibc :/

>>105528728
Stal/IX

The strongest thing about GNU GUIX is GNU GUILE. It's a beautiful language. A GUIX system configuration file is a beautiful thing to see.

based and +1 for keeping this mainly about Guix, the superior Nix model impl.
>>105528926
>Wayland only
no thanks

>>105529996
Package arcan for it.

>>105530038
oh, hi fellow Arcanbro. our time shall come.

Based.

>>105530062
arcan looks cool as fuck, do people actually use it?

>>105530208
>guix
>monero
Holy GNU/Based & XMRedpilled

>>105530414
not as a daily driver yet, no. those that are interested are waiting for the project to stabilize (it's supposedly entering feature freeze soon), learning and playing with it in the meantime. it only has one example DE made that is specialized for the Arcan creator's own interests, but it also serves as a blueprint of how to make a desktop WM, so it is the main learning resource other than the disparate blogposts and docs.

>>105530208
my nigga

>>105530587
The creator has been posting cool demos for so long, but the only time I ever see in the wild is when that brazilian anon shills his distro that uses it as the default.
>https://eltaninos.org/

>>105530711
>https://eltaninos.org
Interesting project

>>105530208
Do you need GuixOS to make bootstrapable monero builds, or Guix the package manager solely? I'd like to use it on Artix cause Guix generally is stable/outdated like Debian and apt.

>>105523518 (OP)
It doesn't solve package management, it just sidesteps it and leans towards the Windows solution of choosing not to require shared binaries.
Don't get me wrong, I think shared binaries are stupid as fuck and freetards were smugly wrong about this for decades, but the real benefit of having your security patches be nearly automatic is lost in every modern application packaging solution from Docker to SilverBlue

If you lose that, you didn't solve package management.

I've seen some real solutions to package management. There's an experimental programming language called Unison which has a much less fragile versioning system by hashing function definitions

>>105530711
ah, nice. hadn't seen that until now. cool to see a serious usage in tandem with the other projects mentioned on the site.

>>105523518 (OP)
Very interesting. Thanks for posting. Although the hoop-jumping with Nonguix kinda kills it for me. I want something as critical as firmware shipped by my OS distributor, not a third party that the OS distributor opposes.

>>105530208
based sir

>>105528926
>Shell 83.2%
>Python 6.5%
Dropped

>>105523518 (OP)
based thread. may you live long so that you may continue the lord's work.

>>105528533
It would be much easier for chinks to backdoor xz if all they had to do was to ship a compromised binary and before that dev would finish his investigation over performance somehow being worse, the compromised binary would make it to the most of distributions.

>>105532120
>but the real benefit of having your security patches be nearly automatic is lost
This makes no sense, it's not lost on Guix at all.

You're making it sound like if you upgrade a library on Guix that not all software will benefit from that upgrade, as is the case on Windows.
That's not true. When I do a system reconfigure and a library was upgraded then all the software that uses it is upgraded/grafted along with it. So it's still very much automatic. I don't know why you think it's not.

>>105532120
>>105534457
Here, let me explain something that might clarify this issue.

Remember that Guix/Nix define their build records programmatically (Guix uses Lisp, Nix uses its own language).

So from the programmers point of view they specify linking in much the same way you do on a standard distro (i.e. not specifying the exact version).
For example if my software depends on libraryA and I don't care which version, then I'll just say it depends on the variable called "libraryA". That variable is then defined as a package object with a specific version (probably the latest version).
So 90% of software will just do it like that, and they all depend on the same version. So when the system gets reconfigured they all get rebuild or grafted to link to the new version.

There may also be symbols defined for major versions. Like "python-2" and "python-3". And a generic symbol "python" which is just defined as "python-3".
If packages need exact versions then you can define new symbols like "python-3.10".

So the way it's specified in the code is very much like a standard distro. The difference is that the package manager _translates_ that into exact versions for you.

So you basically get the best of both worlds.
You yourself said you didn't like shared binaries, well with Guix you get the benefit of not having them because it links to exact versions.
But you also still get the benefit of the automatic patching.
So actually anon, you should be in favor of the way Guix/Nix works, because it does exactly what you want.

>>105530414
Arcan is very underrated.

>>105528520
>he fell for the le bloat meme

>>105535472
trvke

>>105530711
https://eltaninos.org/roadmap#arcan

>>105523532
Who the FUCK compiles custom versions of dynamic libraries?

>>105524808
>meaningless duplication
If this is the shit that you have to deal with then it clearly isn't meaningless.

>>105523518 (OP)
Did nix recover from Rust 1.8 breaking thousands of packages yet?

>>105541725
Sounds fun

How far away is Guix from being able to run Wine (for muh vidya) and not fuck my shit up just because I have a noVidea graphics card?
99.9999% of all people I see running guix are doing so on shitpads that can barely browse the web or in headless rigs that they ssh in every month just to check if their shit is still running.
I want to USE my PC, if all I can do is post my neofetch on the desktop thread there's no point on using it.
Gentoo(+systemD, as goD intendeD) works perfectly fine and I've never encountered any issues with it (other than my own fuckups), but I'd love to use Guix as I'm an emacs enjoyer, I just can't justify kneecapping myself for it.
I also used NixOS, it's alright, but nixlang is dogshit, the documentation is nonexistent and I'm not willing to fucking waste hours searching random places for simple stuff that should be on their wiki.

>>105542117
>How far away is Guix from being able to run Wine
Wine’s already in the core packages. How well it works probably comes down to configs and njudea not being intensely jewish (if they are, which is likely, the drivers are probably in nonguix). As for the rest, I personally use the Guix package manager on top of Debian stable. The core system just fucking works and user space is still highly configurable

>>105541725
>Rust 1.8 breaking thousands of packages
Many such cases

>>105542117
There is the "nonguix" repo which will give you the standard Linux kernel and firmware. It also has packages for proprietary nvidia drivers (and steam).
Although I've heard that the nvidia package still gives people problems. Really I can't say I'd recommend making the leap unless you're using AMD.

>>105543840
>tfw have Guix flash drive ready to go on my desktop with a RTX 3080
At least it's not some laptop switchable GPU shit.

>>105541468
Interesting
https://eltaninos.org/docs/tutorial-pm/venus

Correct me if I am wrong, but Nix solves reproducibility better than even containerization can due to the hashing of package versions. Nix as a development environment, has been comfy AF lately, where I literally don't need to have dependencies installed on my machine, they are all contained in a flake.nix, which gets spun up with database and all. Way easier than even docker-compose.

At the OS level, NixOS does seem to be the way to reproduce a machine with the least amount of effort due to declarative package management. Guix has the issue of not providing non-free packages (which for any Nvidia stuff is going to fuck your shit up). Nix does seem fairly endgame, this coming from someone that was a huge Debian stable advocate.

>>105545297
Nix and Guix definitely feel like they’re what package managers are supposed to be. The only downsides I’ve seen are that the commands themselves are kind of slow (fair), the stores use more storage than apt or pacman or whatever (completely worth it), and that configuration is confusing (at least at first). What I’m trying to say is who the fuck needs dockerfiles when you can define everything in one programmable and perfectly reproducible manifest/flake?

>>105545222
>It's a functional package manager (declarative, reproducible and atomic) scheme built upon the redo build system.

>>105545297
>non-free packages
Nonfree packages are neither reproducible nor bootstrappable. I prefer the way Guix works: the main repository contains only FOSS stuff (all reproducible & bootstrappable), while Nonguix contains all the nonfree shit. Debian also works like this, if I remember correctly. It just works better.

So...
/g/uix > /g/entoo?

Install /g/uix?

>>105542117
i use Guix on my desktop PC perfectly fine, using nonguix and easily playing vidya through Steam. but yes, i am using an AMD card and haven't tried nvidia with it.

>>105528177
>we already have “a standardised set of core libraries,” it’s called the linux kernel and header files.
Kek

>>105545222
>>105546933
crazy how that went full circle. Found the source here
https://github.com/eltanin-os/venus
wonder how it compares to ix? On the topic of reproducible, declarative package management, I've always been intrigued by the process used for oasis linux. Though not nearly as powerful as some of the other options, it does seem like the most minimal and 'suckless' approach
https://github.com/oasislinux/oasis

>>105523518 (OP)
good effortpost
just a lowly nixlet tho, kinda wana switch to guix but not sure it's worth the time and effort just for the scheme

GNU Edolstra

>>105551980
Do it for the autism, anon. I believe in you.

>>105551980

run an experimental instance. Nothing mission critical.
Once you get GNU Guix, I recommend to install DOOM EMACS with GNU Emacs Ares and GNU Emacs Arei. Those tools allow interactive programming in Guile. It is an effective nREPL server for GUILE, as a far as I understand it. It works as such. Once everything is set up you will realize how beautiful the whole thing is.

You load the functions live from the source code with a chord, and you can see the result live as you go.

https://git.sr.ht/~abcdw/emacs-arei
https://git.sr.ht/~abcdw/guile-ares-rs

>>105553924
Why couldn't they just use Common Lisp?

>>105555054
RMS scheming
>From: Richard Stallman
>Common Lisp is extremely complicated and ugly. When I wrote GNU Emacs I had just finished implementing Common Lisp, and I did not like it much. It would bloat Emacs terribly, and documenting it would be hard too.
>Scheme is elegant, and it is a better direction to move in.
>Since we have our own Scheme implementation, we should use that one. If it has a serious disadvantage, we should do something about that. There are various things that might be right to do, but simply disregarding it in the case of Emacs cannot be right.
https://lists.gnu.org/archive/html//emacs-devel/2010-04/msg00612.html

>>105555054

I understand GNU Guile is composed in such a way that any software written with it is shielded by the GNU Affero License, so companies or commercial interests cannot use it legally because they are forced to share their source code to be license compliant. This is done to make the project independent of power actors.

The Nix ecosystem instead is a private company friendly endeavour. The project is being supported by some heavy hitters. Even Edolstra created a start up where he provides consulting services to enterprise customers. I wonder if he is doing alright.

>>105555175
>GNU Affero License
Guile is LGPL-3.0.
https://cgit.git.savannah.gnu.org/cgit/guile.git/tree/LICENSE
>so companies or commercial interests cannot use it legally
How so? These same companies are using Linux (GPLv2) and Git (GPLv2) in production every day.

>>105555259
Even Nix is LGPL.
https://github.com/NixOS/nix/blob/master/COPYING

>>105555259
>>105555285
I did not know about this.

Well established highly regulated companies evade the GNU license family like kryptonite.

>>105527611
>guix locate
Pretty nice.

Companies cannot implement trade secrets under the AGLP License.

>>105557637
So companies cannot use linux?

>>105558836
(((Companies))) love BSD or something

>>105555344
>GNU license family like kryptonite
Good.

>>105551497
>https://github.com/oasislinux/oasis
Interesting

>>105533642
It’s pythover

>>105564287
it's pythonic slow

>>105525092
>currently 507 build failure issues open on nixpkgs
yes because the nix devs are retards who think bigger package number = better. they just auto-import entire language ecosystems and don't test anything

>>105566013
another reason why Guix is better. default to official Guix channel for actually stable packages and opt-in Nix module if i ever need to temporarily use something bleeding edge or missing.