1. 43
  1.  

  2. 5

    Thankfully having a top tech YouTuber destroy their OS by trying to install Steam is the extinction-level event the traditional desktop Linux needed.

    I have rarely been so glad that I avoid YouTubers, Influencers, etc. :-)

    I really didn’t have the foggiest idea of what all this was about, so I went and looked up Flatpak, then cut through the whaagghble from non-technical hype. Flatpak has a list of what they are gluing together:

    https://docs.flatpak.org/en/latest/under-the-hood.html#underlying-technologies

    which all makes a nice bit of sense if you know what’s what.

    1. 3

      I have rarely been so glad that I avoid YouTubers, Influencers, etc. :-)

      I really didn’t have the foggiest idea of what all this was about,

      The tl;dr is Linus of Linus Tech Tips (very famous channel) had a video series about committing to the Linux desktop. First distro he tried, packaging bug caused apt to blow away the core system when installing Steam.

    2. 5

      Totally agree with this post’s message. Linux desktop needs a lot of help to fix its application permission and application packaging issues (installing software as a normal user is more difficult than it needs to be!)

      1. 5

        I think this article is technically correct but in this particular case it might just not be quite the best kind of correct :-).

        There are always going to be people who romanticize “the old way” but painting all criticism of Flatpak & friends as rose-tinted glasses is one of the reasons why Flatpak is six years old and still weird – this story is, ironically enough, on the frontpage along with this article.

        (Disclaimer: I like Flathub, I think it’s a good idea, and I use it). But a half-realized idea of a better system is usually worse than a fully-realized idea of a worse system. Plenty of things break when installing stuff from Flathub and many applications there are minimally sandboxed, to the point where you might as well just install the bloody .deb if it exists. Filing all the breakage under “yeah users don’t need that” (font rendering bugs, themes etc.) or “well the next release of this particular Wayland compositor is going to support that” is the same kind of obliviousness to reality as “but Flatpak breaks the Unix philosophy”, just of a more optimistic nature.

        This leads to a curious state of affairs that’s unsatisfying for everyone.

        It’s certainly in the nature of FOSS software that things don’t happen overnight and software evolves in the open. But if you want to appeal to an audience (technical and non-technical) that’s wider than “people who contribute to FOSS desktop projects”, shipping half-finished implementations is not the way, whether it’s in the nature of FOSS or not. You can say that Linux is not a product but that won’t change the (entirely reasonable) expectation of this wider audience that it should at least work.

        Meanwhile, elitism and gatekeeping are one unpleasant aspect of romanticizing the old ways but, elitism and gatekeeping aside, I think it’s important to be realistic and acknowledge that the old way works – as in, it allows you to install applications, manage, update and uninstall applications which work as intended, to a degree that Flatpak is still aspiring to. While some people may be yearning for the days when being a package maintainer granted you demigod status in cyberspace, I think it’s more realistic to assume that most people just aren’t willing to spend the extra troubleshooting hours on a system that doesn’t always deliver even the security guarantees it’s meant to deliver, and sometimes results in a functional downgrade, too.

        Edit: oh, while we’re on the topic of rose-tinted glasses, it’s also worth keeping in mind that the goalposts have changed quite significantly since then, too. Lots of people today point out that hey, back in 2000 you’d have had to fiddle with XF86Config and maybe fry your monitor, why are you complaining about far softer breakage today? Well, sure, but the alternative back in 2000 – especially if you were on a CS student’s budget – was Windows Me (I’m being as charitable as “maybe fry your monitor” here, realistically it was probably Windows 98). You maybe fried your monitor but got things many computer users couldn’t even dream of in return, unless they were swimming in money to shed out on Windows 2000, Visual Studio and so on. The standard to beat is no longer Windows Me.

        1. 4

          and acknowledge that the old way works

          Especially true when you’re not interested in desktop but servers. I’m very happy that I know I can just apt install php apache and it’ll give me a working bundle. The same for everything built on top of this. Also debian does specify a release cycle by this. I won’t have to worry that my php 7.4 is completely outdated in the next month just because someone thought moving ahead to php 8 is the new flashy thing. No, it’ll certainly work for a long time on php 7.4 as that’s the current debian stable release. And that’s perfectly fine, I don’t have the time to upgrade all the time just because someone though it would be neat to use one feature of php8. Those “gatekeeper” also ship most of these services with very sane defaults (config, location of configs, systemd units,…).

          Yeah that probably won’t work for the new release of $desktopapp, but it works flawless for the server environment.

          No docker is not an answer. It’s a completely different way of operating stuff.

          1. 2

            But a half-realized idea of a better system is usually worse than a fully-realized idea of a worse system.

            Oh, wow, I could not disagree more strongly with this. Give me something that is functionally complete over something that is broken and half-baked but has some kind of vague conceptual superiority any day.

            1. 4

              I’ve read your comment 3 times now and I’m pretty sure you actually strongly agree with the comment you’re replying to.

              1. 3

                Damn it, you’re right.

          2. 4

            Is there anything Flatpak does better than Nix? After Debian, then Ubuntu, then Arch and now NixOS, I just can’t imagine moving to something which isn’t at least as strict, flexible and easy (really!) as Nix.

            1. 2

              Potentially not, in terms of features? But I think it’s vastly more accessible to the type of user who doesn’t want to know too much about what’s going on under the hood of their OS.

              That’s nothing against Nix, I just don’t think it’s for a non-technical audience right now.

              1. 2

                That’s fair. I should’ve specified that I was thinking more about the packaging side of things. Hence the mention of “easy”, because I don’t remember last time I learned a language which is so easy to read. It’s is sometimes hard to write, but once you have something that works it’s probably going to be much shorter and simpler than the equivalent in any other major packaging system.

              2. 2

                Documentation, probably. Last time I checked the getting started page on Nix told you to use nix-env -i to add packages, which is apparently a really bad idea and something you should never do. That’s when I gave up with it.

                1. 2

                  Nix documentation is sadly lacking. Honestly not too surprising given that it comes from an academic background, but I suspect a small handful of dedicated writers could turn that around in a few months. Not saying it’ll happen anytime soon, but I really hope it gets some traction (and some refactors to remove cruft like with).

              3. 2

                The author seems to have a lot of imagination to envision a bright future for Flatpak, saying the warts can be fixed. That optimism is oddly lacking for the future of other tools. Their main complaint seems to be that traditional packages are installed as root and can run install scripts with root’s permissions. I wish they would have explained why that is a death knell rather than a wart. It seems easy to imagine a dpkg --no-scripts and tools like apt using that flag for all but trusted repos. The author encourages us to see corporate app packagers as allies who don’t want to do anything wrong with those permissions so in theory they would also be keen to give up authoring install scripts, won’t abuse setuid, etc. That hints at some missing features of traditional package tools that have been papered over with scripts. It would probably be a better use of all of our time to discuss those detailed use cases than the frustrations of this author. Anyone who packages stuff have any specific gripes about having to write scripts that run as root?

                1. 2

                  This article was a tad bit raw if you lack context (and, some would argue, even if you do know the context :))

                  A few things:

                  • OP is Jorge Castro, ex-Canonical employee and Open source community manager (if you’ve ever landed on askubuntu.com, you’ve probably seen his avatar)
                  • He recently discussed this very topic on the Bad Voltage podcast (this episode) along with Jeremy Garcia and Stuart Langridge. Although the discussion is going very technical quite quickly, it’s still an interesting episode to listen to.
                  1. 1

                    THANK you!