Frequently asked questions (Magyar)

Related articles

• Arch terminology (Magyar)
• Arch compared to other distributions (Magyar)
• Arch User Repository (Magyar)#Gyakran ismételt kérdések
• General troubleshooting (Magyar)

Általános

Mi az Arch Linux?

Tekintse meg az Arch Linux cikket.

Miért nem akarnék Arch Linuxot használni?

Lehetséges, hogy Ön nem szeretné az Arch Linuxot használni, amennyiben:

• Önben nincs meg a képesség/idő/vágy egy "csináld magad" típusú GNU/Linux disztribúció használatához.
• Önnek az x86_64 architektúrától eltérő, másik architektúrához van szüksége támogatásra.
• Ön határozottan ragaszkodik ahhoz, hogy olyan disztribúciót használjon, amely kizárólag a GNU által meghatározott szabad szoftvereket tartalmaz.
• Ön úgy véli, hogy egy operációs rendszernek automatikusan be kellene önmagát állítania, azonnal működnie kellene a telepítés után, és tartalmaznia kellene egy teljes alapértelmezett szoftvercsomagot, valamint egy asztali környezetet a telepítő adathordozón.
• Ön nem szeretne gördülő kiadású (rolling release) GNU/Linux disztribúciót használni.
• Ön elégedett a jelenlegi operációs rendszerével.

Miért szeretnék én Arch Linuxot használni?

Mert az Arch a legjobb.

Milyen architektúrákat támogat az Arch?

Az Arch kizárólag az x86_64 (más néven amd64) architektúrát támogatja. Az i686 támogatása 2017 novemberében meg lett szüntetve[1].

Léteznek nem hivatalos portok az i686 architektúrához [2] és az ARM processzorokhoz [3], mindegyikhez saját közösségi csatornák tartoznak.

Követi-e az Arch Linux a Linux Alapítvány által meghatározott Fájlrendszer-hierarchia szabványt (Filesystem Hierarchy Standard, FHS)?

Az Arch Linux követi a fájlrendszer-hierarchiát azon operációs rendszerek esetében, amelyek a systemd szolgáltatáskezelőt használják. A könyvtárak részletes magyarázatát és rendeltetését a file-hierarchy(7) súgóban találja. Különösen fontos, hogy a /bin, /sbin, és /usr/sbin szimbolikus hivatkozások a /usr/bin könyvtárra, míg a /lib és /lib64 szimbolikus hivatkozások a /usr/lib könyvtárra mutatnak.

Teljesen GNU/Linux kezdő vagyok. Használjam-e az Arch operációs rendszert?

Amennyiben Ön kezdő és használni szeretné az Arch operációs rendszert, akkor hajlandónak kell lennie időt fektetni egy új operációs rendszer elsajátításába, és el kell fogadnia, hogy az Arch egy 'csináld magad' disztribúcióként készült. A felhasználó az, aki összeállítja az operációs rendszert.

Mielőtt segítséget kérne, végezzen saját, független kutatást a weben, a fórumon és az Arch Wiki által biztosított kiváló dokumentációban. Megvan annak az oka, hogy ezek az erőforrások egyáltalán elérhetővé váltak az Ön számára. Több ezer órát töltöttünk önkéntes alapon ezen kiváló információk összeállításával.

Tekintse meg az Arch terminology (Magyar)#RTFM és a Telepítési útmutató leírásokat is.

Szerverre, asztali számítógépre vagy munkaállomásra való használatra van-e tervezve az Arch Linux?

Az Arch Linux nem egy meghatározott felhasználási célra lett tervezve, hanem egy meghatározott felhasználótípus számára. Az Arch célcsoportját azok a hozzáértő felhasználók alkotják, akik élvezik a az operációs rendszernek a "csináld magad" jellegét, és ezt kihasználva az operációs rendszert saját, egyedi igényeikhez igazítják. Ezért a célközönség kezében az Arch gyakorlatilag bármilyen célra felhasználható. Sokan használják az Arch Linuxot asztali számítógépen és munkaállomáson is egyaránt. Természetesen az archlinux.org, az aur.archlinux.org és az Arch szinte teljes infrastruktúrája is Arch Linuxon fut.

