• daojones@lemmy.ml
    link
    fedilink
    arrow-up
    1
    ·
    3 years ago

    Mass containerization and alternate runtimes cannot possibly be the future of desktop apps on Linux. If this is really the direction it’s going, the future will be so shitty that we’ll all end up back on macOS or Windows.

    This posts features great complaints but really shitty reasoning. Very immature perspective on things.

    If you are so upset about it, name the perfect alternative, contribute to one, or go make one. This post barely approaches solutions and spends all of it’s time whining about the outcome of technology choices without even touching on what they would change.

  • art@lemmy.ml
    link
    fedilink
    arrow-up
    1
    ·
    3 years ago

    That’s correct. Flatpak is the present. It’s happening right now.

  • brombek@lemmy.ml
    link
    fedilink
    arrow-up
    1
    ·
    3 years ago

    There are two problems these are “solving”: API incompatibility and isolation. Both of this issues are a real problem when you want to run proprietary software.

    When you have a source code of all applications and libraries you can compile them and otherwise patch them to get things working together most of the time. This way we don’t have to worry about changing libraries that much.

    When you can trust your software you don’t need isolation. For programs like Firefox things are a bit different since it is, by default, running untrusted software and it’s sandbox will never be perfect. You can get isolation without duplicating all dependencies using process isolation (what Android does) or even using namespaces where you share your root files system but not your home directories.

    So for open source software these systems are creating more problems then solving. For running potentially malicious system on Linux I don’t think we have a good solution yet, or if we even should waste time solving it. There are better OS designs that would make this easy (Plan9, object-capability bases security, etc.)

    As for Windows the business model that MS is trying to support is vendor locking combined with licensed closed source binaries. In such case the long term backward compatibility is a must. And consequences of such models we are all aware of.

  • pinknoise@lemmy.ml
    link
    fedilink
    arrow-up
    1
    ·
    edit-2
    3 years ago

    Imo they’re right, but theres some weird (pro proprietary software) claims in there.

    If I ship an app for Windows I don’t have to include the entire Win32 or .NET runtimes with my app. I just use what’s already on the user’s system.

    Those cases are rare on windows, most apps package their own versions of dependencies just like with snap/flatpak/appimage (just not so neatly organized) and it sucks.

    Backwards compatibility is a major part of why Windows is still the dominant desktop OS.

    But thats also a major part in why it sucks and is insecure. Microsoft knows that and has started to break stuff with higher frequency too. You should only freeze interfaces when there is a consensus that there isn’t anything to be improved anymore. You can only build this consensus when you have a clear use case.

    I’d argue, that this is impossible for operating systems with desktop and all. So best you can do for backwards compatibility is to only put breaking changes in major versions and still maintain older ones. Of course that means you can’t have major versions to often and now people will complain that your software sucks because it can’t even do X.

    Microsoft does this too, but they often release a whole new product instead of version bumps. And by that they accumulate even more technical debt.

    Businesses actually care about this! They use ancient proprietary software that is critical to their business whose source code has long been lost to the sands of time.

    This isn’t a case that should be handled by FOSS developers, but by courts fining them for putting their employees, customers and business partners at risk! Running software that isn’t maintained by you or a third party is a liability.

  • mogoh@lemmy.ml
    link
    fedilink
    arrow-up
    1
    ·
    3 years ago

    There has never been a better time to ship a binary app that targets the Linux desktop. And I don’t mean targets its own bundled runtime; I mean truly targets the user’s runtime environment. The time is now.

    I have my doubts. If I compile something for Linux today, I don’t believe the chances are great, that this binary will run on an arbitrary Linux.

    If that is true, am I able to download some binaries from any distributing package repository unpack it, and run it? Can I just run an Arch-Linux KCalc and run it on an Ubuntu 20.04? Will it be able to run in 25 years?

    I think this is the one thing that those package managers will be able to solve.

    I understand the critics, but I do not see an alternative as of now.

  • Dessalines@lemmy.ml
    link
    fedilink
    arrow-up
    0
    ·
    3 years ago

    As a user of arch btw for many years, does anyone have any link to anything that fully goes into why a lot of distros such as arch don’t have this problem? Packages, runtimes, and dependencies have been a non-issue on arch (and I’m sure other distros with proper package managers) for a long time.

    • pinknoise@lemmy.ml
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      3 years ago

      If you use your distro’s up-to-date built and packaged from source applications it’s unlikely you’ll have a problem. Those start when you want to use old packages or packages from a different distro (with different or patched libs) with your system.

      Flatpak, AppImage etc. packaged apps will run on (almost) any system and you only need to build them for different processor architectures. So it’s the ovious choice for lazy or profit oriented developers.

    • pingveno@lemmy.ml
      link
      fedilink
      arrow-up
      1
      ·
      3 years ago

      Dependencies can absolutely be a problem. Let’s say you have a Python program that relies on an older version of a package due to a breaking change. With Arch those packages are installed in a per-Python interpreter global namespace. So if two applications have conflicting version requirements for a package, you’re kind of screwed. Yes, there are ways around the issue, but it’s not customarily used in Arch.

      This is just not a problem with Flatpak. The dependencies can be installed directly with no fears about causing a conflict. Even if the Flatpak itself uses a runtime, that runtime allows the Flatpak to add its Python dependencies as a simple layer on top. This happens independently of any other Flatpaks.

      • M500@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        3 years ago

        That’s the main thing I don’t like about app images. It is just like windows where everything needs to be updated independently.

      • M500@lemmy.ml
        link
        fedilink
        arrow-up
        1
        ·
        3 years ago

        That’s the main thing I don’t like about app images. It is just like windows where everything needs to be updated independently.

      • poVoq@lemmy.ml
        link
        fedilink
        arrow-up
        0
        ·
        3 years ago

        Flatpacks don’t update themselves either, you need a system service to do that. Something similar exists for Appimages, called AppimageUpdate without requiring an appstore for it.

        • daojones@lemmy.ml
          link
          fedilink
          arrow-up
          1
          ·
          edit-2
          3 years ago

          AppImages don’t integrate into the system at all and AppImageUpdate sucks.

          Also flatpak update go brrrr