The more I use snaps on Linux, the more I feel like we came the full circle. Installable package (snap) contains a bundle of all dependencies, and installs them in an isolated system path to avoid version incompatibilities. Snaps can can have some sort of install-time configuration, and they create links to a handful of entry points rather than adding all executables to the path. In short, they do the exact same thing Windows installers have been doing for the past 30 years.

  • 8
    And that's exactly why I won't ever use them.

    Package management on Linux is a mess, since every distro makes their own solution, but it's a lot cleaner and better than any solution Microsoft ever came up with.
  • 1
    Isn't snap voor Debian / Ubuntu?

    I didn't like it. Check df -h. What a shit.
  • 3
    @LotsOfCaffeine Containers aren't a solution to that problem, just a dirty work-around.
  • 1
    @rooter Not really, SUSE, Fedora, Arch, Manjaro, RedHat, Kali, and many other distros have it in their package manager by default. Debian and Ubuntu just have it preinstalled.
  • 2
    @hitko And Mint has removed it. :-)
  • 2
    Agreed that snaps are a poor compromise solution to a package management problem.

    The trend on one hand is towards an ever increasing number of dependencies, making packaging more fragile. But that same increase, on the other hand, makes a solution which just glomms copies of all the dependencies together even less efficient, and even less secure.

    At some point in the future maybe we all give up and run everything and every component in their own containers, mediated by some herd of RPC protocols, but I hope that day can be deferred for as long as possible.
  • 2
    That sort of "package management" is only needed for closed source binary blobs and failed projects that are impossible to get compiled or are stuck requiring ancient libs wich have left all repos years ago.
    But for binary blobs, static linking should work. And the other cases are probably also buggy as hell - so better to avoid them altogether...
  • 0
    @LotsOfCaffeine I'll ask you about it the next time you're trying to run some legacy binary, and need to find the exact patched dependency library which apparently existed in that one distro 5 years ago.
  • 1
    @hitko legacy binary? As in a 6 year old proprietary blob?
  • 0
    @Oktokolo No, that sort of package management is needed for an average user who might switch to Linux one day if they don't have to deal with broken dependencies every time they try to use this app someone made 5 years ago and which does the exact thing they're trying to achieve.
  • 0
    @LotsOfCaffeine No, the library which was patched by ubuntu devs in Ubuntu 10.10, and replaced by another package in Ubuntu 12.04.
  • 1
    @hitko hell if I know how Ubuntu handles these things
    I've always had the impression that it was awfully difficult to run certain applications there

    Right now I'm on arch so everything I even need is in the official repo or the aur
  • 1
    @hitko Then you can maintain that starting from the old source code. Ubuntu is OSS, after all.
  • 3
    @Fast-Nop Sure it can be done. All you need is to first figure where to look for that library, then somehow extract it from the distro's repository, and place it where that program can find it. If you can do it, there's a good chance you'll spend less time just writing your own script for whatever the original binary was supposed to do.
  • 0
    @hitko Not saying it's convenient - just that it can be done, depending on how important it actually is.
  • 0
    I wouldn't mind snap, but it has this nasty feature called "auto update" that from what I can tell can't be turned off. And sometimes I'm stuck using my limited phone data internet and I'd rather if it didn't do that... at least with apt I get to actually be charge of what's in my computer
  • 2
    The average user just goes for what is contained in the distribution repo.

    I can't speak about common new user distributions - but here on Gentoo, wich surely is primarily known for its user friendlyness everywhere, i only experienced dependency problems while trying to get rotten legacy software to work.

    Snap looks like a developer cop out to me.
    They know, their app requires exotic and rotten libs and that they had to spend weeks getting the build system to sometimes work on the CI server.
    So whenever they are lucky and get hold on a binary wich does not segfault right away, they quickly put it into a snap package and ship it, before getting knocked out by the smell of their code wich certainly is still rotten...
  • 2
    Windows installer doesn't do that.

    And snaps / flatpaks are dealing with a problem MS doesn't have... Constantin API changes.

    And all in all the comparison is broccoli to strawberry.

    Hodor.... Hodor...
  • 0
    @IntrusionCM Amusing to see my favorite fruit and favorite vegetable mentioned in the same post, hah. Ironic, too, since I really dislike the whole Snappy movement and even more so the way Canonical is pushing it on users instead of letting them opt-in.

    They still can't explain why so many of the build plug-ins are full of five year old libs either, or why it's still not possible to get snaps to automatically use the same themes as my natively-packaged apps. Grrrr...
  • 2
    @RogueScholar since I was very snarky yesterday...
    Snap is ... Complicated.

    As it wants to run an isolated environment to workaround the problem of dependencies, you'll get the problem that loading or adding stuff from external might be incompatible to the isolated environment.

    They've added a nifty workaround, but didn't fix the problem.


    What build plugins?

    Most libraries are dynamically linked.

    Static linking can lead to degraded performance, but would build a binary that has all required dependencies added and can be run.

    Windows core APIs do not change and Windows provides by default certain libraries like the Visual C++ runtime so programs can run.

    If a program was built with an older version of a Visual C++ compiler, you'll need to get the Visual C++ redistributable to install the matching Visual C++ runtime for the program.

    Linux has an ever changing API - the kernel might change… the libraries adapt... Other libraries adapt to the changes of other libraries.

    (Insert circle of life music now)

    This has down sides - yes. Most build systems written 15 years ago are stuff that will give you a free ride to the looney bin.

    Eg. Checking if library's API call uses 3 arguments or 4... Is the 3 Argument an Int Unsigned 32 bit? Or an Int unsigned 64 bit? And so on.

    Reason why projects like Meson became so popular is that there are very few who "like" writing build system stuff. It's a whole world of complicated stuff. :)

    Which brings me back to the point of programs using 5 year old shit.

    Well. They don't want to have complicated build system.

    They just say: we take the oldest shit, make it run, support it.

    On Windows this works excellent.

    On Linux not.
Add Comment