리눅스 배포판 선택에 대한 잡담

리눅스 배포판이 문제?

리눅스 사용자들이 어떤 배포판을 선택할지 고민하는 경우가 많기 때문에 약간의 고민을 덜어 주고 싶다. 리눅스 관련 커뮤니티에 올라온 질문 들 중에 이런 내용들을 보면 좀 답답하게 느낄 때가 있어서이다. "우분투에서는 WIFI가 잘 되는데 페도라에서는 안된다." "페도라에서는 한글입력이 잘 되는데 우분투에서는 안된다." 또는, "Gnome Shell에서는 한글입력이 잘 되는데 KDE에서는 안된다." 더구나 그 결론이 잘 되는 배포판이나 Dektop으로 갈아타야겠다고 할 때가 많다는 것이다.

기본적으로 동일한 PC 환경에서 특정 배포판 또는 Desktop 환경에서는 잘 되는데 다른 배포판이나 Desktop 환경에서 안되는 이유는 패키지 설치 방법이나 설정 방법이 조금씩 다르기 때문이다. 그러니까, 단지 이런 류의 문제들 때문에 배포판이나 Desktop을 바꾸는 것은 시간 낭비라는 것을 말해 주고 싶다.

나의 경우에, 다른 배포판이나 Desktop을 설치하는 주된 이유는 새로운 기능을 빨리 접해 보고자 할 때이다. 물론, 이외에도 PC 사양, 시스템 안정성이나 편리성, 시스템 보안, 특별한 리눅스 사용 목적, Desktop에 대한 Design 등도 배포판이나 Desktop 선택에 대한 주요 이유가 된다.

리눅스 배포판 들...

우선, DistroWatch에서 배포판에 대한 Page 방문 통계 순위를 제공하는데, 어느 정도 신뢰할 수 있기 때문에 여기를 참고하면 괜찮은 배포판을 선택할 수 있다. Top 5까지는 국내 사용자들도 많기 때문에 문제가 생겼을 때 도움을 얻을 수 있다. 리눅스 배포판들은 역사적으로 특정 시점에 인기 있는 배포판을 기반으로 이를 개선해서 새로운 배포판이 탄생한 경우가 많기 때문에 족보를 갖고 있다고 볼 수 있다. 주요 배포판 중에 Debian이나 Redhat, OpenSuse, Slackware 등은 고조 할배 뻘이 된다. Ubuntu는 Debian에서 분기했는데 Mint나 elementary OS 등 자식들을 많이 두고 있다. Fedora는 CentOS와 함께 Redhat에서 갈라져 나왔다. 같은 할배 밑의 자손들은 리눅스 명령이 거의 비슷하고 대체로 binary 호환성도 유지된다. 할배가 다르면 리눅스 기본 명령은 대부분의 Unix 계열 명령과 거의 같지만, 명령 자체가 다른 경우가 많고 binary 호환성도 보장 받지 못한다. 또한, 기본 명령조차도 배포판에 따라 실행 결과가 조금씩 다를 수도 있다.

그리고, 할배가 낫냐 손자가 낫냐 따지는 것도 큰 의미는 없다. 할배를 개선해서 손자가 탄생했지만, 할배도 계속 Upgrade하면서 새로운 것들을 받아 들이기 때문이다. 더구나, 기본 패키지들은 할배의 저장소에서 가져 오는 경우가 많기 때문에 손자의 S/W 버전이 할배 보다 낮은 경우도 많다. 대부분의 리눅스 배포판들은 부모 배포판이 버전 업되고 나서야 자식 배포판이 버전 업된다.

리눅스 Desktop 환경 들...

리눅스 배포판 내에서도 Desktop(GUI) 환경에 따라서 또 사용자가 나뉜다. Desktop 환경에 따라서 리눅스에 대한 Look & Feel이 달라질 수 있고, GUI 애플리케이션도 조금씩 다르다. Ubuntu만 해도 기본 Desktop인 Unity외에 Gnome Shell, KDE(Kubuntu), XFCE(Xubuntu), LXDE(Lubuntu), Mate, Cinnamon, Panthon... 등등을 사용할 수 있다. Desktop 환경도 대부분의 경우에는 다른 리눅스 배포판에서도 사용할 수 있다. 예를 들어, Gnome Shell은 페도라의 기본 Desktop 환경이고, KDE나 Mate 등을 페도라에서도 사용할 수 있다. 더구나, 한 배포판 내에서 여러가지 Desktop 환경을 동시에 설치해서 사용할 수 있다.

