Frequently asked questions (한국어)

From ArchWiki

Related articles

일반

아치 리눅스란?

Arch Linux문서를 참조하십시오.

아치 리눅스를 사용하지 않을 이유는 무엇인가요?

다음과 같은 경우 아치 리눅스를 사용하고 싶지 않을 것입니다:

  • '직접' GNU/Linux 판에 할애할 능력/시간/욕구가 없는 경우.
  • x86_64 이외의 아키텍처에 대한 지원이 필요한 경우.
  • GNU에서 정의한 대로 무료 소프트웨어만 제공하는 배포판을 사용하는 것에 대해 강력한 입장을 취하는 경우.
  • 운영 체제가 자체적으로 구성되고, 즉시 실행되며, 설치 미디어에 완전한 기본 소프트웨어 및 데스크톱 환경이 포함되어야 한다고 생각하는 경우.
  • 롤링 릴리스 GNU/Linux 배포를 원하지 않는 경우.
  • 현재 사용 중인 OS에 만족하는 경우.

아치 리눅스를 사용할 이유는 무엇인가요?

왜냐하면 아치가 최고이기 때문입니다.

아치는 어떤 아키텍처를 지원하나요?

아치는 x86_64(amd64라고도 함) 아키텍처만 지원합니다. i686에 대한 지원은 2017년 11월에 중단되었습니다[1].

i686 아키텍처와 [2] ARM CPU [3]를 위한 비공식 포트가 있으며, 각각 자체 커뮤니티 채널이 있습니다.

아치는 리눅스 재단의 파일 시스템 계층 구조 표준(FHS)을 따르나요?

아치 리눅스는 systemd 서비스 관리자를 사용하는 운영체제의 파일 시스템 계층 구조를 따릅니다. 각 디렉터리와 그 명칭에 대한 설명은 file-hierarcy(7)[dead link 2024-10-13]를 참고하세요. 특히 /bin, /sbin 및 /usr/sbin은 /usr/bin에 대한 심볼릭 링크이고, /lib 및 /lib64는 /usr/lib에 대한 심볼릭 링크입니다.

저는 완전한 GNU/Linux 초보자입니다. 아치를 사용해야 하나요?

초보자이고 아치를 사용하려면 새로운 시스템을 배우는 데 시간을 투자할 의향이 있어야 하며, 아치가 '스스로 해야 하는' 배포판으로 설계되었으므로 시스템을 조립하는 것은 사용자라는 점을 받아들여야 합니다.

도움을 요청하기 전에 웹, 포럼 및 아치위키에서 제공하는 훌륭한 문서를 검색하여 스스로 조사해 보세요. 애초에 이러한 리소스가 사용자에게 제공된 이유가 있습니다. 이 훌륭한 정보를 편집하는 데 수천시간이 자발적으로 소요되었습니다.

또한 Arch terminology#RTFM 및 설치 가이드를 참조하세요.

Arch는 서버로 사용하도록 설계되었나요? 혹은 데스크톱? 워크스테이션?

아치는 특정 유형의 사용을 위해 설계되지 않았습니다. 오히려 특정 유형의 '사용자'를 위해 설계되었습니다. 아치는 '스스로 해야 한다는' 특성을 즐기고, 나아가 이를 활용하여 자신의 고유한 요구에 맞게 시스템을 구성하는 유능한 사용자를 대상으로 합니다. 따라서 목표 사용자층의 손에 쥐어진 아치는 거의 모든 용도로 사용할 수 있습니다. 많은 사람들이 데스크톱과 워크스테이션 모두에서 Arch를 사용합니다. 물론 archlinux.org, aur.archlinux.org 및 거의 모든 아치의 인프라는 Arch에서 실행됩니다.

저는 아치 리눅스를 정말 좋아합나다. 개발팀이 어떤 기능을 구현해야 한다는 점만 빼면요

참여하고, 코드/솔루션을 커뮤니티에 기여하세요. 커뮤니티와 개발팀으로부터 좋은 평가를 받으면 통합될 수도 있습니다. 아치 커뮤니티는 코드와 도구의 기여와 공유를 통해 번창합니다.