Imádom az Arch Linux operációs rendszert, ám a fejlesztőcsapatnak implementálnia kellene bele egy bizonyos funkciót

Kapcsolódjon be, járuljon hozzá saját programkódjával vagy megoldásával a közösséghez. Amennyiben azt a közösség és a fejlesztőcsapat is elismeri, akkor elképzelhető, hogy az beolvasztásra kerül. Az Arch közösség a kód és eszközök megosztására és közreműködésére épül.

Mikor lesz elérhető az új kiadás?

Az Arch Linux kiadásai egyszerűen egy telepítésre vagy mentésre szolgáló élő környezetet (live environment) jelentenek, amely tartalmazza a base (alap) meta szoftvercsomagot és néhány egyéb szoftvercsomagot. Az új kiadások általában minden hónap első felében jelennek meg.

Stabil disztribúció-e az Arch Linux? Számíthatok-e gyakori hibákra?

Végső soron az Arch Linux stabilitásáért Ön, mint felhasználó felel. A felhasználó dönti el, hogy mikor frissít, és a felhasználónak kell elvégeznie a szükséges módosítások összevonását is. Ha segítségre van szüksége, a közösség gyakran gyorsan reagál. Az Arch és más disztribúciók közötti különbség ebben az, hogy az Arch valóban egy "csináld magad" operációs rendszer, a hibák miatti panaszok félrevezetőek és nem célravezetők, mivel a upstream változtatások nem az Arch fejlesztők felelősségi körébe tartoznak.

Tekintse meg a Rendszerkarbantartás című cikket, amely hasznos tanácsokat nyújt arra vonatkozóan, hogy miként teheti az Arch Linux operációs rendszert a lehető legstabilabbá.

Több sajtóra (azaz reklámra) van szüksége az Arch operációs rendszernek

Az Arch Linux már így is számos sajtómegjelenést kap. A célja nem az, hogy nagy legyen, ehelyett a szerves, fenntartható növekedés természetes módon megy végbe a célzott felhasználói körben.

Több fejlesztőre van szüksége az Arch operációs rendszernek

Lehetséges. Amennyiben szeretné, bátran ajánlja fel az idejét önkéntesként! Látogassa meg a fórumot, az IRC csatornákat, levelezőlistákat, és nézze meg, hogy mire van szükség. További részletekért tekintse meg a Bekapcsolódás című leírást is.

Telepítés

Szükség lenne egy telepítőszoftverre az Arch Linux operációs rendszernek. Talán egy grafikus felületű telepítő jó lenne.

Egy irányított telepítő elérhető szöveges felhasználói felülettel. A részletekért tekintse meg az archinstall nevű telepítőszoftvert.

Feltelepítettem az Arch Linuxot, és most egy parancssorban vagyok. Mi a következő lépés?

Tekintse meg az Általános ajánlások -General recommendations (Magyar)- című leírást.

Melyik asztali környezetet vagy ablakkezelőt érdemes használnom?

Mivel sok lehetőség áll rendelkezésére, válassza azt, amelyik leginkább megfelel az Ön igényeinek. Tekintse meg az Asztali környezet és az Ablakkezelő című cikkeket.

Mi teszi az Arch operációs rendszert egyedivé a többi "minimális" disztribúcióhoz képest?

Tekintse meg az Arch összehasonlítása más disztribúciókkal -Arch compared to other distributions (Magyar)- című leírást.

Rendszerkarbantartás

Tekintse meg továbbá a System maintenance (Magyar) leírást is.

Miért ilyen lassú az internetem más operációs rendszerekhez képest?

Helyesen van-e beállítva az Ön hálózata? Nézze meg a hálózati beállításról szóló cikket. Speciális beállításokhoz érdemes lehet a forgalomszabályozást is megnézni.

Az egyik leggyakrabban használt kernel, a linux, általában újabb, mint más, stabilabb Linux-disztribúciók kernelje. Emiatt ritkán előfordulhat kernel-regresszió vagy illesztőprogram-hiba, különösen Wi-Fi használata esetén. Fontos megjegyezni, hogy ezeknek a hibáknak a túlnyomó többsége nem Arch Linux-specifikus, mivel az Arch Linux csak a legalapvetőbb javításokat alkalmazza. Ezeket a hibákat a fejlesztési lánc magasabb szintjein kell kezelni (upstream). Tekintse meg a #Hibát találtam a(z) X szoftvercsomagban. Mit tegyek? leírást.

