Frequently asked questions (Magyar)

Fordítás állapota:
Ez az oldal az angol
Frequently asked questions
című oldal magyar nyelvre lefordított változata. Utolsó fordítás dátuma: 2026.02.19. Amennyiben a lefordítás időpontja óta az angol nyelvű oldalon történtek újabb
módosítások
, akkor Ön segíthet hozzászinkronizálni az angolhoz ezt a magyar nyelvű fordítást.
További oldalak az adott témakörben
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 származtatott disztribúciók az i686 architektúrához
[2]
és az
ARM
processzorhoz
[3]
. Mindegyiknek megvan a saját közösségi csatornája. Ezeket az Arch Linux
nem támogatja
.
Amennyiben Ön azt szeretné, hogy az Arch más architektúrákat is támogasson, akkor segíthet a meglévő
portolási
erőfeszítésekben, vagy elindíthatja a sajátját. Részletekért tekintse meg a
Getting involved#Help porting Arch Linux to other architectures
leírást.
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#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
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
című leírást.
Rendszerkarbantartás
Továbbá, tekintse meg a
System maintenance
című cikket 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 egy bizonyos 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:           377Gi        40Gi       146Gi       1.1Gi       196Gi       337Gi
Swap:          377Gi       1.1Gi       376Gi
Fontos megjegyezni a "szabad" ("free") és az "elérhető" ("available") memória közötti különbséget. A fenti példában egy 377 GiB összes RAM memóriával rendelkező rendszer úgy tűnik, hogy több mint a fele memóriát használja, és csak 146 GiB a szabad memória. Azonban ebből 196 GiB a "buff/cache" kategóriába tartozik. Így - csere (swap) nélkül - még mindig 337 GiB áll rendelkezésre új alkalmazások indításához. További részletekért tekintse meg a
free(1)
man 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#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/Package signing#Rendszeresen frissítse az operációs rendszert
című 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.
A tükörszerverlistát frissítő szoftver, a
Reflector
, letölti a tükörszerverlistát az
archlinux.org
webhelyről. Az live telepítési környezetben alapértelmezetten engedélyezve van, és
amint hálózati kapcsolat létrejön, azonnal lefut
.
Ö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/Tips and tricks
és
Official repositories
című cikkeket.
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:
Keresse fel a fórumot információért. Nézze meg, hogy más is észlelte-e a problémát.
Küldjön
hibajelentést
részletes információkkal az
Arch Linux GitLab hibakövető rendszerében
.
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.
Arch packages need to use a unique naming convention. ".pkg.tar.zst" is too long and/or confusing
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#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.