I agree that it’s confusing which is why we recommend Bluefin GTS on the website, and it’s the only option on there.
You only need to care about Aurora if you know you want KDE.
Monthly updates won’t work, it needs to be more often than that for security updates, but users don’t see that anyway, which is why it’s automated.
Maybe users don’t see, but they do feel frequent updates, especially such massive updates.
In fact, I notice laptop slows down during the update. When I receive monthly system updates, it’s still manageable (even massive one).
When it comes to application updates, should be as less intensive as possible, ideally weekly.
In many countries and corporate environments, internet is not that fast, that’s where EOS, LTSC come into play. ublue should consider such cases.
Yes this is exactly why we moved to weekly updates instead of daily updates, and why we’re investigating zstd:chunked images so we can use them as soon as we can.
I personally like the daily updates, in fact I am sometimes manually checking for updates when I know there’s an update for KDE, Nvidia, etc. that was released and I want to get it as soon as possible.
If bandwidth is an issue then go with a gts version that won’t pull as many updates, or perhaps changing your update interval then manually checking when the bandwidth is better. Fedora/immutable OSs are known for using alot of bandwidth.
Ehm so you happen to use the pc always at the time when the update cycle runs? But wouldn’t notice it if it runs once a month and would be like 10 times bigger?
I really don’t see a failing cycle. As j0rge has pointed out, there are defaults. By giving people more options you attract a larger audience because you can serve more people with different needs.
We are investigating using the fsync kernel in order to drop our hwe images.
That said, we basically have this matrix.
Bluefin/Aurora
Bluefin-dx/Aurora-dx
Bluefin/Aurora + nvidia
Bluefin-dx/Aurora-dx + nvidia
The Nvidia drivers add a bit to the image size and have significantly larger initramfs. Since you only need the Nvidia driver if you have an Nvidia card we have that separate image.
We then build our:
GTS which is on Fedora -1 w/ slower updating kernel
Stable which is on Fedora +0 w/ slower updating kernel
Latest which is on Fedora +0 w/ distro kernel.
For those who want something to move faster, there is nothing stopping you from forking our repo and just making the workflow run more often. Weekly updates for stable and GTS is a good pace for making sure security updates are reaching updates in a timely manner and feature updates aren’t being held back too long. Additionally, we can always do an out of cycle update as well if needed. Latest is building daily and being rebuilt on every merge. Sometimes, there is kernel drift or we need to change packaging in our upstream images but generally speaking things build pretty consistently.
For nvidia we noticed that the repo changed the package names which affected builds.
@j0rge @m2Giles guys act brave and move GTS to monthly system and weekly app updates. Enthusiasts have Stable and Latest branches.
Gts is already one version behind of Fedora latest
What would it help to provide updates once a month?
The default channel is already GTS (former still supported version of Fedora), and Fedora is considered to be a fairly stable distribution
Bluefin and Aurora GTS are rock-stable in my opinion
Update size will dramatically be reduced in a few months
See
See
We should act brave and move GTS to monthly system and weekly app updates. Enthusiasts have Stable and Latest branches.
Furthermore, not exactly Bluefin issue, but no Windows-type Fractional Scaling makes Bluefin completely unusable on non-framework laptops (which are extremely expensive).
You can also read my previous feedback:
Why would it be brave and what would it bring ?
That’s off-topic, but still a valuable feedback
I’m also not sure to have understood your paragraph
Fractional Scaling comes down to Large Text in Bluefin, which slows down the performance. I read Framework laptops have fractional scaling sorted out, but these laptops are very expensive.
Windows does fractional scaling the best right now. We need the same in Bluefin.
I still don’t get which problems slowing updates down would solve
About fractional scaling, that’s off-topic but it would be a good idea to publish a new post about it
Maybe you also happen to know where the error comes from, it’s a GNOME problem specifically, or how does the framework laptop got that solved already
Fractional scaling doesnt really have to do with Framework laptops. You (might) need fractional scaling with a high dpi screen (depending the resolution and your eyes etc).
Kde i think already has a native fractional scaling support and it works fine. Bluefin/gnome has merge request (guess it comes with gnome 47) and the patches should already be in Bluefin.
Is it on-par with windows, i dont know as i havent really used fractional scaling, i dont need it for ultrawide or my current 1080p laptop screen.
Please kindly stay on-topic 