> I can't believe this worked. Sure, you won't be deploying this in production, but we mostly survived this long with unconfined apps and having transactional updates is an improvement
The resulting system still seems very mutable to me, since it appears the system configuration management isn't tracked in a transactional manner. I would think for a "immutable Linux desktop", NixOS would be what the author was looking for, since the whole system is declaratively specified and can be rolled back to any previous generation. But some users go even further, performing a ZFS rollback on every NixOS boot[0] to ensure that mutable state doesn't accumulate (NixOS only needs /boot and /nix to boot, and creates /etc /var etc. if they don't exist already).
Blog author here, indeed I like NixOS, but I don't have the time to generate an entire nix file for a working desktop. I have some friends that do it and that's great, but there's no "Get you 90% there" installation option afaict. I just don't have the time for that.
That being said I use nix on my systems, just as a package manager to some existing boxes.
The default configuration.nix created by the NixOS installer[0] is a KDE environment already, and it's relatively simple to expand and iterate your system configuration (no restart required!). Personally for me the hardest part was figuring out partitioning (since I rarely do that), but YMMV. Hope you try it sometime!
Yeah, I would love to see a repo with more example configs, for example "This one looks like Ubuntu, this one is more XFCE focused, here's a tiling wm one." and so on.
I am using Linux because it is open source. I can tinker if soemthing does not work and I can switch servers or run my own if there is an issue with the organization running the server.
Without having deeply investigated myself I read the snap server is proprietary, nobody can run another instance. So nothing I want spend time on to even understand. (The client side gets some complaints, too. But without understanding the system I don't want to form an opinion, I uninstall it from the Ubuntu systems I still have.)
Yeah, the funny thing is, that MicroOS is supposed to work with flatpak. It's installed out of the box and you just have to add the Flathub repo. (And on gnome you should remove libpackagekit-zypp to prevent gnome software to try to install updates via zypper)
With flatpak you also don't have to engage in this wierd /snap trickery.
Have been using Silverblue for the past few years as my daily driver. Definitely a game changer, have all of my apps installed in a toolbox or via Flatpak. Can honestly say I have never had a system this stable before.
I started using it a couple of weeks ago and while I love the idea, I still feel there is some unsolved issues. I.e. Powerline does not work that well, accessing serial ports (microcontroller programming) requires a weird hack that is not fully working.
It is definitely usable and even good, but there is edge cases that ere not figured out, I feel. It needs more blog Posts, Docs, Tutorials ...
Blog author here, by default MicroOS comes with flatpaks so you can just use that as you want.
You can use either one you want but keep the same base OS, as far as I can tell openSUSE is the only immutable distro that lets you do that, which I think is pretty cool.
Why was NixOS/GuixSD considered for this? It has immutable system and is fully declarative on top.
Snaps OTOH just seem like a way tk shoehorn proprietary packages onto open source ecosystem (not to mention snap store itself is proprietory, and cannot be swapped for some other snap store)
I've used it before, and run a nixos server at the moment.
I think guix is a lot more ergonomic for package definitions and system configuration than nix, I also think the documentation is a lot easier to break into + it has a semi graphical installer.
the big downside being it doesnt come with proprietary drivers which is pretty annoying, but can be worked around with nonguix -- https://gitlab.com/nonguix/nonguix which also includes a few other proprietary programs, if thats something you need
I have not used GuixSD, but I peek evey now and then on its progress.
Like the sibling comment says, it has less warts than Nix and Nix language, but depending on your stance on Free software, you may need nonfree repo.
Additionally, NixOS has far more mindshare and manpower and has a vast repository, something to keep in m mind if you ever want some exotic piece, Nixpkgs has higher chance of having it already packaged.
As one of the folks that was present during the early decision-making around this, this was a wart that I wish the team had heeded me on fixing early on. Once they introduced "classically confined" snaps (that is, snaps that have no confinement and exposed the real filesystem hierarchy to them), there was no fixing this anymore. To be clear, the decision to stick to their guns on /snap predates the introduction of "classically confined" snaps.
The reason that "classically confined" snaps don't work on Fedora out of the box and don't work on Fedora Silverblue at all is because of this wart. Fedora's snapd uses an alternate path because /snap is not allowed. This means that /snap path doesn't exist, but it also means that "normal" snaps work fine on all Fedora variants, since it doesn't require an FHS hierarchy mutation.
None, but that’s the point/ feature of classic confinement snaps : they have access to the entire filesystem at the expense of having access to the entire filesystem :)
By comparison, a strictly confined snap only has access to its own data directory and possibly to some configuration files or the users home directory, depending on which permissions it’s been granted.
A text editor which is most useful if it can edit arbitrary files in the filesystem could be classically confined.
A music player might be strictly confined with access only to external devices (and maybe users home directory).
A fishy untrustworthy crypto miner could be strictly confined with no additional permissions so it can only see/touch its own data.
The resulting system still seems very mutable to me, since it appears the system configuration management isn't tracked in a transactional manner. I would think for a "immutable Linux desktop", NixOS would be what the author was looking for, since the whole system is declaratively specified and can be rolled back to any previous generation. But some users go even further, performing a ZFS rollback on every NixOS boot[0] to ensure that mutable state doesn't accumulate (NixOS only needs /boot and /nix to boot, and creates /etc /var etc. if they don't exist already).
[0] https://grahamc.com/blog/erase-your-darlings