yay is a package manager that has been made for AUR. yay is not the official package manager for Arch Linux, pacman is, and it does not support AUR. yay is not installed on Arch Linux by default, its official package manager, pacman, is. AUR is for unofficial 3rd party packages, i.e. "use at your own risk". It has always been the case.
Yes, it is "use at your own risk" but most arch users just install from it without giving it a second thought, because availability of packages in the AUR is the one thing Arch is good at.
> most arch users just install from it without giving it a second thought
I'm not sure that's true. Neither I nor most people I know who use Arch (granted, most of them are professional software developers) install software from the internet willy-nilly and without reviewing anything, if by AUR or "curl | bash", especially when on their main computers.
N=1 but I rarely install from AUR and I have been using Arch Linux for decades. Using "yay" is akin to doing "curl | sh". You should inspect the PKGBUILD at the very least, and I do not believe "most users" is correct.
Oh, and by the way, not sure how people miss these:
> Warning: AUR packages are user-produced content. These PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk.
> Warning: AUR helpers are not supported by Arch Linux. You should become familiar with the manual build process in order to be prepared to troubleshoot problems.
"yay" is one of the most common AUR helpers, it requires two confirmations from what I counted. One of them is to inspect the PKGBUILD file, the other one is just to proceed.
Those users are going to learn some hard lessons, either in this incident or a future one.
Archlinux is a distro that’s designed for the user to control their own system, and the AUR is clear about what it is and the nature of the packages in it.
It's also good at being fairly simple and transparent, and having the only sane package format in existence (along with Alpine's apkbuild which is basically the same thing), but okay.
On one hand, the distro developers can’t really prevent people from, say, hitting their computers with a sledgehammer or something. So to some extent, the users have to be trusted.
But, maybe it would be best not to have “yay” available. Using something like AUR without reading the package build files is… pretty bad, right? And it is bad for the community, because if there is a convention of doing that sort of thing, it makes the AUR a good target for attacking.
Oh, I thought it was a package from the repo. (I didn’t use any of those third party package managers, just stuck to manually doing everything when using the AUR, which was fine because I used it sparingly).
> But, maybe it would be best not to have “yay” available. Using something like AUR without reading the package build files is… pretty bad, right? And it is bad for the community, because if there is a convention of doing that sort of thing, it makes the AUR a good target for attacking.
I don't remember how yay works but paru (another AUR package manager) displays the pkgbuild file before it will install.
Nearly all distros have this problem when it comes to packaging and distributing 3rd party software.
Even if you're using an immutable distro, your KDE Plasma session can get hijacked if you simply use the built in wizard to install 3rd party desktop widgets, which is a right-click + single-click away on any Plasma destkop.
The current iteration of SteamOS (the one shipped on Steam Deck) is Arch based. So a lot of non-linux users got exposed to it as their first linux distro. Especially with all the emulation guides and other random guides for doing "advanced" stuff to your Steam Deck by dropping in the Arch-ish desktop.
Also anyone who wants to try "Gaming on Linux" needs bleeding edge kernel which is Arch's default setup compared to other distros.
This is a slight aside, but CachyOS is a great example of the failure of Wikipedia politics.
The "CachyOS" page was deleted[1], and replaced with a redirect to the Arch Linux page. But CachyOS is not mentioned anywhere on that page, nor on the "List of Linux distributions § Arch Linux-based" page.
It links to https://en.wikipedia.org/wiki/Arch_Linux#Derivatives which indeed lacks any mention of CachyOS. Luckily, Wikipedia is free to register, and you can just edit pages you feel like could be better. Seems like you found the perfect first edit to make for yourself :)
It's an endemic issue on wikipedia, and even editing wouldn't fix this one instance, since someone can (and demonstrably already has) remove whatever you add later on. The issue is wikipedias preference for "deletionism", removing perfectly correct information for no particularly good reason. It's especially pernicious when it comes to short articles, which tend to get deleted with impunity, and redirected to sections of articles, which later get renamed, destroying the link, or removed altogether. Nothing can be done by any individual to fix this issue, since it comes from a wikipedia wide policy, which unfortunately is not one of the things that "anyone can edit".
I agree with most of what you wrote, but unless you can demonstrate that someone actually added CachyOS to the "Arch Linux-based" on the "List of Linux distributions" page and it was later removed, I'm not sure how much it matters how Wikipedia generally works.
I have a long Wikipedia history, but that is not the point. There already was a CachyOS page, and it was removed. Why bother contributing stuff that will just be deleted again?
It might have been removed due to the editor's impression that CachyOS is not significantly different from Arch. With proof to the contrary the page may be restored.
There are a lot of derivative(I don't mean it in a negative way) distors out there, not sure if they all need pages.
Most moderated spaces remove content that doesn't fit the community, Wikipedia does take that to the extreme but I still prefer that than the opposite extreme.
But their differentiation is that to improve performance they compile all the packages with newer instruction sets as the target as well as enabling more optimizations like LTO. And some are even optimized with PGO.
I find it odd to call a specific Linux distribution blazingly fast.
Gentoo with make.conf (/etc/portage/make.conf[1]) having "CFLAGS="-O3 -march=native -flto"" means that Gentoo, a Linux distribution, is performant?
[1] It is not a good idea to build everything with LTO or PGO enabled because not all packages support LTO / PGO cleanly. Do it on the basis of per-package.
I've seen claims of decent speed improvements when using CachyOS, though I can't say I've ever hunted down solid confirmation. I'm a bit wary of the project because I would have to put a lot of trust in them since they're rebuilding everything themselves and could easily introduce malware somewhere in there. (But I've been scared of distros before only to have it pointed out to me that some very well respected people are involved, so I could be worrying for nothing here too)
Does Gentoo have binpkgs with these compileflags? With CachyOS you don't have to compile, because it's a rolling binary distro. Regarding your [1]: They do that, systemd(or parts of it) are unoptimized, for instance. They don't apply that stuff blindly, only where it works.
For me it feels blazingly fast, even on obsolete KabyLake Core-I5/7(t) forcibly clocked down to about 800Mhz most of the times :)
It fucking flies without much effort. On modern systems even more so. While being rock solid. Without any crashes. Even under Plasma. When I'm reading about bugfixes regarding crashes under Plasma I just shrug and think "Waddya talkin about?". That may be hardware dependent, though, because they are old Lenovo Thinkcentres(1Litre SFF M910q tiny) with excellent firmware.
Using btrfs, profile-sync-demon, zram(Yes. Even with 32GB Ram!). Suspend/Resume working every single time. No glitches, hick-ups, ever. So far. Since 10th of June, 2024.
Edit: Almost always some music out of yt doodling in some bg-tab, in oh-so-slow FF, without any clicks, stuttering, or other breaks.
No need for yt-dlp, mpv at all. Except for dl/saving stuff, sometimes. While FF is rarely under 100 tabs.
An evaluation of what's best really depends on how one weighs different tradeoffs. For example, Debian and Arch are basically polar opposites in terms of two questions:
1) do you want an intermediary between you and the upstream? for example, to patch out telemetry
2) is it important that what you're using continues to work the same way so you can focus on your actual work?
No answer to either is consequence-free, e.g. for 1), see the Debian SSH patch event, or for 2), if the answer is "it doesn't work", then that kinda forces one's hand.
There's also the significant caveat with 2 that it's only "continues to work the same way" until everything changes all at once because you now need to update to the next version of Debian.
The "everything changing all at once" thing is what eventually drove me to arch (as the most popular at the time rolling release distro - and more stable at the time than debian sid), I'd personally rather have smaller breaking changes more frequently. Though it's probably less painful now to update debian versions than it use to be because things generally work better without configuration than they used to.
This is just ignorant. I've been daily driving Linux since 2005. The majority of that time has been with Arch. Despite the memes, I've found it to be MORE stable than your typical Debian derivatives. It's funny to me that it took over a decade for people to come to the same realization.
You know? I did drive Arch daily for a few years, coming from NetBSD.
Then had to use something 'officially' supported for a while, then did some Debian derivative live-distro running from USB/in RAM because of HW-problems, and settled for CachyOS when new (old) HW arrived.
I update maybe once a month at the most, more likely every two monts, because I don't give a shit. With the exception of FF, or maybe some nicer Kernel, for eBPF and scheduler-stuff.
That's reviewing changes in a few config files, after having read up about them at Archs & CachyOS sites. Maybe five minutes max, opening a few relevant tabs. (If necessary at all, which often isn't the case.)
Starting Pacman. Downloads instantly, even if several GB. Decompresses and installs stuff. Maybe two to three minutes. Reboot. 20 seconds. Plasma is back.
Clicking FF. Back with all its tabs. Maybe two to three seconds. Maybe uBO blocks a few more secs sometimes, while updating lists.
After intentionally having killed it with -9 in preparation before reboot.
Cleaning Pacman's package-cache and btrfs-snapshots because The only way is Fooorwaaard!
Personally I've been running Arch on my work machine for a few years now with very few issues. I'm not even very consistent with updates, and probably run them about once every 3 weeks on average. I have only had to manually intervene on a handful of occasions.
I like it a lot because everything is always up-to-date. I don't face any issues with unsupported versions for tools like I have with Debian in the past. The rolling release model also saves me the pain of doing a "hard" OS upgrade, which often come with issues.
I'm hesitant to comment further seeing I've attracted the ire of some people with my comment, but anyway. I too used Arch out of curiosity about like ten years ago, during the first "Arch, BTW" memes, and found it too unstable, but that's expected from a rolling release: update too soon or too late, and something could break. I didn't mind, as it was a hobby.
Eventually, I got more busy and had less time to tinker, so I migrated to Ubuntu LTS, which has some small warts, but has needed practically null babysitting compared to Arch. I was surprised when the Arch memes resurfaced this year, but that's the only growth I've seen. None of my Linux-savvy peers use Arch, BTW.
FWIW, the only breakage I've seen over the past 5 years is amdgpu bugging out on latest kernel releases, which is easily solved by running linux-lts.
I've had way more problems with Ubuntu trying to be convenient and bringing in lots of Windows-style automation that breaks more often than it works (and when that happens, you're really on your own since you have no idea how it's put together — just like in Windows).
Or even just bugs that were solved upstream ages ago (and have been available in every rolling-release distribution, including Debian testing/sid).
The current Arch installer suggests btrfs with snapper, so you get automatic snapshots pretty much out of the box (need to check one flag in installer), and can easily rollback if something breaks. Not something I needed, but it's there.
I can't imagine what kind of a problem I would personally have to encounter to make me utter such a sweeping generalization with this much confidence. :)
At least this guy has been using it as a daily driver (at home and at work) for at least fifteen years.
Well, Arch has (historically) been rather difficult to install from scratch, and requires a lot of Linux knowledge to get up-and-running as a daily driver. If one is installing it for the first time and misses something (which audio backend?), it can be rather frustrating down the line.
There is a reason Ubuntu is usually the first distro new Linux users go to. For almost a decade now, installing a feature-complete Ubuntu setup is not much more difficult than reimaging Windows.
It this recent? I thought “I use arch btw” was more of a thing… 5 or so years ago.
I switched away from Arch (to Ubuntu) as a sort of side effect of switching computers a couple years ago (desktop->laptop, though Ubuntu would “bring the batteries along” more conveniently). Ubuntu is fine I guess, but I really miss the stability of rolling release and the user-friendliness of not having too many built in programs.