Miért használja az Arch operációs rendszer a számítógépem összes RAM memóriáját?

A lényeg, hogy a kihasználatlan RAM memória az egyenlő az elpazarolt RAM memóriával.

Sok új felhasználó észreveszi, hogy a Linux kernel másképpen kezeli a számítógép memóriáját, mint ahogyan azt a felhasználók korábban megszokták. Mivel az adatok elérése a RAM memóriából sokkal gyorsabb, mint a háttértárról, ezért a kernel a nemrég használt adatokat a memóriában tárolja gyorsítótárként. Ez a gyorsítótárazott adat kizárólag akkor kerül törlésre, amikor az operációs rendszer kezd kifogyni a rendelkezésre álló össz memóriakapacitásból, és új adatok betöltésére van szükség.

A free parancsot futtatva láthatjuk a különbséget:

$ free -h

              total        used        free      shared  buff/cache   available
Mem:          2.8Gi       1.1Gi       283Mi       224Mi       1.4Gi       1.2Gi
Swap:         3.0Gi       881Mi       2.1Gi

Fontos megjegyezni a "szabad" és az "elérhető" memória közötti különbséget. Az előző példában egy 2,8 GiB összmemóriával rendelkező laptop látszólag a legtöbb RAM memóriát használja, mivel csak 283 MiB szerepel szabad memóriaként. Azonban ebből 1,4 GiB a "buff/cache" kategóriába tartozik. Így még mindig 1,2 GiB áll rendelkezésre új alkalmazások indításához, csere (swap) memóriaterület nélkül. További részletekért tekintse meg a free(1) súgót. Mindennek mi az eredménye? Hát a teljesítmény!

Ha felkeltette az érdeklődését, akkor tekintse meg ezt a nagyszerű cikket. Létezik egy weboldal is, amely kifejezetten ennek a félreértésnek a tisztázására jött létre: https://www.linuxatemyram.com/.

Hová tűnt az összes szabad helyem?

A kérdésre adott válasz az Ön rendszerétől függ. Létezik néhány kiváló segédszoftver, amelyek segíthetnek megtalálni a választ.

Miért nem tudok bejelentkezni?

Előfordult-e, hogy elgépelte a jelszavát, vagy megszakított egy sudo parancsot három alkalommal tizenöt percen belül? Ha igen, akkor egy védelmi mechanizmus lépett életbe a brute-force típusú támadások kivédése ellen: További részletekért tekintse meg a Security (Magyar)#Felhasználó kizárása három sikertelen bejelentkezési kísérlet után leírást.

"Jelent-e haza" az Arch?

Röviden? Nem.

Részletesebben:

• A NetworkManager felhasználóinak tudniuk kell, hogy az operációs rendszer automatikus kapcsolati ellenőrzéseket végez: Az alapértelmezett kapcsolati URL címet az Arch biztosítja, és vállalja, hogy nem naplózza a hozzáféréseket.
• A Network Time Protocol (NTP) kliensek alapértelmezett beállításukban egy gyártói NTP szervercsoportot] használnak, amelyet az NTP Pool Project biztosít (saját szabályai szerint).

• Amint azt a megjegyzés is kifejti a Pacman (Magyar)/Package signing (Magyar)#Rendszeresen frissítse az operációs rendszert részben, egy systemd időzítő hetente egyszer lefut, hogy frissítse a már megbízható kulcsok új aláírásait: Ott sincs semmilyen hozzáférés naplózva.

Önkéntesen dönthet úgy, hogy "hazatelefonál", azaz hozzájárul a pkgstats projekthez, amely névtelen adatokat gyűjt a szoftvercsomagok népszerűségéről, ezzel segítve az Arch fejlesztőit abban, hogy hatékonyabban tudják meghatározni fejlesztési prioritásaikat.

Szoftvercsomag-kezelés

További válaszokért tekintse meg a pacman, pacman (Magyar)/Tips and tricks (Magyar) és Official repositories (Magyar) oldalakat.

