• Ferk ( Ferk@lemmy.ml ) 
      2·
      10 months ago

      You are mixing different ideas of freedom. Software freedom is not the same as freedom of choice of software.

      You don’t need Linux to have choices of what software to use, you have that in most (all?) proprietary systems, in some you might even have more choices than in Linux… even if it includes proprietary software.

      This is analogous to how being a free person (not a slave) is not the same as having freedom to choose who to work for, even if some of them are slavers (ie. having freedom to choose your master).

  • Allero ( Allero@lemmy.today ) 
    38·
    10 months ago

    Certainly a fan, and I don’t understand the hate towards it.

    Flatpaks are my preferred way of installing Linux apps, unless it is a system package, or something that genuinely requires extensive permissions like a VPN client, or something many other apps depend on like Wine.

    The commonly cited issues with Flatpaks are:

    • Performance. Honestly, do you even care if your Pomodoro timer app takes up 1 more megabyte of RAM? Do you actually notice?
    • Bloat. Oh, yes, an app now takes 20 MB instead of 10 MB. Again, does anybody care?
    • Slower and larger updates. Could be an issue for someone on a metered traffic, or with very little time to do updates. Flatpaks update in the background, though, and you typically won’t notice the difference unless you need something newest now (in which case you’ll have to wait an extra minute)
    • Having to check permissions. This is a feature, not a bug. For common proponents of privacy and security, Linuxheads grew insanely comfortable granting literally every maintainer full access to their system. Flatpaks intentionally limit apps functionality to what is allowed, and if in some case defaults aren’t good for your use case - just toggle a switch in Flatseal, c’mon, you don’t need any expertise to change it.

    What you gain for it? Everything.

    • Full control over app’s permissions. Your mail client doesn’t need full system permissions, and neither do your messengers. Hell, even your backup client only needs to access what it backs up.
    • All dependencies built in. You’ll never have to face dependency hell, ever, no matter what. And you can be absolutely sure the app is fully featured and you won’t have to look for missing nonessential dependencies.
    • Fully distro-agnostic. If something works on my EndeavourOS, it will work on my OpenSUSE Slowroll, and on my Debian 12. And it will be exactly the same thing, same version, same features. It’s beautiful.
    • Stability. Flatpaks are sandboxed, so they don’t affect your system and cannot harm it in any way. This is why immutable distros feature Flatpaks as the main application source. Using them with mutable distributions will also greatly enhance stability.

    Alternatives?

    AppImages don’t need an installation, so they are nice to see what the program is about. But for other uses, they are garbage-tier. Somehow they manage both not to integrate with the system and not be sandboxed, you need manual intervention or additional tools to at least update them/add to application menu, and ultimately, they depend on one file somewhere. This is extremely unreliable and one should likely never use AppImages for anything but “use and delete”.

    Snaps…aside from all the controversy about Snap Store being proprietary and Ubuntu shoving snaps down people’s throats, they were just never originally developed with desktop applications in mind. As a result, Snaps are commonly so much slower and bulkier that it actually starts getting very noticeable. Permissions are also way less detailed, meaning you can’t set apps up with minimum permissions for your use case.

    This all leaves us with one King:

    And it is Flatpak.

    • nitrolife ( nitrolife@rekabu.ru ) 
      15·
      10 months ago

      I’ve been working on Linux for 15 years now and I perfectly remember the origin of many concepts. If you look at it through time, what would it be like:

      1. We can build applications with external dependencies or a single binary, what should we choose?
      2. The community is abandoning a single binary due to the increased weight of applications and memory consumption and libraries problems
      3. Dependency hell is coming …
      4. Snap, flatpack, appimage and other strange solutions are inventing something, which are essentially a single binary, but with an overlay (if the developer has hands from the right place, which is often not the case)
      5. Someone on lemmy says that he literally doesn’t care if the application is built in a single binary, consumes extra memory and have libraries problems. Just close all permissions for that application…

      Well, all I can say about this is just assemble a single binary for all applications, stop doing nonsense with a flatpack/snap/etc.

      UPD: or if you really want to break all the conventions, just use nixos. You don’t need snap/flatpack/etc.

        • nitrolife ( nitrolife@rekabu.ru ) 
          5·
          10 months ago

          Provided that flatpack has a common parent container, which is not always the case. More precisely, it almost never does. Because someone updates flatpack to new versions of the parent containers, and someone else does not.

          • grinka ( grinka@lemmy.zip ) Banned from communityEnglish
            5·
            10 months ago

            More precisely, it almost never does.

            I don’t know any flatpak in my system that don’t use runtime (I have around 50 flatpak apps installed), or am I misunderstanding your point

            • nitrolife ( nitrolife@rekabu.ru ) 
              4·
              10 months ago

              runtime have versions too. If one runtime version use only one flatpack than exactly same as just static linking binary. Flatpack have just docker layeredfs and firejail in base.

              id: org.gnome.Dictionary runtime: org.gnome.Platform runtime-version: '45' <- here sdk: org.gnome.Sdk command: gnome-dictionary

              • grinka ( grinka@lemmy.zip ) Banned from communityEnglish
                2·
                10 months ago

                I see problem in that only in unmaintained apps (like org.gnome.Dictionary), I have only GNOME 47 & 48 for example and both of them still updating

                • nitrolife ( nitrolife@rekabu.ru ) 
                  3·
                  10 months ago

                  In the initial stage of shared library support, everything was exactly the same. Let’s look at it in 5 years… When some soft will archived and die, some stop maintaining, some new crated and brakes old dependencies…

      • Allero ( Allero@lemmy.today ) 
        6·
        10 months ago

        I don’t mind other solutions, as long as they have the key features Flatpak offers, namely:

        • Being open-source
        • Having app permission system
        • Having bundled dependencies
        • Integrating decently with the system

        Times are changing, and memory constraints for most programs are generally not relevant anymore.

        • nitrolife ( nitrolife@rekabu.ru ) 
          8·
          10 months ago

          Times are changing, and memory constraints for most programs are generally not relevant anymore.

          But there are gaps in the libraries that, unlike distributions with dependencies, can no longer be managed. And all the security of your system depends on a small flatpack access control, which 99% of users do not understand at all and, with any problems simply opens access to the entire home directory.

          • Allero ( Allero@lemmy.today ) 
            7·
            10 months ago

            I’m not saying Flatpak is perfect, but it appears to be the best we have.

            I absolutely agree more needs to be done to explain permissions and have sane defaults. Flatseal in particular could introduce more warnings, and this is where non-technical users set their permissions.

            In my experience, most Flatpaks do not request full home folder access by default, and making Flatpak access everything everywhere typically requires user intervention.

            Native apps, meanwhile, just run with full system-wide access; I get it that they’re more vetted and more properly updated, but this is an unhealthy and insecure arrangement.

            • nitrolife ( nitrolife@rekabu.ru ) 
              5·
              10 months ago

              this is a system for work tasks. Of course, I understand what the developers are going for. that is Android. And it’s really nice to read the Internet on android. But try to do something more complicated than that and you’ll realize that it’s hell. However, I don’t mind if such distributions appear. Why not? I just don’t understand people who voluntarily limit their abilities. And why you don’t just install Android 64?

              The flatpack approach automatically remove everything low-level from the equation. Do you want to write directly to the graphics card buffer? Read the input? Do I set the fan rotation parameters directly in the /proc? All these applications will never work in flat pack.

              On the other hand, flatpack is superfluous and for convenience. You can simply build an executable file without dependencies and configure firejail for it yourself… That’s all. Or run the file from another user. That is so popular exactly bacause RedHat pushed them. Literaly like Canonical pushed snap.

              • Allero ( Allero@lemmy.today ) 
                8·
                10 months ago

                All these applications will never work in flat pack.

                They don’t have to! Flatpak doesn’t remove all other ways to install software. But for 95% of use cases, it will do just fine.

                Firejail is good, but it only solves sandboxing part of the equation, and there’s so much more to Flatpaks than that. Also, it’s more painful to configure and is more sysadmin-oriented.

                • nitrolife ( nitrolife@rekabu.ru ) 
                  3·
                  10 months ago

                  They don’t have to! Flat pack doesn’t remove all other ways to install software. But for 95% of use cases, it will do just fine.

                  Tell this to canonical, they even firefox put in the snap. You know that when choosing “quickly compile something for a flatpack” and “support 10+ distributions”, the developers will choose a flatpack. Which in general looks fine, until you realize that everything is just scored on the mainline of libraries and molded on anything. The most striking example of this is Linphone. just try to compile it…

      • Papamousse ( Frederic@beehaw.org ) 
        5·
        10 months ago

        Old guy here too, used un*x before linux existed in the 90s. I still use a Debian based distro (MX) without systemd and no snap/flatpak/whatever. Just build/compile or install .deb and dependencies. Lastly unfortunately I had to install a flatpak to test “deskflow”, the first time I installed one, I feel dirty now :-(

    • JustEnoughDucks ( JustEnoughDucks@feddit.nl ) 
      10·
      10 months ago

      The few things I don’t like about flatpaks (which become a problem on atomic distros that use almost all flatpak by design):

      • Some types of embedded development is essentially impossible with flatpaks. Try getting the J-link software connected with nrftools and then everything linked to VScodium/codeoss

      • Digital signing simply doesn’t work, won’t work for the foreseeable future, and is not planned to get working,

      • Flatpaks sometimes have bugs for no reasons when their package-manager counterparts don’t (e.g. in KiCAD 8.0, the upper 20% or so of dialog boxes were unclickable with the mouse, but I could select and modify them with the keyboard, only the flatpak version)

      • The status on whether it is still being actively developed or not (at least I hear a fair amount of drama surrounding it)

      But besides those small things, it seem great to me.

      • Allero ( Allero@lemmy.today ) 
        2·
        10 months ago

        Thanks for the input! Yes, there are still certain issues with Flatpaks (for me it was aforementioned VPNs which also don’t work through Distrobox, and it would be quite odd anyway). But overall, they manage most apps well, just as you say.

  • NotSteve_ ( NotSteve_@lemmy.ca ) 
    31·
    10 months ago

    I love installing things from the CLI and prefer to only do it that way but Linux needs a single click install method for applications if it’s ever going to become a mainstream OS. The average person just wants to Google a program, hit download and install. If not that then they want to use a mobile-like App Store.

    Flatpak is kind of perfect at achieving both those things

      • NotSteve_ ( NotSteve_@lemmy.ca ) 
        7·
        10 months ago

        For sure and I agree that should be enough but the average person is not good with computers and they don’t want to learn. They won’t understand the nuances of different distributions of Linux. Like try explaining the difference between a .deb, a .tar.gz, and a .rpm to a person who’s already hésitent about using Linux. Flatpak solves that by just having one download that any Linux install can use

        • thingsiplay ( thingsiplay@beehaw.org ) 
          10·
          10 months ago

          Those mystical average people would probably stay on Windows, if they don’t care or cannot learn basics of other systems. Its really not hard to explain and understand, even for “average person” that there is an universal source for applications and there are packages designed and managed by your operating system. I think its important for people to learn basics and we should teach them, not dumb them down like on Windows. Soon people won’t be able to eat themselves anymore…

  • T Jedi ( Jedi@bolha.forum ) 
    24·
    10 months ago

    About the image: The joke’s on you, I install my flatpaks via the terminal.

    I’ve started using flatpaks more after starting using Bazzite and I liked them more than I expected. As a dev, I still need my work tools to be native, but most of my other needs are well covered by flatpaks.

    Tip: Flatseal is a great config manager for flatpaks’ permissions.

      • Ferk ( Ferk@lemmy.ml ) 
        3·
        10 months ago

        Installing them is not difficult. It’s the same as any other flatpak.

        The problem is when running them (actually, when running any flatpak, not just CLI tools) you need to type out the whole backwards domain thingy that flatpaks use as identifier, instead of having a proper typical and simple executable name like they would have if they were installed normally.

        I end up adding either symlinks or aliases for all my flatpaks because of this reason. After doing that it’s ok… but it’s just an extra step that’s annoying and that the flatpak devs have no interest on fixing apparently.

  • NauticalNoodle ( NauticalNoodle@lemmy.ml ) 
    23·
    10 months ago

    I spent my time fighting AppImages until Canonical started to force Snap on me. I hated Snap so bad it forced me to switch distros. Now I appreciate Flatpak as a result and I don’t find AppImages all that bad, either. Also, I haven’t found myself in dependency-hell nor have I crashed my distro from unofficial Repos in well over a decade.

    -It’s a long way of saying It works for me and it’s not Snap.

  • thingsiplay ( thingsiplay@beehaw.org ) 
    20·
    10 months ago

    Flatpak have their own set of issues. One thing is, that Flatpak applications do not integrate that easily and perfect like a native package. Either rights are to given, you need to know what rights are needed and how to set it up. Theming can be an issue, because it uses its own libraries in the Flatpak eco system instead your current distributions theme and desktop environment.

    But on the other hand, they have actually a permission system and are a little bit sandbox compared to normal applications. Packages often are distributed quickly and are up to date directly from the developers, and usually are not installed with root rights.

    I’m pretty much a CLI guy as well and prefer native packages (Arch based, plus the AUR). But I also use Flatpaks for various reasons, alongside with AppImages.

  • 𝘋𝘪𝘳𝘬 ( Dirk@lemmy.ml ) 
    18·
    10 months ago

    Flatpaks are great for situations where installing software is unnecessary complex or complicated.

    I have Steam installed for some games, and since this is a 32 bits application it would install a metric shit-don of 32 bit dependencies I do not use for anything else except Steam, so I use the Flatpak version.

    Or Kdenlive for video editing. Kdenlive is the only KDE software I use but when installing it, it feels like due to dependencies I also get pretty much all of the KDE desktop’s applications I do not need nor use nor want on my machine. So Flatpak it is.

    And then there is software like OBS, which is known for being borderline unusable when not using the only officially supported way to use it on Linux outside of Ubuntu – which is Flatpak.

    • thingsiplay ( thingsiplay@beehaw.org ) 
      3·
      10 months ago

      And then there is software like OBS, which is known for being borderline unusable when not using the only officially supported way to use it on Linux outside of Ubuntu – which is Flatpak.

      But why is that? I mean just because it is packaged by someone else does not mean its unusable. So its not the package formats issue, but your distribution packaging it wrong. Right? In installed the Flatpak version, because they developers recommended it to me. I’m not sure why the Archlinux package should be unusable (and I don’t want to mess around with it, because I don’t know what part is unusable).

      • 𝘋𝘪𝘳𝘬 ( Dirk@lemmy.ml ) 
        1·
        10 months ago

        But why is that?

        Because the OBS developers say so.

        And since I’m not on Ubuntu, I use the Flatpak version to get OBS as intended bey the OBS developers.

        So its not the package formats issue, but your distribution packaging it wrong. Right?

        Exactly. Most distributions fail hard when it comes to packaging OBS correctly. The OBS devs even threatened to sue Fedora over this.

        https://gitlab.com/fedora/sigs/flatpak/fedora-flatpaks/-/issues/39#note_2344970813

        • thingsiplay ( thingsiplay@beehaw.org ) 
          4·
          10 months ago

          The quoted image does not say so, they do not say the native packaging from your distribution is borderline unusable. That judgement was added by YOU. The devs just state the package on Archlinux is not officially supported, without making a judgement (at least in the quoted image).

          As for the Fedora issue, that is a completely different thing. That is also Flatpak, so its not the package format itself the issue. Fedora did package the application in Flatpak their own way and presented it as the official product. That is a complete different issue! That has nothing to do with Archlinux packaging their own native format. Archlinux never said or presented it as the official package either and it does not look like the official Flatpak version.

          So where does the developers say that anything that is not their official Flatpak package is “borderline unusable”?

          • 𝘋𝘪𝘳𝘬 ( Dirk@lemmy.ml ) 
            1·
            10 months ago

            The quoted image does not say so

            It does exactly say so. Flatpak is the only supported and official method of installation when you’re not using Ubuntu.

            As for the Fedora issue, that is a completely different thing. That is also Flatpak, so its not the package format itself the issue.

            Exactly. And the Flatpak version from Fedora was unusable.

            So where does the developers say that anything that is not their official Flatpak package is “borderline unusable”?

            They don’t. It’s just unsupported.

    • Obin ( Obin@feddit.org ) 
      2·
      10 months ago

      Flatpaks are great for situations where installing software is unnecessary complex or complicated.

      That’s my main use for flatpaks too. Add to that any and all closed source software, because you can’t trust that without a sandbox around it.

      Recently I’ve moved from using flatpak for electron apps and instead have a single flatpak ungoogled chromium instance I use for PWAs.

    • dropped_packet ( dropped_packet@lemmy.zip ) 
      1·
      10 months ago

      This is the main benefit. However, i’m finding the software I use requires less dependencies and libraries these days.

      I barely even use flatpaks anymore. Almost everything is in official repos. I couldn’t tell you the last time I had a dependency conflict.

  • the_wiz ( the_wiz@feddit.org ) Banned
    17·
    10 months ago

    Flatpaks together with “immutable” distributions, Wayland and systemd are a heresy, a crime against the UNIX principles, a disgrace in the eyes of of SED and AWK. REPENT! Save your immortal core dumps and return to the one true /home !

  • MoondropLight ( MoondropLight@thelemmy.club ) 
    17·
    10 months ago

    Perhaps ironically, this is mocking a strawman. Flatpacks can be installed and managed using the terminal! Not only that but Linux-Distros have had graphical package managers for decades.

    The primary reason that distros have embraced flatpack / snap / appimage is that they promise to lower the burden of managing software repositories. The primary reason that some users are mad is that these often don’t provide a good experience:

    • they are often slower to install/start/run
    • they have trouble integrating with the rest of the system (ignoring gtk/qt themes for example)
    • they take a lot more space and bandwidth

    Theoretically they are also more secure… But reality of that has also been questioned. Fine grained permissions are nice, but bundling libraries makes it hard to know what outdated libraries are running on the systems.

  • corsicanguppy ( corsicanguppy@lemmy.ca ) English
    16·
    10 months ago

    Former OS security here (I worked at an OS vendor who sold an OS or two and my job involved keeping it secure).

    Fuck no.

    Sorry if that makes you downvote, but it doesn’t make them safer.

      • zarenki ( zarenki@lemmy.ml ) 
        12·
        10 months ago

        A few reasons security people can have to hesitate on Flatpak:

        • In comparison to sticking with strictly vetted repos from the big distros like Debian, RHEL, etc., using Flathub and other sources means normalizing installing software that isn’t so strongly vetted. Flathub does at least have a review process but it’s by necessity fairly lax.
        • Bundling libraries with an application means you can still be vulnerable to an exploit in some library, even if your OS vendor has already rolled out the fix, because of using Flatpak software that still loads the vulnerable version. The freedesktop runtimes at least help limit the scope of this issue but don’t eliminate it.
        • The sandboxing isn’t as secure as many users might expect, which can further encourage installing untrusted software.

        By a typical home user’s perspective this probably seems like nothing; in terms of security you’re still usually better off with Flatpak than installing random AUR packages, adding random PPA repos, using AppImage programs, installing a bunch of Steam games, blindly building an unfamiliar project you cloned from github, or running bash scripts you find online. But in many contexts none of that is acceptable.

        • eta ( eta@feddit.org ) English
          5·
          10 months ago

          I thought flatpaks were created to make packaging easier, not to solve all security issues. Still sounds like a win to me.

    • 𝕛𝕨𝕞-𝕕𝕖𝕧 ( jwmgregory@lemmy.dbzer0.com ) 
      10·
      10 months ago

      one of my least favorite things about arch and other rolling distros is that yay/pacman will try and recompile shit like electron/chromium from source every few days unless you give it very specific instructions not to - which is annoying as shit bc compiling the entirety of chrome from source takes hours even with decent hardware.

      granted, i fucking hate google products too but if you’re doing any web dev it’s necessary sometimes.

      idk im definitely willing to admit i might be the idiot here. managing your packages with pacman might just be routine to some people. to me arch is the epitome of classic bad UX in an open source project. it’s like they got too focused on being cmatrix-style terminal nerds and forgot to make their software efficiently useable outside of 5 very specific people’s workflows. it’s not even the terminal usage that is bad about arch. plenty of things are focused on that and… don’t do it shittily? idk…

      edit: yes to all the arch fanboy’s points in response to me. i used to be super into arch and am aware of the fact that this isn’t explicit behavior but to act like it doesn’t happen in a typical arch user experience is disingenuous. i also disagree with the take that arch doesn’t endorse this outright with its design philosophy, bc it does. the comparison of the AUR to other, similar things like PPAs doesn’t land for me bc PPAs aren’t integrated into the ecosystem nearly as much as AUR is with arch. you can’t tell people to just grab the binaries or not use AUR whenever it’s convenient to blame the user, when arch explicitly endorses a philosophy amicable to self-compilation and also heavily uses the AUR even in their own arch-wiki tutorials for fairly basic use cases. arch wants to have its cake and eat it too and be a great DIY build it yourself toolkit while also catering to daily driver use and more generalist users. don’t get me wrong, it’s the best attempt at such a thing i’ve seen - but at a certain point you have to ask if the premise makes sense anymore. in the case of arch, it doesn’t and it causes several facets of the ecosystem to flounder from a user perspective. the arch community’s habit of shouting “skill issue” at people when they point out legitimate issues with the design philosophy bugs the fuck out of me. this whole OS is a camel.

        • 𝕛𝕨𝕞-𝕕𝕖𝕧 ( jwmgregory@lemmy.dbzer0.com ) 
          3·
          10 months ago

          sometimes you’re working with particular releases or builds that don’t, but like i said i might be the idiot lol.

          i like the concept of arch. i don’t like the way i need to come up with a new solution for how im managing my packages virtually every few days that often requires novel information. shit, half the time you boot up an arch system if you have sufficient # of packages there is 9/10 times a conflict when trying to just update things naively. like i said it’s cool on paper and im sure once you use it as a daily driver for awhile it just becomes routine but it’s more the principle of the user experience and its design philosophy that i think might be poor.

          arch is for techies in the middle of the bell curve imo… people on the left and the right, when it comes to something as simple as managing all my packages and versions, want something that just worksTM - unless i specifically want to fuck with the minutiae.

          • Feyd ( Feyd@programming.dev ) 
            4·
            10 months ago

            conflict when trying to just update things naively

            Sounds like AUR problems. IMO using AUR helpers that tie AUR packages to your full system update command is a trap. AUR never professed to be a stable repository (in fact it’s the opposite). AUR has a place, but it should be used sparingly and thoughtfully.

            • 𝕛𝕨𝕞-𝕕𝕖𝕧 ( jwmgregory@lemmy.dbzer0.com ) 
              1·
              10 months ago

              i agree with this but this isn’t the reality of the arch ecosystem. AUR is explicitly promoted on the wiki for a large amount of tasks the average user is going to do. it feels skeevy to acknowledge the problems with the AUR and then abscond arch’s responsibility for them, because the AUR is not like PPAs or anything. it is significantly more integrated into the ecosystem.

              • Feyd ( Feyd@programming.dev ) 
                4·
                10 months ago

                The wiki article :

                • specifically says that packages are not thoroughly vetted
                • does not recommend using yay or another AUR helper (which is the primary thing I recommend against)
                • has a frequently asked question section that is fairly technical and should indicate that it is not for the faint of heart

                The aur helper wiki has a fun red disclaimer at the top that no one reads

                • 𝕛𝕨𝕞-𝕕𝕖𝕧 ( jwmgregory@lemmy.dbzer0.com ) 
                  1·
                  10 months ago

                  you (rhetorical you, not you) can recommend not using the AUR officially all you want. it doesn’t mean anything if a large number of tasks the average user is going to do require AUR packages. i’m kind of drunk rn but i’ll go find specific pages of the wiki that demonstrate what i’m talking about, i stg this isn’t nothing. the core system itself can entirely be managed with pacman, yes, but the average user is going to be doing a lot more than just that. there is a certain discord in the messaging of arch as a whole.

                  this is exactly my point. arch can either be a nuts and bolts distro or it can be made for normies. it can’t be both.

      • ayaya ( ayaya@lemdro.id ) English
        8·
        10 months ago

        All of the normal Arch packages are pre-built, so the only way you’d be compiling things that often is if you installed a large amount of things from the AUR. Make sure you get the bin versions instead of git versions.

        The google-chrome and chromium packages are already a binaries so my guess is you need ungoogled-chromium-bin. You can also use the Chaotic AUR repo to get pre-built binaries of a lot of the most common AUR packages. But ideally you should avoid using the AUR when it’s not necessary.

        While using the AUR is common, it’s a bit frustrating you are blaming Arch for your experience. If you only use pacman you would never compile anything, or have very many conflicts. It’s like if you added 20 different PPAs on Ubuntu and then complained about the problems that arose from that.

      • frozenspinach ( frozenspinach@lemmy.ml ) English
        4·
        10 months ago

        one of my least favorite things about arch and other rolling distros is that yay/pacman will try and recompile shit like electron/chromium from source every few days unless you give it very specific instructions not to

        My understanding is that constantly triggering compiling like that shouldn’t be happening in any typical arch + pacman situation. But it can happen in AUR. If it does, I think it’s a special case where you should be squinting and figuring out what’s going on and stopping the behavior; it’s by no means philosophically endorsed as the usual case scenario for packages on arch.

        There’s certainly stuff about Arch that’s Different™ but nothing about the package manager process is especially different from, say, apt-get or rpm in most cases.

        • 𝕛𝕨𝕞-𝕕𝕖𝕧 ( jwmgregory@lemmy.dbzer0.com ) 
          1·
          10 months ago

          saying it can happen in the AUR feels disingenuous to me when you consider how integrated the AUR is to the arch ecosystem. this is a genuine complaint from a user perspective and is an issue with the design philosophy imo. it is a special case but it’s so frequent as to be annoying, is my point.

          not sure why everyone is replying like i’m unaware and totally ignoring the actual grievance i have. im very well aware of pacman and yay’s intended behaviors, i just think they’re shit in some cases. idk if people who say this have never tried to daily drive arch before or something but the AUR is absolutely not optional unless you want to constantly hand roll your own shit. see my edit to the original comment.

          • frozenspinach ( frozenspinach@lemmy.ml ) English
            1·
            10 months ago

            Feyd did a pretty good job of outlining the AUR disclaimers in a different comment so I won’t do that here. It’s true that Arch won’t stop you from shooting yourself in the foot, but again it’s nuts to claim that routine compiling is the usual case for all rolling distros and belies your claim that you’re familiar with usual case experience. There’s absolutely no routine experience where you’re regularly compiling.

            I’ve used debian and apt-get most of my life, I’ve used arch on a pinetab 2 for about 6 months, regularly playing with pacman and yay and someone who’s never met me is saying I’m a fanboy for being familiar with linux package management. 🤷‍♂️

    • frozenspinach ( frozenspinach@lemmy.ml ) English
      4·
      10 months ago

      iit: nerds unable to comprehend that building a piece of software from source in not something every person can do

      huh? Using package managers almost never involves compiling. It’s there as a capability, but the point is to distribute pre-compiled packages and skip that step in the vast majority of cases.

  • data1701d (He/Him) ( data1701d@startrek.website ) English
    14·
    10 months ago

    I’d take a well-maintained native package for my distro over a Flatpak, but sometimes, a Flatpak is just the the easiest way to get the latest version of an application working on Debian without too much tinkering - not always no tinkering, but better than nothing.

    This is especially true of GIMP - Flatpak GIMP + Resynthesizer feels like the easiest way to experience GIMP these days. Same with OBS - although I have to weather the Flatpak directory structure, plugins otherwise feel easier to get working than the native package. The bundled runtimes are somewhat annoying, but I’m also not exactly hurting for storage at the moment - I could probaby do to put more of my 2 TB main SSD to use.

    I usually just manage Flatpaks from the terminal, though I often have to refresh myself on application URLs. I somewhat wish one could set nicknames so they need not remember the full name.