Als je Arch Linux of een van de afgeleide distributies (EndeavourOS, Manjaro, Artix, enz.) gebruikt, zul je vroeg of laat tegen het volgende probleem aanlopen: AUR-repositories en de bekende yay- en paru-assistentenIedereen heeft het erover, ze worden aanbevolen op forums, ze duiken op in bijna elke handleiding, maar als je probeert te beslissen welke je moet gebruiken, zijn de verschillen niet altijd even duidelijk.
In de volgende alinea's zullen we rustig uiteenzetten wat elk van deze opties te bieden heeft, welke meningen er binnen de gemeenschap bestaan en welke mythes er de ronde doen. “Yay is dood” of “Paru is veel sneller”En in welke gevallen het de moeite waard is om van de ene naar de andere over te stappen. Het idee is dat je aan het einde goede argumenten hebt om voor een assistent te kiezen, zonder er te veel over na te hoeven denken.
Wat zijn yay en paru en waarom gebruikt iedereen ze?
Grofweg zijn zowel yay als paru AUR-assistenten die het zoeken naar, compileren en installeren van pakketten automatiseren. Naast het beheren van pakketten vanuit de officiële repositories via de AUR, gebeurt dit ook automatisch op de achtergrond met behulp van pacman. In plaats van handmatig naar de AUR-website te gaan, de PKGBUILD te downloaden en uit te voeren, hoeft u dus niet langer handmatig de PKGBUILD te downloaden en uit te voeren. makepkg en vervolgens installeren ze het pakket; dat doen ze allemaal in één keer.
In Arch Linux en afgeleide omgevingen is het heel gebruikelijk om toegang te willen krijgen tot de In AUR is een uitgebreide catalogus met software beschikbaar.Daar vind je applicaties die niet in de officiële repositories staan, Git-versies, experimentele patches of gewoon programma's die niemand officieel heeft verpakt; bijvoorbeeld handleidingen voor Visual Studio Code installeren op ArchOm dat allemaal wat makkelijker te maken, gebruiken de meeste mensen een assistent, en dat is waar yay en paru in beeld komen als twee van de populairste opties.
Yay is al jarenlang een van de toonaangevende namen: Het is algemeen bekend, gedocumenteerd en heeft een enorme gemeenschap. en is standaard aanwezig in distributies zoals EndeavourOS. Paru daarentegen is recenter, maar heeft aanzienlijke populariteit verworven omdat het een wat strengere en veiligere aanpak biedt voor de AUR-workflow, en omdat de auteur in het verleden betrokken was bij de ontwikkeling van yay.
Technische verschillen: Go versus Rust, ontwerp en filosofie
Een punt dat in alle debatten steevast terugkomt, is dat yay is geschreven in Go en paru is geschreven in Rust.Technisch gezien is dit voor de eindgebruiker minder belangrijk dan soms wordt gesuggereerd, maar het zegt wel iets over de aanpak van elk project.
Yay, ontwikkeld in Go, is geïnspireerd door oude assistenten zoals Yaourt, Apacman en PacaurDe code is relatief gemakkelijk te lezen en uit te breiden voor iedereen die bedreven is in Go, en een van de historische verdiensten is precies dat. De compilatie is snel en probleemloos.Die basis heeft ervoor gezorgd dat het project is blijven bestaan, zelfs na veranderingen in het ontwikkelingsteam.
Paru daarentegen is geïmplementeerd in Rust en maakt direct gebruik van de ervaring van yay, zowel wat betreft functionaliteit als het ontwerp van de commandoregelinterface. Dankzij dit, Migreren van yay naar paru is heel eenvoudig.Veel commando's en opties voelen vrijwel hetzelfde aan, dus je hoeft niet alles helemaal opnieuw te leren.
Op filosofisch niveau legt Paru iets meer nadruk op beveiliging en beoordeling van PKGBUILDsHoewel Yay van oudsher standaard prioriteit geeft aan een snellere en handzamere workflow, is dit verschil duidelijk te zien in de manier waarop beide de bestanden presenteren voordat de pakketten worden gebouwd.
Snelheid: Is Paru echt sneller dan Yay?
Een van de meest gehoorde argumenten op forums en sociale netwerken is dat Paru is “sneller” dan yay.Het is belangrijk dit punt te verduidelijken. Verschillende gebruikers met krachtige hardware en een goede verbinding (bijvoorbeeld 1 Gbps glasvezel) melden dat dit in de praktijk niet het geval is. Het gevoel van snelheid is bij beide erg vergelijkbaar.Bij dit soort systemen is het knelpunt vaak het downloaden of compileren van de software zelf, en niet zozeer de installatiewizard.
Desondanks hebben sommigen beide systemen vergeleken op meer bescheiden machines en beweren dat Paru voert bepaalde handelingen iets sneller uit.Dit is vooral merkbaar bij het uitvoeren van zoekopdrachten, synchronisaties of globale updates waarbij zowel officiële repositories als de AUR betrokken zijn. Het verschil is meestal niet enorm, maar op systemen met beperkte resources of trage schijven kunt u hier en daar een verbetering van een paar seconden zien.
De andere kant van de medaille is dat Paru dwingt je standaard om PKGBUILDs te controleren voordat je compileert.Dit voegt een interactieve stap toe die uiteraard (zij het een beetje) menselijke tijd in beslag neemt. Sommige gebruikers ervaren dit als een "vertraging", terwijl anderen het als een redelijk compromis beschouwen omdat het zorgt voor veiligheid en transparantie.
Kortom, als je een moderne computer en een goede internetverbinding hebt, De snelheidsverschillen tussen yay en paru zullen zeer klein zijn.Paru kan met name nuttig zijn in beperkte systemen waar elke seconde telt, of als je een assistent wilt die tot in de kleinste details is geoptimaliseerd en je dat kleine voordeel merkt.
Syntaxis en gebruikerservaring: hoe het voelt om te typen
Los van prestatie-indicatoren en technische discussies, reageren veel gebruikers enthousiast om een vrij alledaagse reden: Het is erg prettig om te schrijven.Sommige mensen zeggen dat ze letterlijk "beide toetsen tegelijk indrukken" om "yay" te typen, omdat het kort en makkelijk te onthouden is en automatisch wordt aangevuld in de terminal.
Paru is niet bepaald een vreselijke naam, maar sommige mensen zeggen dat Hun zinsbouw lijkt hen wat "ruwer". Bij dagelijks gebruik. De commando's zijn niet heel anders, maar gewoontes spelen een rol, en degenen die Yay al jaren gebruiken, vinden de workflow natuurlijker en sneller, zowel mentaal als tijdens het typen.
In elk geval bieden beide assistenten aan snelkoppelingen, interactieve opties en zeer vergelijkbare vlaggenZo zijn er bijvoorbeeld in beide versies functies beschikbaar zoals het weergeven van een gecombineerd menu met repository- en AUR-updates inclusief versiegegevens. In Yay is er een optie. --combinedupgradedie een kleurgecodeerde lijst weergeeft van wat er wordt bijgewerkt en van welke versie naar welke. In Paru wordt iets vergelijkbaars bereikt via de optie. --upgrademenu, dat een gedetailleerd overzicht van updates biedt.
Een opvallend detail dat in sommige discussies terugkomt, is dat Er zijn zelfs gebruikers die aliassen aanmaken zoals yaya hoeraOmdat ze het nog handiger en leuker vinden om hem op die manier op te roepen. Dit illustreert duidelijk in hoeverre ergonomie en gewoonte een belangrijke rol spelen bij de keuze van een assistent.
Waar worden de gegevens van elk gecompileerd pakket opgeslagen?
Een ander interessant aspect dat vaak over het hoofd wordt gezien, is het beheer van de vooraf gecompileerde pakketten (de .pkg.tar.zst-bestanden)Hier gedragen yay en paru zich iets anders, en dat heeft invloed op hoe ze integreren met typische Arch-paden.
Standaard, makepkg plaatst de gebouwde pakketten in de build-directory.Die route kan worden aangepast met behulp van de variabele. PKGDEST en /etc/makepkg.confJe zou ze bijvoorbeeld kunnen sturen naar /var/cache/pacman/pkg/ om de verpakte binaire bestanden te centraliseren.
In het geval van paru wordt het gebruikelijke gedrag van makepkg gerespecteerd: De pakketten komen terecht in de compilatiemap die is gekoppeld aan paru., meestal zoiets als ~/.cache/paru/clone/$pkgname/Als u dat pad wereldwijd wilt wijzigen, kunt u de optie gebruiken. BuildDir en /etc/paru.confDe compilaties doorsturen naar een andere site.
Yay gedraagt zich enigszins anders. Verschillende gebruikers wijzen erop dat Hoera, kopieer de gebouwde pakketten naar /var/cache/pacman/pkg/ Na het compileren komen je AUR-pakketten effectief op dezelfde plek terecht als de officiële pakketten die door pacman worden beheerd. Dit is handig, maar het betekent in zekere zin dat "hoera is..." op datgene stappen wat je hebt gedefinieerd in PKGDEST en /etc/makepkg.confIets wat door sommigen als respectloos wordt beschouwd ten opzichte van de algehele configuratie van het systeem.
Voor de gemiddelde gebruiker is dit meestal geen groot probleem, maar als u erg kieskeurig bent over hoe binaire bestanden op uw computer zijn georganiseerd, Dit zou een reden kunnen zijn om de voorkeur te geven aan het "nettere" gedrag van paru.Of in ieder geval om te weten wat elke assistent met uw pakketten doet.
Onderhoudsniveau en activiteit van elk project
In diverse debatten is het idee opgedoken dat Yay is verlaten of verouderd en Paru is de natuurlijke vervanger ervan.Deze bewering komt deels voort uit het feit dat een van de ontwikkelaars die bij yay betrokken was, is overgestapt naar paru. In sommige video's en berichten werd dit geïnterpreteerd als het einde van het yay-project of als een teken dat het project niet langer werd onderhouden.
Verschillende gebruikers en ontwikkelaars hebben dat verhaal categorisch weerlegd: Hoera, er is nog steeds actief onderhoud.Met frequente commits naar de repository en een vrij grote community erachter. Sterker nog, een deel van de frustratie van sommige beheerders komt juist voort uit het steeds maar weer horen van de mantra "hoera, het is dood" zonder dat iemand de moeite neemt om de werkelijke status van het project te controleren.
Tegelijkertijd is het waar dat Paru vertoont een zeer hoge en constante activiteit.Soms zelfs iets hoger dan 'yay' op bepaalde momenten. Dat is logisch, aangezien het een relatief nieuw project is, dat graag blijft innoveren en details verfijnt, en met een zeer betrokken auteur die snel reageert op problemen en verzoeken vanuit de community.
In de praktijk leiden deze verschillen in activiteit voor iemand die simpelweg pakketten wil installeren zelden tot problemen. Beide projecten zijn nog steeds actief en ontvangen bugfixes en nieuwe functies.En er is niets dat je dwingt om 'yay' op te geven uit angst dat het op korte termijn kapotgaat.
Beveiliging, PKGBUILD-review en AUR-gebruiksfilosofie
Een belangrijk punt waarop duidelijke verschillen in aanpak worden waargenomen, is hoe elke deelnemer de PKGBUILDs-beoordeling benadertOnthoud dat AUR geen officiële repository is: dit zijn recepten die door gebruikers zijn ingediend, en de eindverantwoordelijkheid voor de beoordeling ervan ligt bij jou.
De Arch-gemeenschap heeft er altijd op aangedrongen dat Je moet de PKGBUILD-bestanden lezen voordat je ze installeert.Om onaangename verrassingen (malafide scripts, downloads van onbetrouwbare bronnen, gevaarlijke commando's, enz.) te voorkomen, is Paru, in lijn met deze filosofie, standaard zo geconfigureerd dat u deze beoordeling te zien krijgt en "dwingt" om er aandacht aan te besteden voordat u het pakket bouwt.
Hoera, hoewel je hiermee ook PKGBUILDs kunt controleren. bevordert een "snellere en zorgeloze" doorstroming Als je een eenvoudige oplossing wilt. Dit is erg aantrekkelijk voor degenen die gemak belangrijk vinden en vertrouwen hebben in de AUR-beheerders, maar het heeft ook de perceptie gecreëerd dat "yay" aanmoedigt tot "installeren zonder te kijken", iets wat niet helemaal past bij de puristische mentaliteit van Arch.
Het is in ieder geval belangrijk om te onthouden dat, welke assistent je ook gebruikt, Alles loopt uiteindelijk via Makepack en Pacman.Met andere woorden, beide methoden helpen bij het automatiseren van het zware werk, maar het basismodel blijft hetzelfde: PKGBUILDs die pakketten worden die pacman beheert en installeert. De verantwoordelijkheid voor het begrijpen van wat je installeert, blijft bij jou.
Het AUR gebruiken zonder assistenten en de rol van Pac-Man
Een terugkerende vraag duikt ook op in verschillende discussies: "Hoe kan ik AUR-pakketten bijwerken zonder een wizard te gebruiken?"Het orthodoxe antwoord, dat rechtstreeks aansluit bij de officiële filosofie van Arch, is duidelijk: gebruik maken van makepkg handmatig met de bijbehorende PKGBUILDs.
PKGBUILDs zijn recepten die definiëren Hoe bouw je het pakket vanuit de broncode of vanuit vooraf gecompileerde binaire bestanden?Zodra dat pakket is gegenereerd, verzorgt pacman de installatie en de logging, net zoals bij pakketten uit de officiële repositories. Er is geen speciale behandeling voor pakketten die afkomstig zijn uit de "AUR": voor pacman is het, eenmaal verpakt, gewoon een ander pakket.
Assistenten zoals Yay en Paru zijn niets meer dan meerdere lagen comfort bovenop die klassieke flow van "download PKGBUILD → makepkg → pacman"Ze voeren zoekopdrachten uit, lossen afhankelijkheden op, automatiseren downloads en compilaties en voegen handige menu's en opties toe, maar ze vervangen of wijzigen de rol van pacman als centrale systeembeheerder niet.
Daarom scheppen sommige ervaren gebruikers er trots op dat ze nooit assistenten gebruiken en verdedigen ze de handmatige methode als de meest transparante en beheersbare. Anderen, de meerderheid, geven er de voorkeur aan om tijd te besparen en te vertrouwen op handmatige tools, in de overtuiging dat automatisering hun leven vereenvoudigt zonder dat ze volledig het overzicht verliezen van wat ze doen.
Paru en yay in afgeleide distributies: EndeavorOS, Manjaro, Artix…
In distributies zoals EndeavourOS komt 'yay' meestal vooraf geïnstalleerd of aanbevolen als de belangrijkste assistentDit heeft een aanzienlijke impact op de ervaring van nieuwkomers, die yay zonder veel nadenken overnemen omdat dat nu eenmaal is wat het systeem en de officiële documentatie voorschrijven. Later ontdekken ze wellicht paru en overwegen ze of de verandering de moeite waard is.
In sommige discussies binnen de EndeavourOS-gemeenschap zelf is het volgende aan de orde gekomen. Ze zouden Paru standaard moeten opnemen.Veel gebruikers en teamleden hebben aangegeven dat ze daar geen echte noodzaak toe zien, omdat yay een degelijke, goed onderhouden en bekende tool blijft. Daarom lijkt het er op korte en middellange termijn niet op dat yay in deze distributie massaal vervangen zal worden door paru.
Bij andere Arch-afgeleiden (Artix, Manjaro, enz.) is de situatie vergelijkbaar: Het belangrijkste is dat je toegang hebt tot de AUR en een assistent kunt gebruiken.Maar welke je uiteindelijk gebruikt, hangt meestal af van wat de documentatie aanbeveelt, wat de community zegt, of simpelweg wat je als eerste hebt geprobeerd en wat goed voor je werkte.
Het is ook gebruikelijk om voor te stellen externe repositories te activeren, zoals Chaotisch-AUR Om de installatie van deze hulpprogramma's te vergemakkelijken zonder dat ze vanuit de AUR zelf gecompileerd hoeven te worden, leggen sommige handleidingen uit hoe het systeem voorbereid moet worden, hoe deze repositories toegevoegd moeten worden en hoe yay of paru vervolgens direct als binaire pakketten geïnstalleerd kunnen worden, waardoor de initiële handmatige compilatiestap wordt vermeden.
Installeer en gebruik beide assistenten.
Een optie die door veel gebruikers, met name door gebruikers die dingen aan het uitproberen zijn, wordt geprefereerd, is installeer zowel yay als paru En leef een tijdje met beide. Op die manier kun je yay gebruiken voor wat je al routinematig doet en met paru experimenteren voor specifieke taken, waarbij je de ervaring en functies op je eigen hardware vergelijkt.
Aangezien deze tools afhankelijk zijn van pacman en makepkg, Ze lopen elkaar niet in de weg en verstoren het systeem niet door naast elkaar te bestaan.Met het ene programma kun je pakketten installeren, met het andere updates weergeven en zonder grote problemen blijven werken, zolang je maar weet wat je doet. Als je eenmaal je voorkeuren hebt bepaald, kun je, om het jezelf makkelijker te maken, alleen het programma behouden dat je het prettigst vindt en de andere verwijderen.
In sommige specifieke gevallen wordt aanbevolen om te installeren Paru gebruikt Yay. (aangezien yay standaard op de distributie is geïnstalleerd), probeer het eens uit, en als het bevalt, schakel dan je scripts, aliassen en gewoontes over naar paru en laat yay achterwege. Maar, om het nogmaals te benadrukken, Er bestaat geen technische verplichting om deze wijziging door te voeren.Het is meer een kwestie van smaak en filosofie.
Aan de andere kant zijn er mensen die er de voorkeur aan geven om altijd de "standaard" methode te volgen: Installeer de hulpprogramma's rechtstreeks vanuit de AUR met behulp van makepkg.Om de consistentie met de pure en eenvoudige Arch-filosofie te behouden. In beide gevallen is het eindresultaat hetzelfde: je hebt een functionele assistent die het gebruik van de AUR vereenvoudigt.
Als we al deze nuances samen bekijken, wordt duidelijk dat Beide assistenten voorzien zeer goed in de behoeften van de gemiddelde Arch-gebruiker.Paru automatiseert AUR-interacties, houdt het systeem up-to-date en biedt bepaalde gemakken die Pacman, per definitie, niet biedt. Paru richt zich meer op herzieningen en een iets verfijndere werking, terwijl Yay een zeer vertrouwde, snelle en beproefde ervaring biedt, wat verklaart waarom zoveel mensen er trouw aan blijven ondanks de komst van nieuwere alternatieven.