새 릴리즈는 언제 제공되나요?

아치 리눅스 릴리스는 단순히 설치 또는 복구를 위한 라이브 환경이며, 여기에는 base 메타 패키지 및 몇 가지 기타 패키지를 포함합니다. 릴리스는 보통 매달 상반기에 배포됩니다.

아치 리눅스는 안정적인 배포판인가요? 잦은 고장이 발생하나요?

자체 롤링 릴리스 시스템의 안정성에 대한 궁극적인 책임은 '사용자'에게 있습니다. 사용자는 업그레이드 시기를 결정하고 필요한 경우 필요한 변경 사항을 병합합니다. 사용자가 커뮤니티에 연락하면 적시에 도움이 제공되는 경우가 많습니다. 이 점에서 아치와 다른 배포판의 차이점은 아치는 진정한 '스스로 하는' 배포판이며, 업스트림 변경은 아치 개발자의 책임이 아니기 때문에 고장에 대한 불만은 잘못된 것이며 비생산적입니다.

아치 리눅스 시스템을 최대한 안정적으로 만드는 방법에 대한 팁은 시스템 유지 관리 문서를 참조하세요.

아치는 더 많은 언론(즉, 광고)이 필요합니다

아치는 많은 언론을 그대로 받습니다. 아치 리눅스의 목표는 규모가 커지는 것이 아니라, 목표 사용자층 사이에서 유기적이고 지속 가능한 성장이 자연스럽게 이루어지도록 하는 것입니다.

Arch에는 더 많은 개발자가 필요합니다

그럴 수도 있죠. 언제든지 자원봉사에 참여해 주세요! https://bbs.archlinux.org 포럼]], IRC 채널, [메일링 리스트를 방문해서 어떤 일이 필요한지 알아보세요. 자세한 내용은 참여하기를 참조하세요.

설치

아치에는 설치 프로그램이 필요합니다. GUI 인스톨러는 어떨까요?

아치에는 아치 설치 프레임워크(AIF)라는 텍스트 기반 사용자 인터페이스가 있는 설치 프로그램이 있었습니다. 마지막 관리자가 떠난 이후 사용하지 않게 되었으며, 대신 arch-install-scripts를 사용하게 되었습니다.

https://archlinux.org/news/installation-medium-with-installer/ 2021-04-01] 이후, 아치에는 다시 설치 프로그램이 있습니다. 자세한 내용은 archinstall을 참조하십시오.

아치를 설치했고, 이제 셸에 있습니다! 이제 어떻게 해야 하나요?

General recommendations를 확인하십시오.

어떤 데스크톱 환경 또는 윈도우 관리자를 사용해야 하나요?

여러 가지가 있으므로 필요에 가장 적합한 것을 사용하세요. 데스크톱 환경 및 윈도우 관리자 문서를 참고하세요.

다른 "미니멀" 배포판과 아치가 다른 점은 무엇인가요?

다른 배포판과 비교한 아치 문서를 참고하세요.

시스템 유지보수

시스템 유지보수 문서를 확인하세요.

다른 운영 체제에 비해 인터넷 속도가 느린 이유는 무엇인가요?

네트워크가 올바르게 구성되어 있나요? 네트워크 구성 문서를 살펴보세요.

또한 아치 리눅스는 트래픽 쉐이핑이 활성화되어 있지 않다는 점에 유의하세요. 따라서, 어떤 프로그램이 P2P 연결이든 전통적인 클라이언트-서버 연결이든 상관없이 인터넷 연결을 최대한 활용하면 다른 로컬 연결이 막혀서 심각한 지연과 시간 초과가 발생할 수 있습니다. Shorewall 또는 Vuurmuur와 같은 방화벽으로 완화할 수 있으며, iproute2에 대한 정적 스크립트도 있습니다. (예: 이 파생의 Wondershaper와 같은) 네트워크 계층에서 셰이핑을 허용하는 정적 스크립트도 있습니다.

아치가 내 RAM을 모두 사용하는 이유는 무엇인가요?