다만, 특정 Desktop 환경에서 다른 Desktop 환경의 애플리케이션을 사용할 목적이라면 굳이 여러개의 Desktop을 설치할 필요도 없다. 해당 애플리케이션의 패키지를 그냥 설치해서 사용하면 된다. 가령, Gnome Shell에서 KDE 애플리케인션인 Okular만 설치해서 사용할 수 있다. 물론, Gnome은 GTK 라이브러리 기반이고 KDE는 Qt 라이브러리 기반이기 때문에 Okular를 설치하면 필요한 Qt 라이브러리 들이 같이 설치된다.

도찐개찐

하지만, 궁극적으로 내가 하고 싶은 얘기는 리눅스 배포판 들은 개콘 코너에서 얘기하듯이 도찐개찐이라는 것이다. 할배 배포판들까지 포함해서 하는 얘기다. 가령, 우분투에서 Gnome Shell을 쓰는 것과 페도라에서 Gnome Shell을 쓰는 것은 겉보기에 아무런 차이가 없다. GUI 애플리케이션들은 Desktop 환경이 동일하면 리눅스 배포판과 상관없이 거의 동일하다. 다만, 리눅스 배포판의 차이에 따른 명령어들은 다르다. 가장 차이가 많이 나는 부분은 Package 관련 명령들인데 이것을 빼면 대부분의 명령이나 애플리케이션 들은 거의 동일하다.

근본적으로 리눅스 kernel이나 H/W 드라이버 들은 똑같다. 특정 배포판에서 H/W가 동작하는데 다른 배포판에서 동작하지 않을 확률은 거의 0에 가깝다. 기본 S/W나 애플리케이션들도 Open Source이기 때문에 대부분의 경우 특정 배포판에서만 안되는 일은 거의 없다고 봐도 무방하다.

리눅스 배포판/Desktop 추천

뭐, 리눅스 커뮤니티에 기여하기 위해 일부러 리눅스 배포판이나 Desktop 환경을 바꾸는 사람들에게는 감사해야겠지만, 단지 어떤 것이 예뻐 보인다는 이유만으로 바꾸는 사람들에게는 맘에 드는 한가지를 선택해서 정착하라는 것이 결론이다.

가령, 우분투 자손인 elementary OS는 무겁지도 가볍지도 않은 중간 쯤의 Desktop 환경인 Pantheon Desktop 환경을 사용하는데 보기는 좋으나 여러가지 불편함을 감수해야 한다. 그래서, 일반 사용자에게 우분투는 가장 무난한 배포판이고 Desktop 환경은 개인적인 선호도가 있기 마련이니까 Unity, Gnome Shell, KDE 셋 중에 하나를 추천한다. Netbook과 같이 PC 사양이 너무 낮은 경우(Mobile CPU, RAM 2GB 미만)에 한해서 리눅스 GUI를 사용하고자 할 경우에는 어쩔수 없이 Mate, LXDE/LXQt, XFCE 등을 권한다.

리눅스 Desktop 환경의 성능은 CPU가 특별히 매우 낮은 사양이 아니라면 RAM 용량에 의존하는데, 그래봤자 가장 무거운 Unity와 가벼운 편인 Mate하고 비교하면 최대 500MB 정도 밖에 차이나지 않는다. RAM이 4GB이상이면 Virtualbox로 다른 guest OS를 설치해도 큰 문제는 없다.

Ubuntu 15.04 systemd 부팅 시간 줄이기

systemd 매번 부팅시마다 fsck 검사하는 문제

