How do you guys get software that is not in your distribution’s repositories?

      • SorryQuick@lemmy.ca
        link
        fedilink
        arrow-up
        7
        ·
        3 months ago

        That’s exactly what the vast majority of AUR packages do already? You can also apply modifications to the compilation process if needed.

    • hperrin@lemmy.world
      link
      fedilink
      arrow-up
      19
      arrow-down
      1
      ·
      3 months ago

      My software, QuickDAV, is not in the AUR. It’s open source, and I release it only as an AppImage, because I am lazy.

      • folkrav@lemmy.ca
        link
        fedilink
        arrow-up
        22
        arrow-down
        1
        ·
        3 months ago

        I guess we should have added the word “notable”

        I’m terribly sorry, you left the door wide open ;)

        I’m curious, what makes AppImage a good choice for the lazy developer? Is it easier to create?

        • hperrin@lemmy.world
          link
          fedilink
          arrow-up
          17
          ·
          3 months ago

          Ouch. xD

          It’s super easy to create. And you distribute it on your own, so it’s basically like an installer exe on Windows. In my mind it’s one step above only offering source code.

        • Samueru@lemmy.ml
          link
          fedilink
          arrow-up
          4
          ·
          edit-2
          3 months ago

          I’m curious, what makes AppImage a good choice for the lazy developer? Is it easier to create?

          The appimage is basically just git clone -> make -> make install DESTDIR=/path/to/AppDir -> wget appimagecreationtool and finally appimagecreationtool /path/to/AppDir and that’s it you have your appimage.

          appimagecreationtool being several tools that can create the appimage from an AppDir, like linuxdeploy, linuxdeploqt, go-appimage, etc

          And that on itself isn’t complex either, it if basically running ldd on the binary, then copy those libraries into the AppDir and finally run patchelf to patch the paths in the binaries and libraries, suyu uses a deploy script instead of using those tools, which I’ve recently forked and began expanding.

          I don’t know how easy it is to make a flatpak or snap, but I do know the dev of zen browser hates dealing with the flatpak and iirc right now the flatpak is outdated as result.

          EDIT: Also lite-xl has been making a flatpak for like 2 years and it isn’t ready yet.

      • oldfart@lemm.ee
        link
        fedilink
        arrow-up
        3
        ·
        3 months ago

        There’s so much random, useful software distributed only as appimages. But not notable enough for packaging fanboys.

    • ILikeBoobies@lemmy.ca
      link
      fedilink
      arrow-up
      2
      ·
      3 months ago

      Rpg paper maker

      Though the Linux version is now in a “do not use” state. The developer decided to just make it into a web app because it was only working on Ubuntu

      • cm0002@lemmy.world
        link
        fedilink
        arrow-up
        19
        ·
        3 months ago

        Clearly we need an Arch version of rule 34 and rule 35

        Rule 34a: If linux software exists, it’s in the AUR. No exceptions.

        Rule 35a: If linux software is not in the AUR, it will be made available in the AUR.

        • ulterno@lemmy.kde.social
          link
          fedilink
          English
          arrow-up
          3
          ·
          edit-2
          3 months ago

          I don’t intend on pushing that one to the AUR. It’s not worth it.
          Maybe I’ll make an AppImage at most.

          I don’t know any formal requirements for it being on AUR, but I just feel like this one does not fit there.

  • cley_faye@lemmy.world
    link
    fedilink
    arrow-up
    64
    arrow-down
    8
    ·
    3 months ago

    Native package manager > Native binaries > AppImage > Flatpak.

    Yes, snap isn’t even on the scale.

    • Kusimulkku@lemm.ee
      link
      fedilink
      arrow-up
      57
      arrow-down
      1
      ·
      3 months ago

      Not a fan of AppImages myself. For an universal format it has surprising amount of issues with different distros, in my experience. And the whole Windows style “go to a website, download the AppImage, if you want to update it, go to the web page again and download it again” is one thing I wanted to get away from. At least they don’t come with install wizards, that clicking through menus thing was a pain.

      For one off stuff I run once and never need again, AppImage is alright. But not being built-in with sandboxing, repos, all that stuff, it just seems like a step back.

      • InverseParallax@lemmy.world
        link
        fedilink
        English
        arrow-up
        9
        ·
        3 months ago

        They are windows, but the linux version of dll-hell across distros and distro versions makes windows dll hell look quaint.

        If someone had addressed that better it would be one thing, but binary interoperability is infinitely broken, so app image is actually an improvement.

      • Samueru@lemmy.ml
        link
        fedilink
        arrow-up
        6
        ·
        edit-2
        3 months ago

        Isn’t the gnome runtime alone 2GiB? You know how many appimages that is?

        Not to mention you are unlikely to only use one runtime.

        • Kusimulkku@lemm.ee
          link
          fedilink
          arrow-up
          10
          arrow-down
          1
          ·
          3 months ago

          Then again, loads of apps share that runtime. And if other runtimes have same stuff as that GNOME runtime, the shared parts are on your disk only once. It’s pretty smart in how it works.

          • oldfart@lemm.ee
            link
            fedilink
            arrow-up
            7
            ·
            3 months ago

            Ran out of space on a 30GB partition when trying around 10 smallish programs as flatpaks. Runtimes are shared in theory but not in practice.

            • Kusimulkku@lemm.ee
              link
              fedilink
              arrow-up
              1
              ·
              edit-2
              3 months ago

              If you allocate 30 GB for / that seems pretty low these days for a desktop system. If you don’t have much space, it’s always best to go with regular repository packages

              Here someone had 163 flatpaks and it used 8,7GB in runtimes. So I’m guessing the 30GB number is for whole of /.

              I just checked out mine, I have 34 apps and runtimes use 3,1GB

              Runtimes are shared in theory but not in practice.

              I think three runtimes (newest freedesktop, KDE and GNOME) cover 90% of my flatpaks. Then there’s programs that use some EOL’d runtime and never get updated, which sucks

          • Samueru@lemmy.ml
            link
            fedilink
            arrow-up
            5
            ·
            3 months ago

            I tested installing some web browers, kdenlive, yuzu and libreoffice and without knowing I ended up with 3 different runtimes and the total storage usage (with deduplication) was 4.79 GIB.

            Meanwhile with 33 appimages that I have (which includes same flatpak apps I mentioned) are using 2.2 GiB.

            It doesn’t matter if they share if in the end they end up using several times more storage than the appimage equivalent.

            • Kusimulkku@lemm.ee
              link
              fedilink
              arrow-up
              1
              ·
              edit-2
              3 months ago

              You should test it out with those 33 installed as flatpak. If you end up with 4.7GB for runtimes, that’s basically nothing these days as far as storage goes for that amount of programs. More you have, more you benefit from shared runtimes. I doubt it’ll be less than AppImages but it’s usually the starting runtime space use that shocks people.

              Here someone tested it with 163 flatpaks and the runtimes used 8.7GB. With the top 5 most used runtimes covering 128 of those flatpaks.

              https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/

              I just checked out mine, I have 34 apps and runtimes use 3,1GB

              It doesn’t matter if they share if in the end they end up using several times more storage than the appimage equivalent.

              Well we are talking about two gigs, after all. Unless you’re using an embedded system, it’s not a much of a concern if you ask me. But it is more, true

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

                . If you end up with 4.7GB for runtimes, that’s basically nothing these days

                Yes but that wasn’t the original comment I replied to was about.

                163 flatpaks and the runtimes used 8.7GB

                163 flatpaks using 8.7 GiB means that the average flatpak is using 54.6 MiB.

                That’s good the other time I got this linked: https://tesk.page/2023/06/04/response-to-developers-are-lazy-thus-flatpak/#but-flatpaks-are-easier-for-end-users

                Which is no good as in that example there was 173 flatpaks using 27.66 GiB, average 160 MiB, while in your case the average flatpak is using 91 MiB.


                This is what I have with appimages:

                In this case the average appimage is using 69 MiB, though there is one outliner which is the Steam appimage that I have there (470 MiB) which is an entire conty container with its own video drivers and everything, without it the average would be 56 MiB.

                I know this doesn’t matter these days but once again that wasn’t what the original comment was about.

                Well we are talking about two gigs, after all. Unless you’re using an embedded system, it’s not a much of a concern if you ask me. But it is more, true

                Thanks for the link showing an average flatpak using 54 MiB though, didn’t think it was possible lol.


                WAIT I just took a deeper look at the link, isn’t that guy just showing the runtimes without the applications using 8.7 GiB?

                • Kusimulkku@lemm.ee
                  link
                  fedilink
                  arrow-up
                  1
                  ·
                  3 months ago

                  Yes but that wasn’t the original comment I replied to was about.

                  I know this doesn’t matter these days but once again that wasn’t what the original comment was about.

                  I agree, it was just about the size differences. I just think it’s good to bring up since there’s many confused about the flatpak size use. Often people might want to install some small app and they’re hit with gigs of stuff and come off thinking that’s the same for every app, which would be insane of course.

                  WAIT I just took a deeper look at the link, isn’t that guy just showing the runtimes without the applications using 8.7 GiB?

                  Yes it’s specifically comparing runtimes. Same for my number, I was calculating how much the runtimes used.

    • skulblaka@sh.itjust.works
      link
      fedilink
      arrow-up
      8
      ·
      3 months ago

      I’m a technically savvy but new to Linux user who installed Mint as my primary OS about a month ago. So far I’ve used Flatpaks and AppImages without any issue and haven’t come across snaps. Would you explain the differences and why I would care about one over another?

      • Kevin Noodle@lemmy.world
        link
        fedilink
        arrow-up
        4
        ·
        3 months ago

        At the end of the day, they’re just different ways of reaching the same goal: universal packages for Linux. I personally use them interchangeably depending on the application and use case.

        There are some packages that definitely work better and are intended to be used and installed via your native package manager (if they rely on system libraries and whatnot). But using either a Flatpak or AppImage results in the same experience - in my experience. It’s a personal preference.

      • PotatoesFall@discuss.tchncs.de
        link
        fedilink
        arrow-up
        2
        ·
        3 months ago

        IMO flatpaks are the future of installing linux apps. The comment you replied to lives in the past. System package manager should be for system binaries, not for applications.

        • Schmeckinger@lemmy.world
          link
          fedilink
          arrow-up
          5
          ·
          3 months ago

          But I like my applications years out of date and I think its good that every distro has to spend manhours on packaging it individually.

            • Schmeckinger@lemmy.world
              link
              fedilink
              arrow-up
              2
              ·
              3 months ago

              I see the appeal for the package manager for a lot of things, but space got so incredibly cheap and fast that duplication is way less of a deal than the effort to make stuff work the traditional way. But im not a real linux user. I don’t like tinkering, I want to download something and it works. And the amazing thing is we can have both. If people like spending time to package something be my guest.

              The funniest interaction I had recently. I downloaded a program that isn’t in my package manager or had any sort of flatpack/appimage so I downloaded it as a deb and it didn’t run because of some dependency. So I could clone the git and build it from source which might have worked, but I was too lazy to. So I just downloaded the windows exe and ran it through wine, which worked flawlessly.

              • meliante@lemmy.world
                link
                fedilink
                arrow-up
                2
                ·
                3 months ago

                I don’t like tinkering, I want to download something and it works.

                And this is what’s keeping Linux at bay. Normies are that to the extreme. They want something that is as simple and resilient as possible, they couldn’t care less about the dependencies or even know what they are. They want a program an app and just install it from an “app store” if possible.

  • BigDanishGuy@sh.itjust.works
    link
    fedilink
    arrow-up
    54
    ·
    edit-2
    3 months ago

    Why not just stick to what we’ve always been doing?

    1. wget something.tar.gz
    2. tar something.tar.gz
    3. man tar
    4. tar xzf something.tar.gz
    5. cd something
    6. ls -al
    7. ./config.sh
    8. chmod +x config.sh
    9. ./config.sh
    10. make config
    11. Try to figure out where to get some obscure dependency, with the right version number. Discover that the last depency was hosted on the dev’s website that the dev self-hosted when it went belly up 5 years ago. Finally find the lib on some weird site with a TLD you could have sworn wasn’t even in latin characters.
    12. make config
    13. make
    14. Go for coffee
    15. make install
    16. SU root
    17. make install
    • merthyr1831@lemmy.ml
      link
      fedilink
      English
      arrow-up
      12
      ·
      3 months ago

      I much prefer our modern package format solutions:

      1. sudo apt install something
      2. open
      3. wtf this is like 6 months old
      4. find a PPA hosted by someone claiming to have packaged the new version
      5. search how to install PPAs
      6. sudo apt <I forgot>
      7. install app finally
      8. wtf it’s 2 months old and full of bugs
      9. repo tells me to report to original developer
      10. report bugs
      11. mfw original dev breaks my kneecaps for reporting a bug in out of date versions packed with weird dependency constraints they can’t recreate
    • PenisDuckCuck9001@lemmynsfw.com
      link
      fedilink
      arrow-up
      3
      ·
      edit-2
      3 months ago

      We should normalize programs that don’t use such exotic and impossible libraries that you have to do anything besides type “make” and “make install” for it to work.

      In theory it’s a no brainer. In practice not so much.

  • RmDebArc_5@sh.itjust.works
    link
    fedilink
    English
    arrow-up
    43
    ·
    3 months ago

    I’m currently on a atomic distro, so how I get my software from favorite to least favorite is this:

    1. Flatpak
    2. Appimage
    3. Fedora distrobox
    4. rpm-ostree
    • u/lukmly013 💾 (lemmy.sdf.org)@lemmy.sdf.org
      link
      fedilink
      English
      arrow-up
      13
      arrow-down
      1
      ·
      3 months ago

      Mine is

      AppImage > Native repos > AUR > Manually compiling from source > Finding an alternative

      I don’t like installing software that doesn’t need to be installed, thus I like AppImage. Pretty portable. That also applies to compiling from source. Yes, my home directory is a mess.

  • boredsquirrel@slrpnk.net
    link
    fedilink
    arrow-up
    18
    arrow-down
    1
    ·
    3 months ago

    Appimages are crap too, but at least there is progress with AppMan, repos and that sandboxing solution.

    Snaps are only sandboxed with Apparmor and snapd only allows a single repo (which contained malware multiple times) so get the hell off my lawn XD

  • aesthelete@lemmy.world
    link
    fedilink
    arrow-up
    16
    ·
    edit-2
    3 months ago

    I hate fucking snap. It might be enough to make me switch distros if Ubuntu keeps up with it (which I am sure they intend to).

    The continual “you have new snaps” or whatever it was message every time I’m just trying to have a web browser open made me eventually figure out how to install firefox for real on all of my computers.

    EDIT: I think you may have convinced me to try out Debian on my next OS installation.

    • hperrin@lemmy.world
      link
      fedilink
      arrow-up
      15
      ·
      3 months ago

      The Firefox snap was the reason I left Ubuntu. (Or, the last straw, at least.) Fedora has been wonderful.

    • InverseParallax@lemmy.world
      link
      fedilink
      English
      arrow-up
      8
      ·
      3 months ago

      Try debian, they improved so much over the past decade, they’re a better Ubuntu than Ubuntu now without any bullshit.

        • InverseParallax@lemmy.world
          link
          fedilink
          English
          arrow-up
          4
          ·
          3 months ago

          It used to be really outdated and missing new applications, with a kernel 1 major version behind.

          All that is fixed, they even have good support for new architectures like riscv on par with Ubuntu.

    • InverseParallax@lemmy.world
      link
      fedilink
      English
      arrow-up
      1
      ·
      3 months ago

      Make a script to extract it to /opt/local and make a symlink.

      You’ll end up using it so much and it’s an easier upgrade on your terms.

  • HouseWolf@lemm.ee
    link
    fedilink
    English
    arrow-up
    12
    arrow-down
    1
    ·
    3 months ago

    AUR or flatpak.

    Honestly the longer I spend daily driving Linux the more I enjoy using flatpaks…

  • Dop@lemmy.world
    link
    fedilink
    arrow-up
    11
    ·
    3 months ago

    Linux noob here, can someone ELI5 why snaps are bad? And how does .deb works?

    • Lettuce eat lettuce@lemmy.ml
      link
      fedilink
      arrow-up
      18
      ·
      3 months ago

      Snaps are a standard for apps that Ubuntu’s parent company, Canonical, has been trying to push for years.

      The issue that most people have with them, is that Canonical controls the servers, which are closed source. Meaning that only they can distribute Snap software, which many Linux users feel violates the spirit & intention of the wider free and open source community.

      Appimages and Flatpaks are fully open source standards, anybody can package their software in those ways and distribute them however they want.

      .deb files are software packaged for the Debian distribution, and frequently also work with other distros that are based on Debian, like Linux Mint.

      • lengau@midwest.social
        link
        fedilink
        arrow-up
        7
        ·
        3 months ago

        Some further context on this that @Dop@lemmy.world might want to know:

        While Canonical’s snap store is proprietary (which, to be clear, I don’t really like), all the client software is open source and the API is well documented (though a bit janky). Their snap store relay app (which is open source) has a full implementation of it. There was a fully functional open snap store for a while, but the project died out of a lack of interest. You can also distribute snaps through another mechanism and install them locally on the machine (though you then lose the benefit of snapd’s auto updates). You can even do this with snapd still checking the signatures of the snaps.

        The standard for snaps is fully open, as is snapd itself.

        There’s no need to oversell the negatives to the point of being wrong.

        • merthyr1831@lemmy.ml
          link
          fedilink
          English
          arrow-up
          1
          ·
          3 months ago

          Interesting, didn’t know it was feasible to make the distribution open.

          That doesn’t give me much to complain about in theory, but canonical has lost way too much good faith to give people a reason to keep open snap distribution going for free. They should definitely consider hosting an open store just to get people on board again.

          • lengau@midwest.social
            link
            fedilink
            arrow-up
            2
            ·
            3 months ago

            It was being done by a group of snapd developers at Canonical, IIRC, but after a couple of years of exactly zero interaction from anyone outside Canonical I think they just gave up and decided it wasn’t worth it because they were getting accused of trying to monopolise whether they had an open store or just an open API.

            Of course, you can also distribute snaps without using the snap store API. I’ve used this for airgapped machines in the past. You can either just grab the .snap file (which is just a squashfs file with a meta/snap.yaml in it so snapd knows how to treat it) and install it with --dangerous, or you can include an assertion file for that snap signed by a certificate that your machine’s snapd trusts and not even have to do that. (Those airgapped machines trusted our own certificate so we could ensure that the snaps came from our CI process and weren’t a developer’s random test snap).

      • Dop@lemmy.world
        link
        fedilink
        arrow-up
        1
        ·
        3 months ago

        Thanks, I recently needed picocrypt and not being comfortable with the terminal, snap were a rather convenient way to get it installed, I’ll avoid them from now on.

    • pixelscript@lemm.ee
      link
      fedilink
      English
      arrow-up
      10
      ·
      3 months ago

      The primary thing I hate about them is that every snap package appears to your system as a separate mounted filesystem. So if you look in your file explorer, you can potentially see dozens of phantom drives clogging up your sidebar.

    • lengau@midwest.social
      link
      fedilink
      arrow-up
      8
      ·
      3 months ago

      I don’t think snaps are bad (and when someone tries to explain why they are, about 85% of the time they say something wrong enough that I suspect they’re probably just parroting someone else rather than actually knowing what’s going on). It’s sad, because if we could get rid of the bullshit we could actually have decent discussions about the benefits and shortcomings of snaps (and how to fix those shortcomings).

      On the .deb front: it’s a package format made by Debian. Each archive contains a data tarball, which has the files in the package in their full structure from /, and a control tarball, which contains metadata such as name, version and dependencies as well as pre-install, pre-remove, post-install and post-remove scripts, which are used doing any setup or removal work that can’t be done just by extracting or deleting the files.

      The upside of deb files is that they tend to be pretty small. The downside is that this typically comes from having a tight coupling to library versions on the system, which means upgrading a library can break seemingly unrelated things. (This is why you get warnings like this page: https://wiki.debian.org/DontBreakDebian) Many third party distributors (e.g. Google with Chrome) take care of this by packaging most dependencies inside the deb, inflating the size.

      Another major difference between packages like debs and rpms and newer formats like snaps and flatpaks is that the latter have confinement systems to prevent apps from having full access to your system.

      • emiellr@lemm.ee
        link
        fedilink
        English
        arrow-up
        2
        ·
        3 months ago

        Worth noting that the confinement of Flatpaks and Snaps can have major drawbacks. It has been a major pain in the ass to get Flatpaks working nicely with fractional scaling (think tiny cursor, huge text, tiny text etc etc)

        • merthyr1831@lemmy.ml
          link
          fedilink
          English
          arrow-up
          1
          ·
          3 months ago

          Nothing in theory makes that an issue of flatpaks and snap, just that both rely on different means to interact with the host system that have been woefully slow to implement. If enough protocols are developed a flatpak or snap should be as capable as a native app with the safety benefits for free.

          • lengau@midwest.social
            link
            fedilink
            arrow-up
            1
            ·
            3 months ago

            If you look through the desktop portals GitHub, it seems to be a mess of bikeshedding, mostly on the part of a small number of people on the flatpak side. Canonical seem to have been working around this in snaps by writing their own interfaces as stopgaps until the desktop portals catch up, probably because they got such pushback when the similar frustration on the display server side resulted in them releasing mir with its own protocol until the Wayland folks could get their act together.

          • emiellr@lemm.ee
            link
            fedilink
            English
            arrow-up
            1
            ·
            3 months ago

            While you’re right in pointing out that in theory it’s basically as capable as native, it’s a royal pain in the ass as it is right now, which disqualifies it from a great deal of applications.

      • merthyr1831@lemmy.ml
        link
        fedilink
        English
        arrow-up
        1
        ·
        3 months ago

        Honestly if not for the convoluted Linux FS layout, debs would be pretty serviceable and aren’t really different to the Windows solution. The fs layout makes installations way too fickle to clashing with other applications.

        That and dependency hell, which distros should have never been allowed to touch beyond the core dependencies required to get your desktop running.

        • lengau@midwest.social
          link
          fedilink
          arrow-up
          1
          ·
          3 months ago

          Well that’s what /opt is for. Well-behaved application packages that aren’t part of your core distro should install themselves in there.

    • merthyr1831@lemmy.ml
      link
      fedilink
      English
      arrow-up
      4
      ·
      3 months ago

      Nothing necessarily at the tech level. They’re more capable than Appimages or flatpaks to the point that you can use it to build a reproducible system hardened against tampering or defective updates.

      The downside is that it’s controlled entirely by canonical, has limited abilities (if any?) for hosting storefronts/packages outside of their ecosystem, and said ecosystem is insecure and has already allowed multiple waves of malicious apps to reach end users because of poor moderation of listings masquerading as legitimate versions.

      Canonical has also been increasingly hostile to flatpaks - removing it from Ubuntu and derivatives by default to push users towards snap.

      The whole loopfs thing is just an annoyance, but the aggressive posturing by canonical as well as the closed nature of the storefront that has led to malicious attacks on end users is enough to give it more than a few haters.

    • kalpol@lemm.ee
      link
      fedilink
      arrow-up
      3
      arrow-down
      1
      ·
      3 months ago

      The snap store is some proprietary store Canonical runs, and snaps are friggin huge in size. I don’t really know though as I don’t use Ubuntu anymore

      • lengau@midwest.social
        link
        fedilink
        arrow-up
        3
        ·
        3 months ago

        The first two snaps I compared sizes of on my system are uv and bitwarden. The uv snap is 9.5 megs vs. the wheel’s 12.2 megs, and the bitwarden snap is 97 megs vs. the Deb’s 79 megs and the AppImage’s 114 megs. These seem pretty reasonable - doubly so since snaps also have delta updates.

        • kalpol@lemm.ee
          link
          fedilink
          arrow-up
          1
          ·
          3 months ago

          OK that’s better than what I’ve seen. Notepadqq I think was 2.4gb and I said no to that one. But again I don’t run Ubuntu.

          • lengau@midwest.social
            link
            fedilink
            arrow-up
            1
            ·
            3 months ago

            I don’t use Notepadqq anywhere (I use kate btw), but on my KDE Neon system it’s currently showing:

            $ snap info notepadqq
            name:      notepadqq
            summary:   A Notepad++-like editor for Linux.
            publisher: Daniele Di Sarli (danieleds)
            store-url: https://snapcraft.io/notepadqq
            license:   GPL-3.0
            description: |
              It helps developers by providing all you can expect from a general purpose text editor, such as
              syntax highlighting for more than 100 different languages, code folding, color schemes, file
              monitoring, multiple selection and much more.
              You can search text using the power of regular expressions. You can organize documents side by
              side. You can use real-time highlighting to find near identifiers in no time.
            snap-id: 6iueWFAtx9P2OQz4SIW64Kry9hT8aUCL
            channels:
              latest/stable:    1.4.8          2018-09-14 (855) 151MB -
              latest/candidate:                                      
              latest/beta:      2.0.0-beta+git 2019-10-12 (890) 201MB classic
              latest/edge:      2.0.0-beta+git 2019-10-16 (897) 197MB classic
            

            It seems to be a dead project (the last release on GitHub is that same 2.0 beta from 2019), but looking at the snapcraft.yaml file, it looks like it’s because they’re vendoring in a pretty big chunk of KDE and gtk libraries. 2019 was before I started doing anything with snaps or flatpaks for desktops so I’m not sure what the state of KDE content snaps was then (I know there was a GNOME one because the core18 gnome content snap is installed on my system for uhh… some app that I have), but these days for desktop apps there are content snaps for gnome (published by Canonical) and KDE Frameworks (published by KDE) to deduplicate those dependencies.

      • merthyr1831@lemmy.ml
        link
        fedilink
        English
        arrow-up
        1
        ·
        3 months ago

        Size isn’t an issue imo. Applications are bulky for many more reasons than their packaging formats.