SuperSandro2000

IMO tileable window managers are over hyped

Sounds familiar

Guix focuses on free software, not on general usability.

NIXOS, NIXOS, NIXOS!

Capitalism does capitalism things...

There shouldn't be much difference between understanding nix and guix, it is basically the same idea.

Big middle finger from me to MyQ

You want the daemon, the sandbox and what you use to manage your inputs does not really matter for the outcome, it only makes the managing easier.

Debian documentation has usually the same gap but there are many resources out there how to get things done but not necessarily the way debian intended which can break things on updates or name them unnecessarily hard.

Sorry for the harsh words but you don't have any idea what you are talking about.

Some examples: managing patches for applications is doable with NixOS. With overlays they survive updates and if they no longer apply, build fail before they can have production impact. Doing the same with docker is a nightmare and different for every dockerfile without a common interface around it. Ansible takes the previous state of the system into account which is terrible if you want to manage it fully declarative. Worst case in NixOS you do a reboot and your config applies almost no matter the previous state.

And that you can leave something running without maintenance is naive and it will start to slowly rot.

In addition to that home-manager does not have have the same value NixOS modules have. You are mostly translating configs and not receiving big parts which are normally copied from the documentation for free.

So they just made the rust plugin paid and I am supposed to be "excited" about that?

Shut up and take my money!

Well, for most other distro you also Google around and back someone together all the time, we just got used to it.

Prior Linux knowledge still applies and is required, it is just managed differently.

Another language won't change much.

Debian reliability is outside of core packages a myth and Debian has no way to properly migrate configuration. Every major update is a wild rollercoaster ride were things might break in the middle.

That's actually worse search experience and slower because less is struggling with the amount of lines.

NixOS core maintainer here. That's about nginx' own test. Gixy is still run when writing any nginx config file with the writer helper function https://github.com/NixOS/nixpkgs/blob/b6cc06826812247fe54655...

As a distro maintainer: we are probably needing to disable that by default.

Some other software can think the exact same thing.

The links also don't contain it. Mailing list based workflows....

Only the package manager and the language share a name, everything else is named more unique

Bare bones as in by default you don't get much unless you turn it on

For that reason many modules have options to set the packages used, so that you can eg. patch openssh without rebuilding everyone.

Nixpkgs does not assume Denver that's why we run if possible the package's tests, our own tests and build dependent packages to make sure the most obvious breakages are noticed before things are even merged.

Unless you are attempting advanced things you don't need to know a lot about the language and how the more advanced things work.

If you have something easy to deploy like a go binary you can just write a dockerfile but for big python projects that start to compile dependencies that is quickly no longer true. The dockerfile likely is also not matching the software you run and test on your local machine, so sometimes debugging is not as easy. Ofcourse you can debug inside the container but then you are missing all your tooling and need to bring that with you. And rebuilding a dockerfile is often not reproducible, so if you want the container back from 1 year ago and you no longer have the artifact you are probably out of luck.

With nix you can easily open a shell with the packages used in the docker image or go back in time and reproduce that image from a year ago with the flake.lock from a year ago.

Also applying patches to dependencies used in dockerfiles is not dead easy as with nix.

I got pretty far the first year without really writing much nix code at all.

It is not incredible fast and while it is running you can do something else like reading hackernews but there is definitely room for improvement and smart people are already thinking about that right now.

> Extremely complicated and hard to understand

That is absolutely not true. If you start to get the hang of it and follow the way things are supposed to be done then things get easier over time. You need to invest upfront more time into your configuration but on the long run it pays off and saves you from an entire error class.

> projects that use it have builds fail anyway

The point of Nix/NixOS is not to have no failing builds but that those are reproducible and deterministic as much as possible and that those failures are noticed early and before the point of no return. A system build is supposed to fail early and not mid way through a major update and prompting you to merge some config under /etc by hand.

> The biggest barrier to adoption unfortunately is not people's inability to explain what the tool is in my opinion.

That's simple: nix is a package manager and the language used by the package manager, NixOS is a Linux distro.

> It's that the tool is incredibly complicated, extremely hard to walk someone through compared to alternative projects, and honestly... In my opinion the problem it attempts to solve doesn't really exist.

From someone who is working as a DevOps Engineer for some years and managing Linux servers for a few years longer that thought is incredible naive. The problem of undefined and undocumented system state is a fundamental problem I encounter everywhere especially bad with legacy systems. I often do things on them blind and just pray for the best outcome, realising months later that some system was broken by one change I did and no one realised that for months.

> I'll take an "impure" os or package manager over a pure one any day if complexity is a thousand fold less and the learning curve doesn't require half a decade. Got stuff to do!

I thought the same first but unwedging Debian once a week on a different system is also not fun and a waste of time and having servers in some undefined state and no one who how the config is supposed to be and why or when it got changed, too.

The result in the end is that every system is different and unique and your Ansible playbook to run a common and good thought out task succeeds on 15 VMs and sometimes completely blows up the 16th because no one could have thought that the state of configuration there is so widely different.