여러분의 배포판 선택을 위한 소개

linuxlogo

지난 글에서 리눅스 배포판 종류에 대해 간략하게나마 소개해드렸습니다. 하지만, 배포판의 종류가 이런 것들이 있다는 정보 만으로는 내가 사용할 배포판을 선택하는데 어려움이 남아있죠. 그래서 여러분의 상황이나 성향에 맞는 배포판 선택에 도움을 드리고자 이 글을 작성하게 되었습니다.

기본적으로 시작점은 하드웨어의 상태입니다. 준수한 하드웨어(i3 이상 급의 CPU, 4G 이상의 RAM)라면 아래의 설명을 읽어보시면 되고, 그에 미치지 못한다면 DSL(Damn Small Linux), Puppy Linux 등을 살펴보시는 편이 좋습니다.

자 그럼, 가장 보편적이고 쉬운 배포판부터 차근차근 설명드리면서 시작해보도록 하겠습니다. 시작은, Out of the Box라고 불리는 배포판들입니다. Out of the Box라는 표현은 보통, 설치하자마자 사용이 가능한, 박스에서 꺼내자 마자 사용이 가능한 이라는 표현으로 사용합니다. 아래에 적을 배포판들은 모두 설치가 완료되자마자 일반적인 용도로 사용하는데 큰 불편이 없는 배포판입니다.(개발 환경을 의미하는 것이 아니라, 일반 데스크탑 사용자 측면으로써의 설명입니다.) Out of the Box로 분류되는 배포판들은 대개 롤링 릴리즈 타입이 아닙니다.

(굵직 굵직한 메이저 배포판만 다루겠습니다. TOP 5 등과 같이 순위를 매기려는 것은 결코 아니며 독자들이 가장 많은 관심을 가질만한 배포판만 다룹니다. 특히, BSD계열은 모두 제외합니다.)


 

ubuntu

 

네, 그 분입니다. 리눅스에 입문을 하시려는 분들은 우분투 리눅스나 혹은, 그 계열인 민트를 사용하시는 것을 추천합니다. 대부분의 사용은 GUI(그래픽 UI 환경)에서 처리가 가능하고 설치도 용이합니다.


 

debian

 

우분투 리눅스는 너무 식상하다거나, 조금 더 자세히 알아보고 싶다고 생각하시는 분들은 데비안 리눅스를 추천합니다. 데비안 리눅스는 GNU/Linux 배포판 중 2번째로 오래되었고, 아직도 건재한 배포판입니다. 데비안에서 파생되어 나온 우분투 리눅스마저 큰 성공을 거두었습니다. 데비안 리눅스는 견고(solid)하기로 유명합니다. 상당히 체계적인 검토와 테스팅을 거쳐 레파지토리(패키지 모음)에 올려지기 때문에, 데비안에서 기본적으로 제공하는 레파지토리에서 설치 가능한 패키지라면 꽤나 신뢰하고 사용하셔도 무방합니다. 다만, 위와 같은 특징 때문에 타 배포판보다 훨씬 오래된 버전의 패키지들을 사용하게 될 수도 있습니다. 이 부분은, ‘/etc/apt/source.list’를 편집하여 testing 버전으로 사용시 롤링 릴리즈 배포판처럼 사용할 수 있습니다.


fedora_logo

블리딩 엣지(최신 기술, 첨단 기술)의 영역에 입장하고 계십니다. 여기까지도 엄밀히 Out of the Box 형태의 배포판이지만 최신 기능이나 패키지들을 탑재하기로 유명합니다. 페도라는 최신 패키지들을 적극적으로 공식 레파지토리에 올려두기로 유명합니다. 어느 정도 버그가 있을 순 있겠지만 사용자에게 가장 최신 버전의 패키지들을 사용가능하도록 제공합니다. Out of the Box 진영과 Bleeding Edge진영의 사이에서 정확한 스윗 스팟을 자극한 배포판으로 생각합니다. 개인적으로, Arch, Gentoo, LFS까지 경험하던 중 결국 페도라에 눌러 앉았습니다. 리눅스 커널의 창시자이자 개발자인 Linus Torvalds가 과거 인터뷰에서 “데비안 설치는 너무 어렵고, 나는 개발자이지 배포판 설치 전문가가 아니라”면서 페도라를 사용하고 있음을 언급한 적이 있습니다.(토르발즈가 언급했던 어려운 설치 버전의 데비안은 아마도 ‘우디’ 시절로 추정하며, 그 당시엔 GUI 인스톨러가 아니었습니다.) 개인적인 생각으로도 개발을 위한 환경까지 아울러, 리눅스에 경험이 어느정도 쌓였다면 최적화된 배포판이 아닐까 생각해봅니다.


 

slackware.png

슬랙웨어 입니다. 리눅스의 역사에 더 매료되시는 분들은, 슬랙웨어를 추천합니다. 가장 오래된 배포판입니다. (사실 데비안과 3개월(?) 정도 차이밖에 나지 않습니다. 다만 데비안과 슬랙웨어를 제외하고는 당시 출시된 배포판은 대부분 소멸되거나 다른 방향으로 변화해왔습니다. 원래의 철학과 모습을 유지하는 배포판은 슬랙웨어와 데비안 뿐으로 생각합니다.) 엄밀히 말하면, 최초의 배포판을 ‘Boot Root’로 생각할수도 있지만, 지금과 같은 형태의 배포판으로써는 슬랙웨어가 확실히 최초라고 알려져 있습니다. 패키지 매니저는 pkgtool 과 slackpkg가 있습니다. 의존성을 직접 체크, 컴파일해야하는 패키지 매니저와 현대적인 의존성 체크와 바이너리 인스톨을 가능하게하는 패키지 매니저 둘 모두를 지닌 매력적인 배포판입니다. 데비안과 마찬가지로 올드한 패키지들을 보유하고 있습니다. 한 번쯤, 경험해보면 좋을 배포판입니다.

(한국 미러가 없습니다. KAIST측 문의를 했고, 검토 중인 것으로 알고 있습니다.)


7a9cb-13zj0sqjigkmcfohq0u2h5w

