dude, I learned and used NixOS for 2 years and I found it incredibly challenging as some of the documentation is fragmented to the point where you have to delve into several hundreds of others configurations to fix singular problems. Some issues are actually impossible to solve (unless you have months of time off and proficiency with Nix) as NixOS is not FHS compliant.
In addition, good luck with finding what you want as sometimes it’s unsearchable as the devs decided not to distinguish the 3 from each other.
Why? I have no idea.
I haven’t even mentioned Nix Flakes which is it’s own level of complexity due to it’s experimental but recommended status by the community.
Perhaps it’s a skill issue but I feel that I’ve spent my 2 years of due diligence to know that it’s still quite rough on the edges.
At this point I’m personally moving back to Arch.
I’ll be experimenting with Gentoo sometime in the near future but at this point it’s very unlikely I’ll ever revisit Nix and NixOS especially since Valve is doing fantastic work in collaboaration with the Arch Linux devs.
For all I’ve said above
Because reading the docs is too hard for an imbecile?
Please reconsider before posting future antagonistic and abbrasive comments as it does no favors to you nor the community and only paints a target on your back👍
Nix and NixOS are not easy beasts to tame as advanced help is sparce and individual challenges can be quite niche such that help cannot be readily found.
I’ve been using Nix for well over a decade and yes it’s fucking hard, sometimes. But when it’s hard it’s usually solvable by using the repl so you can actually see what’s happening.
I agree completely, I still think that for some things Nix is the most convenient thing, e.g. when packaging cross-compiled images of the apps, but I would never be able to build this from ground up, and whenever something breaks it’s a pain to fix. Using NixOS on Mac at least taught me how it works more or less, and it mostly does except for when it doesn’t and I’m in it deep
I’m gonna be honest, I use NixOS, but the docs fucking suck, and a number of things are just broken in nixpkgs. For instance, I recently discovered the structuredExtraConfig option for patching the kernel straight up does not work. This means you cannot unset any kernel options, which means some kernel patches won’t work unless you manually supply the entire kernel config.
EDIT: what’s even more annoying about it not working is that it fails to apply silently. In other words, your kernel tries to compile and then an hour later it fails because your config changes weren’t applied.
An hour? Are you on a pentium4? I’m building everything from source, daily, multiple times and the longest it takes is usually 1.5hours for a complete build of Gnome, Firefox, Nvidia+Kernel. And that’s only if I don’t update for like a month. But just a kernel build, that should only take a min or two.
I’m building multiple patchsets on a laptop. How tf do you expect millions of lines of even somewhat optimized code to compile in a minute or two? The configuration by itself wastes like half of that, not to mention nix taking 2 minutes to evaluate because specializations are slow af. It in fact takes more like 2-3 hours for them to finish.
For instance, I recently discovered the structuredExtraConfig option for patching the kernel straight up does not work. This means you cannot unset any kernel options
From reading, I thought this option was for adding options, not removing them. Sure, you might be able to set options to “no”, but I don’t think this will override the defaults…
You’re supposed to be able to use lib.kernel.unset to unset them. In any case, that’s just one problem. The main issue is the entire option is ignored because of a typo in nixpkgs.
If you drive a car, have you read the entire owner’s manual for every car you’ve owned? If you’re a homeowner, how about your hvac system? What about your system shell? Your compiler(s)?
At some point you need your tools to be intuitive enough that you don’t need to read an entire manual in order to do your work.
I suspect this attitude of “read the fucken manuel” comes from when tooling was simpler and you could actually read all the manuals (or buy a book) to learn every small bit of it. Today, I’d be surprised if someone actually read all the Windows, .Net, and Powershell docs before attempting to write a small script.
Heck, even simpler things like Python have massive docs beneath every layer of them. You don’t learn everything from the ground up anymore, only the relevant parts to your use case.
Because reading the docs is too hard for an imbecile?
My personal nixos config
dude, I learned and used NixOS for 2 years and I found it incredibly challenging as some of the documentation is fragmented to the point where you have to delve into several hundreds of others configurations to fix singular problems. Some issues are actually impossible to solve (unless you have months of time off and proficiency with Nix) as NixOS is not FHS compliant.
In addition, good luck with finding what you want as sometimes it’s unsearchable as the devs decided not to distinguish the 3 from each other.
Why? I have no idea.
I haven’t even mentioned Nix Flakes which is it’s own level of complexity due to it’s experimental but recommended status by the community.
Perhaps it’s a skill issue but I feel that I’ve spent my 2 years of due diligence to know that it’s still quite rough on the edges.
At this point I’m personally moving back to Arch.
I’ll be experimenting with Gentoo sometime in the near future but at this point it’s very unlikely I’ll ever revisit Nix and NixOS especially since Valve is doing fantastic work in collaboaration with the Arch Linux devs.
For all I’ve said above
Please reconsider before posting future antagonistic and abbrasive comments as it does no favors to you nor the community and only paints a target on your back👍
Nix and NixOS are not easy beasts to tame as advanced help is sparce and individual challenges can be quite niche such that help cannot be readily found.
I’ve been using Nix for well over a decade and yes it’s fucking hard, sometimes. But when it’s hard it’s usually solvable by using the repl so you can actually see what’s happening.
## Windows emulator. bottles wine winetricksWine Is Not an Emulator! 😀
I agree completely, I still think that for some things Nix is the most convenient thing, e.g. when packaging cross-compiled images of the apps, but I would never be able to build this from ground up, and whenever something breaks it’s a pain to fix. Using NixOS on Mac at least taught me how it works more or less, and it mostly does except for when it doesn’t and I’m in it deep
I’m gonna be honest, I use NixOS, but the docs fucking suck, and a number of things are just broken in nixpkgs. For instance, I recently discovered the
structuredExtraConfigoption for patching the kernel straight up does not work. This means you cannot unset any kernel options, which means some kernel patches won’t work unless you manually supply the entire kernel config.EDIT: what’s even more annoying about it not working is that it fails to apply silently. In other words, your kernel tries to compile and then an hour later it fails because your config changes weren’t applied.
An hour? Are you on a pentium4? I’m building everything from source, daily, multiple times and the longest it takes is usually 1.5hours for a complete build of Gnome, Firefox, Nvidia+Kernel. And that’s only if I don’t update for like a month. But just a kernel build, that should only take a min or two.
I’m building multiple patchsets on a laptop. How tf do you expect millions of lines of even somewhat optimized code to compile in a minute or two? The configuration by itself wastes like half of that, not to mention nix taking 2 minutes to evaluate because specializations are slow af. It in fact takes more like 2-3 hours for them to finish.
From reading, I thought this option was for adding options, not removing them. Sure, you might be able to set options to “no”, but I don’t think this will override the defaults…
You’re supposed to be able to use
lib.kernel.unsetto unset them. In any case, that’s just one problem. The main issue is the entire option is ignored because of a typo in nixpkgs.Would you mind opening a PR to fix that typo? Would be useful for others as well!
I’m planning to, I’m waiting for the kernel to finish building rn lol
EDIT: PR got merged BTW (https://github.com/NixOS/nixpkgs/pull/431115).
Thank you for your work!
I would not have liked encountering this bug in the wild.
lol
Haha, perfect 😄
I see, thanks
If you drive a car, have you read the entire owner’s manual for every car you’ve owned? If you’re a homeowner, how about your hvac system? What about your system shell? Your compiler(s)?
At some point you need your tools to be intuitive enough that you don’t need to read an entire manual in order to do your work.
I suspect this attitude of “read the fucken manuel” comes from when tooling was simpler and you could actually read all the manuals (or buy a book) to learn every small bit of it. Today, I’d be surprised if someone actually read all the Windows, .Net, and Powershell docs before attempting to write a small script.
Heck, even simpler things like Python have massive docs beneath every layer of them. You don’t learn everything from the ground up anymore, only the relevant parts to your use case.
I miss the days when every package came with a man page.
Every respectable package; don’t come at me, pendants.
Did you do that on purpoise? :3
I cannot speak on behalf of the article author, but as someone who personally is an imbecile, the answer is: definitely!