4 ms·

IMHO this is kind of silly to use very old versions of gcc, libc, etc. Instead use the kernel's namespacing, chroot, etc. features to ship your dependencies.

IMHO this is kind of silly to use very old versions of gcc, libc, etc. Instead use the kernel's namespacing, chroot, etc. features to ship your dependencies. I.e. build a flatpak and forget all these archaic tricks and machinations.

FooBarWidget 4y ago
Not all of your users can, or are willing to accept, container-like packages.
- qbasic_forever 4y ago
  It's 2023, these features have been in the kernel for over a decade.
  - smoldesu 4y ago
    Can Flatpak package system services yet?
    - qbasic_forever 4y ago
      I don't think flatpak was designed or intended for services. What service manager will it depend on? It sounds like you probably want systemd portable services: https://systemd.io/PORTABLE_SERVICES/ https://systemd.io/PORTABLE_SERVICES/
      - smoldesu 4y ago
        If Flatpak wasn't designed or intended for services, I fail to see how it can be recommended as a relevant tool. I get what you're saying about containerization, but Flatpak is as much of a 'solution' to package management as a cork in a bullet wound.
    - jeroenhd 4y ago
      CoreOS (not specifically Fedora CoreOS) used to do that with Docker. I believe the OS ran your standard systemd services and all through interconnected containers. As far as I can tell, the project has been abandoned, though. I don't think Flatpak is the right tool for the job, it's clearly optimized for UI tools and the occasional command line invocation. Snap may be better for composing a working systems, though that comes with the obvious Snap downsides. Systemd has some great tools to accomplish image/container based operating systems, though I'm not sure how common it's used.
- Xelynega 4y ago
  Why would they not accept it when it's functionally the same as "downloading an exe and double clicking" which people seem to like about windows? If they don't want the container, they can typically compile the source too.
  - Dalewyn 4y ago
    Windows executables are not containers, both in the technical and laymen sense.
  - jeroenhd 4y ago
    Because that exe is a gigabyte in size, needs a special globally installed runtime for some reason and conflicts with my firewall rules. Even AppImages somehow manage to extract themselves to locations that conflict with other tools or earlier versions of the same tool. I have one server with a complex firewall configuration that simply won't work well when I install Docker on it. I end up finding a lot of alternatives for what would otherwise be obvious solutions because projects stopped shipping binaries and replaced them with Docker containers. I'll gladly make use of the compilation approach thanks to software available in the AUR. The whole "let's ship a copy of Debian to make my 400kB binary run" approach is as tiresome as "let's ship a copy of Chromium so I don't need to learnddesktop UI". I know how terrible the dependency management situation on Linux is (I myself have had to resort to building software in chroots because of glibc being outdated) but the "modern" approach seems to add more trouble than it solves when I try to run programs like this. On many distros these problems have luckily already been solved. On Ubuntu that means I'll often be using an outdated version of the program that works just as well and on Arch (based distros) that means waiting for a compile every other update, but I've given up on tools that come with an entire ecosystem.
  - badsectoracula 4y ago
    That isn't the experience with flatpak though, flatpak is the same as using apt-get or any other package manager except instead of getting stuff from your distro's repositories you get them from some flatpak repository you have to configure (some distros that provide flatpak might have flathub preconfigured, though not all of them do that). AppImage does provide that "download an exe and double click" experience but it assumes you have made said portable Linux binaries (and they still have the drawback of dragging in a bunch of libraries you most likely already have in your distro).
