_fsql

It's a reproducible thing, until the pile of crap in the abstraction layer they built with Nix on top of Linux fails for any number of reasons, whether they redefined a variable, removed it, direct flaws in the NixOS or Linux mechanisms below or something else.

Another fork, similar to what happened with other Linux projects regarding systemd. The difference is that in NixOS and now SixOS (SexOS), things are more dramatic, and they love piling up a bunch of complex and unnecessary crap on top of Linux. :D

When it's finished and stable.

Sure, but tell me: How often do you see NixOS used as a file server, enterprise app server, in the cloud, as a web server, for big databases, email server, backup server, firewall, satellite server, in labs, banking, or critical mission servers? The answer is clear—hardly anyone uses NixOS in those roles unless it's for something experimental.

You shouldn't use something experimental like NixOS and Nix at work, that's fine at home or as a hobby.

The only thing missing from the article was to say that Ballmer loved Linux and open source but that he was misunderstood lol. Ballmer was a fucking despot and a piece of shit. That article is an ode to the disgusting despotism that Microsoft had.

If NixOS works well for you, that's great! But from my perspective, the whole NixOS model adds unnecessary complexity and makes you learn ways to do things that don’t really translate to other Linux systems. The directory structure in NixOS is different and doesn't follow the FHS (Filesystem Hierarchy Standard) and the system uses a bunch of symbolic links that feel like "hacks" to keep some kind of compatibility with the FHS.

For example, if you want NixOS to recognize paths like /bin or /usr/bin in your scripts, you have to enable services.envfs.enable in your configuration.nix or in a .nix module. If something goes wrong in NixOS, you might run into multiple issues because the problem could be within NixOS, the underlying system, nixpkgs, upstream packages, or a mix of all these factors.

Sure, it might save you time in some situations, but when a problem pops up, you'll find yourself in a tricky spot since you’ll have to dig through all the layers of the system to find the root cause. On top of that, you’ll have to sift through the options and the documentation, which can often be pretty confusing.

No, I like it practical and without such stupid design choices.

Well, with Haskell you know what it is oriented towards and you know what to expect, but Nix wants to control everything in the system by adding unnecessary complexity to the simple and making the complex even more complex.

If Guix were an optimal solution, many companies would be using it, but that's not happening. It's just a niche experiment. And parentheses don't seem so bad when the code is one line, when tens or hundreds of lines won't be so fun.

With NixOS, you simply use Nix to configure a file that in turn configures other files that configure other packages, and you have to rely on the new path and variable definitions created by the maintainers of NixOS for upstream programs. So, you need to learn that if the program used A, in NixOS it's B -> A -> does the job (although it's not that simple). That's why, when you use NixOS, you feel like you're working twice as hard, while Arch Linux aims to be transparent by exposing the system structure without adding a ton of crap complexity like NixOS does.

NixOS has very limited usage, with few companies adopting it for critical or commercial tasks. It is more common in experimental niches.

One of the main issues with nixpkgs is that users have to rely on overlays for a package. This can lead to obscure errors because if something fails in the original package or a Nix module, it's hard to pinpoint the problem. Additionally, the overuse of links in the directory hierarchy further complicates things, giving the impression that NixOS is a patched and poorly designed structure.

As someone who has tried Nix, uses NixOS, and created my own modular configuration, I made optimizations and wrote some modules to scratch my own itch. I realized I was wasting time trying to make one tool configure other tools. That’s essentially what NixOS does through Nix. Why complicate a Linux system when I can just write bash scripts and automate my tasks without hassle? Sure, they might say it’s reproducible, but it really isn’t. Several packages in NixOS can fail because a developer redefined a variable; this then affects another part of the module and misconfigures the upstream package. So, you end up struggling with something that should be simple and straightforward to diagnose.

Guile and Nix are horrible languages with shitty syntax, the difference is that one is general purpose (Guile) and the other is a mix of yaml and json, while Guile (Lisp) abuses parentheses and you end up lost in spaghetti code, in Nix you end up not knowing what it's doing even if you're an "expert". They are bad solutions and not very reproducible, because in NixOS you have to change every so often the shitty variables they use to set garbage and in Guix you have to fight if you need non-free software with the NonGuix channel and other kind of nonsense.

NixOS is a terrible solution rather than a reproducible one. Adding a layer of complexity to simple text files that can be easily edited and having thousands of links that are links to other links is just stupid. Filling up disk space like crazy and using more machine resources on trivial tasks is not an elegant solution. Editing configuration.nix or any other module, reading all the idiotic variable definitions that were invented to change a simple variable in a text file, is boring.

I don't know what the Nix designer (NixOS) had in mind when they thought that putting layer upon layer of complexity was a great solution. If something goes wrong in NixOS at the bottom layer, the nixos-rebuild command will produce weird errors. NixOS is an effort to make Linux complex and, in my opinion, useless. I could go on listing the shortcomings of NixOS, but I'll stop here...