[AnIdiotOnTheNet]

> Love to see more adoption of Nix and NixOS.

I don't want a 'journey' to use my OS. I don't want to learn a whole new language and set of overengineered abstractions to solve what I see as, at most, 5% more of application installation problems that are already 75% solved by package managers[0]. If the Nix community wants more people using Nix, they'll have to make it more attractive for those of us who do not want to waste so much time needlessly learning new stuff to do the same things we're already doing.

[0] which are already an overengineered and under-delivering solution in my opinion.

[kokada]

> I don't want a 'journey' to use my OS. I don't want to learn a whole new language and set of overengineered abstractions to solve what I see as, at most, 5% more of application installation problems that are already 75% solved by package managers[0]. If the Nix community wants more people using Nix, they'll have to make it more attractive for those of us who do not want to waste so much time needlessly learning new stuff to do the same things we're already doing.

This is fair, but keep in mind that package managing is only a small part that what Nix solves, and it is a much superior solution than anything else that I know (Docker for example is not really reproducible because you can't trace all dependencies; this seems like a philosophic issue but I saw some containers breaking because some dependency inside the container was updated without nobody knowing).

If we take NixOS, it also solves the issue with configuration, and with some auxiliary tools it also solves issues with deployment. You have alternatives for both of the issues too, but the fact that NixOS is much more integrated than any tooling (like Ansible, Puppet, etc) means you have much more flexibility. Also, don't forget atomic upgrades and fallback.

Eventually, instead of "wasting time", NixOS starts to save time by becoming the most reliable OS you ever used: you will never waste time anymore reinstalling your system from scratch, or if your hardware broke, you will never waste days trying to get your system to the same way it was. Also, because nixpkgs is enormous, you also tend to save time by not looking at "oh, this program seems cool, how can I install it on my computer since I never heard of this XYZ language?", and them installing the package manager from the language in 5 different ways because you have no clue. And even when you need to package the program yourself, nixpkgs has many abstractions that makes it much easier.

So instead of wasting time, Nix and NixOS is an investment. You may choose to invest your time right now to save later or not. Either way is fine.

Just to finish the topic, I fully concur yo you that we as a community needs to have better documentation.

[sjustinas]

That's absolutely fair, I don't think either the parent or the NixOS devs implied in any way that it should be the right fit for everyone or 100% of the Linux distro market share is the end goal.

For me, the benefits outweigh the quirks of the language. As my alternatives to manage multiple machines consist of: wonky Bash scripts, similar tooling but bolted-on on top of the distro and with no built-in rollbacks (Ansible, Puppet, etc.), or trying to get everything right manually, Nix does not seem like the worst out of this bunch.

[ris]

What I'm hearing is "I really don't like the way traditional systems are designed and I don't want to have to learn anything new!"

Nix is different, unapologetically so, that's the issue. And if it had to be more orthodox to win over a few more itinerant users that would make the whole thing pointless.

[AnIdiotOnTheNet]

I'm not asking it to be more 'orthodox', I'm asking to not have to spend months scouring poor documentation to learn a new language and toolchain to gain the very few benefits Nix provides over the existing systems. If Nix is so inherently complicated it cannot deliver that, then why would I want it?

Ultimately I want less complication in my life, not more, and Nix very much does not provide that from what I can see.

[e3bc54b2]

Traditional systems have complexity too. Its just not up front.

I like to compare it to fossil fuels and global warming. Traditional systems get one started quick, but eventually build a large fragile system that gets harder to fix/rebuild the longer it goes on.

Nix is different, it forces you to do your work upfront. But once setup, you pretty much can (and to my attestation do) forget it is in place. You do have to learn setting a anything a and everything. But you only do it once. If the house burns down, you don't need to remember what you had. You don't need to remember what to setup in what order. You don't have to find out you forgot something in the middle of something else. In other words, the onus is no longer on you.

That last sentence is incredibly liberating. I stopped worrying having black screens after updates and pretty much stopped having rescue disc, because rescue functionality comes built in the system. It sounds cultish, and it kinda is, but as I said in previous comment on Nix, it is the worst system management tool, except all the others.

[ris]

Oh, I use Nix because it does provide less complication in my life. It's just necessary to wrap your head around a few core principles first, which can be a little mind-bending when you start out (no fixed /usr locations? huh?)

[zeec123]

It is like saying I don’t want spending months to learn git to gain the very few benefits of a version control system. I much prefer to share my code with my coworkers via usb-sticks. Yeah this is less complicated in the short term.

[AnIdiotOnTheNet]

I honestly don't want to learn git precisely because there are version control systems that accomplish the things I need in a much simpler way. I only bother using git at all because some FOSS projects I've worked with use it. Hell, my impression is that most people who use git don't bother really learning it, they just keep a recipe book of how to branch, commit, etc. and then rely on stack overflow to un-fuck the repo after they accidentally blow it up.

[anandsuresh]

I could not agree more. Most people, IMO, are workflow junkies! It doesn't matter how good/bad/ugly the tool is; if it works, it stays forever! And git is a perfect example of a tool that is complex, but survives because it became the gold-standard for FOSS.

Having said that, wouldn't you agree that same recipe-book approach is also true for traditional system configuration/administration?

[AnIdiotOnTheNet]

Yes and for the same reason: people don't want to deal with systems that are overly complex for their needs, and OS configuration (especially in Linux) tends to have a ludicrous amount of needless complexity.

But the thing about Nix is that it just adds even more complexity. As was mentioned elsethread, in order to be effective with Nix you need to understand all the complexities of Nix and Linux. And the thing about Linux is that we have a ton of adequate recipe books out there already.

[anandsuresh]

Nix operates at the cusp of some of the most complex and obscure parts of the technology stack: operating systems, compiler toolchains, and package managers. These inherently complex components require a fair bit of commitment to fully comprehend in order to be used well. You can get a lot of mileage skimming through some tutorials to become productive, but to really utilize it to its full potential requires a fair bit of investment. You don't have to be an automotive expert to drive a car, but if you're looking to race, it behooves oneself to invest the time it takes to gain the expertise.

Nix takes a very different approach to system configuration than the traditional ways. Because it treats the entirety of the operating system (bootloader, kernel, user-land, services, account management, etc.) as a single composable unit, it is forced to break some old rules that date back to the oldest days of Unix and are (now) considered to be written in stone. The deviation from the Unix Filesystem Hierarchy is, IMO, required to make systems more composable and maintainable, and is inherently a good thing in the long run. Portable development environments eliminate "works-on-my-laptop" scenarios and ensure everyone on the team is always in sync with each other and CI/CD. Reproducible builds that can be rolled back after a botched deployment are a huge win. And delivering all of these features in a single tool requires breaking some of the old rules, and that is always met with resistance due to the inertia of "it works fine for me".

To be honest, there is no reason why you should give up what works well for you. Having said that, for those that are looking beyond the traditional tools like shell-scripts, Ansible, Chef, Puppet, and others, Nix offers all that is needed to easily build and maintain composable software stacks. Docker comes close to delivering some of the same features as Nix, but comparing the two is a bit like comparing system configuration using shell scripts to Chef/Ansible.

Yes; one does have to learn a new language and its idiosyncrasies. But that is also true of things like Rust. As a seasoned C programmer, I am able to write "good" C code. But that is not a statement about C's ability to scale to larger teams. Rust requires developers to give up their old ways of thinking and "give in" to the Rust-way. The longer you fight the borrow-checker, the more painful it gets. But once you give in, you are able to write code that is safer for use within large teams, thus delivering more momentum in the long run. It is not that it can't be built with C; it requires a communal way of thinking about software complexity that is forged by experience and tempered by camaraderie, and tools like Rust and Nix are excellent supplements.

I do agree with you that the documentation leaves a lot to be desired. I've always considered the FreeBSD Handbook to be the gold-standard for technical documentation and Nix has its work cut out to reach that stage of maturity. But I have full confidence in the Nix community's ability to deliver.

[pxc]

> it is forced to break some old rules that date back to the oldest days of Unix and are (now) considered to be written in stone.

On the other hand, one of Nix's greatest strengths is that in many respects, its innovations are conservative. It brings software building and distribution forward in terms of reproducibility and isolation (like containers do) but (unlike containers) also retains the traditional package management virtues of granularity, efficiency, and sharing common resources (dependencies) when possible.

[rgoulter]

> I don't want a 'journey' to use my OS. I don't want to learn a whole new language and set of overengineered abstractions to [do development work]

This is pragmatic.

Nix somewhat reminds me of the kinds of mindsets that enjoy learning Vim/Emacs, or learning how to use 40%-sized keyboards like the Planck. -- I think it takes curiosity to be interested in that kindof stuff.

[IshKebab]

I agree. I love the idea of Nix. At least what I think is the idea - basically Bazel as a package manager. But the actual implementation is inaccessible.

If someone could make a user-friendly implementation of the Nix concept I think it would be very popular.

[joepie91_]

> set of overengineered abstractions

While there are definitely a lot of remaining documentation and usability issues with Nix as it stands today, the core model is far from 'overengineered' - if anything, it's orders of magnitude less complex than the organically-grown cobbled-together pile of tools and conventions that 'traditional' distros are made out of.

Nix having a well-defined, complete, specified-upfront, coherent model doesn't make it 'overengineered'; it just means that the tools were designed from the start to help you manage the complexity of system management, rather than just kind of leaving it implicit and letting the end user and/or packager deal with the fallout later through an ever-growing collection of workarounds and patches and scripts.

It's completely valid to decide that NixOS is not (yet) for you due to the learning curve that still exists; I frequently warn people away from NixOS (when they are not prepared to deal with that) for this precise reason. But please don't conflate that with 'bad design'.

[pxc]

> [package managers] are already an overengineered and under-delivering solution in my opinion.

This is kinda nuts to me. Every time I use a system that doesn't offer proper package management, it makes me wish I had a decent package manager. What do you think is better than a modern package manager for solving the same problems?