아치 리눅스

{{{#!html <div style="margin-left:50px;"><b style="font-size:14px">

이 문서는 <a href="/w/나무위키 운영 체제 프로젝트">나무위키 운영 체제 프로젝트</a>에서 다루는 문서입니다. </b><br /> 해당 프로젝트 문서를 방문하여 도움이 필요한 문서에 기여하여

주세요!</div>}}}

운영 체제

{{{#!folding [ 펼치기 · 접기 ]

Windows

Microsoft Windows(Windows 9x, Windows NT)

리눅스

데비안

데비안 · 우분투 · 리눅스 민트 · 칼리 리눅스 · 크런치뱅
하모니카 · 구름 OS · 기린 · Damn Small Linux · elementary OS · 스팀 OS · 라즈비안 · Slax · TmaxOS

레드햇

레드햇 엔터프라이즈 리눅스 · 페도라 · MeeGo · 붉은별 · CentOS · 아시아눅스
타이젠 · Open Mandriva Lx · 마제야 · PCLinuxOS

슬랙웨어

슬랙웨어 리눅스 · openSUSE

아치

아치 리눅스 · Manjaro Linux · Antergos · ArchBang Linux · Chakra Linux

안드로이드

안드로이드 · Remix OS · Polaris OS · Phoenix OS

젠투

젠투 리눅스 · 펀투 리눅스

기타

OpenWRT · 크롬 OS · Endless OS

[[유닉스|{{{#white 유닉스}}}]]

BSD

BSD · FreeBSD · NetBSD · OpenBSD · TrueOS · GhostBSD · DragonFly BSD

XNU

Darwin · iOS · macOS · tvOS · watchOS

System V

솔라리스(SmartOS) · IBM AIX

DOS

DR-DOS · MS-DOS · FreeDOS · K-DOS

기타

실시간 운영체제 · ReactOS · BeOS · 하이쿠 · Mac OS · OS/2(eCS, ArcaOS) · Redox

}}}||

1. 개요
2. 특징
2.1. 빠른 업데이트 속도
2.2. 나만의 OS
2.3. ArchWiki
3. 패키지 관리 시스템
3.1. 팩맨
3.2. ABS
3.3. AUR
3.4. 업데이트 속도
4. 아치 기반의 배포판
4.1. ArchBang
4.2. Arch Linux ARM
4.5. -Netrunner-
4.6. 기타
5. 외부 링크

1. 개요

홈페이지

위키

리눅스 배포판 가운데 하나. 주드 비넷(Judd Vinet)이라는 사람이 미니멀리즘으로 유명한 CRUX라는 배포판으로부터 영감을 받아 만들었다. 그러나 어느 시점에서 바쁘다는 이유로 아론 그리핀(Aaron Griffin)에게 관리를 대신 지휘하라고 하고 자신은 손을 뗐다. 그래서 현재 이 배포판의 관리는 아론 그리핀이 지휘하고 있다.

특징으로는 빠른 패키지 업데이트, 미니멀한 설계 등이 있다. 패키지 관리자로는 팩맨을 사용한다.

2. 특징

처음 시작할 때 CUI를 띄우는 것부터 시작해서 손수 세팅할 것을 요구하는 배포판인데도 나름대로 인기 있는[1] 이유가 있다.

2.1. 빠른 업데이트 속도

Open Source Watershed라는 곳에서 조사한 바에 의하면 유명[2] 리눅스 배포판 중에서는 소프트웨어 업데이트 속도가 가장 빠르다. 직접 소스코드를 다운받아 컴파일하는 방식의 젠투보다도 빠르다![3] 리눅스 커널 메이저 업데이트 등 함부로 업데이트하기에는 매우 위험한 경우가 아니면 대부분의 소프트웨어가 릴리즈되고 나서 늦어도 며칠 안에 업데이트된다. 업데이트 속도를 위하여 광범위하게 쓰이는 레거시 버전들을 과감히 버리는 것도 특징.

몇 가지 예를 들자면

  • 용량이 거대하고 업데이트 속도도 빨라서 웬만한 거대 배포판들에서도 지원하지 않는 texlive, sage[4] 같은 프로그램들을 공식 지원.
  • Haskell이라는 프로그래밍 언어는 일반적으로 haskell-platform 패키지에서 필요한 것들을 모두 모아서 제공하고, 대부분의 배포판들이 이것을 가져다 사용할 정도로 표준적인 패키지이지만, 아치 리눅스에서는 haskell-platform에서 제공하는 각 구성물들의 버전이 낮고, 해당 구성물의 업데이트를 하게 되면 의존이 만족되지 않는다며 결국 haskell-platform을 저장소에서 없애고 각 구성물들을 따로 제공하는 방식을 택했다.
  • KDE의 경우 최신 메이저 버전이 본가보다 먼저 업로드되기도 했다.

아치 리눅스에서는 이런 업데이트 속도를 유지하기 위해 롤링 릴리즈(rolling release) 방식을 사용한다. 일반적인 배포판에서 메이저 버전이 존재하고, 메이저 버전이 올라갈 때마다 메이저 업그레이드를 해 줘야 최신 버전으로 유지되는 반면, 아치는 설치만 해 두면 얼마든지 새로운 버전의 프로그램을 받아서 설치할 수 있는 것. 주기적으로 마이너 업데이트만 하다 보면 대부분의 소프트웨어들을 항상 최신 버전으로 유지할 수 있다. pacman -Syu 최신 버전의 소프트웨어 릴리즈 때 배포판 업데이트를 기다리기보다, 먼저 스스로 업데이트하던 사용자라면 아치 리눅스가 입맛에 맞을 가능성이 높다.

2.2. 나만의 OS

또 다른 중요한 하나의 특징은 처음 설치를 할 때 기본적인 틀만 짜인 상태에서 유저가 알아서 자신만의 OS를 만들어간다는 점.

다른 메이저 리눅스 배포판들의 경우, 리눅스를 처음 접하는 유저가 사용하기는 편리하지만, 그것을 위해 디폴트로 온갖 셸스크립트와 데몬으로 중무장시켜놔서리 시스템 세팅을 직접 하려는 유저들에게는 상당히 큰 짜증을 불러일으키는 경우가 많다. 아치 리눅스는 이런 사용자들을 위한 배포판이다.

설치부터 쓸만한 하나의 운영체제가 될 때까지 만들어가는 게 오래 걸리긴 하지만 운영체제의 구석구석을 돌아다니면서 배울 수 있는 것도 많고, 웬만한 설정 파일은 유저의 손을 한 번씩 거치므로 뭔가가 꼬였을 때 풀어나갈 수 있는 안목도 기르게 된다. 나만의 운영체제를 완성해 나간다는 성취감과 완성된 시스템에 대한 애착은 덤.

그러면서도 이러한 종류의 배포판들이 주로 사용하는, 엄청난 시간을 잡아먹는 소스 컴파일 프로그램 인스톨 방식이 아닌 바이너리 인스톨 방식을 디폴트로 사용하여, 세팅과 프로그램 인스톨이 매우 편하면서도 파워유저들의 깐깐한 요구 사항들을 대부분 충족시켜준다. 다른 옵션을 주고 컴파일하고 싶거나 좀 더 극한의 최적화를 원하는 사람들을 위해서는 ABS라는 수단을 통해 소스 컴파일식으로 설치할 수 있는 방법도 만들어뒀다.

2.3. ArchWiki

OS 하나를 바닥부터 짠다니 마냥 불편하고 어려울 것 같지만 아치 위키의 강력한 도움을 받는다면 생각보다 어렵지는 않다. Installation Guide부터 시작해서 General recommendation까지 끝내고 나면 어느새 쓸만한 프로그램은 다 깔려 있게 된다.

아치 리눅스의 위키 페이지는 항목 수도 매우 많고 업데이트도 아치 리눅스답게 매우 빠르며, man page같이 딱딱하면서 형식적이지도 않아, 유저들의 가려운 부분을 족집게처럼 찔러서 긁어준다. 물론 만능은 아니다

특정 프로그램에 대해서 세팅을 하고 싶다면 해당 위키 페이지[5]를 뒤져보면 설치법부터 시작해서 자주 쓰는 설정, 웬만큼 세세한 설정법에다가 뭔가 잘 안될 때의 대처법까지 친절하게 설명되어 있다. 다른 리눅스를 쓰더라도 버전에 따른 차이만 조금 확인해주면 트윅을 위해서 참고하기에도 좋을 정도.

3. 패키지 관리 시스템

패키지 관리 시스템은 일반적으로 유명한 데비안 계열로 치자면 APT를 닮은[6] 팩맨(pacman)이 있다.[7]

3.1. 팩맨

뿅뿅거리며 주황색 점을 집어먹고 귀신을 퇴치한다

팩맨(pacman)[8]은 아치 리눅스의 패키지 관리자이다. 아치 리눅스의 특징을 빼닮아서 공식 GUI 패키지 관리자가 없다. 이런저런 옵션을 사용한다면 다른 배포판의 패키지 관리자에도 꿇리지 않지만 그거 다 외우기는 힘들단 게 문제(...) 게다가 다른 패키지 관리자도 CUI를 웬만큼은 지원하기 때문에 큰 특징이라고 말하기는 힘들다. GUI 형태로 패키지를 관리할 수 있도록 도와주는 프로그램도 있지만 공식 GUI 프로그램은 없기 때문에 약간은 불편한 게 사실. 그래서 아치리눅스 유저라면 pacman 명령어는 손에 익어 있을 정도(...)

진짜 pacman만의 특징이라면 역시나 아치 리눅스의 패키지 관리자답게 설정 파일을 섬세하게 다뤄 준다는 것. 패키지를 설치/삭제/업데이트 하는 과정에서 사용자가 손댄 흔적이 있는 설정 파일이 수정될 경우 절대로 알아서 만져주지 않고 pacorig/pacsave/pacnew 파일을 통해 사용자가 알아서 수정하도록 한다. 예를 들어 패키지를 업데이트하는 중 어떤 설정 파일을 수정해야 하는데 기존 패키지의 내용물과도 다르고 새 패키지의 내용물과도 다를 경우 경고문 하나 띄워 주고 .pacnew를 붙인 파일을 생성해 주는 식.

어찌 보면 불친절한 것 같지만 웬만한 배포판에서 메이저 업데이트로 전체 프로그램들이 죄다 새 버전으로 업데이트될 경우 설정파일이 죄다 엉망이 되는 걸 생각해 보자. 설정 파일 하나하나가 사용자의 고심이 들어간 결과물인 아치리눅스의 특성상 함부로 손댈 수도 없는 일이기도 하다.

여담이지만, 팩맨의 설정 중에는 진행 표시줄을 팩맨 캐릭터[9]가 오른쪽으로 움직이면서 점을 잡아먹는 모양으로 바꿔주는 것도 있다(...)[10]

3.2. ABS

ABS는 FreeBSD의 Ports와 비슷하게, 디렉터리 구조로 이루어진 각 패키지의 메타데이터(의존, 소스 주소, 빌드 스크립트 등)를 싱크한 후, 해당 디렉터리로 들어가서 makepkg 명령으로 빌드하여 그것을 pacman으로 인스톨하는 방식이다.

pacman으로 인스톨하는 과정만 빼면 FreeBSD와 동일한 것 같지만, 차이점을 살펴보자면 첫째로 FreeBSD처럼 재귀적으로 의존을 찾아 컴파일해준다거나 컴파일 옵션을 인스톨 도중 인터랙티브하게 선택이 가능하거나 한 구조는 아니고 보다 원시적으로 해당 디렉터리의 PKGBUILD 파일을 직접 에디트하여 인스톨하는 방식이라는 것과, 둘째로 필요한 의존패키지까지 찾아서 컴파일하는 방식이 아니고 그러한 의존은 pacman으로 바이너리 인스톨 한 후 해당 패키지 자체만 컴파일하는 방식이라는 정도가 있다.

애초에 소스 컴파일방식의 인스톨이 메인이 되는 FreeBSD와 달리, 바이너리 인스톨이 메인인 아치 리눅스인지라, ABS는 사실 원하는 유저에게 원하는 패키지만 소스컴파일 인스톨을 지원하는 일종의 옵션서비스에 더 가깝다.

2017년에 Deprecated가 되어서, 더 이상은 쓰이지 않는다.

3.3. AUR

AUR은 pacman이나 ABS와는 달리 아치리눅스 측에서 공식적으로 관리되는 패키지들이 아닌, 유저들이 직접 패키징하여 올리는 패키지 모음이다. 기본적으로 pacman과 같은 바이너리 다운로드 방식이 아닌 ABS식의 소스 컴파일 방식을 이용한다.

우분투 등 거대 배포판들에 비해 pacman이나 ABS에서 제공하는 패키지의 수가 많이 적기 때문에 pacman 저장소에 없는 다양한 것들을 제공해주는 AUR은 반드시 필요한 것 중 하나라고 볼 수 있다. AUR까지 포함하면 온갖 트윅과 패치는 물론이고, 웬만한 메이저 배포판들을 압도하는 수준의 패키지 양을 자랑한다. 예를 들어 한글 폰트 같은 경우, pacman은 한때 백묵 폰트 밖에 가지고 있지 않았지만, 대세로 쓰이는 은글꼴나눔고딕 등 미려한 폰트는 AUR을 통해 다운받을 수 있었던 식이다.[11]

그러나, 패키지를 관리하는 사람에 따라 제때 업데이트를 올려주지 않기도 하고 패키지가 꼬이는 경우도 생기는 등 100% 문제없이 잘 돌아간다고 확신하기도 힘들고, 업데이트도 제대로 안 되는 경우가 꽤 있다. 그냥 유저가 git이나 cvs 등의 버전컨트롤 소프트웨어를 이용하여 직접 인스톨하는 게 나은 경우도 종종 있다.(...) 패키지를 설치하기 전 out-of-date로 신고되지는 않았는지, 의견란에 다른 프로그램과의 충돌 등의 문제가 제기되어 있지는 않은지 먼저 확인하는 편이 좋다.

AUR에 투표를 해 주면 표가 많은 패키지는 주기적으로 공식 저장소에 등록되니 마음에 드는 패키지에는 열심히 투표해 주자.

AUR의 패키지를 설치할 때 번거로운 과정을 생략하기 위해 Argon 같은 관리 패키지도 있다. #

3.4. 업데이트 속도

빠른 업데이트는 좋기도 하지만, 테스트 기간이 그만큼 짧다고 볼 수 있고, 때문에 이리저리 꼬일 가능성도 배제하지 못하기 때문에 불안할 수 있다. 특히 본격적인 프로덕션 레벨의 머신이라면 아치 리눅스 사용을 신중히 따져 보는 것이 좋다. 이 경우 업데이트된 소프트웨어가 완전히 ok 사인이 나오기 전까지는 레거시 버전을 사용하는 것이 일반적이라 버전업 속도가 빠른 것이 오히려 불편할 수 있기 때문이다. 실제로 프로덕션 레벨에서 많이 이용되는 레드햇 엔터프라이즈 리눅스나 이를 본떠 배포하는 CentOS의 경우, 최신 버전이라도 다른 배포판과 비교하면 어이가 없을 정도로 뒤쳐지는 것들이 많다.

하지만, 데스크톱의 경우 실제 그런 문제가 발생하는 빈도는 사실 상당히 낮으며, 발생하더라도 롤링 릴리즈 배포판답게 매우 빨리 해결된다. 이런 업스트림 소스에 존재하는 버그를 해결하는 제일 빠른 방법은 바로 빠른 업데이트이기 때문. 마치 반달이 일어났을 때 빠르게 수정하는 위키니트같이(...).[12] 따라서 어떻게 보면 오픈소스 특성상 빠른 업데이트가 더 안정적이라 볼 수도 있다.

테스팅 기간이 길다고 만사는 아니다. 소수 열정적인 프로그래머들의 자투리 시간에 만들어지는 경우가 많은 오픈소스 소프트웨어 특성상, 돈으로 밀어붙이는 상용 소프트웨어보다 버그가 있을 가능성이 높다. 배포판에서 아무리 테스팅 기간을 길게 잡고 엄밀하게 테스트한다 해도, 그건 그저 프로그램이 돌아가는 데 있어 배포판 자체적인 문제가 있는가의 테스트 정도일 뿐, 업스트림 소스에 존재하는 그런 버그를 직접 고치는 경우는 거의 없다. 많이 해 준다 해도 원저자에게 버그 리포팅만 해주는 게 대부분. 어차피 실사용자들이 상용 소프트웨어처럼 안정적이고 부드럽게 돌아간다고 느끼기는 힘들다.

리눅스 민트 등 버전업 사이클이 정해진 배포판에서는 일반적으로 해당 버전을 내기 전에 보다 엄밀하게 테스트하지만, 일단 내놓은 뒤에는 버그가 발견되더라도 공식 수정은 긴급한 보안 패치가 아닌 한 다음 버전업 사이클이나 되어야 만나볼 수 있다. 때문에 자주 사용하는 패키지들은 엄밀한 테스트로 매우 안정적이지만, 그렇지 못한 패키지는 안습.[13]

이런 식으로 배포판과의 충돌이 아닌 프로그램 자체의 특정 버그로 골머리를 썩다 버그 픽스된 버전이 나온 경우, 배포판에서 업데이트되기를 그저 기다리거나, 수동으로 직접 설치하고 관리해야 하는데, 어느 쪽이나 매우 짜증 난다(게다가 괜히 설치했다가 설정 파일 같은 게 꼬여서 유실되기라도 하면...). 상당수의 소프트웨어들이 업스트림 소스가 업데이트되고 나서 며칠 안 되어 저장소에 업데이트되는 아치 리눅스의 경우 이런 면에서 상당히 자유롭고 편리하다 볼 수 있다.

빠른 업데이트로 이득을 보는 또 한 가지 경우는 아직 대세가 되지 못한 프로그램을 실험해 보기 좋다는 것이다. 새로운 프로그램일수록 새 시스템에 맞게 만들어져 있고, 또 단순한 프론트 엔드가 아닌 이상 그 프로그램을 받쳐 주는 다른 프로그램이 있어야 설치해서 효과를 보는데 프로그램 자체를 컴파일하는 것도 모자라 이런 환경을 갖춰 주는 것도 쉬운 일이 아니다. 가장 대표적인 예는 리눅스 그래픽계의 표준인 X.org[14]를 대체할 것으로 기대되는 Wayland. KDE나 GNOME 등 대형 DE도 시스템상 큰 비중을 차지하므로 다른 배포판에선 쉽게 건드릴 수 없는 부분이라, 메이저 업데이트가 이루어질 경우 대개 아치 리눅스가 1순위로 혜택을 보게 된다.

원작자의 관심 부족으로 업데이트 속도의 초점이 유명 배포판 한둘 정도에만 맞춰져 있는 경우도 있다. 오히려 이 경우는 빠른 업데이트가 어울리지 않는 경우. 라이선스 업데이트를 하지 않고 구버전을 지속적으로 사용해야 하는 그놈의 라이센싱... 애플리케이션(예를 들어 Cadence의 OrCAD 프로그램들이나 Silvaco의 TCAD 프로그램들)이나 업데이트가 더 이상 제공되지 않는 프로그램들의 경우, 도리어 구버전의 OS를 사용해야 정상 작동을 보장하는 경우도 있다. 참고로 이 프로그램들의 인터페이스는 90년대 GUI 수준이다... 이런 프로그램을 억지로 쓰고자 한다면 일반적인 배포판 버전으로도 커버가 안 되고 옛날 OS까지 꺼내야 하는 경우가 많은데, 이 경우 구식 시스템이 보안상 문제를 일으킬 수 있기 때문에 아예 인터넷 연결 없이 작동시킬 게 아니라면 대체 프로그램을 찾는 것이 낫다.

4. 아치 기반의 배포판

참고로 아치리눅스 측에서는 주제의 통일성을 위해 아치 이외의 배포판 관련 내용을 위키나 포럼에 올리는 것을 금하고 있다. 아래의 '아치 기반 배포판'들도 마찬가지이니 실수하지 말 것.

4.1. ArchBang

http://archbang.org/

아치 리눅스를 기반으로 사용 편의성이 약간 강화된 배포판. 경량화 지향이라 오픈박스 윈도우 매니저 같은 매우 가벼운 X데스크톱 환경을 기반으로 세팅되어 있다. 또한, 인스톨 프레임웍(GUI 비슷한 인스톨 인터페이스. 예전 레드햇의 아나콘다와 비슷하다)을 지원하는 관계로 일일이 명령어를 입력할 일은 없으니 설치가 용이하다. 또한, 아치 리눅스와 동일한 롤링 릴리즈를 지원하므로 빠른 업데이트라는 장점은 그대로 가지고 있는 셈. 물론, 그 뿌리가 뿌리인 만큼 우분투 같은 배포판보다 손볼 점은 많을 수밖에. 그래도 아치리눅스의 저장소도 그대로 쓸 수 있으니 아치의 특징을 살리며 경량화 및 편의성의 접점을 추구하는 배포판이라 할 수 있다. 즉 초보자들이 아치를 접하기에 좀 더 쉬운 배포판이라 할 수 있다.

4.2. Arch Linux ARM

http://www.archlinuxarm.org

줄여서 알람(ALARM)이라고도 한다. 아치 리눅스는 x86-64만 지원하는 데 반해 ARM 아키텍처에서 돌아갈 수 있도록 포팅한 배포판. 부트스트랩 이미지로부터 설치한다는 방법을 사용하지 못하는 임베디드 디바이스 특성상 설치 이미지 대신에 바로 부팅 가능한 루트 파일 시스템을 제공한다. 물론 어떻게든 리눅스를 부트스트랩하는 데 성공했다면[15] x86-64용 아치식의 '전통적인' 설치도 가능하긴 하지만, 공식적으로 지원하는 방법은 아니다. ARM 아키텍처는 대부분 제품별로 각자 특색[16]이 있으므로 이미지를 각각 제공하며, 그만큼 각 제품에 대한 최적화도 갖춰져 있다. 제품별로 커널 이미지/드라이버도 패키지로 만들어 자주 업데이트되는 편. 다만 활발한 테스팅은 이루어지지 않는지 커널 버전은 기기에 따라 뒤처져 있는 경우도 많다. 또한 뒤집어 말하면 미지원 제품은 제너릭 커널을 다운받아서 /boot 파티션에 불필요한 파일을 떠안고 살아야 하거나, 심하면 제너릭 커널이 돌지 않아서 ABS로 직접 커널을 만들어야 할 수도 있다.[17] ARMv5, ARMv6, ARMv7, AArch64 (ARMv8~) 지원.

다른 배포판과 다르게 단순 포팅이기 때문에 x86-64 배포판 위키에 나온 웬만한 아키텍처에 구애받지 않는 설명은 따라 할 수 있다. 다만 인텔 기반 아치와 다르게 부트로더와 커널이 서로 묶여 있어서 공식적으로 부트로더 패키지를 지원하지 않으며[18] 검증이 덜 된 AUR 리포지토리가 미러 리스트에 대놓고 올라와 있으니 패키지를 받기 전에 공식 리포지토리에서 커뮤니티 소속인지 AUR 소속인지 미리 확인해보자.

다만 2016년 1월 14일 기준으로 2015년 12월에 보고된 바가 있는 라즈베리 파이 2 리눅스 커널상 오류가 꽤 오랜 시간 고쳐지지 않았었다. 해당 커널 버전은 4.1.15로, 이후 여러 차례의 업데이트가 있었으나 여전히 일부 SD카드에서 부팅이 되지 않는 증상이 발생하고 있다가, 커널 버전 4.4.10에서 해결되었다고 한다. 해당 포럼 링크

4.3. Antergos

https://antergos.com

구 Cinnarch.

아치 리눅스를 쉽게 사용할 수 있는 배포판. 기본 데스크톱 환경으로 GNOME을 사용하며, Cinnamon, KDE, MATE, Xfce, Openbox도 지원한다. 명령어를 직접 입력하면서 설치해야 하는 아치 리눅스와 달리, Antergos에는 cnchi라는 설치 프로그램이 있는데 이게 우분투의 그것과 흡사하다. 다만, 이 cnchi가 불안정한지 도중에 오류를 뿜고 설치가 취소되는 경우도 있다. 자세한 것은 항목 참조

4.4. Manjaro Linux

https://manjaro.org

아치 리눅스의 장점에 설치 간편화, 드라이버 지원, 하드웨어 자동 감지 등 편의성에 중점을 둔 배포판. 항목 참조.

4.5. -Netrunner-

http://www.netrunner.com/

Manjaro를 기반으로 세련되고 간편한 KDE 환경을 제공하기 위한 배포판이었으나, 2016.01버전을 끝으로 데비안으로 전부 갈아타게 되었다.

4.6. 기타

Arch Linux 32라는 배포판도 존재하는데, 이는 공식에서 32비트(i686) 지원을 끊어버리면서 그 지원을 승계하기 위한 배포판이다.

그 외 다른 아치리눅스 기반 배포판을 보려면 공식 위키의 Arch Based Distributions 페이지로. 전부 롤링 릴리즈의 장점을 그대로 흡수할 수 있다는 장점이 있으므로, 만일 아치 리눅스가 너무 어렵다고 생각되면 여기서 대체를 찾아보는 것도 좋다. 심지어 아랍어 아치도 있다!

KDE 환경을 선호한다면 Chakra, 우분투와 비슷한 환경을 선호한다면 Antergos 또는 Manjaro Linux 추천

5. 외부 링크

아치리눅스 사이트

아치리눅스 한국 사용자 모임

아치리눅스 한국 사용자 모임 페이스북 페이지

아치리눅스 특성상 문제 해결법이 있어도 문제 자체가 없어지거나 시스템이 변경되는 등으로 오래가지 못하는 경우가 많으므로 이곳에 서술하기보다는 위 사이트에 글을 올려주시기 바랍니다.


  1. [1] 그것도 2012년 7월 이후에 인스톨러 프레임워크가 사라졌음에도 불구하고.
  2. [2] 사실상 누구나 시간과 열정만 있으면 공개되어 있는 커널 소스와 기타 오픈소스 프로그램들을 마음대로 가져다 자신만의 리눅스 배포판을 만드는 게 가능하기 때문에 리눅스 배포판이 몇 개인지는 집계된 바도 없고, 아무도 알 수 없기 때문에 '모든 리눅스 배포판 중에서'라는 수식어는 당연히 붙을 수가 없다.
  3. [3] 이는 젠투의 경우 소스를 받아다가 컴파일하는 것은 맞지만, 해당 소스에 젠투 식의 패치를 더하는 경우가 많아 소스가 뜨고서도 패치를 더하고 그에 대한 테스트를 하는 데 시간이 좀(많이) 걸리는 경우가 많기 때문이다. 특히 Gentoo stable 버전은 업데이트가 상당히 느린 편.
  4. [4] 오픈소스 CAS 프로그램.
  5. [5] 다만 마이너한 패키지는 위키 페이지가 없을 수도 있는데, 이 경우는 man page와 해당 소프트웨어의 커뮤니티를 이용하면 된다. 하지만 아치 리눅스 내에서도 마이너한 프로그램이라면 특별한 이유가 있지 않은 한 다른 프로그램을 설치하는 게 나은 경우가 많다.
  6. [6] 단지 설명을 위해 가져온 예시일 뿐 pacman은 APT와 별 관련 없다. 레드햇 계열의 YUM이나 다른 패키지 관리자와 비교했을 때 딱히 APT에 더 가깝다거나 하는 특징도 없다.
  7. [7] ABS는 Deprecated되었다.
  8. [8] PACkage MANager
  9. [9] CUI이니만큼 진짜 캐릭터가 뜨는 건 아니고 한 칸 움직일 때마다 대문자 C와 소문자 c가 번갈아가며 나타난다
  10. [10] /etc/pacman.conf 파일에 'Misc options' 아래에 ILoveCandy를 추가해주면 된다. (대소문자 주의)
  11. [11] 참고로 현재는 본고딕을 pacman을 통해 설치할 수 있어 사정이 나은 편이며, AUR상 은글꼴은 현재 사라지고 spoqa han sans가 들어 있다.
  12. [12] 실제 오픈소스와 위키위키철학을 공유하는 면이 있다. 뿌리를 따져본다면 비슷함을 느끼는 게 당연하다.
  13. [13] 비주류 언어라 볼 수 있는 한국어의 경우 한글 관련 문제가 심심찮게 발생한다. 예를 들어 단어를 입력하다 보면 다음 글자가 입력되는 대신 바로 최근 글자를 커서가 먹어버리는 등.
  14. [14] KDE니 GNOME이니 해도 셸 기반이 아닌 이상 다 이걸 거치게 되어 있다. 80년대 작품인 데다 거듭된 패치로 그 몸뚱이가 심히 비대하고, 설계부터 비효율적인 부분도 있다.
  15. [15] 예를 들어, SD카드로부터 부팅할 때라든지, 기존에 존재하는 리눅스 대신 다른 파티션에 설치할 때라든지
  16. [16] 부팅방법, 하드웨어 드라이버 등
  17. [17] 물론 본가에서 ABS로 만들지 않고 어거지로 커널을 집어넣는 방법을 소상히 설명하고 있지만, 이러면 pacman에서 제공하는 공식 커널 및 거기에 부속으로 딸려오는 디펜던시와 어거지로 집어넣은 커널 파일이 꼬이기 시작해서 시스템 업데이트를 자주 돌리다 보면 망한다. 일단 저 방식대로 어거지로 커널을 넣어서 시스템이 동작하는지만 확인한 뒤, 제너릭 커널의 PKGBUILD 구조를 뜯어서 (AArch64용 예시) 커스텀 커널을 패키징해서 집어넣자.
  18. [18] 그 증거로 GRUB이나 systemd-boot 같은 부트로더들의 엔트리가 리포지토리에 아예 없다. 그래서 미지원 보드에서 EFI를 이용해서 직접 부팅을 시키려면 삽질을 꽤나 해야 한다.

분류

최종 확인 버전:

cc by-nc-sa 2.0 kr

Contents from Namu Wiki

Contact - 미러 (Namu)는 나무 위키의 표가 깨지는게 안타까워 만들어진 사이트입니다. (static)