Hibát találtam egy bizonyos szoftvercsomagban. Mit tegyek?

Önnek először meg kell állapítania, hogy ez a hiba olyasmi-e, amit az Arch csapat kijavíthat. Gyakran nem az (például a Firefox összeomlásai lehetnek a Mozilla csapat hibái). Ezt úgynevezett upstream hibának nevezik. Tekintse meg a Hibabejelentési irányelvek #Upstream vagy Arch? leírást. Ha Arch-specifikus problémáról van szó, akkor jó néhány lépést tehet:

1. Keresse fel a fórumot információért. Nézze meg, hogy más is észlelte-e a problémát.
2. Küldjön hibajelentést részletes információkkal az Arch Linux Gitlab hibakövető rendszerében.
3. Ha szeretné, akkor írjon egy fórumhozzászólást, amely részletesen ismerteti a problémát, valamint azt a tényt, hogy már bejelentette az adott hibát. Ez segít megelőzni, hogy sokan ugyanazt a hibát újra bejelentsék.

Egyedi névadási konvenciót kell használniuk az Arch szoftvercsomagoknak. Túl hosszú a ".pkg.tar.zst" és/vagy zavaró.

Ez a téma már szóba került az Arch levelezőlistán. Néhányan a .pac fájlkiterjesztést javasolták, de nincs tervben a szoftvercsomag kiterjesztésének a megváltoztatása. Ahogy Tobias Kieslich, az Arch egyik fejlesztője fogalmazott: "A szoftvercsomag valójában egy [tömörített] tarball! Bármely tar-kompatibilis alkalmazással megnyitható, megvizsgálható és módosítható. Ráadásul a MIME-típusát a legtöbb alkalmazás automatikusan helyesen ismeri fel."

A pacman szoftvercsomag-kezelőnek szüksége van egy függvénykönyvtárra, ezáltal más alkalmazások is könnyen hozzáférhetnek a szoftvercsomag-információkhoz

A pacman a libalpm(3) — az "Arch Linux szoftvercsomag-kezelő" programozói függvénykönyvtárának — front-end szoftvere, amely lehetővé teszi alternatív front-end szoftverek, például grafikus felhasználói felületek létrehozását.

A pacman szoftvercsomag-kezelőnek szüksége van egy bizonyos funkcióra!

Amennyiben Ön úgy gondolja, hogy egy ötletnek létjogosultsága van, akkor megfontolhatja, hogy megvitassa azt a pacman-dev levelezőlistán. Emellett ellenőrizze a https://gitlab.archlinux.org/pacman/pacman/-/issues oldalt a meglévő funkciók kérésének tekintetében.

Azonban a legjobb módja annak, hogy egy bizonyos funkció bekerüljön a pacman szoftvercsomag-kezelőbe vagy az Arch Linux operációs rendszerbe, ha azt Ön, tehát saját maga valósítja meg. Lehetséges, hogy a javítást vagy a kódot hivatalosan nem fogadják el, de előfordulhat, hogy mások értékelik, tesztelik és hozzájárulnak az Ön munkájához.

Most telepítettem egy bizonyos szoftvercsomagot. Hogyan indíthatom el?

Ha KDE vagy GNOME asztali környezetet használ, akkor a szoftvernek automatikusan meg kell jelennie a menüben, amennyiben az rendelkezik asztali bejegyzéssel. Ha az adott szoftvert parancssorból szeretné futtatni, de nem ismeri a bináris futtatható fájlnak a nevét, akkor használja a következő parancsot:

$ pacman -Qlq szoftvercsoamg_neve | grep /usr/bin/

Miért van csak egyetlen verzió minden megosztott függvénykönyvtárból a hivatalos szoftvercsomag-tárolókban?

Számos disztribúció, úgy mint a Debian, a megosztott függvénykönyvtárak különböző verzióit különálló szoftvercsomagokba csomagolja be: libfoo1, libfoo2, libfoo3 és így tovább. Ily módon lehetőség van arra, hogy ugyanazon az operációs rendszeren különböző libfoo verziókra lefordított alkalmazások legyenek telepítve.

