127
Why aren't more people using NixPKGs?
(lemmy.world)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 18 Feb 2024
127 points (93.8% liked)
Linux
48138 readers
512 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 5 years ago
MODERATORS
In terms of the memory usage, it's a reasonable approach these days. It gets hairy when we consider security vulnerabilities. It's far easier to patch one system-wide shared library than to hunt down every single application still bundling a vulnerable version.
The nice thing about Nix/Guix is that each version of a library only needs to be installed once and it wont really be "bundled" with the app itself. So it would be a lot easier to hunt down the packages that are depending on a bad library.
Nix is a bit of a middle ground. Each package has a specific set of dependency version. It calculates the hash of each dependency and compares it to those that you have installed. If it is installed, it uses that, if it isn't, it installs it. This means that packages can have different versions and dependency hell is impossible, whilst also reusing existing dependencies if they're the exact same.
You've just answered a question I didn't realize I had.
If you use any accelerated graphics (GTK4 anyone?), you cannot and must not bundle all your dependencies.
Conceptually, graphics drivers have two parts: The part in the kernel (e.g. amdgpu), and the part loaded as a library from the system into the application (e.g. Mesa).
Mesa - or any other GL/Vulkan implementation - is loaded from the system into the application as a library. Mesa relies on system libc, system LLVM (!!!!), a particular libc++, etc.
If you ship libGL (and LLVM etc), you must re-release your software with upgraded deps whenever new graphics cards are released (and should whenever bugs are fixed). Your software is literally incompatible with (some) newer computers.
For the proprietary Nvidia libGL - which, again relies on system glibc - you can't legally include it.
Flatpak solves this by separating out 'graphics driver libraries' as a unique type of runtime, and having a shitload of special rules & custom hacks to check the system libGL, open source or proprietary, maybe substitute a Flatpak provided libGL, with all the deps that libGL needs, and make it compatible with whatever app & whatever app runtime.
Actually correctly solving the libGL debacle is half the value of Flatpak to me.
Well the issue for me is internet speed, yesterday night I had to leave my pc on for two hours to update my flatpaks, I don't even have that many of them, but the updates were mostly drivers and runtimes.
Windows apps have been doing this for ages with disasterous security results due to the lack of mandatory OS sandboxing. E.g. CVE for admin level RCE via Adobe Flash. This model works with third party apps only when sandboxed. This was done from the get go on Android and now with Snap and Flatpak (I assume). It's absolutely the way to go once the security framework is in place.
I love it when every basic application is an entire operating system under the hood