Can you share any study for this. If this is true, it is fascinating and worth looking into in more depth

That same logic could be applied for the save and discard button. Should there be a bigger gap between them lest somebody misclick and discard things instead of saving them¿? Atleast in the case where they accidentally click cancel instead of discard, they are not losing any data.

Hell if this really about data safety, discard/don’t save should be the isolated button because it is the only destructive option

Here’s the thing: Apple’s design you’ll find that they carefully included an extra margin between the “Don’t Save” and “Cancel” buttons. This avoid accidental clicks on the wrong button so that people don’t lose their work when they just want to click “Cancel”.

And gnome has those dialogs in a different colour to achieve easily noticable differentiation between the two options

Well for Firefox, the one getting updated is the native rpm version which is part of the standard Silverblue install while the one already updated is the flatpak version. The native version is just called ‘Firefox’ while the one from flatpak is called ‘Firefox Web Browser’ if I remember correctly. I have no idea why signal is showing up there. Maybe it is a bug.

Also next time a system update is shown in GNOME software, check using rpm-ostree status to see if any updated image is staged. If yes, then you don’t have to bother with gnome software - when you shutdown or reboot, the update will automatically be applied.

I think evince will be eventually dropped by GNOME but there is time for that. While papers is porting things to GTK4 and adding some great features, it still has a long way to go in performance and optimisation. Currently it is more than twice as slow to open a pdf when compared to evince. Also scrolling performance is not optimised as it will stop mid scroll for things to render. Well it is only a new project so hopefully all this will be fixed. I am still using papers so that I can report any bugs that I run into

I love this comment because it explains the keywords in the command. Hats off to you.

I don’t know if that would be possible with SoCs. I think if you were able to create a design where the whole SoC was upgraded, that would be more likely to exist.

Doesn’t help that the date based release looks a lot like semantic versioning which a confusing a lot of people. Should’ve just used Ubuntu’s standard of ‘yy.mm’ instead of ‘yy.m’

Well I think it should be a single 0 because Ubuntu’s naming has now established the standard that if the second part of the name suggests month, it is written using two numbers eg 23.10, 24.04, etc. 10 is used for October and 04 is used for April.

They aren’t using semantic numbering though. They using ‘yy.m.patch’ instead of ‘yy.mm.patch’ as the scheme so it looks like semantic without being semantic which is causing all the confusion. The next release is shown as 24.8

Yeah you are right. For some reason I thought I had seen 24.1 but i was mistaken. Stupid naming scheme this since 24.2 and 24.8 sound like v2 and v8 of the 24.x release. Should have just used 24.mm just like the rest of the foss world does and as you suggested it should be

Wait doesn’t ublue have the gnome apps installed as flatpaks¿? I have always rebased silverblue to ublue because I have had trouble with the ublue installer - some efi issues in grub

I don’t think it is based on the release month

If you want a stock gnome experience from the ublue image (like the one you get from silverblue), look for the ublue-main image

Thanks I will try it then

Thanks I will look into it.

I am on a immutable version of fedora(ublue-main) to be precise. Will the appimages work normally¿? I haven’t tried running an appimage since moving to using immutable distros

Sorry I should have mentioned that this is the integrated screen of a laptop

I am on ublue which is immutable. Do appimages work normally on immutable distros¿?

TW also has the issue of having ‘controversial’ software like the media codecs, etc not being included OOTB due to licensing concerns.