Remote View

10mo ago

Why aren't more people using NixPKGs?

Distro agnostic packages like flatpaks and appimages have become extremely popular over the past few years, yet they seem to get a lot of dirt thrown on them because they are super bloated (since they bring all their dependencies with them).

NixPkgs are also distro agnostic, but they are about as light as regular system packages (.deb/.rpm/.PKG) all the while having an impressive 80 000 packages in their repos.

I don't get why more people aren't using them, sure they do need some tweaking but so do flatpaks, my main theory is that there are no graphical installer for them and the CLI installer is lacking (no progress bar, no ETA, strange syntax) I'm also scared that there is a downside to them I dont know about.

114 comments

One reason is probably that people don't know about them.

As you can see from the state of this thread, people see nix or nixpkgs but read nixos. There's no momentum from the community to push it as an extra package manager, while every thread is spammed with nixos.
No gui integrations for casuals. For example Discover integrates flatpaks and snaps, but for nix you need to use the terminal.
The documentation is abysmal. I spent days trying to figure out how to use nix as a declarative package manager before I accidentally came across home-manager. Even the manual leads you down the wrong path. A quick start guide with a few examples for home-manager and flakes, and a few basic commands, would've had me going in 5 minutes. That problem is made worse by the fact that almost all sources of info focus on nixos instead.
Edit:
if anyone's interested in trying it out, here's a part of my other comment in this thread
It's just a list of packages, and an optional flake to control the repositories (stable/unstable) and add packages from outside of the official ones.
To update everything nix related I just run:
cd ~/dotfiles/nix/ && nix flake update && home-manager switch
- Yeah, if it wasn't for my niche needs and desires of using my SteamDeck without touching the system partition, I probably wouldn't have messed with Nix because of how much of a confusing mess of modes and switches there are, and I've used terminal based package managers for years. It's very far from the simple "it just works" of Flatpaks.
  
  Imagine this: a quickstart script to install nix and home-manager, and generate an example home.nix and it's flake. If those files included a few comments on basic usage and what commands to run in order to install and update everything, I legit wouldn't have had to google anything.
  Literally: here's a list, this is how you add packages to it, this is how you ensure everything on it is installed to the newest possible version, enjoy!
  It's not click flatpak in a GUI level of simplicity, but it would've saved me days of frustration.
  
  https://linuxgamingcentral.com/posts/steamos-getting-nix-support/
  Dunno if this ever came to fruition though.

Because it has abominable documentation. Some tools built on top of nix on the other hand have stellar documentation (devenv and jetbox come to mind). The tools even try hard to hide nix because they know it's a goddamn nightmare for beginners to use it.
The CLI is a mess due to the indecisiveness of the nix maintainers whether they want flakes or not. So much so that the official manual doesn't use flakes, but many guides on the internet immediately go into nix dev#yadadada which leaves beginners and mid-term users alike very confused.
Another point is that graphical applications can't use OpenGL without dirty hacks like nixgl. Not only that, installing GUI applications using nix doesn't make them show up in your desktop environment (start menu, finder, whatever). No, you need to either manually create .desktop files or install another tool like home-manager to have them show (and not work properly because of OpenGL).
To top it off, unless you know better, it's command-line only. SnowflakeOS is building GUI tools around nix, but they aren't like say Discover or the Gnome Appstore: you can't install the GUI and have everything working - no, you need to figure everything out.
In short, nix is absolutely nowhere close for desktop user adoption, much less mainstream linux adoption (dev, sysadmin, tester, or whatever other technical role exists).
CC BY-NC-SA 4.0
- Flakes confuse me.
  Guides online say "oh yeah just do this, it's easy" and don't mention flakes at all.
  So I try the thing and it says ARE YOU FUCKING SURE, YOU IDIOT, YOU ABSOLUTE MORON, YOU CAN'T DO ANYTHING WITHOUT ENABLING FLAKES AND YOU HAVEN'T DONE THAT SO YOU CLEARLY DON'T DESERVE NICE THINGS but like, is there just no non-flakes version of that thing, what's the point of having an option that's not enabled by default if you can't do anything without it on
  @moonpiedumplings@programming.dev shares my pain and also explained what I was doing wrong:
  https://programming.dev/comment/7537131
  
  Flakes is still experimental. NixOS devs takes a bunch of time to release that. So most experienced users have enabled Flakes since years. Two different systems are available, which does not help ease of learning.

