4 ms·

Once the linux world moves completely to Flatpak, that would truly help languages like C++ - whose evolution and cleanliness has been tremendously crippled by b

Once the linux world moves completely to Flatpak, that would truly help languages like C++ - whose evolution and cleanliness has been tremendously crippled by being unable to have a clean ABI break.

badsectoracula 4y ago
Let me repeat a message i wrote some time ago here because i really don't think Flatpak is a good solution (note that this isn't issues from some ancient distro, this is from openSUSE Tumbleweed, this is only a few months old): -- Flatpak is awful, i tried installing software from it a few times and not only it always installs 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
- IceWreck 4y ago
  For desktop integration, install flatseal and pass ~/.themes and other desktop directories to the flatpak app. It doesn't happen by default cause sandboxing. Command line software does show up in CLI, just not by its short name. You have to use the fully qualified app name - com.xyz.whatever. You can make an alias if you want. > 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. Are you talking about flatpak install --user ? Yes youre right some apps might not work with it but how is that any worse than traditional packaging. Flatpak isn't perfect and I prefer distro packaging over everything else but it isn't feasable to have distro packaging for everything - not with the strict packaging rules most distros have atleast. But out of snap, appimage and flatpak I'd go with Flatpak.
  - badsectoracula 4y ago
    There are workarounds for everything i mentioned, including just taking out the application binaries and placing them in /usr/local or whatever by hand. The point is that while Flatpak might solve some issues, it also introduces others.
gnulinux 4y ago
I know this is a controversial opinion, some would strongly disagree with me, maybe most would consider me downright wrong. But as a system designer I always thoughts (by always, I mean last ~5 years since I've been thinking about this) the misery we experience with C/C++ package management is an OS problem, not a language problem. The fact that some languages roll their own package manager like pip, npm, cargo etc doesn't change this for me at all. pip, npm, cargo are symptoms of OSs failing to ship dependencies in a sane way. Ultimately I want my software to be shipped by my OS's package manager like pacman, apt, nix, or flatpak etc. The fact that I can go ahead and install dependencies in pip, npm is an implementation detail while I'm working with the code. The entire linux ecosystem should have been designed in the first place like nix, AppImage or flatpak from day 0 and going to the "shared libraries" route was simply a bug. We thought it was ok, but we quickly saw it was not ok and we should have made the observation that it's not working and switched but we didn't. Like nix does, when there are common dependencies between apps you can still optimize and install them once, but each app should define its own dependency and that version alone should be allowed to use so that a library upgrade doesn't break anything. Unfortunately, package management is an utter mess today and I no longer have any appetite to use things like `pacman` or `apt` unless absolutely necessary. And this is not even just the fault of archlinux or Debian. Case in point, MuseScore (an app I use every day to write music) published MuseScore 4 over MuseScore 3. The fact is, MS 4 is much better than MS 3, but some workflows are different and it's not in complete future parity with MS 3 (some things they decided not to implement). Now, I want to use MS 4 and I do use MS 4 for most things, but for certain things I still absolutely need MS 3. By "absolutely": I mean for some compositions MS 4 is a dealbreaker and MS 3 is the correct tool. But most other compositions MS 4 is the superior and correct tool. But when they published MS 4 pacman immediately made the package `musescore` point MS 4 with no option to install MS 3. They're two entirely different apps. Solution? Just download the .AppImage from website and call it a day. It would have been much better if `pacman` serves MS4.pacman_exe and I click on it and it opens MS4. Then, it also optionally serves MS3.pacman_exe, I click on it and that also works. If I desire I click on MS3.6.2.alpha43432.pacman_exe and use that specific version, with every library fixed. But this is currently impossible since each version can potentially need different dependencies etc so .AppImage is the only way.
- 4y ago

Once the linux world moves completely to Flatpak, that would truly help languages like C++ - whose evolution and cleanliness has been tremendously crippled by being unable to have a clean ABI break.

badsectoracula 4y ago

Let me repeat a message i wrote some time ago here because i really don't think Flatpak is a good solution (note that this isn't issues from some ancient distro, this is from openSUSE Tumbleweed, this is only a few months old): -- Flatpak is awful, i tried installing software from it a few times and not only it always installs 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

IceWreck 4y ago
For desktop integration, install flatseal and pass ~/.themes and other desktop directories to the flatpak app. It doesn't happen by default cause sandboxing. Command line software does show up in CLI, just not by its short name. You have to use the fully qualified app name - com.xyz.whatever. You can make an alias if you want. > 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. Are you talking about flatpak install --user ? Yes youre right some apps might not work with it but how is that any worse than traditional packaging. Flatpak isn't perfect and I prefer distro packaging over everything else but it isn't feasable to have distro packaging for everything - not with the strict packaging rules most distros have atleast. But out of snap, appimage and flatpak I'd go with Flatpak.
- badsectoracula 4y ago
  There are workarounds for everything i mentioned, including just taking out the application binaries and placing them in /usr/local or whatever by hand. The point is that while Flatpak might solve some issues, it also introduces others.

gnulinux 4y ago

I know this is a controversial opinion, some would strongly disagree with me, maybe most would consider me downright wrong. But as a system designer I always thoughts (by always, I mean last ~5 years since I've been thinking about this) the misery we experience with C/C++ package management is an OS problem, not a language problem. The fact that some languages roll their own package manager like pip, npm, cargo etc doesn't change this for me at all. pip, npm, cargo are symptoms of OSs failing to ship dependencies in a sane way. Ultimately I want my software to be shipped by my OS's package manager like pacman, apt, nix, or flatpak etc. The fact that I can go ahead and install dependencies in pip, npm is an implementation detail while I'm working with the code. The entire linux ecosystem should have been designed in the first place like nix, AppImage or flatpak from day 0 and going to the "shared libraries" route was simply a bug. We thought it was ok, but we quickly saw it was not ok and we should have made the observation that it's not working and switched but we didn't. Like nix does, when there are common dependencies between apps you can still optimize and install them once, but each app should define its own dependency and that version alone should be allowed to use so that a library upgrade doesn't break anything. Unfortunately, package management is an utter mess today and I no longer have any appetite to use things like `pacman` or `apt` unless absolutely necessary. And this is not even just the fault of archlinux or Debian. Case in point, MuseScore (an app I use every day to write music) published MuseScore 4 over MuseScore 3. The fact is, MS 4 is much better than MS 3, but some workflows are different and it's not in complete future parity with MS 3 (some things they decided not to implement). Now, I want to use MS 4 and I do use MS 4 for most things, but for certain things I still absolutely need MS 3. By "absolutely": I mean for some compositions MS 4 is a dealbreaker and MS 3 is the correct tool. But most other compositions MS 4 is the superior and correct tool. But when they published MS 4 pacman immediately made the package `musescore` point MS 4 with no option to install MS 3. They're two entirely different apps. Solution? Just download the .AppImage from website and call it a day. It would have been much better if `pacman` serves MS4.pacman_exe and I click on it and it opens MS4. Then, it also optionally serves MS3.pacman_exe, I click on it and that also works. If I desire I click on MS3.6.2.alpha43432.pacman_exe and use that specific version, with every library fixed. But this is currently impossible since each version can potentially need different dependencies etc so .AppImage is the only way.

4y ago