Get rid of snap and I’m interested
(and possibly Snap)
I hope they exclude Snap from the default installation. Don’t want an OS with built-in support for Canonical’s closed source app store service when Flatpak is decentralized and FOSS on the server side.
Obligatory please-stop-releasing-new-distros-and-just-improve-exiting-things-instead
What do you have difficulty exiting?
Introducing vimux, the brand new distro nobody has any idea how to exit!
My immediate thought was: why not NixOS as a base? Building KDE is such a nightmare that if they had to deal with it themselves on NixOS, it would help them clear up their dependencies. Right now it’s such a big mess of unnamed and implicit dependencies that exposing it to the team would also show them how to cut down on them.
My hope was also that if the KDE team were invest in a NixOS offshoot, that the OS would finally get proper GUIs or integrations into existing GUIs like Discover (why not Diskover?) Or the system settings and other config management.
But, to be fair, I could understand if they considered it, took one look at the documentation and noped out.
The “distro” would be reduced to a configuration file base (which Id be all for imo).
On that note, Nix desperately needs officially supported config sharing social system like dotfyle.
Cool. My first thought was how this would differ from blendOS, which is also immutable Arch. Seems like the main difference is the use of systemd-sysupdate to handle unprivileged updates.
Not sure how rollbacks are handled, but I only glanced at it.
Flatpak: 😏
Snap: 😑
Flatpak and snap? Count me the hell out.
Wondering why this isn’t built on opensuse.
Opensuse doesn’t have rpm-ostree. Their immutable offerings are just snapper/btrfs snapshots before changes to the system.
Such a setup is nowhere near as powerful. rpm-ostree can rebase itself based off of a container/oci image. It can layer images on top of eachother. Rather than just tracking when changes happened, it can also track what change happened, in a git style setup.
Ok, so rpm-ostree was the reason. Was not aware suse Lacks this…
Oops… my bad. In my earlier comment I assumed that this would be a Fedora/Ublue based distro, rather than an Arch one. Arch doesn’t have RPM ostree either (which makes me dislike it as a choice for an immutable distro).
But, it’s highly likely that with the steam deck and other projects, there is already an ecosystem for immutable Arch, and a minimal base system to start is advantageous, as Possibly Linux said.
Why would it? OpenSUSE isn’t a good choice for a base system it is fairly obscure and the base is rather large.
They have been a supporter / promoter of KDE for a long time, would seem logical to me that KDE would go with suse.
Suse isn’t well suited for a minimal base system. You would want something like Arch or Debian and in this case they went with Arch.
Hmmm I guess this kind of makes sense - most distros push Gnome above KDE (probably because it doesn’t look like this - where’s Tantacrul when you need him?). On the other hand, there’s already Kubuntu…
I’m a bit skeptical about immutable distros too. What if I want to install a package that isn’t already installed and isn’t available as a Flatpak/Snap? Seems like it’s going to run in similar issues to everything else that tries to wade upstream against the bad decisions of the existing Linux packaging zeitgeist, e.g. how Nix has to install everything in one root-owned directory because nobody cares about portable installation.
What if I want to install a package that isn’t already installed and isn’t available as a Flatpak/Snap?
Interesting, so that’s sort of customising the image somehow? Does it use an overlay FS or something?
The silverblue docs explain it best:
When a package is installed with rpm-ostree, a new OS image is composed by adding the RPM payload to the existing OS image, and creating a new, combined image.
