<!DOCTYPE html><html><head><title></title></head><body><div>I am actually running Kinoite as a daily driver, and I can install packages in the base system just fine. Red Hat originally called this distro family "immutable", but changed the word to "atomic" since it isn't actually immutable. You can install packages. There are some other distros that use similar technology but which really are immutable, in that a local administrator cannot change the base system at all, it can only be changed by an OS update. I'm running GrapheneOS on my phone, and that OS really is immutable.<br></div><div><br></div><div>It is true that the root file system is mounted readonly. When you install packages, you need to reboot in order for the changes to be activated. If your changes break the system, you can roll back, either from the command line, or from the boot menu if you broke the boot.</div><div><br></div><div>The benefit of an atomic system like KInoite is that the technology for package management and upgrade is more robust. You can roll back, you can pin versions to keep them in the rollback history, and you can move sideways between different distros based on the same tech stack, all using the same management interface. "Atomic" means that when you install a package or upgrade the operating system, it is impossible for the system to get stuck in a half-way state (eg, due to a power interruption in the middle of package installation or upgrade). Changes to the base system are atomic: either they succeed, or they fail, and if they fail, the system doesn't change. One of the features of an atomic system is that you can install packages, or upgrade the system, in the background, without interrupting the normal operation of the computer. You can never observe the system to be in a half-way state during normal operation. It only atomically switches to a new state when you reboot. You can also configure the system to install updates automatically, in the background, whenever the system senses that new updates are available. This is perfectly safe due to the system being atomic.</div><div><br></div><div>The recommended way of administering a Fedora atomic distro is that you don't put all of your installed packages in the base system, because that is inflexible. Instead, it is suggested you use flatpaks for GUI apps, and you use containers for CLI and development work. You can use different containers for different projects (these containers might contain different versions of the same software). A given container can be set to use the Fedora RPM repository, or Debian, or whatever you want. If a container gets corrupted due to dependency hell, you just delete it: your base system is safe.<br></div><div><br></div><div>Doug.<br></div><div><br></div><div>On Sun, Dec 28, 2025, at 2:53 AM, Jason Eckert wrote:</div><blockquote type="cite" id="qt" style=""><div dir="ltr"><div>1. Kinoite is immutable (i.e., read-only root filesystem, much like modern macOS), so updates replace the whole OS as a snapshot rather than patching files in place. This makes updates safe and rollback-able, reducing the chance of a broken system. Even if versions match, the update mechanism and system stability model are different from regular Fedora.</div><div><br></div><div>2. You can\u2019t normally add packages to the immutable base; instead, you typically use Flatpak for extra software. If you rollback, the base OS reverts to the snapshot state, so any base-layer packages added after that snapshot are lost, but Flatpaks and containerized tools remain.</div></div><div><br></div><div class="qt-gmail_quote qt-gmail_quote_container"><div dir="ltr" class="qt-gmail_attr">On Sat, 27 Dec 2025 at 21:31, William Park via kwlug-disc <<a href="mailto:kwlug-disc@kwlug.org">kwlug-disc@kwlug.org</a>> wrote:</div><blockquote class="qt-gmail_quote" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div><u></u><br></div><div><div>Questions...</div><div> <br></div><div> 1. Regular Fedora KDE 43 has the same KDE/kernel versions, but after
few updates. So, what's the point of "atomic" when it's updated
like the regular?</div><div> <br></div><div> 2. Can you install new packages in Kinoite? And, if you "revert" to
old version of OS, then what happens to the new packages?</div><div><br></div><div><br></div><div>On 2025-12-27 18:16, Doug Moen wrote:</div><blockquote type="cite"><div>I'm running Fedora Kinoite. I have Linux 6.17.12, Plasma
6.5.4.</div><div>This matches Debian testing, so it's up to date.</div><div><br></div><div><br></div><div><br></div><div>On Sat, Dec 27, 2025, at 7:16 AM, William Park via kwlug-disc
wrote:</div><blockquote type="cite" id="qt-m_-3408785592137107778qt"><div>(Double posted, so reply to your list)</div><div><br></div><div>I've been looking for a distro with recent KDE and recent
kerne<b>l</b>. So, the benchmark was <b>Kubuntu</b> 25.10
(v6.4 KDE, v6.17 kernel).</div><div><br></div><div>1. Started with <b>Mint</b> + "<span class="font" style="font-family:monospace;">apt install kde-full</span>".
Result was comparable to Kubuntu LTS, ie. v5.27 KDE, v6.14
kernel. Makes sense, since Mint is based on Ubuntu LTS.</div><div><br></div><div>2. Then, tried <b>LMDE</b> + "<span class="font" style="font-family:monospace;">apt install kde-full</span>".
I was surprised to get a rather recent v6.3 KDE with v6.12
kernel. I was expecting an old KDE, even older than Mint
version.</div><div><br></div><div>3. So, decided to try <b>Debian</b> <b>testing</b> +
KDE. I got v6.5.4 KDE (latest) and v6.17.12 kernel. Not bad.</div><div><br></div><div>Right now, <b>Debian testing</b> is compiling v6.12.62
and v6.18.1 kernels for Raspberry Pi Zero 2W. We'll see how
it goes.</div><div><br></div><div>To those using Debian testing, how would you rate its
stability? Is it suitable for daily PC?</div><div>_______________________________________________</div><div>kwlug-disc mailing list</div><div>To unsubscribe, send an email to <a href="mailto:kwlug-disc-leave@kwlug.org" target="_blank">kwlug-disc-leave@kwlug.org</a></div><div>with the subject "unsubscribe", or email</div><div><a href="mailto:kwlug-disc-owner@kwlug.org" target="_blank">kwlug-disc-owner@kwlug.org</a> to contact a human being.</div><div><br></div></blockquote><div><br></div></blockquote><div><br></div></div><div>_______________________________________________</div><div> kwlug-disc mailing list</div><div> To unsubscribe, send an email to <a href="mailto:kwlug-disc-leave@kwlug.org" target="_blank">kwlug-disc-leave@kwlug.org</a></div><div> with the subject "unsubscribe", or email</div><div> <a href="mailto:kwlug-disc-owner@kwlug.org" target="_blank">kwlug-disc-owner@kwlug.org</a> to contact a human being.</div></blockquote></div><div>_______________________________________________</div><div>kwlug-disc mailing list</div><div>To unsubscribe, send an email to <a href="mailto:kwlug-disc-leave@kwlug.org">kwlug-disc-leave@kwlug.org</a></div><div>with the subject "unsubscribe", or email</div><div><a href="mailto:kwlug-disc-owner@kwlug.org">kwlug-disc-owner@kwlug.org</a> to contact a human being.</div><div><br></div></blockquote><div><br></div></body></html>