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 think NixOS is awesome, but it certainly doesn’t offer “access to (basically) all Linux-capable software, no matter from what repo.” - at least not natively. You can do that through containers, but you can do that with containers on any distro. Where it shines is declaring the complete system configuration (including installed programs and their configuration) in its config file (on file-based configuration, I wouldn’t really consider blendos a viable competitor).
I think NixOS is awesome, but it certainly doesn’t offer “access to (basically) all Linux-capable software, no matter from what repo.” - at least not natively.
I don’t quite agree with this. In NixOS you can write custom expressions that fetch software from any source, and stitch them into your configuration as first-class packages. So you do get access to all Linux-capable software natively, but not necessarily easily. (There is a learning curve to packaging stuff yourself.)
I use this process to bring nightly releases of neovim and nushell into my reproducible config. Ok, I do use flakes that other people published for building those projects, which is a bit like installing from a community PPA. But when I wanted to install Niri, a very new window manager I wrote the package and NixOS module expressions all by myself!
Another NixOS user (and minor package maintainer, if it matters) here. Essentially, NixOS is actually rather simple to write a configuration file for a particular program once you get the knack for the nix language and learn how to workaround the sandboxing. I would actually consider it substantially less involved as compared to (for instance) creating your own Debian package.
However, getting to this point will take a bit of effort, and this step is more or less obligatory to use software on NixOS, whereas it generally isn’t (but still is a good idea) on other distributions.
expired
(There is a learning curve to packaging stuff yourself.)
“Learning curve” is an understatement. Nix is one of the most poorly documented projects I’ve seen, next to openstack. Coming into it with no background in functional programming didn’t help.
Maybe I shouldn’t have tried to package openstack on nix.
But I’ve tried to package other stuff, like quarto, and that was a nightmare. Nixpkgs didn’t have an updated pandoc and I spent an eternity asking around for help, to try to package it. An updated version just got pushed to unstable a few days ago. The same matrix channels I joined to ask for help have been discussing this since then. Props on them for getting it working, but anyone who says that you can easily package anything, is capping. You need to have an understanding of the nix language, nix packaging (both of which are poorly documented), and a rudimentary packaging ecosystem of what you are trying to package.
Don’t even get me started on flakes vs nonflakes.
I still use nix-shell for all my development environments, because it’s the best way for reproducible environments I can share I’ve found.
I would disagree. I feel like nixpkgs has pretty much everything, more so than any other distro in my experience. The differences in how NixOS work can make it a little weird to run something off the cuff, but steam-run has your back in those situations.
You can steam-run any Linux executable, so for those cases it’s fine.
All the major software is already in Nixpkgs, there’s just some holdouts still shipping .deb and .rpm files, though
And you can create package configs, but you can also do that for nearly every distro. So, yeah, that confuses me too… I’m not sure what OP was trying to say there.
Sorry for my ignorance,
but why is blendOS not a viable competitor to NixOS?To clarify, I was referring specifically to its ability to specify the full system configuration in its config file - not overall. But I haven’t used blendos, and my impression is mostly from a quick look at their documentation. They have a snippet with sample configuration. There, they have a “Modules” section, but I couldn’t find what modules are available, what options they have, how to configure them if we want to do something more complex than the available options.
Then containers are clearer: they have a list of installed apps, and then commands to bring them to the desired state (somewhat similar to a dockerfile). But even then, i imagine that if you have a more complex configuration, that’s going to get clunkier.
Thanks, that makes sense.
Do you think the use of OCI containers/images is a mistake/bad choice from blendOS?
How is NixOS different?Do you think the use of OCI containers/images is a mistake/bad choice from blendOS?
No. It’s probably the best way to run packages from Arch, Debian. Ubuntu, Fedora, and others, all on the same system.
How is NixOS different?
NixOS simply doesn’t tackle that problem, so it doesn’t come with containers out of the box. If you want to run packages from other distros on NixOS, you’d probably need to manually configure the containers.
I feel like you’re under the impression that the three distros, NixSO, blendos, and Vanilla OS, have similar goals. I don’t know about Vanilla OS, but the main similarity between the other two is that they’re both non-standard in some way.
But they’re actually solving completely different problems: BlendOS wants to be a blend of different OSes, NixOS wants to have a reproducible, declarative configuration (declarative here means, you don’t list a bunch of steps to reach your system state, but instead declare what that state is).
I think NixOS is awesome
how well is it suited as a daily driver for dev work & playing games?
The single killer feature that convinced me to move to NixOS is the ability to very easily keep separate development environments separate. For instance, if you’re working on multiple dev projects that have different minimum requirements, and you want to ensure that (for instance) you don’t accidentally use features from after boost 1.61 for project A, because that’s the stated requirement, but you need features from boost 1.75 in project B.
In a normal distribution, in order to set up an environment that has the proper version for project A you’d need to set up a chroot, a virtual machine, a complicated set of environment variables in a bespoke script with custom installation paths that you need to set up manually and remember to source, or just install a newer version of boost and rely on continuous integration to catch it if you screw up.
In NixOS, you can set up different shells which all reference the exact correct version of the libraries required for every project, you can have them installed simultaneously and without conflicts, and there’s even a shell hooking program that will automatically load and unload this configuration when you change directories into and out of the project folder. It makes managing many different projects much easier. It’s like a better version of venv, but for everything.
Well, for playing games I use the flatpak version of steam and it works OK.
For dev work, it’s great overall. Especially its ability to create separate reproducible environments with whatever dependencies you need for every project. However, there are some tools (rare, but they exist) that don’t work well with it, and if your dev work happens to need them, it can becomes a problem.
For day to day (i.e. web browsing), it works the same as anything, with one disadvantage: there is a disadvantage here: it downloads a lot more than other distros on update, and uses more disk space. The biggest difference between NixOS, and say Arch, is not how it behaves once it’s up and running, but in how you configure it. Specifically, you have to invest a lot of time to learn how, and set up your system initially. But then reinstalls, and (some of) the maintenance, become easier.
downloads a lot more than other distros on update, and uses more disk space
why is that?
The way nix deals with packages is very different from most distros. If you install a newer version of a package, the older version just gets hidden, not removed. This makes it very easy to rollback or recover from errors, but it does mean you tend to use more space.
You can always configure the garbage collection to reduce disk space usage, or manually run it.
In regular FHS distros, an upgrade to libxyz can be done without an update to its dependants a, b and c. The libxyz.so is updated in-place and newly run processes of a, b and c will use the new shared object code.
In Nix’ model, changing a dependency in any way changes all of its dependants too. The package a that depends on libxyz 1.0.0 is treated as entirely different from the otherwise same package a that depends on libxyz 1.0.1 or libxyz 1.0.0 with a patch applied/new dependency/patch applied to the compiler/anything.
Nix encodes everything that could in any way influence a package’s content into that package’s “version”. That’s the hash in every Nix store path (i.e.
/nix/store/5jlfqjgr34crcljr8r93kwg2rk5psj9a-bash-interactive-5.2-p15/bin/bash). The version number in the end is just there to inform humans of a path’s contents; as far as Nix is concerned, it’s just an arbitrary name string.Therefore, any update to “core” dependencies requires a rebuild of all dependants. For very central core packages such as glibc, that means almost all packages in existence. Because those packages are “different” from the packages on your system without the update, you must download them all again and, because they have different hashes, they will be in separate paths in your Nix store.
This is what allows Nix to have parallel “installation” of any version of any package and roll back your entire config to a previous state because your entire system is treated as a “package” with the same semantics as described above.
Unless you have harsh data caps, extremely slow connections or are extremely tight on disk space, this isn’t much of a concern though.
Additionally, you can always “garbage collect” old paths that are no longer referenced and Nix can deduplicate whole files that are 1:1 the same across the whole Nix store.
It’s the probably the best distro for dev work imo. Nix in general is really nice for development. Games work fine — you can just install steam or putrid or whatever, and you can run normal binaries with steam-run.
NixOS
- “The new Arch”
- Very customizable and minimalist
- Semi-Immutable
- Huge community and very old
- Very different than others
- Config-based
- Not very (new) user friendly, wouldn’t use it. Too complicated for me
BlendOS
- Doesn’t offer much new stuff for me, nothing they offer is substantial for me.
- Small dev team
VanillaOS
- “The new Linux Mint”
- Huge focus on usability and user friendliness
- Apx is basically only a wrapper for distrobox
- Small dev team (the same one that also develops Bottles)
- Huge potential, but not quite there yet
- Will recommend it to new users when it’s updated to 2.0
Silverblue
- My recommendation
- Is one of the oldest immutables and very well thought out
- Biggest dev and userbase
- You can not only install Flatpaks, but also everything else with Distrobox and rpm-ostree
- Best feature: you can easily rebase to it’s other spins or the custom ones from uBlue I just rebased this weekend from the SB to the Kinoite-Spin in just one command. I was able to “change distro” without resinstalling, and KDE was installed very cleanly without leftovers.
Calling NixOS the new arch is needlessly insulting lol.
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.
NixOS is uncomparable.
It just makes so much sense in a way other distros don’t
Fedora Silverblue and NixOS looking very interesting ✨👀
While I’ve looked into Fedora Silverblue, that distro is limited to only install Flatpaks, which is fine for “apps”, but seems to be more of a problem with managing system- and CLI tools.
No. Your understanding to Fedora Silverblue is wrong. I can just run
rpm-ostree install package.namein Silverblue, like other Fedora spins. The small disadvantage is that I need to reboot to apply this update. (re-construct)but doesn’t that result in new A/B snapshots, or something like that?
Well, you can call it snapshots, but there is no need to think about it. In most cases, the system points to the newest snapshot (deployment 0). If a rollback is needed, I can pin to the older deployments. When a major change is to be applied (Like bump Fedora version), I’d manually mark the current deployment as dont-auto-delete.
Sure, but I’d like to have a more seamless experience, i.e. not having to open/start any “containers” or something like that.
I never used toolbox in my Fedora Silverblue system. I feel that I can’t tell the difference between using Silverblue and the default Fedora spin
Thank you; that was very insightful 😊
Also: I think
rpm-ostreeonly supports rpm-based packages, tho; right?Can I install
.debsoftware too?
And is there any kind of system-as-a-config-file kind of solution available like in NixOS or blendOS?For other systems I think distrobox and toolbox are kind the intended way to mess with them. For configuration as code ansible is a popular answer.
How well does Ansible work when I want to change my config? Is a quick reboot sufficient!
It depends on if the changes needs it or not. You can set a reboot flag on a given task and at the end the system will reboot, but if no reboot is needed then it will just make the change live.
Also: I think rpm-ostree only supports rpm-based packages, tho; right?
Can I install .deb software too?
I don’t think
rpm-ostreecould support.debsoftwares, just likednf/yumcan’t support deb packages.Can you share your use case for trying to install a deb package in Fedora? I’m just curious.
And is there any kind of system-as-a-config-file kind of solution available like in NixOS or blendOS?
Good question. I only have a few computers, so I had never considered about it.
@zhenbo_endle @tanja you can install deb software in a seamless way using toolbox https://catalog.redhat.com/software/containers/rhel8/toolbox and a very simple Debian container
Lots of great answers here already so I will only address a couple of things that haven’t been mentioned:
Regarding Fedora Silverblue:
- Currently, Fedora Atomic Desktops are in a major shift to accept OCI container images for delivery of packages. This means that the built image becomes one compliant to OCI and that we boot into an OCI container as our system. As OCI images are relatively declarative (not to the extent that NixOS does (yet)), it becomes possible to have a set of config files (most importantly, the so-called Containerfile) in which your system is ‘declared’/‘configd’. In case you’re interested into how this looks/works, consider taking a look at uBlue’s startingpoint or if you’re more interested in the scope of configuration into Bazzite and/or Bluefin.
- apx is available as a COPR on Fedora Atomic Desktops.
- Nix can be installed on Fedora Atomic Desktops using Determinate Systems’ installer.
Regarding Vanilla OS:
- They’re also moving to a model that’s very close to where Fedora Atomic Desktops is heading towards. So, expect a similar way to config/‘declare’ your system.
What are your thoughts on the
threefour distros mentioned above?It’s a question of polish if you’d ask me. With Fedora Atomic Desktops and NixOS being advantageous due to being more established and better funded. I wouldn’t write off Vanilla OS yet as they seem to know what they’re doing. Though, I wouldn’t keep my hopes up for blendOS as its main developer was unaware of which MAC was configured by default on blendOS (spoiler alert: none, at least at the time).
Furthermore, NixOS is literally its own thing and unfortunately infamous for its steep learning curve. If you can afford to learn and conquer NixOS, then NixOS should be the recommendation; unless (like me) you seek SELinux on your systems.
Between Fedora Atomic Desktops and Vanilla OS; Vanilla OS is still in its major rewrite/revamp. The alpha builds are there, but I wouldn’t recommend using those on production machines. Fedora Atomic Desktops, on the other hand, has been going strong for a while now and the uBlue-team has even succeeded in making the OCI-stuff accessible for the general (Linux) public. So if you want to switch now and NixOS is/seems too hard; then Fedora Atomic Desktops it is. On that note, I recommend to check out the uBlue project.
Which ones are the most interesting, and for what reasons?
Honestly, all of them are really interesting, but NixOS does the most unique stuff; with only Guix doing something similar within the Linux landscape. To give you a taste of some of the wild stuff found on NixOS; there’s the so-called Impermanence module which -to my knowledge- happens to be the closest thing to a usable stateless system we’ve got; period. Consider reading this excellent blog post in case you’re interested to know what this entails.
Thanks for the detailed response.
I’ll probably go for either a Fedora Atomic Desktop or NixOS.
deleted by creator
Silverblue is sure not limited to only flatpaks.
Oh 👀
I didn’t know that; I knew you could modify the underlying system, but doesn’t that result in new A/B snapshots, or something like that?toolbox/distrobox
Sure, but I’d like to have a more seamless experience, i.e. not having to open/start any “containers” or something like that.
Also, can I “normally”/traditionally install software on NixOS, e.g. through Steam?
Listen to the “Linux User Space” podcast, episode 404. They explain every immutability model af of now. Ubuntu Core is missing.
Ubuntu is creating something new, looks really great but based on snaps, which are not bad packages but rely on a nonfree store that cant be replaced. So meh.
Not bad packages
I’ve made the opposite experience. There were loads of snap-specific issues when I used ubuntu. So many that I now recommend not using ubuntu just because of snaps.
Thanks for your suggestion, but I’ll never use snaps/snapcraft/snapd by choice;
I do see the reasons for why developers/app maintainers may want to (universally) package themselves, but we’ve got Flatpak for that.
Less loopback devices = better imho
Agree partly. Maybe snaps are bad, dont know the details, but if system packages and even the kernel can be packaged, thats pretty nice
VanillaOS and BlendOS also use containers to install apps, just like Fedora Silverblue. In fact, it’s easier to install native packages on Silverblue than it is on VanillaOS. Just set your terminal to start a container by default.
Also, can I “normally”/traditionally install software on NixOS, e.g. through Steam?
Depends on what you mean by traditionally. Steam works without needing any special setup by enabling it in your configuration, just
programs.steam.enable = true. There’s also imperative package management with nix profile (don’t use nix-env -i which you will probably come across, it’s broken by design). Personally though I recommend sticking with the declarative configuration and nix-shell which temporarily brings packages in scope for the current shell only.it’s broken by design
what do you mean by that?
There’s two different ways of identifying a nix package: its attribute path in the package set, and the name it self-identifies as. Here’s an example where those differ, firefox-esr. Its attribute path is firefox-esr while the package name it reports is firefox.
It’s very fast to find a package by its attribute path since that’s essentially one or more map lookups. In contrary, the package name isn’t unique (for example, firefox and firefox-esr both have a package name of “firefox” because they are built from the same package file just with different sources) and also doesn’t have an index, so to find a package with a matching name you have to search through the entire package set and evaluate every package to get its name and check if it matches.
nix-env -i searches packages by their package name, which as a consequence makes it slow and also unreliable since you might not get the package you were looking for, but instead another with the same name. nix-env -iA somewhat fixes this by installing packages by their attribute path, but even if you use that you get the same issues with nix-env --upgrade since that always searches for packages to update by the installed packages’ names (it might even replace one package with a completely unrelated one which coincidentally has the same name!).
The new nix profile however stores the attribute paths a package was installed from so doesn’t have any of these problems.
I think it depends on the user :P. NixOS is pretty hard to get into because the documentation isn’t great… but I’d argue it’s one of the most user friendly ways to configure a system, and it can be really nice to copy configurations from other people.
You look at defaults and think this is linux.
Look again at Fedora Silverblue /any other desktop variant. VanillaOSses apx is just a wrapper around distrobox, which is preinstalled on ublue even.
Apx installs apps on containers just as it is possible on Fedora Atomic (the general name for all immutable desktops). You can also layer and remove apps to or from the base OS which is sometimes needed or nice for speed.
On Fedora Atomic you have
- flatpak
- podman containers (toolbx, distrobox: like apx on VanillaOS but without the great tooling and GUI management, yet)
- rootful containers for stuff interacting with systemd, needing USB access etc.
- layering or removing packages / changing the OS to something like ublue to let other people do the work, especially for NVIDIA drivers
You look at defaults and think this is linux.
What do you mean by that?
On the Fedora Atomic website, they write:
Project Atomic is now sunset
The Atomic Host platform is now replaced by CoreOS. Users of Atomic Host are encouraged to join the CoreOS community
Do you think CoreOS is a good fit for a desktop?
I always thought it’s more of a server distro.On a related note: Would you recommend Fedora Silverblue?
Oh no. The rebrand is not done. There is no Atomic site yet, Atomic= Fedora Desktop with OSTree (Silverblue, Kinoite, Sericea, …)
If you like GNOME, yes I recommend Silverblue a lot.
Fedora has a very different system of the core distro. But with defaults I mean that they dont have apx by default but the same underneath.
You could use a bash function for DNF for example, but in general it is
distrobox-create Fedora39 distrobox enter Fedora39 sudo dnf install PACKAGE distrobox-export --app PACKAGEfor GUI packages
You van both use rpm-ostree and toolbox to install regular fedora packages on silverblue/kinoite
How do those compare to NixOS and blendOS in your opinion in terms of usability, flexibility and stability, considering an (at least mostly) tech-literate audience?
Given I’m still on Manjaro, would you recommend I consider NixOS, Fedora Silverblue, or blendOS?
I would check out something like universal-blue.org. It is fedora silverblue but with fixes that make it more usable (like codecs by default). It also ships distrobox right out of the gate so you can use that for apps that aren’t in the fedora repos, copr , or flatpak. You also don’t have to layer packages if you install via distrobox so I think it ends up being pretty handy for stuff that you want that isn’t available as a flatpak. Finally there are many different images for all different desktop environments so you can switch between them just by using rpm-ostree rebase and the link to the different image.
What is your usecase?
This is the key question.
Daily driver;
- Dev work (VS Code) 👩💻
- Using Firefox 🔥🦊🛜
- Playing games every now and then (mostly Steam & Proton) 🎮
Is there something that attracts you to NixOS for that purpose?
I’ve got Nix OS running on one of my computers, and honestly, haven’t found it to be particularly notable for those usecases.
I’ve got Nix OS running on one of my computer
That’s very interesting 👀
Why did you choose NixOS?Mostly to learn about it’s unique selling points.
I think it is very interesting in terms of the easy deployment of specific environments, and in terms of writing recipes for new packages.
Having said that, outside of these two rather niche areas for home use, I think it is rather unintuitive and offers no real advantages over more established players that offer a more polished experience, like Fedora for workstation and gaming use.
Dev work is not specific enough. Pip is a nightmare because it just wanted to modify folders that were read only and you never know what it wants to do to your system. Your experience may vary depending on how much the language package manager assumes about your system. If you’re in a container, it will work perfectly, though
Firefox just works, and I installed Steam from nixpkgs and it worked after enabling a few settings. Then I just enabled Proton on every game and it works okay, with a few weird bugs sometimes (although I blame Gnome for messing up alt tabbing sometimes)
I have a similar use case on my laptop and love NixOS with hyprland
- NixOS built its own package manager. neet. Remind us why it’s better.
- blend and vanilla both run debian packages, which has a reduced validity check.
So none. Didn’t even have to look further, as they’re all dead to me.
Nix is better because you can use a lock file to fetch the exact revisions of each software. Even proprietary stuff is hashed so when you download it, it’s checked to be bit identical to the lock file hash before it’s installed
This means your setup on another machine is the same as long as the lock file is the same.
Also you can switch to an older revision, mix and match stable and unstable, keep your whole setup in a git repo. It’s basically everything you ever would want from a package manager (reproducible builds already done for the minimal version, soon coming to all 80,000 packages)
I would guess what distro you use, but I think I can guess.
Blend is based of arch not Debian.
What do you use, then?
Given the context, I’d assume either Arch or Fedora Silverblue 🤔
