Frequently asked questions (Čeština)
Obecné
Co je to Arch Linux?
Vizte článek Arch Linux.
Proč bych nemusel chtít používat Arch?
Arch Vám nebude vyhovovat, pokud:
- nemáte chuť/prostředky/dovednosti na spravování GNU/Linux distribuce;
- potřebujete podporu pro architekturu jinou než x86_64;
- si skálopevně stojíte za svobodným softwarem, jak je popsán podle GNU;
- věříte, že operační systém by měl nastavit sám sebe, být provozuschopný ve výchozím stavu, a obsahovat plochové prostředí a plnou sadu softwaru na instalačním médiu;
- nepřejete si rolling-release GNU/Linux distribuci;
- jste šťastni s Vašim nynějším operačním systémem.
Proč bych chtěl používat Arch?
Protože Arch je nejlepší.
Které architektury podporuje Arch?
Arch podporuje výhradně x86_64 (jež je občas nazývaná amd64) architekturu. Přestali jsme podporovat i686 od listopadu 2017 [1].
Jsou k mání neoficiální vydání pro i686 architekturu [2] a ARM procesory [3]; každé má své vlastní komunitní kanály.
Řídí se Arch podle FHS (Filesystem Hierarchy Standard) od Linux Foundation?
Arch Linux se řídí podle file system hierarchy pro operační systémy, které užívají systemd správce služeb. Vizte file-hierarchy(7) pro vysvětlivky každého adresáře a jejich určení. Hlavně /bin, /sbin a /usr/sbin jsou symbolické odkazy na usr/bin, také /lib a /lib64 jsou symbolické odkazy na /usr/lib.
Jsem úplný GNU/Linux začátečník. Měl bych používat Arch?
Jste-li začátečník a chcete používat Arch, musíte být ochotni věnovat čas učení se novému systému a přijat skutečnost, že Arch je 'udělej-si-to-sám' (DIY; do it yourself) distribuce; uživatel je ten, kdo si skládá systém.
Ještě než se budete ptát ostatních, pokuste se sami vyzkoumat, jak vyřešit problém, vyhledáváním na internetu nebo naší skvělé Arch Wiki. Je velmi dobrý důvod, proč jsou tyto zdroje Vám vůbec přístupné. Tisíce lidí dobrovolně strávili mnohé hodiny, aby byla tato výjimečná ponaučení přístupná všem.
Vizte také Arch terminologii#RTFM a Instalační příručku.
Arch není navržen pro žádný neobvyklý způsob použití. Místo toho je navržen pro daný typ uživatele. Arch se zaměřuje na schopné uživatele, kteří oceňují 'udělej-si-to-sám' přístup a vytváří si systém tak, aby vyhovoval jejich jedinečným potřebám. Proto v rukou uživatele z cílené skupiny lze Arch použít prakticky pro cokoli. Mnozí využívají svůj Arch systém na desktopech i pracovních stanicích. A samozřejmě archlinux.org běží na Archu.
Velmi se mi líbí Arch, ale tým vývojářů musí implementovat funkci X
Zúčastněte se, přispějte komunitě svým kódem či řešením. Bude-li to uznáváno komunitou a vývojovým týmem, možná se to sjednotí s hlavním projektem. Arch komunita prospívá díky komunitním příspěvkům a sdílení kódu nebo nástrojů.
Kdy bude vydána další verze?
Arch GNU/Linux vydání jsou jednoduše pouze živá prostředí pro instalaci nebo záchranu systému; skládají se z base meta balíčku a několik jiných balíčků. Vydáváme nové verze často v první polovině každého měsíce.
Je Arch stabilní distribuce? Nedojde často k rozbití?
Je to právě uživatel, kdo je koneckonců odpovědný za stabilitu svého rolling-release systému; uživatel se rozhoduje, kdy aktualizovat, a sjednocuje podstatné změny, je-li to podstatné. Pokud uživatel zkonzultuje komunity, brzy se mu dostane pomoci. Rozdíl mezi Arch a jinými distribucemi je ten, že Arch vskutku je 'udělej-si-to-sám' druh distribuce; stížnosti na rozbití jsou scestné a neúrodné, neboť upstream změny nejsou odpovědnost Arch vývojářů.
Vizte článek Údržba systému pro rady, jak zajistit, aby Arch GNU/Linux systém byl stabilní.
Arch potřebuje více reklamy
Archu se dostává reklamy, kolik jen jde. Cílem Arch Linuxu není být velký; přirozený a udržitelný růst se vyskytuje spíše mezi uživateli.
Arch potřebuje více vývojářů
Možné to je. Ciťte se svobodnými dobrovolně obětovat Váš čas! Navštivte fóra, IRC kanály, emailové konference a podívejte se, co je potřeba udělat. Vizte také Jak se zúčastnit pro podrobnosti.
Instalace
Arch potřebuje instalátor. Možná grafický instalátor?
Arch míval instalátor s textově založeným uživatelským rozhraním nazývaným Arch Installation Framework (AIF). Potom, co se o něj přestal starat poslední vývojář, byl odmítnut a nahrazen arch-install-scripts.
Od 2021-04-01 Arch opět nabízí instalátor. Vizte archinstall pro podrobnosti.
Nainstaloval jsem Arch a nacházím se v shellu! Co nyní?
Vizte Obecná doporučení.
Které plochové prostředí nebo správce oken bych měl použít?
Jelikož se jich nabízí hodně, zvolte takový, který Vám nejvíce vyhovuje. Podívejte se na články Plochová prostředí a Správce oken.
Čím Arch vyniká mezi jinými "minimalistickými" distribucemi?
Vizte Arch v porovnání s jinými distribucemi.
Údržba systému
Vizte také Údržbu systému.
Proč je můj internet tak pomalý ve srovnání s ostatními operačními systémy?
Je Vaše připojení správně nastaveno? Podívejte se na stránku Konfigurace sítě.
Poznamenejme, že Arch GNU/Linux nemá ve výchozím stavu povoleno řízení provozu. Proto je možné, že když program nějakým způsobem využije plnou rychlost Vašeho připojení (nehledě na to, zdali se jedná o P2P provoz nebo o klasická klient-server spojení), dojde k ucpání, což vede ke znatelným zpožděním a časovým prodlevám. Úlevu mohou poskytnout firewally, např. Shorewall nebo Vuurmuur; též jsou k mání statické skripty pro iproute2 (např. tento derivát Wondershaperu), které povolí řízení provozu na síťové vrstvě.
Proč Arch využívá celou moji RAM?
Stručně řečeno, nevyužitá RAM je zbytečná RAM.
Mnoho nových uživatelů si všimne, jak Linuxové jádro zachází s pamětí jinak, než jsou zvyklí. Protože přístup k datům z RAM je mnohem rychlejší než k datům na disku, jádro ukládá data z disku do RAM a vytváří tím mezipaměť. Data v mezipaměti jsou uvolněna pouze pokud místo v RAM začne docházet a je potřeba uložit nová data.
Asi nejběžnějším viníkem tohoto zmatení je příkaz free:
$ free -m
total used free shared buffers cached Mem: 1009 741 267 0 104 359 -/+ buffers/cache: 278 731 Swap: 1537 0 1537
Je důležité zdůraznit řádek -/+ buffers/cache: -- reprezentuje totiž množství paměti, která je aktivně používána, a množství dostupné paměti namísto nevyužité paměti.
V příkladě výše máme notebook s celkově 1G RAM. Na první pohled to vypadá, že je využito 741M, přičemž je spuštěno pouze několik terminálů a webový prohlížeč! Ale po důkladnějším prozkoumání zdůrazněného řádku vidíme, že pouze 278M je aktivně používáno a 731M je dostupno. Očividně 104M použité paměti obsahuje data v bufferech a 359M obsahuje data v mezipaměti; oboje může být uvolněno, pokud by bylo potřeba. Pouze 267M z celkového 1G je opravdu volno.
A výsledek tohoto chování? Výkon!
Vizte tento skvělý článek, pokud jste zvědaví. Za účelem vysvětlení tohoto omylu také existuje webová stránka.
Kam mi zmizelo všechno volné místo?
Odpověď na tuto otázku záleží na Vašem systému. Můžete užít skvělých utilit, jež Vám pomohou najít odpověď.
Správa balíčků
Vizte články pacman, pacman/Tipy a triky a Oficiální repozitáře pro více odpovědí.
Našel jsem chybu v balíčku XY. Co bych měl udělat?
Nejdříve potřebujete zjistit, zda může tuto chybu opravit tým Arch GNU/Linuxu. Někdy nemůže (např. padající Firefox může být důsledkem chyby týmu Mozilly). Takováto chyba se nazývá upstream error. Pokud je to problém Archu, je posloupnost kroků, jež můžete udělat, následující:
- Hledejte podrobnosti na fórech. Podívejte se, zda si chyby nevšiml i někdo jiný.
- Odešlete zprávu o chybě s důkladným popisem na https://bugs.archlinux.org
- Můžete napsat příspěvek na fóra, kde podrobně popíšete problém a skutečnost, že jste už o tom podali zprávu. Pomůže to mnohým lidem, aby neposílali zprávu o té samé chybě.
Balíčky Archu potřebují jednotnou příponu. ".pkg.tar.gz" a ".pkg.tar.xz" jsou příliš dlouhé a/nebo matoucí
O tomto se jednalo na emailové konferenci. Byla navržena přípona .pac. V současnosti není v plánu změnit současnou příponu balíčků. Jak napsal Tobias Kieslich, jeden z vývojářů Archu, "Balíček je [kompresovaný] tarball! A může být otevřen, prozkoumán a manipulován libovolnou aplikací, která umí formát tar. Navíc typ MIME je automaticky většinou aplikací správně rozpoznán."
Pacman potřebuje knihovnu, aby ostatní aplikace mohly mít snadný přístup k informacím o balíčku
Pacman je front-end pro libalpm(3), "Arch Linux Package Management" knihovnu, jež povoluje užití jiných frontendů, včetně GUI.
Pacman potřebuje funkci X!
Myslíte-li si, že daný nápad má hodnotu, můžete si o tom promluvit zde. Též se podívejte na https://bugs.archlinux.org/index.php?project=3[dead link 2024-01-13 ⓘ] pro seznam stávajících požadavků.
Poznamenejme, že nejlepším způsobem, jak přidat do pacmana či Arch GNU/Linuxu novou funkci, je stvořit si ji sám. Patch nebo kód může a nemusí být oficiálně přijat, ale ostatní mohou ocenit, testovat a přispět k Vašemu úsilí.
Nainstaloval jsem balíček X. Jak jej mám spustit?
Jestliže používaté plochové prostředí jako KDE nebo GNOME, program by se měl mimovolně zobrazit v nabídce. Pokud se pokoušíte spustit program z terminálu a neznáte název binárního souboru, zkuste následující příkaz:
$ pacman -Qlq jmeno_balicku | grep bin
Proč je k mání jenom jedna obdoba každé sdílené knihovny v oficiálních repozitářích?
Několik distribucí, jako například Debian, mají jiné verze sdílených knihoven jako jiné balíčky: libfoo1, libfoo2, libfoo3 a tak dále. Tímto způsobem je možné mít aplikace kompilované proti jiným verzím libfoo nainstalovaných na stejném systému.
Ale na distribuci jako je Arch, pouze poslední verze balíčků jsou oficiálně podporovány. Ukončením podpory pro starý software se mohou údržbáři balíčků věnovat jednomu úkolu, aby nejnovější verze byly provozuschopné. Jakmile je z upstreamu dostupná nová verze sdílené knihovny, je přidána do repozitářů a všechny ovlivněné balíčku jsou znovu sestaveny, aby užívaly nové verze.
Co když spustím úplnou aktualizaci systému a vyskytne se i aktualizace pro sdílenou knihovnu, ale ne pro aplikace, které na ní závisí?
Tento případ by se vůbec neměl stávat. Předpokládejme, že aplikace zvaná foobaz je v jednom z oficiálních repozitářů a je úspěšně sestavená vůči nové verze sdílené knihovny zvané libbaz; pak bude aktualizovaná spolu s libbaz. Nicméně pokud se nesestaví úspěšně, foobaz bude mít verzovanou závislost (například libbaz 1.5) a bude odstraněna pacmanem po další aktualizaci libbaz kvůli sporu.
Pokud foobaz je balíček, který jste si sami sestavili a nainstalovali z AUR, měli byste zkusit jej znovu sestavit proti nové verzi libbaz. Pokud sestavování selže, nahlaste chybu foobaz vývojářům.
Je možné, aby byla v repozitáři nová verze jádra a aby některé balíčky ovladačů nebyly aktualizovány?
Ne, není to možné. Velké aktualizace jádra (například linux 3.5.0-1 na linux 3.6.0-1) jsou vždy doprovázeny sestavováním všech podporovaných jádrových ovladačů. Na druhé straně máte-li nainstalovaný nepodporovaný balíček ovladače (například z AUR) na svém systému, může aktualizace jádra rozbít Váš systém, pokud jej nesestavíte pro nové jádro. Uživatelé jsou odpovědní za aktualizování kterýchkoliv nepodporovaných balíčků ovladačů, jež nainstalovali.
Co mám dělat před aktualizací?
Řiďte se podle Údržba systému#Aktualizace systému.
Aktualizace balíčku byla vydána, ale pacman praví, že systém je aktuální
pacman zrcadla nejsou sladěna okamžitě. Může to trvat déle než 24 hodin, než bude dostupná aktualizace. Zbývá Vám jedině vyčkat nebo použít jiné zrcadlo. MirroStatus Vám může pomoci nalézt aktualizovaná zrcadla.
Upstream projekt X vydal novou verzi. Jak dlouho bude trvat, než se aktualizuje Arch balíček na novou verzi?
Aktualizace balíčků budou vydány, až budou připraveny. Nemůžeme Vám říct přesnou dobu; může to trvat jen několik hodin po tom, co upstream vydá malou bugfix aktualizaci, ale i několik týdnů po vydání velké aktualizace. Doba záleží na určitých baličích a dostupnosti údržbářů balíčků. Dodatečně mohou balíčky strávit čas v testing repozitáři; to může prodloužit čekání. Údržbáři balíčků se snaží pracovat rychle, aby poskytli stabilní aktualizace repozitářům. Naleznete-li balíček v oficiálním repozitáři, který je zastaralý, označte jej tak na stránce balíčku.
Potřebuji-li starou verzi nainstalované knihovny, mohu prostě užít symbolický odkaz na novou verzi?
Máte-li štěstí, může to jít, tedy alespoň chvíli. Nicméně rozhodně to není řádné řešení, neboť:
- Knihovny nemění verze náhodně - API/ABI se určitě mezi verzemi změnila (možná i odstranila); zdali to ovlivní využívání je záležitost štěstí.
- O symbolickém odkazu by správce balíčků nevěděl. Nováčci, již se okamžitě začnou hrabat v systémových souborech, jsou v největším nebezpečí, jelikož mohou zapříčinit omyl, z něhož se už nedostanou; proti tomu brání správce balíčků.
- Mírná alternativa vhozeného starého souboru knihovny do souborového systému, jsouc netrasovaná, by byla zapomenuta a nikdy by se neopravily bezpečnostní chyby.
Místo toho užijte/napište compat balíček, jenž poskytuje potřebnou verzi knihovny.
64-bit
Jak zjistím, zdali je můj procesor x86_64 kompatibilní?
Pokud Váš procesor je x86_64 kompatibilní, naleznete lm (long mode) vlajku v /proc/cpuinfo. Například,
$ grep -w lm /proc/cpuinfo
Pod Windowsem freewarový CPU-Z pomůže zjistit, zdali je Váš procesor 64bit kompatibilní. Procesory s AMD instrukční sadou "AMD64" nebo Intelovským "EM64T" by měly být kompatibilní s x86_64 vydáními a binárními balíčky.
Proč 64-bit?
Je to rychlejší v mnoha případech a jako dodatečný bonus je to též bezpečnější kvůli "Address space layout randomization (ASLR) v kombinaci s "Position-independent code (PIC) a NX Bit, jehož nelze využít v základním i686 jádře kvůli vypnutému "Physical Address Extension (PAE). Má-li Váš počítač víc než 4 GiB RAM, pouze 64bit OS bude schopen toho využít.
Programátoři se též začínají méně zajímat o 32bit ("legacy") a "nové" x86 procesory většinou podporují 64bit rozšíření.
Našli bychom mnohem více důvodů, proč se vyvarovat 32bit; nemá cenu vypisovat, co všechno 64bit řeší mnohem lépe, co se týká jádra, uživatelského prostoru či jednotlivých programů.