Yes I also thought about a “the flathub appstore” as GNOME software was a bit better but still didnt contain all infos from the website.
But I dont get why not update that interface a bit? Were there issues with the GNOME devs? I see GNOME ditching old apps and using entire rewrites (like Papers, Text editor, Loupe, that video player).
But if it is Flatpak-only, that will never happen. So while it may be cool, it only makes sense for SteamOS or something where you really have no other way of installing software (and even there that isnt true, is it?)
Or is the idea to add more sources in the future? I dont think there ever was a problem having “the flatpak appstore”. Getting all info, yes. So adding a few more changes do Software and Discover.
NixOS
For my use NixOS is way easier. I build my system with a directory tree of configs, thats it. I can write random config files using nix, or use builtin options. I dont understand the system and its details, but the rebuild process warns you about all issues and you get them fixed.
Whenever I tried to build my own images, I had build failures without an error code, so I kinda gave up. Otherwise I would probably have made my own image, LTS kernel, the changes I want, and called it a day.
So no, nix is also very understandable, but more like programming.
Yes I think so too? Maybe they persist with blue-build? Having them as kinda unopinionated bases for other images sounds nice?
Of course reducing scope to a few opinionated products with shared configs is way easier. Taking care of images not meant for shipping? But I thought that this was the big cloud native advantage.
Agreed. I tried GNOME.
switched to dash-to-panel to get more screen real estate.
Added a clipboard manager as weirdly that is not included.
Decided to go with community dropdown-menu-addons instead of app indicators, which only works as GNOME is so popular.
had my screen at 100% scaling and scaled the fonts and all apps, to reduce these absurdly thick bars.
…
Then it works, otherwise no way. What works, works really well. But a ton is missing.
Using Kvantum to make KDE apps work, interesting. That is pretty custom though, and not native anymore.
From what I can gather, apps are being retired because they lost their maintainers, or the efforts to refactor to the latest GUI toolkit are too important.
Like any software, GUI toolkit are continually being developped, and every so often, there’s a big rewrite, and the old version stops being maintained. Which forces the apps that use that toolkit to be rewritten! Which may be a really big deal if the app was not written with software engineering practices and techniques that serve to mitigate those efforts and whose goals are to make maintenance and evolution easier.
Open Source software made by people in their spare time might not always follow those practices. (And that’s OK. Those practices take time to learn.) Which means that’s it a lot harder to make the code evolve over time.
So some apps are getting abandoned, and must be replaced with other apps that are written with the new GUI toolkit.
So, why not work with GNOME devs on the software app? Because that may be really difficult to do, because GNOME Software and KDE Discover are made to interface with lots of different packages managers (apt, rpm, pacman, flatpak, snap…). Those engineering practices I spoke about had to be used in this case, to be so flexible, but that means it’s a lot harder to optimize loading speed for one of the package managers it supports.
It could take a lot of time, and the devs may have other priorities. (And then there’s real life.)
But that’s the beauty of Open Source: someone always steps up to fill a need.
For me, it’s the opposite. The GitHub Actions build log is pretty clear in what it says, and the format of the yaml recipe is pretty clear as to what I supposed to do.
I use the older format, that’s since become blue-build. It’s been pretty easy for me. As for kernel, I think that’s more of an issue with Fedora since that’s not really a thing in Fedora. You can define your own kernels in blue-build, but it doesn’t seem to have LTS. The closest thing you could do is probably using COPR to add your own kernel - idk what that would do to the rest of the build process, but theoretically it should be possible since Bazzite has its own kernel and all.
It is still the default in many distro. Many Ubuntu-based and Arch-based derivatives I tried uses it. Not quite default and built in, yeah, which is why Kirigami is being pushed.
The main feature of Bazaar is for us is it doesn’t support rpm-ostree package layering, doesn’t try to install themes that arbitrarily add files to /usr, and doesn’t know what an RPM, DEB, or otherwise are.
Being a flatpak-first and flatpak-only store means it can be the premier place for Flatpaks, which beside from Brew and Containers are the only thing we care to show an end user.
Also (see my API section above), I actually don’t care how many flatpak stores there are.
In cloud native we care that there’s a documented way for apps to interact with flathub. Make as many as you want for all we care, every toolkit, make one with charm.sh, make one with Qt, etc. We don’t consider that wasted effort that’s exercising an open API and that’s what’s actually important to us.
The users will decide. And I don’t mean by arguing on wether it’s good or bad, we’ll see when we look at Flathub’s usage statistics over time.
When using an app that is either GTK or QT on a system primarily designed for the other library, particularly on a standard non-uBlue distribution like Mint or Debian, various issues can arise, whether they stem from dependencies or general integration with the desktop environment.
However, with uBlue, these problems are eliminated since everything is containerized. It doesn’t matter if the application is GTK or QT; it will function properly, and visual glitches should also be resolved in this manner, as the app is required to comply with Flatpak technology and integration. I find this completely acceptable, although I get the aesthetics purism dilemma.
If someone installs uBlue in January 2025 with certain applications, and by December 2025 the developers opt to change some of those apps, this will only impact future fresh installations, correct? Therefore, the concern raised by the person who started this thread seems to be directed at those creating their own custom images? (If I understand correctly, this appears to be more of a niche issue?)
There are numerous technical details here that I don’t fully grasp. However, one thing I am certain of is that you all are overlooking a crucial element in this entire mission. In my view, nothing remarkable or impressive is likely to occur for uBlue or Linux as a whole unless people come together for arguably the most vital aspect concerning hardware and system usage: battery life.
Why would anyone choose to use Linux if all distributions, spin-offs, etc., only provide a session battery life of 1 hour and 30 minutes? With TLP, maybe 2 hours. Why is that? MacOS outperforms everything in this regard. Even Windows can extend battery life to about 3 hours.
And I am referring to the standard laptops that people typically purchase in the $300-$700 range, which usually come equipped with batteries that have at most 3 cells with 40-50 wattage.
Most individuals have never heard of Framework, and likely never will. I apologize, but that’s just the reality, and the same goes for Tuxedo, System 76, and others.
I am currently using a desktop PC and Aurora, so battery is not a thing for me. However, the target audience cannot solely be grandmothers at home with old laptops that can remain charged around the clock since they never leave their homes.
I think that the adoption of Linux and FOSS applications is currently more prevalent among government entities than among everyday users (for instance, Denmark’s transition to LibreOffice, etc.). These organizations typically utilize PCs or desktop computers, while the average user often has a laptop or sometimes both.
I hope I have not offended anyone here; I enjoy being part of this community and I just wanted to add my fair share of thoughts. Nevertheless, the laptop battery experience on Linux is just terrible, completely unacceptable, trash.
Beating a dead horse, but monoliths - whether they exist as conglomerate businesses or sprawling application toolkits trying to provide every app - are unlikely to provide the best experience. There is no way either GTK or KDE are going to provide the best every app for all the things they’re trying to do, and I for one will always embrace the best-in-class tool.
At this point most of the apps I use are based on their own application toolkits or Electron: browser (Firefox, Chrome are customish), VSCode (Electron), Discord (Electron), Wezterm (custom), DBeaver (Eclipse), and so on.
Yeah, GTK and KDE will both ship their own calculator app and other basic utilities like File Explorer, and in those cases it makes sense to ship those apps. I wouldn’t be all that surprised if I was running a File Manager which wasn’t created by either GTK or KDE frameworks in 10 years btw.
One cool thing that KDE has got going for it is that its apps tend to be easier to run on Windows. I can tell people to scoop install extras/dolphin (or winget install -e --id KDE.Dolphin) on Windows so that they can comfortable earlier with differences and run both operating systems a bit more similarly. I ran KDE Connect for a while on Windows altho is was a bit finicky.
All that said, keeping the desktop minimal is ideal for people like me. Give people an onboarding flow to install all the stuff.
For example, I am trying ptyxis but ultimately thinking I’ll stick to wezterm for example, so considering building my own image to rip out ptyxis eventually. But I’d really rather not have to do that. I guess there are reasons why some apps need to be baked in and also sounds like the base may slim down as progress happens. This is similar to the Ubuntu direction altho not sure where that landed Ubuntu Plans to Ditch its 'Minimal' Install Option - OMG! Ubuntu
No, the root of my concern is that there is A LOT of deprecation and changes lately.
I use ublue-os as a whole because I was annoyed by Arch-based breaking so much in 2023 (glibc, libcrypto-3, grub). In the first place, I switched from Windows because I don’t want to be bothered - I want to setup my system once, and then keep using it, without things randomly breaking and/or requiring manual intervention from me. The ublue-os Mission page stating that the project is somewhat “maintenance mode” and focused on contributing to upstream actually appealed to me in this case.
Now, at the same time, there is a push for yet another new GUI app store. One that is just around a month old, which is very young for a FOSS project (and we’ve seen how even forks just dies pretty quickly in weeks) yet is pushed as “the solution to getting apps and getting paid for users and developers”. It is also announced on General thread and there is a video where it is running on Bazzite.
How am I to trust that this isn’t another Bluefin LTS? It is, seemingly, a ublue-os wide move so I can’t just ignore it as “Bluefin doing Bluefin experiments, and I’ll get it once it matures.” No, it’s significant effort put into an experimental thing, that will become part of ublue-os, that is done - due to the timing of it - seemingly at the expense of other things that has been there for ages.
I’m not going to stay silent until I’m affected. I have my concerns and doubt towards ublue-os suitability for me. Legitimately, between this and Xbox Ally announcement, I have thoughts about just moving back to Windows when they release Xbox mode. Or just installing SteamOS so that I’m not bothered by what’s going on in the ublue upstream.
I just want clarity of what will and will not be supported going forward. This wave of deprecations, new experiments, more deprecations, and then not communicating clearly what I need to do and be aware of reminds me of how I dropped Manjaro because the maintainers did something similar with regards to Mesa h264 codecs.
I’m fine with doing some maintenance on my stuff - I’m not fine if it’s not clear what is actually going on and how much I can trust anything new or old in the project. I’m fine with deprecation, but I hate feeling like my early buy-in into ublue-os ecosystem is possibly being left behind.
Battery life is more an issue with manufacturer driver and hardware. The only way it could be fixed, properly, if Linux adoption gets enough driver and hardware. Which is something I can get behind, and major driver for why I had come to tolerate and push for Bazaar - because I thought it was going to solve getting apps on all distro and Linux as a whole.
Getting apps is part of the larger issue in getting more users on Linux; not everyone is PewDiePie who is willing to learn, a lot of people are Linus from LTT who barely does any research who just want their workflow to work, and will blame Linux if something breaks.
This is why I’m in favor of an official Flathub GUI that supersedes whatever weird thing other distro does with their GUI software package manager. A lot of people are going to complain, but if Linux gets to the point that developers has to account for it because Linux gets polished to the EU, Chinese, or just vendor can use it because they don’t want to pay and beholden to Microsoft – then it’ll be all worth it.
To a degree - a lot of functions I expect from my DE, that’s standard because it is part of the server side decorations, are just broken on new Gtk apps. Things like right click menu being much more limited than KDE’s native one. Global Menu, Menu icon on titlebar, and menubar as a whole is gone. It barely follows my window button setting - but no support for keep on top and pin to all desktop button. Custom actions on the titlebar is gone, I can’t just scroll on the titlebar to move an app between desktop, nor can I middle click to shade the app. Headerbar is undismissable, I prefer to have titlebar disappear when I maximized the window.
It is fine for the normal app function, but new Gtk comes into my environment and override what I can and cannot do with apps’ window, that otherwise functions correctly on any other toolkit (like Gtk3). I’ve gotten to the point where I would choose electron app over libadwaita, and I cheered when I heard Bottles getting remade to potentially use electron to support macOS as well (I think they choose something else, but I don’t care, as long as it isn’t Gtk4 and libadwaita).
Again, I’ll underline that I can tolerate it. But it’s tolerance that comes from tiredness and powerlessness, not happyness.
@fenglengshun I do feel with you that things move fast. However, I don’t understand why you feel a push and worried about the GUI? Even though there is a proposal being worked on to change the GUI, the backend (fedora + flathub + brew) stays the same, so that all our automation and customization in user land remain.
Who is going to make an official flathub GUI? Who will maintain it?
I feel that the discussion on UI toolkits and libraries doesn’t help here.
For now, nothing has changed yet: the default is still Software center and the Bazaar developments are deployed next to it in the Fedora 42 images only. If things move too fast to your liking, then the install guides tell us to stay on GTS (Fedora 41 based).
I also thought in the beginning: why does @j0rge throw a broken app into my stable install?
Now I must admit that @j0rge did a great job in explaining his vision forward here on the forums, including some awesome videos. I realized that Stable means it’s the enthusiast channel and it comes with some community engagement. I’m impressed by the way @j0rge is building a community and gets things done.
What’s the worst thing that could happen? Maybe some experiments won’t last long and others do. Then let’s enjoy it. Rolling back should always be possible. And if something doesn’t work well, then GTS-ers won’t even notice.
Apologies if I don’t understand your message well. Let’s try to move forward with concrete and actionable feedback (for example, as in the call for testing forum). Some people have shared some detailed experiences and reported rough edges. Even if we are not developing apps ourselves, testing is an effort where the community can help moving forward.
Okay, I’m going to make this very simple. There is a lot of things deprecated. There was an effort to try for Bluefin LTS that didn’t pan out, and then deprecated. We now have another new thing that is pushed. Will that be deprecated as well? Will something else be deprecated in exchange? What can I trust will be there and what can I look forward to in exchange for the changes that I don’t like that I will have to just accept and deal with?
There is no GTS in Bazzite. If there was, I’d be using it.
Our main interest are the end-images, so Aurora, Bluefin and bazzite. These are the ones we consume and others do too. There is no depraction for these.
So i just think people are thinking this way too hard. The -main image deprecation doesn’t really affect our end “product” which are the end images mentioned. Some people run the base main images and that is fine, but there were a lot of them that were like not used at all. I don’t think there is really a point keep building them if they are not actually used on the end images.
We still have the base main images that are used for aurora/bluefin/bazzite. Those weren’t any part of the deprecation.
Bluefin LTS users account for less than .1k of weekly active systems and continues to be in Beta. I use it everyday.
We do not make Bazaar, we are integrating Bazaar. The person working on Bazaar does not have an impact of what the rest of the team is doing. Supporting Bazaar doesn’t cost us much and it helps the Flathub ecosystem by providing users and contributors who want to help. Due to our efforts people have started to show up to help.
For custom image people the base image deprecation looks like this:
Before
FROM ghcr.io/ublue-os/silverblue-cosmic
RUN dnf install -y my favorite packages
After
FROM ghcr.io/ublue-os/base-main
RUN dnf install -y @cosmic-desktop @cosmic-desktop-apps
RUN dnf install -y my favorite packages
uCore was a main end-user image as well. It’s great that it’s continued, but if it hadn’t, then I wouldn’t have know what I’d do if I had done my plan to swap my Ubuntu LTS device to uCore. But, ultimately, stuff happens. The issue is none of it is communicated until it happens.
As far as I, who doesn’t really go to the Discord, is concerend things just randomly get deprecated. And then another. Other major changes also happened as well, affecting me. Then a random new project was picked up, shown it off like it is the next best thing since Proton, all after a different experiment was shut off. It’s just one thing after another, every other week. And I’m supposed to not be concerned?
Sure, today the thing I use are still mostly there. I just have to change some of my setup, but I can figure it out. But can I trust that next time I wake up, more things won’t be deprecated or at least changed? Frankly, no. Whatever “maintenance mode” is mentioned in ublue mission doesn’t mean what I think it means, and I don’t know if in the long term ublue-os will remain reliable. I don’t even know if ublue-os as a whole is an area for experiments and playground or something stable I can just use and forget most of the time, with the conflicting messaging.
This is why I asked about a roadmap before. It’s not necessarily about when is the next thing coming out. It can be a simple list if what exactly are going to be deprecated and when, what is going to have an upgrade and when (which means it’s continuing for at least that time), when should current efforts start to bear fruit which meant it isn’t just an aimless effort but one with clear goals and commitment.
I’m not asking for Fedora tier change proposals. I just need proper assurance that isn’t just a nebulous “this will stay,” as if that wasn’t implied about a lot of things before they’re suddenly discontinued.
But honestly? It’s whatever man. I really don’t care anymore. Do whatever you guys will, it’s your project, I don’t really have a say in it.
I think this simple sentence encapsulates about everything you ever said in this thread.
It’s a valid thing to value stability of experience, Ublue does not seem to match your needs on that front, and it’s ok for you to find a project that will match them more closely.
If you want to stay on an image based system closer to stock KDE, I have heard OpenSuse Kalpa is quite good.
The only thing I see… maybe, just maybe “Stable” is not the best name for fast moving channel intended for enthusiast. Debian has “stable” for extra “hard” stable. Maybe Stable channel should be named Fresh, like LibreOffice name for latest release.
Also GTS is some unusual name. Probably ESR (extended support release) like Firefox has would be better name.
No need to invent new names or invent new meanings for established names… because there are already good established names out there in other projects and working well.
But in the meantime we have plenty to do!