Egy Arch operációs rendszerhez hasonló Linux disztribúció esetén csak a legfrissebb becsomagolt verziók kapnak hivatalos támogatást. Az elavult szoftverek támogatásának megszüntetésével a csomagkarbantartók több időt tudnak fordítani arra, hogy biztosítsák az újabb verziók megfelelő működését. Amint egy megosztott függvénykönyvtár új verziója elérhetővé válik az upstream forrásból, bekerül a szoftvercsomag-tárolókba, és az érintett szoftvercsomagokat újraépítik, hogy az új verziójú függvénykönyvtárat használják.

Mi történik, ha teljes operációsrendszer-frissítést hajtok végre, és frissül egy megosztott függvénykönyvtár, de nem frissülnek azok az alkalmazások, amelyek függnek tőle?

Ez a forgatókönyv elvileg egyáltalán nem fordulhat elő. Feltételezve, hogy egy foobaz nevű alkalmazás szerepel a hivatalos szoftvercsomag-tárolókban, és forráskódból sikeresen lefordítható a libbaz nevű megosztott függvénykönyvtár új verziójával, akkor a foobaz frissítése a libbaz frissítésével együtt történik. Ha azonban nem fordítható le sikeresen a forráskódból, akkor a foobaz szoftvercsomag verzióhoz kötött szoftvercsomag-függőséget kap (például libbaz 1.5), és a pacman eltávolítja a libbaz frissítésekor, mivel ütközés lép fel.

Ha a foobaz egy olyan szoftvercsomag, amelyet Ön, saját maga készített, és az AUR szoftvercsomag-tárolóból telepített, akkor forráskódból újra kell fordítania a foobaz szoftvercsomagot a libbaz szoftvercsomag új verziója ellenében. Ha a forráskód lefordítása sikertelen, akkor jelentse a hibát a foobaz fejlesztőinek.

Lehetséges-e, hogy a szoftvercsomag-tárolóban elérhető egy nagyobb kernelfrissítés, miközben néhány illesztőprogram-szoftvercsomag még nem lett frissítve?

Nem, ez nem lehetséges. A nagyobb kernelfrissítéseket (például linux 3.5.0-1-ről linux 3.6.0-1-re) mindig kíséri az összes támogatott kernelillesztőprogram-szoftvercsomag forráskódból történő újrafordítása. Másrészt, ha egy nem támogatott illesztőprogram-szoftvercsomag van telepítve az Ön operációs rendszerére (például az AUR szoftvercsomag-tárolóból), akkor egy kernelfrissítés problémákat okozhat, amennyiben forráskódból nem fordítja újra az adott szoftvercsomagot az új kernelhez. A felhasználók felelősek azért, hogy frissítsék az általuk telepített nem támogatott illesztőprogram-szoftvercsomagokat.

Mit kell tenni az operációs rendszer frissítése előtt?

Kövesse a System maintenance (Magyar)#Operációs rendszer frissítése leírást.

Megjelent egy szoftvercsomag-frissítés, de a pacman szerint az operációs rendszer naprakész állapotban van

A pacman tükörszerverek nem szinkronizálódnak azonnal. Előfordulhat, hogy több mint 24 órát kell várnia, mire az adott frissítés elérhetővé válik az Ön számára is. Az egyetlen lehetőség, hogy türelmes marad, vagy másik szoftvercsomagokat tartalmazó tükörszervert használ. A MirrorStatus weboldal segíthet az aktuális, naprakész tükörszerver kiválasztásában.

Bizonyos upstream projekt kiadott az adott szoftverből egy újabb verziót. Mennyi időbe telik, amíg az Arch szoftvercsomag frissül erre az új szoftververzióra?

