<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
I tried Fedora Kinoite 42-1.1 and 43-beta in VirtualBox (7.2.2).<br>
<ul>
<li>Both installed OK.</li>
<li>Right after, they show 12 updates waiting.</li>
<li>I click "Update All".</li>
<li>I get 10 errors, and they're unusable after that.</li>
</ul>
Maybe it's my VirtualBox, I don't know. At least, <b>Mint</b>
(XFCE + KDE) is standard layout.<br>
<br>
By the way, doesn't <b>Fedora</b> have ability to "revert" back to
last snapshot? I remember, reading about it.<br>
<br>
<br>
<div class="moz-cite-prefix">On 2025-10-20 00:20, Doug Moen wrote:<br>
</div>
<blockquote type="cite"
cite="mid:278b8cb5-cad9-4e5b-9cbf-5ef35258853b@app.fastmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<title></title>
<div>William, probably just ignore what I said earlier. I've
upgraded my Thinkpad from Mint to Kinoite now, and I'm still
trying to understand how it works.</div>
<div><br>
</div>
<div>The underlying filesystem is btrfs. The root file system is
mounted as a readonly composefs file system. The "OSTree"
system, which appears to be a git-like version-controlled
package manager, implements a "content-addressable object
store", where multiple versions of the same file can exist.
These files are immutable and are addressed using their content
hashes (which is roughly how I believe git works). Multiple
different versions of the same package can coexist in the object
store. Multiple releases of the operating system can co-exist in
the object store. Metadata is used to describe a particular
version, which then corresponds to a particular tree of files
and file content (which, note, is immutable). This metadata is
interpreted by the composefs file system driver to materialize
an immutable tree of files for a specific OS release.</div>
<div><br>
</div>
<div>With this system, you can't directly modify the files of the
core operating system in the usual way, eg by editing a text
file. The root filesystem is readonly. Instead, the way you
modify it is by installing, upgrading, or removing a package
(together with its dependencies). (Note that you can edit files
in /etc.)</div>
<div><br>
</div>
<div>I am free to install any package I want into the core OS.
I'll be installing RPMs, since this is Fedora. The core OS
package manager is called rpm-ostree. OSTree keeps track of the
history of package installs as a sequence of git-like commits,
or layers (like in a container repository).</div>
<div><br>
</div>
<div>Until now I've mainly used Debian based distros: Ubuntu and
Mint. My typical habit is to install all sorts of weird software
from 3rd party repositories. Eventually the package system
somehow gets corrupted and a bunch of things break when I
upgrade the operating system. OSTree is supposedly more
resistant to this kind of corruption to due the additional
structure it keeps track of. One big benefit is that if you
install a package and all its dependencies, that change will be
applied as a single atomic transaction, either all or nothing.
And then you can cleanly revert this change later, without
ending up with packages that are no longer referenced and must
be garbage collected.</div>
<div><br>
</div>
<div>One thing I managed to do a while back was corrupt the C
compiler, clang, after an OS upgrade. I have no way of knowing
how this happened, and there's no way to fix it other than wipe
the disk and do a clean OS install. The Mint documentation warns
you that this can happen, and tells you to do a fresh install as
the solution, so it's not just me. It must be inherent in the
way that the Debian apt package manager works. The Mint docs say
you are particularly at risk when you use 3rd party package
repositories.</div>
<div><br>
</div>
<div>With Kinoite, you are encouraged to be choosy about what
packages you install in the core OS. For development work, you
are recommended to work in a container. You can have multiple
containers with different versions of the same languages, and
they don't conflict with each other. Upgrading the operating
system won't break any of your containers. You can delete a
container without modifying the core operating system or
interfering with any of the other containers. Kinoite
pre-installs a container tool called "toolbox", which allows you
to create a custom environment in which you can install
packages, then you can run a shell in this container.</div>
<div><br>
</div>
<div>For GUI apps, you are encouraged to install flatpaks, instead
of installing apps directly into the core OS (although either
will work). The new install of Kinoite came with an old version
of Firefox in the core OS. I don't use firefox anymore, because
it is riddled with advertising and spyware. I installed
LibreWolf and Ungoogled Chromium from flathub, and they work
flawlessly. They were a bit buggy on Mint, which had soured me
on the use of flatpaks, but on Kinoite, it appears that flatpaks
just work.</div>
<div><br>
</div>
<div>Instead of Cinnamon, I'm using KDE. They are very, very
similar; both are essentially clones of the classic Windows
desktop environment. On my previous Cinnamon install, the
desktop magnification feature was buggy and flaky. I rely on
this due to my eyesight. On my new system, it is so far rock
solid.</div>
<div><br>
</div>
<div>I'll need to use the system for 6 months and go through a few
upgrade cycles before I know if I like this, but so far it is my
best experience yet for desktop linux.</div>
<div><br>
</div>
<div>The installation process is not beginner friendly, and
setting up dual boot correctly in particular is claimed to be
tricky, but once installed, it is quite beginner friendly.
LIbreOffice is not preinstalled, but it's in the app store,
which is pinned to the dock. A beginner would just be installing
flatpaks from the app store, and not messing with the command
line tools that I mentioned.</div>
<div><br>
</div>
<div>There are other distros that work this way, not just Fedora.
Eg, <a href="https://vanillaos.org/" moz-do-not-send="true">Vanilla
OS</a> is debian based. Search for "immutable linux".</div>
<div><br>
</div>
<div>Doug.</div>
<div><br>
</div>
<div>On Fri, Oct 17, 2025, at 8:38 PM, William Park via kwlug-disc
wrote:</div>
<blockquote type="cite" id="qt" style="">
<div class="qt-moz-cite-prefix">
<div><br>
</div>
<div>On 2025-10-17 07:04, Doug Moen wrote:</div>
</div>
<blockquote type="cite"
cite="mid:b28b0bee-eb33-42bc-a1bf-1e5df5dc921e@app.fastmail.com">
<div>The system doesn't switch over to the new release until
you reboot, when it will atomically switch over to the new
release. Internally, the atomic switchover doesn't require
moving or copying files, it's just a single file that
changes to point to the new release. If the new release has
problems, you can roll back to the previous release, either
in the boot menu, or in the GUI app store.</div>
</blockquote>
<div><br>
</div>
<div>Single file? Ahh, mount this "os file" read-only, and then
do overlay. If "os file" can be selected like "kernel" now,
then it would be easier for users. My only concern would be
speed.</div>
<div> <br>
</div>
<div> But, having separate /home partition, and 2 root
partitions (current and old) would be same thing, no? Just
don't wipe the <b>whole</b> disk, when installing distro. :-)</div>
<div>_______________________________________________</div>
<div>kwlug-disc mailing list</div>
<div>To unsubscribe, send an email to <a
href="mailto:kwlug-disc-leave@kwlug.org"
moz-do-not-send="true" class="moz-txt-link-freetext">kwlug-disc-leave@kwlug.org</a></div>
<div>with the subject "unsubscribe", or email</div>
<div><a href="mailto:kwlug-disc-owner@kwlug.org"
moz-do-not-send="true" class="moz-txt-link-freetext">kwlug-disc-owner@kwlug.org</a>
to contact a human being.</div>
<div><br>
</div>
</blockquote>
<div><br>
</div>
</blockquote>
<br>
</body>
</html>