badsectoracula 4y ago
Flatpak is awful, i tried install software from it a few times and not only it always in a ton of unnecessary stuff (practically an entire distro!) but also the software doesn't integrate seamlessly with the rest of the system. GUI software looks wrong (themes do not apply, font rendering is wrong), command line software doesn't show up in PATH. Example in [0] for the GUI bits (Bless for theme, Notepadqq for font rendering) as well as the disk usage for two simple programs like a hex editor and a text editor. Even worse, while there is an option to install things in the user's directory only (so i can make a separate user to try some things that i can easily delete later) not everything installs with that options and wants root access to pollute the rest of my system. Nowadays i simply avoid anything related to flatpak. If something doesn't provide normal binaries and i really want it, i'd rather compile it from source (and if the source language is something exotic or the program needs a ton of dependencies i'd just skip it). [0] https://i.imgur.com/9tmo26J.png https://i.imgur.com/9tmo26J.png
- Vogtinator 4y ago
  > (practically an entire distro!) Practically most container images literally are their own distro install. In the case of flatpak, this becomes obvious when looking at flathub and the provided "runtimes". At that point they just reinvented packages.
  - badsectoracula 4y ago
    Flatpak is much worse than packages because if i install a package from my distro it doesn't make duplicates for libraries and other software i already have installed. If Flatpak checked to see what i have already available and downloaded only the dependencies i do not have already installed while also providing seamless integration (a large part of which wouldn't be an issue if it used the system libraries/software), it'd actually be very useful and a solution to every distro having to package every program under the sun and keep it up to date (which IMO is also a bad thing because obviously not all distros can do that, it is just that Flatpak is a worse solution).
  - robertlagrant 4y ago
jvanderbot 4y ago
Or, you know, build with three tool chains: arm, windows x64, and Linux gnu x64 and get 90% of your users. Static complied dependencies goes a long way.
- qbasic_forever 4y ago
  No like the post mentions you need to target a libc your users have on their system, which they show is best handled by linking to one that's a decade plus old (as a least common denominator most likely to be available). If that sounds silly... then ship your libc and everything you depend on in a flatpak or similar contained system image.
- AnIdiotOnTheNet 4y ago
  Build for Windows, get 90% of potential users. Many of them on Linux!
PaulDavisThe1st 4y ago
flatpak is basically useless for any context where the application is expected to load and execute arbitrary 3rd party shared libraries (aka "plugins"). This rules out most sophisticated audio applications.
- jancsika 4y ago
  Are audio apps the only type of app to use the plugin pattern? I've never seen any other app category mentioned when plugins (or an equivalent descriptor) come up. Does dl_open crash if it can't find an open ALSA connection or something?
  - PaulDavisThe1st 4y ago
    dlopen("plugin.so"); /* Load that super cool reverb plugin */ .... /* oops, the .so is not part of the flatpak ... fail */ Most other systems that do "plugins" tend to use a domain specific language and load the "plugin" as a normal file, rather than via the dynamic linker.

FooBarWidget 4y ago

Not all of your users can, or are willing to accept, container-like packages.

qbasic_forever 4y ago
It's 2023, these features have been in the kernel for over a decade.
- smoldesu 4y ago
  Can Flatpak package system services yet?
  - qbasic_forever 4y ago
    I don't think flatpak was designed or intended for services. What service manager will it depend on? It sounds like you probably want systemd portable services: https://systemd.io/PORTABLE_SERVICES/ https://systemd.io/PORTABLE_SERVICES/
    - smoldesu 4y ago
      If Flatpak wasn't designed or intended for services, I fail to see how it can be recommended as a relevant tool. I get what you're saying about containerization, but Flatpak is as much of a 'solution' to package management as a cork in a bullet wound.
  - jeroenhd 4y ago
    CoreOS (not specifically Fedora CoreOS) used to do that with Docker. I believe the OS ran your standard systemd services and all through interconnected containers. As far as I can tell, the project has been abandoned, though. I don't think Flatpak is the right tool for the job, it's clearly optimized for UI tools and the occasional command line invocation. Snap may be better for composing a working systems, though that comes with the obvious Snap downsides. Systemd has some great tools to accomplish image/container based operating systems, though I'm not sure how common it's used.
Xelynega 4y ago
Why would they not accept it when it's functionally the same as "downloading an exe and double clicking" which people seem to like about windows? If they don't want the container, they can typically compile the source too.
- Dalewyn 4y ago
  Windows executables are not containers, both in the technical and laymen sense.
