• vrighter@discuss.tchncs.de
          link
          fedilink
          arrow-up
          0
          ·
          1 month ago

          or they somehow still find a way to not work. I can count the number of times i had an appimage just work, and it is exactly 2. Any other time i had crashes

        • AnimalsDream@slrpnk.net
          link
          fedilink
          English
          arrow-up
          0
          ·
          1 month ago

          It would, if there were no other options for package management. Package formats don’t have to be either/or. My systems typically end up with mixes of native packages, flatpak, appimages, and you could technically consider Steam a package management system as well.

    • srestegosaurio@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 month ago

      Last time I read something from the main dev I almost ran stright into the woods.

      Also idk about how it is the management situation, portals integration, etc…

  • Admiral Patrick@dubvee.org
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 month ago

    Let the hate of the crowd wash over me, but I don’t even like Flatpak, and I’ve got love-hate (mostly hate) relationship with AppImage as well.

    Just give me a system package or a zipped tarball.

    In recent years, have had to just get used to needing to build most projects from source.

      • jj4211@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        1 month ago

        I’d say that complete lack of a single consistent way to manage updates.

        I really don’t feel having to micromanage each piece of software.

        • Samueru_sama@programming.dev
          link
          fedilink
          English
          arrow-up
          0
          ·
          1 month ago

          AppImage is meant to be updated using the embedded zsync info the runtime, that is the user should never have to open the app to update it.

          The user needs to have something like AM, appimagelauncher or appimaged that is then able to parse the info and update the appimages using appimageupdatetool

          This method also provides delta updates, meaning it doesn’t download the entire app but only a diff, see this test with CPU-X where it downloaded 2.65 MiB to update the app:

          TLDR: https://github.com/ivan-hc/AM

      • Admiral Patrick@dubvee.org
        link
        fedilink
        English
        arrow-up
        0
        ·
        1 month ago

        Just not a fan of container formats in general.

        I say that as a heavy user of Docker, but that’s a different use-case.

          • Admiral Patrick@dubvee.org
            link
            fedilink
            English
            arrow-up
            0
            ·
            edit-2
            1 month ago

            At least for appimage, it doesn’t create application launchers. And it’s 50/50 whether the icon in the window list works or not.

            I also build a lot of Docker images, and container formats throw a wrench in that if that’s the only way the application/utility is packaged. So I end up building from source.

            • klu9@lemmy.ca
              link
              fedilink
              English
              arrow-up
              0
              ·
              1 month ago

              Personally, I use AM. Takes care of that and more.

              It is CLI and I’m GUI by nature, but AM is easy enough for me. Just yesterday I did a simple am -u and got the latest updated versions of qBittorrent, FreeTube, yt-dlp etc. (I.e. the kind of program that system packages are too out of date to work safely or even work at all.)

              There are other options like zap (CLI), Gear Lever (GUI) and just recently I believe the Nitrux distro came out with a complete AppImage software manager. (Checking it out, https://github.com/Nitrux/nx-software-center , it seems it pulls from AppImageHub.com, which unfortunately has largely been forgotten by developers, a lot of software is either out of date, unverifiable or completely absent. AM is much more up-to-date, pulling the latest AppImages mostly from official GitHub repos.)

      • monk@lemmy.unboiled.info
        link
        fedilink
        arrow-up
        0
        ·
        29 days ago

        I already have the system package manager. Everything else that isn’t it doesn’t manage my system and is doomed to suck.

      • Björn Tantau@swg-empire.de
        link
        fedilink
        arrow-up
        0
        ·
        1 month ago

        For me it is the “Windowsy” feeling of downloading an executable from some website. I prefer having all my packages managed in one place.

            • Monstrosity@lemm.ee
              link
              fedilink
              English
              arrow-up
              0
              ·
              edit-2
              1 month ago

              Most update themselves & flatpaks are the worst when you need them to work with your system (ie: scripts).

              So I guess your opinion is just wrong, sorry!

              • Kusimulkku@lemm.ee
                link
                fedilink
                arrow-up
                0
                ·
                1 month ago

                I despised the Windows way of everything having their own updater either running in the background or only alerting you when you want to use an app.

                AppImage to me feels like a big step backwards.

              • HunterLF@lemmy.zip
                link
                fedilink
                arrow-up
                0
                ·
                1 month ago

                Damn, should have said that sooner, I see people don’t tolerate that kind of talking to others in here. Respect the community.

            • Samueru_sama@programming.dev
              link
              fedilink
              English
              arrow-up
              0
              ·
              1 month ago

              AppImage is meant to be updated using the embedded zsync info the runtime, that is the user should never have to open the app to update it.

              The user needs to have something like AM, appimagelauncher or appimaged that is then able to parse the info and update the appimages using appimageupdatetool

              This method also provides delta updates, meaning it doesn’t download the entire app but only a diff, see this test with CPU-X where it downloaded 2.65 MiB to update the app:

          • cecilkorik@lemmy.ca
            link
            fedilink
            English
            arrow-up
            0
            ·
            1 month ago

            For simple “apps” it is fine, but my computer is not a phone and I don’t use it like one. I mostly don’t want simple apps that have their own little sandbox to play in.

            I want full-scale applications that are so big they have to use system libraries to keep their disk size down. I also don’t want them in a sandbox. I want them to have full access to the system to do everything they need to do, I want them to integrate with far-flung parts of the system and other applications too. I only use applications I trust and don’t want them constantly pestering me about configuring permissions and access in just the right ways and opening all the right doors and ports and directories to make them work, I trust them by installing them, they have permission, and the easier they make it to access everything I will inevitably be asking them to access, the happier I am.

            My practical concern with distribution methods like AppImage and Flatpak is that now I have to do a lot of extra thinking every time I’m installing anything. To pick how I’m going to install something, I have to solve the matrix of “what kind of distribution method do I prefer for this type of software” combined with “what distribution methods are available for this software” and “what versions are the available distribution methods for this software” and “what distribution method provides the best way for this software to get updates”.

            In the olden days, when the distro’s package manager was the only choice, all I had to care about was “is it available in my distro” and the decision tree was complete. I appreciate all the availability of choice that things like AppImage provide, but it doesn’t actually make it easier for me, it just makes it easier for the packager of the software. They’re doing less, but making more work for me, as a user. Distro packages are a lot of work for the maintainer precisely because they at least make an effort to solve many of these issues for the user. The value-add that maintainers provide is real.

            • notabot@lemm.ee
              link
              fedilink
              arrow-up
              0
              ·
              1 month ago

              I couldn’t agree more. Occasionally I’ll use an appimage where something is not packaged for my distro version and I only need it temporarily.

              Maybe I’m just long in the tooth, but linux used to be a simple, quite elegant system, with different distros providing different focuses, whether they were trying to be windows clones, something that a business could bank on being there in ten years, or something for those who like to tinker. The common theme throughout was ‘the unix way’, each individual tool was simple, did one job, and did it well. Now we seem to be moving to a much more homogenous ecosystem of distros with tooling that tries to be everything all at once, and often, not very well.

            • MrQuallzin@lemmy.world
              link
              fedilink
              arrow-up
              0
              ·
              1 month ago

              It doesn’t sound like they’re making more work for you. It sounds like you’re making more work for yourself, and it sounds exhausting.

            • Samueru_sama@programming.dev
              link
              fedilink
              English
              arrow-up
              0
              ·
              1 month ago

              omg I cannot fucking believe that while I was typing this I just saw another distro package nonsense:

              There is this very good tool called soar which I use for static binaries. (It also has support for appimages but to be honest it is not as good as AM rn).

              Well we just got a complain that fastfetch is not displaying the package count of soar, which fastfetch is able to do.

              Turns out this is because the archlinux package is built without SQLITE3 which is needed for that feature to work 😫

              And what’s worse is that account registrations are disabled in the archlinux gitlab, so I have to jump thru some hoops to get a basic bug report filed…

              • YouAreLiterallyAnNPC@lemmy.world
                link
                fedilink
                arrow-up
                0
                ·
                1 month ago

                Just enable the sqlite3 USE flag in /etc/portage/make.conf.

                Sorry, wrong distro. I’m assuming Arch can use portage or something if you want.

                • Samueru_sama@programming.dev
                  link
                  fedilink
                  English
                  arrow-up
                  0
                  ·
                  1 month ago

                  The issue is arch and not us. They are building fastfetch without SQLITE3 and then we get people asking why the package count of fastfetch doesn’t display soar pkgs… All we can do is just tell people to not use fastfetch from the arch repos.

                  All archlinux has to do is change this line from OFF to ON

            • Samueru_sama@programming.dev
              link
              fedilink
              English
              arrow-up
              0
              ·
              1 month ago

              I want full-scale applications that are so big they have to use system libraries to keep their disk size down

              Linux is in such sad state that dynamic linking is abused to the point that it actually increases the storage usage. Just to name a few examples I know:

              most distros ship a full blown libLLVM.so, this library is a massive monolith used for a bunch of stuff, it is also used for compiling and here comes the issue, by default distros build this lib with support for the following targets:

              -- Targeting AArch64
              -- Targeting AMDGPU
              -- Targeting ARM
              -- Targeting AVR
              -- Targeting BPF
              -- Targeting Hexagon
              -- Targeting Lanai
              -- Targeting LoongArch
              -- Targeting Mips
              -- Targeting MSP430
              -- Targeting NVPTX
              -- Targeting PowerPC
              -- Targeting RISCV
              -- Targeting Sparc
              -- Targeting SystemZ
              -- Targeting VE
              -- Targeting WebAssembly
              -- Targeting X86
              -- Targeting XCore
              

              Gentoo used to offer you the option to limit the targets and make libLLVM.so much smaller, but now rust applications that link to llvm have issues with this with caused them to remove that feature…

              Another is libicudata, that’s a 30 MiB lib that all GTK applications end up linking to for nothing, because it is a dependency of libxml2, which distros override to build with icu support (by default this lib does not link to libicudata) and what’s more sad is that the depenency to libxml2 comes because of transitive dependency to libappstream, yes that appstream that I don’t even know why most applications would need to link to this.

              And then there is archlinux that for some reason builds libopus to be 5 MiB when most other distros have this lib <500 KiB

              Sure dynamic linking in the case of something like the coreutils, where you are going to have a bunch of small binaries makes sense, except you now have stuff like busybox which is a single static bin that acts as each of the different tools by checking the name of the symlink that launched it and it is very tiny at 1 MiB and it provides all your basic unix tools including a very good shell.

              Even Linus was surprised by how much dynamic linking is abused today: https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=RcUSmQg@mail.gmail.com/

              To pick how I’m going to install something,

              https://github.com/ivan-hc/AM

              I have all these applications using 3.2 GIB of storage while the flatpak equivalent actually uses 14 GiB 💀: https://i.imgur.com/lvxjkTI.png

              flatpak is actually sold on the idea that shared dependencies are good, you have flatpak runtimes and different flatpaks can share, the problem here is that those runtimes are huge on their own, the gnome runtime is like 2.5 GiB which is very close to all those 57 applications I have as appimage and static binaries.

              but it doesn’t actually make it easier for me, it just makes it easier for the packager of the software

              Well I no longer have to worry about the following issue:

              • My application breaking because of a distro update, I actually now package kdeconnect as an appimage because a while ago it was broken for 2 months on archlinux. The only app I heavily rely from my distro now is distrobox.

              • I also get the latest updates and fixes as soon as upstream releases a new update, with distro packaging you are waiting a week at best to get updates. And I also heard some horror stories before from a dev where they were told that they had to wait to push an update for their distro package and the only way to speed it up was if it was a security fix.

              • And not only you have to make sure the app is available in your distro packages, you also have to make sure it is not abandoned, I had this issue with voidlinux when I discovered the deadbeef package was insanely out of date.

              • Another issue I have with distro packages in general is that everything needs elevated rights to be installed, I actually often hear this complains from linux newbies that they need to type sudo for everything and it doesn’t have to be this way, AM itself can be installed as appman which makes it able to work on your HOME with all its features. And you can take your HOME and drop it in any other distro and be ready to go as well.

  • 33manat33@feddit.org
    link
    fedilink
    arrow-up
    0
    ·
    1 month ago

    I’d love to use flatpak more, but with my peculiar internet situation, installing a single package can take 6-7 hours.

  • Monstrosity@lemm.ee
    link
    fedilink
    English
    arrow-up
    0
    ·
    1 month ago

    I tried a snap package on my pop-os system once & it poo’ed folders all over my system, then didn’t actually uninstall when I uninstalled it.

    No thank you.

    • fembinary@lemmy.blahaj.zone
      link
      fedilink
      arrow-up
      0
      ·
      1 month ago

      thats the thing with snaps: they go all over the place on your system, so even if you uninstall it (which itself is a tiring and cumbersome task at times!), they magically stay everywhere on the systems, with tons of folders and files.

        • fembinary@lemmy.blahaj.zone
          link
          fedilink
          arrow-up
          0
          ·
          1 month ago

          install yes, but there are tons of other files and folders that get created, IIRC even pseudo-users or something along those lines? (or that was distro-specific perhaps)

          • Sibshops@lemm.ee
            link
            fedilink
            English
            arrow-up
            0
            ·
            1 month ago

            You mean like the program itself is creating files? The issue would be the same whether apt or snap is used, in this case.

  • procapra@lemm.ee
    link
    fedilink
    arrow-up
    0
    ·
    1 month ago

    If flatpak didn’t make me put the entirety of KDE onto my system (thats an exaggeration but you know what I mean) I’d gladly crown it king of the package managers.

    • sensiblepuffin@lemmy.funami.tech
      link
      fedilink
      arrow-up
      0
      ·
      1 month ago

      Plus make it hell on earth to a) access drives other than the one flatpak is installed on, b) interoperate with non-flatpak applications, and c) retain any amount of free space on my drives (exaggeration for effect).

      • OsrsNeedsF2P@lemmy.ml
        link
        fedilink
        arrow-up
        0
        ·
        1 month ago

        This is a “security” feature and I’m so tired of it. Same thing with Wayland, random crap doesn’t work sometimes

      • JayDee@lemmy.sdf.org
        link
        fedilink
        arrow-up
        0
        ·
        1 month ago

        Yeah, flatseal should come stock with flatpak IMO. You will have to configure many apps to get them to play nice with your system.

    • rtxn@lemmy.worldM
      link
      fedilink
      arrow-up
      0
      ·
      1 month ago

      I just want to point out the dependencies of Konsole (arguably a small and simple application in concept): glibc gcc-libs icu kbookmarks kcolorscheme kconfig kconfigwidgets kcoreaddons kcrash kdbusaddons kglobalaccel kguiaddons ki18n kiconthemes kio knewstuff knotifications knotifyconfig kparts kpty kservice ktextwidgets kwidgetsaddons kwindowsystem kxmlgui qt6-5compat qt6-base qt6-multimedia sh.

    • OsrsNeedsF2P@lemmy.ml
      link
      fedilink
      arrow-up
      0
      ·
      1 month ago

      Psst … the first KDE app you installed via your package manager also put “the entirety of KDE” onto your system.

      • CarrotsHaveEars@lemmy.ml
        link
        fedilink
        arrow-up
        0
        ·
        1 month ago

        Indeed. As much of how loved and popular KDE is, fuck it. I use the glorious XFCE. XFCE is beautiful too. Fuck, I’m not the maniac who would waste 2GB just for my DE to look beautiful.

    • LeFantome@programming.dev
      link
      fedilink
      arrow-up
      0
      ·
      1 month ago

      Flatpak does not install KDE by default. It is only required if you install a KDE app. You can hardly blame it if you do that.

  • cley_faye@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    1 month ago

    A rusty bucket riddled with holes and the stick part of a shovel is better than snap for running software.

  • miguel@fedia.io
    link
    fedilink
    arrow-up
    0
    ·
    1 month ago

    Only tangentially related - but a friend brought over a new kubuntu install and Canonical had the cheek to demand money for VLC patches? They don’t fing own VLC. What the actual f is going on over there, Canonical?

  • MoonlightFox@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    1 month ago

    I have really started to like AppImage. You just download a single file make it executable and it just works.

    I use Cursor for coding, and it has an appimage that replaces itself when it updates.

    • bdonvr@thelemmy.club
      link
      fedilink
      arrow-up
      0
      ·
      1 month ago

      That’s cool and all but it would be even cooler if you could just install and keep it updated through your package manager

        • dinckel@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          1 month ago

          That’s kind of the point though. One of the foundational pillars of a good distribution is mature package management, and that includes not relying on self-updaters that will pollute your system with untracked files

          • Leon@pawb.social
            link
            fedilink
            English
            arrow-up
            0
            ·
            1 month ago

            Absolutely, but don’t AppImage updaters basically just replace the AppImage? They’re self-contained, no?

        • bdonvr@thelemmy.club
          link
          fedilink
          arrow-up
          0
          ·
          1 month ago

          That’s cool.

          It would still be even cooler if the app makers just packaged them for distros. Or even just Flatpak.

          But that’s a cool project I’ll keep it in mind for my next go with an immutable distro

          • Samueru_sama@programming.dev
            link
            fedilink
            English
            arrow-up
            0
            ·
            1 month ago

            Or even just Flatpak.

            AM was started because flatpak sucks.

            • With flatpak devs can’t agree to use a common runtime, so the user ends up with a bunch of different runtimes and even EOL versions of the same runtime, making the storage usage 5x more than the appimage equivalent and this is much worse if you use nvidia which flatpak will download the entire nvidia driver again.

            • flatpak could not bother to fix the hardcoded ~/.var directory, something that AM fixes by simply bind mounting the existing application config/data files to their respective places when sandboxing which yes it is able to sandbox appimages with aisap (bubblewrap).

            • flatpak threw the mess of handling conflicting applications to the user, so you have to type nonsense like flatpak run io.github.ungoogled_software.ungoogled_chromium, AM just puts the app to PATH like everyone else does, even snap doesn’t have this issue.

            • Colloidal@programming.dev
              link
              fedilink
              English
              arrow-up
              0
              ·
              1 month ago

              Having experienced Flatpak bloat and seeing your posts here, I might just have been converted. The Flatpak integration on my distro is neat though. But I already use Aptitude for most of my package management needs, so I guess adding AM to my toolbox doesn’t seem too bad.

          • klu9@lemmy.ca
            link
            fedilink
            English
            arrow-up
            0
            ·
            edit-2
            1 month ago

            I do wish something like AM’s functions was built into an all-in-one package manager for my distro. The closest I found was bauh which handles “AppImage, Debian and Arch Linux packages (including AUR), Flatpak, Snap and Web applications”. Which seems like an all-in-one solution.

            But the problem with bauh (that last time I tried it) is that it accesses only a small number of (often very out-of-date) AppImages from the largely moribund AppImageHub.com, unlike AM, which pulls in the latest releases from loads of GitHub repos, and adds more on a frequent basis or request.

    • Psychadelligoat@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 month ago

      Some apps are a bitch and a half for some reason, other apps just work

      Make a .desktop file, slap it in ./local/share/imdrawingafuckingblank and boom, it’s integrated into your shell menu like any other app

      The Nexus Mod App and Foundry VTT work flawlessly and it’s so nice

      • MoonlightFox@lemmy.world
        link
        fedilink
        arrow-up
        0
        ·
        1 month ago

        As a somewhat Linux noob I just made a folder called ~/Apps and launch them through terminal. Not ideal, but I don’t care enough to fix it.

        Your suggestion makes me kinda want to fix it though. Doesn’t seem like to much work

        • Fisch@discuss.tchncs.de
          link
          fedilink
          English
          arrow-up
          0
          ·
          1 month ago

          I’ve used Linux for years and I also have a ~/Applications folder where I put AppImages, applications cloned with git and stuff like that in. E.g. I have the last Yuzu AppImage in there, since it got taken down, but I also made a .desktop file for it, so I can launch it through the application menu. Btw, you should be able to just double click AppImages in your file explorer to open them.

  • Abnorc@lemm.ee
    link
    fedilink
    arrow-up
    0
    ·
    edit-2
    1 month ago

    It’s not about the package management method that we use. It’s about the friends and enemies we made along the way (while arguing about package management.)

  • chrash0@lemmy.world
    link
    fedilink
    arrow-up
    0
    ·
    1 month ago

    i just got an Ubuntu machine at work, and really simple packages are only available as snaps. so i guess i’m going to try out Nix home-manager

  • danhab99@programming.dev
    link
    fedilink
    arrow-up
    0
    ·
    1 month ago

    Nix is just across the street sipping tea because it understands what it is and is at peace with the chaotic world around it.

    • stebator@lemmy.world
      link
      fedilink
      arrow-up
      0
      ·
      1 month ago

      I use NixOS and Flatpak (Nix-Flatpak) to install software that is not available in Nixpkgs. Unlike Arch’s AUR, Nixpkgs has fewer popular packages. However, Nixpkgs beats AUR in terms of quantity because many Nixpkgs packages are redundant.

  • Phoenixz@lemmy.ca
    link
    fedilink
    arrow-up
    0
    ·
    1 month ago

    That’s because we are…

    If .y Firefox will once again be updated without asking me and then refusing to open any page without a restart I’ll fucking lose it

    • Sonotsugipaa@lemmy.dbzer0.com
      link
      fedilink
      English
      arrow-up
      0
      ·
      1 month ago

      Wait hold on wait, does that bullshit have something with Firefox being distributed through Snap?

      If it does, I’m going to sn… also fucking lose it

      • mogoh@lemmy.ml
        link
        fedilink
        arrow-up
        0
        ·
        edit-2
        1 month ago

        I have bad news for you …

        (TBH I am not sure, but as I remember, this problem was specifically a snap problem.)

      • Phoenixz@lemmy.ca
        link
        fedilink
        arrow-up
        0
        ·
        1 month ago

        Yeah, it’s snap

        Always updating without letting you know, without asking and it’s ALWAYS at the most inconvenient time

          • Phoenixz@lemmy.ca
            link
            fedilink
            arrow-up
            0
            ·
            10 days ago

            It basically IS the cause as it’s the system doing the updates without asking. But snap has other issues too. For one, it’s the slowest installer in recorded human history, it takes literally ten times longer on snap to install anything. Why? Beats me, in theory it ought to be faster as it shouldn’t have to resolve dependencies but here we are. Try installing anything with snap, it takes forever.

            Then, snap is closed source eon the server side, so fuck all of that, that’s already 200% of reasons not to use it ever. I don’t trust closed source software anymore