Frequently asked questions (Polski)

From ArchWiki
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Powiązane artykuły

Ogólne

Czym jest Arch Linux?

Przeczytaj artykuł o Arch Linux.

Kiedy nie powinienem używać Arch Linux?

Prawdopodobnie nie powinieneś używać Arch Linux jeśli:

  • nie masz umiejętności / czasu / chęci aby używać dystrybucji GNU/Linux opartej na zasadzie „zrób to sam” - jeśli przeraża Cię sama myśl o korzystaniu z wiersza poleceń (konsoli), Arch Linux nie jest na razie dla Ciebie.
  • potrzebujesz obsługi architektury innej niż x86_64.
  • nie chcesz używać dystrybucji, która zapewnia tylko darmowe oprogramowanie zdefiniowane przez GNU.
  • uważasz, że system operacyjny powinien się skonfigurować sam, być od razu gotowy do użycia i zawierać na nośniku instalacyjnym pełny domyślny zestaw oprogramowania i środowisko komputerowe.
  • nie chcesz rozpowszechniać dystrybucji GNU/Linux.
  • jesteś zadowolony ze swojego obecnego systemu operacyjnego.

Jakie architektury obsługuje Arch?

Arch obsługuje tylko architekturę x86_64 (czasami nazywaną amd64). Wsparcie dla i686 zostało porzucone w listopadzie 2017 r [1].

Istnieją nieoficjalne porty dla architektury i686 [2] i procesorów ARM [3], każdy z własną społecznością i kanałami komunikacji [4].

Czy Arch przestrzega standardów systemu plików Linux Foundation Hierarchy Standard (FHS)?

Arch Linux przestrzega hierarchii systemu plików dla systemów operacyjnych korzystających z menedżera usług systemd. Wpisz komendę man file-hierarchy, aby uzyskać wyjaśnienie dotyczące hierarchii katalogów w systemie wraz z ich oznaczeniami. Przykładowo /bin, /sbin i /usr/sbin są symbolicznymi linkami do /usr/bin a /lib i /lib64 to dowiązania symboliczne do /usr/lib.

Jestem zupełnie początkującym użytkownikiem systemu GNU/Linux. Czy powinienem używać Arch?

Jeśli jesteś początkujący i chcesz korzystać z Arch Linux, będziesz musiał poświęcić czas na naukę nowego systemu i zaakceptować fakt, że Arch Linux jest zaprojektowany jako dystrybucja z kategorii „zrób to sam”. To użytkownik składa cały system w całość i go konfiguruje.

Domyślna i podstawowa instalacja Arch Linux nie zawiera żadnego środowiska pulpitu (okienek), a cała jej obsługa odbywa się (przynajmniej na początku) jedynie poprzez wiersz poleceń (konsolę). Arch nie zawiera żadnych domyślnych konfiguratorów. Oczywiście możesz później doinstalować całe spektrum oprogramowania (w tym środowiska pulpitu) znajdujące się w oficjalnych i nieoficjalnych repozytoriach Arch, w tym w AUR.

Zanim poprosisz o pomoc, przeszukaj Google, nasze forum oraz doskonałą dokumentację dostarczoną przez Arch Wiki. Zasoby te zostały udostępnione użytkownikom nie bez powodu. Zgromadzenie tych użytecznych informacji zajęło ochotnikom wiele tysięcy godzin.

Zobacz także uwagi o zdobywaniu informacji na temat systemu oraz Instrukcję instalacji.

Czy Arch Linux został zaprojektowany do użytku domowego czy jako serwer?

Arch Linux nie ma jednego określonego zastosowania. Jest on raczej przeznaczony dla określonego typu użytkownika. Arch jest skierowany do kompetentnych użytkowników, którzy zgadzają się z filozofią "zrób to sam" i którzy lubią dostosowywać system do własnych potrzeb. Dlatego w rękach członka docelowej bazy użytkowników, Arch Linux może być używany praktycznie do każdego celu. Wielu korzysta z Arch zarówno na swoich komputerach stacjonarnych, jak i na serwerach. Ponadto oczywiście strona archlinux.org działa na systemie Arch.

Naprawdę lubię Arch Linux, ale zespół programistów powinien wdrożyć funkcję X

