There are many reasons to dislike Nvidia on Linux. Here is a little thing that bugs me all the time, the updates. Normally the system updates would be quick and fast, but with the proprietary drivers of Nvidia involved, it gets quiet slow process. And I am not even talking about any other problem I encounter, just about the updates.
As an Archlinux based system user (EndeavourOS to be precise), I get new Kernel updates all the time. That means every time a new Kernel version is installed, the Nvidia driver DKMS has to be installed too. And that is basically the slowest part. But that’s not too bad, even though it’s doing this twice for each Kernel I have once.
What’s more infuriating is, if you also happen to use Flatpaks for a very few applications. I really don’t have many Flatpaks at all. Yet, the Nvidia drivers are installed in 7 versions or what?! And they are full downloads, each 340 MB or more. This takes ages and is the only part that takes long to update Flatpak system. I always do flatpak remove --unused to make sure nothing useless is present. /RANT (EDIT: Just typos corrected.)
AUR is not the same as the community repository on other distros though. Community repositories on other distros contains pre-built packages supplied by community members, while AUR contains build scripts that let you download the source code directly from the vendor website, compile it into a package and install it in your system with a single command, so you’ll often get the bleeding edge version faster than most community repositories on other distros.
Wrong again, xbps does this better than Pacman. Packtinstall works the same way, dude you have no Idea
What are you talking about? We’re talking about AUR, right? not Pacman?
Bro, why do I even bother. makepkg is part of Pacman, you use pacman to install the package… Pacman is arch Linux package manager the same tool you use to install from aur.
That’s just the tool to build the packages. The AUR itself is a repository of user-submitted build scripts where anyone can signup and publish their pkgbuild scripts, totally incomparable with community repository on other distros which ship binary packages instead of build scripts. Pacstall is the closest of alternative, but they are not made by canonical (actually, who made them? Their privacy policy seems to by copy-pasted from a boilerplate unrelated with the actual service provided by pactstall) and aren’t shipped with the distro by default.
You have no idea, what you are talking about. And it’s starting to become to cringe to keep going, you’re either a troll or clueless.
Aur is not supported by Arch Linux. It’s a community repository that has build scripts yes, but you have either one download the build scripts and use pacman to install them, two use a pacman wrapper like yaurt to fetch them and install them for you using guess what pacman!
Just because the tool isn’t supported by the distro doesn’t matter in this case, because they solve the same issue!! You are installing packages from a repository that the community oversees. Your case for arch Linux was installing the latest version of an application.
Have you even pulled your head out of arch linux ass and looked att xbps? No, because I’m starting to doubt if you would understand it, and there are other distros that offer the same thing.
You keep straw maning
pkgsrc and *BSD entered the chat.
Don’t bother arguing with him. AUR is special because it is arch and arch is special and because he is using it and it has to be special!
Come on, when did I say AUR is special? I said AUR has different approach that other community repositories, and you somehow assume I’m an arch user? Why do discussion involving arch always devolve into combative arguments? Can’t we talk it out without assuming the other party is malicious?
I was addressing the fact that AUR is a repository of build scripts that fetch and compile them, which make it very different than other community repository. An AUR entry could be not updated for months, but because it fetch a the source code directly from source, it often will fetch the latest version of the app regardless the when was the last time the build script itself updated, which is not the case on other binary community repo (which install whatever available in the repo instead of fetching directly from the apps’ maker).
You are the one that keep strawmanning to compare pacman with other package manager when I’m not talking about the package manager itself, but about the different approach of arch user repository. And no, I’m not actually an arch user anymore. I never even once say that pacman is good or even better than others, but you somehow assume that I say so.
Actually I haven’t heard about xbps or tried void linux yet, so thanks for mentioning it.
Yeah no, most build scripts if they are worth their salt, will absolutely not pull the latest package from a given source. Because that is insane, 99% of the time they validate the download with a checksum, meaning that you have to update the checksum in the build script, or in the case of multiple downloads - multiple checksums.
Yes pacman is the underlying technology that enables aur to exist.
Those ideal build scripts would also get updated when the the source published a new version, but alas, being maintained by random users means the build scripts not updated in timely matter sometimes. In that situation, having another build scripts that say, pull git head, is often useful than none at all. It’s up to the users to evaluate and use whichever is appropriate for them.