So I’ve recently taken an interest in these three distros:
All of these offer something very interesting:
Access to (basically) all Linux-capable software, no matter from what repo.
Both NixOS and blendOS are based on config files, from which your system is basically derived from, and Vanilla OS uses a package manager apx to install from any given repo, regardless of distribution.
While I’ve looked into Fedora Silverblue, that distro is limited to only install Flatpaks (edit: no, not really), which is fine for “apps”, but seems to be more of a problem with managing system- and CLI tools.
I haven’t distro hopped yet, as I’m still on Manjaro GNOME on my devices.
What are your thoughts on the three distros mentioned above?
Which ones are the most interesting, and for what reasons?
Personally, I’m mostly interested in NixOS & blendOS, as I believe they may have more advantages compared to Arch;
What do you think?
I mean seeing how people here act after having been on nixos for a few weeks I would say it’s an apt comparison. I swear we weren’t that obnoxious when I started using the distro in 2019 D:
I don’t think it’s an apt comparison of the distros, but I agree that both have a cult-like following. I also feel like there’s a bit of a difference in the evangelism of both distros… I don’t really understand why people evangelize Arch, and my impression is largely that (1) people mention that they’re on Arch so others know they might be having different configuration issues, or less charitably (2) people mention Arch as a weird brag because it’s seen as an “advanced” distro. In contrast people seem to recommend nix and NixOS because it solves a frankly ridiculous amount of real problems that people experience with development environments, package managers, and system management. I.e., we bring up nix and NixOS because we care about you and think it might actually be useful for you. I don’t really want to dictate what other people use or brag about using nix / NixOS, but people complain to me about different problems constantly that are just resolved by nix, so it feels wrong not to mention it. It’s frustrating because it definitely makes you seem like you’re in a cult, but it really is the right level of abstraction for package management, and as a result it solves so many problems and little frustrations.
Honestly, it’s kind of frustrating to watch people not use nix. I have nix set up for the projects at work because I got tired of them not building and people randomly changing dependencies and it taking 3-4 weeks for somebody new to the project to get the thing to compile. Everybody new that I have set up with nix gets the project working instantly, and everybody else ends up spending weeks flailing around with installation. Unfortunately, I’ve given up on recommending people use nix for the project because a number of senior people have decided that they don’t like nix and there’s a bizarre amount of drama whenever I recommend a newbie just use it to get set up (even though it has always worked out better for them). It’s just not worth the headache for me to stick my neck out, but I feel bad and it’s really frustrating how literally everybody else takes 3-4 weeks to get up and running without nix :|.
I tried NixOS and was quite frustrating when I needed community help / documentation. I guess that’s the aspect of “the new arch”, the community will go “not my problem fix it yourself”. I’ve seen some good tutorials on YT popped up since then, so I’ll try it again once I get college vacation. It’s hard for me as a non programmer/psychology student. My field doesn’t overlap with programming not by a little, lmao. I think you need to recommend nix and have the way people need to do things. Like, a nix flake? You can get it to work 100 ways, and nix uses its own language and way of declaring things. That’s one thing that made me go “I just need to have a working system and I have a Arch install script done”. I like to fiddle around with things, but when you are stuck with something and there isn’t a clear path to do it, it gets frustrating. The 100 ways to 1 thing makes copycat difficult, because you have to copy the same person, which will not have all the needs for you, or find people that did their config the same way (which is really hard). Like, overlays, packaging programs, making modules, even Arch had a “this is how you get things done” wiki. I really think Nix and NixOS is really good and I will try it out again in some months.
Yeah, I don’t have good answers for you… I honestly don’t know what the best way to get people into it is. The resources really are not great.
FWIW I think when it does end up clicking everything is a LOT less complicated than it seems at first. Nix is sort of all about building up these attribute sets and then once that really sinks in everything starts to make a lot more sense and you start to realize that there aren’t that many moving parts and there isn’t much magic going on… but getting there is tricky. A lot of people recommend the nix pills, and honestly I think it’s the best way to understand nix itself. If you do earnestly read through them I think there is a good chance you will come out enlightened… they just start so slow and so boringly that it’s tempting to skip ahead and then you’re doomed. They also have a bit of a bad habit of introducing simple examples that don’t work at first which can be confusing, and eventually some of the later stuff seems like “ugh, I thought we already solved this” but it’s building up nicer abstractions. The nix pills give a pretty good overview of best practices in that sense, I think… so maybe it’s the source of truth you’re looking for (or part of it anyway). I think the nix pills are a bit more “how the sausage is made” than is necessary to use nix, but it’s probably the best way to understand what all of these weird mkDerivation functions you keep seeing are actually doing, and having an understanding of the internals of nix makes it a lot easier to understand what’s going on.
ah I think that’s where I’m at odds with a lot of lemmy NixOS users then 😅, since I am and have always been pretty hesitant to recommend NixOS to anyone in particular. I find the upfront costs of NixOS too big for me to recommend the OS to anyone who wasn’t already looking into it and knows its downsides and upsides.
I do agree however on the fact that using nix is purely beneficial. It doesn’t hurt if you just add a .nix file to your project, since it doesn’t do any harm to an already existing project. It can just install your build tools and then consider itself done, and if you don’t happen to like nix after all, the new installer makes uninstalling easier than ever. There is pretty much no downside to downloading the package manager, something I can’t say about the OS.
Having said that, I don’t think nix should be the end-all be-all standard in package management. I’m sure there will be other package managers that will be better than “nix but with yaml sprinkled in”, and are capable of improving the state of the art. At least, that’s something I hope to happen. For example, I have reservations about using a full-blown programming language for doing my project configuration (see people’s problems with Gradle for why you might not want that). I think a maven-style approach (where you’d have just limited config options, but can expand the package manager’s capabilities by telling it to install certain plugins (in the same config file!)), could be worth looking into, and I’d be lying if I said I wasn’t on the look out for a potential better nix alternative
For sure! I don’t think we’re actually in disagreement at all, just the limits of text communication :). NixOS is certainly less important to me and I don’t really care if people use it or not at all (it’s nice but there’s enough differences that you have to be aware of that it’d be frustrating to some people — even if ultimately those differences are something that can be worked around… If you’re well versed in nix and Linux NixOS is kind of a no brainer, though). Nix for development (or something like it) is legitimately enough of a game changer to warrant some of the evangelism in my opinion, particularly since as you mention it’s pretty much free to try on any (non-windows) system, and adding nix to a project doesn’t harm non-nix users (more than they’re already harmed anyway, haha). I’ll admit that I worry about how “nix ugly and unintuitive” seems to be a huge problem for adoption, and frankly I don’t blame people for bouncing off of nix (I bounced off of nix in 2011 or so and didn’t come back to it for like 10 years — though it was a bit of a brain worm nagging at me the whole time). That said I think the impression people have of nix being this horrible and completely ugly language (an impression I’ve had in the past as well) is also somewhat untrue. The nix language itself isn’t so bad, but the expectation is for it to just be yaml because “I just want to list dependencies”, which is fair and it might be nice if we had some better abstractions to make that more clear. All of the phases in a nix derivation are confusing and poorly documented, and some operations on attribute sets should probably just have nice special syntax instead of these fancy update fixpoints that the average developer isn’t going to understand… ultimately I’m a little unclear on how much of this is “the nix language sucks and needs to be thrown out” and how much is “we really need a better introduction to what this is and how to use it, especially with some beginner examples and best practices for different languages”. I worry a bit about non-nix nix package managers just from the perspective that it’s really nice to have the one tool to rule all development environments, but maybe fragmentation won’t be a huge problem.