기본적으로 사용하지 않는 RAM은 낭비되는 RAM입니다.

많은 신규 사용자들은 리눅스 커널이 기존과 다르게 메모리를 처리한다는 사실을 알게 됩니다. RAM에서 데이터에 액세스하는 것이 스토리지 드라이브에서 액세스하는 것보다 훨씬 빠르기 때문에 커널은 최근에 액세스한 데이터를 메모리에 캐시합니다. 캐시된 데이터는 시스템의 사용 가능한 메모리가 부족해져 새 데이터를 로드해야 할 때만 지워집니다.

이 차이점을 free 명령을 통해 구별할 수 있습니다: 

$ 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

"비어있는" 메모리와 "사용 가능한" 메모리의 차이점을 알아두는 것이 중요합니다. 위의 예에서 총 RAM 용량이 2.8기가바이트인 노트북은 283메비바이트만 여유 메모리로 남기고 대부분을 사용하고 있는 것처럼 보입니다. 그러나 이 중 1.4기가바이트는 "버퍼/캐시"입니다. 스왑하지 않고 새 애플리케이션을 시작하는 데 사용할 수 있는 1.2기가바이트는 여전히 남아 있습니다. 자세한 내용은 free(1)를 참조하세요. 이 모든 것의 결과는? 성능 향상입니다!

궁금한 점이 있으시다면 이 멋진 글을 참조하세요. 이러한 혼란을 해소하기 위한 웹사이트도 있습니다(https://www.linuxatemyram.com/).

여유 공간이 모두 어디로 갔나요?

이 질문에 대한 답은 사용 중인 시스템에 따라 다릅니다. 답을 찾는 데 도움이 될 수 있는 유용한 도구가 몇 가지 있습니다.

패키지 관리

pacman, pacman/Tips and tricks 와 Official repositories 페이지를 확인하세요.

어떤 패키지에서 오류를 발견했습니다. 어떻게 해야 하나요?

먼저 이 오류가 아치 팀에서 수정할 수 있는 오류인지 파악해야 합니다. 때로는 그렇지 않은 경우도 있는데(예: Firefox 충돌은 Mozilla 팀의 잘못일 수 있음), 이를 '업스트림 오류'라고 합니다. 아치 문제인 경우 취할 수 있는 일련의 단계가 있습니다:

  1. 포럼에서 정보를 검색합니다. 다른 사람이 이 문제를 발견했는지 확인합니다.
  2. 자세한 정보와 함께 버그 리포트를 Gitlab의 아치 리눅스 버그 트래커에 게시하세요.
  3. 원하는 경우 문제와 이미 신고했다는 사실을 자세히 설명하는 포럼 게시물을 작성하세요. 이렇게 하면 많은 사람들이 동일한 오류를 보고하는 것을 방지하는 데 도움이 됩니다.

아치 패키지는 고유한 명명 규칙을 사용해야 합니다. ".pkg.tar.zst"는 너무 길고 혼란스러울 수 있습니다.

이 문제는 아치 메일링 리스트에서 논의되었습니다. 일부는 .pac 파일 확장자를 제안했지만 패키지 확장자를 변경할 계획은 없습니다. 아치 개발자 중 한 명인 토비아스 키슬리히(Tobias Kieslich)는 "패키지는 [압축된] tarball입니다! 그리고 모든 tar 지원 애플리케이션에서 열고, 조사하고, 조작할 수 있습니다. 게다가 대부분의 애플리케이션에서 mime 유형이 자동으로 올바르게 감지됩니다."

다른 애플리케이션이 패키지 정보에 쉽게 접근할 수 있도록 팩맨에는 라이브러리가 필요합니다

팩맨은 "아치 리눅스 패키지 관리" 라이브러리인 libalpm(3)의 프론트엔드로, GUI 프론트엔드와 같은 대체 프론트엔드를 작성할 수 있게 해줍니다.

pacman에 어떤 기능이 필요합니다!

아이디어가 가치가 있다고 생각되면 pacman-dev에서 논의할 수 있습니다. 또한 https://gitlab.archlinux.org/pacman/pacman/-/issues 에서 기존 기능 요청을 확인해보세요.

그러나 pacman이나 아치 리눅스에 기능을 추가하는 가장 좋은 방법은 직접 구현하는 것입니다. 패치나 코드가 공식적으로 받아들여질 수도 있고 그렇지 않을 수도 있지만, 다른 사람들이 여러분의 노력을 높이 평가하고 테스트하며 기여할 수도 있습니다.

방금 패키지 X를 설치했는데 어떻게 시작하나요?

KDE 또는 GNOME과 같은 데스크톱 환경을 사용하는 경우, 프로그램이 자동으로 메뉴에 표시됩니다. 터미널에서 프로그램을 실행하려고 하는데 바이너리 이름을 모른다면 다음을 사용하세요: 

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

공식 리포지토리에 각 공유 라이브러리의 버전이 하나만 있는 이유는 무엇인가요?

데비안과 같은 여러 배포판에는 서로 다른 버전의 공유 라이브러리가 서로 다른 패키지로 패키징되어 있습니다: libfoo1, libfoo2, libfoo3 등입니다. 이러한 방식으로 동일한 시스템에 설치된 libfoo의 다른 버전에 대해 컴파일된 애플리케이션을 사용할 수 있습니다.

아치와 같은 배포판의 경우 최신 패키지 버전만 공식적으로 지원됩니다. 오래된 소프트웨어에 대한 지원을 중단함으로써 패키지 관리자는 최신 버전이 예상대로 작동하는지 확인하는 데 더 많은 시간을 할애할 수 있습니다. 업스트림에서 공유 라이브러리의 새 버전을 사용할 수 있게 되면 바로 리포지토리에 추가되고 영향을 받는 패키지는 새 버전을 사용하도록 다시 빌드됩니다.

전체 시스템 업그레이드를 실행했는데 공유 라이브러리에 대한 업데이트는 있지만 이에 의존하는 애플리케이션에 대한 업데이트는 없는 경우 어떻게 해야 하나요?

이 시나리오는 절대 발생하지 않아야 합니다. 공식 리포지토리 중 하나에 foobaz라는 애플리케이션이 있고 libbaz라는 공유 라이브러리의 새 버전에 대해 성공적으로 빌드된다고 가정하면 libbaz와 함께 업데이트됩니다. 그러나 성공적으로 빌드되지 않으면 foobaz 패키지는 버전 종속성(예: libbaz 1.5)을 가지며, 충돌로 인해 libbaz 업그레이드 중에 pacman에 의해 제거됩니다.

만약 foobaz가 직접 빌드하여 AUR에서 설치한 패키지라면, foobaz를 새 버전의 libbaz에 맞게 다시 빌드해야 합니다. 빌드에 실패하면 foobaz 개발자에게 버그를 보고하세요.

리포지토리에 주요 커널 업데이트가 있는데 일부 드라이버 패키지가 업데이트되지 않았을 가능성이 있나요?

아니요, 불가능합니다. 주요 커널 업데이트(예: Linux 3.5.0-1'에서 Linux 3.6.0-1로)에는 항상 지원되는 모든 커널 드라이버 패키지의 재빌드가 수반됩니다. 반면에 시스템에 지원되지 않는 드라이버 패키지(예: AUR)가 설치되어 있는 경우 새 커널에 맞게 다시 빌드하지 않으면 커널 업데이트로 인해 문제가 발생할 수 있습니다. 사용자는 자신이 설치한 지원되지 않는 드라이버 패키지를 업데이트할 책임이 있습니다.

업그레이드 하기 전에 무엇을 해야 하나요?

System maintenance#Upgrading the system 항목을 따르십시오.

패키지 업데이트가 릴리스되었지만 pacman이 시스템이 최신 상태라고 말합니다

pacman의 미러는 즉시 동기화되지 않습니다. 업데이트를 사용할 수 있으려면 24시간 이상 걸릴 수 있습니다. 인내심을 갖고 기다리거나 다른 미러를 사용하는 방법밖에 없습니다. MirrorStatus에서 최신 미러를 확인할 수 있습니다.

업스트림 프로젝트에서 새 버전을 출시했습니다. 아치 패키지가 새 버전으로 업데이트되는 데 얼마나 걸리나요?

패키지 업데이트는 준비가 되면 릴리스됩니다. 구체적인 시간은 업스트림에서 사소한 버그 수정 업데이트를 릴리스한 후 몇 시간에서 대규모 패키지 그룹의 주요 업데이트 후 몇 주까지 걸릴 수 있습니다. 업스트림의 새 버전이 릴리스된 후 아치에서 새 패키지를 릴리스하는 데 걸리는 시간은 특정 패키지와 패키지 관리자의 가용성에 따라 달라집니다. 또한 일부 패키지는 테스트 저장소에서 일정 시간을 보내므로 패키지가 업데이트되기까지 시간이 길어질 수 있습니다. 패키지 관리자는 저장소에 안정적인 업데이트를 제공하기 위해 빠르게 작업하려고 노력합니다. 공식 리포지토리에서 오래된 패키지를 발견하면 패키지 웹사이트에서 해당 패키지의 페이지로 이동하여 플래그를 지정하세요.

설치된 라이브러리의 이전 버전이 필요한 경우 최신 버전으로 심볼릭 링크할 수 있나요?

운이 좋다면 한동안은 효과가 있을 수 있습니다. 그러나 이는 적절한 해결책이 아닙니다:

  • 라이브러리는 무작위로 버전을 변경하지 않습니다. API/ABI는 변경되었을 가능성이 높으며(비트가 제거되었을 수도 있음), 이러한 변경 사항이 사용량에 영향을 미치는지 여부는 운의 문제일 뿐입니다.
  • 심볼 링크는 패키지 관리자에 의해 추적되지 않습니다. 시스템 라이브러리 파일을 바로 해킹하려는 초보자는 진단/수정할 수 없는 원치 않는 변경을 할 위험이 가장 크며, 패키지 관리자는 이를 방지하는 데 도움을 줍니다.
  • 이전 라이브러리 파일을 추적하지 않고 파일 시스템에 덤프하는 약간의 대안은 잊혀지고 잠재적인 보안 버그를 발견/패치할 수 없습니다.

대신 필요한 라이브러리 버전을 제공하는 compat 패키지를 사용/작성하세요.

64비트

내 프로세서가 x86_64와 호환되는지 어떻게 확인하나요?

프로세서가 x86_64와 호환되는 경우 lm (Long mode) 플래그가 /proc/cpuinfo에 표시됩니다. 다음은 명령어 예시입니다. 

$ grep -w lm /proc/cpuinfo

Windows에서는 프리웨어 CPU-Z를 사용하면 사용 중인 CPU가 64비트와 호환되는지 확인할 수 있습니다. AMD의 명령어 세트 "AMD64" 또는 Intel의 솔루션 "EM64T"를 사용하는 CPU는 x86_64 릴리스 및 바이너리 패키지와 호환되어야 합니다.

왜 64비트인가요?

대부분의 상황에서 더 빠르며, 주소 공간 레이아웃 무작위화(ASLR)의 특성상 위치 독립 코드(PIC) 및 NX 비트와 함께 물리적 주소 확장(PAE)을 비활성화하여 기본 i686 커널에서 사용할 수 없기 때문에 본질적으로 보안이 더 뛰어납니다. 컴퓨터에 4기가바이트 이상의 RAM이 있는 경우 64비트 OS만 이를 완전히 활용할 수 있습니다.

또한 "새로운" x86 CPU가 일반적으로 64비트 확장을 지원하기 때문에 프로그래머들은 점점 더 32비트("레거시")를 덜 신경 쓰는 경향이 있습니다.

32비트를 피해야 하는 이유는 더 많지만 커널, 사용자 공간, 개별 프로그램 등 요즘에는 64비트가 훨씬 더 나은 모든 것을 일일이 나열하는 것은 불가능합니다.