지금부터는 롤링 릴리즈 타입입니다. 본인이 어느 정도 리눅스를 공부하고자 하는 의지가 있는 분들에게 추천합니다. 설치는 CLI(커맨드 라인 인터페이스)로 진행하며, 기본 설치가 완료되어도 베이스만 설치되어있을 뿐, Xorg와 데스크탑 환경이나 윈도우 매니저도 직접 설치하여야 합니다. 따라서, 본인이 성공적으로 데스크탑을 완성하더라도 이 것이 어느정도나 안정적이고 보안에 취약한지는 확신할 수가 없습니다. 일반적으로 커뮤니티에선 “작동한다면 된거다”라고 하지만 완벽을 추구하는 성격인 분들은 상당히 성가신 부분일 수 있습니다. 패키지 매니저인 pacman은 C로 쓰여 상당히 빠릅니다. 롤링 릴리즈타입으로 특정 버전이 존재하지 않으며, 지속적으로 업데이트를 하면서 굴려 나가는 배포판입니다. 따라서, 롤링 릴리즈가 아닌 배포판들이 갖는, 메이저 업데이트 때의 충돌 위험 등을 고려하면 상당히 마음 편한 배포판입니다. (아치 리눅스 설치 방법)

(현재 카이스트 측 미러가 403에러를 뿜습니다. 카이스트 측에 문의를 드렸고, 권한 관련 오류 확인 되었고, 수정한다고 답신이 왔습니다.)


 

gentoo

네 애증의 젠투입니다. 젠투도 롤링 릴리즈입니다. 심지어, 아치와 마찬가지로 모든 설치는 CLI에서 진행하며, 설정도 직접 해주셔야 합니다. 아치보다 더 나아가 모든 패키지는 소스 코드를 다운 받아 직접 컴파일 합니다. 젠투 리눅스부터는 하드웨어의 영향을 좀 받습니다. 2 core 노인 CPU로 KDE Plasma 메타 패키지 컴파일에 2700여 분이 소요되고, KDE Framework 컴파일에 3400여 분이 소요됬던 사진은 페이스북에 업로드해드렸습니다. 재밌는 점은 하드웨어가 받혀준다면 사용하는데 큰 문제는 없습니다. i5-4세대 CPU로는 위의 패키지들 컴파일에 30여 분이 소요된 것으로 추정합니다.(정확한 측정은 하지 못했습니다.) USE플래그를 활용하여 각 패키지별로 본인이 사용할 기능과 그렇지 않은 기능을 포함/미포함하여 컴파일 할 수 있습니다. 개인적으로, CPU가 워크스테이션 급이 아닌 분들은 한 번쯤 사용만 해보시고 바이너리 배포판(위의 배포판 모두)을 사용하시는 것을 추천합니다. 급하게 ATOM에디터가 필요해서 $emerge -s app-editors/atom 이후, ~amd64로 마스크되어 있는 것을 확인하고 의존성 패키지의 마스크까지 ‘/etc/portage/package.accept_keywords’에 언마스크해준 이후, 컴파일을 시작하여 컴파일이 완료될 때 까지 개발을 못하고 있는 상황에 처하자마자 페도라로 돌아갔습니다. (젠투 리눅스 설치 방법, 젠투 홈페이지의 iso는 UEFI 부팅이 불가능합니다. 따라서, 아치 리눅스등의 iso를 통해 UEFI/GPT파티션으로 설치가 가능합니다: 해당 방법 설명)


lfs

LFS(Linux from Scratch)입니다. 완벽히, 학습용이라고 생각합니다. 설치 이미지(iso)파일도 제공되지 않고, 책을 보면서 설치합니다. 설치 환경 조성을 위해 ‘/mnt/lfs/tools’ 디렉토리를 생성하여 그 곳에 GCC등의 필수 패키지를 컴파일(호스트 PC의 GCC와 다른 필수 패키지들의 설정과 버전 등을 신뢰할 수 없기 때문에) 해 놓은 후, /tools의 패키지들을 이용해 /mnt/lfs의 베이스(다시, GCC와 나머지 필수 패키지)를 설치하고나서, 추가로 필요한 패키지들을 베이스 시스템의 GCC를 이용해 컴파일합니다. 추후에, BLFS 등에서 Xorg와 데스크탑 환경 등 까지도 컴파일할 수 있습니다. 젠투를 위시한 여러 배포판들은 사실상 LFS와 BLFS, CLFS 등과 같거나 유사한 과정을 통해 탄생한 배포판 들 입니다. 배포판 제작에 관심이 있으신 분들은, LFS를 통해 공부,연구 하셔도 무방할 듯 합니다. 젠투에서도 말씀드렸듯이, 젠투 부터 아래로는 모두 CPU의 영향을 매우 크게 받습니다.


여기까지 굵직한 배포판들의 간략한 소개를 드렸습니다. 이 글을 통해, 여러분들이 사용하실 배포판 선택에 도움이 되었기를 바랍니다. 개인적인 소망이지만 대한민국에 Daily Machine으로써의 리눅스 사용자가 더욱 더 많아지기를 기대합니다!

logorealfinal

LINUX에서 WIFI 사용 총 정리

linuxlogo

업데이트: 2018-08-30, 18:07 – wpa_supplicant 관련

LINUX에서 WIFI를 이용하는 것, 전혀 어렵지 않습니다.

이번 글에서는, CLI환경에서 몇 가지의 커맨드만을 이용해서 WIFI를 사용하는 방법을 소개하겠습니다.

우선, 친숙해지셔야할 명령어입니다.

  • ipconfig
  • iw dev
  • wpa_supplicant

