Apps simply need a solid CI pipeline so that when dependencies have security patches, the app is automatically rebuilt and pushed out with the patches as soon as possible.
Right, and since this is so easy software distribution is a solved problem, bugs don't exist and tools like containers, VMs, package managers, app stores etc were never developed because they are totally unnecessary.
In particular, this thread does not exist and I never wrote this.
The containerization still has advantages. For one you have a solid and predictable baseline system regardless of what distro the user installed. Next you have sandboxing (if properly applied) protecting the user until they install the update (which might be some time).
You can also SXS the application in case you want to (ie some feature in the app was removed or changed but you want the new version too).
No, it does not, and this very article reveals why on a desktop environment. If the "solid and predictable baseline system" you used contains even a slightly different version of the input method library the user is currently using, then the user can no longer type _at all_ in your fancy application. Same thing for a myriad other integration points users are expecting in a desktop program. Drag and drop? Running the default program for X service? Window manager decorations? Etc.
The user might as well just be forced to run your "solid and preditactable baseline system" as his desktop system.
Containers may be massaged to work on servers because at the end of the day most interaction between server programs happens using TCP/IP (sigh). This is an entire different story with desktop programs.
>If the "solid and predictable baseline system" you used contains even a slightly different version of the input method library the user is currently using, then the user can no longer type _at all_ in your fancy application. Same thing for a myriad other integration points users are expecting in a desktop program. Drag and drop? Running the default program for X service? Window manager decorations? Etc.
Well that input library is not an issue of the flatpak environment but an issue of the application and/or that library. That error could have easily occured if the application linked an old version of that library and the new version of the daemon was incompatible.
Drag and drop works with flatpak to my knowledge, as does running something as default program for opening a file or URL. And window manager decorations work fine for my flatpak apps too.
The user would not be forced to do that if Linux system devs got their shit together. At the moment, Linux is barely a end-user desktop because everything beyond opening a webbrowser (and maybe not even that) is complicated. Configuring default fonts requires me to sudo'ing a text editor into an /etc file and manually insert the right incanations into an XML format.
Many subsystems in the linux desktop haven't been properly updated in quite some time and lag behind modern developments.
This is an issue Linux created because everyone makes their own solution and then distro managers will silently patch over the mistakes, so it all kinda works together.
The IME issue can be solved by making portals versioned, so flatpak can install the app with a runtime that contains a version of the IME lib that works. Similarly for other IO between the host services and client libraries.
Additionally, portals can already provide a number of things (drag and drop for example) without having to compromise security or convenience.
I would also like to point out that not every input method library the user has is going to break every single revision.
> Well that input library is not an issue of the flatpak environment but an issue of the application and/or that library. That error could have easily occured if the application linked an old version of that library and the new version of the daemon was incompatible.
But that wouldn't happen in a distro-packages environment, because the distribution would ensure that everything was built against the same version of the library.
> This is an issue Linux created because everyone makes their own solution and then distro managers will silently patch over the mistakes, so it all kinda works together.
And flatpak is yet another case of that - doing their own incompatible thing instead of fixing what's there already.
>But that wouldn't happen in a distro-packages environment, because the distribution would ensure that everything was built against the same version of the library.
This does not ensure that the library is compatible with the package, it only ensures that it builds.
>And flatpak is yet another case of that - doing their own incompatible thing instead of fixing what's there already.
They are working on standards that would improve things regardless of whether you're in a container or not. For example, the flatpak portals generally work just as well if you don't use flatpak at all, so apps don't care if they are inside our outside it.
This is part of the Freedesktop initiative on various things around Linux, which is already followed by quite a majority of desktop apps (and CLI apps), so there is a standard that improves things as they are.
Portals give you a standard way to interact with the user and the system that don't rely on distro specific patches.
