With the rise of immutable and atomic desktop operating systems (such as Fedora Silverblue, Kinoite, or Bazzite), the way users interact with updates is changing. Unlike traditional package-based systems, these environments often require a reboot to switch into the new deployment after an update.
However, many users, especially casual ones, primarily rely on sleep instead of shutdown or restart. This can create confusion: even after applying updates through tools like Discover or Topgrade, the user may not realize that the system is still running the old deployment until they manually restart.
Suggested Approach:
A simple but effective solution would be to adopt a mechanism similar to what Windows 11 uses:
When updates are pending, the restart and shutdown options could change to indicate this (e.g., âRestart and Updateâ or âShutdown and Updateâ).
The buttons could also change color or display a badge/indicator, signaling that a new update will be applied on the next boot.
Hovering over the button could show a tooltip explaining: âAn update is ready. Restarting will boot into the updated system image.â
Why this is Important:
We are in an era where restarts and shutdowns are rare, and users increasingly expect updates to âjust workâ once they press update in their package or system management app. Without a clear notification, they may assume their system is fully updated when in fact the new image is pending activation.
This feature would:
Prevent confusion for end users.
Improve usability of immutable and rpm-ostreeâbased systems.
Align KDEâs UX with user expectations from other platforms.
Ideally, this functionality should not be hardcoded to a specific update tool (such as Discover). Instead, it should be flag-driven, allowing distributions to enable it depending on their update mechanism (e.g., Fedoraâs rpm-ostree).
PS:
If I had the technical skill, I would gladly begin contributing to this feature myself. Unfortunately, I donât have the necessary expertise, but I wanted to put forward the idea in the hope that it resonates with the community and developers.
I have no idea about Windows 11, but I know when I apply MY updates, Iâm told if a restart is required, and Iâm also told if only certain components need restarting (which means I donât need to reboot or restart the desktop). Itâs an interactive experience; and itâs not related in any way to KDE or Plasma.
Your post appears to aim to change KDE to suit Redhat immutable and rmp-ostree systemsâŚ
I donât think tying updates to restart or shutdown is a good idea though⌠generally the function only advises you AFTER you perform your update that a restart is needed - but thereâs no need to update until you want to load up the new stuff.
Basically we start the ball rolling with the Debian original tool needrestart which performs checks - kernels, libraries, running services, and service/daemons.
Basically weâre presented with a message like this:
:: The following 3 services should be restarted:
nginx.service
cronie.service
docker.service
Then options to restart each service, or reboot. It behaves differently for User applications (like Firefox) than background services (nginx) and obviously for Core libraries and Kernel, it advises you that to complete the update, a restart is recommended.
If only Windows 11 could come even close to competing with this granular approach!
If linux starts updating more like Windows 11, Itâll be time to run off and join the flowerpot men.
Arch brings needrestart to the table, though this isnât the original tool.
Fedora has needs-restarting part of the dnf-plugins-core package.
Debian invented needsrestart and after an upgrade, you see lists of processes and services that need a restart.
openSUSE (Tumbleweed et al) has it in zypper.
Remember, Windows enjoys itâs single-point failures; so restart required is necessary.
Linux is a collection of independent parts allowing for a more granular update strategy, itâs much better and more advanced than Windows 11.
So I would suggest keeping an eye on what KDE Linux does around this, and encouraging the Fedora / uBlue distros to hook into the Plasma functionality that supports this.
I havenât tried KDE Linux myself but it looks like there are a few tickets being worked on around the update experience.
I think we are talking about two different but related things:
Detecting that a recently installed update would need a restart to become effective
Indicating this recommendation to the user
First thing seems to work already pretty nicely on normal Linux setups, so it it doesnât for image based updates then this is probably something that can be fixed easily (always need a restart to switch to the new image).
Second is currently handled by showing the restart icon in system tray.
Adding further visual hints in places that deal with shutdown/restart/sleep might still be worthwhile but probably more along the lines of a badge
i like the idea of a restart button that changes color when there is a mismatch between the native updates that have been applied and the packages that are currently running in memory.
that seems like a good feature for a DE to have.
the current default of using âoffline updatesâ to force a restart after every update seems heavy handed, imho.
with my snap version of firefox, it will notify me when there is an update and all i need to do is close the app and re-open it for it to be applied⌠easy peasy.
@ben2talk Sorry but how is literally anything you wrote in your reply have ANYTHING to do with a simple flag that shows a badge on the shutdown restart button? Out of my whole post that requests a dead simple update budge/color on the shutdown update buttons you chose to focus on the âlike windows 11 doesâ.
Why? Doesnt KDE trying to provide a unified UX for the enduser with plasma? Why not make the distro maintainers do a bunch of other stuff then? A simple feature/flag that is integrated in the plasma experience is exactly the point of what plasma is trying to achieve. Instead of each distro trying to do its own thing KDE can have a simple flag that provides the function to each distro maintainer to use at their own tempo/function, but instead of being jarring to the eyes it ties right into the Plasma UX.
A simple color change or badge on the shutdown/restart button that gets activated with a RestartPending flag.
I agree. But that is based on discover. It would be much better to be based on a flag that any distro can tie in and not be locked to the discover as the flatpak appstore. For example ublue and some other distros are adopting bazaar for its flatpak only function and huge bump in speed, ease of use and simplicity.
if they find a solution that is appstore independent all the better.
Thanks of actually understanding what I am requesting. All I am asking is a simple badge on the restart/shutdown button. Not some convoluted change to the KDE ideology. What I have in mind is the ease of use for the user that is tech illiterate and only puts its computer to sleep. Also as I already said some distros are moving away from discover so the restart should not be something specific to Discover and neither some hack the maintainers did specific to their distro. Its something basic that the DE should provide to the distro devs as a tool to use at their own discretion.
I think all of Discoverâs backend can provide that information if they have the capability at all.
For image based updates that is likely the systemd-sysupdate backend.
It wouldnât necessarily be.
The information always needs to come from the system that knows the update state (PackageGit, Flatpak, Snap, etc.), Discover is just the primary frontend to them.
Thatâs why I wrote earlier that we are dealing with two different (yet related) things.
Aggregating the update state across software sources and displaying the state are currently in Discover. They could be in different processes (probably already the case, Discover main app and notifier are different programs)
Hence the suggestion to look at this separately.
The places in Plasma that can show logout/lock/restart/shutdown can be made capable of showing the need to restart.
The easiest data source would be to take the same state that Discover (notifier) already is capable of displaying.
If distributions want to use their own status aggregator they would just need to make it look like the original data source or modify a single location in Plasma to get the state however they want to
I found the phrase âon the shutdown restart buttonâ because I donât actually see one at all unless I navigate to it⌠so an additional notification (perhaps colouring the âshutdownâ or ârestartâ icons orange when they need using - to match the colour of a notification badge in the tray) could be a visual guide, but the tray icon and a pop-up notification should be more than enough.
I havenât used all desktops/distributions, but I certainly am notified prominently and given opportunities to reload individual items, or reboot, as required.
The warning is needed for people who updated but didnât yet reload⌠and who are continuing to use their machines; likely without a visible shutdown icon; so on the desktop is the place for it.
@krake In the current state of KDE what resource should I recommend to the universal blue devs to use for update pending notifications on their KDE images? With the knowledge that Discover was removed as of a month ago from the images and Bazaar is the only app manager because only flatpaks are supported by the user and those never need a system reboot. Whats left is rpm-ostree image updates.
You are free to directly reply with a recommendation ofc as you are far more knowledgeable than me:
If a true feature does not exist right now and you recommend I open a request ticket/issue on the KDE git I would be happy to.
Well, notifications can always be sent with things like notify-send
Apparently they do that already just only when the image is older than 30 days. Probably didnât consider earlier that image updates might contain security fixes. I would be surprised if they donât change that in case an update contains these.
Right.
GNOME Software and KDE Discover have both support for RPM OSTree, so this is mostly a need for image based distributions which have removed those two tools
Since they intend to automatically check for updates and downloads them when necessary without such a tool, their tool would ideally also be exposing the state for UI to query and display, e.g. via a D-Bus interface.
However it doesnât seem to have that (yet?) otherwise the GNOME shell extension linked from this comment wouldnât need to poll for it.
One option for the Plasma based spins would be to do the same but for Plasma.
Potentially sharing code for the data gathering and just having different UI portions.
Not as idea as getting the state information from the update process that already has it but something Bazzite/Kionite developers could work on without needing changes in the base distribution
Discover already does this, no? It worked for years for me on Fedora with offline updates enabled (which is the default), and now with KDE Linux, which is image-based, as of yesterday it works as well.
The Fedora based immutable distributions decided to remove Discover and GNOME Software so they no longer have any indication about updates.
On any other distribution Plasma could still offer the option of indicating ârestart into new imageâ (or for core system updates on non-image distributions) in places users might see lock/restart/shutdown options.
The status must already be somewhere for discover-notifier to show
Just to qualify what âFedora basedâ means here.
The immutable distributions actually published by the Fedora project (Kinoite is the Plasma-based one) still use the DEsâ own software stores. So Kinoite uses Discover for updates and users get update notifications that way.
The Universal Blue project publishes immutable images which are based on Fedoraâs, but this is an independent project that is not part of the Fedora projectâs governance. Itâs these images (Aurora, and the Plasma flavour of Bazzite) which are deprecating Discover - and thatâs whatâs driving the request in this thread.
Here is the Universal Blue website that list the images that are included under the project.
Plasma is used on Bazzite and Aurora. Bazzite is expanding much faster right now because of the gaming coverage that tech channels give it and its ready-to-game state right out of the install screen. Hence my request for implementing this QOL feature for the Ublue devs to utilize.
The coverage right now is driving a huge spike in people migrating from Windows to a Linux distro, and Bazzite has the most newcomers by far. Plasma is whatâs recommended for Windows users for obvious reasons. I know that for most users here this feature is simple and almost a non-issue, but many casual new users do not know that an update also means you have to restart, or that keeping the computer in sleep means staying on the same version.
As you said, Discover can be utilized for that feature, but I feel like having a way to integrate the requested feature into the Plasma UI, such as the start menu, the restart/shutdown options, or even the login screen, would be a huge QOL boost. Of course, a user could always turn it off in the settings, or the distro maintainers could disable the feature, as this would be transparent to the end user.
Edit: I really appreciate everyones input on the matter and if you have any more recommendations regarding the feature I would love to hear them!
also, for what itâs worth, when a kernel update comes thru and reboot is required, my discover icon in the system tray changes to the restart symbol so there is already a pretty clear visual indication when the reboot is required for that kind of update.
i think the grey area is when normal updates are applied but âoffline updatesâ is not selected, so you could be running on the older versions an not realize it or not understand why that bug it was supposed to fix, still keeps happening.
If you run Discover in âoffline updatesâ mode it could have downloaded packages that do normally not require restart but would need restart due to how this mode works.
Does anyone use Discover that way?
Does it show the restart icon regardless of what the most recent update contained?