(기본적으로 본인 하드웨어, 즉, 와이파이 장치의 드라이버가 로드되었다고 가정하겠습니다. 장치의 드라이버는 대부분 배포판에서 모듈로써 설치되어 인식되자마자 로드되기 때문에 걱정하지 않으셔도 됩니다. 이 부분을 신경써주셔야 할 배포판은 아치 리눅스(아치 리눅스도 사실 범용 드라이버는 문제 없다고 생각하셔도 무방합니다.), 젠투 리눅스 및 슬랙웨어, BSD계열 혹은 LFS입니다.)

  1. 드라이버
    기본적으로 본인의 Wireless 드라이버가 설치되어 로드되는지 확인해야합니다. 각 배포판에서 제공하는 Linux-firmware가 설치되어 있다면 대부분의 무선 장치는 문제없이 사용할 수 있어야만 합니다. 아래의 커맨드를 입력해 봅니다. (모듈이 제대로 로드되지 않았다면, 해당 부분은 별도의 글에서 다루도록 하겠습니다. 현재는 모듈이 제대로 로드되어있는 경우를 대상으로 합니다.)

    $lspci -k

    아래와 같은 부분이 확인되어야 합니다.

    06:00.0 Network controller: Intel Corporation WiFi Link 5100
    Subsystem: Intel Corporation WiFi Link 5100 AGN
    Kernel driver in use: iwlwifi
    Kernel modules: iwlwifi

    위의 정보에서 1) 네트워크 컨트롤러가 어떤 것인지, 2) 커널 드라이버가 어떤 것이 사용되고 있는지, 3) 커널 모듈의 이름은 무엇인지 확인할 수 있습니다. 즉, 위의 예에서는 Intel WiFi Link 5100이라는 이름의 하드웨어가 사용되고 있고, 커널드라이버는 iwlwifi가 사용되며, iwlwifi에 해당하는 모듈의 이름은 iwlwifi입니다.

    다음의 명령을 통해 인터페이스의 이름이 무엇으로 적용되었는지 확인합니다.

    $ipconfig

    기본적으로 아웃풋을 눈여겨보시면

    eth0       Link encap:Ethernet ~~
    inet addr:192.168.0.194 Bcast:192.168.0.255 Mask:255.255.255.0
    (추가적인 정보들)

    lo            (지금은 모르셔도 되는 추가적인 정보들)

    wlan0    Link encap:Ethernet Hwaddr~~
    (아래로 추가적인 정보들)

    위와 같이 등장합니다. 일반적으로, eth0에 해당하는 여러분의 장치명(예를 들어, enp2s0일 수도 있고, enp0s3일 수도 있고)은 유선 연결 인터페이스명에 해당하고 wlan0 부분에 해당하는 여러분의 장치명(예를 들어, wnp2s0 혹은 wlp0s2 등)은 와이파이 장치의 인터페이스 이름에 해당합니다. 이 인터페이스 이름을 잘 기억해두시거나 적어두신 후에 아래를 진행합니다.

  2. 인터페이스 켜기
    이제, 해당 장치의 인터페이스를 켜보도록 하겠습니다. 쉽게 설명하자면 장치를 켜는 것과 같다고 생각하시면 됩니다. 반드시 아래 예시의 wnp2s0부분에는 위에서 확인한 본인 와이파이 장치의 인터페이스 이름이 들어가야합니다. 아래에서 계속 동일합니다. 

    $ip link set wlp2s0 up
  3. 정보 입력
    1. 본인의 와이파이 이름을 모르는 경우
      $iw dev wlp2s0(본인 장치명) scan

      위의 명령어를 통해 와이파이 장치가 주변의 와이파이를 스캔할 수 있습니다. 결과물 중, 본인이 연결하고 싶은 와이파이 이름을 확인합니다.

    2. 본인의 와이파이 이름과 비밀번호를 모두 아는 경우
      1. ‘wpa_passphrase’라는 명령을 통해 내가 알고 있는 와이파이 이름과 비밀번호를 변형해줍니다. ‘$wpa_passphrase 와이파이이름 와이파이비번’을 해보시면 올바른 형태로 출력됩니다. 하지만 이것을 파일에 그대로 옮기는 것이 귀찮기도하고, 오타가 발생할 확률이 있기 때문에 아래와 같이 자동으로 처리하는 방법이 있습니다. 참고로, /etc/wpa_supplicant/본인드라이버명.conf 파일에 추가하면 관리하기가 편합니다. 다른 파일명으로 하셔도 무방합니다. 하지만 와이파이 연결을 진행할 때 해당 파일명을 정확히 기억하고 있어야 합니다.
        $wpa_passphrase my_wifi_ssid my_wifi_password >> /etc/wpa_supplicant/wlp2s0.conf
      2. 이제 아래 명령을 통해 실제로 와이파이를 켜보겠습니다. -B: background로 진행, -i: device 이름을 적어줍니다. 아래 예시에서는 wlp2s0, -c: 파일의 위치를 알려줍니다. 아래 예시에서는 2.에서 진행했던 경로를 사용하였습니다.
      3. $wpa_supplicant -B -i wlp2s0 -c /etc/wpa_supplicant/wlp2s0.conf
  4. IP 받기-DHCP를 이용하는 경우
    $dhcpcd
    or
    $dhcpcd wlp2s0(본인 장치명)

 

확인은 물론 아래와 같이 합니다.

$ping -c 3 www.google.com

 

끗!

logorealfinal

젠투 리눅스에 대하여

gentoo

2주간 10여차례 젠투를 빌드하고 부수고 다시 빌드하고, 사용하기도 해보았으나, 도저히 메인 OS로 사용하기에는 취향이 맞지 않아서 아치로 돌아왔습니다. 어떤 점들이 불편했는지, 어떤 점들은 불편하지만 여전히 강점으로 작용하는지 분석해보려고 합니다. 최근 새로운 포스팅이 뜸했던 이유가…

