Laughs in AUR
Not great to laugh at the mess Linux is in, due to people paddling in different, incompatible, directions. Users can’t choose the package format. They have to take what they are given. Good or bad. I don’t care which format. As long as it works. But this is a good way to scare more people off of Linux.
laughs at people scared of choice and “mess” . . .
If they’re switcing to linux they should first come to know about open source forking around - arguably - one of the most important features of the whole thing.
If they don’t wan’t that choice and all that inevitable open source forkery, they probably should go for an apple mac or windows or something like that. And maybe they will have to pay for some software for the privilege because it takes work to do those things. They can of course try plain old ubuntu and do stuff the way canonical wants, that removes quite a bit of choice if it is otherwise too terrifying for them.
But in general, I don’t think its a good idea to to try to sell pig-carcasses to vegans by painting them the colours of broccoli.
Laughs in nixpkgs
Laughs in confusion
(I dont know how i got here)
Laughs in support
Support laughs in you
Cracks up in ebuilds
Snickers in pipx
I like the aur too but a proprietary app that isn’t updated to support newer dependencies, it most likely won’t run anyway. At that point it’s either broken app, broken system, or you don’t have anything else installed using that library(yet).
Not an issue on NixOS, you can ship old deps with it
I don’t wanna be that guy, but someone has to say it: Nix Flakes
I have both nix and flatpak lol. Different usecases: flatpak for stuff that I would rather have sandboxed (browsers, games), nix for stuff that I would rather be integrated into the system (command line tools, etc). Tho I still have to learn about flakes, right now I’m just using
nix-envfor everything like a caveman lol
Haters aren’t worth listening to. Doesn’t matter if it is flatpak, systemd, wayland, or whatever else. These people have no interest in a discussion about merits and drawbacks of a given solution. They just want to be angry about something.
I know, right!? Add gimp to that list as well. I can go on and on about shortcomings of gimp despite being a happy user. The average gimp hater, on the other hand, doesn’t have anything to say besides “the UI is dumb and I can’t figure out how to draw a circle”
“The UI is unintuitive” is a legitimate complaint
“Intuitive UI” results in Gnome.
Is it really intuitive if I have to open dconf-editor to change the system font?
They call it “intuitive UI”, Linus calls it “‘users are idiots, and are confused by functionality’ mentality of Gnome”
It’s not always a zero-sum game.
Elaborate? Most of good UI comes from KDE.
What I mean is, makingg a UI more intuitive does not necessarily make it more… Gnome-ey? It can still be effective, customizable, etc.
“Intuitive UI” crowd usually means Gnome-ey/Apple-ey design.
In reality customizable design is more intuitive, because you can customize it to your intuition.
Wayland gets the hate because compositors are authoritative so you cannot e.g. install your own window manager, taskbar, etc. It would be good if there were specifications governing these, but there isn’t.
laughs in appimage.
Flatpaks aren’t perfect, but I think it’s a good solution to the fragmentation problem that is inherent to Linux.
Precisely. Flatpaks solve an important problem. Perfect should not be the enemy of good.
Binary compatibility is a sad story on Linux, and we cannot expect developers — many of whom work for free — to package, test, debug, and maintain releases for multiple distributions. If we want to sustainable ecosystem with diverse distributions, we must answer the compatibility question. This is a working option that solves the problem, and it comes with minor security benefits because it isolates applications not just from the system but from each other.
Also companies are lazy and if we don’t want to be stuck on Ubuntu for proprietary app stability. We should probably embrace something like flatpak. Also when companies neglect their apps, it’ll have a better chance of working down the road thanks to support for multiple dependency versions on the same install.
Great point! At the end of the day, the apps I want to use will decide which distro I main. Many FOSS fanatics are quick to critique Ubuntu, So they should support solutions that allow our distro to be diverse and use all the killer apps.
If you really hate flatpak just make an arch distrobox and download off the AUR. Or install Nix or something
That’s what I’ve done with my deck. Some things just aren’t available through discover, and the Firefox build on there has behavior that I don’t like or know how to correct. Distrobox gives me access to the Arch repos + AUR with persistence that you can’t get on SteamOS without it.
SteamOS is an arch derivative, so you could also just install arch, add the SteamOS repos, and set the steam UI in gamescope to launch on login
Or just use Arch… only for half of your AUR packages to be broken and end up still using flatpaks anyways.
I do sort of wish Nix was a more popular distro agnostic solution
I’ve never used it. Its like all the others though and I have been forced to use snaps. Those I slowly replace every time I decide to start fresh.
Try linux mint, it’s basically ubuntu but without snap (you can install snap if you want to, but it’s not forced on you)
Oh I have. I have it running on some older hardware.
If I can choose between flatpack and distro package, distro wins hands down.
If the choice then is flatpack vs compile your own, I think I’ll generally compile it, but it depends on the circumstances.
Why?
Stubbornness
Based
Because it’s easier to use the version that’s in the distro, and why do I need an extra set of libraries filling up my disk.
I see flatpack as a last resort, where I trade disk space for convenience, because you end up with a whole OS worth of flatpack dependencies (10+ GB) on your disk after a few upgrade cycles.
flatpak has dedub, so no
Yep that’s all well and good, but what flatpack doesn’t do automatically is clean up unused libs/dependencies, over time you end up with several versions of the same libs. When the apps are upgraded they get the latest version of their dependency and leave the old behind.
Is compiling it yourself with the time and effort that it costs worth more than a few GB of disk space?
Then your disk is very expensive and your labor very cheap.
For a lot of project “compiling yourself”, while obviously more involved than running some magic install command, is really not that tedious. Good projects have decent documentation in that regard and usually streamline everything down to a few things to configure and be done with it.
What’s aggravating is projects that explicitly go out of their way to make building them difficult, removing existing documentation and helper tools and replacing them with “use whatever we decided to use”. I hate these.
They didn’t say anything about compiling it themselves, just that they prefer native packages to flatpak
2 comments up they said
If the choice then is flatpack vs compile your own, I think I’ll generally compile it, but it depends on the circumstances.
99% of the time it’s just “make && sudo make install” or something like that. Anything bigger or more complicated typically has a native package anyway.
I should have noted that I’ll compile myself when we are talking about something that should run as a service on a server.
TEN WHOLE GIGABYTES!! OMG WHAT ARE WE TO DO??
10 out of 40 is 25%
10 out of 4000 is 0.25%
I mean it’s 2024. I regularly download archives that are several tens or even over 100 GB and then completely forget they’re sitting on my drive, because I don’t notice it when the drive is 10TB. Last time I cared about 10GB here and there was in the late-2000s.
Great that you have 4tb on your root partition then by all means use flatpack.
I have 256Gb on my laptop, as I recall I provisioned about 40-50gigs to root.
Why not upgrade your hdd?
I’m sorry. I didn’t realize people were still regularly using such constrained systems.
🤣
I change my opinion depending on which app it is. I use KDE, so any KDE app will be installed natively for sure for perfect integration. Stuff like grub costumizer etc all native. Steam, Lutris, GIMP, Discord, chrome, firefox, telegram? Flatpak, all of those. They don’t need perfect integration and I prefer the stability, easy upgrades and ease of uninstall of flatpak. Native is used when OS integration is a must. Flatpak for everything else. Especially since sometimes the distro’s package is months/years old… prefering distro packages for everything should be a thing of the past.
I’m 100% on this camp.
You don’t need the distro to package your sodtware through their package management systems though. Apt and dnf repositories are extensible, anyone can publish. If you go to copr or ppa you can have a little extra help too, without distro maintainers.
The headache comes up when multiple third party repositories start conflicting with each other when you add enough of them, despite they’re best efforts. This scenario starts needing flatpack, which can, for example concurrently provide multiple distinct library versions installed that traditionally would conflict with each other. This doesn’t mean application has to bundle the dependency, that dependency can still be external to the package and independently updated, it just means conflicts can be gracefully handled.
The headache comes up when multiple third party repositories start conflicting with each other
Which is traditionally why you needed the distro to package your software…
Lol who the fuck is blaming app devs? Also something something arch
aur is the only thing I miss. I do like fedora with i3 very much but rpm can be pain in the ass sometimes
could you perhaps run them with Distrobox? i was always wondering that.
Yes! This is something I do on 3 of my machines. My ArchLinux Distrobox with paru works like a charm. (so far)
that’s very good to hear, I’ll probably try out silverblue with distrobox and that’ll be my end of distrohopping
It was for me, check out ublue for simpler setup.
most likely but I’m super lazy with my pc unless I’m having hyperfocus going, so I don’t know
distrobox?, i also installed nix and works perfectly
…btw
And this, this is why I love the AUR
“oh this is a flatpak or hell even a windows exe…” proceeds to search for it on AUR “ah there it is, wonderful!”
Hell I’ve found a god damn windows gaming cheat trainer on AUR and it worked.
The AUR is basically just a script that describes best case scenario for building something under Arch. They don’t have any specific quality rules they have to meet.
It’s super easy to make and publish an AUR script compared to a regular distro package (including Arch packages).
I think no one said it needs to be ON a distro’s repos. That’s a straw man.
A package should be available in a native package format in a way that doesn’t cause conflict with what’s in the official repo.
Wow, is this meme a really naive take that is contradicted by - oh god, everything. Can someone know about enterprise Linux and also be this naive?
The responsibility to figure out the dependencies and packaging for distros, and then maintain those going forwards, should not be placed on the developer. If a developer wants to do that, then that’s fine - but if a developer just wants to provide source with solid build instructions, and then provide a flatpak, maybe an appimage, then that’s also perfectly fine.
In a sense, developers shouldn’t even be trusted to manage packaging for distributions - it’s usually not their area of expertise, maintainers of specific distributions will usually know better.
While I agree that developers (like myself) are not necessarily experts at packaging stuff, to conclude that it’s fine that a developer provides a flatpak is promoting shitty software. Whether a software should run in a jail, or within user space is a decision that - for most use cases - should be made by the user.
There is absolutely no reason not to provide software as a tar.gz source code archive with a proper makefile & documentation of dependencies - or automake configuration if that’s preferred.
From that kind of delivery, any package maintainer can easily build a distro-package.
I think you’re actually agreeing with me here. I was disputing the claim that software should be made available in “a native package format”, and my counterpoint is that devs shouldn’t be packaging things for distros, and instead providing source code with build instructions, alongside whatever builds they can comfortably provide - primarily flatpak and appimage, in my example.
I don’t use flatpak, and I prefer to use packages with my distro’s package manager, but I definitely can’t expect every package to be available in that format. Flatpak and appimage, to my knowledge, are designed to be distro-agnostic and easily distributed by the software developer, so they’re probably the best options - flatpak better for long-term use, appimage usable for quickly trying out software or one-off utilities.
As for tar.gz, these days software tends to be made available on GitHub and similar platforms, where you can fetch the source from git by commit, and releases also have autogenerated source downloads. Makefiles/automake isn’t a reasonable expectation these days, with a plethora of languages and build toolchains, but good, clear instructions are definitely something to include.
Makefiles/automake isn’t a reasonable expectation these days, with a plethora of languages and build toolchains, but good, clear instructions are definitely something to include.
As for the Makefiles, I meant that for whatever build toolchain the project uses - because the rules to build a project are an essential part of the project, linking the source code into a working library or executable. Whether it is cmake, or gnu make, or whatever else there is - that’s not so important as long as those build toolchains are available cross platforms.
I think what is really missing in the open source world is a distribution-agnostic standard how to describe application dependencies so that package maintainers can auto-generate distro-packages with the distribution-specific dependencies based on that “dependencies” file.
Similar to debian dependencies
Depends: libstdc++6 (>= 10.2.1)but in a way that identifies code modules, not packages, so that distributions that package software together differently will still be able to identyfindPackageFor( dependency )I would really like to add this kind of info to my projects and have a tool that can auto-build a repo-package from those.
I’m new to Linux. Every time I’ve had a major issue with an application it turned out to be due to a flatpak. I’ll stick with other options for the time being.
Also at least let me compile it myself if not in a repo 😩
People always forget about appimages.
Your security people have not forgotten about appimages. It fills their nightmares.
Same app in native format: 2MB. As a flatpak: 15MB. As an appimage: 350MB.
Appimages are awesome, rock solid, and I have a few on my system, but flatpak never gave me any problem and integrates better with my KDE, and is smaller. Both have their advantages tho. I’m fine with using both. If you are a developer, make a flatpak or an appimage i dont really care just make your software available for linux. Both are fine, choose the one that fits your specific app the most.
But I also think appimages deserve the same attention and great integration with the OS as flatpaks. Stuff like that AppImageLauncher functionalities should just be integrated inside the DE itself.
But we need an universal package format for linux asap. Flatpak is on the front in this race, and I’m fine with it. Appimages second, for sure.
If you don’t run your install off a 12 zetabyte NAS are you even a real linux user?
Just compile from source?
Not optimal
Yes, it would depend on your flatpack usage. For me I only have like 5 programs compiled from source and one flatpack (bottles) because of the sandboxing
That’s not good. It breaks the system as there isn’t any change control with that unless your using something like Gentoo. Get your packages from the package manager.
I like the ports tree that only compiles from source, yes it’s slow, but you know the binaries you make are pure.
This doesn’t scale. If I have a bug and my package has about two dozen dependencies which can all be different versions, and the developer can’t reproduce my bug, I’m just screwed. Developers don’t have the time and resources to chase down a bug that depends on build time variables.
Ask me how I know this happens.
Back in the day, when I installed my very first Linux OS, I had a wireless stick from Netgear. Wireless Drivers back then were abysmal, so I had to compile them from source (literally 15 mins after seeing a TTY for the first time). After I had found out how build-dependencies and such worked somehow and ./configure completed successfully for the first time, the script ended with the epic line:
configure done. Now type 'make' and prayAh, I had one of those wireless sticks from Netgear as well, probably a different model but still a royal pain to get it working.
Luckily ndiswrapper has become a thing of the past nowadays.
Because it’s always so easy to compile everything you need from source! Just make sure to download, compile and install the dependencies first as well. Oh, and the dependencies’ dependencies. And the ones from them. And so on. Unless you’re lucky enough that there are already packaged dependencies available for you. Don’t know how to compile? No problem, just read the documentation. You can be absolutely 1000000% dead serious sure that everything you need to know is documented and extremely super duper easy to understand if you don’t know the source code or barely know how to code at all. And if not, maybe you can find the bits of information on the respective Discord server. It will probably be also very intuitive to know which build options you have to set in which way and which ones even exist. And that without causing conflicts with other packages you need to compile. Still got got problems with compiling? EZ, just open a bunch of issues on the respective GitHub pages. (If present. Otherwise, try to find another way to contact devs and get support, Discord for example.) Maybe, about six months later you’re lucky to get a response. And if not, don’t worry. Some will tell you, you should RTFM or are an idiot. Some will just close the issue because your platform isn’t supported anyway. Then you know, what you did wrong. Also don’t mind if your issue gets ignored.
If you finally managed to compile everything from source, congratulations! Now run the program and test if everything is working. If it’s not or if it is crashing, don’t worry! In developed and civilised countries you can just buy a shotgun and blast your own head away to end this suffering.EZ! Just compile from source! /s
My workflow always definitely includes multiple weeks to debug random issues with building the tools I need to use. Totally a scalable and good solution to dump this work on the end user.
I just complie from source some lightweight programs that are too niche for repositories. I am in no way advocating for full source compilation of every program in your system, that’s a security and usage nightmare. Flatpack does have its use for sandboxing an environment. I personally use it for windows applications in bottles.
You have rediscovered LFS
Nix: you package it yourself and do a pull request
Sadly, many flatpaks don’t even work on NixOS properly because of assumptions about the file structure or similar
Exactly. And even if one doesn’t know how to package it, they can just open a request issue.
