Frequently asked questions (Čeština)

Stav překladu:
Tento článek je přeložená obdoba "
Frequently asked questions
". Naposledy přeloženo: 2022-10-10. Můžete pomoci sladit překlad, byl-li původní článek
upraven
.
Související články
Arch terminology
Arch User Repository#Frequently asked questions
General troubleshooting
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
.
Je Arch navržen pro použití jako server? Jako desktop? Jako pracovní stanice?
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
[
dead link
2025-11-16—domain name not resolved]
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—HTTP 404]
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ů.