Learning curve? I've meant to get around to it but my to do list is pretty big so far.
Nix is on the destinations to visit but the configurations are still confusing at a glance.
- If you use Nix the imperative way (nix profile blah), you don't need to learn the Nix language at all, or write config files. Installing/removing/upgrading packages is just a single command, similar to other package managers.
  Eg:
  To search for bat on nixpkgs: nix search nixpkgs bat
  To install bat: nix profile install nixpkgs#bat
  To upgrade all packages: nix profile upgrade '.*'
  Ref: https://nixos.org/manual/nix/stable/command-ref/new-cli/nix3-profile
  
  Or just home-manager with a list of packages, and you avoid all of the issues imperative PMs have.
- Stop making a list and start with eg: Nix Pills

I'm going to go against the grain and say that the Nix and Guix package managers are very good, but they really belong in their respective distros where they're a core part of the system. That'd be Guix System for Guix and NixOS for Nix.
They may have advantages for a foreign distro too, but they are lesser (Guix System can boot into a backup of the system before the last update, for example, but that advantage doesn't exist on, say, Debian.
Also, can we agree to not recommend these systems to new users for the time being? While they're very powerful, they're absolutely designed for power users, and until they're more polished and they have fancy GUIs and stuff for installation and package management, I think it'd be best to keep recommending normal distros like Debian for now.
- You can do rollbacks if you're using something like home-manager on a foreign distribution. It's just a bit more janky admittedly.
- Guix System can boot into a backup of the system before the last update, for example, but that advantage doesn't exist on, say, Debian.
  Yeah, why would I ever want to have bleeding edge userland packages on Debian? Nobody needs something like that or the option to rollback the entire update or pin specific versions of packages...
  Also, can we agree to not recommend these systems to new users for the time being?
  Did anyone do it in this thread? OP is literally just asking about a list of packages to home-manage. Beginners can most certainly handle it if they don't need a gui to update their system.
  
  No, nobody did mention it, I was just making a side-point.
  I also said there are advantages to Guix/Nix on foreign distros.

I maintain some software, and Nix is by far the hardest to deal with. To package config files are relatively complex, and to submit a package you have to download the entire Nix repo, which is huge. Getting a package to build correctly can be a challenge.
It's a pretty large ask for software contributors, who may have to iteract with a half dozen different distros. Now, you could say, leave it to the distro people to do the packaging, but it remains a barrier for entry and is by nature exclusive.
I don't use NixOS, so I have little motivation to stay conversant with Nix and, frankly, it's so demanding I don't bother anymore. I can make RPM, deb, and aur packages trivially, and without having to hold Gb of some package repo (which I otherwise don't use) on my disk.
- git clone --depth 1 will clone a git repo without older stuff. Without this, the nixpkgs git repo is like 13-14 GB, but with a depth of 1, it's only 200 mb.
- If you maintain upstream software and do not have an interest in learning and using Nix, please don't put the burden of packaging software in Nix onto yourself. Nobody in their right mind would expect you to package anything for a dozen distros; that's not how distros are supposed to work.
  Leave it to someone who is interested to package your software in Nixpkgs. Your "job" is to make your software better and provide a sane way to build your software that packagers can rely on (i.e. no assumptions where things are or are supposed to go, document your dependencies and build processes).
  If you do want to go the extra mile, offer your help in assisting packaging in the appropriate channels. You know the technical details of your software and Nix users how Nix packaging works but the reverse mostly isn't true, so cross-pollination can be super helpful here.
  Even just things like testing that your software works as you expect when the packaging is touched in some way (i.e. an update) is incredibly helpful. (If saw a package update PR with the upstream maintainer's approval stating that it works as they expect, I'd merge immediately.)
  If packaging for Nix is a burden for you, please just open an issue on Nixpkgs with links to your packaging/build documentation and let someone else do it for you.
  As a Nixpkgs committer, I'd much rather have someone invested in Nix build and maintain a package than an upstream maintainer who somehow feels obligated to do so but has no experience or actual interest as the former is more likely to produce good code and keep maintaining the package.
  
  Sure. My point is that it's trivial to make and test packages for many distributions; it is harder to do so for Nix. It tends to get your software out there and used faster if you bootstrap the packaging - immediately, if you have an AUR account.
  IMHO, Nix is unreasonably harder. There are frequently small projects that don't get packaged for most distros. When I encounter these, I have a couple of options:
  Submit a packaging request. Hope someone is willing to accept it. Wait until it is packaged.
  Install it from source and let it pollute the core system. Hope this causes no issues. Manually track and maintain the installation. If lucky, the software lets itself be installed somewhere non-standard, in which case I can use stow and keep things a bit cleaner.
  Throw together a package for it and let my distro manage the installation.
  The third option is preferrable to the others, for a variety of reasons, and it's easy on most distros. On Arch, I might submit the package to AUR, but I'll often just make a -git package and install it locally.

