维基百科是这样介绍 MicroOS 的：
MicroOS是一个极简、自我维护且事务性的系统，专为边缘计算与容器运行时设计，但也能作其他用途，比如桌面系统。
MicroOS 采用全新的方法来满足边缘计算或云计算的需求：MicroOS从只读文件系统运行，从而最大限度地减少维护需求。这样能够在一定程度上防止意外更改和恶意软件攻击。该系统是自包含和事务性的，这意味着 MicroOS 在更新时要么完全成功要么失败且不留下任何更改（即事务性更新），并在出现问题时回滚到前一阶段。事务更新不会影响正在运行的系统。基本上所有可用于 Tumbleweed 的软件也可用于 MicroOS。由于附带了podman这个容器运行时，MicroOS 可完美用于容器主机。
包管理
为了对得起 Micro 一词，MicroOS 的 Libzypp 配置为默认不安装依赖，且不安装文档。而且，默认的包管理器不是 MicroOS 服务器的 transactional-update 而是 pkcon。
这就导致了我刚刚装上的时候，里面既没有输入法，也没有浏览器……LibreOffice 这样的配套软件更是影子都没有。
虽然 MicroOS 鼓励使用 Flatpak 装软件，但是默认的 Flatpak 却没有任何软件源，用户需要自行添加。但问题在于，没有浏览器，添加软件源时就不能直接从 Flathub 上复制连接了。我当时是手机访问网页，然后一个字一个字的敲进终端的。然后后来我发现 KDE Discover（KDE 发现者，就是 KDE 的软件商店）的设置里面有个自动添加 Flathub 软件源的按钮（这个按钮只有在没有 Flatpak 源的时候才出现）。
另外，目前我个人不推荐使用 KDE Discover 装系统的软件包，因为其目前还没有使用 transactional-update 作为安装工具，装 Flatpak 包则没什么不可以的。
默认的配置还是会带来一些问题。
MicroOS KDE 没有预装 xdg-desktop-portal-gtk ，因为被依赖排除掉了，但实际上这个包是使用 Flatpak 内的 GTK 程序时必装的（安装 DVD 里面应该也是有的），不然使用时 GTK 程序外观会和 QT 的不一致。同样， tpm2.0-abrmd 也是缺失的，然后 fwupdmgr security 的安全检查又需要这个，在 KDE 信息中心会提醒你安全等级过低，据说 Gnome 也要加入这种提醒，所以干脆装上就好。
Flatpak
MicroOS 的本意就是让用户用 Flatpak 装应用。Flatpak 目前作为一种比较成熟的跨发行版打包方案还是有很多可圈可点的地方。
首先是 Flatpak 比 AppImage 这种更加跨平台，AppImage 依赖主机上的 libc 兼容，而且取决于打包者水平，AppImage 可能在跨发行版时遇到困难，而 Flatpak 不需要考虑以上问题。Flatpak 自身也是包含了近乎完整的运行时，这样在运行一些应用的时候，主机就没必要包含这些依赖，比如 Steam 不得不依赖一堆 32 位库，而 LinusTechTips 为了装个 Steam ，因为这蛋疼的依赖，毁掉了整个系统。
我平时也有在使用 Flatpak，所以讲 Flatpak 并不是本文重点。因为 MicroOS 的根文件系统不可写，用户避免安装软件而频繁重启的方式之一就是使用 Flatpak，另一个方式是使用 Toolbox 或 Distrobox 这样的容器化工具。
Toolbox
Toolbox 不是个包管理器的名字，而是一个脚本工具。他的作用很简单，帮你使用 podman 设置一个 非特权的 opensuse 容器。这样就可以安装自己需要的工具，而不受 MicroOS 原本不可写的根文件系统的影响。
使用方法也非常简单：
tux@Tux-Laptop ~> toolbox enter
Trying to pull registry.opensuse.org/opensuse/toolbox:latest...
Getting image source signatures
Copying blob 65b091c0910f skipped: already exists
Copying blob 44562acba0ab skipped: already exists
Copying config 907968a043 done
Writing manifest to image destination
Storing signatures
907968a04339e0c03834c646f063cc8af4fc3afdcbaef23c64dd32cf1e3e43cc
Spawning a container 'toolbox-tux-user' with image 'registry.opensuse.org/opensuse/toolbox'
Setting up user 'tux' (with 'sudo' access) inside the container...
(NOTE that, if 'sudo' and related packages are not present in the image already,
this may take some time. But this will only happen now that the toolbox is being created)
Container created.
Entering container. To exit, type 'exit'.
tux@toolbox-tux-user:~> 即可进入容器环境。
程序会自动配置 podman 容器，下载对应的镜像。Toolbox 的目标很简单： bring your own utilities with you ，翻译过来就是带上你的工具。所以 Toolbox 的目标就是存放开发环境和各种小工具，因此容器内部的 ~ 文件夹与当前用户是互通的，原本的 / 被挂载在 /media/root 下面，方便用户使用。
Toolbox 是 openSUSE 官方的项目，类似的第三方项目有 Fedora Toolbox 和 Distrobox，原理都类似。
加密
加密是现代计算机的一部分，不爽不要玩。讲真，Windows 在 OEM 那里都会要求启用系统的 Bitlocker，用户也没理由在用 Linux 时裸奔。但 MicroOS 的文件系统结构给这带来了困难。
MicroOS 不兼容单独的 /boot 分区。如果在安装时选择了单独的 /boot，安装程序会继续安装，但是在后期安装与升级和内核相关的软件时会有严重问题。
如果想避免输入两次密码，这里有个教程 Avoiding to type the passphrase twice
Nvidia
鉴于大多数需要 NV 驱动的玩意都跑在容器或 Flatpak 内部，那容器外部只需要 nvidia-gfxG06-kmp-default 和 nvidia-computeG06 ，前者是内核驱动，后者提供 nvidia-smi，那些GL库与GL32位库不用装。
但是如果要切换双显卡，suse-prime 还是需要安装的。
下面是 XWayland 下游戏运行的一个例子：
安装过程可能提示/boot/grub2: no such directory，因为分离了boot分区所以需要手动 ——我发现是我分离 /usr/sbin/grub2-mkconfig -o /boot/grub2/grub.cfg ，开了 SecureBoot 的话需要签名，安装后进 shell 把这个脚本复制到 /root 手动运行。理论上 openSUSE 会自动签名模块并导入 MOK，但是不知道是最近 Nvidia 的打包有问题，还是 MicroOS 有问题，或者我的单独 /boot 影响了安装脚本，反正就是没成功，需要手动签名。我翻遍了 Nvidia 的安装脚本也没找到他们签名的脚本在那儿……能力不足，所以没法追根究底。/boot 带来的问题。
虚拟化
VirtualBox 的 Qt 前端不支持 Wayland，所以只能用 libvirt 和 Virt-Manager。安装包组后还还要额外安装 qemu-hw-usb-redirect qemu-hw-display-qxl qemu-ui-spice-app。
说句题外话，我个人认为 VirtualBox 是开源虚拟化方案中图形化界面功能做的最好的一个，非常方便个人使用。至于 KVM 一派——安装个客户机辅助程序都要自己做个 ISO（官网只有 EXE，当然也可以用包含 VirtIO 驱动且只支持 Windows8 + 的 VirtIO ISO，但我测试这个 ISO 自带的 SPICE 客户机程序有问题，还是得从官网装），文件共享要自己弄 NFS 或 SMB （我认为 SPICE 的 WebDAV 做共享显然是个坏注意，微软对 WebDav 有个默认的 50MB 大小限制，大于这一大小的文件也无法下载）。
SELinux
MicroOS 以默认启用 SELinux 为特色。
但是吧，SELinux 有些时候不那么尽如人意。如果怀疑某个应用受到 SELinux 影响，可以使用 ausearch 排查审计日志（ -ts recent 代表最近10分钟）：
sudo ausearch -m avc -ts recent与一般的 SELinux 不同，MicroOS 要想重新给文件系统上标签（Relabel）不能直接用 /.autorelabel 而必须要 touch /etc/selinux/.autorelabel。因为根文件系统不可写，你写不进去。
SMB
不能开箱即用，多谢了 SELinux 用户需要手动。按照 配置 Samba。Selinux 拦住了 Samba 服务器，究其原因是没Selinu标记。sudo restorecon -R -v /var/lib/samba 从新标记。除了标记要共享的目录外，还要标记其上级目录（这样 samba 才能访问该目录，否则 canonicalize_connect_path failed）
Fprint
SELinux 也会影响 Linux 指纹认证，因为 Fprintd 文件夹的默认权限有问题，用 sudo rm -r /var/lib/fprint 删除然后让 systemd 重建文件夹，这样 SELinux 就会打上正确的标签。
游戏
SELinux 会拦住部分起源引擎的游戏，原因是他们的 MP3 库用了 execheap 和 execstack
，而这会使一段代码可被读写，又可以被执行，这不安全。（在 heap 和 stack 上执行代码确实有点那啥）Windows 的数据执行保护 (DEP) 会拦截类似情况，所以这并不是 Linux 或者 SELinux 。实际上，如果发现发行版自带软件触发了 execheap 和 execstack 规则，可以考虑汇报到发行版的开发人员。Valve 在新版的起源引擎游戏里也修复了这个，至少 CSGO 没这种问题。
同样 SELinux 也会拦住 Proton 和 Wine，因为这两种程序可能会使用 execmod 这种行为，尝试执行一个已经被 CoW 的文件映射。在发行版提供软件的情况下，需要这么做的库文件会被打上 textrel_shlib_t ，SELinux 这样做也是为了防止执行可写的内存，为了安全嘛。但我的实践表明，这种行为会导致 Proton 下的 Unity 崩溃。（似乎原生 Unity/Mono 也有类似1问题）对于系统自带的 Wine 这不是个问题，SELinux 已经设置了相应的策略，但显然发行版的 SELinux 策略可没法考虑到 Proton。
运行以下命令可以关闭这种保护：
setsebool allow_execstack 1
setsebool allow_execheap 1
setsebool allow_execmod 1这样设置不会被永久保存，重启后会恢复原状。如果想永久设置，运行的时候加个参数 -P。
setsebool -P allow_execstack 1
setsebool -P allow_execheap 1
setsebool -P allow_execmod 1当然也可以写一个本地策略，然后打上标签，允许这些行为。但考虑到这玩意实在太麻烦了，我猜没人会这么干。关于这些配置的详细解释在此：https://wiki.centos.org/TipsAndTricks/SelinuxBooleans
Rebootmgr
MicroOS 是为了容器和集群而设计的，所以有个默认的自动重启策略，可以通过命令关闭：
systemctl --now disable rebootmgr要不然用着用着自己关机就尴尬了。
Wayland
使用 MicroOS 三天，Wayland 治好了我的卡顿感。MicroOS 并没有强制用户使用 Wayland，KDE 默认的会话还是 “Plasma (X11)”，但是不得不承认，Wayland 确实解决了问题。
在 Xorg 上，我的 KWin 的垂直同步开了就像没开似的，画面常有撕裂；在 Wayland 上，KWin 的垂直同步就能很好的起作用。同时剪贴板的使用也更顺畅。Xorg 上使用 Firefox 的内置截图，将截取的图片放进剪贴板时，Plasma 会卡住一小会（讲真，剪贴板塞10MB左右的玩意就会卡就不现代了），Wayland 上则没有这种现象。
问题在于有些应用他不支持 Wayland 或者默认没有开启 Wayland 支持，就迫使 KDE 使用 XWayland 来照顾这些应用。用户可能需要设置一些额外的变量和参数。
另外，据说 Wayland 内部的缩放实现比较奇葩：先按一个很大的倍数渲染，之后再重采样缩小。比如 1.20 倍缩放是先放大到两倍再缩小——这也会导致一些比较奇怪的行为：Spice 客户端渲染窗口大小会比平常不缩放时小的多，Flameshot 截图会出现只显示在屏幕 1/4 区域的 Bug 。
XWayland
KDE 对 XWayland 的缩放支持不太完全，在高缩放下，KDE 会直接拉伸 Xwayland 内部的内容到对应比例，说白了就是强行放大，看上去比较糊。不过我是 1.20 缩放，还能接受。我本来是想放个图给诸位感受一下的，但是嘛……KDE 的 Spectacle 截图下来……Wayland 和 XWayland 都糊了。目前 Wayland 是真的不成熟。
总结
MicroOS 目前还非常不成熟。能用是能用，但小毛病一堆。Wayland 也是这样。新的开源技术在初期貌似都免不了这一阶段——能用，但绝对不算好用。我本人是在日用 MicroOS，但目前我是不建议像我这样尝试的。