What to Expect from System Updates?

English Install/Boot/Login
1

Hi, I just finished watching The Kalpa Desktop. In the video, Shawn mentioned that the Plasma Login Manager is on the roadmap.

I am not using Kalpa yet, but I would like to understand the scope of its capability. Specifically, I am wondering what we can expect as users:

  • Automated Updates: Will the Plasma Login Manager be automatically deployed after a reboot in the future, without requiring manual intervention?
  • System Transitions: For major shifts like switching from AppArmor to SELinux (as occurred in Tumbleweed previously), what should we expect if Kalpa is our primary OS?
2

Kalpa’s automatic updates will not change things like sddm → plasma-login-manager, grub2->systemd-boot or apparmor → selinux automatically.

SELinux is kind of a bad example, as Kalpa has been using SELinux since day one, but no, unless something goes horribly wrong, you shouldn’t notice anything changing like that, because that’s just not how changes like this work (technically not even on Tumbleweed), the contents of your running system should be fine.

1 Like
3

That makes sense. It sounds like there might be some “installation drift” over time as the default components of a fresh Kalpa install evolve.
You’ve mentioned “Powerwash” as a solution for configuration drift; could it also be used to transition the system to new defaults like plasma-login-manager?

I realize I could manually run sudo transactional-update pkg install plasma-login-manager, but I’m concerned that switching core components manually might lead to a broken or inconsistent state compared to a fresh install.

4

It’s possible, but a powerwash feature doesn’t exist yet.

5

Yes, that is a risk that you as a system owner take when you make changes, but that is a better situation than automatically letting the system do it whenever it decides to.

If you really want to keep the ‘fresh install’ experience, you do fresh installs. If you’ve kept everything you customize in your users home directory, a simple backup and restore after a reinstall is all you’d need to to do get the system back as you were before.

6

Automatic updates are a huge design goal of Kalpa in the first place, and are enabled by default. Users are largely not intended to be mucking about with things in the system root, enabling third-party respositories, or running manual updates.

It isn’t that it can’t be done, it’s just a case of “If you do it, you’re largely on your own to support whatever it is that you’ve done”

1 Like
7

Updates yes, massive system changes not so much. And to be clear, I am aware of how MicroOS/Aeon/Kalpa handle this as I do run MicroOS, though I absolutely customize it and those automatic updates are the first to be turned off.

But like I said, if you don’t make system changes, all you need to do to get the current new install defaults is backup your home, install new, restore home and you’re back to running the way you were before.

They expressed concern that if they did make these manual changes that their config would drift from whatever is the new default configuration, and yes that is the risk you take when you make customization to the system install. If you don’t want to take that risk your option is to reinstall, something that should be lower impact if you’ve been treating the system as an appliance.

8

Thanks for all the input.

I’ll keep an eye on Kalpa. I believe the biggest hurdle toward GA is probably similar to Aeon’s hurdle: OpenQA. Having a “Powerwash” feature would be great for attracting newcomers.

The reason I want to avoid fresh installs is that backing up home directories takes time. One of the main reasons many of us consider immutable distros in the first place is precisely to avoid that need.

“Simple” is contextual; in some cases, it can take an entire day just for the backup and restore process, without even accounting for other setup steps.

We know that whatever we choose probably won’t be, but every time we pick a distro, we want it to be our forever home.

9

There is absolutely nothing in Aeon/Kalpa, Fedora Atomic, VanillaOS or any other “immutable” distribution scheme, that negates the need for proper backups.

Period.

I can assure you that I am not developing Kalpa in any way, shape, or form, to somehow avoid users needing to have backups, nor is that in my development roadmap.

3 Likes
10

Can never be said enough.

2 Likes
11

To clarify, the “backing up” I referred to is specifically the process of moving the entire home directory to separate media, reinstalling the OS, and then moving it back.

I agree that data backups are essential, but they can take many forms; GitHub repositories, Dropbox for metadata, etc. An entire home directory can be massive (think of all the dependencies pulled when building software), even though the essential files may not.

When I talk about avoiding backups, I mean the full-scale backup of the entire home directory. While losing it would be cumbersome, the situation is manageable.

12

@san-b2ab Use rsync to your backup medium, yes the first one takes awhile, after that it’s just the differences… or however you configure.

I have a separate machine to rsync too, so it’s reasonably fast over ssh.

13

Yeah, the first backup of $HOME takes a while, but subsequent backups are fairly quick. I use vorta backup, to back mine up to my NAS via borg, and my incrementals, after the initial backup only take a few seconds, really.

14

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.