Zaangażuj się, przekaż społeczności swój kod lub rozwiązanie. Jeśli Twoje propozycje zostaną dobrze ocenione przez społeczność i zespół programistów, być może zostaną one włączone do systemu. Społeczność Arch rozwija się dzięki udostępnianiu kodu i narzędzi.

Kiedy nowe wydanie zostanie udostępnione?

Arch Linux nie posiada wydań sensu stricto tak jak inne dystrybucje np. Ubuntu czy Fedora. Arch jest tzw. wydaniem ciągłym (rolling release).

Pliki instalacyjne np. w formie obrazu iso, to migawki stanu pakietów na dany moment. Obrazy te tworzone są i dostarczane zwykle w pierwszej połowie każdego miesiąca. Aktualizacje systemu dostarczane są na bieżąco.

Czy Arch Linux jest stabilną dystrybucją? Czy często się psuje?

To użytkownik jest ostatecznie odpowiedzialny za stabilność własnego systemu. To on decyduje, kiedy uaktualnić system i w razie potrzeby wprowadza niezbędne zmiany w oprogramowaniu i konfiguracji. Jeśli użytkownik zwraca się do społeczności o pomoc, często udzielana jest ona odpowiednim czasie. Różnica między Arch Linux i innymi dystrybucjami pod tym względem polega na tym, że Arch jest dystrybucją typu „zrób to sam”. Oznacza to, że wszelkie pretensje co do awarii danego systemu są bezproduktywne i niepotrzebne, gdyż za wszystkie zmiany w konkretnym systemie nie są odpowiedzialni twórcy Arch Linux, a sam użytkownik.

Zobacz artykuł System maintenance, aby uzyskać wskazówki, jak uczynić system Arch Linux tak stabilnym, jak to możliwe.

Arch potrzebuje więcej rozgłosu (tj. reklamy)

Arch Linux już dostaje dużo rozgłosu. Celem Arch Linux nie jest być wszechobecną i potężną dystrybucją. Dla twórców istotny jest zrównoważony wzrost rozpoznawalności systemu wśród docelowej grupy użytkowników.

Arch potrzebuje więcej programistów

Pewnie tak. Zapraszamy do poświęcenia czasu na rozwój dystrybucji! Odwiedź fora, IRC channels lub listy mailingowe i zobacz, co należy zrobić. Zaangażowanie się w forum to dobry początek.

Dlaczego mój internet jest wolniejszy niż na innych systemach operacyjnych/dystrybucjach?

Czy Twoja sieć jest poprawnie skonfigurowana? Przeczytaj artykuł Network configuration.

Zauważ też, że Arch Linux nie ma włączonej usługi kształtowania ruchu sieciowego. Dlatego możliwe jest, że jeśli program w jakiś sposób w pełni wykorzysta przepustowość Twojego połączenia internetowego - niezależnie od tego, czy jest to połączenie P2P lub klasyczne połączenia klient-serwer - inne lokalne połączenia nie uzyskają wymaganej przepustowości, co powoduje poważne opóźnienia i przekroczenia limitu czasu. Spowolnienie mogą powodować także zapory sieciowe, takie jak „Shorewall” lub „Vuurmuur”; istnieją również skrypty statyczne dla iproute2 (takie jak pochodne „Wondershaper”), które umożliwiają modyfikacje sieci.

Dlaczego Arch Linux używa całej mojej pamięci RAM?

Zasadniczo nieużywana pamięć RAM to zmarnowana pamięć RAM.

Wielu nowych użytkowników zauważa, że ​​jądro Linuksa traktuje pamięć inaczej, niż to się działo do tej pory. Ponieważ dostęp do danych z pamięci RAM jest znacznie szybszy niż z dysku twardego, jądro buforuje ostatnio dostępne dane w pamięci. Buforowane dane są usuwane tylko wtedy, gdy w systemie zaczyna brakować dostępnej pamięci i konieczne jest załadowanie nowych danych.

Możemy to sprawdzić za pomocą polecenia free: 

$ free -h
              total        used        free      shared  buff/cache   available
Mem:           2.8G        1.1G        283M        224M        1.4G        1.2G
Swap:          3.0G        881M        2.1G