아래의 내용은 모두 개인적인 견해이며, 객관적인 지표로 활용될 수 없음을 밝힙니다. 또한, 사용자가 젠투를 빌드하고, 사용했던 환경의 CPU는 ‘i3-6006U’이었으므로, 최소 4코어/4쓰레드 이상의 CPU 혹은 그렇지 않다 하더라도, 높은 클럭을 자랑하는 프로세서의 경우에서는 아래의 내용 중 일부의 불편은 없을 것으로 생각됩니다.

  1. 인기도 : [디스트로 워치/slant 기준] 물론, 디스트로 워치의 사용자 선호도 순위가 절대적이지 않습니다. 오히려 리눅스 커널 기반의 배포판은 사용자를 추적하지 않기 때문에 정확한 수치를 산출해내기가 어렵습니다. 다만, 이용자들의 방문,검색을 기반으로 하는 수치임에도 불구하고 현저한 차이가 난다는 것은 그 만큼의 선호도 격차가 존재할 수 있다는 ‘경향성’ 자체는 부정하기 힘들어 보입니다. (2017년 12월 5일 09시 현재 6개월간의 페이지 방문 순위를 기준으로) 아치 리눅스는 14위, 젠투 리눅스는 41위에 위치해 있습니다. 그리고 이 인기도는 ‘7.1. 커뮤니티’에서 설명할 커뮤니티 사용자 수에 영향을 주고 있는 것으로 보입니다.
  2. 컴파일 : (컴파일에 소요된 시간은 설치 도중, 그리고 emerge 명령어에 선행하여 ‘time’ 명령어를 삽입함으로써 확인할 수 있습니다.)젠투는 stage3 타르볼을 links등의 cli기반 웹브라우저를 통해 다운로드한 뒤 압축을 해제하여 기본 도구를 갖춘 상태로, 커널을 포함한 모든 빌드를 직접 컴파일 합니다. 이것은, 내 하드웨어에 직접적으로 영향을 미치는 작업으로써, 다른 배포판에 비해서 모든 것이 빌드되고 난 후 성능에 있어서 긍정적인 효과를 기대할 수 있습니다. 문제는 2가지 측면에서 발생합니다. 컴파일 자체에 들어가는 ‘시간’과, 그러한 ‘직접’ 컴파일 과정을 통해 얻을 수 있는 성능의 ‘기대치’ 입니다.
    1. 시간 : 우선, ‘i3-6006u’ CPU와 4G 램을 포함하는 ‘ASUS-X541U’ 랩탑으로 커널 빌드에 30여분 이상이 소요되었고(configuration 제외/순수 ‘make’, ‘make install’), ‘xorg-server’ 및 ‘KDE-plasma’의 경우에는 (메타)패키지 ‘fetch’ 이후 컴파일 하는데 최소 3~7시간이 각각 소요되었습니다. (심지어, 저것들은 GUI 환경 구축을 위한 필수적인 요소일 뿐, 추가적으로 여러 패키지들이 컴파일되어야 합니다.)물론, 제 경우에는 취침 동안 컴파일 하였기 때문에 생활에 직접적인 영향이 있지는 않았습니다만, 활용할 수 있는 다른 기기가 없는 경우에는 컴파일 되는 화면만 여러 시간 지켜보고 있어야 한다는 뜻이 되기도 합니다.
    2. 성능 : (이 부분에 있어서 가장 큰 논쟁의 가능성이 엿보입니다. 개인적인 견해로 생각해주시고, 비판은 환영합니다.)흔히 젠투의 컴파일을 통하여 얻을 수 있는 성능의 차이는 3%내외라고 합니다.(링크1/링크2) 과거의 경우 프로세서 성능이 현재와 비교하기 힘들만큼 부족했기 때문에 컴파일 시간이 상당하더라도 그를 통해서 얻을 수 있는 이점 또한 명확했다고 생각합니다. 웹 환경에서 검색을 해보더라도 2003~2009년 까지도 ‘젠투 vs 다른 배포판’ 구도의 성능 차이 질문이 상당 부분 차지합니다. 물론, 아치 리눅스가 런칭하였던 2002년 부터는 KISS의 철학을 가장 잘 구현해낸 대표적인 배포판 둘 답게 메인 대결 구도로 확산되어 왔습니다. 다만, 2010년대에 이르러서는 프로세서의 성능이 워낙 향상되는 바람에, 컴파일을 통한 성능 차이가 실존하는가에 대한 물음으로 바뀌는 경향을 확인할 수 잇습니다. 이전에 제시한 링크2를 보시면, 5개월 전에 이르러서는 일반 사용자 기준의 대부분 소프트웨어의 경우에 확연한 성능 차이는 없다는 답변 마저 보이고 있습니다. 개인적인 의견으로는 심지어 파이어폭스 브라우저의 경우에도 성능의 차이는 존재하기는 하는 것처럼 느꼈습니다. (그건 기분탓..). 그 성능의 차이가 3%이든지, 혹은 확연한 차이가 존재하든지 컴퓨터 하드웨어적인 측면에서 생각해보았을 때 각종 CPU flag를 사용하여 직접 컴파일한 배포판에서 성능의 차이가 ‘존재할 수 밖에 없음’을 부정할 수는 없을 것입니다. 문제는 그 성능의 차이가 컴파일에 소요된 시간을 상쇄해줄 만큼 큰지는 개인적인 선택에 맡겨질 것입니다.
    3. 추가로 따라오는 문제는 컴파일의 문제 덕분에 산업 환경에서 민첩하게 대응하기 힘들다는 점입니다. 집에서 워크스테이션으로 사용하면서 필요한 모든 패키지를 얼마나 오랜 시간이 걸리든 모두 컴파일 해두고 조금씩 수정해나가는 경우에는 문제가 없으나, 성능의 향상을 기대하는 랩탑의 경우에는 들고다니면서 업무상 필요한 새로운 소프트웨어가 발생할 경우, 그것을 컴파일해야하므로 업무가 일시정지되는 문제가 발생합니다. (이것은 ‘3. 바이너리 빌드에서 예로 드는 방법으로 해결할 수도 있습니다.)
  3. 바이너리 빌드 : 컴파일의 문제가 대두될 경우, 바이너리 빌드를 사용할 수 있습니다. 소프트웨어가 내 CPU아키텍처를 이용해 컴파일 된 바이너리 파일이 존재할 경우 그 바이너리 파일을 다운로드하여 설치할 수 있습니다. 제가 이런 방법이 있다는 것을 알게 된 후에 바로 든 생각 한 가지는 다음과 같습니다. “젠투 리눅스에서 바이너리 빌드를 활용한다면, 도대체 아치 리눅스와 다른 점이 무엇인가?”. 젠투 리눅스를 사용하겠다고 결정할 경우 가장 크게 작용하는 요인이 하드웨어에서 직접 컴파일 하는 부분일테고, 그렇다면 굉장히 시급한 경우가 아니고서는 바이너리 빌드가 가지는 매력은 전무하다고 가정해야 할 것 같습니다. 심지어는 ‘5. USE Flag’ 에서 보여드릴 ‘bindist’를 이러한 측면에서 꺼두고(-bindist) 사용하시는 분들도 계십니다.
  4.  MAKE.CONF : 일반 환경 아래에서 ‘/etc/portage/make.conf’파일이 있습니다. 이 파일이 젠투의 핵심에 해당한다고 할 수 있습니다. 여기에는 GCC 컴파일 과정에서 옵션으로 사용할 기본값을 제공할 수 있고, ‘5.USE Flag’에서 설명할 각종 플래그를 설정해둘 수 있습니다. 뿐만 아니라, 내가 사용할 ‘Input Device’, ‘Mirrorlist’, ‘grub-platform’ 등 젠투 빌드의 설계도면과 같습니다. 아주 매력적이고 재미있는 부분이었습니다. 다만, 아치의 경우 ‘/etc/makepkg.conf’에 유사한 대부분의 환경 설정을 해줄 수 있습니다. 젠투는 사용자의 빌드에 의존하여 설계를 시작하지만(gcc cpu flag의 경우에도 ‘-march=native’마저도 default로 제공되어 있지 않습니다.), 아치의 경우는 기본적인 설계 도면이 제공된다는 측면을 제외하면 차이점은 없어 보입니다. 아치 리눅스의 기본 설정 cpu-flag는 다음과 같습니다. (i3-6006u프로세서에서/ “-march=x86-64  -tune=generic -O2 -pipe -fstack-protector-strong -fno-plt”/ 이 내용을 활용하시면 본인 하드웨어에 최적화된 ‘make.conf’ 파일을 생성하기에 수월할 것으로 보입니다.
  5. USE Flag : ‘예시’ 라는 이름의 패키지를 설치할 때 이 패키지가 가지는 USE flag를 확인한 뒤 원하는 기능을 켜고, 끈 채로 컴파일할 수 있습니다. 예를 들어서, ‘예시’ 패키지가 가지는 USE flag가 ‘a’,’b’,’c’,’d’ 가 있을 때, 내가 원하는 ‘a b’ 기능은 ‘make.conf’ 파일의 USE flag 아래에 입력하여 포함한 채로 컴파일 할 수 있습니다.
    1. USE flag 설정의 체계 : 젠투의 USE flag는 세련된 계층 구조를 가지고 있습니다. ‘#eselect profile set n’을 통해서 설정한 프로필을 통해 크리티컬한 USE flag의 경우 default.use로 적용 됩니다(링크). 그 이후, 그 곳에는 포함되어 있지 않은 (대부분의 경우 유저 측면의 소프트웨어에서 제공하는) 소프트웨어의 USE flag중 사용하지 않을 것들은 make.conf/USE flag 부분에서 켜고 끌 수 있습니다. 다만, 예외로 할 패키지가 있는 경우에는 /etc/portage/package.use에 혹은 그 아래에 개별 패키지명을 제목으로 하는 파일을 생성하여 활용할 수 있습니다.(예시, ‘/etc/portage/package.use/example’ 파일 내부에 ‘test/example d e -f’와 같이)
    2. -c & 미포함의 차이 : 위의 경우에 어차피 c를 포함하지 않는 경우와 굳이 USE flag에서 ‘-c’로서 제외해주는 것에 어떤 차이가 있는지에 대해서 대표적인 두가지 차이를 볼 수 있습니다.(포럼)
      1. 일부 패키지에서 c를 사용하려고 하지만, 나머지의 대부분 경우에서 c를 제외하고 싶은 경우 : use flag에는 -c를 해둔 후, package.use에 원하는 패키지에만 c플래그를 켜실 수 있습니다.
      2. 패키지에서 default로 c를 켜는 경우 : 일부 패키지의 경우 그 기능이 필요하다는 이유 혹은 여러 다른 이유에서 일부 use flag를 켠채로 등장할 수 있습니다. 이럴 때에 직접 USE flag에서 -c플래그를 통해 꺼줌으로써 컴파일되는 것을 막을 수 있습니다.
  6. emerge -auDN @world : USE플래그에 수정을 하였거나, 업데이트를 하고 싶은 경우 사용합니다. 이게 가장 큰 걸림돌입니다. 내가 가진 소프트웨어들 중, 수정된 USE flag의 영향을 받거나, 업데이트가 있는 경우 재컴파일하거나 설치합니다. 잘 때 실행합니다.
  7. 그 외 : 아래의 내용들은 젠투를 포기하는데 크진 않지만 작게 영향을 미친 항목들입니다. 혹시 독자의 성향에는 중요한 판단 기준일 수 있으므로 포함하겠습니다.
    1. 커뮤니티 : 아치의 커뮤니티는 너무 거대합니다. 최대한 유사한 카테고리에 비슷한 시기에 올린 비슷한 질문에 대한 뷰수가 확연히 차이납니다. 아치 리눅스의 경우 재확인 하였을 때 6400뷰를 넘어서고 4페이지까지 밀려있었지만, 그만큼 답변도 활발하고 해결방법들이 여러가지로 제시되어 있었습니다. 다만, 젠투의 경우 2300뷰에 문제는 1페이지 첫 글로 유지되고 있다는 점입니다. (글 작성 현재까지도) 물론, 페도라 포럼에 비하면 두 커뮤니티 모두 어마어마한 강점을 가집니다. 글의 내용과 어긋나긴 하지만 페도라 포럼은 300뷰에 해결도 되지 않습니다. 아예 답변이 달리지 않더군요. 각 포럼의 링크를 제공해드리고 이 항목은 마치겠습니다. (아치 리눅스/젠투 리눅스/페도라 리눅스) (젠투 포럼/위키는 유독 접속 시 소요 시간이 길고, 간혹  DNS 에러가 발생하는데 왜 그런지 모르겠습니다;)
    2. UEFI 설치 : 다른 글에서 포스팅하려고 하지만 여기에 포함하는 것이 적합해 보여서 수정합니다. 젠투 미니멀 인스톨 iso의 경우에 마지막 확인했을 때 까지는 UEFI 인스톨을 지원하지 않습니다. UEFI로는 부팅이 되지 않아서 다른 UEFI 부팅이 가능한 설치 이미지를 이용해서 설치하셔야 합니다. (해당 방법은 링크를 통해 확인하시면 됩니다.) 본의 아니게, 젠투 리눅스를 아치 리눅스 설치 이미지로 설치한 진귀한 현상이 벌어졌습니다.

글은 여기서 마치겠습니다. 이 외에도 젠투가 가지는 강점이 더 있을 거라 사료됩니다. 짧은 경험이었고 저도 아직 공부할 부분이 많은 학생이기 때문에 적힌 내용이 편향되었거나, 오류가 있을 수 있습니다. 그런 부분은 지적해주시면 확인해보고 수정하도록 하겠습니다. 또, 추가하고 싶은 사항이 있으신 경우에 댓글 다시거나 이메일:talk@withjeon.com 으로 연락하시면 고려하여 추가하도록 하겠습니다.

logorealfinal

 

젠투 리눅스를 아치 리눅스 iso로 설치하는 방법

gentoo

많은 분들이 젠투 관련 포스팅을 할 때 머리말에 즐겨 쓰시는 것 같아서 저도 적어봅니다. 젠투 리눅스를 사용하고자 하시는 분이라면, 이미 리눅스 전반에 대하여 어느 정도 지식이 있다고 가정하겠습니다.

젠투 리눅스 공식 페이지의 “minimal-install.iso”파일의 경우 UEFI부팅을 지원하지 않습니다. 왜인지는 열심히 찾아보아도 정답을 찾지 못했습니다. 공식 핸드북에서는 UEFI부팅을 원할 경우 LiveDVD.iso를 다운로드 받아서 설치하라고 권장하는데, LiveDVD는 2016-07출시버전이 최신인데다가, 심지어 LiveDVD파일도 UEFI 부팅이 가능하지 않습니다.

포럼에서는 UEFI 부팅을 위해서 RescueCD를 사용하라고 합니다. 개인적으로는 “아치 리눅스 iso”파일을 이용해서 젠투를 설치하는 방법을 소개해드리겠습니다.

64비트, UEFI 설치를 가정합니다.

준비물

성공적으로 부팅이 가능한 archlinux.iso파일

다운로드 링크>하단>SouthKorea>ftp.kaist.ac.kr>
"archlinux-2017.11.01-x86_64.iso"다운로드(날짜는 변경가능)

usb에 구워줍니다.

#lsblk

#sudo dd bs=4M if=~/Downloads/arch(tab) of=/dev/sdb status=progress && sync

재부팅

재부팅 과정에서 F2등 바이오스/UEFI환경으로 진입합니다. UEFI설치를 진행할 예정이므로, BIOS로 진입되는 분들은 추가 설치가 불가능합니다.(오히려 그런 분들은, 공식 핸드북에서 설명하는대로 진행하시면 됩니다. BIOS환경에서는 minimal install iso가 더 낫습니다.) UEFI 환경으로 진입하시게 되면, 두가지를 다시 한번 확인하겠습니다.

>CSM-MODE : DISABLED

>SECURE-BOOT : DISABLED

부팅 완료 후

인터넷 확인

#ping -c 3 www.google.com

디스크 파티션

#gdisk /dev/sda

/dev/sda1 = EF00 = 512MB = /boot 에 마운트할 예정

/dev/sda2 = 8200 = 4G = swap

/dev/sda3 = 8300 = free space = /(root) 에 마운트할 예정

포맷

UEFI 를 위해선 ESP가 필요합니다. 부트 디렉토리에 마운트될 파티션의 경우 fat32로 포맷하셔야 합니다.

#mkfs.fat -F32 /dev/sda1

#mkfs.ext4 /dev/sda3

#mkswap /dev/sda2

#swapon /dev/sda2

마운트

#mkdir /mnt/gentoo

#mount /dev/sda3 /mnt/gentoo

#mkdir /mnt/gentoo/boot

#mount /dev/sda1 /mnt/gentoo/boot

젠투 설치 준비

날짜

#date 112111252017(월/일/시/분/년)

설치 환경 진입

#cd /mnt/gentoo

타르볼 다운로드

아치 리눅스에서는 “elinks”라는 브라우저를 제공합니다. 이것을 이용합니다.

#elinks https://www.gentoo.org/downloads/mirrors/

접속해서 화살표 아래키를 이용해 내려가다보면 미러 목록에서 아시아에 KR이 있습니다. 엔터를 통해 이동합니다. DAUM의 미러를 이용하겠습니다. http://ftp.daum.net/gentoo/에  접속해보시면 (폴더)releases>amd64>autobuilds>”current-stage3-amd64″>

stage3-amd64-20171116.tar.bz2“엔터>다운로드를 받아줍니다.>

아직 브라우저를 종료하지 마시고>Parent Directory를 계속 이용하여>아까 release를 들어갔던 디렉토리로 재이동합니다.(/gentoo)>snapshots>맨 아래로 내려가서>

“portage-latest.tar.bz2”를 다운로드 받습니다.

압축 해제

#tar xvjpf stage3(tab) --xattrs --numeric-owner

기다려줍니다.

#tar xvjpf port(tab) --xattrs --numeric-owner

이건 조금 짧은 편입니다.

MAKE.conf파일 수정

#nano -w /mnt/gentoo/etc/portage/make.conf

Cflag=”-march=native -O2 -pipe”

MAKEOPTS=”-j4″

MAKEOPTS의 경우에는 #nproc 명령어를 통해 출력되는 숫자를 입력하시면 됩니다.

미러 선택

아치 환경에서 설치를 진행하면서 mirrorselect 커맨드는 찾을 수 없다고 해서 위의 make.conf파일에 수동으로 입력해주었습니다.

GENTOO_MIRRORS=”http://ftp.daum.net/gentoo/ http://ftp.kaist.ac.kr/pub/gentoo/ http://ftp.lanet.kr/pub/gentoo”

그 이후로는 젠투 핸드북(아래 링크)의 내용과 동일하게 진행하시면 됩니다.

링크: 젠투 핸드북(Gentoo ebuild repository부터/한글 페이지 사용 가능)

필독!! [링크]

  1. 진행 중 proc 마운트 부분에서 : “#mount -o bind /proc /mnt/gentoo/proc” 를 사용
  2. /dev 까지 마운트 이후
    1. #test -L /dev/sdhm && rm /dev/shm && mkdir /dev/shm
    2. #mount –types tmpfs –options nosuid,nodev,noexec shm /dev/shm
    3. #chmod 1777 /dev/shm
  3. chroot 할 때
    1. #chroot /mnt/gentoo /bin/env -i TERM=$TERM /bin/bash
    2. #env-update
    3. #source /etc/profile
    4. #export PS1=”(chroot) $PS1″
  4. grub2때 핸드북에서 UEFI부분 잘 읽기

logorealfinal

 

 

 

 

시스템 언어 설정 정리

linuxlogo

아치 리눅스 설치 과정에서

$locale-gen

이 있고,

$local.conf

파일을 수정하는 단계가 있습니다.

locale-gen의 경우 language_territory.codeset 의 구성을 가지고 사용할 언어와 현재 지역, 언어의 코드셋을 지정하는 것입니다. 따라서, 설치 과정에서 ‘en_US.UTF-8’의 주석을 제거할 경우, english(영어)를 사용하면서, US(미국)에서, UTF-8 코드셋을 사용하겠다는 뜻이 됩니다. 따라서, 추가로 여러가지 주석을 더 제거해도 큰 문제가 없습니다. 예를 들어 ‘ko_KR.UTF-8’의 주석을 제거할 경우 한국어를 사용하며 한국에 있고, UTF-8코드의 한글을 사용하겠다는 뜻입니다(근데, /etc/locale.gen 파일에서 너무 아래에 있어서 그냥 안지우곤 합니다.)

locale.conf의 경우에는 시스템 전반에서 사용하는 언어를 의미합니다. 따라서

$echo "LANG=en_US.UTF-8" >> /etc/locale.conf

라고 하면, 언어를 영어로 미국지역.UTF-8코드셋으로 사용하겠다는 의미가 되어, 디렉토리 등의 모든 시스템 언어가 영어로 설정됩니다.

$export "LANG=en_US.UTF-8"

이것은 별도로, 현재 쉘에서 진행되는 모든 과정을 저 언어 세팅으로 변경하겠다는 뜻입니다.

 

(한글 입력 방법이 궁금하신 분들은, 설치 과정 가이드를 클릭하셔서 목차>”한글 입력”부분을 참고하시면 됩니다.)

logorealfinal

usb 리눅스/윈도우 호환 포맷

linuxlogo

리눅스 시스템에서 USB를 어떤 파일시스템으로 포맷해야 윈도우즈와 문제가 없이 호환이 될까요? 이전에 NTFS로 포맷했다가 리눅스에서 권환 관련 설정으로 애먹은적이 있어서 포스팅합니다.

각 파일 시스템별로 최대 크기나 파일 크기의 한계가 다르기 때문에 포맷하기전에 잘 확인하셔야 합니다!(파일시스템 정리 링크)

간단하게 다시 정리해드리면 아래와 같습니다.

  1. NTFS : 최근 윈도우 시스템에서 사용하는 파일시스템입니다.
    1. 최대 파일 크기 : 충분(상업용으로 사용 가능한 드라이버의 용량보다 큼)
    2. 최대 볼륨 크기 : 16EB
  2. HFS+ : 애플에서 사용하는 파일시스템입니다.
    1. 최대 파일 크기 : 충분(상업용으로 사용 가능한 드라이버의 용량보다 큼)
    2. 최대 볼륨 크기 : 8EB
  3. APFS : HFS+ 대체하고자 개발된 파일시스템입니다.
    1. 최대 파일 크기 : 충분(상업용으로 사용 가능한 드라이버의 용량보다 큼)
    2. 최대 볼륨 크기 : 16EB
  4. FAT 32 : NTFS 이전 윈도우즈의 기본 파일시스템입니다.
    1. 최대 파일 크기 : 4GB
    2. 최대 볼륨 크기 : 8TB
  5. EXT 2,3,4 : 리눅스의 기본 파일시스템들입니다. 아래는 EXT 4 기준
    1. 최대 파일 크기 : 1EB
    2. 최대 볼륨 크기 :  16TB

각 배포판별 호환여부를 확인하시는게 올바르지만 기본적인 관점에서 봤을 때 리눅스는 APFS정도 제외하고는 무난하게 호환이 가능합니다. 다만, NTFS는 위에서도 언급했듯이 자동 usb 마운트로는 권한에 문제가 생겨서 파일 생성이나, 삭제 등에 번거로움이 있으니 피하신는 것도 좋습니다. 문제는 윈도우즈나 APPLE의 호환 여부입니다. 윈도우즈의 경우 위의 번호목차에서 3번부터 아래로는 호환이 되지 않습니다. 물론, 5.EXT 2,3,4 들의 경우에는 추가 소프트웨어를 통해 호환이 가능하지만 그런 번거로움은 우리가 원하는 것이 아니죠.

그리고 본인이 관리하는 파일들의 크기도 염두해두셔야합니다. 큰 크기를 가지는 각종 동영상(?) , 혹은 전문 사진 작업을 위한 파일 등을 관리하셔야 할 경우에는 FAT32의 경우 개별 파일의 크기가 최대 4GB이기 때문에 적합하지 않습니다.

여러가지 상황을 종합해 보았을 때 윈도우즈 PC와 리눅스 PC를 오가며 작업하셔야 할 때에는 FAT32가 가장 무난한 것 같습니다. FAT32 파일시스템의 경우 공개된지 기간도 오래되어 거의 모든 OS와 호환이 지원됩니다. Windows는 당연하고 MacOS, LINUX, Playstation, Xbox One까지 호환되는 것으로 알려져 있습니다.

그럼, 리눅스 환경에서 USB를 포맷해 보겠습니다.

$lsblk
//출력된 결과에서 usb 장치의 이름을 정확히 확인합니다.
$sudo wipefs --all /dev/sdb
//usb 장치의 이름을 정확히 확인하셔야 합니다.
//'/dev/sdb' 의 내용을 모두 지웁니다.
$sudo mkfs /dev/sdb
//시간이 소요됩니다. 기다리시면 됩니다.
$sudo cfdisk

‘DOS’ 라벨 선택

‘Linux Filesystem’ 타입 확인

$sudo mkfs.fat -F32 /dev/sdb1
//끝!

 

 

#각 배포판에서 사용하는 파일 매니저에서 usb에 마우스를 올리거나, 우클릭을 해보면 ‘안전하게 장치 제거’가 보입니다. 사용을 권장합니다.(혹은 $umount /dev/sdXn 추천!)

logorealfinal

리눅스 파일 시스템 정리

linuxlogo

파일 시스템에는 엄청나게 많은 종류가 있습니다. 각각 다룰 수 있는 총 드라이브의 크기, 각각의 파티션 볼륨의 최대 크기, 파일 이름으로 지정할 수 있는 길이 등이 천차만별입니다. 그 중에서 일부를 간략하게나마 정리해보도록 하겠습니다.

  1. 마이크로 소프트 계열
    1. FAT(File Allocation Table)
      1. FAT12
        1. MBR identifier
        2. 최대 볼륨 크기 :16Mib
        3. 최대 파일 크기 : 최대 볼륨 크기
        4. 최대 파일 개수 : 4068
        5. 최장 파일 이름 : 8.3filename
      2. FAT16
        1. MBR identifier
        2. 최대 볼륨 크기 : 4Gib(?)
        3. 최대 파일 크기 : –
        4. 최대 파일 개수 : 65,536
        5. 최장 파일 이름 : 8.3 filename
      3. VFAT
        1. 위의 파일 시스템이 갖는 파일 이름 길이의 한계를 극복하고자 만들어짐
        2. 기존의 파일 시스템과 하위 호환을 유지함
        3. 255 글자, 공백, 마침표를 지원
        4. Windows 95 이후 등장
        5. 실제로는 긴 이름으로 파일 생성시 Windows 95이상을 위한 파일하나와 약식 제목으로 하는 파일 하나(Windows DOS 호환 목적)이 생성됨
      4. FAT32
        1. MBR identifier
        2. 최소 볼륨 크기 : 4.5Kib ~ 32Mib
        3. 최대 볼륨 크기 : 2Tib
        4. 최대 파일 크기 : 4Gib-1(4,294,967,295 bytes) with LFS
        5. 최대 파일 개수 : 268,173,300
        6. 최장 파일 이름 : 8.3 filename
        7. 기타 : UEFI 부팅을 위해 필요한 ESP에서 필요로 하는 파일 시스템.
      5. exFAT(EXtended File Allocation Table)
        1. 2006년 11월 마이크로소프트에 의해 공개
        2. USB나 SD 카드에 적합한 파일시스템 목적
        3. 최대 볼륨 크기 : 256Tib
        4. 최대 파일 크기 : 최대 볼륨 크기
        5. 최대 파일 개수 : 디렉토리당 2,796,202
        6. 최장 파일 이름 : 255 UTF-16
    2. NTFS
      1. 최대 볼륨 크기 : 256Tib
      2. 최대 파일 크기 : 최대 볼륨 크기
      3. 최대 파일 개수 : 4,294,967,295
      4. 최장 파일 이름 : 255 UTF-16
  2. 애플 계열
    1. HFS
    2. HFS+
    3. APFS
  3. 유닉스/리눅스 계열
    1. UFS(Unix File System)
      1. 최대 볼륨 크기 : 8Zib
      2. 최대 파일 크기 : 최대 볼륨 크기
      3. 최장 파일 이름 : 255 bytes
    2. ext2(Second EXTended filesystem)
      1. 1993년 2월 리눅스와 함께 공개
      2. 최대 볼륨 크기 : 2~32Tib
      3. 최대 파일 크기 : 16Gib~2Tib
      4. 최대 파일 개수 : 10^18
      5. 최장 파일 이름 : 255 bytes
    3. ext3(Third EXTended filesystem)
      1. 2001년 11월 리눅스 2.4.15와 함께 공개
      2. 최대 볼륨 크기 : 4Tib~32Tib
      3. 최대 파일 크기 : 16Gib~2Tib
      4. 최대 파일 개수 : 가변적
      5. 최장 파일 이름 : 255 bytes
    4. ext4(Fourth EXTended filesystem)
      1. 첫 등장(unstable version) 2006년 10월 10일 리눅스 2.6.28과 함께 공개
      2. 최대 볼륨 크기 : 1Eib/권장 : 16Tib
      3. 최대 파일 크기 : 16Tib
      4. 최대 파일 개수 : 40억개(가변적)
      5. 최장 파일 이름 : 255 bytes
  4. XFS
  5. btrfs
  6. VMFS
  7. ZFS 등

 

 

logorealfinal

아치 리눅스 – pacman.conf 수정

7a9cb-13zj0sqjigkmcfohq0u2h5w

$sudo nano /etc/pacman.conf

color 주석 제거

-자동으로 색 적용

 

VerbosePkgLists 주석 제거

-업데이트 할 때 이전 버전, 업데이트 할 버전, 용량 등을 표 형식으로 출력.

-설치를 할 때 설치될 버전, 용량 등을 표 형식으로 출력

 

logorealfinal

아치 리눅스 – reflector 사용법

7a9cb-13zj0sqjigkmcfohq0u2h5w

reflector는 미러리스트를 관리하기 수월하게 해주는 프로그램입니다.

$sudo pacman -S reflector

 

부디 기존의 미러리스트를 백업해두시고 활용하시기 바랍니다.

$sudo cp /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.bak
$sudo reflector --verbose --latest 200 --sort rate --save /etc/pacman.d/mirrorlist

최근 동기화된 미러리스트 200개중에서 다운로드 속도로 정렬해줍니다. 시간이 조금 걸립니다.

옵션 :

–verbose : 내용 출력

–latest 숫자 : 가장 최근 동기화된 숫자 개수 중에서

–sort : 구분 기준을

–rate : 핑 속도로

–save : 저장. 경로는

/etc/pacman.d/mirrorlist : /etc/pacman.d에 mirrorlist이름으로

$nano /etc/pacman.d/mirrorlist

확인해봅니다.

logorealfinal

리눅스에서 Shell 환경, ‘>’와 ‘>>’의 차이

linuxlogo

‘~/Documetns/test.txt’ 파일이 있다고 가정합시다.

‘test.txt’ 에는 이런 내용을 적어두었습니다.

for test

ABC &

123

 


먼저, 아래의 명령어를 실행해 보면,

$echo 'Something' > ~/Documents/test.txt

다시 파일을 열어보겠습니다.

Something

‘echo’로 주어진 내용이 ‘test.txt’의 내용을 모두 삭제하고 적혀 있습니다.

‘>’를 한개만 사용했을 때에는 파일명이 이미 존재할 경우 파일의 (기존 내용을 지운 후)내용을 덮어쓰기합니다.(Overwrite) / 파일명이 존재하지 않을 경우, 파일을 생성 후 내부에 쓰입니다.


반면,

$echo 'Something' >> ~/Documents/test.txt

위 명령어를 실행후 ‘test.txt’를 열어보면

for test

ABC &

123

Something

맨 아래에 ‘echo’로 주어진 내용이 추가된 것을 볼 수 있습니다.

‘>>’로 두개를 사용할 겅우, 파일명이 이미 존재하면 내용을 추가합니다.(Append) / 파일명이 존재하지 않을 경우, 파일을 생성 후 내부에 쓰입니다.

logorealfinal