“You can’t get there from here” - - - - (saying I heard in Maine)
Today I updated a Bluefin system for the first time since August – 71 layers of updates. The NVMe drive survived when the user hurled their laptop at the floor back in August, when they were in a hurry to download a document from WhatsApp web, fill it out in OnlyOffice, and send it back. What on non-flatpak systems just works – downloading a document from WhatsApp web – was impossible, as the download just went… nowhere? From whatever dedicated flatpak, and from the Brave Browser flatpak.
Oh, well, I thought back in August when trying to assist the user through that hurried moment, we’ll workaround by using the person’s phone to share the file from WhatsApp to Nextcloud, and then access it on the laptop through Nextcloud. Honestly, I don’t remember if I tried that and it also failed for some flatpak-is-protecting-me reason, or if the laptop got smashed before I got a chance to try.
I really like the Universal Blue thesis, of making a long-term-stable GNU/Linux distro that builds on useful stuff from cloud computing. I like to artwork, I like the distrobox integration, and the fine touches. But flatpak hell and a hot temper cost my user $600, and has given me a few headaches.
And wow is it slow sometimes! I’ve run it on 7th and 8th gen i5 CPUs with 24 to 32 GB RAM and NVMe drives, where other GNU/Linux distros don’t take multiple seconds to open a system monitor app. I assume this is just because favorite apps were picked by the Bluefin team, and they’re relatively new apps and haven’t been polished over time to be more efficient, and also… Flatpak maybe? Or is it Fedora? Or immutable OS? Or Gnome? I think it’s something about Bluefin.
To be fair, of course, the way a flatpak is configured is (AFAIK) not influenced by the distro, but 100% determined by the packager. Still, my experience on PopOS with flatpaks hasn’t been quite so rough, though it hasn’t been smooth either.
So, I don’t expect the updated system to be any more usable in terms of avoiding flatpak hell – I’m using it now to write this post, but I haven’t tested WhatsApp web or Signal or any other messaging apps or the web browser for file downloading, so there’s a chance I’m in for a pleasant surprise. Given that this frustration can come from any system that uses flatpaks, and is magnified on a system that depends heavily on flatpaks, I think it’s an area that deserves serious attention in the Universal Blue project, and could be a key step in achieving the usability vision of the project.
Also, after the update today, the desktop artwork of Bluefin disappeared, replaced by a plain blue-ish desktop.
Thanks for all the great parts, and here’s hoping that attention will be given to escaping flatpak hell and giving users a system that lets them get their work done.
If I could tweak this system so that the user can actually get work done on it (now that the drive is in a new laptop), that would save me some time from choosing, installing and configuring a new distro. I’m open to suggestions, as long as they respect the user’s workflow of sharing files over WhatsApp and editing them locally.
Blufin always updates in layers. By default Blufin tries to update ones per day for system packages, but usually once per week new system updates arrives. Blufin tries to update flatpak twice per day and installs them silently in the background. You can check if auto-update is turned on with command: ujust toggle-updates
This is not a fault of flatpaks or even less Blufin, this is a fault of packaging software in the wrong way or software does not uses portals.
In mobile app word Apple and Google prescribed rules how software must be packaged and application MUST package software according to the rueles or software will just not work or publishing will get rejected it in the first place.
But… in Linux word the first alfa master way of installing software is using system packages (dnf, apt,…) and most of software is tested via this system packages, but a lot of software is just not tested well using flatpaks. Flatpaks gives some sandboxing feature and may restrict the way software is used (remember the same way as on mobile application) and in a lot of way application developers just say this is flatpack issue, but it is in majority of cases the application problem. Now… multiplatform software that packages software for Windows, macOS and Linux… Linux has way the smallest market share and inside this small market share is even much smaller flatpak market share. A lot of packagers do not bother fixing flatpak related application problems… because of an argument, user can always install software from package manager.
I don’t use Brave web browser, but in my humble opinion most probably browser just automatically saves file to some location. Location can probably be retrieved from browser settings (I just did humble assumption how Firefox web browser does using flatpak system). You should most probably ask on Brave forum to get answers to specific questions.
It is difficult to suggest anything, because of too general language. But as I have written above, not a flatpak issue, blame the package manager of not well written application. It also can be, that you don’t understand some specifics about this software and it actually works just fine. I don’t know, general statement, general response.
On what Blufin channel are you in? Please post output of sudo bootc status.
I have been using flatpaks for many years, and the problems have always been strictly to how badly software is packaged or not tested or not using proper components that works fine in flatpak (e.g. portals). Don’t blame the road, if you car is a mess.
Now we see where is the issue: “…hot temper cost my user $600”. Don’t give sharp objects to children.
I hope you compare the same programs, same version of programs and same packaging etc. Flatpak programs may start little bit slower… but should not be a major issue. I run Blufin in virtual machine and application startup is not instant, but not terrible slow. Some of this may be blame for bloated software that loads plenty of libraries at startup instead of loading them in background.
Another general statement. What apps you see issues with?
Now we are getting somewhere…
Another general statement… Do you have some measurements of specific applications and actions you measured? I have been using several Linux distributions and I don’t see some flatpaks running slower on one distro vs. another.
Try and measure… is proper way of finding out the truth.
That was my assumption above.
This can also be true. More badly packaged software you use, more likely you get into frustration.
I think you have too big expectations. Universal Blue if repackaging platform and not fixing issues in flatpaks. Issues in flatpak must be fixed at flatpak level. Will there be soon fixed, probably not - we are waiting for Year of Linux for 20+ years, until Linux get bigger market share I am not super optimistic. But that is how the world of Linux is. Something does not work, do some testing, go upstream, report bug or even better provide a software fix. I know a lot of users are not used to this and even don’t want to go this route, but don’t expect major improvements without major involvement.
Obviously you are disappointed using flatpaks… but you don’t have to, if you don’t want them.
There are several other option you can install software in Blufin like using “distrobox” containers (the proper way). I suggest to read my post on how to install any application using GUI tool BoxBuddy.
You can also install software in Blufin using layering: rpm-ostree install <package>
This is not really recommended way. Why? Because you actually lose separation between operating system environment and end-user applications. Mixing both together and you get any other classical (mutable) Linux distro.
By the way, if you were so pleased with PopOS, maybe that Linux distro is more appropriate for you type of usage. Think of it, try to reduce frustration in your live by using things that reduces frustration.
Hard to actually say what the actual issue is, but for example browser flatpaks just generally work and they can save files to “wherever you want”. For example, I use the Zen Browser flatpak as my browser and if I click something to download it pops the normal Firefox download popup where I can either just save the file and it goes to ~/Downloads or try to open it with app X (depending on the file).
Not sure how Whatsapp web works inside a flatpak browser but it shouldn’t cause any issues (personally I use Beeper or Matrix client with matrix to whatsapp bridge to connect to whatsapp) sending files.
In general flatpaks will never go away in Atomic distros as they are pretty much an integral part of the system.
Universal Blue has shown its ability, as a community, to come up with novel creations that make people’s lives easier. How could this same ethos and creativity be applied to making Flatpak system integration smoother, in ways no one has seen yet?
Maybe I wasn’t clear about my purpose of sharing this story. I don’t expect Bluefin to take responsibility for any apps installed. I don’t expect Flatpaks to go away, since they’re pretty useful in many ways. I didn’t give specific details because A) they’d probably be out of date by now, and B) the details aren’t the point.
I got the impression (maybe from Bluefin materials) that Bluefin aims to be a useful desktop for everyday people, not just people who like running their computer as an experiment. I thought the idea was to make something solid, stable, usable for everyday people. If that is indeed a goal, then we can assume that everyday people will install software that Bluefin hasn’t packaged. I’m not going to ask non-technical people to look at Flatseal – I looked at it myself, tinkered with it, and none of the settings fixed the situation, and I have almost 20 years of Linux experience.
My purpose in sharing the story is that for non-technical users, and even semi-technical users that might support them, maybe Bluefin could check Flatpak settings, and offer suggestions to users somehow. For apps that are often used for file sharing, it would make sense for the app to have adequate permissions. Some sort of assistance in this would set Bluefin apart from other distros, plus the solution could be adopted by other distros if desired.
I hesitate to offer any concrete ideas, just because of my ignorance about Flatpaks, but… Is there a way the system could detect an intent to save a file that did not result in the file being saved in the ~ directory? There are probably a dozen other ways to make Flatpak system integration better, ranging from documentation, to a helper app, to some sort of automated check on Flathub between app purpose and app configuration… Universal Blue has made kernel contributions, so making some sort of contribution to improving the Flathub / Flatpak system seems totally within bounds.
Yes, I too thought the person smashing their computer was not a mature response to the situation. And, for non-technical folks, computers are like mysterious black boxes that they are forced to deal with in order to participate in society, and I can empathize a bit with the sense of powerlessness that arises when over and over the computer doesn’t work and it gets in the way of participating in society and moving forward with life goals. People respond to that in many ways, and while smashing the computer on the floor didn’t resolve the flatpak-is-protecting-me-wrong issue, it was effective at expressing the sense of powerlessness and rage. And that non-technical user has been on various Linux distros for about 10 years, and always had a hot temper, but never reached that level of system malfunction before. I’m just saying, there’s some user story here worth listening to, beyond judging their temper.
That’s a fair point. The challenge arose because it appeared to work, and then in practice we found a bump in the road.
There are various Flatpaks that offer WhatsApp web as a standalone app. In this case, ZapZap was the chosen one. The developer has released some major updates since August, so maybe it’s working better.
Again, I’m not really focused on the details, because difficulties related to Flatpak isolation seem pretty common, based on forums here and elsewhere. It’s not just a matter of “Is the app I need available on Flathub” but rather “Is the app available and does it behave as expected” which requires testing instead of just seeing if it’s there. Maybe some sort of testing could be done in the Flatpak packaging pipeline, and included as a data point on Flathub and the app store. Yes, I know there are already various data points shown in the app store. I mean something different, and I don’t know exactly what.
Yeah it’s a matter of getting people to contribute in flatpak/flathub, but fundamentally it’s a matter of getting app developers to care about their apps.
I’m not going to ask non-technical people to look at Flatseal
Nor me, most people will just use their web browser, that’s how I use whatsapp.
Bluefin could check Flatpak settings, and offer suggestions to users somehow.
We would end up being a repository of workarounds and it would be terrible to maintain. Might be worth investigating the whatsapp flatpak github repo and see if there’s anything that can be contributed.
Some sort of assistance in this would set Bluefin apart from other distros, plus the solution could be adopted by other distros if desired.
This is related to my comments above, we’re not a distribution, the entire point is to move away from distribution specific tweaks and get people looking at flathub instead. All the stuff in your post is doable and good ideas, it just needs to be done at the flatpak/flathub layer and not the OS.
Personally, if I don’t want to mess around with Flatpak or Distrobox, I just use Nixpkgs (via Home-Manager) or Conty. Or AppImages, that works too, but I don’t like it so-
This has been an issue with Steam Flatpak for a long while. For me, I default to Flatpak, but if I can’t then I go checklist of Flatpak, then Distrobox, then Conty, then Nix (might try Brew at some point), and then I layered them into my image via the image builder if I really need it.
On the xdg-desktop-portals, most likely. Honestly, if @plibre is so annoyed by this, then the best way is to just go there directly, take a look at the current PRs, and offer inputs/testing because a lot of things are being worked on, it’s just progressing veeeery slowly right now (still waiting for WebExtensions/NetworkHostMessaging portal here).
…well, okay, the actual best way is to go and meet the devs involved with the PR and reviewing in person, because it seems what gets things to progress the most are actual offline meetups. The perils of being a community driven FOSS project, instead of a company that needs to just ship, I guess.
I use regular Fedora, not a uBlue OS (yet). But I try to use Flatpaks where I can, and Zapzap works well for me as a WhatsApp client. I think it’s an Electron wrapper round WhatsApp web, but downloading files from messages into a local directory works fine for me.
The app shouldn’t need filesystem permissions to do that, because the FileChooser portal allows access to directories outside the sandbox when the user selects them in the file chooser dialog. But as it happens, Zapzap by default has access to the whole host filesystem. I myself have disabled this but I kind of understand the developer’s rationale for doing it this way. Without it, you could add attachments from anywhere via a file chooser, but you couldn’t drag and drop them into the chat.
(Re the earlier post, I didn’t use Zapzap before last August, so maybe it previously didn’t work as smoothly as it does now.)
Blufin is not Linux distribution in full sense. Fedora is Linux distribution and one of Fedora’s spin is SilverBlue that is Gnome desktop environment made “immutable”. But… Fedora is super great but has some limitations primarily because of free and open-source philosophy that it follows. Universal Blue has more freedom and just uses Silverblue in case of Blufin and just installs additional packages and make back image immutable (simplified). Such an image everyone can make and publish and others can download.
Blufin is not a Linux distribution in full sense, but more like a repackager or redistributor. You know just like small shop buys articles in multiple bigger shops adds own touch like some cowboy decoration style and sells the product further. We can’t expect from this small shop to improve the quality of caw meat, because small shop does not possess living caws to feed them with better food. If we want to improve meat quality we need to go upstream.
There is similarity, what we can expect from Blufin is, we find some very interesting program that many of users may be interested (e.g. LDAP login integration for companies) and such programs are installed on default image.
How should this be done?
Install system level packages.
Install flatpaks.
Make some scripts that modifies how flatpaks works.
There are some problems with this philosophy:
If there is an issue with specific flatpak, why not contribute fix upstream at flatpak/flathub level and all of the Linux ecosystem can benefit.
Why should we maintain some special integration and get maintenance burden to deal with. Blufin is a small team of voluntears and doing such integration is just not fun thing to do.
What if application developer does not want what we make? We will get into “war” with application developer, because his/her bugtracker will be filled with “bugs” that are not bugs from aplication developer, but distributor. I have seen some of this kind of “wars” even lately with OBS Studio software.
Some intensive search should be done, to find out what users really like. Do they like such an integration, if not we need to provide rollback scenario. Additional burden.
Flatpak is relatively new kid in the block and in such cases you can’t make full of restrictions, but just go with the flow and make as much applications to work as much as possible. Slowly over time frameworks adds support for flatpak and application developers using new version of frameworks automatically get this new functionalities and can add them to application they develop. Then second phrase kicks in, when enough traction is made, and flatpak/flathub starts to impose some small rules, some small requirements how should applications be build to be published on Flathub repository. This has already happened multiple times and flapak applications are improving over time, but this is slow process, because in the free software ecosystem you can’t do things with force, because it just doesn’t work like this, because there are plenty of good working alternatives that application developers, package maintainers etc would use instead.
Flathub is not even near any Apple/Google mobile like position, when rules are made and if you do not follow them, you can’t publish applications on there platform. If Flathub has such a “power”, flatpak applications would improve immediately. But from decates of Linux we have learned that we are grateful if application for Linux even exists because of tiny Linux desktop market share and imposing all kind of restrictions will just shrink market share even further.
In my humble opinion it may not be like this. @j0rge has written somewhere on this forum, that primary target users for Blufin are application developers. They can fix the issues so they can benefit and doing this over and over and Blufin improves to the point that is more and more useful to average Joe and Jane. I don’t think Blufin is there yet, not because it is not great by itself, but because whole ecosystem is just not super stable, like flatpaks break time to time, flatpaks are packaged by third party (not application developers), because application developer likes to program, packaging is whole lot of additional work. But I think flatpak has made some traction and big open-source projects like LibreOffice office suite and Firefox web browser are now maintained by original application developer organizations, so we can expect much better quality. When some third party maintainer package software any issue with flatpak is not an issue for application developer, even worse application developer can just ignore all of the flatpak issues and just point to the users that they install application from native Linux distribution package repository. But… when application developers recognizes the benefit of flatpak ecosystem and knows there product users are there, then they start to package flatpak for themself, now whole new world opens, all issues related to flatpak directly appears in there bug tracker and they make some testing system to make sure there product is working without issues.
When flatpak is build, package maintainer decides what kind of privileges application needs and just adds privileges in flatpak manifest file that is used to build flatpaks. Additional privileges can be added by end user, but in most cases are not required. Maybe in your case it was not permission error, we can’t know, because you are talking in general instead of specific. In general no new privileges are required, but in specific there may be some rare cases when additional restrictions needs to be lifted. But maybe there was whole different issue… we can’t know, because we don’t know the specifics. Doctor can’t cure the illness if we wants to cure “general” issue and saying to the doctor, can you make your medicine in the way my whole “specific” issues will go away?
I think you are expecting too much. This is the upstream job at flathub or even upper application developer. What I see Whatsup is not even officially packaged by application developers. What you can do, is search for there bug tracker and add new request to build Whatsup. I assume such an issue is already added - in this case in Github on first post just add “+” to the issue itself and when a lot of people makes there vote, then application developer may decide to package application as flatpak. But… Whatsup is made by multi-billion dollar company and such companies wants few billion people to use there app, or at least few 100-million. Linux is tiny share, and flatpak is even tinier. Don’t expect any application from multi-billion-trillion corporations to land in flatpak any time soon. That’s the way it is… show me the market philosophy and we will to throw few millions in the market to get some billions out of it.
It looks like you think Blufin and wider Universal Blue team is huge team of few thousand of developers. Blufin is tiny, just like ten or little bit more. If there was a kernel fix by one of Blufin developers, it is not because this team has huge resources, but because one of the issue that prevented developer as being user of product, made a fix.
Hmmmm… I have somehow got an impression, what you would like to do is someone other to fix your issues. This is classical proprietary software thinking. You pay for the product and you are entitled to get product working. Not in open-source, sorry… if you want your issues to be solved, then you have to move your ass and do something about it. Like do some testing, go to upstream bug tracker and report issue, when fix is provided, do additional testing etc. You can do some other things fix documentation, help with translations to some other language or similar. Don’t expect everything to just works. It is not the year of the Linux yet and it may never be. Linux on desktop is a niche product and on niche products such an issues are common and widely expected.
In my humble opinion Blufin is great even for average users, but make sure you have some guru at the end to help average user when he/she gets into trouble.
But at the end… like I have written before. If your main complain is flatpaks and you would like to have flawless system, I think flatpaks are yet not at the level of first class citizen. Many application developers do not care about distribution. They just hack and packaging is just burden they want to avoid. If there is alternative like native Linux package, they will most probably prefer it. What maybe has to change is, to make flatpaks more easy to build, like some easy to follow wizard that makes flatpak manifest file. Because assembling manifest file manually is pain that requires a lot of documentation reading and help from Flathub community forums.
In my humble opinion, if you expect flatpaks to work flawlessly, they don’t. Currently most Linux native packages works better and maybe for average Joe and Jane currently Blufin is not the best solution. Because you will need someone to actively fix issues for average users. But… average users may don’t like constantly to bother you and will request to install something else that works flawlessly.
My suggestion:
Don’t expect to do nothing and everything will be fixed by itself. This is not the way Linux works.
Get actively involved, test, report bugs, fix issues, write documentation, do translations etc and make improvements.
Reconsider if flatpak based distribution like Blufin is the best what you want for your friends and how much time do you want to invest to help them. Maybe some other Linux distribution is more suitable for your needs.
And the final and probably the most important one. Talking about general is nice and easy, but actual issues are solved at specific. Try to open new thread with actual specific issue you have that me or someone else can help you with.
Whole this general discussion about flatpak hell should in my humble opinion be way way way way… (up to the million way) be better to discuss where actual issue originates from, Flathub forum, but be prepared with specific issues, because they will point you to even upper stream to application developer forum or bug tracker. You can’t expect to have clean ocean with cleaning machine at the ocean level. You need to go up the river stream, one river after another all sub streams to search for pollutants and make river by river cleaner and at the end ocean (Blufin) will be clean and happy to swim in. Hard work? Super hard… but that is the way Linux works.
Ok I think I figured out a better way to say this since we may not make whatsapp but we are trying to make them care about us. Here’s a more constructive way to think about it:
We have to have sandboxed apps or we may as well pack our bags and go home. Currently that’s flatpak via flathub. Despite all the complaining you read about flatpak, there’s plenty of people with happy experiences. Bluefin with libadwaita apps via flathub is just sooooo good. And the apps I cared about I set up so long ago I forgot.
Some apps are going to not be good. We vote and review appropriately in the software store, the apps are in a competitive marketplace now. The good ones should rise to the top. And also we left the whole “let’s just package the planet ourselves” part of the model behind because we know it doesn’t scale. That means it needs to be the app developers that take charge of their destiny, and it’s our job to just deliver the entire thing to the user.
People tell me all the time how great Flathub is on our images, our project’s purpose is to go all in on what that is, knowing that it’s up to us to make that happen. And Bazzite now has enough momentum now to help that, just like SteamOS does. We use the gamer attention to get attention to Flathub. And even though we don’t support snap Ubuntu does, and the more successful Ubuntu is the more they invest in the portals because they need them too. Common API, that’s very cloud native. Then we get what we want.
Bluefin is like a lab, the flatpak experience on lots of distros really sucks. So in a way we wanted to prove that a flatpak model done properly could work. Of course it’s going to have issues, I have been known to say that computers were a mistake.
This is also why we’re not a distro – we’re three distros, fedora for the base, homebrew for the CLI, flatpak for the gui apps. Oh and then since you have distrobox, any other distro package. It’s a pretty great combo, and the papercuts keep getting fixed, but we know the model is solid.
It also means that we can keep our project’s scope limited, it’s not our job to fix desktop linux, it’s our job to fix the delivery pipeline, that’s our role in this ecosystem. And we want to be as cheap as possible from a maintainer point of view. Our job should be getting attention to those projects, we’re just the sysadmins.
I’ve been struggling with boot times on fedora immutable and flatpak. I feel like this is just an intrinsic issue with the libostree philosophy, as both systems use libostree and they both seem to perform poorly.
It’s definitely a good idea but it seems like it’s even less performant than an ABroot or nix structure (which is just plain symlinks after all).
Also this could also be part btrfs as it’s just not the most performant fs out there.
Hahah it’s indeed a great master plan I use NixOS again after having tried Aurora but I really see the value proposition here. It’s becoming such a sublime OOB experience. I could probably install Bluefin on a laptop, hand it to my grandma or other non-tech-savvy family, and they could definitely have a good time with it.
Yes I know systemd-analyze, and I don’t remember its output exactly, but overall it seems to be a bootloader/loading plasma problem. On my machine nowadays with Nix it has systemd-boot and just simply less cruft (I have a very carefully curated config, including only what I want and nothing more, which is just impossible for something as general-purpose as uBlue).
If you want I could try running both systems under VMs with equal specs and try to figure out the specifics so we could try shaving off some boot time…
If you want smaller boot times on uBlue, you could try making your own custom uBlue using BlueBuild and then compare the times. Of course, it’s never going to be as good as a curated NixOS build, but it shouldn’t be that bad either, on a modern system.
Personally I’m content with the boot times on my 1.3yr old Bazzite install, with three layered packages, on my 2.3yr ThinkPad Z13, which takes only 23.7 seconds (not counting firmware/bootloader). Sure, it’s not going to win any speed awards, but it’s not like a few more seconds shaved off this would matter.
Alright, I’m willing to put it down on paper. I’ve called for a vote on our mission statement. Feel free to leave your comments there, you can also vote to show your support/opposition. (Only the approver and member votes count but it’s a cool way to show sentiment.)
Here I have a TP X1 Carbon G8 (10th gen i5) and it boots in 17s total (0s delay on grub, silent boot):
Startup finished in 8.424s (firmware) + 1.484s (loader) + 3.488s (kernel) + 3.673s (userspace) = 17.070s
graphical.target reached after 3.668s in userspace
And my (a little) beefier desktop PC with a Ryzen 5 2600 in it (with a couple more enabled-by-default systemd services):
Startup finished in 10.392s (firmware) + 3.437s (loader) + 2.910s (kernel) + 4.191s (userspace) = 20.930s
graphical.target reached after 4.188s in userspace.
(to be clear these are both NixOS)
Not counting firmware/loader as you did, I get 8 seconds tops. As I said I don’t know the exact numbers, but I do know Aurora definitely couldn’t match that.
Thank you for your suggestion about BlueBuild though. I’ll try it out, as I don’t really want a lot of things out of the box (for example my laptop doesn’t need to run distrobox/podman etc.). I also feel like the *.mount units in systemd tend to take a lot of time…
Then we get what we want. 
I use NixOS again after having tried Aurora but I really see the value proposition here. It’s becoming such a sublime OOB experience. I could probably install Bluefin on a laptop, hand it to my grandma or other non-tech-savvy family, and they could definitely have a good time with it.
