back to article The rocky road to better Linux software installation: Containers, containers, containers

Linux cross-platform packaging format Flatpak has come under the spotlight this week, with the "fundamental problems inherent in [its] design" criticised in a withering post by Canadian software dev Nicholas Fraser. Fraser wrote in a blog published on 23 November that "these are not the future of desktop Linux apps," citing a …

  1. msobkow Silver badge

    Personally I disagree with the whole concept of "vendor neutral" packaging for most of what I use on a system. I need the database as close to the metal as possible for performance. I need everything as close to the metal as possible for that reason. The ONLY thing I use snaps for are tools like Netbeans, where performance isn't an issue.

    Call me old school (and I am), but I cut my teeth doing things like getting the perversion of Oracle 6 running on a Netware server... I do NOT like having things "just happening" without me knowing about it and having control over whether that default is applied or not. :)

    1. el_oscuro

      Hold my beer. I had the fun of troubleshooting a Oracle6 installation on WFW 3.1, running in real mode. Apparently a requirement of Oracle 6 on DOS. Both Windows and Oracle were flaky and I spent hours troubleshooting. Finally, I tried to resize the virtual memory file and it BSOD, nuking the entire filesystem with it.

    2. Anonymous Coward
      Anonymous Coward

      > Personally I disagree with the whole concept of "vendor neutral" packaging for most of what I use on a system

      Agreed. I've been packaging software for a certain distro, on and off, for the last 16 years, and I believe that the premise of projects like flat pack and so on is on the whole misguided.

      There is work to do on certain aspects of dependency-based packaging (RPM is what I'm familiar with) but some of those are issues which are hard at a pretty fundamental level, in terms of theory of computation.

      Also, packaging and development are two separate processes. It's certainly nice when the devs work with ease of packaging and distribution in mind but that's by no means a requirement. We'll figure out a way to ship your software, however much cursing might be required.

      I thought the article was going to talk about the security model of Linux executables and compartmentalisation via cgroups or such, which is indeed a more worthy issue to address.

    3. W.S.Gosset Silver badge

      I'm a bit late to the party so you might not see this, but:

      > I need the database as close to the metal as possible for performance.

      If you find yourself in future wanting VM flexibility, I unreservedly recommend Xen.

      3% penalty to the bare metal, for Linux on Xen using their drivers.

      !!

  2. Lars Silver badge
    Coat

    At least there are lots of words in this article.

    1. Anonymous Coward
      Anonymous Coward

      Lots of right words, just not necessarily in the right order.

    2. badflorist

      Hidden deep are the words...

      "... the benefit that you can install most of them side-by-side on the same OS..."

      Sums up the article.

    3. -v(o.o)v-

      It was an *excellent* article!! Hoping to read the next one soon.

      El reg needs more of this kind of original content instead of just regurgitating press releases and other news sites.

      Bravo to the writer!

  3. Anonymous Coward
    Anonymous Coward

    From the article,

    In comparison, installing software on Windows is easy. Download an installer, run it, and you have a new app. The snags are that it means trusting unknown binaries from the internet – and that it teaches Windows users that this is fine and a perfectly normal thing to do.

    Er, MS did introduce signed applications, where Windows will show you confirmation of the signature before the installer runs. It'll also make it clear if you're installing something that isn't signed. So there's no excuse for unknowingly installing software from an unknown or spoofed location. Furthermore with Windows networks you can enforce practising of safe hex at the domain level.

    All bets are off if you download, compile and run unknown source code, but that's true of anything including Linux.

    Impossible Goal with RedHat in Control Of So Much

    From other El Reg articles that cast a poor light on the state of Gnome and the ever-changing state of the GTK libraries, it seems to me impossible to have a sensible, sane installation mechanism on Linux distros that use it. If you can't count on the host OS and desktop having stable APIs, there's no choice but for an app to provide its own versions of the API libraries and rely on the lowest common denominator - the Linux syscall API (which Linus is famously fastidious about not breaking) and glibc.

    Sure, other distros don't use Gnome / GTK, but then if they do achieve a sane installation mechanism it's only a partial win, because other distros do use Gnome.

    1. AndrueC Silver badge
      Unhappy

      Windows installers do generally work well and yes the signing system is pretty secure. The problems are really on the developer side.

      * Where to install to: Program Files\, Program Data\, AppData\ ? All have good and bad points.

      * To MSI or not to MSI. Great for Sysadmins but impose restrictions on what an installer can do that can be a nuisance for the developer.

      We have yet find a standard way to install our software. It seems like almost every IT department we encounter needs it to be done differently.

      1. Anonymous Coward
        Anonymous Coward

        I guess a lot of it depends on the toolset one is using. My limited experience of creating windows installers is with Visual Studio, which seems to make it easy to build a number of different installer configs within a solution. Though I've never liked the idea of software installing itself into Appdata... In the old days installers would prompt for an installation location.

        I've also noticed that Office seems to have two separate and incompatible installation styles. I'm not sure hy Ms have chosen to do that.

        One thing I am impressed by is that really quite elderly software with an installer still seem to install quite cleanly on Windows. The days of DLL hell are a long time ago...

        1. AndrueC Silver badge
          Meh

          We use the Wix toolset. I wouldn't say it was difficult per se just somewhat unpleasant due to its use of XML. The real headache isn't the toolset so much as having to maintain multiple configurations to generate different installers or implement alternative logic paths for the installer.

          It may be the nature of our market which is the NHS but we have sites where individuals can install their own software. Sites where a nominated person installs. Sites where installation can be via our Web front end and sites where a multi-site supporting IT department (or NHS Digital itself) impose various restrictions on us.

          And once you've got it installed you have to consider how you're going to push updates. Or pull them. Or send the IT department a package for them to roll out.

          It's a minor but ongoing nuisance for our development team and impacts sales and support departments as well.

        2. Charles 9 Silver badge

          The reason for Appdata/Local is that there's no Windows-standard way for a user to install his/her own programs in a user-specific way. I generally create a Programs subdir off my user directory, but it's not a universal convention. Appdata/Local is the closest analogue to a directory that exists for every user and is specific to each user.

          1. Stuart Castle Silver badge

            While AppData/Local is often used to install programs to a user's folder, I'm not sure that's it's actual purpose (although IIRC, Teams does install itself there, so I could be wrong, but that wouldn't be the first time Microsoft broke their own guidelines).

            I thought that folder was to give Applications somewhere to store user specific data that doesn't need to roam from machine to machine in an Enterprise environment. Things like caches. After all, as a Domain Admin, you aren't going to want your users clogging up the file servers with multi gigabyte profiles, and as a user, you aren't going to want to wait 10s of minutes to log in or out while your data is copied to or from the file server.

            1. Charles 9 Silver badge

              It definitely Not the Intended Purpose, but it's also The Best Option Available. Microsoft at the time hadn't thought of the idea of installable programs just for one given user.

      2. -v(o.o)v-

        There is only one directory for programs. The two others are abused. The reason is that users don't install software ffs! Luckily it can be enforced with AppLocker.

        As for MSI, what restrictions do they have?

        1. AndrueC Silver badge
          Boffin

          I think I mis-phrased that. I'm only peripherally aware of our installer but I know that we build both an .EXE and an MSI because some sites need one, other sites need the other. I can see that large sites will want an MSI because it makes it easier to roll it out but I confess that I don't know why we continue supplying EXEs. It be related to our update process. I vaguely recall that an MSI is incompatible with our update process for some reason.

          There are some other thoughts here. This comment seems interesting:

          "An msi could check for required software, it would just be a bit more complicated to code. Depending on what tools were used to make the installer, the Setup.exe can be generated automatically by some of MS's development tools, making life easier for the coder."

          Also this:

          "A single MSI file can only have one single locale for the install wizard (details).

          This can be a reason for distributing an app as .exe, which is more flexible.

          So, if the language of the install wizard is important, you might have better luck with the .exe"

    2. nijam Silver badge

      > So there's no excuse for unknowingly installing software from an unknown or spoofed location.

      Except that Windows users have been trained to do so for years. By MS.

  4. Ian Johnston Silver badge

    My biggest issue with snaps and flatpaks - both of which I keep off my computers - is that they don't update dependencies unless the maintainer tells them to, Which the maintainer rarely does, and who can blame them? Instead of updating just their bit in the knowledge that all the libraries used will be updated as and when bugs show up or improvements are possible, the poor sod(s) have to keep an eye on everything.

    Here, for example, is the list of dependencies for Chromium, snappage of which is why from Ubuntu 20.4 is why I am sitting resolutely at 18.04:

    Depends: libasound2 (>= 1.0.16), libatk-bridge2.0-0 (>= 2.5.3), libatk1.0-0 (>= 2.2.0), libatspi2.0-0 (>= 2.9.90), libc6 (>= 2.27), libcairo2 (>= 1.6.0), libcups2 (>= 1.7.0), libdbus-1-3 (>= 1.9.14), libdrm2 (>= 2.4.38), libexpat1 (>= 2.0.1), libgbm1 (>= 17.1.0~rc2), libgcc1 (>= 1:3.0), libglib2.0-0 (>= 2.39.4), libnspr4 (>= 2:4.9-2~), libnss3 (>= 2:3.22), libpango-1.0-0 (>= 1.14.0), libwayland-client0 (>= 1.0.2), libx11-6 (>= 2:1.4.99.1), libxcb1 (>= 1.9.2), libxcomposite1 (>= 1:0.3-1), libxdamage1 (>= 1:1.1), libxext6, libxfixes3, libxkbcommon0 (>= 0.5.0), libxrandr2, libxshmfence1, libxtst6, bash (>= 4), libx11-xcb1, xdg-utils, chromium-codecs-ffmpeg-extra (= 95.0.4638.69-0ubuntu0.18.04.1) | chromium-codecs-ffmpeg (= 95.0.4638.69-0ubuntu0.18.04.1)

    Maybe a large project like Chromium can keep an eye on all of these and update as required, but smaller ones can't and won't, so my computer would fill up with increasingly out-of-date and vulnerable libraries.

    1. Oczhlan

      Try building Chromium from source. You'll need to download 1 GiB of source code to build a 80 MiB program. lolz

      1. Mike_R
        Linux

        > Try building Chromium from source.

        Or Google how to install the binary from a Debian repository

      2. tp2

        chromium build tree didn't seem to work with all versions of ubuntu, given that only LTS versions are supported, and chromium simply fails to build if you have anything more modern.

  5. karlkarl Silver badge

    I had to install ntfs3g (FUSE) on a 4 year old Mac OS X install the other day. Nothing worked, the whole process was terrible.

    Did it on Linux in a couple of seconds.

    The ad-hoc installer approach on macOS is absolutely terrible. In Windows it oddly works quite well (though cleanly uninstalling is impossible). Linux is infinitely ahead of the game here. Actually the game is moving in the incorrect direction entirely.

    The only thing that beats traditional Linux package management (in terms of maintenance) is possibly ports collections (like Portage, FreeBSD ports, AUR). This gets the benefits of distributed (from the vendors website) *and* the benefits of platform specific patches.

    We have been faffing with computers for over half a century now and we have solved very little. Granted scum like Microsoft and Apple have been holding back the industry for decades.

    1. Falmari Silver badge

      Cleanly uninstalling is impossible

      @karlkarl “In Windows it oddly works quite well (though cleanly uninstalling is impossible).” Can you elaborate on why cleanly uninstalling is impossible?

      I have written a lot of install packages for Windows using MSI with either InstallShield or WIX. I have always been able to cleanly uninstall both files and registry entries.

      1. Adam Azarchs

        Re: Cleanly uninstalling is impossible

        It's certainly possible to make an uninstaller that will cleanly (as in completely) uninstall an application, but it isn't especially common. Most apps' uninstallers will leave some files or registry keys lying around in the hope that the user will some day reinstall the app and want their customized settings to remain. Either that, or just negligence. The issue, I think, is that nothing _forces_ apps to uninstall clearly, and perhaps more to the point nothing forces apps to have sufficiently hermetic runtime behavior to prevent them creating garbage in all kinds of places that the uninstaller doesn't know to look. That later problem is of course not unique to windows; my Linux home directory is littered with .files from programs I've tried out once and then removed.

      2. Jon 37 Silver badge

        Re: Cleanly uninstalling is impossible

        If you have a whole-system installation, used by multiple users, you can't delete all the per user settings in your uninstall.

        Though that applies to Linux as well as Windows.

        1. Anonymous Coward
          Anonymous Coward

          Re: Cleanly uninstalling is impossible

          Speaking for Linux, which is what I'm familiar with, technically you can (it's a matter of scanning user home directories for your config in postuninstall), but we do not tend to do it.

          And yes, it is something that causes the occasional issue when $USER has a config from version 0.0.5 and years later version 37.9rc2 is installed. That's a developer responsibility though, as a defensive programming approach will dictate that you contemplate the possibility of previous configuration data being found, as well as pure file conflicts (e.g., someone is using the same config file name as your application).

        2. Richard 12 Silver badge

          Re: Cleanly uninstalling is impossible

          An uninstaller that's able to uninstall from the all-user install location (program files) can easily remove per-user settings and cache from all users on that machine.

          However, toolsets like Wix will only automatically rollback/uninstall stuff the installer itself installed. You have to manually tell them about any stuff the application will create - obviously.

          Most don't bother.

          The bit I don't know is how that interacts with roaming profiles. Quite likely they would put it all back.

          Roaming profiles are both brilliant and utterly horrific. So many applications put huge cache or even machine-specific things in them. We don't use them anymore, it caused too much trouble.

          1. Falmari Silver badge

            Re: Cleanly uninstalling is impossible

            @Richard 12 “However, toolsets like Wix will only automatically rollback/uninstall stuff the installer itself installed. You have to manually tell them about any stuff the application will create - obviously.

            Most don't bother.”

            Exactly Richard 12 you must add steps to the uninstall to remove files created after the install.

            Unlike most I have to bother. Because QA will test the installers installs/uninstalls and fail it if files are left behind. So, I test my installers installs/uninstalls.

    2. rcxb1

      <blockquote>The only thing that beats traditional Linux package management (in terms of maintenance) is possibly ports collections (like Portage, FreeBSD ports, AUR). This gets the benefits of distributed (from the vendors website) *and* the benefits of platform specific patches.</blockquote>

      You can do that on Linux. SRPMs include the upstream source, but you could easily exclude that and download from upstream with spectool, before building into the binary RPMs needed.

  6. thames

    The origin of Snaps

    Snaps are a spin-off of the Ubuntu Phone project. They were the app format for the planned phone app store. Ubuntu Phone was abandoned (although it lives on unofficially) not because of any technical issues. Canonical came to realize that the real barriers to market entry were the business partnerships that were required with critical app vendors (Facebook, Twitter, and the like) and the lack of negotiating leverage that a small vendor had with them.

    The Snap format was then resurrected and repurposed to solve a different issue, which was the widespread use of PPAs as a distribution format, something they were never intended for but which application makers were doing anyway. Ubuntu resolved this by steering PPA users to Snap instead. As a result it's been a while since I've seen anyone instructing people to "install this PPA to get my application".

    I don't think that Snaps will ever replace normal debs for most applications, nor are they intended to. They are however intended to provide a viable option to developers who want complete control over their application packaging and deployment, such as proprietary game developers or Firefox. They also let people publish their own apps that haven't made it through the long process involved in getting into the Debian repos.

    The reason that the project to develop a Snap store independent of Ubuntu's died was due to lack of interest. They realized that without a centralized search, rating, and recommendation system there wasn't a good way for people to find Snaps unless they were already really popular, and if they were already really popular then the distro was probably packaging them through the regular means anyway.

    1. slimshady76

      Re: The origin of Snaps

      Thanks for the historical racconto. I agree with you, what's wrong with .Deb packages? They create a dependable build chain, declare their dependencies in a clear way, minimize downloads and disk usage, and most of the folk building apps know the way to deliver a functional installer in the format.

      If anything, RedHat diehards have issues bringing newer versions of apps to their side, but Debian users are familiar with alien and how to de-rpm a YUM package.

      But as others have said before me, the real cancer of the Linux desktop is gnome. A lot of the so-called "standards" (not even honored by the gnome team) these overlaying package managers are trying to adhere to stem from gnome and it's ridiculously eccentric principles.

      I'm still holding a candle to Budgie desktop, although after re-merging with the Solus project they have been silent. Hopefully the world kick-starting again will infuse a new life to the project and we would have a better alternative to the gnome/kde duality.

      1. thames

        Re: The origin of Snaps

        Snaps solve a particular set of problems. If these problems aren't ones that you have, then Snap isn't something you personally need.

        • How to create a package that works across multiple distros and multiple distro releases without going through the time and effort of creating and testing multiple different combinations of dependencies.
        • How to release a package that doesn't have to be released in sync with each distro you support but instead is.updated on a schedule that suits the developer.
        • How as a user to be able to download and run a package that you are fairly confident has limited ability to access resources on your PC that it shouldn't have access to. Examples here being proprietary games.

        The main target for Snap is proprietary software and software that is released on Linux but whose major market is Windows. For the average person using Linux on their desktop or running a web or mail server their really isn't any advantage.

        However, not every available feature has to be a feature that you will personally use provided someone else has a use for it. I have some VMs set up to test software and always uninstall Snap because I need to control the update process since I roll back the VM before each test. It's not a problem, as you can uninstall Snap just like you uninstall any other default package that you don't need.

        For a few releases Ubuntu packaged the calculator as an example of a snap. It instead ended up being a good example of why everything shouldn't be a snap. It was very slow on start up, due to having to drag its own chain of dependencies with it. I used to uninstall the default version and re-install the non-Snap version whereupon it would load almost instantly. They ended up binning the Snap version as it was a poor advertisement for Snap.

        1. Ian Johnston Silver badge

          Re: The origin of Snaps

          How to release a package that doesn't have to be released in sync with each distro you support but instead is.updated on a schedule that suits the developer.

          And that's the problem, isn't it? Because you end up with outdated, buggy and vulnerable libraries which only get "updated on a schedule that suits the developer" of an application, not when the maintainers of the libraries decide it needs done.

          1. Anonymous Coward
            Anonymous Coward

            Re: The origin of Snaps

            Furthermore, you don't need to wait for the next distro release if you really want a newer version of your app.

            We'll usually package stuff soon after it is released. You can then grab it from the development repos, with no guarantee of consistency with other things you have installed.

            Another option may be to use a rolling distro.

          2. Charles 9 Silver badge

            Re: The origin of Snaps

            Well. you can't have it both ways. Jumping the gun may prove problematic, too, as newer versions have a disturbing tendency to break things that depends on older, now-deprecated behavior. Given the choice, I say let the developer (who at least knows what versions of what they're using) say when.

      2. Anonymous Coward
        Anonymous Coward

        Re: The origin of Snaps

        > But as others have said before me, the real cancer of the Linux desktop is gnome

        I enthusiastically share your intense dislike for gnome but I'm not sure how that is germane to a discussion about package management, which occurs on an entirely different level. Please could you clarify?

        1. slimshady76

          Re: The origin of Snaps

          See a comment on the installers thread, above this one. TL/DR: Gnome libraries set the standard which in turn inposes some other restrictions on the rest of a distribution's packaged apps.

  7. Henry Wertz 1 Gold badge

    Ugh

    Snap. Ugh. 1) It starts pulling down huge updates whenever it feels like it, even if you are on a low-speed connection. Forced updates and no way to hold back an update. 2) The bigger problem, the few I tried were broken -- the attempt to sandbox one kept it from being able to access my home directory... then after I persuaded it to do that it could literally open files from my home directory, but nowhere else (I want to load a file from a USB stick or something? Too bad!) Another was supposed to use OpenGL but was unable to successfully do so. And this was Snaps (made by Canonical) on Ubuntu (made by Canonical), so forget using it on some other distro if it's that screwy on the primary distro.

    FlatPak? Sounds like, from a practical matter, it's essentially running a parallel package manager -- the FlatPak depends on other FlatPaks to provide base libs. I saw it pointed out that you may already have Gnome, but you install one copy of Gimp and it install's another copy of Gnome using Fedora's FlatPaks; another package will install ANOTHER copy of Gnome using freedesktop.org's FlatPaks. I mean, if it works maybe that's OK but it sounds like it could get a bit out of control pretty easily.

    I ran an app or two as an AppImage, and that actually did work OK. They don't get cutesy with sandboxing, just blob up the libs and junk into a .AppImage file. To be honest the only one I've tried is rpcs3 (PS3 emulator), but it acts just like a "portable" Windows app... you download it, you run it, and it works. If you want a newer version, download the newer .AppImage and run that instead. But I've seen plenty of complaints about this format too, since just like FlatPak and Snap it's including libs that are already on your system,. Primary complaint being apps that should match your desktop theme may not since the AppImage will be looking for whatever theme it may have within the AppImage file itself.

    I've also heard these are all a bit of a PITA to package, to the point that some people "drank the Koolaid" and thought they should definitely ship an AppImage, FlatPak, or Snap, but could not sort out how to get their package to do so. Apparently this is not a terribly easy process.

  8. Jason Hindle Silver badge

    On a technical level, this

    “ if files in different Flatpaks are identical, OStree can reduce duplication by hard-linking them together… although in principle, a smart enough filesystem could do the same at the block level.”

    Though I’m happy with the Apple approach of putting all resources the app needs in a single directory. I can live with the duplication. I still bear the scars of early Windows where you didn’t know what shit an install was littering your file with and what that might (sometimes quite subtly) bork.

  9. _LC_ Silver badge
    Headmaster

    Containers

    When trying to install new software (such as VLC, for example) onto an older - stable - system, you'll find that it won't work due to unmet dependencies. The joke is on you. ;-)

  10. LordHighFixer
    Linux

    And people wonder

    Why I am migrating back to Slackware after years of using all of the others. Sure, I occasionally have to drag an app through the seven circles of dependency hell, but for the most part, it is just:

    configure ; make ; make install

    Everything else just works, (including VLC) and no systemd, as a bonus.

    1. Anonymous Coward
      Anonymous Coward

      Re: And people wonder

      > after years of using all of the others.

      Have you really used *all* other Linux distributions out there?

      If not, perhaps it would be more helpful if you explicitly listed the ones you have experience with and the extent thereof.

  11. cornetman Silver badge
    Headmaster

    "Not Invented Here"

    Never really understood the term, since clearly the point of it is that it *is* invented here.

    Must come from the same shop as "I could care less" which also makes no sense in the context in which it is usually used.

    1. Throatwarbler Mangrove Silver badge
      Linux

      The point, in the Linux context, is that developers keep reinventing the wheel because they can't be arsed to learn an existing toolset or believe that they have found a new and superior approach which justifies throwing out all the work that other developers have done.

      1. boblongii
        Flame

        Can we drop this "reinventing the wheel is a waste of time" trope, please? Reinventing the wheel is how you get better wheels.

        You know that gag about how we went to the moon in 1965 but we didn't have wheels on suitcases until 1996? That's because 1965 wheels weren't up to the job. Materials have advanced. Manufacturing has advanced. And that let us invent new types of wheel.

        If you don't like reinventing the wheel, then go back to cutting the end off a log when you need to drive somewhere.

        And don't get me started on axels!

      2. cornetman Silver badge

        I understand what it means.

        It just puzzles me that it seems to say the exact opposite of what is actually meant. Just like the other quoted example. Perhaps it would be better to have said "always invented here". At least that would make some sense.

        1. Charles 9 Silver badge

          Seems clear enough to me. I've always read it as, "Not Invented Here. I Don't Give A Damn About It." They insist on control, they don't trust outsiders, or some other reason.

          1. Anonymous Coward
            Anonymous Coward

            Yes, I think of it as:

            [That other solution was] not invented here.

            In other words professional ego (either individual or at the institution level) won't allow me to acknowledge that someone else did a good (enough) job and so I will reinvent what they did, with a slight twist which enables me to claim that I'm not simply copying.

    2. PerlyKing Silver badge

      Re: Not Invented Here

      I always understood it to mean, "I'm not going to use X because it was Not Invented Here. I'll write my own instead."

  12. EddieC
    Pint

    Minutes rather than seconds?

    That would be a positive feature for me, at my age I need more loo breaks.

  13. steelpillow Silver badge
    Unhappy

    ROX

    Sad that ROX never made it to the bigtime. Drag-and-drop app installation was a feature of Acorn's RISC OS that ROX (RISC OS on X) tried to bring to Linux. The "Not invented here" turning of backs was deafening. Shame.

    1. bigtreeman

      Re: ROX

      Thanks for the history, I have used Rox filer for a long time, preferred file manager and desktop skin usually over jwm, light and fast.

  14. Kevin McMurtrie Silver badge

    The obvious

    Dependency managers suck. They haven't evolved fast enough to keep a big modern systems running smoothly. FlatPak, Snap, and other bundles are workarounds, not solutions. I personally hate Snaps because they're huge, update inconsistently, have poor visibility of potentially insecure bundled libraries, and their security sandbox is more hassle than protection.

    Dependency management is difficult and risks becoming sprawling tech debt. I can't think of any Engineering teams with the resources to build a great one without corporate profit biases. I'm sure Google could fart one out in a year if it was thoroughly crafted for Google Cloud integration. Oracle could outsource it if it had usage fees.

    1. Anonymous Coward
      Anonymous Coward

      Re: The obvious

      I can't talk for every package manager (or more specifically, dependency solver) out there, but within my narrow field of experience the issues I've been seen seeing in the last few years are not with the solvers, which are pretty good, but with the dependency data that we, the packagers, use to describe the satisfiability conditions. Sometimes we miss dependencies, sometimes we add the wrong ones, sometimes we give too many and sometimes we give conflicting ones.

      Package building tools help us catch quite a few of those but others require human judgement.

      At the end of the day there's (almost) no magic behind it, just a lot of people toiling away trying to do the right thing and not always succeeding.

      I apologise if the result of our work does not meet with your approval.

  15. Anonymous Coward
    Anonymous Coward

    What about the environment?

    I appreciate that these packaging formats are mostly used in desktop Linux, but the server counterpart, Docker, is essentially the same thing. Desktop Linux is tiny, server Linux is huge.

    Data transmission and storage does have a cost and in the aggregate it may be significant.

    Should we really be pushing around gigabytes of data (for a single package for a single user) when megabytes or kilobytes would do? This may not be bitcoin we're talking about but surely every bit (and every byte) counts.

    1. stiine Silver badge
      Happy

      Re: What about the environment?

      Do you mean we should return to patching binaries instead of replacing them?

  16. Anonymous Coward
    Anonymous Coward

    From the linked article

    "A major goal of most of these technologies is to support an “app store” experience"

    I don't understand. Linux software installation is based on the repository concept, "app store" being merely a marketing name for it.

    If the author is talking about monetisation, I still don't see what prevents you from having a regular RPM or what have you repository with a payments / donation mechanism.

  17. Robert Grant Silver badge

    > Naturally, because of the rampant Not Invented Here Syndrome of the Linux industry

    It's not NIH when it's just competition between different parties. There's no Linux industry, except in the sense that, say, there are different databases in the database industry. Rampant NIH in everyone not using Oracle!

  18. CrackedNoggin Bronze badge

    Maybe just a few major apps - a couple of browsers and an IDE, is about the limit. Anything less important just can't pay for itself in terms of the memory it takes.

  19. bigtreeman

    Debian

    Only one mention of Debian ?

    Debian packaging has worked for decades, with improvements along the way,

    but not changing how you can use it, apt, aptitude, synaptic ... etc

    You might infrequently suffer dependency hell,

    security updates have always been a breeze

    apt install package, apt purge package ... just works

    maybe apt should be ported to all other Linuxes

    (WARNING flame bait ;) why would anyone use another Linux

    1. Richard 12 Silver badge

      Re: Debian

      The elephant is commercial software.

      Commercial software needs to ship closed binaries, with some form of control over who downloads them and/or runs them (be that login, hardware dongle or online one-time validation).

      That creates a lot of compatibility complications.

      It also creates a testing issue. When there are contracts (and often lots of money) involved, customers have rather higher expectations that something is going to work.

      You can get away with it never working when it's a massive bespoke government system, but not when it's tens of thousands of small customers.

      1. Adair Silver badge

        Re: Debian

        I may be exposing myself to ridicule here, but as far as I know the .deb package format doesn't prevent 'closed binaries', it's just not the way things are generally done.

        My experience of debs over the last fifteen years is that, with literally one or two exceptions from years ago, they 'just work'. I know that is because people behind the scenes do 'the work' to make sure the repository does 'work' - but surely that's the point: it's a system that works.

        I know some wish there was some platform/distro agnostic way of packaging software so that developers can have an easy life, but it's a holy grail quest. There is always going to be some reason why there is an exception that has to be allowed for, and so the work has to be done to allow for it, etc.

        Reality bites.

  20. Chronos

    "Just Works™"

    Apple has a huge advantage here: With both their hardware and software, they choose for the user. That's not how most of us "roll" and anyone using GNU/Linux seriously will eventually have software installed from various sources, all quite manageable after the initial pain of getting repos added, versions matched, deps installed, cmake behaving etc.

    This is not to denigrate Apple's ecosystem; for some people I have no doubt it works very well. Equally, GNU/Linux will be unsuitable for many of those same people and more. The point is there's no "one size fits all," even within those ecosystems. Proudly proclaiming the "One True" anything is a hiding to nowhere. Every time I see a "this is the future" op-ed I know anyone without tunnel vision will be shaking their head by the second paragraph.

  21. Ross 12
    Unhappy

    Confusing mess

    The problem I have with this is that after years of singing the virtues of 'just apt install it', there's now this confusing mess of packages, snaps and flatpaks.

    Just the other weekend I got round to guiding my boyfriend through his first linux install. Ive been a linux geek since the RedHat 5.2 days whereas he's a capable power user and graphics bod, but not an OS geek.

    So I advised on Ubuntu 21.10 - it was running on my machine with no problems after all. Perhaps I should have opted for the LTS release but I figured that this was to explore, not installing a safe daily-driver.

    After the can of worms that was not having an appropriate wifi driver, we dug up some old ethernet-over-power kit and got connected. So far so good.

    Then came the applications. 'How do I install Chrome?' oh... well... normally you'd 'sudo apt install chrome' (or whatever the actual package name was), but now you shouldn't do that because it installs a Snap instead and that's.. 'what's a snap?' oh.. well.. *some time later*

    OK looks like the only way to do this now then is to use firefox to go to google and install chrome from there. 'hmmm' so like Windows then?

    Then things got worse. 'Lets install Blender' I said, knowing that he uses it a lot on Windows, so it would be nice and familiar. And before I could say 'fire up a terminal and apt search blender' he'd found the cunningly named 'Software' app. Oh, I thought, this isn't going to end well.

    So we searched for Blender and there were three results. Blank stare. 'So which one do I install?' Well, I said, click on each one and check the version, see which is the latest. It was the second one. The third one appeared to be someone else's custom build. Why was it there? Was it official in any way? Was it safe? Who knows.

    So we installed the second one, which turned out to be a Snap. Installation went ok then he clicked 'launch'. And waited. 'I thought linux was meant to be fast?'. Oh, Snaps sometimes take a few seconds to start. I said. 'Why?' - I'm... not sure.

    So when it launched, it was immediately obvious that something was wrong. The whole UI was really sluggish, and this machine powered by an i9 and a 2080ti.

    Was it a driver issue? nope. We were using the latest official Nvidia driver. Hmmm.. my instinct was telling me that, being containerised, something was getting in the way of Blender and the gpu. OK, I said, try uninstalling it, and installing the other version, even though it's slightly out of date.

    So we installed the repository version and lo and behold, it ran perfectly.

    'So how do you update it to the latest version?' - well, you can't. You'll only get bug fixes with this package. Unless we try a flatpak version..

    But before we could do that, we needed to install flatpak itself. Oh and gnome-software-plugin-flatpak but that actually made things even more confusing. However, after what seemed like a life-time, we got the flatpak version of Blender installed and it ran perfectly fine.

    By this point I was exhausted and quite honestly a bit embarrassed and somewhat regretting suggesting the idea of installing linux.

    My boyfriend and I have not spoken about linux packages since.

    1. Nate Amsden

      Re: Confusing mess

      Linux user here since 1996. Your story reminded me of when I installed SuSE for a computer I let my sister use when she lived with me back in 2002 maybe? SuSE was one of the early distros to have a real slick installer and interface. I used Debian on my personal systems at the time(today use Devuan on my personal servers and Linux MATE on my main laptop).

      Anyway SuSE, linux right. So imagine my surprise when I came home one day to see her running Yahoo IM on SuSE. Yahoo from WINDOWS. I couldn't believe it. I mean she just downloaded the windows installer(she was never much into computers even now I'd rate her computer skills as entry level at best), clicked on it did the install and it worked, even put an icon on the desktop I think.

      Obviously I know all about WINE used it off and on for ~10-15 years, but was not expecting any distro to have it integrated to that level(exception may be for Corel Linux perhaps), especially back then.

      Even today I find it hard to believe. She had no idea she was installing software designed for an entirely different operating system. And the damn thing installed and ran. I was impressed, shit still am.

      Back on topic I've never used snaps or flatpacks or whatever, I immediately uninstall all of that after a system gets installed if it is there to begin with. I can imagine it has some value for some folks out there. The only containers I use are ones I've built myself with LXC (so that means no docker either). Some people get upset they can't run the latest greatest version of some software package, because the distro packaged version X to include and they want version Y because it's better(it may not even make a difference for the user they just see a higher version number and want it). 95% of the time for me I just use version X even if it is older since it is good enough, the trade offs to get to version Y aren't worth it. Snaps etc are for those folks I think.

      I gave up trying to pitch Linux as a desktop replacement probably about the time OS X started hitting it big(2007ish?). I can recall of only 1 person that I've worked with in the past 15 years that uses linux on their desktop as their daily driver(my work is generally with companies with in house internet facing website stuff so developers, server/network admins etc etc). Some run windows(mainly the windows IT staff), but seems everyone else is comfortable with Mac. I don't think I could ever use Mac, I tried it a couple times and it's just not for me.

  22. Archivist

    Experiences

    My experience with Linux snaps has been similar. Because of my job, I have 23 versions of the same app sitting in my Mac Applications folder, all of which were easily installed - with some renaming, any of which I can spring to life with a click.

    If only Linux could do that.

    1. Adair Silver badge

      Re: Experiences

      You can - appimage allows exactly the same, and without needing to rename anything, assuming they are all different versions.

  23. Anonymous Coward
    Anonymous Coward

    Register at it's best

    A good article sparking a lively discussion on important matters by dozens of well-informed punters... I learned a lot. Thank you.

  24. Anonymous Coward
    Anonymous Coward

    How do you think about GoboLinux's approch?

    Personally I love their file system hierarchy and taking package management easy (install just by copying a folder and uninstall just by deleting it)

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Biting the hand that feeds IT © 1998–2022