Należy zauważyć różnicę między pamięcią wolną (free) a dostępną (available). W powyższym przykładzie laptop z 2,8 GB całkowitej pamięci RAM wydaje się zużywać większość z zaledwie 283 MB wolnej pamięci. Jednak 1,4G to pamięć podręczna (buff/cache). Nadal dostępne jest 1,2G do uruchamiania nowych aplikacji. Szczegółowe informacje można znaleźć w man free (1). Co z tego wszystkiego wynika? Wzrost wydajności!

Przeczytaj | ten wspaniały artykuł, jeśli Twoja ciekawość została pobudzona. Istnieje również strona internetowa poświęcona wyjaśnieniu wszystkich tych kwestii: https://www.linuxatemyram.com/.

Gdzie się podziała cała moja wolna przestrzeń dyskowa?

Odpowiedź na to pytanie zależy od Twojego systemu. Istnieje kilka doskonałych narzędzi, które mogą pomóc znaleźć odpowiedź na to pytanie.

Zarządzanie pakietami

Zobacz strony pacman (Polski), pacman/Tips and tricks i Official repositories, aby uzyskać więcej odpowiedzi.

Znalazłem błąd w pakiecie X. Co powinienem zrobić?

Najpierw musisz dowiedzieć się, czy ten błąd jest z kategorii takich, które zespół Arch jest w stanie naprawić. Często tak nie jest (np. awarie Firefoksa mogą być winą zespołu Mozilli). Jeśli jest to problem z Arch Linux, możesz wykonać szereg kroków:

  1. Przeszukaj Google i fora w celu uzyskania informacji. Sprawdź, czy ktoś zauważył to samo co Ty.
  2. Opublikuj raport o błędzie ze szczegółowymi informacjami na https://bugs.archlinux.org.
  3. Jeśli chcesz, możesz napisać post na forum szczegółowo opisujący znaleziony błąd i wskazać, że już go zgłosiłeś. Pomoże to zapobiec zgłaszaniu tego samego błędu przez kilka osób.

Pakiety Arch powinny używać unikalnej konwencji nazewnictwa. Rozszerzenia .pkg.tar.gz i .pkg.tar.xz są za długie lub mylące

Zostało to omówione na liście mailingowej Arch. Niektórzy proponowali rozszerzenie pliku .pac, ale nie planuje się zmiany nazwy rozszerzenia pakietu. Jak ujął to Tobias Kieslich, jeden z programistów Arch: „Pakiet” to „archiwum gzipped” - „[xz]”! I można go otwierać, sprawdzać i modyfikować za pomocą dowolnej aplikacji obsługującej tar. Ponadto większość typów aplikacji automatycznie wykrywa typ MIME.

Pacman potrzebuje biblioteki, aby inne aplikacje mogły łatwo uzyskać dostęp do informacji o pakiecie

Pacman jest nakładką na libalpm[dead link 2021-11-10 ⓘ] - bibliotekę „Arch Linux Package Management” - która umożliwia alternatywne interfejsy, takie jak interfejs GUI.

Pacman potrzebuje funkcji X!

Jeśli uważasz, że Twój pomysł coś wnosi, możesz przedyskutować go na pacman-dev. Sprawdź również https://bugs.archlinux.org/index.php?project=3 pod kątem istniejących propozycji zmian i funkcji.

Jednak najlepszym sposobem na dodanie funkcji do pacman lub Arch Linux jest jej samodzielne wdrożenie. Łatka lub kod może nie zostać oficjalnie zaakceptowany, ale inni mogą go ocenić, przetestować lub udoskonalić.

Właśnie zainstalowałem pakiet X. Jak go uruchomić?

Jeśli używasz środowiska pulpitu takiego jak KDE lub GNOME, program powinien automatycznie pojawić się w menu. Jeśli próbujesz uruchomić program z terminala i nie znasz nazwy binarnej, użyj: 

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

Dlaczego w oficjalnych repozytoriach jest tylko jedna wersja każdej biblioteki współdzielonej?

Niektóre dystrybucje, takie jak np. Debian, mają różne wersje bibliotek współdzielonych spakowanych jako różne pakiety: libfoo1, libfoo2, libfoo3 i tak dalej. W ten sposób można kompilować aplikacje dla różnych wersji libfoo zainstalowanych w tym samym systemie.

