Please tell your friends about federated social media site that speaks several fediverse protocols thus serving as a hub uniting them, hubzilla.eskimo.com, also check out friendica.eskimo.com, federated
macroblogging social media site, mastodon.eskimo.com a federated microblogging site, and yacy.eskimo.com an uncensored federated search engine. All Free!
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.
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(TM) but nothing about the package manager process is especially different from, say, apt-get or rpm in most cases.
The one "good" thing about containers is that you keep your DLL-like mess localized. Just one or a few related apps run in the container and if they want / need some weird library version, they can have it without breaking other things.
Yeah but that’s a huge benefit already. I am not savvy enough in the development side to know whether that’s a reward that justifies any of the frustrations people have. Personally I don’t really mind varying methods to do any one job, as long as it’s well-documented, easily managed, and does not create a higher load on the system in any respect.
I view the delays during launch and the extra time spent during updates as a "load on the system."
Also, it entirely depends on your deployment environment. I develop system images that go out on thousands of devices deployed in "Cybersecuity Sensitive" environments, meaning: we have to document what's on the system and justify when anything in the SBOM (list of every software package installed on the machine) is identified as having any applicable CVEs... soooo.... keeping old versions of software anywhere on the machine is a problem (significant additional documentation load) for those security audits. Don't argue with logic, these are our customers and they have established their own procedures, so if we want their money, we will provide them with the documentation they demand, and that documentation is simplest when EVERYTHING on the system has ALL the latest patches.
The most secure systems are those that don't do anything at all. You can't hack a brick.
Hey, like I said, great info for me to learn because I don’t know. I was only saying that I don’t mind because my situation is fine with it. Thanks for the info, it’s interesting. I’m sure for any situation there’s a better and worse solution and I’m sure that for any solution, there’s a situation that either likes or dislikes the approach.
Yeah, I agree. Canonical seems to think "snaps are for everyone" so, for both my personal and professional applications they have decided: "Canonical is not for me."
I seem to have constant issues with AppImages. Every single one I have currently won't open. I get an error message relating to either qT or GTK. Tried searching for the error and get a bunch of old forum threads talking about either not being compatible with Wayland at all, or comments stating that the one specific AppImage in question must have been "packaged badly". Thankfully, nothing 'mission critical' for me is an AppImage currently, but it is quite upsetting that I have the most problems with the supposed "just works" app packaging/distribution option.
i mostly use them for proprietary stuff or for software that is incredible painful to package (mostly electron apps). i will probably never use them for anything that actually matters but i also use rolling release distros everywhere so latest release is never too far. for testing latest version of any software i prefer appimages since they are simpler and don't need a messy setup as flatpak, but i also won't use them pass the testing phase and i prefer packaging the software if possible.
snaps, on the other hand, will never go near any of my systems. not even by accident
The thing that grinds my gears is when I'm doing an apt update and then it goes off to check on the snaps and drags the process out a lot longer. It doesn't help that they're slower to load the apps too. Then there's the additional attack surfaces to accumulate more CVE reports (and more out of date library versions on your system begging for a security patch...) Mostly, I just purge snap support from Ubuntu these days - but for people who don't notice / mind such things, you do you - maybe they'll eventually improve the lightweight container system until the rest of us don't notice it either.
main selling points are isolation and having the latest version directly from developers without having to wait for your distro to package/update it.
both are debatable since they are not as good as promoted (isolation doesn't always work correctly and it's a mess to configure it once you use anything different than the more mainstream distros) or goes against the historical preference (using bundled everything instead of cooperating with your distro packages and trusting every individual over trusting your distro as a whole) but having the latest version on any distro without having to wait is a popular need so they gained traction quite fast. this might make little sense for rolling release distros (arch, nix) but it's helpful if you have a stable base (years old debian) but need the latest feature on an specific application or have to use very specific libraries that are not packaged on the main distro and would require complex upgrades
There was a few years where I pretty much only used Flatpaks because I was scared of the terminal. But now that I've learned how to use the terminal, it's so much more convenient because I can quickly update all my applications all in one place without having to open a separate app. Plus, some Flatpaks can fall really behind on software updates.
There might be a Linux userbase someday where no one over than developers actually knows how to use the terminal, because users can run everything they want without a command line, but maybe that's actually a good thing because it'll drive up how many people use a Linux distro.
With Windows and Mac, there's a shareholder incentive to enshittify. With Linux, if a distro goes bad and gets commercialized, there's always another distro people can move to, not to mention there's no financial incentive. The more people get on Linux, the less power these tech companies have. Personally, that and privacy are what drew me to Linux much more so than being able to tinker or fine-tune my experience.
There might be a Linux userbase someday where no one other than developers actually knows how to use the terminal, because users can run everything they want without a command line
Ideally, all the essential terminal commands could be replicated in a user-friendly GUI-applicable manner. Don’t ever have to remove the terminal for those that enjoy it, but if we could have a magic world where even the failure states could be navigated with little to no prior knowledge required and it gets everyone away from Windows and Mac for good, I’m all for it.
If we’re talking about enterprise-grade, five-nines reliability: I want the absolute simplest, bare-bones, stripped down, optimized infra I can get my hands on.
If we’re talking about my homelab or whatever else non-critical system: I’m gonna fuck around and play with whatever I feel like.
Could things like this go in linuxmemes? Memes are fun but it would be nice to keep this a place for actual information. And no, this is not a comment on what it's saying, I'm just tired of so many memes.
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.
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.
Immutable OSes are difficult to use for coding or other tasks that include installing many terminal utilities and for that reason, I don't recommend them and certainly don't want them to be the future of Linux distros. And if I'm going to create a container running a different distro to install and run the apps I want to use, then I may as well use that distro on my host.
Either it did something it shouldn't, or the system updated Nvidia drivers every time for no apparent reason. I have an Nvidia GPU, running proprietary drivers, and haven't ever witnessed anything of the kind.
I wouldn't say I have had a problem with snaps or flatpacks either. I uninstall all snaps first thing when I install recent Ubuntu versions, and I have never messed with flatpacks, so... no problems.
You just move to user directory installation of most tools via brew on Linux. It's not difficult. The Bazzite distro handles all this incredibly well via brew, flatpaks, and distrobox.
I've no real preference so long as my PC starts stuff. The reason I avoid flatpaks is because I have at some point acquired the habit of anything I install that's not an appimage I pretty much launch from the terminal and I remember trying flatpaks and them having names like package.package.nameofapp-somethingelse and I can't keep that in my head.
Flatpaks aim to be a middle ground between dependency hell and "let's pull in the universe" bloat.
Applications packaged as Flatpaks can reference runtimes to share "bases" with other applications, and then provide their own libraries if they need anything bespoke on top of that.
And they are still, in my experience, slow to load, a cumbersome addition to the update process, and often un-necessary.
Don't get me wrong, if you're in a tight spot and can't make two significant software packages work in a distribution due to conflicting library version requirements... some kind of lightweight container solution is attractive, expedient, and better than just not supporting one of the packages. But, my impression is that a lot of stuff has been moved into flatpak / snap / etc. just because they can. I don't think it's the best, or even preferred, way to maintain software - for the desktop environment.
(Returns to checking on his Docker containers full of server apps on the R-Pi farm...)
I'm running an immutable distro at the moment (GNOME OS), and I felt no loss of performance due to Flatpaks. Snaps, on the other hand, do have a perceivably longer launch time.
Given that it's an immutable distro, everything I need needs to be either a Flatpak, a Snap, an Appimage or an extracted tarball, otherwise it runs in a container. The advantage of this system is stability and making the host incorruptible, as well as the ability to very easily roll back updates or failed systemd-sysext layers.
Not everything can run in a Flatpak at the moment, but we're hoping the evolution in Flatpak, XDG portals as well as encouraging developers to use the available XDG portals can make this a possibility someday. Namely, IDEs don't run that well in a Flatpak, but GNOME Builder has proven that it's 100% possible with the currently available XDG portals as well as connecting your IDE or editor to a container.
Ubuntu Core, based on Snaps, is very much not ready for prime time IMO. It's kind of a mess outside of server use.
Look instead at Fedora Silverblue, Vanilla OS, and for the bleeding edge of immutable systems, GNOME OS.
KDE is about to launch their analogue to GNOME OS relatively shortly, named "Project Banana". These two are not exactly distros as they do not distribute the kernel, they are simply platforms that layer a bunch of images together to create a stable, reproducible system. There's also OpenSuSE Aeon, but I don't like its style of immutability as it's immutable by rootfs lock-out rather than immutable by image.
As for advice, learn how to use Distrobox / Toolbx containers. If you're a developer, this is where you will be working.
Immutable Linux is still young, and a lot of software isn't written with it in mind, so expect some growing pains.
Thanks. In the past I have worked in Slackware, and even had Gentoo on my home system for a couple of years, but otherwise I've been fully saturated in Debian and its children - so that's my "comfort zone." I used to like KDE, but drifted away from it when I got a 4K screen notebook and KDE hadn't figured out resolution scaling yet, while Ubuntu/Unity had. I never quite warmed up to GNOME, but definitely have done my time with it. XFCE has matured enough for me to daily drive it without too much pain now, and I love the ways it can be de-featured (don't want a launcher bar? Don't run it, nothing else breaks.)
Server-side, I have been filling my Raspberry Pis with Docker containers for a while now... it's not completely alien, but I do kind of tend to "set it and forget it" when it comes to container deployments.
Fast storage is one of the cheapest components of modern PCs so I'm always surprised when Flatpak file size is brought up. It's not something I worry about very much.
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).
I've actually been discussing the idea of Flatpaks offering "terminal aliases", similar to what Snaps do, with some people involved in Flatpak. It's something that could happen in the future, but for now, you can totally create an alias to run a Flatpak from a single word, it's just a PITA.
It's a neat concept. The distro-agnostic aspect is definitely a plus for some people but I still prefer distro-specific installation methods. The only time I would seek out the Flatpak version of a particular software is when it's the only version available.
flatpaks are fine and useful, i just wish we didn't move into a scenario where applications that used to be easily available in distro repos start moving away from them and are only available through flatpaks. distro packages are just so much more efficient in every way. flatpaks are easier on maintainers and developers but that comes at a cost to the user. i have about a dozen or less flatpak apps installed and already i have to download at least 2 gigs of updates each week. i run debian
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.
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
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.
To reiterate, I don't think there is anything wrong with using the AUR. I think that using an AUR helper that ties updating AUR packages to your pacman -Syu is a trap that people keep falling into despite the warnings in the wiki.
I like flatpak, but I can't download Flathub flatpak applications and (specially) Flathub flatpak runtimes from my phone. I hope Flathub learns from F-Droid
I'm happy to use Flatpaks but the annoyances I've had are like when one application says to use you'll need to point to the binary of another application that it depends on but very understandably doesn't package together, figuring that out to me can be annoying so I'll switch to a regular installation and it all just works together no fuss, no flatseal, no thinking about it really. Also some applications where it's really nice to launch from the terminal especially with arguments or just like the current working directory and with Flatpaks instead of just right off the bat it's application name and hit enter, Flatpak hope you remember the whole package name
As long as software is available in the Software Manager to be installed that way... I don't care what format it's in.
But don't make normies go to the terminal. It's inhumane, and really does not help the masses get away from big tech - which is a worthier goal than keeping your software terminal-only.
While I wouldn't want flakpak going deep into the OS I think the advantage of using them on the desktop is obvious. Developers can release to multiple dists from a single build and end users get updates and versions immediately rather than waiting for the dist to update its packages. Plus the ability to lock the software down with sandboxes.
The tradeoff is disk consumption but it's not really that big of a deal. Flatpaks are layered so apps can share dependencies. e.g. if the app is GNOME it can share the GNOME runtime with other apps and doesn't need to ship with its own.
FTFY: Flatpaks are layered so apps can share dependencies. e.g. if the app is GNOME 4.2.11.3 it can share the GNOME 4.2.11.3 runtime with other apps and doesn't need to ship with its own, but every app requires a different GNOME version anyway
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.
As far as I know, I've only installed Flatpaks using the terminal. The most annoying thing about them for me is having to type out the fully-qualified name of the software (e.g. org.mozilla.firefox instead of just firefox), which is a very terminal-specific issue, LOL!
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.
Yes, Flatpak is overall a better approach when compared to AppImages, since being dependent on a known runtime ensures the program will run whenever the runtime is available.
What I wish they would add is a way to run the flatpak in a portable way. Because as it stands, AppImages is the only option for that. Flatpak doesn't really allow to have a portable installation in a pendrive, for example. At the moment there's no replacement for AppImage in such use cases, which is a pity.
But there's no fundamental technical design roadblock in flatpak that would prevent it from supporting this in the future, imho. theoretically one could create a program that mounts the flatpak file into a ramfs layered with the runtime and run it.
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).
Yeah that's why I'm a bit weary of switching to Wayland, so many apps still seem unsupported, or have issues, whereas on X11 everything for me just works. Plus, the two DE's I'd actually consider using either don't have Wayland support at all or have very early experimental support (Cinnamon and Xfce) so it'll still be a while for me before I am able to consider switching to Wayland, assuming everything else works.
Size and gnome/GTK dependencies are main reasons why I don't use Flatpaks (I have nothing against gnome though, it just pulls in too much and KDE is worse in this regards, which is why I use Sway and River)
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. 🤷♂️
The unofficial OBS Studio Flatpak on Fedora Flatpaks is, seemingly, poorly packaged and broken, leading to users complaining upstream thinking they are...
I don't actually know if it is a Wayland issue - most of those forum posts are like 3 years old... And I have definitely used these same AppImages in the past on Wayland without issue. I think the AppImages are expecting some specific dependency to be installed on my system that is no longer installed due to updates. (which I thought was counter to the entire point of an AppImage? I thought it was supposed to be kinda like Flatpak where it has it's dependencies in the image? Maybe I just misunderstood AppImage...)
To give you some hope, my Distro switched to Wayland as default a little over a year ago (i think) and I have not been running into problems (outside this AppImage problem, if it is indeed a Wayland issue, which I cannot confirm or deny).
Flatpak being securely sandboxed by default is both its biggest strength and its worst point of contention. The XDG is still scrambling to replicate the permission requests paradigm from Android on the Linux desktop.
Not a fan for a few reasons. Flathub (as far as I know) works on the app store model where developers offer their own builds to users, which is probably appealing to people coming from the Windows world who view distros as unnecessary middlemen, but in the GNU/Linux world the distro serves an important role as a sort of union of users; they make sure the software works in the distro environment, resolve breakages, and remove any anti-features placed in there by the upstream developers.
The sandboxing is annoying too, but understandable.
Despite this I will resort to a flatpak if I'm too lazy to figure out how to package something myself.
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"?
I'm a big fan of the idea of sandboxed apps. Flatpak is not great as it compromises sandboxing for compatibility (both with distros and apps) and also it's quite stagnant now. But there are no other options anyway, so I use it.
War with who? I'm posting this from Kubuntu and I'd happily agree with you that Snap should fuck off and die. (In particular, the backend being controlled by Canonical makes it objectively bad compared to Flatpak.) Even among people like me who tolerate Snap (for now...), I really don't think you're gonna find anybody who actually likes it, let alone enough to champion it.
Oh, hi! I also use Kubuntu, but I love Snaps! I use them for everything. I even tried to use a Snap-version of the kernel, but it completely destroyed my system so I had to reinstall... but other than that, they're great.
I "grew up" with Slackware, so I definitely understand the dependency issue.
I like flatpaks (and similar) for certain "atomic" pieces of software, like makemkv. For more "basic" software, like, say, KDE, I want it installed natively.
Just another tool in the toolbox. Use it or not, up to the user. I've even seen Slackware users who say they use Flatpak to ward off dependency rabbit holes.
frozenspinach
Unknown parent • • •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.
frozenspinach
Unknown parent • • •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(TM) but nothing about the package manager process is especially different from, say, apt-get or rpm in most cases.
AndrewZabar
in reply to shrewdcat • • •MangoCats
in reply to AndrewZabar • • •AndrewZabar
in reply to MangoCats • • •MangoCats
in reply to AndrewZabar • • •I view the delays during launch and the extra time spent during updates as a "load on the system."
Also, it entirely depends on your deployment environment. I develop system images that go out on thousands of devices deployed in "Cybersecuity Sensitive" environments, meaning: we have to document what's on the system and justify when anything in the SBOM (list of every software package installed on the machine) is identified as having any applicable CVEs... soooo.... keeping old versions of software anywhere on the machine is a problem (significant additional documentation load) for those security audits. Don't argue with logic, these are our customers and they have established their own procedures, so if we want their money, we will provide them with the documentation they demand, and that documentation is simplest when EVERYTHING on the system has ALL the latest patches.
The most secure systems are those that don't do anything at all. You can't hack a brick.
AndrewZabar
in reply to MangoCats • • •MangoCats
in reply to AndrewZabar • • •Crozekiel
Unknown parent • • •frozenspinach
Unknown parent • • •machinya [it/its, fae/faer]
in reply to shrewdcat • • •i mostly use them for proprietary stuff or for software that is incredible painful to package (mostly electron apps). i will probably never use them for anything that actually matters but i also use rolling release distros everywhere so latest release is never too far. for testing latest version of any software i prefer appimages since they are simpler and don't need a messy setup as flatpak, but i also won't use them pass the testing phase and i prefer packaging the software if possible.
snaps, on the other hand, will never go near any of my systems. not even by accident
sunzu2
Unknown parent • • •All of this is true and precisely zero normies care about any of it.
The fact that I can put my ~~idiots~~ family on any modern distro and tell them to use the app store alone makes flatpaks king of the app management
MaysaMayako
in reply to shrewdcat • • •Personally I am okay with them actually. I use several on my system and having each app allowed to have different permissions is super useful.
But also I like things that are directly installed cause they seem just a tad faster performance wise.
MangoCats
in reply to MaysaMayako • • •MaysaMayako
in reply to MangoCats • • •machinya [it/its, fae/faer]
Unknown parent • • •main selling points are isolation and having the latest version directly from developers without having to wait for your distro to package/update it.
both are debatable since they are not as good as promoted (isolation doesn't always work correctly and it's a mess to configure it once you use anything different than the more mainstream distros) or goes against the historical preference (using bundled everything instead of cooperating with your distro packages and trusting every individual over trusting your distro as a whole) but having the latest version on any distro without having to wait is a popular need so they gained traction quite fast. this might make little sense for rolling release distros (arch, nix) but it's helpful if you have a stable base (years old debian) but need the latest feature on an specific application or have to use very specific libraries that are not packaged on the main distro and would require complex upgrades
NostraDavid
in reply to shrewdcat • • •17lifers
in reply to NostraDavid • • •MystValkyrie
in reply to shrewdcat • • •There was a few years where I pretty much only used Flatpaks because I was scared of the terminal. But now that I've learned how to use the terminal, it's so much more convenient because I can quickly update all my applications all in one place without having to open a separate app. Plus, some Flatpaks can fall really behind on software updates.
There might be a Linux userbase someday where no one over than developers actually knows how to use the terminal, because users can run everything they want without a command line, but maybe that's actually a good thing because it'll drive up how many people use a Linux distro.
With Windows and Mac, there's a shareholder incentive to enshittify. With Linux, if a distro goes bad and gets commercialized, there's always another distro people can move to, not to mention there's no financial incentive. The more people get on Linux, the less power these tech companies have. Personally, that and privacy are what drew me to Linux much more so than being able to tinker or fine-tune my experience.
otacon239
in reply to MystValkyrie • • •Ideally, all the essential terminal commands could be replicated in a user-friendly GUI-applicable manner. Don’t ever have to remove the terminal for those that enjoy it, but if we could have a magic world where even the failure states could be navigated with little to no prior knowledge required and it gets everyone away from Windows and Mac for good, I’m all for it.
captainlezbian
in reply to MystValkyrie • • •gravitas_deficiency
Unknown parent • • •It’s extremely context-dependent.
If we’re talking about enterprise-grade, five-nines reliability: I want the absolute simplest, bare-bones, stripped down, optimized infra I can get my hands on.
If we’re talking about my homelab or whatever else non-critical system: I’m gonna fuck around and play with whatever I feel like.
Lovable Sidekick
in reply to shrewdcat • • •jwmgregory
in reply to frozenspinach • • •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.
jwmgregory
in reply to frozenspinach • • •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.
Allero
in reply to frozenspinach • • •Wow that's actually big difference, thanks for bringing it up!
Good news, though, is that you are free to install Gimp as a native package, and use Flatpaks for the rest.
BlameTheAntifa
Unknown parent • • •Ziglin (it/they)
Unknown parent • • •ztwhixsemhwldvka
in reply to shrewdcat • • •geneva_convenience
in reply to ztwhixsemhwldvka • • •sudo_halt
in reply to ztwhixsemhwldvka • • •✋😕🤚
Absolute Dogshit
Eyck_of_denesle
Unknown parent • • •Eyck_of_denesle
Unknown parent • • •VitabytesDev
Unknown parent • • •Allero
in reply to Eyck_of_denesle • • •Huh?
Either it did something it shouldn't, or the system updated Nvidia drivers every time for no apparent reason. I have an Nvidia GPU, running proprietary drivers, and haven't ever witnessed anything of the kind.
Allero
in reply to Eyck_of_denesle • • •PillowD
in reply to shrewdcat • • •MangoCats
in reply to PillowD • • •wewbull
in reply to PillowD • • •Axum
in reply to VitabytesDev • • •BeardedGingerWonder
Unknown parent • • •spookedintownsville
in reply to shrewdcat • • •setVeryLoud(true);
in reply to spookedintownsville • • •Flatpaks aim to be a middle ground between dependency hell and "let's pull in the universe" bloat.
Applications packaged as Flatpaks can reference runtimes to share "bases" with other applications, and then provide their own libraries if they need anything bespoke on top of that.
MangoCats
in reply to setVeryLoud(true); • • •And they are still, in my experience, slow to load, a cumbersome addition to the update process, and often un-necessary.
Don't get me wrong, if you're in a tight spot and can't make two significant software packages work in a distribution due to conflicting library version requirements... some kind of lightweight container solution is attractive, expedient, and better than just not supporting one of the packages. But, my impression is that a lot of stuff has been moved into flatpak / snap / etc. just because they can. I don't think it's the best, or even preferred, way to maintain software - for the desktop environment.
(Returns to checking on his Docker containers full of server apps on the R-Pi farm...)
setVeryLoud(true);
in reply to MangoCats • • •I'm running an immutable distro at the moment (GNOME OS), and I felt no loss of performance due to Flatpaks. Snaps, on the other hand, do have a perceivably longer launch time.
Given that it's an immutable distro, everything I need needs to be either a Flatpak, a Snap, an Appimage or an extracted tarball, otherwise it runs in a container. The advantage of this system is stability and making the host incorruptible, as well as the ability to very easily roll back updates or failed systemd-sysext layers.
Not everything can run in a Flatpak at the moment, but we're hoping the evolution in Flatpak, XDG portals as well as encouraging developers to use the available XDG portals can make this a possibility someday. Namely, IDEs don't run that well in a Flatpak, but GNOME Builder has proven that it's 100% possible with the currently available XDG portals as well as connecting your IDE or editor to a container.
MangoCats
in reply to setVeryLoud(true); • • •Not mocking: can you share any good guides to practical immutable systems?
What I observed of Ubuntu Core made a strong "not ready for prime time, and even if it was I don't want it" impression on me.
setVeryLoud(true);
in reply to MangoCats • • •Ubuntu Core, based on Snaps, is very much not ready for prime time IMO. It's kind of a mess outside of server use.
Look instead at Fedora Silverblue, Vanilla OS, and for the bleeding edge of immutable systems, GNOME OS.
KDE is about to launch their analogue to GNOME OS relatively shortly, named "Project Banana". These two are not exactly distros as they do not distribute the kernel, they are simply platforms that layer a bunch of images together to create a stable, reproducible system. There's also OpenSuSE Aeon, but I don't like its style of immutability as it's immutable by rootfs lock-out rather than immutable by image.
As for advice, learn how to use Distrobox / Toolbx containers. If you're a developer, this is where you will be working.
Immutable Linux is still young, and a lot of software isn't written with it in mind, so expect some growing pains.
beastlykings
in reply to setVeryLoud(true); • • •I'm on silverblue, well, bluefin, specifically.
So far so happy 🤷♂️
MangoCats
in reply to setVeryLoud(true); • • •Thanks. In the past I have worked in Slackware, and even had Gentoo on my home system for a couple of years, but otherwise I've been fully saturated in Debian and its children - so that's my "comfort zone." I used to like KDE, but drifted away from it when I got a 4K screen notebook and KDE hadn't figured out resolution scaling yet, while Ubuntu/Unity had. I never quite warmed up to GNOME, but definitely have done my time with it. XFCE has matured enough for me to daily drive it without too much pain now, and I love the ways it can be de-featured (don't want a launcher bar? Don't run it, nothing else breaks.)
Server-side, I have been filling my Raspberry Pis with Docker containers for a while now... it's not completely alien, but I do kind of tend to "set it and forget it" when it comes to container deployments.
Toribor
in reply to spookedintownsville • • •HugeNerd
in reply to spookedintownsville • • •Unlike that apostrophe.
thingsiplay
Unknown parent • • •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).
Crabhands
in reply to shrewdcat • • •DanWolfstone
Unknown parent • • •j0rge
in reply to Allero • • •Install GNU Image Manipulation Program on Linux | Flathub
FlathubsetVeryLoud(true);
in reply to BeardedGingerWonder • • •MangoCats
Unknown parent • • •jabeez
in reply to shrewdcat • • •HugeNerd
in reply to shrewdcat • • •SpiceDealer
in reply to shrewdcat • • •beleza pura
in reply to shrewdcat • • •seralth
in reply to beleza pura • • •jwmgregory
Unknown parent • • •Feyd
in reply to jwmgregory • • •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
AUR helpers - ArchWiki
wiki.archlinux.orgjwmgregory
in reply to Feyd • • •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.
Feyd
in reply to jwmgregory • • •brianary
Unknown parent • • •MotoAsh
Unknown parent • • •Fatur_New
in reply to shrewdcat • • •commander
in reply to shrewdcat • • •I'm happy to use Flatpaks but the annoyances I've had are like when one application says to use you'll need to point to the binary of another application that it depends on but very understandably doesn't package together, figuring that out to me can be annoying so I'll switch to a regular installation and it all just works together no fuss, no flatseal, no thinking about it really. Also some applications where it's really nice to launch from the terminal especially with arguments or just like the current working directory and with Flatpaks instead of just right off the bat it's application name and hit enter, Flatpak hope you remember the whole package name
org.wilson.spalding.runner.knife.ApplicationName ...
Ya alias but got to remember to do that. So far anything I'd ever want to run from terminal, no Flatpak
Outwit1294
in reply to DanWolfstone • • •Paddy66
in reply to shrewdcat • • •As long as software is available in the Software Manager to be installed that way... I don't care what format it's in.
But don't make normies go to the terminal. It's inhumane, and really does not help the masses get away from big tech - which is a worthier goal than keeping your software terminal-only.
arc99
in reply to shrewdcat • • •While I wouldn't want flakpak going deep into the OS I think the advantage of using them on the desktop is obvious. Developers can release to multiple dists from a single build and end users get updates and versions immediately rather than waiting for the dist to update its packages. Plus the ability to lock the software down with sandboxes.
The tradeoff is disk consumption but it's not really that big of a deal. Flatpaks are layered so apps can share dependencies. e.g. if the app is GNOME it can share the GNOME runtime with other apps and doesn't need to ship with its own.
RheumatoidArthritis
in reply to arc99 • • •MoondropLight
in reply to shrewdcat • • •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:
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.
grue
in reply to MoondropLight • • •org.mozilla.firefox
instead of justfirefox
), which is a very terminal-specific issue, LOL!Ferk
Unknown parent • • •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.
Ferk
in reply to Crozekiel • • •Yes, Flatpak is overall a better approach when compared to AppImages, since being dependent on a known runtime ensures the program will run whenever the runtime is available.
What I wish they would add is a way to run the flatpak in a portable way. Because as it stands, AppImages is the only option for that. Flatpak doesn't really allow to have a portable installation in a pendrive, for example. At the moment there's no replacement for AppImage in such use cases, which is a pity.
But there's no fundamental technical design roadblock in flatpak that would prevent it from supporting this in the future, imho. theoretically one could create a program that mounts the flatpak file into a ramfs layered with the runtime and run it.
Ferk
Unknown parent • • •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).
nullpotential
in reply to shrewdcat • • •elo13
in reply to jwmgregory • • •You keep saying this but can you give any concrete examples? I don't recall coming across anything like this.
ipkpjersi
in reply to Crozekiel • • •a Kendrick fan
in reply to shrewdcat • • •seralth
in reply to a Kendrick fan • • •frozenspinach
in reply to jwmgregory • • •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. 🤷♂️
𝘋𝘪𝘳𝘬
in reply to thingsiplay • • •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.
Exactly. Most distributions fail hard when it comes to packaging OBS correctly. The OBS devs even threatened to sue Fedora over this.
gitlab.com/fedora/sigs/flatpak…
Broken OBS Studio Flatpak presented as official package (#39) · Issues · Fedora / Special Interest Groups (SIGs) / Fedora Flatpak SIG / Fedora Flatpaks · GitLab
GitLabCrozekiel
in reply to ipkpjersi • • •I don't actually know if it is a Wayland issue - most of those forum posts are like 3 years old... And I have definitely used these same AppImages in the past on Wayland without issue. I think the AppImages are expecting some specific dependency to be installed on my system that is no longer installed due to updates. (which I thought was counter to the entire point of an AppImage? I thought it was supposed to be kinda like Flatpak where it has it's dependencies in the image? Maybe I just misunderstood AppImage...)
To give you some hope, my Distro switched to Wayland as default a little over a year ago (i think) and I have not been running into problems (outside this AppImage problem, if it is indeed a Wayland issue, which I cannot confirm or deny).
rumba
in reply to shrewdcat • • •I need OBS on this new computer!
Let's install the flatpack!
V4l problems
Plugins Problems
Wayland Problems
I'm just going back to the .deb, thanks.
Carlos Solís
in reply to rumba • • •Captain Beyond
in reply to shrewdcat • • •Not a fan for a few reasons. Flathub (as far as I know) works on the app store model where developers offer their own builds to users, which is probably appealing to people coming from the Windows world who view distros as unnecessary middlemen, but in the GNU/Linux world the distro serves an important role as a sort of union of users; they make sure the software works in the distro environment, resolve breakages, and remove any anti-features placed in there by the upstream developers.
The sandboxing is annoying too, but understandable.
Despite this I will resort to a flatpak if I'm too lazy to figure out how to package something myself.
Developers: Let distros do their job
drewdevault.comscholar
in reply to Captain Beyond • • •thingsiplay
in reply to 𝘋𝘪𝘳𝘬 • • •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"?
Mahi
in reply to shrewdcat • • •muusemuuse
in reply to shrewdcat • • •Enter the calm and quiet room
Pass out torches and pitchforks, guns and knives
“Snaps exist”
War erupts.
sudo
in reply to muusemuuse • • •SNAP BAD
grue
in reply to muusemuuse • • •War with who? I'm posting this from Kubuntu and I'd happily agree with you that Snap should fuck off and die. (In particular, the backend being controlled by Canonical makes it objectively bad compared to Flatpak.) Even among people like me who tolerate Snap (for now...), I really don't think you're gonna find anybody who actually likes it, let alone enough to champion it.
Can't start a war when there's a consensus!
Decker108
in reply to grue • • •limelight79
in reply to shrewdcat • • •I "grew up" with Slackware, so I definitely understand the dependency issue.
I like flatpaks (and similar) for certain "atomic" pieces of software, like makemkv. For more "basic" software, like, say, KDE, I want it installed natively.
Bilb!
in reply to shrewdcat • • •Bronstein_Tardigrade
in reply to shrewdcat • • •