I don’t think that’s the main problem, as on the inside (meaning backends) most things are rather standardized (ignoring legacy stuff) and any distro not adhering to those modern standards can be - purely from an economic aspect, NOT a nerd or enthusiast aspect - safely ignored. I do concur that choice paralysis indeed is a problem though.
The modern stack is pretty straight-forward: Flatpak and Snap for distribution, GTK4 (opt. with or without libadwaita) or Qt6 for the UI, Gnome and KDE to take care for proper integration, and stuff like Wayland, Pipewire and the XDG specs to focus on in technical aspects. All the documents necessary to work on fully functioning apps to publish via both Flatpak and Snap are there (not saying everything is perfect, just that it’s properly working). Distro-specific bugs will also be either prevented by the new sandboxing or are to be fixed by the distro in 99% of all cases, not the app author. What’s really missing right now is a way to sell it through those hubs.
Eventually there’ll be sufficient pressure on all sides so common technical necessities will be defined that distros will have to adhere to if they want to receive app support (which is very much possible given the sandboxing around Flatpaks and Snaps). Until then every company keeps freely defining what they support. Right now they usually go two or three big ones, namely Ubuntu, RHEL+Fedora and perhaps SteamOS. Some also go for OpenSuse, probably because they use SLES for their own machines.
Meanwhile commercially developed distros - meaning stuff like Pop!_OS (System76 devices), SlimbookOS (Slimbook devices), Tuxedo OS (Tuxedo Computers) - all use Flatpaks, and as they all integrate it as intended apps work on them as they do on any other distro that uses the modern stack. So customers don’t have to think too much about it.
tl;dr…
Don’t give new users too many options (avoids choice paralysis) but 1 or 2 modern ones or whatever a hardware vendor offers, and don’t expect developers to target distros that do not want to fully support either Flatpaks or Snaps. Then we’re already on a good way.
@Natanox@mtchristo
>Flatpak and Snap for distribution, GTK4 (opt. with or without libadwaita) or Qt6 for the UI, Gnome and KDE to take care for proper integration, and stuff like Wayland, Pipewire
I do not have anything of this in my system and will not install any app that requires to support all of this.
Flatpak even cannot work without namespaces (which is not enabled in kernel defconfig). If you want to make flatpak default option to distribute apps, first make sure it does not require enabling some (possibly insecure) kernel configurations and work on default kernel
Wayland (in current implementation) is error. Flatpak/snap is error.
Before all of this, all we need to make app work is some x11 libraries, so app can bundle it’s needed portable toolkit and run without any additional requirements. Now we cannot just provide wayland-client, because app cannot draw with it. It needs opengl, which needs many libraries, which… cannot be provided in compatible way, so you need container bullshit that runs other distro inside… only to run some graphical app that draws few buttons…
Really, i’ll prefer using windows, not this bullshit.
Now flatpak causes people ignoring new glibc compatibility bugs, so it soon will be impossible to build portable binary for glibc systems… Even now Portable Executable (windows exe) is most portable way to distribute software for linux, because wine gives compatibilty that glibc cannot (or jusn do not want). And sometimes wine even have less memory overhead than flatpak/snap
I do not have anything of this in my system and will not install any app that requires to support all of this.
What are you using, a potato? Any modern distro comes with those. Without GTK4 and Qt6 barely anything even runs, lol.
I mean, you can reject literally everything of this new technology stack, but that doesn’t change the fact it’s things are working now. If you stay with old tech don’t be surprised if things stop working though, the world will move even if you prefer to stand still. However if you want to be taken serious in your criticism please inform yourself on what you’re criticize. Neither Flatpak nor Snap run “another distro inside”. What you’re talking about is stuff like Docker or Distrobox. Those are neither the default on user systems nor should they be, only very few distros aimed at enthusiasts and professionals ship them by default.
There are also multiple ways to ship portable apps, the best known of them would be AppImage. That one simply isn’t recommendable due to a lack of maintenance and security issues (they simply don’t fix the libfuse2 issue).
It’s not like everything was great in ye’ olden days anyway. There literally are FOUR different backends for desktop notifications, Pulseaudio is a friggin’ trainwreck and don’t even get me started on Xorg configuration. Every desktop environment very much did their own thing and once you installed an app using f.e. GTK2 on a KDE3 system the whole thing looked like it recently insulted Mike Tyson since there was no proper config available / it lacked the icon theme / the font broke everything / it didn’t like your hairstyle. Likewise running older software more often than not was a real pain as they expected an environment with obsolete libraries etc.
Like it or not, Flatpak and Snap already are the standard. So is Wayland (and it works like a charm by now), and Pipewire is a god damn godsend after meddling with Pulseaudio all those years. And from a developer’s perspective it’s so nice to have a controllable environment to work with, i.e. Flatpak and Snap. Of those two only Snap generates huge overheads btw, it’s a known problem with Canonicals approach (one of many). Still, technology like that is what Linux needs for the future.
But hey, ultimately Linux gives you the choice. If you want to stay in your niche I hope it suits you well.
@Natanox
>Without GTK4 and Qt6 barely anything even runs, lol.
There is very few qt6-only software and i even did not see gtk4.
I not even using gtk3, because it looks ugly and usually there are gtk2 or qt5 alternatives.
I will swicth to qt6 when renderdoc will support it. Almost all software i using support both qt5 and qt6 and i see no reason to keep both toolkits installed
It is powerful Gentoo system with TDE, which runs heavy games (including VR), and of course, it can run gtk4/flatpak if i enable it. But i do not want. I want exclusive control my system and not let some binary distro (including flatpak/snap) maintainers to control it and tell me what technologies to use
>There are also multiple ways to ship portable apps, the best known of them would be AppImage. That one simply isn’t recommendable due to a lack of maintenance and security issues (they simply don’t fix the libfuse2 issue).
AppImage does not help with portability, this is just bundle. And very bad designed bundle. For example, it may use some static lightweight fuse implementation, not depending on libfuse.
You do not need bundle to make app compatible, you need to build it (including all dependencies) with compatible glibc version.
For wayland it’s very difficult because usual waylan app depends on heavy non-portable toolkits and GL drivers and you need make it not conflict with system GL. It is quite possible when both toolkit and GL driver depends on some expat/llvm/etc…
So really to do that, you toolkit need able to draw with opengl and have software fallback (because drawing 2d with llvmpipe is nonsense)
I may suggest SDL2+imgui and now using it in my apps, but this is very limited solution, really and it cannot draw effectively in software too (because ImGui decided to only use blended triangles to draw). Some drawing protocol in wayland may solve this, but it is unlikely to happen because wayland is protocol for compositing, not drawing and refers to using graphics API (where is hardware accelerated 2d drawing API???) to draw. So i even cannot show simple messagebox without headache! Imagine Windows without GDI and user32? Wayland is alike.
X11 really old and we need better solution, but wayland is not better solution. Wayland is already more complex than X11 for application developers. Maybe it’s better for some toolkit developers, but only because toolkit developers are compositor developers. If you need better solution, look at windows GDI, android hwcomposer/surfaceflinger, haiku, etc… Only advantages we got from wayland are fractional scaling and faster (in comparsion with x11/glamor) compositing. But even legacy x11/(exa/sna) works faster, it’s just glamor is very slow.
For sound, pipewire really looked good, until pipewire-media-session was deprecated. Now it requires wireplumper monster, and recent xdg-desktop-portal versions depend on it.
Why wireplumper is bad? Because last time i installed it it was just crashing somewhere in libcamera after daemonize and i spend 5 hours to debug it. Yes, no sound because of some camera (which i did not even have)
Now i using jack2 in my system and it works, allowing me to route audio as i want. Maybe it will be seamlessly replaced by PW later… But not now. I think, media session for TDE may be implemented in aRtsd, so it will be useful again. For apps, generic sound API is still libasound, because asound architecture allows to integrate audioservers seamlessly. For pulseaudio-only apps, we have apulse wrapper.
>Like it or not, Flatpak and Snap already are the standard
Any shit may be named a standard (like Google’s WebComponents, which is just internal chrome feature was forced to web standard). Long time ago there was ActiveX standard, flash was “standard” too. But this does not mean it’s OK to support it. Yes, flatpak is not proprietary, but it’s purely commercial and possibly forced by corps. It’s designed to make it impossible to work without corps. Maybe this is another EEE?
Anyway, i still may unpack ostree images, install dependencies and run flatpak app if very needed.
But i really do not want this to be standard, because it’s really workaround, not well designed standard.
It will break anyway if i using some rare gl/vulkan implementation (like amdgpu-pro with specific version) and it is not present in flatpak. And one of my previous PCs only worked with such driver, mesa drivers caused crash every 15-20 minutes. In comparsion with flatpak, Valve’s pressure-vessel supports it (because it always using system driver).
Also, Android linker has namespaces, which allows to split system private/vendror and user libraries to prevent symbol conflicts. This would much better solve things, flatpak trying to solve. I do not know, can glibc’s dlmopen do same thing, but android library namespaces doing it automaticly
I don’t think that’s the main problem, as on the inside (meaning backends) most things are rather standardized (ignoring legacy stuff) and any distro not adhering to those modern standards can be - purely from an economic aspect, NOT a nerd or enthusiast aspect - safely ignored. I do concur that choice paralysis indeed is a problem though.
The modern stack is pretty straight-forward: Flatpak and Snap for distribution, GTK4 (opt. with or without libadwaita) or Qt6 for the UI, Gnome and KDE to take care for proper integration, and stuff like Wayland, Pipewire and the XDG specs to focus on in technical aspects. All the documents necessary to work on fully functioning apps to publish via both Flatpak and Snap are there (not saying everything is perfect, just that it’s properly working). Distro-specific bugs will also be either prevented by the new sandboxing or are to be fixed by the distro in 99% of all cases, not the app author. What’s really missing right now is a way to sell it through those hubs.
Eventually there’ll be sufficient pressure on all sides so common technical necessities will be defined that distros will have to adhere to if they want to receive app support (which is very much possible given the sandboxing around Flatpaks and Snaps). Until then every company keeps freely defining what they support. Right now they usually go two or three big ones, namely Ubuntu, RHEL+Fedora and perhaps SteamOS. Some also go for OpenSuse, probably because they use SLES for their own machines.
Meanwhile commercially developed distros - meaning stuff like Pop!_OS (System76 devices), SlimbookOS (Slimbook devices), Tuxedo OS (Tuxedo Computers) - all use Flatpaks, and as they all integrate it as intended apps work on them as they do on any other distro that uses the modern stack. So customers don’t have to think too much about it.
tl;dr… Don’t give new users too many options (avoids choice paralysis) but 1 or 2 modern ones or whatever a hardware vendor offers, and don’t expect developers to target distros that do not want to fully support either Flatpaks or Snaps. Then we’re already on a good way.
@Natanox @mtchristo
>Flatpak and Snap for distribution, GTK4 (opt. with or without libadwaita) or Qt6 for the UI, Gnome and KDE to take care for proper integration, and stuff like Wayland, Pipewire
I do not have anything of this in my system and will not install any app that requires to support all of this.
Flatpak even cannot work without namespaces (which is not enabled in kernel defconfig). If you want to make flatpak default option to distribute apps, first make sure it does not require enabling some (possibly insecure) kernel configurations and work on default kernel
Wayland (in current implementation) is error. Flatpak/snap is error.
Before all of this, all we need to make app work is some x11 libraries, so app can bundle it’s needed portable toolkit and run without any additional requirements. Now we cannot just provide wayland-client, because app cannot draw with it. It needs opengl, which needs many libraries, which… cannot be provided in compatible way, so you need container bullshit that runs other distro inside… only to run some graphical app that draws few buttons…
Really, i’ll prefer using windows, not this bullshit.
Now flatpak causes people ignoring new glibc compatibility bugs, so it soon will be impossible to build portable binary for glibc systems… Even now Portable Executable (windows exe) is most portable way to distribute software for linux, because wine gives compatibilty that glibc cannot (or jusn do not want). And sometimes wine even have less memory overhead than flatpak/snap
What are you using, a potato? Any modern distro comes with those. Without GTK4 and Qt6 barely anything even runs, lol.
I mean, you can reject literally everything of this new technology stack, but that doesn’t change the fact it’s things are working now. If you stay with old tech don’t be surprised if things stop working though, the world will move even if you prefer to stand still. However if you want to be taken serious in your criticism please inform yourself on what you’re criticize. Neither Flatpak nor Snap run “another distro inside”. What you’re talking about is stuff like Docker or Distrobox. Those are neither the default on user systems nor should they be, only very few distros aimed at enthusiasts and professionals ship them by default.
There are also multiple ways to ship portable apps, the best known of them would be AppImage. That one simply isn’t recommendable due to a lack of maintenance and security issues (they simply don’t fix the libfuse2 issue).
It’s not like everything was great in ye’ olden days anyway. There literally are FOUR different backends for desktop notifications, Pulseaudio is a friggin’ trainwreck and don’t even get me started on Xorg configuration. Every desktop environment very much did their own thing and once you installed an app using f.e. GTK2 on a KDE3 system the whole thing looked like it recently insulted Mike Tyson since there was no proper config available / it lacked the icon theme / the font broke everything / it didn’t like your hairstyle. Likewise running older software more often than not was a real pain as they expected an environment with obsolete libraries etc.
Like it or not, Flatpak and Snap already are the standard. So is Wayland (and it works like a charm by now), and Pipewire is a god damn godsend after meddling with Pulseaudio all those years. And from a developer’s perspective it’s so nice to have a controllable environment to work with, i.e. Flatpak and Snap. Of those two only Snap generates huge overheads btw, it’s a known problem with Canonicals approach (one of many). Still, technology like that is what Linux needs for the future.
But hey, ultimately Linux gives you the choice. If you want to stay in your niche I hope it suits you well.
@Natanox
>Without GTK4 and Qt6 barely anything even runs, lol.
There is very few qt6-only software and i even did not see gtk4.
I not even using gtk3, because it looks ugly and usually there are gtk2 or qt5 alternatives.
I will swicth to qt6 when renderdoc will support it. Almost all software i using support both qt5 and qt6 and i see no reason to keep both toolkits installed
It is powerful Gentoo system with TDE, which runs heavy games (including VR), and of course, it can run gtk4/flatpak if i enable it. But i do not want. I want exclusive control my system and not let some binary distro (including flatpak/snap) maintainers to control it and tell me what technologies to use
>There are also multiple ways to ship portable apps, the best known of them would be AppImage. That one simply isn’t recommendable due to a lack of maintenance and security issues (they simply don’t fix the libfuse2 issue).
AppImage does not help with portability, this is just bundle. And very bad designed bundle. For example, it may use some static lightweight fuse implementation, not depending on libfuse.
You do not need bundle to make app compatible, you need to build it (including all dependencies) with compatible glibc version.
For wayland it’s very difficult because usual waylan app depends on heavy non-portable toolkits and GL drivers and you need make it not conflict with system GL. It is quite possible when both toolkit and GL driver depends on some expat/llvm/etc…
So really to do that, you toolkit need able to draw with opengl and have software fallback (because drawing 2d with llvmpipe is nonsense)
I may suggest SDL2+imgui and now using it in my apps, but this is very limited solution, really and it cannot draw effectively in software too (because ImGui decided to only use blended triangles to draw). Some drawing protocol in wayland may solve this, but it is unlikely to happen because wayland is protocol for compositing, not drawing and refers to using graphics API (where is hardware accelerated 2d drawing API???) to draw. So i even cannot show simple messagebox without headache! Imagine Windows without GDI and user32? Wayland is alike.
X11 really old and we need better solution, but wayland is not better solution. Wayland is already more complex than X11 for application developers. Maybe it’s better for some toolkit developers, but only because toolkit developers are compositor developers. If you need better solution, look at windows GDI, android hwcomposer/surfaceflinger, haiku, etc… Only advantages we got from wayland are fractional scaling and faster (in comparsion with x11/glamor) compositing. But even legacy x11/(exa/sna) works faster, it’s just glamor is very slow.
For sound, pipewire really looked good, until pipewire-media-session was deprecated. Now it requires wireplumper monster, and recent xdg-desktop-portal versions depend on it.
Why wireplumper is bad? Because last time i installed it it was just crashing somewhere in libcamera after daemonize and i spend 5 hours to debug it. Yes, no sound because of some camera (which i did not even have)
Now i using jack2 in my system and it works, allowing me to route audio as i want. Maybe it will be seamlessly replaced by PW later… But not now. I think, media session for TDE may be implemented in aRtsd, so it will be useful again. For apps, generic sound API is still libasound, because asound architecture allows to integrate audioservers seamlessly. For pulseaudio-only apps, we have apulse wrapper.
>Like it or not, Flatpak and Snap already are the standard
Any shit may be named a standard (like Google’s WebComponents, which is just internal chrome feature was forced to web standard). Long time ago there was ActiveX standard, flash was “standard” too. But this does not mean it’s OK to support it. Yes, flatpak is not proprietary, but it’s purely commercial and possibly forced by corps. It’s designed to make it impossible to work without corps. Maybe this is another EEE?
Anyway, i still may unpack ostree images, install dependencies and run flatpak app if very needed.
But i really do not want this to be standard, because it’s really workaround, not well designed standard.
It will break anyway if i using some rare gl/vulkan implementation (like amdgpu-pro with specific version) and it is not present in flatpak. And one of my previous PCs only worked with such driver, mesa drivers caused crash every 15-20 minutes. In comparsion with flatpak, Valve’s pressure-vessel supports it (because it always using system driver).
Also, Android linker has namespaces, which allows to split system private/vendror and user libraries to prevent symbol conflicts. This would much better solve things, flatpak trying to solve. I do not know, can glibc’s dlmopen do same thing, but android library namespaces doing it automaticly