W przypadku dystrybucji takiej jak Arch oficjalnie obsługiwane są tylko najnowsze stabilne wersje pakietów. Porzucając obsługę przestarzałego oprogramowania, opiekunowie pakietów mogą spędzić więcej czasu na sprawdzenie, czy najnowsze wersje działają zgodnie z oczekiwaniami. Gdy tylko nowa wersja biblioteki współdzielonej stanie się dostępna, zostanie ona dodana do repozytoriów, a pakiety, których dotyczy problem, zostaną przebudowane tak, aby używać najnowszej wersji.

Co się stanie, jeśli uruchomię pełną aktualizację systemu, a aktualizacja zostanie udostępniona dla biblioteki współużytkowanej, ale nie dla zależnych od niej aplikacji?

Coś takiego nie powinno się wydarzyć. Zakładając, że aplikacja o nazwie foobaz znajduje się w jednym z oficjalnych repozytoriów i z powodzeniem buduje się na nowej wersji biblioteki współdzielonej o nazwie libbaz, zostanie ona zaktualizowana wraz z libbaz. Jeśli jednak nie uda się jej skompilować, pakiet foobaz będzie zależny od wersji (np. Libbaz 1.5) i zostanie usunięty przez pacmana podczas aktualizacji libbaz z powodu konfliktu.

Jeśli foobaz to pakiet, który sam zbudowałeś i zainstalowałeś z AUR, powinieneś spróbować przebudować foobaz na nową wersję libbaz. Jeśli kompilacja się nie powiedzie, zgłoś błąd programistom foobaz.

Czy jest możliwe, że w repozytorium znajduje się poważna aktualizacja jądra i że niektóre pakiety sterowników nie zostały zaktualizowane?

Nie, nie jest to możliwe. Ważnym aktualizacjom jądra (np. „Linux 3.5.0-1” do „linux 3.6.0-1”) zawsze towarzyszą przebudowy wszystkich obsługiwanych pakietów sterowników jądra. Z drugiej strony, jeśli masz zainstalowany nieobsługiwany pakiet sterowników, taki jak z AUR, to aktualizacja jądra może się zepsuć, jeśli nie przebudujesz go dla nowego jądra. Użytkownicy są odpowiedzialni za aktualizację wszelkich nieobsługiwanych pakietów sterowników, które zainstalowali.

Co zrobić przed aktualizacją?

Postępuj zgodnie z sekcją System maintenance#Upgrading the system.

Wydano aktualizację pakietu, ale Pacman mówi, że system jest aktualny

Serwery lustrzane „Pacman” nie są natychmiast synchronizowane. Aktualizacja może potrwać 24 godziny. Jedynymi rozwiązaniami są cierpliwość lub użycie innego serwera lustrzanego. MirrorStatus może pomóc w identyfikacji aktualnego serwera lustrzanego.

Dystrybutor pakietu „X” wydał nową wersję. Jak długo potrwa aktualizacja pakietu Arch do tej nowej wersji?

Aktualizacje pakietów zostaną wydane, gdy będą gotowe. Określony czas może wynieść kilka godzin po wydaniu oficjalnym (upstream) gdy dotyczy niewielkiej aktualizacji błędów lub też nawet kilka tygodni po dużej aktualizacji dużej grupy pakietów. Czas od nowej wersji nadrzędnej do wydania przez Arch nowego pakietu zależy od konkretnych pakietów i dostępności opiekunów pakietów. Ponadto niektóre pakiety spędzają trochę czasu w repozytorium testowym, co może wydłużyć czas do aktualizacji pakietu. Jeśli znajdziesz pakiet w oficjalnych repozytoriach, który jest nieaktualny, przejdź do strony tego pakietu na stronie pakietów i oznacz go.

Jeśli potrzebuję starszej wersji zainstalowanej biblioteki, czy mogę po prostu dowiązać symbolicznie do nowszej wersji?

