-
Notifications
You must be signed in to change notification settings - Fork 1
2. Unsupported Operations
Some operations are unsupported & not recommended to do on Gidro-OS.
This page will note some of those down below.
While I would like this operation to be supported, currently it's not.
It requires the user to be aware of the change he made on top of the Gidro-OS, which is something I want to avoid.
It is more annoying that you have to constantly open those affected apps for notification/updating functionality, than to quit them whenever you don't need them.
This would get solved if upstream offered universal notification service which all apps would use & which Android devices have implemented. That way, apps are only running minimally enough to ping the notification service when needed & do not run fully, wasting resources, like now.
Why rpm-ostree install/remove or dnf install/remove doesn't work to install/remove some applications ?
Option for using rpm-ostree install, aka layering, & rpm-ostree (override) remove is disabled in Gidro-OS since 5.11.2024.
Option for using dnf for these purposes is disabled since 5.12.2024.
While there is a way to technically enable this feature, I won't provide the steps for it, because I believe it worsens the reliability & ruins the integrity of the OS image.
As a reference, bootc will land as a default image-update mechanism instead of rpm-ostree in the future, which doesn't provide the option of layering &/or removing packages at all.
As an user, it is advisable to install flatpaks as user applications, through Software application.
Another option as an image-maintainer, is to simply build the custom image using BlueBuild with all packages that you wanted to layer. This approach also allows you to remove any package from the system image that you can't remove in run-time.
You should not modify anything inside /etc/ folder & it's subfolders, as those modifications will override Gidro-OS changes & behavior. This operation is not supported & should be done only by advanced users, who can remember to revert the modifications they did manually to Gidro-OS defaults.
Take a note that you won't get support if you modified some stuff in /etc/ folder.
Ideally, this would be solved by requiring users to automatically reset /etc/ modifications done by them.
But that is not currently supported & upstream needs to jump in with the fix.
Modifying the default partition layout that is used in Gidro-OS/Fedora Silverblue is not supported.
Reason for this is that some issues can arise if some non-optimal partition layout is used.
Example of this is Chris Titus Tech's video on YouTube where he installed Bazzite custom image
with dirty $HOME partition on separate drive, which was also used by previous Linux distributions before.
This is not a recommended practice to do on any Linux distribution, as $HOME should be always clean when trying new image/distro.
What happened is that KDE broke because of dirty .cache folder, which contained incompatible older KDE cache for latest KDE version.
Link to the video:
https://youtu.be/lvUQVFE5lIU
If you have the habit, or you're been advised, to use chsh/lchsh to change the default shell, then don't.
chsh/lchsh is removed in Gidro-OS because of some serious issues it can cause.
For more details about this, see this blog.
Instead, it is advisable to change the default shell in Terminal itself.
That can be simply done by:
- Opening the Terminal
- Going to Preferences
- Profiles
- selecting the current profile (Untitled is the default, unless changed)
- Turn on "Use custom command"
- Type the path to the shell for the custom command
X11 session is not present since Fedora 41 got released (29.10.2024). Gidro-OS updated to Fedora 41 the same day.
Note that this doesn't mean that X11 applications are not supported (they are supported through XWayland), but just that X11 session option is dropped.
It is advisable to use the default Wayland session instead.
If you really want to use the X11 session, it is recommended to make a custom image with BlueBuild to achieve that.
This is because I locked some settings to prevent users changing the options which affect system reliability.
I also locked some settings because they are already offered by something else, to avoid duplicate functionality:
-
Universal Blue auto-updater service instead of Gnome Software flatpak + system auto-updater
Having 2 auto-updaters at the same time is making the system less reliable.
Gnome Software also works better without own auto-updater, because it doesn't constantly refresh metadata & page whenever you want to do anything.
Some minor page refresh is still happening after flatpak app is installed or uninstalled, but it's much better compared to the original behavior. -
Warehouse "Manage Remotes" instead of Gnome Software "Software Repositories"
Makes Gnome Software strictly app-store focused, while Warehouse is intended for general flatpak customization.
Other locked settings:
-
Gnome Software remote preference
I don't want users to mess with this, as it would greatly affect system reliability. -
Keyboard XKB options
To prevent users modifying CapsLock modifier, which is needed to partially fix caps-lock delay. -
GTK themes
They are known as unsupported + unreliable in Gnome & they are very easy to break through updates. -
Icon themes
They are more reliable, but I am still cautious with them.
The only icon theme I trust is MoreWaita icon theme, which is based on the original Adwaita theme, which I ship by default. -
Mouse middle-click paste for GTK apps
I don't see a reason to ever enable this under any scenario. -
Remove old trash files
I don't want this option disabled ever for storage + privacy reasons & there is no way to lock "Disable" option only. -
Mutter check alive timeout
This is the option which extends "Not responding" dialog to 20s.
I don't want users messing with this option, potentially loosing fix for Valve games frozen loading screen.
Here's the dconf file which contains all those locked settings: