5 ms·

Because they've given up on being able to maintain a desktop distro with a set of system libraries that allow you to run programs. Future shock from the too rap

Because they've given up on being able to maintain a desktop distro with a set of system libraries that allow you to run programs. Future shock from the too rapidly changing underlying libs and no thought of forwards compatibility longer than 3 years means no software lasts longer than 3 years, if that. And so, like a fever is a symptom of infection, we have containers as symptom of future shock. As for which container, it doesn't really matter, and there's been a lot of not-invented here going around creating new containers that muddied the waters. But the truth is they're all symptoms of something bad even if they mitigate a problem temporarily (while making debugging, networking, freedesktop standards, etc incomparably harder).

smoldesu 4y ago
I agree. You've got a bit of a fatalist tone, but you're not wrong either - if Microsoft or Apple announced that they were depreciating all of their prior packaging options in favor of a QEMU image of your application, people would lose it. It's not just about performance or integration or nativeness for most people, it's about the files living in the same spot and not needing extra apps to manage a sandbox. Flatpak feels like it took the wrong lessons from the past 30 years of software distribution and turned it into a platform. I get that it has to be simplified to be friendly to newer users, but it's also a complete turnoff when you want to fix an issue or edit a config file.
quaintdev 4y ago
What do you think about Nix
- superkuh 4y ago
  Nix is the ultimate expression of this abandonment of the concept of a desktop distro. It doesn't even try to have system libraries. Nix gives up re: future shock. The entire OS is just containers. I'm sure it works fine if you only ever use popular software but as someone that's constantly compiling and adding little .c programs from the 'net to my bin/ having to manually create and specify the entire "system" libraries set bit by bit every time I want to compile (or run!) something is no go. Great for business use as server, bad for human persons as a desktop.
  - RGamma 4y ago
    Haven't tried it but you could probably pin an env with everything you would want and then use direnv for automation. And for quick experiments there's FHS/steam-run. But yeah.. setup.
  - gray_-_wolf 4y ago
    > manually create and specify the entire "system" libraries set bit by bit every time I want to compile (or run!) something is no go. I don't have first hand experience with nix, but if I would look at this statement from Guix point of view (and I assume nix will be same/very similar), this is not really true. Nothing prevents you from having a list of libraries (in a manifest). That list might be way to wide for any specific program and it can represent what you would normally have as "system libraries". You can then just invoke shell as guix shell --manifest=manifest.scm and you will be given working shell with all the libraries available. You can also just package your program using trivial copy&paste code with the same list. Sure, the dependencies will be too wide, but since you are not sending the package to upstream Guix for inclusion, no one really cares. So, is it as friction-less as "normal" distro? No (especially the "add to /bin" part). Is it as bad as "manually create and specify the entire "system" libraries set bit by bit every time"? Also no.
  - rgoulter 4y ago
    > Nix is the ultimate expression of this abandonment of the concept of a desktop distro. NixOS deliberately avoids having global/implicit 'system' libraries / configured state, and instead demands declarative expression of the system configuration. -- The libraries the system uses don't adhere to a global FHS structure. Nix similarly eschews use of global/implicit libraries. Building each package requires its dependencies be declared. However, it's incorrect to say this is "just containers". I don't see how you get "abandonment of concept of desktop distro" from "doesn't have implicit system libraries". -- NixOS allowing the whole system configuration starting from a single file is convenient, and something people might otherwise use a tool like Ansible for. That said, NixOS obviously has many use cases which have significantly higher friction compared to more typical systems. (And a steep learning curve to overcome that friction). -- e.g. on Arch or Ubuntu, the system configuration is global and malleable.
  - 4y ago
- colordrops 4y ago
  It would be a better solution if it had a proper GUI that auto-generated config for novice users. Until then it's too hard to use for non-technical folk.
mouse_ 4y ago
Forgive me if it seems like this question comes from a place of ignorance and misunderstanding; it probably does. Why can't we just static link everything, and distribute binaries like we're on win32?
- whoisthemachine 4y ago
  That exists - https://appimage.org/ https://appimage.org/.
  - oynqr 4y ago
    Appimages are not statically linked at all.
    - Infernal 4y ago
      While not statically linked necessarily, app images do attempt to bundle dependencies such that they “just work” as self-contained executables on most Linux distros - which is what the poster above seems to care about.
      - rewgs 4y ago
        Which causes the aforementioned ballooning storage issue.
        Infernal 4y ago
        The ballooning storage issue was mentioned along with Flatpak, and is an issue as every single dependency is pulled in. AppImage excludes those dependencies which are "reasonably expected" to be on any Linux system. See the Application Sizes section here: https://askubuntu.com/questions/866511/what-are-the-differences-between-snaps-appimage-flatpak-and-others#1009061 https://askubuntu.com/questions/866511/what-are-the-differen... Example: LibreOffice download size (source) - AppImage ~248 MByte - Snap 463 MByte [July 2020 update] - Flatpak 543 MByte EDIT: formatting
      - 4y ago
lenkite 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.
Ygg2 4y ago
> forwards compatibility longer than 3 years Maintaining backwards and forwards compatibility will cripple you as a lib developer. If you do it, your solution will be slower to change, and probably slower overall than a solution that breaks compatibility occasionally. So you get less contribution and small bus factor means this library is more likely to die.
- badsectoracula 4y ago
  On the other hand the developers who rely on your library wont need to waste time trying to play catch up with your breakage so that their programs keep doing the exact same stuff they were already doing and instead their most likely limited time (especially important for FLOSS developers, many of whom do that in their free time) will be instead put into improving what their applications actually does. In addition, even in the case the applications stop getting developed, they will keep working since their dependencies would not break and other developers can pick them up if needed, even years later. On the other hand having to pick up a project whose dependencies do not even work anymore is much harder.
  - Ygg2 4y ago
    > In addition, even in the case the applications stop getting developed, they will keep working since their dependencies would not break and other developers can pick them up if needed, even years later. In theory, yes. In practice due to Hyrum's law you'll have to reproduce bugged behavior because an application exploited a bug in your code. See for example SimCity Windows 95 compatibility story. https://arstechnica.com/gadgets/2022/10/windows-95-went-the-extra-mile-to-ensure-compatibility-of-simcity-other-games/ https://arstechnica.com/gadgets/2022/10/windows-95-went-the-... Now Microsoft could afford to buy and test a wide combination of hardware and applications to ensure future compatiblity.

smoldesu 4y ago

I agree. You've got a bit of a fatalist tone, but you're not wrong either - if Microsoft or Apple announced that they were depreciating all of their prior packaging options in favor of a QEMU image of your application, people would lose it. It's not just about performance or integration or nativeness for most people, it's about the files living in the same spot and not needing extra apps to manage a sandbox. Flatpak feels like it took the wrong lessons from the past 30 years of software distribution and turned it into a platform. I get that it has to be simplified to be friendly to newer users, but it's also a complete turnoff when you want to fix an issue or edit a config file.

quaintdev 4y ago

What do you think about Nix

superkuh 4y ago
Nix is the ultimate expression of this abandonment of the concept of a desktop distro. It doesn't even try to have system libraries. Nix gives up re: future shock. The entire OS is just containers. I'm sure it works fine if you only ever use popular software but as someone that's constantly compiling and adding little .c programs from the 'net to my bin/ having to manually create and specify the entire "system" libraries set bit by bit every time I want to compile (or run!) something is no go. Great for business use as server, bad for human persons as a desktop.
- RGamma 4y ago
  Haven't tried it but you could probably pin an env with everything you would want and then use direnv for automation. And for quick experiments there's FHS/steam-run. But yeah.. setup.
- gray_-_wolf 4y ago
  > manually create and specify the entire "system" libraries set bit by bit every time I want to compile (or run!) something is no go. I don't have first hand experience with nix, but if I would look at this statement from Guix point of view (and I assume nix will be same/very similar), this is not really true. Nothing prevents you from having a list of libraries (in a manifest). That list might be way to wide for any specific program and it can represent what you would normally have as "system libraries". You can then just invoke shell as guix shell --manifest=manifest.scm and you will be given working shell with all the libraries available. You can also just package your program using trivial copy&paste code with the same list. Sure, the dependencies will be too wide, but since you are not sending the package to upstream Guix for inclusion, no one really cares. So, is it as friction-less as "normal" distro? No (especially the "add to /bin" part). Is it as bad as "manually create and specify the entire "system" libraries set bit by bit every time"? Also no.
- rgoulter 4y ago
  > Nix is the ultimate expression of this abandonment of the concept of a desktop distro. NixOS deliberately avoids having global/implicit 'system' libraries / configured state, and instead demands declarative expression of the system configuration. -- The libraries the system uses don't adhere to a global FHS structure. Nix similarly eschews use of global/implicit libraries. Building each package requires its dependencies be declared. However, it's incorrect to say this is "just containers". I don't see how you get "abandonment of concept of desktop distro" from "doesn't have implicit system libraries". -- NixOS allowing the whole system configuration starting from a single file is convenient, and something people might otherwise use a tool like Ansible for. That said, NixOS obviously has many use cases which have significantly higher friction compared to more typical systems. (And a steep learning curve to overcome that friction). -- e.g. on Arch or Ubuntu, the system configuration is global and malleable.
- 4y ago
colordrops 4y ago
It would be a better solution if it had a proper GUI that auto-generated config for novice users. Until then it's too hard to use for non-technical folk.

mouse_ 4y ago

Forgive me if it seems like this question comes from a place of ignorance and misunderstanding; it probably does. Why can't we just static link everything, and distribute binaries like we're on win32?

whoisthemachine 4y ago
That exists - https://appimage.org/ https://appimage.org/.
- oynqr 4y ago
  Appimages are not statically linked at all.
  - Infernal 4y ago
    While not statically linked necessarily, app images do attempt to bundle dependencies such that they “just work” as self-contained executables on most Linux distros - which is what the poster above seems to care about.
    - rewgs 4y ago
      Which causes the aforementioned ballooning storage issue.
      - Infernal 4y ago
        The ballooning storage issue was mentioned along with Flatpak, and is an issue as every single dependency is pulled in. AppImage excludes those dependencies which are "reasonably expected" to be on any Linux system. See the Application Sizes section here: https://askubuntu.com/questions/866511/what-are-the-differences-between-snaps-appimage-flatpak-and-others#1009061 https://askubuntu.com/questions/866511/what-are-the-differen... Example: LibreOffice download size (source) - AppImage ~248 MByte - Snap 463 MByte [July 2020 update] - Flatpak 543 MByte EDIT: formatting
    - 4y ago

lenkite 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.

Ygg2 4y ago

> forwards compatibility longer than 3 years Maintaining backwards and forwards compatibility will cripple you as a lib developer. If you do it, your solution will be slower to change, and probably slower overall than a solution that breaks compatibility occasionally. So you get less contribution and small bus factor means this library is more likely to die.

badsectoracula 4y ago
On the other hand the developers who rely on your library wont need to waste time trying to play catch up with your breakage so that their programs keep doing the exact same stuff they were already doing and instead their most likely limited time (especially important for FLOSS developers, many of whom do that in their free time) will be instead put into improving what their applications actually does. In addition, even in the case the applications stop getting developed, they will keep working since their dependencies would not break and other developers can pick them up if needed, even years later. On the other hand having to pick up a project whose dependencies do not even work anymore is much harder.
- Ygg2 4y ago
  > In addition, even in the case the applications stop getting developed, they will keep working since their dependencies would not break and other developers can pick them up if needed, even years later. In theory, yes. In practice due to Hyrum's law you'll have to reproduce bugged behavior because an application exploited a bug in your code. See for example SimCity Windows 95 compatibility story. https://arstechnica.com/gadgets/2022/10/windows-95-went-the-extra-mile-to-ensure-compatibility-of-simcity-other-games/ https://arstechnica.com/gadgets/2022/10/windows-95-went-the-... Now Microsoft could afford to buy and test a wide combination of hardware and applications to ensure future compatiblity.