the aur has everything I need

Part of the reason is that people are still finding out about it, Project has no marketing so it grows organically, in the last year the number of contributors grew by 25 percent.
Another problem is that it still needs polish in term of ease of use, for example it takes me forever to search for packages using the nix-env command but using the website it takes less then a second, That's a basic feature that still does not work correct, Plus their documentation is still not great in my opinion, I actually helped improved it and the improvement they made is still not really good IMO.
- It's cause you're not actually supposed to use nix-env: https://stop-using-nix-env.privatevoid.net/
  You're actually supposed to be using nix search nixpkgs#packagename to search and nix profile install nixpkgs#packagename to install.
  However, to use both of those, you need to have the "experimental" (not really though, most of the community uses them) features of nix-command and nix flakes enabled, which they aren't by default.
  And of course, nowhere on the main documentation did I find any if that, I only found it via the pain of using it wrong, and forum posts.
  Nix's documentation is horrific. I've had situations where I only got help via discord...

For me personally, I just haven't taken any steps into the nix environment. Seems rather complex, setting up those nix files and stuff.
I use Debian on servers and LMDE on my PC, most things I need are in the Debian repos and for other cases I get by pretty good with appimage s and flatpaks. Installing is just a simple command and me happy.
Nixpkgs are probably easy too, I assume. I know a lot of people really like nix, but the effort required to start seems significant to me, especially when we have other methods that just work.
- Nixpkgs can be used without knowing anything about nix. You can install almost anything by just running e.g.:
  undefined
  
  nix-shell -p cowsay
  The requirement for that is the nix package manager but that should be easy to install. But yeah getting into Nixos with flakes and all that stuff can be hard.
  
  So I can in theory just do apt install nix-shell (or whatever), do something like nix-shell -p curl and then curl just works?
- the effort required to start seems significant to me, especially when we have other methods that just work.
  It's just a list of packages, and an optional flake to control the repositories (stable/unstable) and add packages from outside of the official ones.
  To update everything nix related I just run:
  cd ~/dotfiles/nix/ && nix flake update && home-manager switch
  I've only included a few packages from the actual list, but you can see how simple everything is. It just took me days to get to that point because the docs are really bad.
  most things I need are in the Debian repos and for other cases I get by pretty good with appimage s and flatpaks.
  I use it to freshen up Debian packages. For example Debian docker is like 4 major versions behind the nix one, and it stopped being supported months ago.
  Also, now that I've created the list from above, I can just run a single line to reinstall everything I need.
- Why don't you just install nix on debian and see

