# Aeon Desktop (formerly MicroOS Desktop) **URL:** https://discuss.privacyguides.net/t/aeon-desktop-formerly-microos-desktop/12012 **Category:** Tool Suggestions **Created:** 2023-03-09T10:34:43Z **Posts:** 58 ## Post 1 by @Regime6045 — 2023-03-09T10:34:43Z 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. --- ## Post 2 by @Niek-de-Wilde — 2023-03-09T13:32:32Z Interesting project, ill be looking into it. --- ## Post 3 by @Torsten — 2023-03-11T00:52:35Z 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? --- ## Post 4 by @Regime6045 — 2023-03-13T09:25:39Z Yes, Flatpaks are set up automatically. See [https://en.opensuse.org/Portal:MicroOS/Desktop](https://en.opensuse.org/Portal:MicroOS/Desktop) For KDE: > 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. --- ## Post 5 by @Torsten — 2023-03-20T12:30:53Z > [@Regime6045](#): > > . 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](https://crates.io/crates/sddm2rpm) --- ## Post 6 by @Regime6045 — 2023-03-21T09:53:06Z 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. --- ## Post 7 by @Torsten — 2023-06-11T10:27:00Z 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? --- ## Post 8 by @Regime6045 — 2023-06-11T12:17:24Z 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). --- ## Post 9 by @anon73250778 — 2023-07-11T01:48:23Z I’d bump this again. Its been recently renamed to openSuSE [Aeon](https://en.opensuse.org/Portal: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. --- ## Post 10 by @jonah — 2023-07-11T02:51:33Z > [@anon73250778](#): > > recent-ish internet drama with RedHat 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. --- ## Post 11 by @anon61996769 — 2023-07-19T20:15:02Z Could you make a configuration guide for openSuse Aeon, to get it to the point? It would be of great help. --- ## Post 12 by @Regime6045 — 2023-07-20T08:30:31Z Following the General Recommendations from here: [Linux Overview - Privacy Guides](https://www.privacyguides.org/en/os/linux-overview/#general-recommendations) - 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](https://en.opensuse.org/Portal:Kalpa#Printer_Setup) --- ## Post 13 by @anon61996769 — 2023-07-20T17:30:48Z thank you!! --- ## Post 14 by @xe3 — 2023-07-20T22:32:39Z > [@anon73250778](#): > > Maybe compare and contrast Silverblue with Aeon (or Kinoite with Kapla). 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. --- ## Post 15 by @jonah — 2023-07-22T16:51:23Z > [@xe3](#): > > Part of this is just normal learning curve 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 :laughing: 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. --- ## Post 16 by @Viper — 2023-07-22T21:47:01Z using tumbleweed atm on spare laptop so far ok. i guess i can try this one too. \*wanting to see new avatar on front pg XD --- ## Post 17 by @xe3 — 2023-07-23T18:46:06Z > [@jonah](#): > > I think this is most if not all of it to be honest. 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. --- ## Post 18 by @xe3 — 2023-07-24T00:02:56Z > [@Regime6045](#): > > I’m not sure why it still has the “alpha” status for [the KDE Plasma version of] MicroOS If you’d like some insight on why it is still in alpha, I suggest reading [this blogpost](https://microos.opensuse.org/blog/2023-04-02-state-of-microOS-Desktop-Plasma/) by the primary contributor to OpenSUSE Kalpa (KDE Plasma flavor or MicroOS) --- ## Post 19 by @Regime6045 — 2023-07-24T08:34:38Z 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. --- ## Post 20 by @xe3 — 2023-07-24T19:18:48Z > 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. --- ## Post 21 by @anon73250778 — 2023-07-28T09:26:16Z I am back after nuking and paving my daily driver for MicroOS and here are my impressions: It is a _release candidate_ and still honestly feels like beta. I was expecting some basic power saving measures and hibernate function because I was going to use is as my daily driver for my laptop but it did not have those features ready yet. I closed my laptop lid and it did not turn off the monitor. I realized only this after about 4 hours with the screen on full brightness. It shouldnt be an issue but I have an OLED screen. When I came back, I tested my suspicion and I could still see the light shine through a bit on a closed screen lid in a dark room. There was also no fingerprint support off the bat and while it is probably more secure not have a fingerprint registered in a sensitive device, having to type a long password/passphrase everyday on a daily driver with no fingerprint alternative would be too much of a usability problem. All in all, OpenSuSE Aeon feels like 2 tiers below Fedora and Vanilla Ubuntu respectively. I really want to use it but the polish isnt there yet. I switched to a regular Tumbleweed install and above issues still persist. There was also the minor annoyance of learning the _right way_ to update. There are a lot of alternative ways to update a system and I am not aware if what is the preferred one (its probably zypper). Also about zypper, I really didnt want to learn another way to update: we already have apt-get, apt, dnf, pacman, pamac?, etc… and I realize OpenSuSE also uses the RPM and I wonder why they couldnt use the dnf instead? I am guessing the F in DNF is Fedora, maybe? I dont exactly know how to layer the Aeon/MicroOS Distrobox install over an app when I wanted to install something, to be fair, I really didnt try but Fedora Silverblue seems more straightforward - I just ran the .rpm file and it did install it on top of Silverblue. It feels like installing and updating is all over the place: Too many GUI apps to update and the experience is less that cohesive. We have 2 different kinds of GUI apps to do things and I feel like it should have been consolidated with the Software Center like how Fedora and Ubuntu does it. I also dont even know what YaST is for and I am tired of the random lower case in the naming convention of OpenSuSE products. At least System76 only have a weird name only in its title of Pop!\_OS. As for the plus: - I believe the OpenSuSE installer is probably the best at striking a good balance between usability and customizability. The only weak point in the installer is when I want to use a more complicated partitioning and somehow I am having a hard time to translate what I want to happen and what had to do. In the end I just opted for a plain recommended autopartitioning. - There is also the option of choosing your DE/WM in the install instead of downloading a separate KDE or GNOME (or other DEs if you have internet access during install) and you can even install a MicroOS system from a regular Tumblweed install. - I was really able to put most of the apps - flatpaks and AppImages that I needed in the end of the exercise to have a technically functioning system to do work with. * * * In summary: With the recent drama dying down and the focus going back on the worse of the Tech companies rather that RedHat. I want to go back again to OpenSuSE in the future and maybe give it one more good go in trying to daily drive it. Right now it is not a good laptop Distro with the above reasons (hibernate and fingerprint) but maybe it is a good desktop replacement for Fedora and maybe replacement for Silverblue. Maybe this is OpenSuSE Tumbleweed/Aeon may be fit for a small PC form factor (like a NUC) install? Despite as being an enterprise grade distro along the lines of RedHat and Canonical, OpenSuSE feels like it needs more polish and maturing and I dont know if this is due to a smaller base relative to all other Distros, not just the enterprise ones. Only time will tell. At least I am now more tuned in to them. --- ## Post 22 by @username0990 — 2023-08-02T13:22:39Z Is it possible to install a VPN client with the .deb package using distrobox and route the whole system’s traffic to the VPN without any problems like in traditional operating systems? --- ## Post 23 by @Regime6045 — 2023-08-02T13:45:20Z I was not able to get that to work but it could have been just my specific VPN provider’s app. --- ## Post 24 by @anon61996769 — 2023-08-02T16:13:53Z VPN and video drivers need to use transactional-update because they modify the system, distrobox does not work. --- ## Post 25 by @username0990 — 2023-08-03T06:00:56Z Thanks for the answer. Does this method not work because the OS is immutable, or because applications installed with distrobox cannot modify the system even on traditional operating systems (e.g. Tumbleweed, Leap)? --- ## Post 26 by @Regime6045 — 2023-08-03T08:11:48Z Applications in Distrobox cannot modify the system I think. I got some error relating to resolv.conf when I tried to install the VPN .deb in the Distrobox. You can still install VPNs on immutable systems via transactional-update (openSUSE) or rpm-ostree (Fedora), but the VPN would need to be available as an RPM package. --- ## Post 27 by @username0990 — 2023-08-03T11:08:55Z The Silverblue [FAQ](https://docs.fedoraproject.org/en-US/fedora-silverblue/faq/#_how_do_i_create_a_vpn_connection) states that the etc directory is not part of the immutable system. If it is the same for MicroOS, if etc is not part of the read-only immutable system, I think the VPN client application will actually work. I know distrobox is not a container that provides isolation, sandbox. If it is not a nickname similarity, it seems that the distrobox developer gave you a similar answer in the link below. > > > Problem: > My VPN providers only has an DEB package. They don't have a RPM or Ap…pImage so I can't install it on my distro (OpenSUSE). However I could of course create an Ubuntu guest in Distrobox and install their VPN app there. > > Suggestion: > It would be great if the VPN connection in the guest (here Ubuntu) also applies to the host (here OpenSUSE). So for example, if I connect to a VPN server via OpenVPN or Wireguard in Ubuntu, then all connections in OpenSUSE run through that VPN. --- ## Post 28 by @Regime6045 — 2023-08-03T11:25:28Z Yes you’re right. However, my specific VPN provider\* didn’t work even in a rootful container. I guess it depends on how well-designed the app is. I mean there’s even one VPN (ProtonVPN) that’s available as a Flatpak. '\* not a particularly good or private VPN provider, I just got a cheap lifetime deal many years ago and it’s still working so I’m not going to switch --- ## Post 29 by @starkle — 2023-08-03T20:16:19Z Worth noting that the option for full-disk encryption is [planned to be removed](https://en.opensuse.org/Portal:Aeon/DevelopmentThoughts#No_FDE,_Yes_FHE) on Aeon (and likely Kalpa), in favor of something more “user friendly”. FDE is currently a requirement for distributions to be listed here. Edit: Changed link to Wiki instead of matrix chat. [Original link](https://matrix.to/#/!rJKcfgIndKVMvmgntJ:opensuse.org/$ENp8tMw0IZVmoZY0LY7sI5pJp-A9PFOQw8NuDiai2c4?via=opensuse.org&via=matrix.org&via=tchncs.de) --- ## Post 30 by @Regime6045 — 2023-08-04T08:19:28Z this is informative and unfortunate --- ## Post 31 by @iustitia — 2023-10-04T17:25:55Z > [@starkle](#): > > Worth noting that the option for full-disk encryption is [planned to be removed](https://en.opensuse.org/Portal:Aeon/DevelopmentThoughts#No_FDE,_Yes_FHE) This is concerning, both because of the decision itself, but also the general approach to security it speaks of. > However, users need to have a secure Linux desktop, so we’ll be using systemd-homed by default to ensure that every users home directory is securely encrypted. Is this in any way an adequate replacement? Can anyone explain in some more detail how security would be impacted? --- ## Post 32 by @crossroads — 2023-10-05T18:55:51Z There’s some explanation > However, users need to have a secure Linux desktop, so we’ll be using systemd-homed by default to ensure that every users home directory is securely encrypted. Not even root on a potentially exploited Aeon machine will be able to change a systemd-homed users encryption key. > This should also bring additional benefits including > > - Support for FIDO2 as a second factor for user authentication > - User + Home directory portability, which is additionally useful in the event of resetting/reinstalling Aeon machines > - Forgetting encryption keys as system suspend, further improving security in a Laptop context > It does bring some complications > > - Storage management will be slightly more complicated than ideal, as the encrypted loopback device will need to be allocated space and managed appropriately. homed will do much of that automatically, but even at it’s best it doesn’t scale wonderfully. However, given most laptops are realistically to be used by 1-5 people most, this shouldn’t be an issue > - SSHing into an homed user will be much harder/impossible to support, as the user will need to be decrypted with the passphrase before SSH can read the key information. Given Aeon should be the OS you SSH FROM not SSH TO this is probably not the biggest issue > - Some tooling like gnome-initial-setup will need to be modified to work best with homed, which may cause some rougher edges than ideal for a while And I kind of agree with this. I stopped using FDE on desktop PC, and even on portable computers (steam deck) I could live without it, as long as my private files are encrypted (Cryptomator or KDE Vault). Though I do have it now on laptop with openSUSE --- ## Post 33 by @jonah — 2023-10-14T07:13:51Z File-Based Encryption is theoretically just better than FDE, as Android and iOS have proven… The general problem with it on Linux specifically is that verifying the non-encrypted portions of the disk (i.e. the system) haven’t been tampered with while the system is powered off is challenging. FDE prevents physical, offline attacks, and FBE has all the advantages they covered in the explanation above, but it alone doesn’t really address the same thing as FDE. This is why we usually recommend FDE _ **and** _ FBE like Cryptomator, systemd-homed, etc. I’m not sure how robust MicroOS’s secure boot implementation is to circumvent this issue? --- ## Post 34 by @anon21489307 — 2023-10-28T21:06:43Z Regarding openSUSE Aeon, I would like to add that as a Tumbleweed user, I don’t see any point in moving to Aeon **at all**. As a desktop user, I think it might be less secure for me too, due to fewer _official_ software sources available/compatible on the system, i.e. it doesn’t support Snap, and AppImage is not supported out of the box. That’s a lot of official apps out there. The recommended software source on Aeon is Flatpak, but it’s not there yet, as some major apps on Linux are not supporting it (yet), for example, **[Blender](https://projects.blender.org/blender/blender/issues/102949)**, **[Inkscape](https://github.com/flathub/org.inkscape.Inkscape/issues/87)**, **[VLC](https://code.videolan.org/videolan/vlc/-/issues/28356)**, all the Chromium-based browsers, IVPN client, in which Blender and VLC officially maintain Snap, while Inkscape officially maintain AppImage for non-Ubuntu users, and Brave officially maintain Snap, though not recommended. Big cooperations, for example, Spotify, Flutter (Google), Skype (Microsoft), support Snap, not Flatpak. I can’t list them all. If the users can’t find their apps in Flatpak, it’s recommended to install their apps in Distrobox, which might not fully compatible with all the apps. Some apps might not run at all. And the process of installing apps through CLI, also with dependency hell issue, is clunky at best. Most users who gave up with Distrobox, then fall back to `transactional-update`, or to Tumbleweed entirely, as you can also use Flatpak and Distrobox on Tumbleweed just like on Aeon. Then, you won’t mutate your OS ever again, assuming that your workflow/usage can survive with only Flatpak and Distrobox. Auto download and install updates? Yes, I do this on Tumbleweed as well with GNOME Software, no need to use Aeon. What about bad updates? Yes, I have snapper and rollback system in place _by default_ on Tumbleweed. The issue about all immutable OS is that the users believe that they can install unofficial Flatpak apps and call it a day since apps are sandboxed, which is not true, as it’s up to the packagers to set those permissions. The most noticable one is `filesystem=host`. Flatpak also doesn’t prompt any permission request to the users like Android or iOS does. With the current form of Aeon and the overall packaging situation, I would rather choose official support from devs, security-wise, over immutable things from the OS. --- ## Post 35 by @crossroads — 2023-10-29T06:41:25Z I agree with you. I was also TW user (swtiched to Leap & Kubuntu), and have been testing Aeon a bit. First I was surprised to see AppImage is not supported and Richard confirmed it will stay that way. So I realized if I would like to keep minimal number of programs installed from repos, I could still use Tumbleweed and install (only) snaps, flatpaks & appimages. I see these kind of distros useful for less experienced users (who would still need support when needed program is not available from the official package manager) and maybe (small) business --- ## Post 36 by @Regime6045 — 2023-10-30T09:13:59Z That’s a very interesting point. Would you bring the same argument against Fedora Silverblue/Kinoite, as they also don’t support Snaps (though I think AppImages should work)? (I guess the main benefit of an immutable system for me personally would be the ability to roll back updates, but Tumbleweed & Leap already support that anyway.) --- ## Post 37 by @sha123 — 2023-10-30T11:12:31Z I haven’t tested it myself, but you might be able to get Snaps to work. But it will be without Apparmor’s confinement, since Fedora’s and Suse’s immutable spins use Selinux, which basically makes Snaps unsandboxed. Snaps are far from perfect, but way less of the confined apps have _trivial_ sandbox escapes, while on Flatpak - without manually adjusting permissions -quite many do. And I have found way more of my apps with official packages as Snap than as Flatpak. Another advantage is that Brave’s and Firefox’s sandbox was fully functional and unmodified, last time I checked, which isn’t the case for browsers as Flatpak. There are also a few downsides, for example Snap fell through Suse’s security audit. --- ## Post 38 by @anon21489307 — 2023-10-30T14:05:32Z > [@Regime6045](#): > > Would you bring the same argument against Fedora Silverblue/Kinoite, as they also don’t support Snaps (though I think AppImages should work)? I have no experience with Silverblue/Kinoite, so I can’t tell. I tried Fedora 36 for 3 months, but it’s not my cup of tea, too much hassle to set up a stable system with snapshot and rollback system in place. Therefore, I went Tumbleweed ever since. Nevertheless, if Silverblue/Kinoite doesn’t support Snap, I would express the same argument I have with Aeon against it. > [@sha123](#): > > Fedora’s and Suse’s immutable spins use Selinux, which basically makes Snaps unsandboxed. I can’t understand why these immutable distros ban Snap. Sure, Snap has some security concerns against it. But why don’t they place the same concern against .rpm packages then? Compared to Snap, those packages have no sandbox or whatsoever. To me, it’s more like a political move than a technical perspective. As a user, I am concerned about security that all apps should come from the most creditable source (official channel from the app devs) whenever it’s possible. I don’t care a bit about Snap’s political nonsense. I will happily use Snap, Flatpak, AppImage, or whatever, as long as it’s from the _official/verified_ app devs. The OS should not interfere with that, especially if the users are put at another/even more risk by that interferance. --- ## Post 39 by @Regime6045 — 2023-10-30T16:57:14Z > [@anon21489307](#): > > I can’t understand why these immutable distros ban Snap. Sure, Snap has some security concerns against it I don’t they they “ban” it per se, it’s just that the `/snap` folder can’t be created if the root partition is immutable? --- ## Post 40 by @anon21489307 — 2023-10-30T18:16:59Z If they wanted the `/snap` folder to be mutable just like `/etc` and many others on the root partition, they could. So, I don’t think this is a technical limitation, see **[here](https://nelsonaloysio.medium.com/installing-ubuntus-snap-on-fedora-silverblue-e82ca6fd6108)**. I don’t know if this will work on Aeon, though. My point is it’s not impossible to support Snap on an immutable OS, technical-wise. --- ## Post 41 by @jonah — 2023-10-31T03:48:29Z I think you’re correct, it’s just that the people who are working on immutable distros—like Fedora—have strict policies about open-source software, and snap as a proprietary distribution method can never be officially supported as a result. To be fair, your question about why distros don’t support the `/snap` folder/filesystem is just as valid as wondering why snap doesn’t change itself to support immutable distros like Silverblue. The work could be put in on either end and neither one seems to want to do it, so here we are. It’s obviously _possible_ to use snap on an immutable OS because Ubuntu Core exists. When Canonical finally releases a desktop version of Ubuntu Core, they’re actually going to do the opposite and not support _Flatpaks_, so there’s a political component to this too for whatever reason. --- ## Post 42 by @Regime6045 — 2023-10-31T13:39:25Z > [@jonah](#): > > Fedora—have strict policies about open-source software, and snap as a proprietary distribution method can never be officially supported as a result But Snap _is_ open source and it’s also in the Fedora repository. Agree with you that it’s more of a political decision, not a technical constraint. --- ## Post 43 by @anon28734771 — 2023-11-24T10:49:11Z Does anyone know how can I use my security key for unlocking users and decrypting LUKS instead of typing my passphrases on MicroOS Kalpa? --- ## Post 44 by @anon63378630 — 2023-11-24T16:29:46Z @Lukas You can use pam-u2f for users and systemd-cryptenroll for luks. If you’re on Fedora or similar the included authselect package has a simple option that I added to use pam-u2f. --- ## Post 45 by @anon48875053 — 2024-06-02T08:21:38Z RC2 is here: > **[Aeon Desktop Brings New Features in RC2 Release](https://news.opensuse.org/2024/05/28/aeon-desktop-brings-new-features-in-rctwo-release/)** > > Contributors developing the Aeon Desktop are happy to announce a major milestone with the launch of Release Candidate 2 (RC2) images. Within the last 24 hour... --- ## Post 46 by @anon48875053 — 2024-06-06T10:47:10Z [https://x.com/sysrich/status/1797702451732382066?s=46](https://x.com/sysrich/status/1797702451732382066?s=46) --- ## Post 47 by @Dkama — 2024-06-06T18:00:04Z Was able to install Aeon in a VM with the MicroOS ISO, as there were no ARM images in Aeon’s own site. Found this: > **[Reddit - The heart of the internet](https://old.reddit.com/r/openSUSE/comments/15f4wde/microos_desktop_aeon_on_arm64_firefox_and_apps/jubbthu/?context=3)** > [u/rbrownsuse](https://snoo.habedieeh.re/user/rbrownsuse) SUSE Distribution Architect & Aeon Dev [Aug 01 '23](https://snoo.habedieeh.re/r/openSUSE/comments/15f4wde/microos_desktop_aeon_on_arm64_firefox_and_apps/jubbthu/?context=3) > > At this current time our plans are to drop aarch64 support for Aeon due to flatpaks like Firefox not existing and there being a general lack of hardware suitable for bare metal installs > > When I finally get around to publishing aeon only install media it will likely be x86\_64 only Which is both sad and weird, because 1. There’s nothing I haven’t found yet in Flathub for aarch64 2. Apparently installing FF via flatpak lessens its sandboxing, so it’s not even desirable --- ## Post 48 by @Slopadopolus — 2024-07-25T14:48:08Z > **[Reddit - The heart of the internet](https://www.reddit.com/r/AeonDesktop/comments/1ebqf4a/experimental_prerc3_image_available_for_brave/)** Installed on my laptop yesterday, having migrated my /home directory from RC2. Everything is working, except for updates, because it is currently pending Factory approval (once approved, updates will work)! @jonah when RC3 is accepted, will it be added to the Desktop/PC recommendations, seeing as it meets all criteria? --- ## Post 49 by @anon48875053 — 2024-07-25T15:00:29Z Can’t wait for RC3 to be released! I’m currently on RC2. I think Aeon should 100% be recommended when RC3 comes out. --- ## Post 50 by @xe3 — 2024-07-25T18:28:15Z > [@Slopadopolus](#): > > @jonah when RC3 is accepted, will it be added to the Desktop/PC recommendations, seeing as it meets all criteria? I’m not Jonah and can’t speak for PG, I think Aeon has promise and is interesting, but RC3 being labelled _RC3_ (Release Candidate 3) and not as _Stable_ is a deliberate choice by the lead developer. RC3 introduces some big and important changes (RC2 to RC3 will need a reinstall I believe), and having RC3 be a release candidate instead of a stable release, gives time to find flaws, test, refine/revise, check for unintended consequences etc, and make changes as needed, before the official release. This designation is the choice of he developer, not some external formal process, so if the developer felt it ready to be generally recommended and considered ready for primetime he would’ve labelled it as such. My recollection is RC3 or a possible RC4 is expected be the last release candidate before the first stable release if nothing comes up. **TL;DR** _In my opinion_ it is prudent to hold off on a recommendation, at least until an official stable release . Aeon is still evolving, changing, design decisions are still being made and changed or revised, and as important as anything else, documentation is still pretty sparse. Aeon is ready for testers, early adopters, and the curious, but (imo) not ready for general recommendation. --- ## Post 51 by @LumenNaturale — 2024-07-27T17:17:01Z > **[Reddit - The heart of the internet](https://www.reddit.com/r/AeonDesktop/comments/1edi3tr/aeon_rc3_released/)** “As RC3 is now ‘Feature Complete’ it is expected to be the last RC that will require a reinstallation. Users who install RC3 can expect to be automatically upgraded to any future RC versions and the official Aeon Release automatically… with only regular improvements expected as upstream versions develop and our community contribute additional features and packages.” As per Richard Brown, the lead dev on Aeon. @jonah ready for addition to PG now? --- ## Post 52 by @xe3 — 2024-07-27T20:13:47Z You left out some relevant parts of the announcement, that should partially answer your question: > The main difference between RC3 and official Release will be the writing of [openQA Tests](https://github.com/os-autoinst/openQA/blob/ff00eea047a30b6390b25fdb490c800e5cc71265/docs/WritingTests.asciidoc) to cover Aeon’s installation and basic functionality. And [followup](https://www.reddit.com/r/AeonDesktop/comments/1edi3tr/comment/lf8bxz2/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button) in the comments: > > **[Redditor]**: I assume OpenQA testing is designed to catch bugs, improve reliability and possibly security. And that that should be a pre-requisite to an official release. Is my impression more or less correct? > > **[Aeon’s Lead Dev]**: That is correct. openQA will provide a safety net to make sure Aeon keeps working as well as it is right now. And that subtle but important difference is importantly for people expecting a “Release quality” product > > **[Redditor]** Would you recommend Aeon to a conservative and security focused audience today (RC3), or recommend this group of users hold off until after Aeon’s official release? > > > > I interpret RC as implying Aeon is usable, close to ready, and ready for testers and early adopters, but not yet the full general public, is that more or less what you mean to imply with the RC tag? > > **[Aeon’s Lead Dev]**: That would be a perfect summary of the current status, yes > > [late edit] I’d recommend it to anyone, security and conservative users included, now as long as they’re comfortable with maybe needing the odd extra rollback until we’ve got Aeons testing to meet our expectations * * * I’m enthusiastic about Aeon (have been for over a year), but I reallycan’t understand the urgency here. What urgency justifies PG officially recommending a pre-release distro, particularly considering that Aeon’s lead developer is also not officially recommending it to a general audience yet. --- ## Post 53 by @Regime6045 — 2024-07-27T20:28:52Z Meanwhile Kalpa seems to be standing still in “alpha” :smiling_face_with_tear: Aeon is such a great concept for a distro, but I can’t bring myself to use that awful, horrible desktop (the one formerly known as GNU Network Object Model Environment) --- ## Post 54 by @LumenNaturale — 2024-07-27T21:14:11Z > [@xe3](#): > > I’d recommend it to anyone, security and conservative users included, now as long as they’re comfortable with maybe needing the odd extra rollback until we’ve got Aeons testing to meet our expectations You just answered your own question: _it is ready, and meets all PG criteria for inclusion._ Personally, it’s the best distro I’ve ever used, so obviously I would like others to have a similar experience as soon as possible! --- ## Post 55 by @xe3 — 2024-07-27T21:52:47Z > [@LumenNaturale](#): > > You just answered your own question: _it is ready, and meets all PG criteria for inclusion._ Personally, it’s the best distro I’ve ever used, so obviously I would like others to have a similar experience as soon as possible! It feels to me like you are repeatedly cherrypicking and quoting only the specific parts of statements that support what you want and excluding everything else. It makes it frustrating to try to discuss. I added Richard’s late edit, for the sake of giving the full picture, and because it is useful information, knowing full well you would probably fixate on just that one line and ignore everything else he said in his comment. But I did it anyway, because quoting only the part that supports my perspective would be disingenous and unconstructive. I wish that you would try to do the same. Richard Brown’s willingness to personally but not officially recommend Aeon to users so long as long as they don’t mind things breaking and rolling back occasionally, and don’t care about waiting for testing/QA is part of the whole of what he said. But so is everything else he said in that comment, including that: > > Aeon is usable, close to ready, and **ready for testers and early adopters, _but not yet the full general public_** > > [Aeon Lead Dev]: **That would be a _perfect summary_ of the current status, yes** You still haven’t explained the sense of urgency (meeting PG’s minimum criteria isn’t enough, dozens of Linux distros meet the criteria) why the immediacy? Why take the risk of officially recommending pre-release software now rather than just being patient for a some weeks or months. Giving some time for testers and early adopters to test the substantial changes that just landed _today_, for docs to catch up and improve, and for Richard to decide Aeon is ready for an official release. As he often says, _‘Aeon will be ready when its ready.’_ --- ## Post 56 by @anon48875053 — 2025-04-27T08:26:09Z So what’s keeping Aeon from being recommended apart from the arbitrary RC3 status? --- ## Post 57 by @anon1614724 — 2025-04-27T10:41:07Z I suppose that’s the only thing… unless someone want’s to bring up the firewall question which has been answered several times. --- ## Post 58 by @anon57621611 — 2025-11-05T14:31:18Z I’ve tried Aeon several times during the past year and every time I’ve encountered serious issues with FDE so I had to reinstall. Other than that and the GNOME only option, the distro does seem nice and I hope the openQA test will be written soon so it can become Stable. To be honest, AerynOS also looks very promising.