우분투 15.04부터 본격적으로 systemd를 채택했으니 여기에 적응할 필요가 생겼다. 기본적으로 매번 부팅할 때마다 fsck가 파티션 별로 file system check를 하다보니 10초 정도를 허비하고 있다는 것을 알았기 때문이다. Ctrl-C로 취소할 수 있다고 메시지가 뜨지만 실제로 Ctrl-C도 동작하지 않는다. 이 두 가지 문제 중에서 첫번째만 해결되면 Ctrl-C가 동작하지 않아도 큰 문제는 없다.

systemd에서는 부팅 후 터미널에서 아래의 명령으로 부팅 시 소요 시간과 서비스(systemd unit service)별 병목 구간을 알 수 있다.

$ systemd-analyze
$ systemd-analyze blame
$ systemd-analyze critical-chain

예전에 fsck 주기를 mount 횟수나 일정 시간 간격으로 설정할 수 있었던 기억이나서 tune2fs를 가지고 별짓을 다 해 보아도 부팅시 fsck가 파일시스템 검사하는 것을 막을 방법이 없었다. 구글링으로 찾은 방법은 /etc/fstab 파일에서 <Pass> 파라미터를 0으로 바꿔주면 해당 파티션은 fsck 검사를 하지 않는다는 것이다. 모든 파티션에 대해 파라미터를 0으로 수정하고 재부팅하니, 과연 10초 정도 부팅속도가 빨라졌다. 뭐 이 방법도 나쁜 방법은 아니지만, fsck를 고생해서 쓰라고 우분투에 넣었는데 안쓰는 것도 좀 미안한 생각도 들고, 왠지 가끔씩은 돌려야 할 것 같아서 더 좋은 방법을 찾아 보기로 했다.

e2fsck time-stamp 문제

우분투 관련 사이트에는 systemd 사용역사가 짧아서인지 문제점을 지적한 글을 찾을 수 없다. 역시, systemd를 처음 채택한 Fedora 관련 사이트에서 이 두가지 문제에 대한 글들을 찾을 수 있었다. fsck 버그란 얘기도 있고 fsck time-stamp 때문이란 얘기도 있다. 실제로 아래의 명령으로 fsck time-stamp 문제가 발생하는 것을 확인할 수 있었다.

$ journalctl | grep -i fsck

May 23 17:20:10 localhost.localdomain systemd-fsck[278]: ROOTFS: Superblock last write time is in the future.
May 23 17:20:10 localhost.localdomain systemd-fsck[278]: (by less than a day, probably due to the hardware clock being incorrectly set). FIXED.

또, 아래 명령으로 리눅스 ext 파티션의 mount와 최종 fsck 시간을 확인할 수 있는데 UTC time으로 로그가 찍힌다.

$ sudo tune2fs -l /dev/sda8

가만히 생각해 보니, Windows와 Ubuntu의 시간을 맞추기 위해 /etc/default/rcS 파일에서 UTC=yes 설정을 UTC=no로 바꾸었다는 것을 깨닫게 됐다. 이 설정은 컴퓨터 내장 시계의 시간 기준이 UTC인지 local time인지를 부팅시에 알려 준다. 추정컨대, H/W clock이 local time으로 설정되어 있어서 fsck 검사시에 local time으로 최종 시간을 파일시스템에 저장했는데 다시 fsck 검사할 때는 이것이 UTC time이라고 생각하기 때문에 발생하는 문제인 듯 싶다. 즉, 우리나라 local time인 KST = GMT+09로 UTC 시간 보다 9시간이 빠르다. 참고로, 시간 설정에 대한 정보는 아래의 명령으로 확인할 수 있다.

$ timedatectl status
$ sudo hwclock --show

문제 해결?

아무튼 /etc/default/rcS 파일을 원래대로 UTC=yes로 저장하고 재부팅했더니 파일시스템 검사 시간이 줄어 들었다. 검사 시간이 줄어드는 정도로는 안되고 아예 검사를 하지 말아야 한다. journalctl 명령으로 확인해 보니, EFI System Partition(ESP)에 대해서만 fsck가 파일시스템 검사를 했음을 알 수 있었다. ESP는 vfat 파일시스템이므로 fsck 검사시간 정보 등을 저장할 수 없다. 예외적으로 이 놈에 대해서만 /etc/fstab의 <Pass> 파라미터를 0으로 설정하기로 하였다. 이 후로 몇번 재부팅해봤는데 더이상 fsck가 돌지 않아서 부팅시간이 10초 정도 빨라졌다.

vfat 빼고는 생기지도 않았을 문제를 해결했다니 느낌이 좀 이상하네...

systemd 부팅 시간 쬐금 더 줄이기

systemd에서는 서비스들을 unit 단위로 관리한다. unit 간에 의존성이 있을 수도 있다. 일단 아래의 명령으로 현재 서비스 unit과 상태를 확인할 수 있다. 상태는 enabled, static, disabled, masked의 4가지가 있을 수 있는데, static은 다른 unit과 의존 관계가 있다고 이해하면 될 듯하다. masked는 disable 시킨건 아니지만 의존 관계를 유지하면서 해당 unit만 disable 시키는 방법인 듯하다. 물론, 부팅 후 특정 서비스 unit을 stop하거나 start 할 수도 있다.

$ systemctl list-units --type service
$ systemctl list-unit-files --type service

그리고, systemd 서비스 unit을 부팅시에 동작하지 않도록 하거나, 다시 동작하도록 하려면 아래의 명령을 사용하면 된다.

$ sudo systemctl disable <unit 명>
$ sudo systemctl enable <unit 명>

앞서 systemd-analyze blame 명령에서 서비스 unit 별로 실행시간 profile을 알 수 있는데 시간이 오래 걸리는 놈들 중 불필요한 서비스 unit을 disable 시키면 된다. 아래 두 놈을 시범삼아 제거해 보았다. 참고로, fsck의 경우도 systemd-fsck@.service를 disable 시킬 수도 있지만 다른 unit와 의존관계가 있었고 아래 두 놈은 의존관계가 없어 보였다.

$ sudo systemctl disable ModemManager.service
$ sudo systemctl disable bluetooth.service

결론

위의 두 놈을 제거후 재부팅했더니 5초 정도 부팅시간이 빨라졌다. fsck까지 포함해서 15초를 절약하게 됐다. 그래서 총 부팅시간이 35초에서 20초 정도로 줄었다는 것이 결론이다. 뭔가 허무한 느낌... 더구나 애초에 /etc/default/rcS 파일을 건드리지 않았으면 fsck에 대한 10초도 빨라진게 아니라는... ㅠ.ㅠ

참고 사항

위에서 우분투 H/W 시간 기준을 UTC로 바꾸고 Windows로 부팅하면 Windows에서는 그 시간을 local time이라고 해석하기 때문에 시간이 UTC time으로 바뀌어 9시간 느린 시간이 표시될 수 있다. 특히, NTP time 서버와 동기화 되지 않을 때 이 문제가 생기는데 Windows Scheduler에서 NTP 서버 동기화 작업을 걸어 주거나, Windows에서도 H/W 시계의 시간 기준이 UTC라고 알려 주는 방법도 있단다. Mac OS X의 경우에는 Unix 계열이므로 리눅스와 마찬가지로 timezone으로 시간을 설정하므로 시간 불일치 문제는 발생하지 않는다.

Syntax Highlighter 구 버전으로 회귀

구관이 명관이라는 말이 실감난다. 최신 버전의 Syntax Highlighter를 이 블로그에 적용했었는데 구 버전으로 회귀해야했다. 신 버전은 테마를 사용할 수 있어 깔끔하고, 원저자의 사이트 링크들만 블로그 Template에 복사하면 되었기에 구글 블로그에 적용하기가 매우 편리하다.

그런데, 어제 저녁에 갑자기 내 블로그에 접속이 안되는 일이 발생했다. www.blogger.com에는 접속이 되는데 내 블로그에는 접속이 안되는 황당한 상황이었는데 Firefox가 원인을 알려 주었다. 내 블로그에 접속하려면 Syntax Highlighter 사이트를 거쳐와야 했는데 거기에 접속이 안되니까 내 블로그에도 접속이 안되는 상황이 발생한 것이다. 해킹을 당한건지 서버가 망가진건지 알 수 없지만 지금도 해당 사이트로는 접속이 안된다.

내 발등에 떨어진 불을 끄기 위해 신버전의 Syntax Highlighter를 걷어내야 했다. 그리고 구버전을 설치했다. 구 버전에서도 링크를 병행해서 사용해야 하지만 syntaxhighlighter.googlecode.com 링크를 사용하기 때문에 상대적으로 안전하다. 문제는 구버전과 신버전 tag가 달라서 예전에 올린 글들을 일일이 수정해야 하는데 귀찮아서 모두 수정할수 있을지 장담하기 어렵다.

요즘 알게 모르게 Cloud 환경을 많이 사용하고 있는데 구글 같은 대형 사이트가 아니면 언제든지 유사한 일을 당할 수가 있다. 뭐, 구글같은 사이트도 정책이 바뀔 수도 있으니 아무튼 미래에도 Cloud 환경이 안전하다고 맹신하면 안될 것이다. 전에 iPhone을 애들이 갖고 놀다가 비밀번호를 바꿨는데 기억을 못하는 바람에 iOS부터 새로 설치해야 했던 적이 있는데 다행히 iCloud를 사용하고 있어서 중요한 데이터가 거의 완벽히 복구된 적이 있었다. 그런 면에서 Cloud 환경이 편리한 것도 사실이다. 하지만, Syntax Highlighter 문제와 같이 Cloud 환경의 위험성에 대해서도 경각심을 가져야 할 것이다.

구 버전의 Syntax Highlighter 설치 방법은 stackoverflow.com에 올라와 있는데 Backup 차원에서 이 글에 다시 남긴다.

1. 먼저, blogger template을 백업

2. http://syntaxhighlighter.googlecode.com/svn/trunk/Styles/SyntaxHighlighter.css의 파일 내용을 </b:skin> tag 앞에 복사

3. 아래 내용을 </head> tag 앞에 복사: 필요한 brush 파일만 선택

<script src='http://syntaxhighlighter.googlecode.com/svn/trunk/Scripts/shCore.js' type='text/javascript'></script>
<script src='http://syntaxhighlighter.googlecode.com/svn/trunk/Scripts/shBrushCpp.js' type='text/javascript'></script>
<script src='http://syntaxhighlighter.googlecode.com/svn/trunk/Scripts/shBrushCSharp.js' type='text/javascript'></script>
<script src='http://syntaxhighlighter.googlecode.com/svn/trunk/Scripts/shBrushCss.js' type='text/javascript'></script>
<script src='http://syntaxhighlighter.googlecode.com/svn/trunk/Scripts/shBrushDelphi.js' type='text/javascript'></script>
<script src='http://syntaxhighlighter.googlecode.com/svn/trunk/Scripts/shBrushJava.js' type='text/javascript'></script>
<script src='http://syntaxhighlighter.googlecode.com/svn/trunk/Scripts/shBrushJScript.js' type='text/javascript'></script>
<script src='http://syntaxhighlighter.googlecode.com/svn/trunk/Scripts/shBrushPhp.js' type='text/javascript'></script>
<script src='http://syntaxhighlighter.googlecode.com/svn/trunk/Scripts/shBrushPython.js' type='text/javascript'></script>
<script src='http://syntaxhighlighter.googlecode.com/svn/trunk/Scripts/shBrushRuby.js' type='text/javascript'></script>
<script src='http://syntaxhighlighter.googlecode.com/svn/trunk/Scripts/shBrushSql.js' type='text/javascript'></script>
<script src='http://syntaxhighlighter.googlecode.com/svn/trunk/Scripts/shBrushVb.js' type='text/javascript'></script>
<script src='http://syntaxhighlighter.googlecode.com/svn/trunk/Scripts/shBrushXml.js' type='text/javascript'></script>

4. 아래 내용을 </body> tag 앞에 복사

<script language='javascript'>
dp.SyntaxHighlighter.BloggerMode();
dp.SyntaxHighlighter.HighlightAll('code');
</script>

5. blogger template 저장

6. 사용 방법은 아래와 같이 <pre name="code" class=cpp></pre> tag 사용

<pre name="code" class="cpp">
int x = 0, y = 10;
</pre> 

7. 사용 가능한 Brush class: cpp, csharp, css, delphi, java, js, php, python, ruby, sql, vb, xml