MicroOS Desktop is basically openSUSE’s equivalent to Fedora Silverblue/Kinoite, just imho a bit better.
Immutable system
Based on the rolling openSUSE Tumbleweed (so it should be even more up to date than Fedora which has a new release every 6 months)
Automatic daily updates without needing user input/approval
Automatic rollbacks if a system update went wrong (based on btrfs + snapper I think, so relatively space-saving way of keeping the old system image)
Choice of GNOME and KDE Plasma
GUI applications are installed as Flatpaks. If not available as Flatpaks (e.g. CLI applications or those that need root) can be set up in Distrobox (equivalent to Toolbox in Fedora SB/Kinoite but imho superior) or as a last resort via the transactional-update command (equivalent to rpm-ostree in Fedora SB/Kinoite).
So basically this is like Fedora Silverblue/Kinoite but even more up to date and hands-off.
As openSUSE Tumbleweed is already recommended in the “traditional distros” section, I’d recommend adding MicroOS Desktop in the immutable section.
Havent tried it yet, very happy with Kinoite. Its literally the first distro I didnt break. Is KDE stable? Some time ago it was a horrible experience, I guess it got better. But gnome seems to always be better in preconfigs. Are flatpak apps autoinstalled?
In Discover, the flathub repository is enabled upon first login, and some flatpaks are installed by default (Mozilla Firefox and kCalc)
For Gnome:
At first boot flatpaks are enabled and some flatpaks are installed by default (Mozilla Firefox, Text Editor, Gnome Calculator and Extension Manager).
Currently they say on the Wiki that KDE is not as mature as Gnome in MicroOS, but according to various reviews I’ve seen it is already very usable and the missing pieces are smaller bits like for now having to install global themes for KDE through Discover, but the main functionality is all there already.
On Kinoite you cant install Global themes at all, which is a problem of SDDM writing to a read-only path, so upstream issue. There is a workaround, sddm2rpm
I’ve tried both a fresh Tumbleweed KDE and MicroOS KDE in a VM and can see no difference between the two KDE implementations. Both seem to work fine and I’m not sure why it still has the “alpha” status for MicroOS. Updating and installing the Flatpaks through Discover works as well.
There are updates now. OpenSuse supports GNOME primarily, and KDE is not focus. They even renamed the Distros, many people said this means they want to abandon the KDE side even more.
KDE also still is in beta. If you want GNOME, you can probably use that. But I have to say the installer is kinda weird.
Also it is not image-based, so I dont know how stable it really is, as there are no bit-for-bit integrity checks or rebase (I guess?) like with OSTree. Can you rebase using an ISO?
I agree the lack of progress with the KDE version (Kalpa) is disappointing. While KDE is the most popular desktop on Tumbleweed by far, there’s only one main dev for Kalpa at the moment. I guess the Gnome version (Aeon) can be good once you install half a dozen Gnome extensions to add basic functionality - same with Fedora Silverblue. But I think the renaming also takes some pressure off the KDE version because Kalpa can go at its own pace and doesn’t have to match Aeon’s features 1:1.
It’s not image-based, it’s a rolling release tracking the “Aeon”/“Kalpa” package patterns. So you can’t rebase but you’ll have the same packages as everyone else. However, once you start making changes to the system via transactional-update, you’re on your own and you can’t just rebase back to the standard image, just roll back to an earlier btrfs snapshot. So it’s not “anti-hysteresis” like Silverblue/Kinoite. However, the big advantage is that using transactional-update shell you can basically do any changes you want to your next snapshot, meaning you theoretically have the same flexibility as with Tumbleweed. My understanding is that Silverblue/Kinoite cannot do any changes to the system unless it’s via installing an RPM (which is then overlayed over the base image).
Its been recently renamed to openSuSE Aeon for GNOME and openSuSE Kalpa for KDE fans. It is currently on release candidate.
There is a certain lack of available reviews online and maybe @jonah would like to make a mini youtube/peertube review about it. Maybe compare and contrast Silverblue with Aeon (or Kinoite with Kapla).
Currently, there is nothing wrong with my Silverblue installed in my daily driver laptop for work. It is wonderfully boring, apart from some minor flatpak issues with some niche apps I use for work because of X11/wayland incompatibilities (that work without issues on a regular .rpm install).
I may move on to finally try my first openSuSE product after fixing my NAS as I have a lot of other things going on IRL right now.
This bump/almost necropost is in response to the recent-ish internet drama with RedHat - that frankly doesnt matter to me as a pedestrian/normie end user. I should know better than to participate in online drama and yet here I am. If you want to move on to other OSes, or just feeling a bit of distrohop bug bitting, this could be a good place to try if you want a Silverblue/Kinoite alternative because of privacy guides recommendation.
Which drama? Because there’s a lot of different things they’re pulling lol. Seems like they’re on a roll lately with pissing everybody off.
It saddens me as a long-time Fedora/RedHat fan user, but yeah, re-exploring alternatives might not be such a bad idea. I did use openSUSE for a time years ago, I’ll give it another shot sometime.
Drive encryption: On the final summary screen before the installation of the OS begins, click on Partitioning and then click on Guided Partitioning → enable LVM, enable disk encryption, separate /home (to optimize disk space use by using using btrfs subvolumes rather than partitions, but you can choose to have a separate /home if you prefer), separate swap (we will use swap-on-ZRAM instead)
Swap on ZRAM: sudo transactional-update pkg install systemd-zram-service, then reboot, then sudo systemctl enable --now zramswap.service
Wayland: just select the Wayland session at login if it’s not default already. Both GNOME and KDE support Wayland.
Firmware updates: don’t know but the Privacyguide already says that “openSUSE has the microcode updates applied by default.” Nothing to do.
Updates: System package will be installed automatically in the background, and with it being a rolling release based on Tumbleweed you’ll mostly get the up to date versions of all packages. Flatpaks can be updated through GNOME Software / KDE Discover, can probably also be done automatically (Discover has a toggle for “automatic updates”, not sure about Gnome). The only thing left would be the packages in your Distrobox container, if you’re using it (a Tumbleweed container is set up by default). On KDE you could make it automatically update by going to KDE Settings → Startup and Shutdown → Autostart → “Add Application”, then enter the command: /usr/bin/distrobox-upgrade --all but I don’t know if Gnome has a similar feature. (The more complicated but desktop-independent alternative would be creating a systemd service for this.)
SELinux, Firewall and Secure Boot are supported out of the box. Note that the Firewall may prevent openSUSE from discovering network printers. In Tumbleweed/Leap you can set up printers in Yast but Yast is missing in Aeon/Kalpa so you have to do it differently: Portal:Kalpa - openSUSE Wiki
This is something I would find useful. I’ve used both and the surface level user experience is largely the same, but I know that there are some fundamental differences under the hood which I would like to learn more about.
So far with my OpenSUSE Aeon VM i’ve managed to keep the base image completely ‘clean’ (nothing installed/overlayed on the base image). But I do find immutable’s like MicroOS / Silverblue somewhat frustrating and mentally taxing to use. Things that are super simple on a mutable distro require more conscious thought, research, and sometimes trial and error with an immutable distro. Part of this is just normal learning curve, not made easier by relatively skimpy documentation, but part of it is just the nature of immutable distros.
I think this is most if not all of it to be honest. From what I can tell, everything is possible on an immutable distro like Silverblue, you just do it via different means (and yeah, figuring out how can be tricky because of the poor documentation). But my point is once you do become an expert at using it you don’t run into these issues, and then going back to regular Linux feels ridiculous.
It’s like that YouTuber who learned to ride the backwards bicycle after months of practice, but then he couldn’t ride a regular bike properly afterward
Of course I won’t argue that it isn’t a super big challenge, and relatively most people’s time is probably better off doing other things to improve their privacy/security posture rather than learning how to use an immutable distro for little practical benefit (today). I’ll just continue to argue that immutable distros aren’t inherently more limited than traditional distros, or anything like that.
This is likely true in my case (and exacerbated by the lack of documentation and relatively small pool of resources and experienced users).
But my point is once you do become an expert at using it you don’t run into these issues, and then going back to regular Linux feels ridiculous.
Possibly true, I suppose what I was reflecting on is that in contrast to a traditional distro, each change you make each package you install requires more deliberate conscious thought (and sometimes research or troubleshooting). Something relatively simple like installing your VPN client or installing neofetch might be a single terminal command or a few mouse clicks with a traditional distro but can take more mental bandwidth and research with an immutable.
That said, I am excited about the development and growth of both Silverblue and MicroOS and acknowledge that some or most of my struggle has to do with my relative inexperience with immutable distros. And I especially see a lot of promise in MicroOS as a server distro, I really want to use it for my next home server once I get a little more comfortable with MicroOS and podman.
If you’d like some insight on why it is still in alpha, I suggest reading this blogpost by the primary contributor to OpenSUSE Kalpa (KDE Plasma flavor or MicroOS)
Yes but essentially it just talks about some Wayland bugs and stuff that would be the same in Tumbleweed. It would be more interesting to know if Kalpa is still “alpha” compared to Tumbleweed with KDE, or Fedora Kinoite as these are the competitors.
Yes but essentially it just talks about some Wayland bugs
That is not at all the takeaway that I took from reading the article.
And I don’t think its fair or accurate to reduce it to just ‘Wayland bugs’ considering that the authors problems were resolved by switching from Kalpa to Aeon (which both use Wayland). From the article:
after suffering through a couple weeks of pain with Plasma, I made the decision to just try and see what would happen, if I installed microOS Desktop Gnome (Wayland) on the same hardware, and the same configuration.
Quite literally, everything has worked. The Wayland session sees my external displays just fine, I have no screen flickering, my mouse and keyboard work, I can mount a samba share right through nautilus.
And as to:
It would be more interesting to know if Kalpa is still “alpha” compared to Tumbleweed with KDE, or Fedora Kinoite as these are the competitors.
Kalpa is considered to be in alpha regardless of what it is being compared to since the designations alpha, beta, etc are not comparative designations. But you are right it would be interesting to see if the problems the author encountered were present on Kinoite or Tumbleweed KDE. Kinoite uses Wayland by default, Tumbleweed KDE does not.