A szoftvercsomag-frissítések akkor kerülnek kiadásra, amikor azok készen állnak arra, hogy ki legyenek adva. A frissítés időtartama az upstream által kiadott kisebb hibajavítás után akár néhány óra is lehet, míg egy nagyobb szoftvercsomagcsoport főverziójának frissítése akár több hétig is eltarthat. Az upstream új verziója és az Arch szoftvercsomag-frissítésének megjelenése közötti idő a konkrét szoftvercsomagoktól és a szoftvercsomag-karbantartók rendelkezésre állásától függ. Emellett egyes szoftvercsomagok először a testing szoftvercsomag-tárolóba kerülnek, ami meghosszabbíthatja a frissítés megjelenésének az idejét. A szoftvercsomag-karbantartók igyekeznek gyorsan dolgozni, hogy stabil frissítéseket juttassanak el a szoftvercsomag-tárolókba. Amennyiben Ön az Arch hivatalos szoftvercsomag-tárolóiban elavult szoftvercsomagot talál, akkor kérjük, látogasson el az adott szoftvercsomag oldalára, és jelölje azt meg elavultként.

Amennyiben egy telepített függvénykönyvtár régebbi verziójára van szükségem, akkor szimbolikus hivatkozást létrehozhatok-e az újabb verzióra?

Ha szerencséje van, akkor egy ideig működhet. Ennek ellenére ez a módszer nem a megfelelő megoldás, mert:

• A függvénykönyvtárak verziói nem véletlenszerűen változnak – az API/ABI nagy valószínűséggel módosult (esetleg bizonyos részek el lettek távolítva belőle), és hogy ezek a változások befolyásolják-e a használatot, az pusztán a szerencse kérdése.
• A szimbolikus hivatkozást a szoftvercsomag-kezelő nem követi nyomon. A kezdő felhasználók, akik azonnal megpróbálnak módosításokat (kókányolásokat, hackeléseket, patkolásokat) végezni a az operációs rendszer függvénykönyvtárain, fokozottan ki vannak téve annak a veszélynek, hogy olyan nem kívánt változtatásokat hajtanak végre, amelyeket nem tudnak diagnosztizálni vagy kijavítani. Ebben nyújt védelmet a szoftvercsomag-kezelő.
• Egy enyhébb alternatíva, amikor a régi függvénykönyvtárfájlt egyszerűen bemásolja a fájlrendszerbe anélkül, hogy azt a szoftvercsomag-kezelő nyomon követné, könnyen feledésbe merülhet, és az esetleges biztonsági hibák így nem kerülnek felismerésre vagy javításra.

Ehelyett például használjon vagy írjon egy kompatibilitási (compat) szoftvercsomagot, amely biztosítja a szükséges függvénykönyvtár-verziót.

64-bit

Hogyan tudom megállapítani, hogy a processzorom kompatibilis az x86_64 architektúrával?

Ha az Ön processzora kompatibilis az x86_64 architektúrával, akkor a /proc/cpuinfo fájlban megtalálható lesz az lm (long mode) jelölőzászló. Például:

$ grep -w lm /proc/cpuinfo

Windows rendszeren az ingyenes CPU-Z program használatával megállapítható, hogy az Ön processzora kompatibilis-e a 64 bites architektúrával. Azok a CPU-k, amelyek az AMD "AMD64" utasításkészletét vagy az Intel "EM64T" megoldását használják, kompatibilisek kell, hogy legyenek az x86_64 kiadásokkal és bináris szoftvercsomagokkal.

Miért érdemes 64 bites architektúrát használni?

A 64 bites architektúra a legtöbb esetben gyorsabb, és ráadásként biztonságosabb is, mivel az Address Space Layout Randomization (ASLR) technika, a Position-independent Code (PIC) és az NX Bit együttes alkalmazása révén fokozott védelmet nyújt. Ezek a funkciók nem érhetők el az alapértelmezett i686 kernelben, mivel abban a Physical Address Extension (PAE) ki van kapcsolva. Amennyiben az Ön számítógépében több mint 4 GiB RAM található, kizárólag egy 64 bites operációs rendszer képes azt teljes mértékben kihasználni.

A programozók egyre kevésbé foglalkoznak a 32 bites ("örökölt") architektúrával, mivel az "újabb" x86 processzorok jellemzően támogatják a 64 bites kiterjesztéseket.

Számos további érvet is felsorolhatnánk amellett, hogy miért érdemes elkerülni a 32 bites operációs rendszert, de a kernel, a felhasználói tér és az egyes programok szintjén annyi terület van, ahol a 64 bites megoldás ma már sokkal jobban teljesít, hogy egyszerűen nem lenne kivitelezhető minden egyes előnyt részletesen felsorolni.