Jeśli masz szczęście, może to działać przez jakiś czas. Nie jest to jednak właściwe rozwiązanie, ponieważ:

  • Biblioteki nie zmieniają wersji losowo - interfejs API/ABI prawdopodobnie się zmieni (możliwe, że z usuniętymi bitami), a to, czy zmiany te wpływają na użytkowanie biblioteki, jest kwestią przypadku.
  • Menedżer pakietów nie wyśledzi dowiązania symbolicznego. Początkujący, którzy natychmiast próbują włamać się do plików biblioteki systemowej, są najbardziej narażeni na dokonanie niepożądanej zmiany, której nie mogą zdiagnozować/naprawić, przed czym chroni menedżer pakietów.
  • Niewielka alternatywa zrzucenia starego pliku biblioteki do systemu plików, bez śledzenia, zostałaby zapomniana i nie zauważono by/nie usunięto potencjalnych błędów bezpieczeństwa.

Zamiast tego użyj/napisz pakiet compat, który zapewnia wymaganą wersję biblioteki.

Dlaczego w grupie podstawowej istnieją niepotrzebne pakiety (np. netctl)?

Istnieją propozycje poprawy tego stanu rzeczy. Oto dyskusje z listy mailingowej:

https://lists.archlinux.org/pipermail/arch-dev-public/2019-January/029435.html

https://lists.archlinux.org/pipermail/arch-dev-public/2019-February/029452.html

Instalacja

Arch potrzebuje instalatora. Może instalator graficzny (GUI)?

Arch miał kiedyś instalator z tekstowym interfejsem użytkownika o nazwie Arch Installation Framework (AIF). Po opuszczeniu go przez opiekuna pakietu, został on porzucony na rzecz Skryptów instalacyjnych Arch (Arch Install Scripts).

Ponieważ instalacja od zera co do zasady nie zdarza się często (przeczytaj resztę tego artykułu, aby dowiedzieć się więcej o tym, co oznacza „wydanie ciągłe”), instalator graficzny nie jest priorytetem dla programistów ani użytkowników. Instrukcja instalacji została w pełni zaktualizowana w celu wykorzystania wiersza poleceń (konsoli).

Zainstalowałem Arch i mam przed sobą wiersz poleceń! Co teraz?

Zobacz Zalecenia ogólne.

Jakiego środowiska pulpitu lub menedżera okien powinienem użyć?

Ponieważ wiele z nich jest dostępnych, użyj tego, który najbardziej Ci się podoba, w zależności od potrzeb. Zajrzyj do artykułów Desktop environment i Window manager.

Co czyni Arch wyjątkowym spośród innych „minimalnych” dystrybucji?

Zobacz porównanie z innymi dystrybucjami.

64-bit

Jak ustalić, czy mój procesor jest zgodny z architekturą x86_64?

Jeśli twój procesor jest kompatybilny z x86_64, będziesz mieć flagę lm (tryb długi) w /proc/cpuinfo. Na przykład: 

$ grep -w lm /proc/cpuinfo

W systemie Windows skorzystanie z bezpłatnego oprogramowania CPU-Z pomoże ustalić, czy Twój procesor jest kompatybilny z 64-bitami. Procesory z zestawem instrukcji AMD „AMD64” lub rozwiązaniem Intela „EM64T” powinny być kompatybilne z wydaniami x86_64 i pakietami binarnymi.

Dlaczego 64-bity?

W większości przypadków 64-bitowy system operacyjny jest szybszy i dodatkowo z natury bardziej bezpieczny ze względu na swoje właściwości Randomizacja układu przestrzeni adresowej (ASLR) w połączeniu z Kod niezależny od pozycji (PIC) i NX Bit, który nie jest dostępny w standardowym jądrze i686 z powodu wyłączenia PAE. Jeśli Twój komputer ma więcej niż 4 GB pamięci RAM, tylko 64-bitowy system operacyjny będzie mógł go w pełni wykorzystać.

Programiści również coraz mniej dbają o 32-bitowe („starsze”) procesory, ponieważ „nowe” procesory x86 zazwyczaj obsługują rozszerzenia 64-bitowe.

Istnieje wiele innych powodów, które moglibyśmy tutaj wymienić, a które świadczą o wyższości systemów 64-bitowych, ale między jądrem, przestrzenią użytkownika i poszczególnymi programami po prostu nie jest możliwe wyszczególnienie każdej rzeczy, którą 64-bit robi obecnie znacznie lepiej.