- jeroenhd 4y ago
  Because that exe is a gigabyte in size, needs a special globally installed runtime for some reason and conflicts with my firewall rules. Even AppImages somehow manage to extract themselves to locations that conflict with other tools or earlier versions of the same tool. I have one server with a complex firewall configuration that simply won't work well when I install Docker on it. I end up finding a lot of alternatives for what would otherwise be obvious solutions because projects stopped shipping binaries and replaced them with Docker containers. I'll gladly make use of the compilation approach thanks to software available in the AUR. The whole "let's ship a copy of Debian to make my 400kB binary run" approach is as tiresome as "let's ship a copy of Chromium so I don't need to learnddesktop UI". I know how terrible the dependency management situation on Linux is (I myself have had to resort to building software in chroots because of glibc being outdated) but the "modern" approach seems to add more trouble than it solves when I try to run programs like this. On many distros these problems have luckily already been solved. On Ubuntu that means I'll often be using an outdated version of the program that works just as well and on Arch (based distros) that means waiting for a compile every other update, but I've given up on tools that come with an entire ecosystem.
- badsectoracula 4y ago
  That isn't the experience with flatpak though, flatpak is the same as using apt-get or any other package manager except instead of getting stuff from your distro's repositories you get them from some flatpak repository you have to configure (some distros that provide flatpak might have flathub preconfigured, though not all of them do that). AppImage does provide that "download an exe and double click" experience but it assumes you have made said portable Linux binaries (and they still have the drawback of dragging in a bunch of libraries you most likely already have in your distro).

badsectoracula 4y ago

Flatpak is awful, i tried install software from it a few times and not only it always in a ton of unnecessary stuff (practically an entire distro!) but also the software doesn't integrate seamlessly with the rest of the system. GUI software looks wrong (themes do not apply, font rendering is wrong), command line software doesn't show up in PATH. Example in [0] for the GUI bits (Bless for theme, Notepadqq for font rendering) as well as the disk usage for two simple programs like a hex editor and a text editor. Even worse, while there is an option to install things in the user's directory only (so i can make a separate user to try some things that i can easily delete later) not everything installs with that options and wants root access to pollute the rest of my system. Nowadays i simply avoid anything related to flatpak. If something doesn't provide normal binaries and i really want it, i'd rather compile it from source (and if the source language is something exotic or the program needs a ton of dependencies i'd just skip it). [0] https://i.imgur.com/9tmo26J.png https://i.imgur.com/9tmo26J.png

Vogtinator 4y ago
> (practically an entire distro!) Practically most container images literally are their own distro install. In the case of flatpak, this becomes obvious when looking at flathub and the provided "runtimes". At that point they just reinvented packages.
- badsectoracula 4y ago
  Flatpak is much worse than packages because if i install a package from my distro it doesn't make duplicates for libraries and other software i already have installed. If Flatpak checked to see what i have already available and downloaded only the dependencies i do not have already installed while also providing seamless integration (a large part of which wouldn't be an issue if it used the system libraries/software), it'd actually be very useful and a solution to every distro having to package every program under the sun and keep it up to date (which IMO is also a bad thing because obviously not all distros can do that, it is just that Flatpak is a worse solution).
- robertlagrant 4y ago

jvanderbot 4y ago

Or, you know, build with three tool chains: arm, windows x64, and Linux gnu x64 and get 90% of your users. Static complied dependencies goes a long way.

qbasic_forever 4y ago
No like the post mentions you need to target a libc your users have on their system, which they show is best handled by linking to one that's a decade plus old (as a least common denominator most likely to be available). If that sounds silly... then ship your libc and everything you depend on in a flatpak or similar contained system image.
AnIdiotOnTheNet 4y ago
Build for Windows, get 90% of potential users. Many of them on Linux!

PaulDavisThe1st 4y ago

flatpak is basically useless for any context where the application is expected to load and execute arbitrary 3rd party shared libraries (aka "plugins"). This rules out most sophisticated audio applications.

jancsika 4y ago
Are audio apps the only type of app to use the plugin pattern? I've never seen any other app category mentioned when plugins (or an equivalent descriptor) come up. Does dl_open crash if it can't find an open ALSA connection or something?
- PaulDavisThe1st 4y ago
  dlopen("plugin.so"); /* Load that super cool reverb plugin */ .... /* oops, the .so is not part of the flatpak ... fail */ Most other systems that do "plugins" tend to use a domain specific language and load the "plugin" as a normal file, rather than via the dynamic linker.