You're not exactly comparing apples to apples here.
Flatpak and appimages tend to be used in any distro because they can just be downloaded in a one off manner and installed then you're running the application (for the most part). They offer a manager of sorts but you don't need it to use the packages.
For nixpkgs, whike I'm sure I can get a package from the sounds of the sizes the package covers only the application or the library, meaning I still need the dependencies.
So what exactly would make me the user trade my built in tools (apt/pacman/dnf) for nix? Keep in mind no matter how great you feel it is, you need to provide reasoning that motivates me to install and learn this new tool instead of the old ones I have.
- Flatpak still depends on runtimes though, I have a few different runtimes I had to install just because of one or two flatpaks that required them (like for example I have both the gnome and kde flatpak runtimes, despite not running either of those desktop environments)... and they can depend on specific versions of runtimes too! I remember one time flatpak recommended me to uninstall one flatpak program I had because it depended on a deprecated runtime that was no longer supported.
  Also, some flatpaks can depend on another flatpak, like how for Godot they are preparing a "parent" flatpak (I don't remember the terminology) that godot games can depend on in order to reduce redundancies when having multiple godot games installed.
  Because of those things, you are still likely to require a flatpak remote configured and an internet connection when you install a flatpak. It's not really a fully self contained thing.
  Appimages are more self contained.. but even those might make assumptions on what libraries the system might have, which makes them not as universal as they might seem. That or the file needs to be really big, unnecessarily so. Usually, a combination or compromise between both problems, at the discretion of the dev doing the packaging.
  The advantage with Nix is that it's more efficient with the users space (because it makes sure you don't get the exact same version of a library installed twice), while making it impossible to have a dependency conflict regardless of how old or new is what you wanna install (which is something the package manager from your typical distro can't do).
  
  All of these points are completely correct and paint an accurate picture of the inherent issues with both technologies.
  My intent with my earlier comment was to show how flatpaks and appimages were different from traditional package managers at a high level so I could ask what made nixpkgs different from something I felt and still kinda feel is a more accurate comparison which are traditional package managers like apt etc.
  The big selling point to me now is that nixpkgs seem to work similarly to virtualenvs from Python which is cool.
- For nixpkgs, whike I’m sure I can get a package from the sounds of the sizes the package covers only the application or the library, meaning I still need the dependencies.
  When you download/build a nix package, nix will absolutely also download all necessary dependencies.
  So what exactly would make me the user trade my built in tools (apt/pacman/dnf) for nix?
  Getting a shell with a specific package as a one off. Want ffmpeg? nix-shell -p ffmpeg opens a shell with ffmpeg in its path, and only that shell has it.
  Along with that, that means users can install packages for themselves. Limited use for single-user systems, but nonetheless it's possible.
  Per-project dependencies. Pretty much the same as above, but the dependencies are declared in a file which is part of the project. In many cases that same file can also be used as a nix package itself, like any other in nixpkgs. Very useful if you write software yourself. Here's an example.
  Being a source-based package manager with a cache means that you get all the benefits of prebuilt packages but can easily patch or use other versions of a package, with no difference in use (other than that it will build it locally instead of downloading from the cache).
  On a distro with a different main package manager I would probably mainly use it for per-project dependencies though.
  
  I often stumble on this example of nix usage - a one-off shell with a a specific package. This is such a niche and seemingly unimportant use case, that it’s really strange to have it mentioned so often.
  Like literally what’s the point of having a shell with ffmpeg? Why not simply install it? Even if you need something just once, just install it and then uninstall it, takes like 10 seconds.
  The other use case that is often brought up is for managing dev environments, but for a lot of popular languages (Python, Node, Java, Rust, etc. ) there are proven environment management options already (pyenv and poetry, nvm, jenv, rustup). Not to mention Docker. In the corporate setting I haven’t seen nix replacing any of these.
  From my limited experience using home manager under Linux and macOS:
  GUI app shortcuts work in neither of the OSs
  error messages are about as readable as the ones you get for C++ templates
  a lot of troubleshooting searches to unsolved GitHub issues
  All in all nix seems like a pretty concept but not too practical at the moment.
  
  So it sounds like nixpkgs is more akin to virtualenvs in Python rather than a traditional package manager. Is that an accurate statement?
  If so, I'd recommend that be your selling point because that's some powerful security.
  
  docker run --rm -ti -v "${PWD}:${PWD}" -w "${PWD}" ffmpeg gets me most of the way there. I alias commands like this all the time.

The way nix installs in my root directory in another distro is a no-go for me
- I can reassure you that it does not encroach on anything the "host" distro package manager does and does not cause conflicts with it.
  At runtime, it only ever touches things in `/nix; it's self-contained.
  The only time Nix needs to interact with the host distro in any way is during install where it must place a little glue in your system configuration for things like PATH, bash completions or the nix-daemon to work as expected.
  
  IIRC it puts a user owned directory inside the root. I have no clue what the total implications are in respect to privacy and security.
  The last time I looked the NIX solution to secure boot keys was to disable secure boot, making the largest attack surface on modern computers completely unprotected by default. The idea of leaving it up to the user to figure out keys and self signing was a giant red flag for me. My current workstation requires a shim as the bootloader that came with the device rejects custom keys and I didn't care to figure out Keytool on my own to boot into UEFI and try to change them by force. That knocked NIX off my list of complete distros to run. While I don't know the implications for the NIX package manager on another distro, this is the combination of real factors that formed my chain of reasoning about using NIX in both respects.
  I also ran arch for a few weeks once and am now extremely skeptical of any distro that presents anything that hints at "you figure it out yourself" complications for basic function. After Arch I went to Gentoo back when the Sakaki guide still worked and that was much more my style. I had something that just works, and made extra complications much more approachable. Specifically, I found documented entry points on things I didn't understand, approached in ways I found useful. I don't recall exactly what I was trying to do at this point, but with NIX I spent a couple of days trying to figure out stuff and went in circles. I think I had come across a NIX package for KoboldCPP and tried a bunch of stuff that didn't work.
  Anyways, I have nothing against NIX and might try it again one day. This is not bashing on NIX, or calling it inadequate. This was just my experience as a dumb user.

Pacman (and paru and the AUR) and chezmoi works fine, I don't see any reason to switch.

yeah, everybody should use them. I usually write my own kernel mods tailored for my hardware and certain needs, I don't know why not everyone is doing that. admittedly is a bit janky maintaining a separate kernel fork, but you get used to it, everyone should do it

Inate complexity that keeps moving as they introduce things like flakes.
Its a declarative configuration management system as package manager. Thats a lot more to handle off the bat than normal linux + flatpak.
- Inate complexity that keeps moving as they introduce things like flakes.
  Flakes solve the problem of reproducibility for which nixpkgs (or other external input) revision to use (e.g. in a software project). The main thing they bring is a npm-like lock file and a predictable interface. You don't have to use them if you don't want that.
  Its a declarative configuration management system as package manager.
  No it isn't. That's NixOS, which is another thing built on top of Nix and nixpkgs. nixpkgs is first and foremost a package collection.
  
  Say, did nix take inspiration from. npm? That would certainly explain a lot of things...
- It is a whole ecosystem:
  Nix the package manager
  Nix the functional language used to declare packages and configurations
  NixOS that has the package manager and a system configuration in the functional language
  Home Manager, which provides a configuration on the user level and can be used on NixOS as well as other distros and MacOS
  To start out it's completely fine to just install Nix the package manager on a regular distro or on MacOS and use the nix-env command to install some packages. It will automatically use nixpkgs and use working dependencies for each package, whilst also checking if the depency is already installed to avoid installing the same one twice. This is pretty much the same thing as using Flatpak
  Flakes explanation:
  The Nix package manager has channels to manage package repos. It works like package managers on other distros where you simply have a list of urls to pull packages from, with Nix it would just be the nixpkgs release either a version number for stable or unstable for the unstable rolling release. Any time you install through the package manager or the config in NixOS, it will get the packages from the channel.
  The problem is that the channels aren't very reproducible. The repos get updates regularly, especially unstable which updates even faster than Arch. Channels don't provide an easy way to specify a single commit of the repo, except for entering a url with the commit version in it. For stuff like a shell.nix, you'd need to either import nixpkgs from the system's channel or import the url of nixpkgs with a specific commit ID.
  Flakes is a feature that for some reason is still experimental after years, but many are already using it. It works like manifest.json and package.lock in a JavaScript project. You have a directory or git repo with a flake.nix file in which you specify your external dependencies like the nixpkgs release in the "inputs" section and your outputs in the "outputs" section, like a NixOS/Home Manager configuration, a shell or a package. Then when you use an output, Nix pulls the inputs and builds the output, it then generates a flake.lock file that contains all the inputs with their specific commit and hash. Now if you use an output again later with the same flake.lock, it will still use the exact same version as last time and should generate the exact same outputs. You just run nix flake update to generate a new flake.lock with new dependencies. You can't use flakes with nix-env simply because installing packages imperatively without a config file defeats the point of reproducibility with flakes.
  Flake example with Home Manager:
  undefined
  
  My Flake Repo/ ├── flake.nix - nixpkgs input and home manager configuration output ├── flake.lock - generated by nix └── home.nix - home manager config import from flake.nix
  Here the home.nix file contains the config with the list of packages to install as well as configuration options for those programs. The flake.nix contains the nixpkgs input and a homeManagerConfigurations output that import the home.nix. You can run home manager switch --flake ./My Flake Repo to use that config from the flake. To update run nix flake update.
  
  I appreciate the breakdown, but you've basically made my point for me.
  The above, with its many advantages, versus:
  Sudo apt install X Y Z G F P -y
  Simple, clean, gets it done for near anyone.

I use NixOS on my personal machine and nixpkgs on my work Ubuntu (22.04 LTS). In the absence of NixOS I would not be using it: it somehow breaks all the file (open, save, etc.) windows, causing any app that tries to open one to crash (particularly annoying for browsers).
Not to mention the wrapGL issue.
It needs more polish on "genericlinux". I did previously use it on MacOS, and it did make MacOS almost bearable - definitely years ahead of brew.

NixOS sounds amazing in some regards, but I'm not really interested in learning a whole programming language for it... I have enough to do already.
- The nix package manager can be used on any os and doesn't require usage of the nix programming language..
- Note that Nix is not a full-blown programming language, it's an expression language. The end result of an expression is always data and side-effects are not possible; you can't do network requests or write to arbitrary files. There is no such thing as a variable in Nix either, only constants. You can think of it like JSON with (pure) functions and an additional data type (~package).
  From a user perspective, it's really not very different from any of the other 100s of weird configuration syntaxes you've surely come across in your Linux journey.
  My nixos-config is a bit more complex because I like to reap the benefits that abstraction but here's a simpler section that is representative of how a typical NixOS desktop config would look like:
  https://github.com/Atemu/nixos-config/blob/ee2d85dc3665ae3cad463a3eb132f806651fe436/modules/desktop/module.nix#L16-L77
  (Though note that even this is slightly more complex than what you'd do when starting out; ignore the LADSPA_PATH and tablet conditional for now.)
- Did OP mention nixos at some point?
  
  No, but the top-level comment you're replying to is a perfect response for the OP because of what it demonstrates.

Nix is the vim of package management but without good documentation. So it's incredibly powerful and useful once you get into it, but imagine trying to learn vim without any docs or guidance. Vim has a steep learning curve with good documentation, YouTube tutorials, blog posts, and forum guides.
Nix doesn't really have a wealth of that.
That's nix package management and nixos in a nutshell.

Steam Deck is using Flatpaks so.....
- You can also use nixpkgs and AppImages on SteamOS.

How does it solve the problem of dependencies without becoming bloated?
- From what I gather it goes something like this:
  every package is assigned a hash
  every package lists their dependencies through their hashes
  different versions of packages have different hashes
  when you launch an application it creates an environment with all its dependencies, this means that two applications that both use the same library at the same version share that library. However if they both require the same lib but not the same version of that lib they don't share it.
  Which solves DLL hell as far as i understand it.
- By not being a universal packaging format. It uses your system libraries, which completely eliminates the main reason devs are pushing for things like Flatpak, Snap, or Appimage.
  
  It doesn't use the system libraries, unless the system in question is NixOS. It still provides its own dependencies. Arguably in a more elegant and less wasteful manner, but they are still distinct from the ones used by the rest of the system.
  EDIT: typo
  
  Huh? as far as I know it has its own libraries and dependency system. What do you mean?

Was curious myself don't like flatpaks & appimages much, but from a quick googling, they don't seem to integrate with the desktop so you need to launch them from terminal? That is a deal breaker for me at least.
- you have to set up the XDG_DATA_DIRS environment variable to take into account ~/.nix-profile/share the desktop icons will only appear after a relogin though.
  
  It's automatically set up alongside PATH

My guess would be that it's because Flatpaks are easy. You have a handy GUI tool often pre installed that includes search and one-click install.
If you want something lower level, Arch users have the AUR, and others may actually do that horrifying curl https://... | sh pattern.
Nix pancakes on the other hand.... I have no idea how to use them and generally assume it's the thing NixOS uses. Since I don't use NixOS, I've never given them a second thought.

Because nixPKGs have the same Single-Source of Truth wrecking problems as flatpaks and appimages and all that junk.
There's only so much room in the ecosystem for best-practice-violating product, and systemd takes up a lot of that. And until systemd collapses under the weight of doing a thousand things poorly for all the wrong reasons and delivering on none of its brochure features, the other entrants have to wait outside.
- As a largely non-technical linux enjoyer I have such a hard time understanding why people hate systemd so much. If I switched to a distro that uses another init system would my experience be better?
  Like I get that the complaint is partially the philosophy, but it sounds like you also have problems with it in practice and I just can't really relate to that. I dunno, maybe I just wouldn't notice if there are problems happening with how my init system is working 🤷

I'm already using more than I would like to they are complete TRASH.

114 comments

Flakes explanation:

Flake example with Home Manager: