[{"content":"Preface 핸드북에서 명시하듯 23년 12월 부로, 젠투에서 바이너리 패키지 설치를 공식 지원합니다.\n이번 업데이트에 따라 VPS에 새로운 젠투 머신을 설치하며 과정에서 바이너리 패키지를 사용하는 방법을 정리합니다.\nbinrepos.conf 이제 /etc/portage/repos.conf/gentoo.conf와 더불어, 바이너리 패키지를 위한 /etc/portage/binrepos.conf/gentoo.conf를 작성합니다. (예시에서는, 카이스트 미러를 활용합니다)\n[binhost] priority = 9999 sync-uri = http://ftp.kaist.ac.kr/gentoo/releases/amd64/binpackages/17.1/x86-64/ Make binary default 기본값으로 바이너리 패키지를 설치하고자 하시는 분들은 /etc/portage/make.conf에 해당 설정을 추가합니다.\nFEATURES=\u0026#34;${FEATURES} getbinpkg\u0026#34; Emerge 이제 portage 패키지 매니저에서 바이너리 패키지 관련 옵션을 제공합니다.\n--getbinpkg, -g: 원격 바이너리 패키지 호스트로부터 바이너리 패키지를 다운로드. 찾을 수 없는 경우 일반(소스-베이스) 패키지를 다운로드합니다 --getbinpkgonly, -G: --getbinpkg, -g와 유사하지만 바이너리 패키지를 찾을 수 없는 경우 실패함. Error: OpenPGP signing and verification fail 이전 후 첫 패키지 설치 과정에서, 무결점 확인 오류가 발생하는 경우가 있습니다.\n로컬 환경의 신뢰할 수 있는 GnuPG, OpenPGP 키를 업데이트하는 소프트웨어 getuto를 실행하여 해결합니다.\n# getuto 부가적인 사항은 해당 위키 페이지에서 확인하시기 바랍니다.\n","permalink":"http://ptrtoj.com/kr/gentoo-binary/","summary":"\u003ch2 id=\"preface\"\u003ePreface\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://wiki.gentoo.org/wiki/Handbook:AMD64/Installation/Base#Optional:_Adding_a_binary_package_host\"\u003e핸드북\u003c/a\u003e에서 명시하듯\n23년 12월 부로, 젠투에서 바이너리 패키지 설치를 공식 지원합니다.\u003c/p\u003e\n\u003cp\u003e이번 업데이트에 따라 VPS에 새로운 젠투 머신을 설치하며 과정에서 바이너리 패키지를 사용하는 방법을 정리합니다.\u003c/p\u003e","title":"젠투 리눅스 바이너리 패키지"},{"content":" This is a translated work. The original post was written by Julia Evans and you can read it here. On 03, Nov. 2023, permission was granted via e-mail.\n이 문서는 번역본입니다. 원본은 줄리아 에반스(Julia Evans)에 의해 작성되었으며, 다음 링크를 통해 읽을 수 있습니다.이메일을 통해 23/11/03 번역 허가를 받아 작성 후 업로드 합니다.\n주요 개념, 명령어나 명령어 출력은 독자의 오해를 방지하기 위해 한국어와 영어를 병기합니다\nImportant concepts, commands or outputs are written in both Korean AND English, so readers can avoid misunderstanding\n안녕하세요! 저는 Git을 설명하기 위한 작업을 진행 중입니다. 15년간 Git을 사용하는 과정에서 생긴 제게 가장 큰 문제라면, Git의 특이한 점에 대해 너무 익숙해져 어떤 점들이 헷갈리는지 잊기 쉽다는 점입니다.\n따라서 저는 Mastodond을 통해 사람들에게 질문을 남겼습니다:\n어떤 Git 용어들이 헷갈리나요? Git의 요상한 용어 사용에 대한 블로그 포스트를 작성할까 생각 중입니다: \u0026ldquo;떼어진 HEAD 상태(detached HEAD state)\u0026rdquo;, \u0026ldquo;패스트-포워드(fast-forward)\u0026rdquo;, \u0026ldquo;인덱스/스테이징 구역/스테이지됨(index/staging area/staged)\u0026rdquo;, \u0026ldquo;\u0026lsquo;원격/메인\u0026rsquo;보다 1 커밋 앞서있음(ahead of ‘origin/main’ by 1 commit)\u0026rdquo;, 등\n저는 많은 훌륭한 답들을 받을 수 있었으며 일부를 여기에 요약하고자 합니다. 요약하는 용어들은 아래와 같습니다:\nHEAD와 \u0026ldquo;헤드들(heads)\u0026rdquo; \u0026ldquo;떨어진 HEAD 상태(detached HEAD state)\u0026rdquo; 머지(merge), 리베이스(rebase) 과정에서 \u0026ldquo;우리쪽(ours)\u0026ldquo;과 \u0026ldquo;저쪽(theirs)\u0026rdquo; \u0026ldquo;당신의 브랜치는 \u0026lsquo;원격/메인\u0026rsquo; 최신 상태입니다(Your branch is up to date with ‘origin/main’)\u0026rdquo; HEAD^, HEAD~ HEAD^^, HEAD~~, HEAD^2, HEAD~2 .. 와 \u0026hellip; \u0026ldquo;패스트 포워드 가능(can be fast-forwarded)\u0026rdquo; \u0026ldquo;레퍼런스(reference)\u0026rdquo;, \u0026ldquo;심볼릭 레퍼런스(symbolic reference)\u0026rdquo; refspecs \u0026ldquo;tree-ish\u0026rdquo; \u0026ldquo;인덱스(index)\u0026rdquo;, \u0026ldquo;스테이지됨(staged)\u0026rdquo;, \u0026ldquo;캐시됨(cached)\u0026rdquo; \u0026ldquo;리셋(reset)\u0026rdquo;, \u0026ldquo;되돌림(revert)\u0026rdquo;, \u0026ldquo;복원(restore)\u0026rdquo; \u0026ldquo;트랙되지 않는 파일(untracked files)\u0026rdquo;, \u0026ldquo;원격-트래킹 브랜치(remote-tracking branch)\u0026rdquo;, \u0026ldquo;원격 브랜치 트래킹하기(track remote branch)\u0026rdquo; 체크아웃(checkout) reflog 머지(merge) vs 리베이스(rebase) vs 체리픽(cherry-pick) rebase -onto 커밋(commit) 추가 헷갈리는 용어들 이런 용어들을 설명하고자 최선을 다했으나 사실상 이 용어들이 각각 Git의 주요 기능들에 해당하다보니 하나의 블로그 포스트에 담기에는 너무 양이 많아 일부 설명은 간략할 수 있습니다.\nHEAD와 “헤드들(heads)” 적지 않은 사람들이 HEAD라든지 refs/heads/main과 같은 용어를 혼란스럽다고 했습니다. 이런 용어들이 너무 복잡하고 기술적인 내부 작업을 표현하는 것처럼 들리기 때문인데요.\n핵심 요약은 이렇습니다:\n\u0026ldquo;헤드들(heads)\u0026ldquo;은 \u0026ldquo;브랜치들(branches)\u0026ldquo;입니다. Git 내부적으로, 브랜치들은 .git/refs/heads로 불리는 디렉터리에 저장됩니다.(기술적으로는, 공식 깃 용어집에 따르면, 브랜치란 해당 브랜치에 있는 모든 커밋(commit)이며 헤드는 그 중 가장 최근의 커밋일 뿐입니다. 같은 것을 표현하는 2가지의 다른 방법이 있는 거죠) HEAD는 현재 브랜치입니다. .git/HEAD에 저장되어 있습니다. 제 생각에 \u0026ldquo;head는 하나의 브랜치이며, HEAD는 현재 브랜치이다\u0026quot;는 문장이 Git이 선택한 용어 중 가장 이상한 것 후보가 될만 합니다. 그러나 지금으로써는 이미 더 명확한 이름으로 변경하기엔 확실히 너무 늦어버렸으니 그냥 넘어가죠.\n\u0026ldquo;HEAD는 현재 브랜치다\u0026quot;라는 문장에는 일부 중요한 예외가 있습니다. 이는 이후 설명하도록 하겠습니다.\n“떨어진 HEAD 상태(detached HEAD state)” 여러분은 이런 메시지를 봤을 겁니다:\n$ git checkout v0.1 You are in \u0026#39;detached HEAD\u0026#39; state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by switching back to a branch. [...] $ git checkout v0.1 현재 \u0026#39;HEAD와 분리된\u0026#39; 상태에 있습니다. 파일들을 확인해 실험적인 변경을 수행하고 커밋하시기 바랍니다. 이 상태에서 수행한 커밋들은 브랜치로 돌아오는 과정에서 다른 브랜치들에 어떤 영향도 끼치지 않고 버릴 수 있습니다. [...] 이 메시지를 이해하는 방법입니다:\nGit에서는 일반적으로, 가령 main과 같이, \u0026ldquo;현재 브랜치\u0026quot;로 체크 아웃된 상태다. 현재 브랜치가 저장된 곳은 HEAD로 불린다. 작성한 새로운 커밋은 모두 현재 브랜치에 추가되며 git merge other_branch 명령을 수행한다면 이것도 현재 브랜치에 영향을 끼친다. 그런데 HEAD는 브랜치일 필요는 없다. 대신 커밋 ID일 수 있다. Git은 이런 상태(즉, HEAD가 브랜치가 아니라 커밋 ID인 상태)를 \u0026ldquo;떨어진 HEAD 상태\u0026quot;로 부른다. 예를 들어, 태그로 체크 아웃 함으로써 떨어진 HEAD 상태에 들어설 수 있는데, 이는 태그가 브랜치가 아니라서 가능하다. 현재 브랜치가 없다면, 여러가지가 고장난다: git pull은 전혀 동작할 수 없다(이는, 명령어의 존재 목적 자체가 현재 브랜치를 업데이트 하는 것이기 때문) 또한 git push도 특이한 방식으로 사용하지 않는한 동작하지 않는다 git commit, git merge, git rebase, git cherry-pick은 의외로 잘 작동하지만 이런 명령어들은 어떤 브랜치와도 연결되어 있지 않은 \u0026lsquo;고아(orphaned)\u0026rsquo; 커밋 상태로 남게 만들기 때문에 해당 커밋들을 찾기 어렵게 만든다 떨어진 HEAD 상태로부터 벗어나기 위해서는 새로운 브랜치를 만들거나 존재하는 브랜치로 스위치 하는 방법이 있다. 머지(merge), 리베이스(rebase) 과정에서 “우리쪽(ours)”과 “저쪽(theirs)” 머지(merge) 과정에서 충돌(conflict)이 발생하면, git checkout --ours file.txt 같은 명령을 수행해 \u0026ldquo;우리쪽(ours)\u0026ldquo;에서 file.txt의 버전을 고를 수 있습니다. 그런데 뭐가 \u0026ldquo;우리쪽(ours)\u0026ldquo;이고 뭐가 \u0026ldquo;저쪽(theirs)\u0026ldquo;일까요?\n저도 이 부분이 항상 혼란스러웠기 때문에 git checkout --ours 명령은 절대 사용하지 않습니다. 그러나 뭐가 뭔지 이번에 찾아봤습니다.\n일단 머지의 작동 방식은 이렇습니다: 현재 브랜치는 \u0026ldquo;우리쪽\u0026quot;이고 머지 해올 브랜치가 \u0026ldquo;저쪽\u0026quot;입니다. 합리적인데요.\n$ git checkout merge-into-ours # 현재 브랜치가 \u0026#34;우리쪽\u0026#34; $ git merge from-theirs # \u0026#34;저쪽\u0026#34;으로부터 머지함 리베이스는 이와 반대입니다 - 현재 브랜치가 \u0026ldquo;저쪽\u0026quot;이고 리베이스를 진행하는 타겟 브랜치가 \u0026ldquo;우리쪽\u0026rdquo; 입니다:\n$ git checkout theirs # 현재 브랜치가 \u0026#34;저쪽\u0026#34; $ git rebase ours # \u0026#34;우리쪽\u0026#34;을 리베이스함 제 생각에 이런 식으로 작동하는 이유는, 내부에서 git rebase main이 현재 브랜치를 메인에 머지하기 때문으로 보입니다 (마치 git checkout main; git merge current_branch처럼). 그러나 여전히 혼란스러다고 느낍니다.\n이 사이트가 \u0026ldquo;우리쪽\u0026quot;과 \u0026ldquo;저쪽\u0026rdquo; 용어를 설명하고 있습니다.\n몇몇 사람들이 VSCode에서는 \u0026ldquo;ours\u0026rdquo;/\u0026ldquo;theirs\u0026quot;를 \u0026ldquo;현재 변화\u0026rdquo;/\u0026ldquo;들어오는 변화\u0026quot;로 부른다는 점을 언급했는데, 이 역시 같은 방식으로 헷갈립니다.\n“당신의 브랜치는 ‘원격/메인’ 최신 상태입니다(Your branch is up to date with ‘origin/main’)” 이 메시지는 직관적인 것처럼 보입니다 - 당신의 main 브랜치가 원격(origin)에 최신화,동기화 되어있다는데요!\n그러나 여기엔 약간의 오해 소지가 있습니다. 이 메시지를 여러분의 main 브랜치가 최신화되어있다는 뜻으로 생각할 수 있습니다. 그러나 그렇지 않습니다. 이것이 실제로 의미하는 바는 - 예를 들어 여러분이 git fetch 또는 git pull을 5일 전에 수행했다고 가정했을 때, 여러분의 main 브랜치가 그 5일 전 변화에 최신화 되어 있다는 의미입니다.\n따라서 이를 깨닫지 못하면, 보안상 안전하다는 잘못된 판단을 하게 만듭니다.\n제 생각에 이론적으로는 Git이 여러분에게 \u0026ldquo;당신의 마지막 fetch였던 5일 전 원격(origin)의 main과 최신화되어 있음\u0026quot;같은 식의 유용한 메시지를 줄 수도 있어 보입니다. 왜냐하면 가장 마지막 수행한 fetch 시간이 reflog에 저장되기 때문인데요. 그런데 그러지 않네요.\nHEAD^, HEAD~ HEAD^^, HEAD~~, HEAD^2, HEAD~2 저는 오랫동안 HEAD^가 직전 커밋을 일컫는 다는 점을 알고 있었습니다. 그러나 HEAD~와 HEAD^의 차이에 대해서는 오랫동안 혼란스러워 했는데요.\n검색해보고 서로와 어떻게 관련되는지 정리했습니다:\nHEAD^와 HEAD~는 같음(1 커밋 전) HEAD^^^와 HEAD~~~, HEAD~3는 같음(3 커밋 전) HEAD^3은 커밋의 3번째 부모(parent)를 가리키며 HEAD~3과 다름 여기서 이상합니다 - 어째서 HEAD~와 HEAD^가 같은 걸까요? 그리고 \u0026ldquo;세 번째 부모\u0026quot;가 뭐죠? 혹시 부모의 부모의 부모와 같은 걸까요?(스포일러: 아닙니다) 살펴보죠!\n대부분의 커밋은 단 하나의 부모를 가집니다 그러나 머지 커밋(Merge commits)들은 다수의 부모를 갖습니다 -2개 이상의 커밋을 머지하기 때문이죠. Git에서 HEAD^란 \u0026ldquo;HEAD 커밋의 부모\u0026quot;를 말합니다. 그런데 여기서 만약 HEAD가 머지 커밋(merge commit)이라면 어떻게 될까요? HEAD^는 어떤 것을 가리키죠?\n답은 \u0026lsquo;HEAD^는 머지의 첫 번째 부모를 가리킨다\u0026rsquo;입니다. HEAD^2는 두 번째 부모를, 마찬가지로 HEAD^3는 세 번째 부모를 가리키죠.\n그런데 제가 추측하기로 \u0026ldquo;3 커밋 전\u0026quot;을 가리킬 수 있는 방법도 함꼐 원했던 것 같습니다. 따라서 HEAD^3는 현 커밋의 세 번째 부모(머지 커밋이라면 부모를 여럿 가질 수 있음)이며, HEAD~3은 부모의 부모의 부모를 가리키게 됩니다.\n제 생각에 앞서 진행된 머지 커밋 우리쪽/저쪽 논의에서의 맥락을 이어가자면 HEAD^는 \u0026ldquo;우리쪽\u0026rdquo;, HEAD^2는 \u0026ldquo;저쪽\u0026quot;이죠.\n..와 \u0026hellip; 여기 두 개의 명령어가 있습니다:\ngit log main..test git log main...test ..와 ...의 차이가 뭘까요? 저는 이것을 절대 사용하지 않다보니 git-range-diff 매뉴얼 페이지를 확인해봤습니다. 아래와 같은 경우에:\nA - B main \\ C - D test main..test는 커밋 C와 D입니다 test..main은 커밋 B입니다 main...test는 커밋 B, C, D입니다 이보다 더 복잡합니다: 확실히 git diff 역시 ..와 ...를 지원합니다. 그러나 여기서는 git log와 완전히 다른 방식으로 작동합니다. 요약하자면:\ngit log test..main은 main에 존재하는 변화지만 test에는 없는 것들을 보여줍니다. 반면, git log test...main은 양 쪽 변화를 모두 보여줍니다. git diff test..main은 test의 변화와 더불어 main의 변화도 보여줍니다(B와 D의 차이점을 보여줌). 반면, git diff test...main은 A와 D의 차이를 보여줍니다(한 쪽에 존재하는 차이점만 보여줌) 이 블로그 포스트가 조금 더 자세히 설명하고 있습니다.\n\u0026ldquo;패스트 포워드 가능(can be fast-forwarded)\u0026rdquo; 여러분이 git status의 출력(output)으로 흔하게 보시는 메시지입니다.\n$ git status On branch main Your branch is behind \u0026#39;origin/main\u0026#39; by 2 commits, and can be fast-forwarded. (use \u0026#34;git pull\u0026#34; to update your local branch) $ git status 브랜치 main에 있음 브랜치가 \u0026#39;원격/메인\u0026#39;으로 부터 2커밋 뒤쳐져있으며 패스트 포워드 가능. (\u0026#34;git pull\u0026#34;을 통해 로컬 브랜치를 업데이트 하시오) \u0026ldquo;패스트-포워드(fast-forward)\u0026ldquo;가 무슨 뜻일까요? 기본적으로 두 브랜치 상황이 아래와 같다는 것을 말하려고 하는 것입니다:(우측일수록 신규 커밋)\nmain: A - B - C origin/main: A - B - C - D - E 다른 방식으로 시각화하자면:\nA - B - C - D - E (origin/main) | main 여기서 origin/main에는 main이 갖고 있지 않은 2개의 여분 커밋이 존재합니다. 따라서, main을 최신화 하는 것은 쉽습니다 - 그 2개의 커밋을 추가하면 되죠. 말 그대로 어떤 것도 잘못될리가 없습니다 - 머지 충돌(merge conflict)이 발생할 확률도 없구요. 패스트 포워드 머지(fast forard merge)는 훌륭한 겁니다! 2개의 브랜치를 합치는 가장 쉬운 방법이죠.\ngit pull을 수행한 이후, 이런 상황이 됩니다:\nmain: A - B - C - D - E origin/main: A - B - C - D - E 그러나 아래는 패스트-포워드 할 수 없는 상황의 예시입니다.\nA - B - C - X (main) | - - D - E (origin/main) 여기서 main은 origin/main이 갖지 않은 (X) 커밋을 갖고 있습니다. 따라서 패스트 포워드를 진행할 수 없습니다. 이런 경우, git status는 다음과 같은 메시지를 내보냅니다:\n$ git status Your branch and \u0026#39;origin/main\u0026#39; have diverged, and have 1 and 2 different commits each, respectively. $ git status 브랜치가 \u0026#39;origin/main\u0026#39;으로부터 분화됨, 각각 1개 2개의 다른 커밋이 존재함. “레퍼런스(reference)”, “심볼릭 레퍼런스(symbolic reference)” 저는 항상 \u0026ldquo;레퍼런스(reference)\u0026ldquo;라는 용어를 헷갈린다고 생각했습니다. 아래는 git에서 \u0026ldquo;레퍼런스\u0026quot;가 가리키는 최소한 3가지의 용례입니다\nmain이나 v0.2와 같은, 브랜치와 태그 현재 브랜치를 의미하는, HEAD HEAD^^^ 따위의 git이 커밋 ID 처리를 위해 사용하는 것들. 기술적으로 이런 것들이 \u0026ldquo;레퍼런스\u0026quot;는 아닐 수 있으며, git은 이런 것들을 \u0026ldquo;수정 매개변수(revision parameters)\u0026ldquo;로 부르는 것으로 보이지만 저는 그런 용어를 사용해본적이 없습니다.\n\u0026ldquo;심볼릭 레퍼런스(symbolic reference)\u0026ldquo;는 굉장히 광범위한 용어 같습니다. 이는 제가 심볼릭 레퍼런스를 사용해 본 유일한 상황이 HEAD(현재 브랜치) 관련해서가 전부이기 때문인데요. 더욱이 HEAD는 git에서 상당히 핵심에 해당하다보니(git의 주요 명령어들의 연산은 대부분 HEAD 값에 의존한다) 이런 일반적인 컨셉을 갖고 있는 목적을 알 수 없네요.\nrefspecs 여러분이 .git/config에 있는 원격 저장소를 설정할 때, +refs/heads/main:refs/remotes/origin/main 같은 것을 볼 수 있습니다.\n[remote \u0026#34;origin\u0026#34;] url = git@github.com:jvns/pandas-cookbook fetch = +refs/heads/main:refs/remotes/origin/main 저는 이게 뭔 뜻이 진짜 모릅니다. 저는 그냥 git clone 혹은 git remote add 등을 수행하며 적힌 디폴트 값들을 사용해왔고, 이에 대해 더 자세히 배워야겠다든지 디폴트 값을 바꿔야겠다는 동기를 가졌던 적이 전혀 없습니다.\n\u0026ldquo;tree-ish\u0026rdquo; git checkout 매뉴얼 페이지에 따르면:\ngit checkout [-f|--ours|--theirs|-m|--conflict=\u0026lt;style\u0026gt;] [\u0026lt;tree-ish\u0026gt;] [--] \u0026lt;pathspec\u0026gt;... 그런데 tree-ish가 뭐죠??? git이 말하고자 하는 바는 git checkout THING .을 수행할 때, THING이란:\n커밋 ID(182cd3f 따위) 커밋 ID를 가리키는 레퍼런스(main 또는 HEAD^^, v0.3.2 따위) 커밋 내부의 서브디렉터리(main:./docs 따위) 이 정도인 듯???? 개인적으로 \u0026ldquo;커밋 내부의 디렉터리\u0026quot;는 사용해본 적이 없고 제가 봤을 때 \u0026ldquo;tree-ish\u0026quot;는 아마 \u0026ldquo;커밋 혹은 커밋 레퍼런스\u0026quot;를 의미하는 것 같습니다.\n“인덱스(index)”, “스테이지됨(staged)”, “캐시됨(cached)” 아래는 모두 정확히 같은 것을 가리킵니다(파일 .git/index, 이는 변경 사항이 git add를 통해 스테이지 되었을 때 생성됨):\ngit diff --cached git rm --cached git diff --staged .git/index 파일 궁극적으로 같은 파일을 가리키지만, 이런 용어들이 실제로 사용되는 다양한 용례가 있습니다:\n예상하시듯 --index와 --cached 플래그(flag)들은 일반적으로 같은 것을 의미하지 않습니다. 저는 개인적으로 --index를 전혀 사용해 본적이 없으며 따라서, 이를 더 자세히 설명하지 않을 생각입니다. 그러나 Junio Hamano의 블로그 포스트(git 리드 메인테이너)가 세부 사항을 모두 설명하고 있습니다. \u0026ldquo;인덱스\u0026quot;는 트래킹되지 않는 파일들을 목록화 합니다(아마도 성능 이유인 듯), 그러나 여러분은 일반적으로 \u0026ldquo;스테이징 구역(staging area)\u0026ldquo;가 \u0026ldquo;트래킹되지 않는 파일들\u0026quot;을 포함한다고 생각하지 않습니다 “리셋(reset)”, “되돌림(revert)”, “복원(restore)” 많은 분들이 \u0026ldquo;리셋(reset)\u0026rdquo;, \u0026ldquo;되돌림(revert)\u0026rdquo;, \u0026ldquo;복원(restore)\u0026ldquo;가 비슷한 단어이며 구분하기 어렵다고 언급하셨습니다.\n상황을 더욱 악화시키는 것은\ngit reset --hard와 git restore .가 각자 같은 일을 수행하기 때문입니다. (물론 git reset --hard COMMIT과 git restore --source COMMIT .의 경우에는 서로 완전히 다른 것이기는 함) 각각의 매뉴얼 페이지가 유용한 설명을 제공하지 못함: git reset: \u0026ldquo;현재 HEAD 상태를 특정 상태로 리셋함(reset)\u0026rdquo; git revert: \u0026ldquo;존재하는 커밋 일부를 되돌림(revert)\u0026rdquo; git restore: \u0026ldquo;작업중인 트리 파일들을 복원함(restore)\u0026rdquo; 위의 짧은 설명들을 통해 영향을 받는 대상이 무엇인지 파악할 수는 있지만(\u0026ldquo;현재 HEAD\u0026rdquo;, \u0026ldquo;일부 커밋\u0026rdquo;, \u0026ldquo;작업 중인 트리 파일들\u0026rdquo;) 여러분들이 이미 \u0026ldquo;reset\u0026rdquo;, \u0026ldquo;revert\u0026rdquo;, \u0026ldquo;restore\u0026quot;가 문맥상 무엇을 의미하는지 알고 있을 것으로 가정하고 있습니다.\n각각의 짧은 설명입니다:\ngit revert COMMIT: 현재 브랜치의 COMMIT의 \u0026ldquo;반대되는\u0026rdquo; 새로운 커밋을 작성함(만약 COMMIT이 3줄을 추가했다면, 새로운 커밋은 해당 3줄을 삭제함) git reset --hard COMMIT: 여러분의 현재 브랜치가 COMMIT 상태의 모습으로 돌아가도록 강제하며, COMMIT이후 생긴 모든 변화를 삭제함. 상당히 위험한 작업. git restore --source=COMMIT PATH: PATH 내의 모든 파일들을 COMMIT 당시 상태로 돌려놓음, 다른 파일들은 변화 발생하지 않으며 커밋 히스토리 역시 변화 없음. “트랙되지 않는 파일(untracked files)”, “원격-트래킹 브랜치(remote-tracking branch)”, “원격 브랜치 트래킹하기(track remote branch)” Git은 \u0026ldquo;트랙(track)\u0026ldquo;이라는 단어를 3가지의 서로 다르면서도 관련있는 방식으로 사용합니다:\ngit status의 출력에서 Untracked files:. 이는 해당 파일들을 Git이 관리하지 않고 있으며 커밋에 포함되지 않을 것임을 의미합니다. origin/main 따위의 \u0026ldquo;원격 트래킹 브랜치\u0026quot;에서 사용. 이는 로컬 레퍼런스이며, 마지막으로 여러분이 git pull 혹은 git fetch를 수행한 이후 main이 가리키는 원격 origin의 커밋 ID를 의미합니다. \u0026ldquo;오리진의 원격 브랜치 bar를 트랙하는 브랜치 foo 구성\u0026rdquo; \u0026ldquo;트랙되지 않는 파일\u0026quot;이라든지 \u0026ldquo;원격 트래킹 브랜치\u0026quot;의 경우는 나쁘지 않습니다 - 모두 \u0026ldquo;트랙\u0026quot;을 사용하지만 맥락이 크게 다르지 않죠. 문제 없습니다. 그러나 다른 두 가지 \u0026ldquo;트랙\u0026quot;의 용례가 상당히 혼란스럽습니다:\nmain은 원격을 트랙하는 브랜치다(branch that tracks a remote) origin/main은 원격-트래킹 브랜치다(remote-tracking branch) \u0026ldquo;원격을 트랙하는 브랜치\u0026quot;와 \u0026ldquo;원격-트래킹 브랜치\u0026quot;는 Git에서 서로 다른 것들이며 그 구분은 매우 중요합니다! 여기 그 차이점 요약일 적어드립니다:\nmain은 브랜치 입니다. 여기에 커밋을 만들거나, 여기로 머지할 수 있씁니다.보통 원격 main을 \u0026ldquo;트랙(track)\u0026ldquo;하는 것으로 .git/config에 설정되어 있습니다.이는 git pull이나 git push를 사용해 가져오기/밀어내기 작업을 수행할 수 있도록 하죠. origin/main은 브랜치가 아닙니다. 이는 \u0026ldquo;원격-트래킹 브랜치(remote-tracking branch)\u0026ldquo;이며, 브랜치 종류가 아닙니다(죄송).여기에는 커밋을 만들 수 없습니다.이를 업데이트하는 유일한 방법은 git pull또는 git fetch를 수행해 원격으로부터 main의 최신 상태를 가져오는 것입니다. 저는 이전에 이 부분이 모호하다는 생각을 해본 적이 없는데 가만보니 사람들이 왜 혼란스러워 하는지 알 것도 같네요.\n체크아웃(checkout) 체크아웃(checkout)은 두개의 완전히 관련 없는 것들을 수행합니다:\ngit checkout BRANCH는 브랜치를 변경합니다 git checkout file.txt는 file.txt에 존재하는 스테이지되지 않은 변화들을 버립니다 이는 혼란을 유발하는 것으로 매우 잘 알려진 부분이며 따라서 git은 실제로 두 기능을 git switch와 git restore로 구분했습니다(그러나 만약 여러분이 저처럼 15년간의 습관이 git checkout 기반으로 형성되어 있고 배운걸 억지로 버리기 싫으신 분들은 여전히 checkout을 사용할 수 있습니다).\n게다가 개인적으로 15년이나 지나고도 여전히 저는 main 브랜치로부터 file.txt의 버전을 복원하기 위해 수행할 git checkout main file.txt의 인자 순서를 제대로 기억할 수가 없습니다.\n제 생각에 여러분들은 간혹 --를 인자로써 checkout을 수행해 어떤 인자가 브랜치고 어디가 경로인지를 확인할 수도 있다고 보지만 저는 그렇게 하지 않으며 언제 그런 방법이 필요할지 모르겠네요.\nreflog 많은 사람들이 reflog를 ref-log가 아닌 re-flog로 읽는다고 언급합니다. 이미 포스트가 상당히 길기 때문에 저는 여기서 reflog에 대해 깊이 들어가지는 않을 겁니다. 그러나:\n\u0026ldquo;레퍼런스\u0026quot;는 git이 브랜치, 태그, HEAD를 의미하며 사용하는 일반 용어(umbrella term)입니다 레퍼런스 로그(\u0026ldquo;reflog\u0026rdquo;)는 여러분에게 레퍼런스가 가리켰던 모든 히스토리를 제공합니다 만약 여러분이 실수로 주요 브랜치를 삭제했다든지 하는 등의 상당히 안좋은 git 상황으로부터 벗어날 수 있도록 도움을 제공합니다 저는 git UI의 최고 헷갈리는 부분 중 하나라고 생각하며 가급적 사용을 피하려고 합니다 머지(merge) vs 리베이스(rebase) vs 체리픽(cherry-pick) 꽤 많은 사람들이 머지와 리베이스, 그리고 리베이스에서의 \u0026ldquo;베이스\u0026quot;가 뭘 말하고자 하는지 구분하는게 어렵다는 점을 언급하셨습니다. 저는 여기서 상당히 간략한 요약을 제공합니다. 그러나 여러분에게 여기 나오는 1줄짜리 설명이 도움이 될 것으로 기대하지는 않습니다. 이는 많은 사람들이 각자의 작업 방식을 머지/리베이스의 각기 다른 이해 방식을 중심으로 구성했놨을 것이기 때문이며 실제로 머지/리베이스를 이해하고자 한다면 작업흐름(workflow)를 이해해야 하기 때문입니다. 또한 그림이 상당한 도움이 됩니다. 그또한 하나의 별도 포스트가 될 개연성이 크므로 여기서 자세히 파고들진 않을 겁니다..\n머지는 2개의 브랜치를 합치는 새로운 단일 커밋을 생성함 리베이스는 한 번에 한 개씩 현재 브랜치에 있는 커밋을 타깃 브랜치로 복사함 체리-픽은 리베이스와 유사하지만 완전히 다른 문법을 지니고 있음(가장 큰 차이점 중 하나는 리베이스가 커밋을 현재 브랜치로부터 복사하는 반면, 체리 픽은 현재 브랜치로 커밋을 복사함) rebase \u0026ndash;onto git rebase는 onto라는 플래그(flag)를 가집니다. 이는 git rebase main의 존재 목적 자체가 현재 브랜치를 메인 위에 리베이스하는 것이라는 점에서 저를 혼란스럽게 했습니다.따라서 별도의 onto 인자는 왜 존재할까요?\n찾아보니 --onto가 확실히 저는 거의/전혀 겪어보지 못했던 문제를 해결하기는 합니다. 그래도 일단 제가 이해한 것을 적어보도록 하겠습니다.\nA - B - C (main) \\ D - E - F - G (mybranch) | otherbranch 무슨 이유에서인지 제가 갑자기 커밋 F와 G를 main에 리베이스해야 된다고 칩시다. 제 생각에 이런 상황이 발생하는 git 작업흐름이 꽤나 존재할 것 같은데요.\n여기서 여러분은 git rebase --onto main otherbranch mybranch를 수행할 수 있습니다. 제가 보기에 이 문법을 기억하는 것은 불가능해 보입니다(3개의 각기 다른 브랜치 이름이 필요하며, 제가 보기엔 너무 많네요). 그러나 많은 사람들이 이야기를 나누는 것을 보니 분명 유용한가 봅니다.\n커밋(commit) 누군가 커밋(commit)이 git에서 동사로도 쓰이고 명사로도 쓰여 혼란스럽다고 언급하셨습니다.\n예를 들어:\n동사: \u0026ldquo;자주 커밋해야 함을 기억하라\u0026rdquo; 명사: \u0026ldquo;main에 있는 가장 최근의 커밋\u0026rdquo; 제 추측상 대부분 사람들은 이 부분에 꽤 빨리 익숙해지는 것 같습니다만, 이런 방식의 \u0026ldquo;커밋\u0026rdquo; 용례는 SQL 데이터베이스에서의 사용과 상당히 다릅니다. 그 쪽에서의 \u0026ldquo;커밋\u0026quot;은 제 기억에 동사로써만 쓰이지(여러분은 작업을 완료한 이후 \u0026ldquo;COMMIT\u0026quot;합니다) 명사로는 안 쓰이니까요.\n추가로 git에서는 Git 커밋을 세가지 다른 방식으로 생각할 수도 있습니다:\n모든 파일의 현재 상태 스냅샷 부모 커밋과의 차이점(diff) 모든 이전 커밋 기록(history) 틀린 것은 없습니다: 서로 다른 명령어들이 커밋의 이런 모든 용례들을 활용하고 있습니다. 예를 들어 git show는 커밋을 차이점으로 다루고, git log는 기록으로 다루며, git restore는 스냅샷으로 활용합니다.\n그러나 git의 용어 사용이 주어진 명령어에서 커밋이 어떤 용례로 활용될지 이해하는데 큰 도움이 되지는 않습니다.\n나머지 헷갈리는 용어들 여기 헷갈리는 용어들이 더 있습니다. 저도 많은 것들의 의미를 잘 모릅니다.\n제가 진짜 도저히 이해할 수 없는 것들:\n\u0026ldquo;the git pickaxe\u0026rdquo;(아마 이는 git log -S와 git log -G를 의미하고, 이전 커밋들의 차이를 검색하는데 쓰일까요?) 서브모듈(제가 알기로 얘네는 제가 원하는 방식으로 작동하지 않습니다) git sparse checkout에서의 \u0026ldquo;cone mode\u0026rdquo;(이게 뭔지 감도 안오지만 누군가 언급했습니다) 사람들이 헷갈린다고 언급했으나 이미 포스트가 3000자가 넘어 생략한 것들:\nblob, tree \u0026ldquo;merge\u0026rdquo; 방향 \u0026ldquo;origin\u0026rdquo;, \u0026ldquo;upstream\u0026rdquo;, \u0026ldquo;downstream\u0026rdquo; push와 pull이 반대가 아니라는 점 fetch와 pull 사이 관계(pull=fetch+merge) git prcelain 서브트리(subtree) 워크트리(worktree) the stash \u0026ldquo;마스터\u0026quot;냐 \u0026ldquo;메인\u0026quot;이냐 (뭔가 특별한 의미가 있는 것 같지만 없습니다) origin main을 사용해야 하는 때(git push origin main 등) vs origin/main이 필요한 때 사람들이 언급한 Github의 용어들:\n\u0026ldquo;pull request\u0026rdquo; (vs Gitlab의 \u0026ldquo;merge request\u0026quot;를 사람들은 더 명확하다고 생각하는 것 같습니다) \u0026ldquo;squash and merge\u0026quot;와 \u0026ldquo;rebase and merge\u0026quot;가 뭘 수행하는지(저는 어제까지 git merge --squash를 들어본 적도 없다보니, \u0026ldquo;squash and merge\u0026quot;가 Github의 특이한 기능인 줄 알았습니다) 사실상 \u0026ldquo;모든 git 용어\u0026quot;입니다 저는 git의 핵심 기능의 사실상 모든 것들을 대상으로 최소한 한 명 이상은 희한한 방식으로 헷갈린다고 언급하는 것을 보고 놀랐습니다. 제가 빼먹은 것들 중 헷갈리는 git 용어들에 대한 예시를 더 들을 수 있으면 좋을 것 같습니다.\n이에 대해 과거 2012년에 작성된 훌륭한 포스트 가장 헷갈리는 git 용어가 또 있습니다. 이 글에서는 git의 용어들이 어떻게 CVS와 Subversion의 용어들과 관련되어 있는지에 집중하고 있습니다.\n제가 git 용어 중 가장 헷갈리는 3가지를 골라야 한다면, 당장 떠오르는 것들은 아래와 같습니다:\nhead는 브랜치인데 HEAD는 현재 브랜치다 \u0026ldquo;원격 트래킹 브랜치\u0026quot;와 \u0026ldquo;원격을 트래킹하는 브랜치\u0026quot;가 서로 다른 것이다 \u0026ldquo;인덱스\u0026rdquo;, \u0026ldquo;스테이지됨\u0026rdquo;, \u0026ldquo;캐시됨\u0026quot;이 같은 것을 의미한다 여기까지예요! 저는 이것을 작성하며 많이 배웠습니다(TN: 저도 이걸 번역하며 많이 배웠네요!) - git에 대해 새로운 사실들도 알게 되었고, 가장 중요한 건 누군가 git의 모든게 헷갈린다고 말할 때 그게 뭔 소린지 조금은 잘 이해할 수 있게 되었다는 점입니다.\n솔직히 이런 문제들에 대해 전에는 깊게 고민해본 적이 없습니다 - 즉, \u0026ldquo;트래킹\u0026quot;이 브랜치들 논의 중에 사용되는 이상한 방식에 대해 알지 못했죠.\n추가로, 경험해보지 못했던 git의 구석구석을 다루다보니 평소처럼 제가 몇몇 실수를 했을지도 모릅니다.\n","permalink":"http://ptrtoj.com/kr/confusing-git-terminology/","summary":"\u003chr\u003e\n\u003cp\u003eThis is a translated work.\nThe original post was written by Julia Evans and you can read it \u003ca href=\"https://jvns.ca/blog/2023/11/01/confusing-git-terminology/\"\u003ehere\u003c/a\u003e. On 03, Nov. 2023, permission was granted via e-mail.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003e이 문서는 번역본입니다.\n원본은 줄리아 에반스(Julia Evans)에 의해 작성되었으며, 다음 \u003ca href=\"https://jvns.ca/blog/2023/11/01/confusing-git-terminology/\"\u003e링크\u003c/a\u003e를 통해 읽을 수 있습니다.이메일을 통해 23/11/03 번역 허가를 받아 작성 후 업로드 합니다.\u003c/p\u003e","title":"헷갈리는 Git 용어"},{"content":"제가 공부하려고 개인적으로 정리한 리스트입니다.\n따라서, 각 커리큘럼에 대한 문의나 질문은 여기(Original)나 혹은 여기(updated)에 해주시면 감사하겠습니다.\n시작 전 환기 The First Three Minutes by Steven Weinberg (Level: Easy). An account of the Big Bang by one of the most brilliant physicists of all time. The Character of Physical Law by Richard Feynman (Level: Easy). A brilliant, inspiring little book on the laws of nature. The Particle Odyssey by Frank Close (Level: Easy). A brilliant popular introduction to particle physics and its history, beautifully illustrated with amazing figures and photographs. (Unfortunately it’s a bit difficult to find online right now, but if you find a copy, you should buy it ASAP!) Black Holes and Time Warps by Kip Thorne (Level: Easy/Medium). My absolute favorite popular introduction to general relativity. The Theoretical Minimum by Leonard Susskind and George Hrabovsky (Level: Medium). A solid introduction to classical mechanics. Is best understood around level 5 in the undergraduate curriculum. The Feynman Lectures on Physics (Boxed Set) and Feynman Lectures on Physics (Kindle Edition) (Level: Medium). Feynman\u0026rsquo;s Lectures are essential readings for everyone interested in physics, and you\u0026rsquo;ll find a copy on the bookshelf of every amateur and professional physicist. These lectures are what got me into physics: my astronomy professor told me to read them and see if I liked physics - they changed my life! They are somewhat difficult to understand if you are just getting started, but they will make more and more sense by the time you reach levels 5 and 6 in the undergraduate curriculum. Deep Down Things: The Breathtaking Beauty of Particle Physics by Bruce Schumm (Level: Difficult). The very best popular book about particle physics — it clearly explains the most difficult concepts without resorting to speculation. (I had the honor of working with Bruce on a search for supersymmetry at the ATLAS detector.) This book is a great read while you are starting level 7 in the undergraduate curriculum. 수학 Why Math? by R.D. Driver 학부 Introduction to Mechanics University Physics with Modern Physics by Young and Freedman (essential). Work through all of the \u0026ldquo;Mechanics\u0026rdquo; chapters (in my edition, these are chapters 1-14). This is the best introductory book I\u0026rsquo;ve found, and you can use it when you learn electrostatics and modern physics, too. It does a great job of introducing the relevant mathematics, but you\u0026rsquo;ll need to be learning calculus alongside it. There are plenty of great example problems to work through, and the solutions are easy to find online (though you can also buy a Student Solutions Manual). Please note that you don\u0026rsquo;t need to spend $250 on the new edition — Amazon has lots of copies of the 12th edition, the 13th edition, and the 14th edition that contain the same material. You\u0026rsquo;ll need to learn calculus while working through University Physics. My favorite introductory calculus book is Thomas\u0026rsquo; Calculus (you can also use the earlier editions), with Stewart\u0026rsquo;s Calculus(older edition here) coming in as a close second. Work through each chapter, and make sure you can solve problems at the end of each chapter before continuing to the next. Electrostatics Keep working through the calculus textbooks (Thomas or Stewart) while you work through the basics of electrostatics, but you should finish them by the time you finish the electromagnetism chapters in University Physics. You absolutely must understand the basics of calculus before you move on to the other topics in physics.\nUniversity Physics with Modern Physics by Young and Freedman (essential). Work through the chapters on \u0026ldquo;Electromagnetism\u0026rdquo; (in my edition, these are chapters 21-32). You can find inexpensive copies of the 12th edition, the 13th edition, and the 14th edition that contain the same material. Waves and Vibrations By this point, you should have finished the introductory calculus books and are ready to move on to more advanced mathematics. You should start working through Zill\u0026rsquo;s Advanced Engineering Mathematics, which is a thorough introduction to more advanced topics in mathematics (linear algebra, complex analysis, real analysis, partial differential equations, and ordinary differential equations). The topics in this book are essential — once you master them, you\u0026rsquo;ll have all the math you need to know in order to understand undergraduate physics. You can also buy the (cheaper) 4th and 5th editions.\nVibrations and Waves by French (essential) and Vibrations and Waves by King (essential). These two books complement each other very well, and contain different problems and solutions. Modern Physics Continue working through Zill\u0026rsquo;s Advanced Engineering Mathematics. Once you have mastered all of the topics in this book, you\u0026rsquo;ll have all the math you need to know in order to understand undergraduate physics.\nUniversity Physics with Modern Physics by Young and Freedman (essential). Work through the \u0026ldquo;Thermodynamics\u0026rdquo; section (chapters 17-20 in my edition of the book), and the \u0026ldquo;Modern Physics\u0026rdquo; section (chapters 37-44). You can find inexpensive copies of the 12th edition, the 13th edition, and the 14th edition that contain the same material. Classical Mechanics If you haven\u0026rsquo;t finished working through Zill by now, you should master the topics in it by the time you finish studying classical mechanics.\nTaylor\u0026rsquo;s Classical Mechanics (essential). This is a fantastic introduction to classical mechanics. Morin\u0026rsquo;s Introduction to Classical Mechanics with Problems and Solutions (supplement). Morin\u0026rsquo;s book is a good supplement to Taylor\u0026rsquo;s, and contains some great problems to work through. Problems and Solutions in Introductory Mechanics by Morin (supplement). Even more great problems (with solutions) to work through, and contains some great problem-solving strategies. Electrodynamics Griffith\u0026rsquo;s Introduction to Electrodynamics (essential). This is the book on undergraduate electrodynamics and one of the very best physics textbooks ever written. Make sure you work through every single problem in the book. Div, Grad, Curl and All That by Schey (supplement). This is a short textbook on vector calculus that is very helpful when trying to work with vectors in electrodynamics. A Student\u0026rsquo;s Guide to Maxwell\u0026rsquo;s Equations by Fleisch (supplement). Maxwell\u0026rsquo;s equations are essential in understanding electrodynamics, and this book is the best supplement on the topic. Quantum Mechanics Griffith\u0026rsquo;s Introduction to Quantum Mechanics (essential). This is, without a doubt, the book on undergraduate quantum mechanics, written by the same Griffiths who wrote the Introduction to Electrodynamics. It\u0026rsquo;s written in the same concise and beautiful style, and every single problem is worth solving. Thermodynamics and Statistical Mechanics Schroeder’s An Introduction to Thermal Physics (essential). A very thorough and comprehensive introduction to thermodynamics and statistical mechanics; contains very clear and straightforward explanations and examples. Introductory Statistical Mechanics by Bowley and Sanchez (supplement). A good second text to have on hand to reference. Undergraduate Electives Now that you understand all of the fundamentals of undergraduate physics, you have a solid foundation and can study more advanced and specialized topics\nAstronomy: The Cosmic Perspective. A wonderful introduction to astronomy, accessible to anyone who is just beginning to study physics. Astrophysics: An Introduction to Modern Astrophysics by Carroll and Ostlie. A comprehensive introduction to modern astrophysics. Biophysics: Biophysics: An Introduction by Glaser. A solid introduction to the principles of biophysics. Cosmology: Ryden\u0026rsquo;s Introduction to Cosmology. My absolute favorite introductory cosmology book. Electronics: Basic Electronics for Scientists and Engineers by Eggleston. Accessible to anyone who has worked through the basics of electrodynamics. Optics. Optics by Hecht. The classic (and truly amazing) optics textbook. Particle Physics: Griffith\u0026rsquo;s Introduction to Elementary Particles. Written by the same Griffith who gave us the Introduction to Electrodynamics and Introduction to Quantum Mechanics, this book is the perfect introduction to the fundamentals of particle physics and is a joy to work through. String Theory. A First Course in String Theory by Zwiebach. The essential introduction to string theory. 대학원 Mathematical Methods in Physics Mathematical Methods for Physicists by Arfken, Weber, and Harris (essential). This book covers the essentials of everything you\u0026rsquo;ll need to know for the mathematical rigor demanded by the graduate core. Tolstov\u0026rsquo;s Fourier Series (supplement). The best book on Fourier Analysis ever written. Complements the main text very well. Complex Variables by Fisher (supplement). Amazing overview of complex analysis. Can be used along with Needham\u0026rsquo;s Visual Complex Analysis to supplement the main text. Zee\u0026rsquo;s Group Theory in a Nutshell for Physicists (supplement). A brilliant introduction to group theory for physicists. Electrodynamics Classical Electrodynamics by Jackson (essential). This is the bible of classical electrodynamics, and everyone who works through either loves it or hates it (I loved it). If you can master everything in this book and work through a decent selection of the problems, you\u0026rsquo;ll have mastered electrodynamics. Quantum Mechanics Sakurai\u0026rsquo;s Modern Quantum Mechanics (essential). This is my favorite textbook on quantum mechanics, and the one I used to learn quantum mechanics for the very first time. It\u0026rsquo;s a wonderful, elegant, simple book with clear and understandable problems. Try to work through all of the problems — if you do, you\u0026rsquo;ll understand quantum mechanics very well. Quantum Mechanics and Path Integrals by Feynman (essential). Sakurai\u0026rsquo;s coverage of Feynman\u0026rsquo;s Path Integral formalism of quantum mechanics doesn\u0026rsquo;t do it justice. Working through this text (written by Feynman himself) is not only useful, but incredibly fun. The Principles of Quantum Mechanics by Dirac (supplement). Dirac was one of the founding fathers of quantum mechanics and quantum field theory. This book is important historically, and also will open your eyes to the need for quantum field theory. Principles of Quantum Mechanics by Shankar (supplement). A great supplement to Sakurai for more information about each topic. A bit too dense to serve as a primary text, it works best as an addition or reference. Decoherence and the Appearance of a Classical World in Quantum Theory (supplement). This book is very dense and you may not understand all of it even after working through Sakurai, but understanding decoherence is essential to understanding how the classical world arises from the quantum. The Everett Interpretation of Quantum Mechanics: Collected Works 1955-1980 (supplement). Very few books have been written on interpretations of quantum mechanics, and reading through this volume helps to understand the limitations of our interpretations as well as the complexities and details of Everett\u0026rsquo;s Many-Worlds interpretation. Statistical Mechanics Statistical Mechanics by Pathria and Beale (essential). This book is, admittedly, a bit frustrating, but it\u0026rsquo;s worth suffering through because if you make it all the way to the end and work through the majority of the problems, you\u0026rsquo;ll know stat mech like the back of your hand. Huang\u0026rsquo;s Statistical Mechanics (supplementary). This is a great book to supplement the main text — is a good bridge between undergraduate stat mech and Pathria. General Relativity Spacetime and Geometry by Carroll (essential). This is the book on general relativity, and Carroll does a phenomenal job of introducing the essentials of differential geometry and general relativity. Einstein Gravity in a Nutshell by Zee (supplement). A great, accessible overview. Wald\u0026rsquo;s General Relativity (supplement). Wald\u0026rsquo;s book is a very abstract, high-level overview of general relativity, and makes a great supplement to Carroll\u0026rsquo;s book. Go to Carroll for the overview, look it up in Wald for the high-level abstractions, and then look in the apple book for the dirty details. Gravitation by Misner, Thorne, and Wheeler (supplement). Also known as the \u0026ldquo;apple book\u0026rdquo; thanks to the apple gracing its cover, this book goes into the nitty-gritty details of general relativity in ways that no other book does. Weinberg\u0026rsquo;s Gravitation and Cosmology (supplement). Weinberg is one of those rare physicists who has not only been at the forefront of every major field in physics, but has written about each of them as well. His books tend to be inaccessible to beginners, however, and this book is no exception. It does make a good supplementary reading, but I\u0026rsquo;d advise reading it after you\u0026rsquo;ve worked through the rest. Differential Geometry of Curves and Surfaces by Manfredo P. do Carmo (supplement). The classic differential geometry textbook; may be useful to help you wrap your head around differential geometry. Quantum Field Theory Zee\u0026rsquo;s Quantum Field Theory in a Nutshell (essential). This is my favorite physics book of all time, and the most beautiful introduction to QFT ever written. You\u0026rsquo;ll walk away understanding the basics of QFT and with a deep understanding of the fundamental nature of the universe. An Introduction to Quantum Field Theory by Peskin and Schroeder (essential). This is the bible of QFT, but its far too terse and encyclopedic to work through on its own and must be studied alongside Zee. Covers everything you could possibly want to know about QFT. Try to work through the problems, but be aware that mastery of QFT will take a very, very long time. Weinberg\u0026rsquo;s The Quantum Theory of Fields, Volume 1 (supplement). Another great volume by Weinberg, who was one of the most important physicists in the history of particle physics. This book should be used only as a supplement, and preferably not read until Zee and Peskin and Schroeder have been completed. It\u0026rsquo;s not a book to learn from, but one to gain additional understanding of QFT through after you\u0026rsquo;ve mastered all of the basics. Lie Algebras in Particle Physics by Georgi (supplement). This dives into the details of Lie Algebras in QFT. Graduate Electives Condensed Matter Physics: Lubensky’s Principles of Condensed Matter Physics. A modern, comprehensive textbook. Fairly advanced, and is easier to understand after completing the graduate core and working through something like Ashcroft and Mermin. Cosmology: Mark Trodden and Sean Carroll’s TASI Lectures: Introduction to Cosmology. Supplement with Steven Weinberg’s Cosmology. Electronics: The Art of Electronics by Horowitz and Hill. The best electronics textbook there is, period. Optics: Optics by Hecht. The classic optics textbook. Particle Physics: Quarks and Leptons by Halzen and Martin. Wonderful overview that’s fun to read and work through. Supplement this with Modern Particle Physics by Mark Thomson, which is up-to-date on contemporary discoveries like the Higgs. Quantum Computing: Quantum Computation and Quantum Information by Michael A. Nielsen and Isaac L. Chuang. Also known as “Mike and Ike,” this is the standard introduction to quantum information and computation. Solid-State Physics: Solid-State Physics by Ashcroft and Mermin. The classic introductory solid-state textbook. Supplement with Introduction to Solid State Physics by Kittel. String Theory: String Theory: Volume 1, An Introduction to the Bosonic String and String Theory: Volume 2, Superstring Theory and Beyond, by the late Joe Polchinski; and String Theory and M-Theory: A Modern Introduction. I found it really enjoyable to pair Polchinski’s books with Becker Becker Schwarz when I was learning string theory — they complement each other well. ","permalink":"http://ptrtoj.com/kr/physics/","summary":"\u003cp\u003e제가 공부하려고 개인적으로 정리한 리스트입니다.\u003cbr\u003e\n따라서, 각 커리큘럼에 대한 문의나 질문은 \u003ca href=\"https://www.susanjfowler.com/blog/2016/8/13/so-you-want-to-learn-physics\"\u003e여기(Original)\u003c/a\u003e나 혹은 \u003ca href=\"https://www.susanrigetti.com/physics\"\u003e여기(updated)\u003c/a\u003e에 해주시면 감사하겠습니다.\u003c/p\u003e\n\u003ch2 id=\"시작-전\"\u003e시작 전\u003c/h2\u003e\n\u003ch3 id=\"환기\"\u003e환기\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cinput checked=\"\" disabled=\"\" type=\"checkbox\"\u003e \u003ca href=\"https://www.amazon.com/gp/product/0465024378/ref=as_li_tl?ie=UTF8\u0026amp;camp=1789\u0026amp;creative=9325\u0026amp;creativeASIN=0465024378\u0026amp;linkCode=as2\u0026amp;tag=susanfowler-20\u0026amp;linkId=d72aaa7813d719344a4c88258a5488d0\"\u003eThe First Three Minutes by Steven Weinberg\u003c/a\u003e \u003cstrong\u003e(Level: Easy)\u003c/strong\u003e. An account of the Big Bang by one of the most brilliant physicists of all time.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/Character-Physical-Law-MIT-Press/dp/0262533413?dchild=1\u0026amp;keywords=character%20of%20physical%20law\u0026amp;language=en_US\u0026amp;linkCode=ll1\u0026amp;linkId=85b0a8234adfc1bb7a7c4b643f59bf6b\u0026amp;qid=1618957764\u0026amp;ref_=as_li_ss_tl\u0026amp;s=books\u0026amp;sr=1-1\u0026amp;tag=susanfowler-20\"\u003eThe Character of Physical Law by Richard Feynman\u003c/a\u003e \u003cstrong\u003e(Level: Easy)\u003c/strong\u003e. A brilliant, inspiring little book on the laws of nature.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/gp/product/0198504861/ref=as_li_tl?ie=UTF8\u0026amp;camp=1789\u0026amp;creative=9325\u0026amp;creativeASIN=0198504861\u0026amp;linkCode=as2\u0026amp;tag=susanfowler-20\u0026amp;linkId=bfce048e1031401ef7c664d79ab2d927\"\u003eThe Particle Odyssey by Frank Close\u003c/a\u003e \u003cstrong\u003e(Level: Easy)\u003c/strong\u003e. A brilliant popular introduction to particle physics and its history, beautifully illustrated with amazing figures and photographs. (Unfortunately it’s a bit difficult to find online right now, but if you find a copy, you should buy it ASAP!)\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/Black-Holes-Time-Warps-Commonwealth/dp/0393312763?dchild=1\u0026amp;keywords=black%20holes%20and%20time%20warps\u0026amp;language=en_US\u0026amp;linkCode=ll1\u0026amp;linkId=5c79d14a1bc80bbd2207736f7540668f\u0026amp;qid=1618958068\u0026amp;ref_=as_li_ss_tl\u0026amp;s=books\u0026amp;sr=1-1\u0026amp;tag=susanfowler-20\"\u003eBlack Holes and Time Warps by Kip Thorne\u003c/a\u003e \u003cstrong\u003e(Level: Easy/Medium)\u003c/strong\u003e. My absolute favorite popular introduction to general relativity.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/Theoretical-Minimum-Start-Doing-Physics/dp/0465075681?dchild=1\u0026amp;keywords=the%20theoretical%20minimum\u0026amp;language=en_US\u0026amp;linkCode=ll1\u0026amp;linkId=e69e149c7cda69c3a460847a5e1b341c\u0026amp;qid=1618956738\u0026amp;ref_=as_li_ss_tl\u0026amp;sr=8-1\u0026amp;tag=susanfowler-20\"\u003eThe Theoretical Minimum by Leonard Susskind and George Hrabovsky\u003c/a\u003e \u003cstrong\u003e(Level: Medium)\u003c/strong\u003e. A solid introduction to classical mechanics. Is best understood around level 5 in the undergraduate curriculum.\u003c/li\u003e\n\u003cli\u003e\u003cinput checked=\"\" disabled=\"\" type=\"checkbox\"\u003e \u003ca href=\"https://www.amazon.com/gp/product/0465023827/ref=as_li_tl?ie=UTF8\u0026amp;camp=1789\u0026amp;creative=9325\u0026amp;creativeASIN=0465023827\u0026amp;linkCode=as2\u0026amp;tag=susanfowler-20\u0026amp;linkId=47c82e27eae89efef1db2659759c65f7\"\u003eThe Feynman Lectures on Physics (Boxed Set)\u003c/a\u003e and \u003ca href=\"https://www.amazon.com/gp/product/B016OMK7XW/ref=as_li_tl?ie=UTF8\u0026amp;camp=1789\u0026amp;creative=9325\u0026amp;creativeASIN=B016OMK7XW\u0026amp;linkCode=as2\u0026amp;tag=susanfowler-20\u0026amp;linkId=50edb7c48df214e8eb9a3a5e4d868806\"\u003eFeynman Lectures on Physics (Kindle Edition)\u003c/a\u003e \u003cstrong\u003e(Level: Medium)\u003c/strong\u003e. Feynman\u0026rsquo;s Lectures are essential readings for everyone interested in physics, and you\u0026rsquo;ll find a copy on the bookshelf of every amateur and professional physicist. These lectures are what got me into physics: my astronomy professor told me to read them and see if I liked physics - they changed my life! They are somewhat difficult to understand if you are just getting started, but they will make more and more sense by the time you reach levels 5 and 6 in the undergraduate curriculum.\u003c/li\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/gp/product/080187971X/ref=as_li_tl?ie=UTF8\u0026amp;camp=1789\u0026amp;creative=9325\u0026amp;creativeASIN=080187971X\u0026amp;linkCode=as2\u0026amp;tag=susanfowler-20\u0026amp;linkId=6b2ca839cec6cc43cbad403e156c14cf\"\u003eDeep Down Things: The Breathtaking Beauty of Particle Physics by Bruce Schumm\u003c/a\u003e \u003cstrong\u003e(Level: Difficult)\u003c/strong\u003e. The very best popular book about particle physics — it clearly explains the most difficult concepts without resorting to speculation. (I had the honor of working with Bruce on a search for supersymmetry at the ATLAS detector.) This book is a great read while you are starting level 7 in the undergraduate curriculum.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"수학\"\u003e수학\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ca href=\"https://www.amazon.com/Why-Math-Undergraduate-Texts-Mathematics/dp/0387944273?_encoding=UTF8\u0026amp;amp%3Bqid=\u0026amp;amp%3Bsr=\u0026amp;language=en_US\u0026amp;linkCode=ll1\u0026amp;linkId=0fc3187aa8b5febcc75391ba905635b5\u0026amp;ref_=as_li_ss_tl\u0026amp;tag=susanfowler-20\"\u003eWhy Math? by R.D. Driver\u003c/a\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"학부\"\u003e학부\u003c/h2\u003e\n\u003ch3 id=\"introduction-to-mechanics\"\u003eIntroduction to Mechanics\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cinput checked=\"\" disabled=\"\" type=\"checkbox\"\u003e \u003ca href=\"https://www.amazon.com/University-Physics-Modern-15th-dp-0135159555/dp/0135159555?language=en_US\u0026amp;linkCode=ll1\u0026amp;linkId=83f94d8e110a2add683656ac03b021c1\u0026amp;ref_=as_li_ss_tl\u0026amp;tag=susanfowler-20\"\u003eUniversity Physics with Modern Physics by Young and Freedman\u003c/a\u003e (essential). Work through all of the \u0026ldquo;Mechanics\u0026rdquo; chapters (in my edition, these are chapters 1-14). This is the best introductory book I\u0026rsquo;ve found, and you can use it when you learn electrostatics and modern physics, too. It does a great job of introducing the relevant mathematics, but you\u0026rsquo;ll need to be learning calculus alongside it. There are plenty of great example problems to work through, and the solutions are easy to find online (though you can also buy a \u003ca href=\"https://www.amazon.com/Student-Solutions-Manual-University-Physics/dp/0135216958?_encoding=UTF8\u0026amp;language=en_US\u0026amp;linkCode=ll1\u0026amp;linkId=d12dd683b7365eb115eeb59b93966df8\u0026amp;pd_rd_i=0135216958\u0026amp;pd_rd_r=6cbcc49d-5945-4800-862a-f2d9a5664310\u0026amp;pd_rd_w=7KvdQ\u0026amp;pd_rd_wg=xjZRM\u0026amp;pf_rd_p=fd3ebcd0-c1a2-44cf-aba2-bbf4810b3732\u0026amp;pf_rd_r=YVPF9YHJKQGRAK06BWD8\u0026amp;psc=1\u0026amp;refRID=YVPF9YHJKQGRAK06BWD8\u0026amp;ref_=as_li_ss_tl\u0026amp;tag=susanfowler-20\"\u003eStudent Solutions Manual\u003c/a\u003e). Please note that you don\u0026rsquo;t need to spend $250 on the new edition — Amazon has lots of copies of \u003ca href=\"https://www.amazon.com/gp/product/0321501217/ref=as_li_tl?ie=UTF8\u0026amp;camp=1789\u0026amp;creative=9325\u0026amp;creativeASIN=0321501217\u0026amp;linkCode=as2\u0026amp;tag=susanfowler-20\u0026amp;linkId=5a574e1c2ff846a346c32c7f53955499\"\u003ethe 12th edition\u003c/a\u003e, \u003ca href=\"https://www.amazon.com/gp/product/0321696867/ref=as_li_tl?ie=UTF8\u0026amp;camp=1789\u0026amp;creative=9325\u0026amp;creativeASIN=0321696867\u0026amp;linkCode=as2\u0026amp;tag=susanfowler-20\u0026amp;linkId=ddf424a6eecfcfe35e44d1db6790be82\"\u003ethe 13th edition\u003c/a\u003e, and the \u003ca href=\"https://www.amazon.com/gp/product/0321973615?ie=UTF8\u0026amp;language=en_US\u0026amp;linkCode=ll1\u0026amp;linkId=0542066c72a562b902ea737105713149\u0026amp;ref_=as_li_ss_tl\u0026amp;tag=susanfowler-20\"\u003e14th edition\u003c/a\u003e that contain the same material.\u003c/li\u003e\n\u003cli\u003eYou\u0026rsquo;ll need to learn calculus while working through \u003ca href=\"https://www.amazon.com/University-Physics-Modern-15th-dp-0135159555/dp/0135159555?language=en_US\u0026amp;linkCode=ll1\u0026amp;linkId=b29655ef6d618e95cb854f8f9ae55142\u0026amp;ref_=as_li_ss_tl\u0026amp;tag=susanfowler-20\"\u003eUniversity Physics\u003c/a\u003e\u003cem\u003e.\u003c/em\u003e My favorite introductory calculus book is \u003ca href=\"https://www.amazon.com/Thomas-Calculus-14th-Joel-Hass-dp-0134438981/dp/0134438981?language=en_US\u0026amp;linkCode=ll1\u0026amp;linkId=e055fccb0e90aa26395bf8b70ad8eb90\u0026amp;ref_=as_li_ss_tl\u0026amp;tag=susanfowler-20\"\u003eThomas\u0026rsquo; Calculus\u003c/a\u003e (you can also use the \u003ca href=\"https://www.amazon.com/gp/product/0321587995?ie=UTF8\u0026amp;language=en_US\u0026amp;linkCode=ll1\u0026amp;linkId=a3bf72c1bdee13f41d667b22236fcd0c\u0026amp;ref_=as_li_ss_tl\u0026amp;tag=susanfowler-20\"\u003eearlier\u003c/a\u003e editions), with \u003ca href=\"https://www.amazon.com/Calculus-Early-Transcendentals-James-Stewart-dp-1337613924/dp/1337613924?language=en_US\u0026amp;linkCode=ll1\u0026amp;linkId=f6ab8fd13d35a55416bd8323a003f1e7\u0026amp;ref_=as_li_ss_tl\u0026amp;tag=susanfowler-20\"\u003eStewart\u0026rsquo;s Calculus\u003c/a\u003e(older edition \u003ca href=\"https://www.amazon.com/gp/product/0538497904?ie=UTF8\u0026amp;language=en_US\u0026amp;linkCode=ll1\u0026amp;linkId=2ff44ed10fac5d8dc3431070f7747618\u0026amp;ref_=as_li_ss_tl\u0026amp;tag=susanfowler-20\"\u003ehere\u003c/a\u003e) coming in as a close second. Work through each chapter, and make sure you can solve problems at the end of each chapter before continuing to the next.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3 id=\"electrostatics\"\u003eElectrostatics\u003c/h3\u003e\n\u003cp\u003eKeep working through the calculus textbooks (\u003ca href=\"https://www.amazon.com/Thomas-Calculus-14th-Joel-Hass-dp-0134438981/dp/0134438981?language=en_US\u0026amp;linkCode=ll1\u0026amp;linkId=d72cf5af7a3e077a3deb9bb2556886e9\u0026amp;ref_=as_li_ss_tl\u0026amp;tag=susanfowler-20\"\u003eThomas\u003c/a\u003e or \u003ca href=\"https://www.amazon.com/Calculus-Early-Transcendentals-James-Stewart-dp-1337613924/dp/1337613924?language=en_US\u0026amp;linkCode=ll1\u0026amp;linkId=260314dde4baac0f191ee371e799ad18\u0026amp;ref_=as_li_ss_tl\u0026amp;tag=susanfowler-20\"\u003eStewart\u003c/a\u003e) while you work through the basics of electrostatics, but you should finish them by the time you finish the electromagnetism chapters in \u003ca href=\"https://www.amazon.com/gp/product/0321973615/ref=as_li_tl?ie=UTF8\u0026amp;camp=1789\u0026amp;creative=9325\u0026amp;creativeASIN=0321973615\u0026amp;linkCode=as2\u0026amp;tag=susanfowler-20\u0026amp;linkId=4724b43f949f1f5295f91dd9b2c1c3f5\"\u003eUniversity Physics\u003c/a\u003e. You absolutely must understand the basics of calculus before you move on to the other topics in physics.\u003c/p\u003e","title":"물리 독학 커리큘럼"},{"content":"제가 공부하려고 개인적으로 정리한 리스트입니다.\n따라서, 각 커리큘럼에 대한 문의나 질문은 여기에 해주시면 감사하겠습니다.\nStart with Algebra Pre-Algebra는 ‘자연수, 정수, 분수, 소수, 백분율, 실수, 1차 방정식, 기초 기하학, 그래프’로 구성돼 ‘일반적인 경우’ 중등 교육으로 학습했을 것이므로 생략 가능 단계로 생각합니다.\nPre-Algebra, Nichols Elementary Algebra, Sullivan, Struve, Mazzarella or with Discrete Math Pick one of below, but 2-4 are really hard. I would take 1 \u0026amp; 2.\nDiscrete Mathematical Structures, Kolman, Busby, Ross Concrete Mathematics, Graham, Knuth, Patashnik or Discrete Mathematics and its Applications, Rosen or Discrete and Combinatorial Mathematics, Grimaldi or Jump right into Proof Writing Recommended book was ‘How to Prove it’.\nHow To Prove It, Velleman or Foundations of Higher Mathematics, Fletcher, Patty or An Introduction To Abstract Mathematics, Bond, Keane or How to Read and Do Proofs, Solow Pre-Calculus \u0026amp; Trigonometry Precalculus, Stewart, Redlin, Watson or Algebra and Trigonometry, Stewart, Redlin, Watson Calculus Calculus, Stewart or Thomas\u0026rsquo; Calculus or Calculus, Larson, Edwards or Calculus, Swokowski Differential Equations Differential Equations, Zill Differential Equations, Nagle, Saff, Snider or Schaum\u0026rsquo;s Differential Equations Probability \u0026amp; Statistics Elementary Statistics, Weiss or Mathematical Statistics and Data Analysis, Rice Geometry Geometry, Jurgensen Linear Algebra Elementary Linear Algebra, Anton Linear Algebra, Friedberg, Insel, Spence Complex Variables Schaum\u0026rsquo;s Complex Variables Fundamentals of Complex Analysis, Saff, Snider or Complex Variables, Brown, Churchill or Complex Variables, Ablowitz, Fokas (Advanced) Partial Differential Equations Introduction to Partial Differential Equations, Zachmanoglou, Thoe Partial Differential Equations, Miller Abstract Algebra Abstract Algebra, Saracino Algebra, Lang (Said ‘considered as bibile of abstract algebra) Real Analysis Introduction to Real Analysis, Bartle, Sherbert Advanced Calculus, Fitzpatrick Advanced Calculus, Buck Number Theory any one of below\nNumber Theory, Long Number Theory, Andrews Number Theory, Dudley Graph Theory Graph Theory, Gould Topology Topology, Gamelin, Greene or Topology, Munkres Others All The Math You Missed, Thomas A. Garrity Cryptography, Trappe Advanced Engineering Mathematics, Erwin Kreyszig Basic Mathematics, Lang ","permalink":"http://ptrtoj.com/kr/math/","summary":"\u003cp\u003e제가 공부하려고 개인적으로 정리한 리스트입니다.\u003cbr\u003e\n따라서, 각 커리큘럼에 대한 문의나 질문은 \u003ca href=\"https://youtu.be/didXE0HkSC8\"\u003e여기\u003c/a\u003e에 해주시면 감사하겠습니다.\u003c/p\u003e\n\u003ch2 id=\"start\"\u003eStart\u003c/h2\u003e\n\u003ch3 id=\"with-algebra\"\u003ewith Algebra\u003c/h3\u003e\n\u003cblockquote\u003e\n\u003cp\u003ePre-Algebra는 ‘자연수, 정수, 분수, 소수, 백분율, 실수, 1차 방정식, 기초 기하학, 그래프’로 구성돼 ‘일반적인 경우’ 중등 교육으로 학습했을 것이므로 \u003cstrong\u003e생략 가능 단계\u003c/strong\u003e로 생각합니다.\u003c/p\u003e\n\u003c/blockquote\u003e","title":"수학 독학 커리큘럼"},{"content":"제가 공부하려고 개인적으로 정리한 리스트입니다. 따라서, 각 커리큘럼에 대한 문의나 질문은 여기에 해주시면 감사하겠습니다.\nAt Least Must study at least these two books.\nComputer Systems: A Programmer\u0026rsquo;s Perspective Designing Data-Intensive Applications Programming SICP (Structure and Interpretation of Computer Programs) Course: Brian Harvey’s Berkeley CS 61A Architecture CS:APP (Computer Systems :A Programmer’s Perspective) Course: Berkeley CS 61C Algorithms the Algorithm Design Manual Course: Steven Skiena’s lectures (also recommended) How to Solve It, Polya, Conway Math Mathematics for Computer Science Course: Tom Leighton’s MIT 6.042J Operating Systems OS:TEP (Operating Systems: Three Easy Pieces) Course: Berkeley CS 162 Network CN:TDA (Computer Network: a Top Down Approach) Course: Stanford CS 144 Database Readings in Database Systems Course: Joe Hellerstein’s Berkeley CS 186 Languages \u0026amp; Compilers Crafting Interpreters Course: Alex Aiken’s course on edX (also recommended) Compilers: Principles, Techniques \u0026amp; Tools, commonly called the Dragon Book Distributed Systems Designing Data-Intensive Applications by Martin Kleppmann Course: MIT 6.824 (also recommended) Maarten van Steen and Andrew Tanenbaum’s Distributed Systems, 3rd Edition ","permalink":"http://ptrtoj.com/kr/cs/","summary":"\u003cp\u003e제가 공부하려고 개인적으로 정리한 리스트입니다. \u003cbr\u003e\n따라서, 각 커리큘럼에 대한 문의나 질문은 \u003ca href=\"https://teachyourselfcs.com/\"\u003e여기\u003c/a\u003e에 해주시면 감사하겠습니다.\u003c/p\u003e\n\u003ch2 id=\"at-least\"\u003eAt Least\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eMust study\u003c/strong\u003e at least these two books.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eComputer Systems: A Programmer\u0026rsquo;s Perspective\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eDesigning Data-Intensive Applications\u003c/strong\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"programming\"\u003eProgramming\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cinput checked=\"\" disabled=\"\" type=\"checkbox\"\u003e \u003cstrong\u003eSICP\u003c/strong\u003e (\u003cem\u003eStructure and Interpretation of Computer Programs\u003c/em\u003e)\u003c/li\u003e\n\u003cli\u003eCourse: Brian Harvey’s Berkeley CS 61A\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"architecture\"\u003eArchitecture\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cinput checked=\"\" disabled=\"\" type=\"checkbox\"\u003e \u003cstrong\u003eCS:APP\u003c/strong\u003e (\u003cem\u003eComputer Systems :A Programmer’s Perspective\u003c/em\u003e)\u003c/li\u003e\n\u003cli\u003eCourse: Berkeley CS 61C\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"algorithms\"\u003eAlgorithms\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003ethe Algorithm Design Manual\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003eCourse: Steven Skiena’s lectures\u003c/li\u003e\n\u003cli\u003e\u003cem\u003e(also recommended)\u003c/em\u003e \u003ca href=\"https://www.amazon.com/How-Solve-Mathematical-Princeton-Science/dp/069116407X/?pldnSite=1\"\u003eHow to Solve It\u003c/a\u003e, Polya, Conway\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"math\"\u003eMath\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eMathematics for Computer Science\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003eCourse: Tom Leighton’s MIT 6.042J\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"operating-systems\"\u003eOperating Systems\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eOS:TEP\u003c/strong\u003e (\u003cem\u003eOperating Systems: Three Easy Pieces\u003c/em\u003e)\u003c/li\u003e\n\u003cli\u003eCourse: Berkeley CS 162\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"network\"\u003eNetwork\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cinput checked=\"\" disabled=\"\" type=\"checkbox\"\u003e \u003cstrong\u003eCN:TDA\u003c/strong\u003e (\u003cem\u003eComputer Network: a Top Down Approach\u003c/em\u003e)\u003c/li\u003e\n\u003cli\u003eCourse: Stanford CS 144\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"database\"\u003eDatabase\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eReadings in Database Systems\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003eCourse: Joe Hellerstein’s Berkeley CS 186\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"languages--compilers\"\u003eLanguages \u0026amp; Compilers\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cinput checked=\"\" disabled=\"\" type=\"checkbox\"\u003e \u003cstrong\u003eCrafting Interpreters\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003eCourse: Alex Aiken’s course on edX\u003c/li\u003e\n\u003cli\u003e\u003cem\u003e(also recommended)\u003c/em\u003e \u003cem\u003e\u003ca href=\"https://smile.amazon.com/Compilers-Principles-Techniques-Tools-2nd/dp/0321486811\"\u003eCompilers: Principles, Techniques \u0026amp; Tools\u003c/a\u003e\u003c/em\u003e, commonly called \u003cem\u003ethe Dragon Book\u003c/em\u003e\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"distributed-systems\"\u003eDistributed Systems\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eDesigning Data-Intensive Applications by Martin Kleppmann\u003c/strong\u003e\u003c/li\u003e\n\u003cli\u003eCourse: MIT 6.824\u003c/li\u003e\n\u003cli\u003e\u003cem\u003e(also recommended)\u003c/em\u003e Maarten van Steen and Andrew Tanenbaum’s \u003cem\u003e\u003ca href=\"https://www.distributed-systems.net/index.php/books/ds3/\"\u003eDistributed Systems, 3rd Edition\u003c/a\u003e\u003c/em\u003e\u003c/li\u003e\n\u003c/ul\u003e","title":"컴공 독학 커리큘럼"},{"content":"🔧 근본 저처럼 근본 찾으시는 분들은 익히 아시겠지만 Bill Joy의 vi가 h,j,k,l을 방향키로 쓰게 된 이유, esc가 모드 변경에 쓰인 이유, 특히 유닉스 계열에서 홈 디렉터리를 ~로 줄여 쓰기 시작한 원인은 모두 ADM-3A 키보드에 있습니다.\nBill Joy가 vi를 개발하던 당시 사용하던 키보드가 아래와 같기 때문이죠.\n출처: Lear Siegler\u0026rsquo;s ADM-3A computer terminal\u0026rsquo;s full keyboard\nH,J,K,L 상단의 화살표가 보이시나요? 방향 이동을 위해서는 Ctrl과 함께 H,J,K,L을 입력할 수 있었습니다.\nA 좌측에 Ctrl, Q 좌측에 ESC가 위치해 있습니다.\n독립적인 :(콜론) 키가 숫자 0 우측에 위치합니다. 현재도 독립적인 ;(세미콜론)처럼 :(콜론)도 독립 키였습니다.\n최상단 행에서 가장 우측 끝에 보시면 HOME키가 있는데 여기에 같이 존재하는 특수키로 ~(tilde)가 있습니다. 이로써 편의를 위해 ${HOME}은 ~로 표기하게 되었죠.\n출처: Lear Siegler\u0026rsquo;s ADM-3A computer terminal\n👍🏻TAB → ESC 코드 작성 시에서만 문제가 되는 것은 아닙니다. 쉘 자동 완성에서도 Tab은 유용하게 쓰이니까요.\n그러나 아래에서 작성했든 기능이 없게된 왼쪽 Ctrl키를 이용해 Tab을 살려두는 방법도 있습니다.\nVim-insert 모드에서 Ctrl-T를 활용해 들여쓰기를 할 수 있고, 내어쓰기는 Ctrl-D로 가능합니다. (출처)\n👍🏻CAPS LOCK → CTRL 최근에 CAPS LOCK을 활용하신 기억이 나나요?(MySQL) 근본대로 좌측 Caps Lock을 Ctrl로 변경해줍니다.\nEmacs를 사용하기에도 편해집니다 ㅋㅋ\n👍🏻CTRL_L → TAB 그래도 아예 없애는 건 서운하니 쉘 자동 완성 등에서 아직 유용한 경우가 많으니 살려는 드릴게..\n🏁How? (참조)\nGnome gnome-tweaks를 이용합니다\nPlasma system settings → input devices → keyboard → advanced에 ‘Caps Lock is also a Ctrl’ 등의 옵션이 있습니다.\n그 외 (1) - Xmodmap xmodmap을 설치해 사용합니다.\n! ! Swap Caps_Lock and Control_L ! remove Lock = Caps_Lock remove Control = Control_L keysym Control_L = Caps_Lock keysym Caps_Lock = Control_L add Lock = Caps_Lock add Control = Control_L .xinitrc 등에서 소환합니다. (보통 복사하신 시스템 xinitrc에서 적용되어 있습니다)\n$ [[ -f ~/.Xmodmap ]] \u0026amp;\u0026amp; xmodmap ~/.Xmodmap 그 외 (2) - Xkbd $ setxkbmap -option ctrl:swapcaps # Swap Left Control and Caps Lock ➕Bonus - Hyper key Hyper key is long gone. But if we move ctrl to caps (or tab whatever), there’s two ctrl on the left side of keyboard. So we can bring Hyper key back to life.\n(ref: You can also put .Xmodmap in your .xinitrc with xmodmap ~/.Xmodmap \u0026amp;. I have it between the setxkbmap and xcape lines, and it has been stable.)\nclear lock clear control clear mod1 clear mod2 clear mod3 clear mod4 clear mod5 keycode 37 = Hyper_L add control = Control_L Control_R add mod1 = Alt_L Alt_R Meta_L add mod2 = Num_Lock add mod3 = Hyper_L add mod4 = Super_L Super_R add mod5 = Mode_switch ISO_Level3_Shift 여담 (1) QMK 많은 분들이 커스텀 키보드를 활용하시면 키 리맵 소프트웨어(QMK)를 사용하실 겁니다. 특히, 40%키보드에서 키 리맵을 하신다면 특히 이 페이지에서 설정하는 방식으로 활용해보시는것은 어떨까 싶네요. (게이머는 많은 고난이 예상되므로 제외)\n40% Ortholinear (출처)\n(2) HHKB 많은 개발자들이 사랑하는 해피해킹 키보드도 있긴 합니다; 이쪽에선 아예 Caps Lock 자리가 Control로 변형되어 있습니다. 그.. 그런데 Delete까지 Enter(Return) 상단으로 이사;;\nHHKB Pro Hybrid Type-S (Snow/Blank) 구입해서 사용하고 있습니다.\nemacs 사용도 너무 편하고 좋네요. vim이고 뭐고 안가리는 전무후무 맞는듯 ㄷㄷ\nHHKB (출처)\n","permalink":"http://ptrtoj.com/kr/kbd/","summary":"\u003ch2 id=\"-근본\"\u003e🔧 근본\u003c/h2\u003e\n\u003cp\u003e저처럼 근본 찾으시는 분들은 익히 아시겠지만 Bill Joy의 \u003ccode\u003evi\u003c/code\u003e가 \u003ccode\u003eh\u003c/code\u003e,\u003ccode\u003ej\u003c/code\u003e,\u003ccode\u003ek\u003c/code\u003e,\u003ccode\u003el\u003c/code\u003e을 방향키로 쓰게 된 이유, \u003ccode\u003eesc\u003c/code\u003e가 모드 변경에 쓰인 이유, 특히 유닉스 계열에서 홈 디렉터리를 \u003ccode\u003e~\u003c/code\u003e로 줄여 쓰기 시작한 원인은 모두 ADM-3A 키보드에 있습니다.\u003c/p\u003e","title":"옳게된 키보드 레이아웃"},{"content":" fcitx, scim 등도 잘 작동하는 것으로 알고 있습니다만,\n저는 리눅스를 처음 접했을 때부터 지금까지 ibus를 사용중이므로 가이드는 ibus 기준으로 작성합니다.\n들어가기 전에 (1) Gnome의 경우 이제 Gnome은 ibus와 통합되어 개발됩니다. 대부분의 배포판에서, Gnome 데스크탑 환경을 사용하시는 경우라면, 아래 과정은 Settings 앱을 통해 진행하실 수 있습니다. Region \u0026amp; Language 옵션을 확인하세요!\n(2) 글자가 네모로 표시된다? 입력과 무관하게 한글이 포함된 페이지에서 한글에 해당하는 부분이 네모로 표시되는 문제는 폰트가 원인입니다. 한글 표기를 할 수 있는 폰트, 예를 들어, noto-fonts-cjk 등을 설치해서 해결합니다.\nCJK란?\ncjk는 Chinese, Japanese, Korean의 앞글자를 따 동북아시아 3국 언어 관련 패키지 혹은 개발 환경을 일컬을 때 쓰입니다.\nnoto-fonts, noto-fonts-cjk, noto-fonts-emoji, noto-fonts-extra와 같이 폰트 패밀리 전체를 선택하는 것도 좋은 옵션이 됩니다. 각종 웹 페이지에서 다양한 글자와 기호들을 사용하기 때문입니다.\n일부 배포판에 따라 noto-fonts-extra 등이 없을 수 있습니다. 사용하시는 배포판의 패키지 매니저를 활용해 noto같은 키워드로 검색해 결과를 확인하시기 바랍니다.\n중요한 것은 cjk가 포함된 폰트(noto-fonts-cjk처럼) 혹은 baekmuk(백묵), nanum(네이버의 나눔)처럼 한글을 표기할 수 있는 폰트를 설치하는 것입니다.\nibus 설치 우리에게 직접 필요한 ibus-hangul이 ibus에 의존하므로 ibus-hangul만 인자로 제공해 패키지 매니저를 실행해도 보통은 ibus와 함께 설치합니다.\n// Debian 계열 - Ubuntu, Mint $ apt install ibus-hangul // Red Hat 계열 - Fedora, CentOS, Rocky, Alma $ dnf install ibus-hangul // Arch $ pacman -S ibus-hangul // Gentoo $ emerge -av ibus-hangul /etc/environment ibus를 사용하기 위해서는 /etc/envrionment 파일 수정이 필요합니다.\n// 선호하는 텍스트 에디터로 파일을 엽니다 $ sudo vim /etc/environment 아래의 내용을 추가해줍니다.\nGTK_IM_MODULE=ibus QT_IM_MODULE=ibus XMODIFIERS=@im=ibus ibus 세팅 아래 명령을 수행하면, 창이 뜹니다.\n$ ibus-setup 데몬을 실행하냐는 창이 뜰텐데 Yes 하시면 됩니다.\n/etc/environment에 입력한 변수들을 설정하라는 알림이 뜰텐데 Yes 하시면 됩니다. 그리고 나면, 아래와 같은 화면이 표시됩니다.\nInput Method을 클릭합니다.\n여러분들의 화면에는 아직 Korean - Hangul이 없고, English - English(US)만 있거나 English조차 없을 수도 있습니다.\n참고로 Korean - Hangul만 제대로 추가되어 있으면 입력기 내부 언어 변경키를 활용해 영어와 한글을 모두 입력할 수 있습니다. 굳이, English를 유지할 필요가 없습니다.\n즉, 아래의 작업을 모두 성공적으로 마치신 분들은 다시 아래 화면으로 진입하셔서 English를 클릭하고 우측 버튼 중, Remove를 통해 제거하셔도 무방합니다.\n우측의 Add를 누릅니다.\n언어 목록이 뜹니다. 하단의 세로로 된 ⁞ 를 클릭합니다.\n입력창에 보시는 것처럼 korea를 입력합니다.\nibus-hangul이 제대로 설치되었다면 태극 문양의 Hangul이 표시되어야 합니다.\n해당 Hangul을 클릭하고 Add를 눌러 나옵니다.\n이제 입력기는 추가되었습니다.\n우측 Alt 혹은 한/영키를 이용해 입력기를 변경하기 위해서 Preferences 단추를 누릅니다.\n한글 입력기 내부에서 언어 변경을 어떻게 할 지 선택할 수 있습니다.\n참고로 시스템에서 한글 입력이 훨씬 잦으신 분들은 아래 Etc 항목에서 Start in Hangul mode를 체크해 두시는 것도 좋은 옵션입니다.\nHangul Toggle Key 메뉴에서 Add 버튼을 누릅니다.\n현재 제 이미지 상에는 화면 캡쳐를 하느라 Super_L이 찍혔는데 해당칸이 공란인 상태에서 한/영키로 활용하고자 하는 키를 입력하시면 Alt_R, 혹은 Hangul로 입력됩니다.\nOK를 클릭하셔서 설정을 완료하시면 됩니다.\n이제 웹 브라우저 등을 활용해 한글 입력이 잘 되는지 확인하시면 됩니다.\nst 터미널의 경우, dwm을 껐다가 켜는 수준이 아니라 재부팅을 하고서 제대로 동작한 적이 있습니다.\n표기된대로 따라왔음에도 불구하고 도저히 입력이 안되시면 로그아웃 이후 재 로그인, 혹은 아예 재부팅을 해보시는 것도 좋습니다.\n추후 부팅 시 자동 실행 설정 그래픽 데스크탑 환경, 예를 들어, Gnome, Plasma 등을 사용하시면 autostart 등의 옵션을 통해 $ ibus-daemon -drxR, 혹은 ibus 프로그램을 추가합니다.\n명령어 설명\n-d: 데몬으로 실행해 백그라운드에서 동작합니다. -r: 이미 실행 중인 데몬이 있다면 이번 실행으로 교체합니다. -x: ibus XIM 서버를 실행합니다. -R: 실행에 실패해도 패널과 설정 과정을 재시작합니다. 윈도우 매니저를 활용하시는 분들은 .xinitrc나 본인 윈도우 매니저의 autostart 설정을 통해 $ ibus-daemon -drxR을 추가합니다.\n윈도우 매니저의 경우\nautostart를 통한 $ ibus-daemon -drxR을 활용할 때 크고 작은 오류가 발생합니다. 한글 입력이 필요할 때, 직접 $ ibus-daemon -drxR을 실행하거나 키보드 단축키 세팅을 통해 해당 명령을 실행하시는 것이 수월합니다.]\n","permalink":"http://ptrtoj.com/kr/korean/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003ccode\u003efcitx\u003c/code\u003e, \u003ccode\u003escim\u003c/code\u003e 등도 잘 작동하는 것으로 알고 있습니다만,\u003cbr\u003e\n저는 리눅스를 처음 접했을 때부터 지금까지 \u003ccode\u003eibus\u003c/code\u003e를 사용중이므로 가이드는 \u003ccode\u003eibus\u003c/code\u003e 기준으로 작성합니다.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"들어가기-전에\"\u003e들어가기 전에\u003c/h2\u003e\n\u003ch3 id=\"1-gnome의-경우\"\u003e(1) Gnome의 경우\u003c/h3\u003e\n\u003cp\u003e이제 Gnome은 \u003ccode\u003eibus\u003c/code\u003e와 통합되어 개발됩니다. 대부분의 배포판에서, Gnome 데스크탑 환경을 사용하시는 경우라면, 아래 과정은 Settings 앱을 통해 진행하실 수 있습니다. Region \u0026amp; Language 옵션을 확인하세요!\u003c/p\u003e","title":"한글 입력 방법"},{"content":"the Grand Unified Settings Theory 특정 배포판의 기능에 대한 설명이 아닌 견해, 각종 프로그램에 대한 견해는 여기에 모두 합쳤습니다.\nGentoo + Dwm 😊 (dwm/st/dmenu는 패치 없이 소스 수정만 해서 씀미댜)\n선호도 기준 0. 문서화 기본적으로, 그리고 개인적으로, 큰 틀에서의 선호도는 문서화 정도에 따라 갈립니다.\n예를 들어,\n배포판의 경우, 옛 젠투 위키, 현 아치 위키 윈도우 매니저의 경우, Xmonad 터미널의 경우, kitty, 심지어 config 문서는 따로 존재함 컬러 테마의 경우, 드라큘라나 노드(Nord) 처럼 문서화가 잘 되어 있는 것을 선호합니다.\n1. 미니멀리즘 복잡성은 버그를 낳습니다. 제가 특별히 선호하는 기능이 아닌 경우, 가급적 심플하고 미니멀한 접근을 하는 것을 선호합니다(simple에 대한 재밌고 철학적인 컨퍼런스 영상). 그게 그냥 제 철학에 부합하기 때문이지 무조건 옳은 방향이므로 모두가 따라야 한다는 뜻이 아닙니다.\n-. 라이선스 반드시 GPL을 요구하지는 않지만, 그렇다고 Proprietary를 굳이 찾아서 쓰지도 않습니다.\nGPL + MIT + BSD + Apache 라이선스 선에서 사용하려고 애 쓰는 중\n-. 통일성 굳이 다른 언어로 구성하고 싶은 마음이 있지 않고서야\nLISP: GuixSD + EXWM + Emacs Haskell: (NixOS) + Xmoand Lua: (ANY) + Awesome + NeoVIM C: (ANY) + DWM + ST + Surf 처럼 구성도 가능합니다만 현재는 그렇게까지 추구하지 않는 기준입니다.\n배포판.old 0. 들어가기 앞서 *systemd는 크게 영향을 끼치지 않습니다. 사실, init system 논쟁에는 크게 관심 없습니다. 차라리 에디터 전쟁(Editor War : vim vs emacs)이나 들여쓰기 전쟁(Tab vs Spaces)이 더 꿀잼이라고 봅니다.*\n배포판 선정하기가 개인적으로 너무 힘들어서 다른 사람들에게 얘기하기에 민망한 수준으로 특이하고 까다로운 기준을 적용해왔습니다.\n1. 독립 배포판일 것 포기 못하는 기준\nUbuntu는 Debian에 기반하므로 탈락\nMint는 Ubuntu에 기반하므로 탈락\nSuse는 과거에 RedHat에 기반했으므로 탈락\nRedHat 계열과 Fedora는 서로 기반했던 시절이 있어서 탈락\nArtix, Manjaro, EndeavourOS등도 아치 리눅스에 기반하므로 탈락\n→ 살아남은 것 : Gentoo, Solus, Arch, Debian, Void, Venom, KISS, CRUX, LFS, NixOS\n2. 처음 만든 사람이 남아 있을 것 Gentoo는 다니엘 로빈스가 가출해서 Funtoo를 제작\nSolus도 첫 제작자 탈출\nArch도 쥬드 비넷 바빠서 탈출\nDebian은 이안 머독의 자살\nVoid는 제작자 연락 두절 이후 컴백하려 했으나 쫓겨남\n→ 살아남은 것 : Venom, KISS, CRUX, GUIX, LFS, NixOS\n3. Proprietary 지원 예를 들어, Google Chrome 혹은 Visual Studio Code 등 지원 여부\n‘철학(Only Free and Open Source)’을 이유로 리눅스를 쓰는 건 아니기 때문에 중요함\n→ 살아남은 것 : NixOS (LFS???, CRUX???)\n→ 앞선 기준에 부합하지 못했으나 주목할만한 것\nArch(AUR이 있음) Gentoo(공식 레파지토리에 웬만한 게 다 있음) FreeBSD(마찬가지) 4. 패키지 매니저 이름이 깔끔할 것 진짜 내가 생각해도 오반데; 어쨌든\n→ 살아남은 것\nNixOS : nix ←FHS 부합 안해서 vscode등 extension 설치가 쓸데없이 까다로워짐 ㅡㅡ LFS 패키지 매니저 자체가 없음. 현실적으로는 사용할 수가 없음 ㅠㅠ → 앞선 기준에 부합하지 못했으나 주목할만한 것\nFreeBSD → pkg : 다만, FreeBSD는 넷플릭스 시청(DRM 지원 안 함)이 문제 Alpine → apk : 다만, 클라우드 용도가 주목적이라 문제 배포판.new 일단 얘 얘기부터 → ArchLinux 가족 입원할 일 있어서 랩탑 챙기는데 당일 오전까지 고민하다 결국 손이 가는건 아치임 ㅇㅇ. 10분이면 설치 가능ㅋㅋ\n강점\nRolling Release라 Point Release 때마다 차라리 Fresh Install 할지 고민 안 해도 됨 AUR: vscode, google-chrome 싱크하고 싶은데 너무 편함 너무 속속들이 잘 알고 있어서 다른 거 배우는게 너무 귀찮; 단점 ← 끝까지 고민하게 만든 이유\n예전 기준에서 지적받았듯\n만든 사람이 이제 관리 안 함 ← 이게 뭐가 문제지? 하실 수도 있는데, 기존에 배포판을 설계했던 철학이 붕괴되어 갈 수 있어서 개인적으로 싫어합니다. Slackware의 Volkerding이 아직도 BDFL로써 개발하고 있는 것을 봐도 기존에 Slackware를 만들었던 이유와 철학이 매우 잘 유지되고 있을거라 추정할 수 있죠. 혹은 OpenBSD의 de Raadt도 그렇구요. 남들이 들으면 욕할지도 모르는 ‘그’ 기준: 패키지 매니저 이름.. pacman.. 음.. FreeBSD는 pkg임!! 그럼 FreeBSD 쓰지 왜 안 씀? 802.11ac 지원 상황 페이지 보셨나요? 어지간한 Wifi 칩셋은 지원이 안 됨. 즉, 어지간한 랩탑에서 FreeBSD를 사용하고자 한다면 Wifi 동글이 필수로 요구됨. 문제는 FOSS 철학 때문에 개발을 ‘안’ 하는 것이 아니라, 개발이 ‘더디다’는 것. 개발자가 모자라 도움이 적극적으로 필요한 상황임\n와이파이만 문제가 아니라서, 19년 출시 랩탑의 그래픽도 올리기 어려움. 결국 실패함 정작 OpenBSD에서는 별도의 명령어 입력이나 패키지 설치 없이 APU 확인하고 알아서 펌웨어 찾아다 설치해줘서 Xorg 바로 올라감. ㄷㄷ\n그럼 차라리 OpenBSD를 쓰지 왜 안 씀?? 패키지 매니저 이름.. 설치에 pkg_add, 검색에 pkg_info -Q, 업데이트에 pkg_add -U???? 안 씀!\n그럼 단점 이렇게 명확한데 대체 왜 고민함? 그것은 the ‘근본(根本)’ UNIX. 이기 때문\nGuixSD는 뭐가 문제임?? GuixSD 정말 좋음. 게다가 lisp 계열인 scheme 의 일종(dialect)인 guile로 만든 패키지 매니저와 운영 체제라니 ㄷㄷ 미침 모든 시스템 설정(configuration)을 lisp으로 가능ㅋㅋㅋㅋㅋㅋ\n여기에 EXWM으로 아예 풀 이맥스 환경 구축 가능ㅋㅋㅋ\n근데!\nGNU 진영 배포판 답게 아주 빡센 FSF 기준을 가지고 있음. 이게 왜?? 싶은 것도 포팅 안 됨. 예를 들어, firefox도 없음. 물론, non-guix로 설치 가능(firefox) 물론, flatpak으로 더한 것도 설치 가능(chrome, vscode) 근데 커널도 GNU Hurd를 최종 목표로 일단 linux-libre를 사용, init system도 systemd는 바라지도 않지만 openrc, SysV도 아니고 GNU Sheperd 임 물론, 일반 linux 커널도 non-guix로 설치 가능 물론, non-free firmware blob도 non-guix로 설치 가능 이래저래해도 어쨌든 다른 배포판(Arch, Nix)은 그냥 되는 걸 실현하기 위해 별도로 만져야 되는 게 귀찮..\n그리고 추가로 아주 사소한 불만이 있는데\nemacs 지원이 너무 훌륭한 바람에 여기서 올린 config 파일은 외부와 sync하며 쓰기 어려워짐. 물론, 그냥 use-package 쓰면서 사용하면 상관 없는데 그러면 Guix 쓰는 이유가??… 역시나 사용자 수가 깡패다. ibus-hangul v1.5.3 ㄷㄷ… 작성 시점 22년 8월 30일 기준, v1.5.4 출시가 20년 8월 23일로 무려 2년 전임 ㄷㄷ.. (”그럼 니가 버전 범프 해주지??” 는 좋은 지적임요. ㅇㅈ) Nix는 뭐가 문제임?? vscode 익스텐션 관리 ㄷㄷ함. 함수형 패키지 매니저를 쓰는 만큼 FHS에 부합하지 않기 때문.\n그래도 nix-shell이 개발 환경 후딱 구축하기에 깡패라는 점도 꼭 적어야 함\n또 하나의 예민 포인트이지만 stateVersion이 20.03이든 21.05든 현재로썬 수정하지 말라고 연신 경고하는 것도 애매합니다. 물론 이유는 납득을 했는데 선언식 배포판에서 버전 변수가 설치 당시 시점 연도와 월로 고정되있는게 참 보기 싫어요.\n옵션 변수명 바뀌는 것(exfat-utils → exfat)도 그렇고 여러모로 더 무르익으면 쓰기 좋을 것 같습니다.\n함수형 패키지 매니저 및 배포판들 결론적으로 시간이 지나면 최광자 자리를 탈환할 것 같아요.\n배포판-하여튼 그래서 결론은? Arch Linux Python 같은 배포판\n후딱 올려서 테스트 하기 너무 좋음\n넉넉잡고 10분이면 설치함\nGentoo Linux C 같은 배포판\nVoid Linux Haskell 같은 배포판\n아주 매력적이지만 아무도 안 써서 쓰기 귀찮음(특히, 패키지 버전 범프)\nCrux Linux ???\nLFS, BLFS ASM 같은 배포판 책\nUbuntu 이거 완전 Objective-C 꼴 아님?ㅋㅋㅋㅋㅋㅋ\nDebian C++ 같은 배포판\nSlackware Fortran 같은 배포판\nFedora Java 같은 배포판 1\nCentOS Java 같은 배포판 2\nRHEL Java 같은 배포판 3\nOpenSUSE C# 같은 배포판\n그래도 롤링 릴리즈 있으니 점수 0.01점 더 줌\n픽스드로 Leap, 롤링으로 Tumbleweed가 있음\n근데 Tumbleweed 업데이트 명령어로 $zypper up가 맞냐 $zypper dup가 맞냐로 자기들 내부에서도 싸웠던 전적이 ㅋㅋㅋㅋㅋ\nNixOS 이게 이제 미래형이니까 Rust 같은 배포판이라고 하면 되려나 ㄷㄷ\n사실은 Nix 그 자체ㅋㅋㅋㅋㅋ\nGuixSD Lisp 그 자체ㅋㅋㅋㅋㅋ\n그러나 Guile로 변장하고 매복 중\n데스크탑 환경(DE) Gnome 이젠 더 이상 Plasma나 XFCE를 선호할 이유가 없어보임\n다만, Gnome Terminal Ligature 지원 좀.. 제발 ㅠㅠ Konsole은 되잖아 ㅠㅠ 굳이 외모 때문에 별도 터미널을 설치하기는 또 귀찮은데.. 🤔우\nGnome을 선호하면 속 편한게 어지간한 배포판은 default 느낌으로 Gnome을 가져다 씁니다 ㅋㅋㅋ\nPlasma 그러나, Plasma가 유독 마음에 든다면 선택지가 줄어들죠. 아니면 고수가 되어서 ArchLinux나 Gentoo에 올려도 좋구요. 다만, Gentoo에 Plasma-meta를 컴파일한다고 생각하면 ㄷㄷ\nXFCE 무지 오래된 냄새나는 그런 데스크탑 환경이었는데 뜬금없는 대규모 업데이트 이후 세련되게 변했습니다 ㅋㅋ\nCinnamon/Mate 할머니용\n안 좋다는 뜻 아님. 아주 편함. 건드릴 게 없음\n특히, Linux Mint로 둘 중 하나 에디션을 사용하면 거의 윈도우즈 급 ㅋㅋㅋ\nBudgie Evolve OS에서 꺼내놓더니 Solus로 배포판 이름이 바뀌었다가 Solus는 어디가고 Budgie라는 명작만 남김ㅋㅋㅋㅋ\n키 바인딩 윈도우 매니저, 특히 에디터 얘기에 들어가기 전에 키 리맵 얘기를 하려고 합니다.\nVIM의 h,j,k,l과 esc로 모드를 변경하는 것, 심지어 유닉스에서 ~가 홈을 의미한게 된 것들은 ADM-3A 터미널에서 유래합니다.\n특히, 프로그래밍이 가능한 40% 키보드 등을 사용한다면 현재의 TAB을 ESC, CAPS LOCK을 CTRL로 옮기면 소위 얘기하는 emacs pinky 같은 a repetitive strain injury (RSI)를 방지할 수 있습니다.\n윈도우 매니저(WM) 당연히 compositor는 picom이죠. compton is now deprecated.\nDWM 미니멀 EXWM Emacs!! Lisp!!\n터미널 고를 필요 없음 bash vs zsh vs fish 고민할 필요 없음 물론, picom은 쓰게될 확률이 높음 선택에 따라 polybar같은 스테이터스 바를 쓸 수도 있음 그러나 아아.. 단일 쓰레드.. BSPWM 진짜 윈도우 매니저 역할만 함 따라서 키 바인딩을 위해 sxhkd 필요 Xmonad Haskell!! i3 는 gaps 지원 안 됨\n근데 gaps 왜 쓰냐는 사람도 많음. 그럴 거면 그냥 DE 쓰지. 화면 자원 아깝다고 WM 쓰면서 gaps를 이해하지 못하는 사람들도 많더라구요.\n어쨌든 gaps를 위해서는 i3-gaps라는 포크 프로젝트를 설치하게 됨\nSway 흠 wayland에서는 picom이 필요 없다라 🤔\n흠 다만 video driver 쪽 아쉬움이 있다라 🤔\nAwesome Lua!!\nNeoVIM도 Lua!! 루아로 대동단결!!\nApp Launcher Dmenu Suckless에서 제일 잘 난 아들이 아닐까;; (dmenu \u0026gt; dwm \u0026gt; st \u0026gt; surf 순?)\nRofi Dmenu가 심심하다고 느끼는 분들이 제일 많이 쓰는 대체품으로 보임\nStatus Bar Polybar 다 됨\nLemonbar 아직 안 써봄\nShell sh 와…\nZsh oh-my-zsh\nprompt → pure\nFish POSIX compatible 논란이 있었죠 ㅋㅋㅋㅋ\nCsh BSD 냄새 1\nKsh BSD 냄새 2\nDash 우분투네 쉘\nBash 디폴트 냄새\nEditor 이제 config 직접 수정 안하고 그냥 문서화 가장 잘 되어 있는 번들 사용 합니다.\nNeoVIM → AstroNvim, LuanrVim 등\nEmacs → Doom Emacs 등 살펴보세요\nHelix Rust 최고!\nNeoVIM Lua로 통일!!\n이긴한데, neovim 잘 쓰다가 생각난 게 제가 fork 프로젝트를 정말 비선호하나봅니다. 어차피 처음 만나는 서버에 ssh 하더라도 디폴트 vim에서도 날아다닐 수 있는건 바뀌지 않기 때문에 그냥 neovim을 포기하고 vim이 시스템에 그냥 설치되어 있으면 그거 씁니다.\n이유 1: vim → nvim alias 도저히 귀찮. 특히, 저처럼 배포판 이것저것 돌아다니고 이것저것 계속 바꿔 설치하는 사람은 더 귀찮 이유 2: root환경에 추가로 vim 을 alias하거나 시스템 단위에서는 또 별도로 vim 설치 (예를 들어, NixOS configuration.nix에서는 vim을, home-manager에서는 neovim을 이 따위로)해야 해서 귀찮 이유 3: 결국 vim 개발 방향도 맘에 안들고 그렇다고 앞에 neo- 붙은 커뮤니티 개발 neovim도 꺼림칙함 Vim is everywhere.\n다만, ${XDG_CONFIG_HOME} 지원 좀… ㅂㄷㅂㄷ\nEmacs is everything, but not an editor\nvim에서 dd로 줄을 지울 수 있다면 emacs에선 C-a C-k입니닼ㅋㅋ\nvim에서 o로 커서 아래에 공백열을 넣을 수 있다면 emacs에선 C-e C-j입니닼ㅋㅋ\nvim에서 O로 커서 위에 공백열을 넣을 수 있다면 emacs에선 C-a C-j C-p입니닼ㅋㅋ\n(참조)\n가능한 플러그인을 줄이고자 하는 스타일이지만, 정작 에디터 기능 관련해서는 evil이 필요할지도?\nVisual Studio Code 돈이 최고다.\nTerminal st 사실상 기본적인 기능도 패치해서 써야되는게 너무 귀찮..\nurxvtc rxvt-unicode a.k.a urxvt, with daemon feature\nalacritty 사용자들은 rust로 쓰인 것을 이유로 들며 아주 선호함\n2017년 1월 5일부터 요구되어 온 ligature 지원은 아직도 안되지만 이슈 쓰레드는 스팸으로 처리, 닫아버린다(?)\nkitty 비판자들은 python으로 쓰인 것을 이유로 들며 아주 싫어함\n원격 서버 접속 기능 이슈 있음. 이에 대한 제작자 반응(1, 2)이 ㄷㄷ alacritty와 크게 다를 건 없네요 ㄷㄷ\nTermite 안 써 봄\nFonts 본인이 어떤 터미널을 사용하든지 일부 글자가 박스로 깨져서 나오는 현상은 터미널 자체의 문제라기보단 일반적으로 폰트의 문제인 경우가 많습니다(물론 st처럼 하드코어한 경우, 패치 문제겠지만; 이걸 읽는 분들이 그걸 모를리는 없고;)\n따라서 기본적인 이모지 테스트와 유니코드 테스트를 해볼 수 있는 명령을 제공합니다.\n## Emoji $ curl https://unicode.org/Public/emoji/5.0/emoji-test.txt ## Unicode $ curl https://www.cl.cam.ac.uk/~mgk25/ucs/examples/UTF-8-demo.txt 일부 아이콘이 제대로 안 뜨는 경우 → 패치된 폰트를 사용(링크) 일부 유니코드(외국어)가 제대로 안 뜨는 경우 → DejaVu Fonts를 사용(링크) 메인으로 쓰고 싶으신 폰트를 둔 채로 fallback 폰트를 위의 것들로 지정하시면 됩니다.(링크) Nerd Fonts 너드 폰트\nBerkeley Mono (유료, link)\n기본 팩 만으로 좋지만, 일부 아이콘 지원을 위해 nerd fonts, → font patcher로 패치함: 아래 NFM\nBerkeleyMono NFM (Personal, Patched)\n라이선스 때문에 어디 업로드해두지 못함\n아이콘도 추가되었지만 기본 폰트에서 일부 ligature를 지원하지 않음업데이트 됨. 따라서 아래 Fira Code 혹은 nerd fonts의 FiraCode NFM을 설치하면 더 좋음\nFira Sans, Fira Code Fantasque Sans Mono Font Awesome IBM Plex 개인적으로 한글 폰트도 맘에 듬 (IBM Plex CJK KR)\nJetBrains Mono Powerline Color Theme Nord 뭐.. 근데 예쁜건 노드ㅋㅋㅋ(링크)\nArchLinux에 Nord 테마를 쓰게 되면 AUR에서 아래를 설치합니다ㅋㅋ\nNord-KDE Nord-GTK Nord-Icons Nord-Konsole Solarized by. Ethan Schoonover\nthe 근본(링크) 이지만 요즘은 다들 잘 안 쓰는 것으로 보임ㅋㅋ\n자세한 이야기\nModus light: operandi, dark: viviendi\nby. Protesilaos Stavrou (웹사이트, 유튜브)\n아아.. Emacs 근본?(링크)\nDracula (링크)\nGruvbox E-mail Service ProtonMail 개인 이메일 서버 구축은 한 번쯤 도전해보세요! Gmail에게 황송해질 겁니다! ㅋㅋㅋㅋㅋㅋㅋ\n아! 프레임워크 말구요ㅋㅋ Postfix + Dovecot + SpamAssassin + OpenDKIM 세팅을 말하는 겁니다 ㅋㅋㅋㅋㅋ\nPassword Manager PM을 사용하기 시작하면 특히 웹 브라우저의 비밀번호 저장, 결제 수단 저장, 주소 저장을 끄는 것을 권장합니다. PM을 쓴다고 안전해지는 것이 아니라 오히려 공격 타겟을 한 곳으로 집중시키는 노릇을 합니다. 따라서, 긴 기본 비밀번호 + 2FA + 생체 인증 등을 활용해 이 곳은 무조건 사수해야 합니다. Bitwarden 처음 써본건데 제일 좋아서 씀 1password 안써봄 LastPass 안써봄 2FA Auth App Aegis GPL\nDomain Service Namecheap Cafe24 한국 도메인 특히 .kr, .co.kr, 등 구매하려면 별다른 방법 없음\nVPS Vultr 서울 리젼 지원함\nLinode Digital Ocean 서울 리젼 지원되는지 확인해야함. Vultr랑 고민할 때는 지원을 안 했음.\nCDN Cloudflare ","permalink":"http://ptrtoj.com/kr/gust/","summary":"\u003ch2 id=\"the-grand-unified-settings-theory\"\u003ethe \u003cstrong\u003eG\u003c/strong\u003erand \u003cstrong\u003eU\u003c/strong\u003enified \u003cstrong\u003eS\u003c/strong\u003eettings \u003cstrong\u003eT\u003c/strong\u003eheory\u003c/h2\u003e\n\u003cp\u003e특정 배포판의 기능에 대한 설명이 아닌 \u003cstrong\u003e견해\u003c/strong\u003e, 각종 프로그램에 대한 견해는 여기에 모두 합쳤습니다.\u003c/p\u003e\n\u003cp\u003e\u003cimg alt=\"gust\" loading=\"lazy\" src=\"/gust-setup.png\"\u003e\n\u003cstrong\u003eGentoo + Dwm\u003c/strong\u003e 😊 (dwm/st/dmenu는 패치 없이 소스 수정만 해서 씀미댜)\u003c/p\u003e","title":"통합 세팅 이론"},{"content":" This is a translated work.\nThe original post was written by Tim Pope and you can read it here.\nOn 11, July. 2022, permission was granted via e-mail.\n이 문서는 번역본입니다.\n원본은 팀 포프(Tim Pope)에 의해 작성되었으며, 다음 링크를 통해 읽을 수 있습니다.\n이메일을 통해 22/07/11 번역 허가를 받아 작성 후 업로드 합니다.\n깃 커밋 메시지 관련하여\n19 Apr 2008\n잘 구성된 커밋(Commit) 메시지가 무엇인지 좀 더 상세히 적고자 시간을 할애 합니다. 깃(Git)을 더 위대하게 만드는 사소한 디테일 중 하나가 바로 커밋 메시지 형식 관행이라고 생각합니다. rails.git의 초기 커밋 중 일부가 굉장히-긴-줄의 메시지 형태를 갖게 된 이유는 이해할만하지만, 왜 이게 안 좋은 것인지 자세히 살펴보고자 합니다.\n아래는 깃 메시지 영문 예시입니다:\nCapitalized, short (50 chars or less) summary More detailed explanatory text, if necessary. Wrap it to about 72 characters or so. In some contexts, the first line is treated as the subject of an email and the rest of the text as the body. The blank line separating the summary from the body is critical (unless you omit the body entirely); tools like rebase can get confused if you run the two together. Write your commit message in the imperative: \u0026#34;Fix bug\u0026#34; and not \u0026#34;Fixed bug\u0026#34; or \u0026#34;Fixes bug.\u0026#34; This convention matches up with commit messages generated by commands like git merge and git revert. Further paragraphs come after blank lines. - Bullet points are okay, too - Typically a hyphen or asterisk is used for the bullet, followed by a single space, with blank lines in between, but conventions vary here - Use a hanging indent 아래는 깃 메시지 한글 예시입니다:\n첫 글자 대문자, 50글자 이내의 짧은 요약 필요한 경우, 더 자세히 설명. 줄 바꿈은 72 글자 근처에서. 몇 상황에서 첫 줄은 이메일의 제목으로도 활용되고 나머지 텍스트는 본문에 쓰임. (본문을 통째로 생략하는 경우가 아닌 이상) 제목과 본문을 구분 짓는 한 줄의 공백이 중요함; rebase 류의 도구들은 구분 짓지 않은 경우 오작동 할 가능성이 있음. 명령형으로 커밋 메시지를 작성할 것: \u0026#34;버그 수정\u0026#34;식으로. \u0026#34;버그 고쳤음\u0026#34; 혹은 \u0026#34;버그 고치는 중\u0026#34;은 안 됨. 이런 관습을 통해 git merge나 git revert 등의 명령어로 생성된 커밋 메시지와 일치하게 됨. 추가 문단은 추가 공백 줄 이후 적음. - 글머리 기호를 사용하는 것도 괜찮음 - 통상적으로, 빈 줄 사이의 문장에서 공백 사이에 들어 있는 하이픈(\u0026#39;-\u0026#39;)이나 별표(\u0026#39;*\u0026#39;)가 글머리 기호로 활용되나 이 관례는 다를 수 있음 - 행잉 인덴트(*바로 아래 설명 참조)를 사용할 것 행잉 인덴트(hanging indent): 단락의 두 번째 라인 및 후속 행의 인덴트 또는 한 라인 보다 큰 표시물의 인덴트. ⇒규범 표기는 미확정이다.\n일단 왜 72 글자 제한을 두는지 몇 가지 이유를 살펴보겠습니다.\ngit log는 커밋 메시지의 자동 줄바꿈(wrap)을 전혀 하지 않습니다. 기본 페이저인 less -S를 사용하는 경우, 문단이 스크린 끝까지 너무 멀리 가버려 읽기 매우 어렵게 만든다는 것을 의미하죠. 세로 80 줄 터미널에서 좌측에 들여쓰기를 위해 4 글자를 빼고 우측에 균형을 위해 똑같이 4 칸을 제외하면 72 칸이 남습니다. git format-patch --stdout 는 메시지를 본문으로 하여 일련의 커밋들을 연속된 이메일로 변환합니다. 잘 만들어진 이메일 네티켓 지시 사항들을 보면, 답장으로 생기는 지시자 들여쓰기를 감안해도 세로 80 줄의 터미널에서 화면의 가로로 내용이 넘어가지 않도록 하기 위해 일반 텍스트(plain text) 이메일을 미리 래핑하도록 요구합니다. (물론 현재 rails.git 업무 방식은 이메일을 수반하지 않습니다만 미래에 이메일을 활용할지 누가 알겠습니까.) Vim 사용자들은 이런 요구 사항을 내 vim-git 런타임 파일을 설치해 만족 시킬 수 있고 혹은 다음 옵션을 Git 커밋 메시지 파일에 추가해 달성할 수도 있습니다:\n:set textwidth=72\nTextmate의 경우, view 메뉴 아래 “Wrap Column(줄 바꿀 열)” 옵션을 조정할 수 있는데, 이후 ^Q를 이용해 문단을 원하는 대로 다시 래핑할 수 있습니다 (코멘트들이 섞이는 것을 피하기 위해 빈 줄이 추가된다는 점을 명심하세요). 아래는 매번 선택을 위해 드래그 하지 않기 위해 메뉴에 72를 추가하는 쉘 명령어 입니다:\n$ defaults write com.macromates.textmate OakWrapColumns '( 40, 72, 78 )'\n본문 정렬 방식보다 훨씬 중요한 것은 제목을 다는 것입니다. 예시에서 보인 것처럼, (타협 불가능한 제한 사항까지는 아니지만 가급적) 50 글자를 목표로 삼아야 합니다. 그리고 항상, 무조건 한 줄을 비우세요. 첫 줄은 커밋으로 인해 생기는 변화들의 구체적 요약이어야만 합니다; 만약 기술적인 디테일이 이런 엄격한 글자 수 제한 안에 표현하기에 너무 많다면, 차라리 본문에 넣기 바랍니다. 제목 줄은 깃 전반에 걸쳐 활용되며, 너무 긴 메시지가 사용되면 뒷 부분이 짤려 나가는 경우가 많습니다. 다음은 그런 식으로 짤려 나간 제목들의 종착점입니다:\ngit log --pretty=oneline 은 커밋 id와 요약으로 구성된 상세한 과거 기록을 보여줌 git rebase --interactive 은 에디터에서 요청하는 항목의 커밋 요약을 보여줌 설정 옵션 merge.summary 이 켜져 있는 경우, 통합된(Merged) 커밋들의 모든 요약이 머지 커밋 메시지에 포함됨 git shortlog 는 요약 부분의 내용을 명령어가 출력하는 체인지로그-스타일의 아웃풋에 가져다 씀 git format-patch, git send-email, 과 관련 도구들은 짤린 제목으로 가져다 이메일 제목으로 씀 reflogs라는 git reflog 명령을 통해 접근 가능한 로컬 기록은 멍청한 실수로부터 복구하고자 존재하는데, 요약에서부터 복사본을 가져옴 gitk 는 요약을 위한 탭이 존재함 깃허브(GitHub)는 사용자 인터페이스 곳곳에 요약을 활용함 제목/본문 구분은 사소해 보일 수 있으나 서브버젼(Subversion)에 비해 깃 히스토리가 훨씬 더 작업하기 좋다고 느끼게 만드는 다양한 세부 요인 중 하나입니다.\n","permalink":"http://ptrtoj.com/kr/commit/","summary":"\u003cblockquote\u003e\n\u003cp\u003eThis is a translated work.\u003c/p\u003e\n\u003cp\u003eThe original post was written by Tim Pope and you can read it \u003ca href=\"https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html\"\u003ehere\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eOn 11, July. 2022, permission was granted via e-mail.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cblockquote\u003e\n\u003cp\u003e이 문서는 번역본입니다.\u003c/p\u003e\n\u003cp\u003e원본은 팀 포프(Tim Pope)에 의해 작성되었으며, 다음 \u003ca href=\"https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html\"\u003e링크\u003c/a\u003e를 통해 읽을 수 있습니다.\u003c/p\u003e\n\u003cp\u003e이메일을 통해 22/07/11 번역 허가를 받아 작성 후 업로드 합니다.\u003c/p\u003e\n\u003c/blockquote\u003e","title":"Git 커밋 메시지에 대하여"},{"content":"올바른 비밀번호 설정 방법\n서문 사이버 보안에 관심이 많거나, 개발 직종에 근무하시는 분들은 이미 알고 있는 내용이겠지만 그렇지 않은 분들이 너무 많은 오해를 하고 있거나 관심이 없는 것 같아서 적습니다.\n아래에서 쉬운 이해를 위해 ‘해킹’, \u0026lsquo;추측\u0026rsquo;까지 소요되는 예상 시간이라고 적고 있으나, 엄밀하게 말하면 그 자체로 ‘해킹’이라기 보다는 ‘비밀번호 찾는 것만을 목표로 했을 때 정답을 찾을 때까지 소요될 예상 시간’입니다.\n최근에는, 보안을 위한 다양한 방법 중 웹사이트 측 방법론인 ‘공격 시도와 또 다른 시도 사이의 물리적인 시간 자체를 늘리는 쪽’으로 개발하기 때문에, 현실에서는 훨씬 오랜 시간이 걸릴 수 있습니다.\n예를 들어, 비밀 번호 n회 연속 오류 시, 물리적으로 x분 간의 로그인 시도 자체를 차단하는 것, 은행들의 경우 아예 창구를 방문해야만 접근 해제를 풀어주는 방법까지 사용합니다.\n그러나 이 글에서 소개하는 여러 가지 방법을 활용하면, 시스템 측에 의존하지 않고 스스로도 안전한 비밀번호를 생성할 수 있을 것으로 기대합니다.\n현 상황 일반적으로 알고 있는 \u0026lsquo;안전한 비밀번호\u0026rsquo;의 개념은 완전히 잘못되어 있습니다.\n최근 한국의 일부 웹사이트에서 요구하는 비밀번호 요구 사항은\n특수 문자를 0~2개(사이트 별로 상이) 요구 대문자 요구 ← 큰 의미가 없음 글자 수 20자 이내 ← ‘이내’ 자체가 말도 안 되는 요구임 등 입니다.\n저 조건들을 만족한다고 안전한 것이 아닙니다.\n더불어, 저 조건들을 더 잘 조합했다고 안전해지는 것도 아닙니다.\n예시 그럼 예를 들어 보겠습니다.\n아마도 김 아무개씨가 쓸 것으로 보이는 비밀번호 \u0026lsquo;kimcat02\u0026rsquo;의 경우, 추측에 \u0026lsquo;14.04분\u0026rsquo;이 소요됩니다. 요즘엔 저런 비밀번호로는 가입 단계에서 거절되므로, 조건을 하나씩 부합시켜 보겠습니다.\n각 단어를 대문자로 변경한 \u0026lsquo;KimCat02\u0026rsquo;의 경우, \u0026lsquo;53.25 \u0026lsquo;으로 늘어났습니다. 1시간이 채 걸리지 않습니다.\n예상 소요 시간 관련\n등장할 예상 소요 시간은 모두 유틸 사이트의 예상치입니다만 계산 사이트가 다르다고 결과가 크게 상이하지는 않습니다.\n아! 그런데 특정 웹사이트들은 IT 업체 답게 특수 문자를 요구하죠! 그것도 3개를 넣으라고 합니다. \u0026lsquo;!Kim@Cat#02\u0026rsquo;를 했더니 \u0026lsquo;27년\u0026rsquo;이 걸립니다. 27년이면 괜찮아 보이나요? 어떤가요? 이 글을 끝까지 읽으시면 매우 놀라실 겁니다.\n또 다른 문제: 비밀번호 3개월/6개월마다 변경? 그럼 비밀번호를 일정 기간마다 변경하는 것은 의미가 있을까요?\n아니요.\n해킹 공격은 \u0026lsquo;당했다/안 당했다\u0026rsquo;로 나뉘지, \u0026lsquo;비밀번호가 새로운 거다/조금 오래된 거다/아주 오래된 비밀번호다\u0026rsquo;로 나뉘지 않습니다. 해킹 공격자가 대상으로 삼은 웹사이트에 내가 회원인데 마침 그 때 내 비밀번호 자체가 쉬운 것으로 되어 있는 것이 문제지 바로 이틀 전에 변경했다는 점은 해킹 방어에 그 어떤 도움도 되지 않습니다.\n해답 해답은 \u0026lsquo;길이\u0026rsquo;에 있습니다.\n비밀번호의 복잡도가 한정된 길이에서 증가하는 것보다 차라리 물리적인 길이 자체가 늘어나는 게 더 효율적입니다.\n아까 27년이라 괜찮아 보였던 예시를 가져오겠습니다. 해당 비밀번호는 \u0026lsquo;!Kim@Cat#02\u0026rsquo;였습니다.\n차라리 대문자, 특수 문자를 빼고 원래 11 글자였던 비밀번호의 길이를 22 글자로 늘리면 어떻게 될까요?\n\u0026lsquo;kimcatwoodskywaterpark\u0026rsquo;는 정확히 22 글자이고 해킹에 소요되는 시간은 \u0026lsquo;3,100년\u0026rsquo;이 걸린다고 나옵니다.\n전체 길이가 늘어나면 한 자리, 한 자리에 소요되는 경우의 수가 ‘알파벳 개수의 제곱 형태(자릿수를 22 자리로 한 경우 262226^{22}2622)로 증가하기 때문에 훨씬 효율적입니다.\n대소문자와 특수 문자를 포함 시켜 봐야 늘어나는 자리당 경우의 수 열 댓가지 보다 차라리 제곱을 11 제곱에서 22 제곱으로 늘리는 것이 자릿수만 충분하다면 무조건 더 큰 숫자이기 때문입니다.\n그렇다면, 길이를 늘리는 것은 알겠는데 그렇게 긴 비밀번호를 잘 외울 수 있을까요? 여기서 아래 두 파트 \u0026lsquo;한국인이라 갖는 장점 \u0026lsquo;과 \u0026lsquo;나만의 알고리즘 \u0026lsquo;이 중요합니다.\n한국의 상황\n그런데도 한국의 일부 웹사이트는 가입 시점부터 이미 20글자 이내로 설정하도록 요구합니다.\n더 어이 없는 경우는 가입시점엔 20글자 이상을 입력했는데도 필터링 되지 않고 로그인 시에 20 글자까지만 입력되어 로그인을 할 수 없는 촌극이 벌어지는 것입니다.\n해당 사이트 이름을 밝히고 싶지만, 고소가 무서워서 여기서 적진 않겠습니다. 컴퓨터 소프트웨어 제조사 홈페이지 소수와 정부 부처 홈페이지 다수가 그렇습니다.\n한국인이라 갖는 장점 한국인이라서 갖는 특이한 강점이 하나 있습니다.\n물론 따지고 보면 모든 비 영어권 국가 사람들이 갖는 강점이긴 합니다.\n바로, 외국인들이 사전 공격(Dictionary Attack; 완전히 무작위한 단어를 사용하지 않을 것을 감안해 사전에 등장하는 단어를 통해 공격하는 기법)을 하기 위해 사용하는 영단어를 쓰지 않을 수 있다는 점입니다.\n집에서 키우는 반려견 이름을 꼭 비밀번호로 활용하고 싶더라도 (하필 또 그 이름이 영단어인 \u0026lsquo;초코 \u0026lsquo;일지라도) 비밀번호를 \u0026lsquo;choco \u0026lsquo;로 쓰기보다 \u0026lsquo;chzh \u0026lsquo;로 쓰는게 낫습니다.\n억지 비교 아주 무식한 케이스지만 그냥 단순 비교를 위해 ‘choco’와 ‘chzh’ 둘 자체의 비밀번호 공격 소요 시간을 비교해보면 1.61초 vs 22.85초로 산출됩니다.\n놀라운 점은 한글을 단순히 영타로 친 \u0026lsquo;chzh \u0026lsquo;의 경우 오히려 한 글자가 적다는 점입니다.\n따라서 비밀번호에 사용할 단어들이 영단어일지라도 가급적 한글 발음으로 적듯이 적는 것이 낫습니다.\n(조바심에 더 적는 예시: \u0026lsquo;password \u0026rsquo; - \u0026gt; \u0026lsquo;votmdnjem \u0026rsquo; 또는 ‘qlalfqjsgh’ , \u0026lsquo;bank \u0026lsquo;- \u0026gt; ‘qodxm’ 또는 \u0026lsquo;dmsgod \u0026rsquo; 등)\n나만의 알고리즘 그래도, 모든 웹사이트에서 동일한 비밀번호를 사용한다면, 한 군데에서 혹시나 해킹에 성공하거나, 또는 내 비밀번호가 실수로 유출되는 경우(예. 은행 비밀번호가 적힌 통장 자체를 분실) 모든 사이트에서 공격을 받게 됩니다.\n따라서, 본인만의 알고리즘을 생성하면 매우 유용합니다. \u0026lsquo;알고리즘 \u0026lsquo;이라는 단어를 사용해서 막 어려울 것 같은 기분이 들지만 전혀 그렇지 않습니다. 안 그래도 길어져서 외우기 힘들어진 비밀번호를 외우기 쉽게 해주기도 합니다.\n알고리즘을 만든다는 뜻은 본인이 웹사이트 가입을 할 때 혹은 이 글을 읽고 설득되어 현재 가입한 사이트들의 비밀번호를 변경하고자 할 때, 규칙을 정하는 것입니다.\n자, 이런 식입니다.\n(각 사이트 비밀번호 = (내이름)#(내가제일좋아하는동물)#(내가태어난도시)#(가입하려는사이트이름)\n적용한다면 이렇습니다.\n네이버를 가입한다고 하면, 비밀번호는 (전우형)#(강아지)#(서울)#(네이버).\n이렇게 보면 너무 쉬워 보이지요? 그러나 전체를 전환해보면 다음과 같아집니다.\nwjsdngud#rkddkwl#tjdnf#spdlqj\n특수 문자 에이, 너도 특수문자 넣네? 라고 하실수도 있는데, 특수 문자 넣는 것 자체에 반대하는 것도 아닐 뿐더러 파트를 구분하기에도 용이해서 적극 활용할 수 있습니다.\n본인이 좋아하는 숫자 순서가 있다면 해당 순서로 특수 문자를 삽입하는 것도 좋습니다.\n예를 들어, 3278을 비밀번호로 자주 사용하는 사람이라면 \u0026lsquo;가나다#비밀번호 @예시\u0026amp;특수문자 * \u0026lsquo;와 같습니다.\n아까 활용하던 사이트에 입력해볼까요? 소요 예측 시간은 \u0026lsquo;4 hundred trillion trillion trillion years\u0026rsquo;로 나왔습니다.\n이게 그러니까 검색해보니, \u0026lsquo;400 * 조 * 조 * 조 년\u0026lsquo;이 걸린다는 얘기네요.\n이렇게 웹사이트마다 다른 비밀번호를 손쉽게 만들어낼 수 있습니다.\n그래서 결론은? 무조건 길이를 길게 만드는 것이 좋습니다. 한국인이라는 장점을 십분 활용해야 합니다. 본인만의 비밀번호 생성 알고리즘이 필요합니다. 일부 한국 웹사이트의 보안 요구 사항은 반드시 수정 되어야 합니다. ","permalink":"http://ptrtoj.com/kr/passwd/","summary":"\u003cp\u003e올바른 비밀번호 설정 방법\u003c/p\u003e\n\u003ch2 id=\"서문\"\u003e서문\u003c/h2\u003e\n\u003cp\u003e사이버 보안에 관심이 많거나, 개발 직종에 근무하시는 분들은 이미 알고 있는 내용이겠지만 그렇지 않은 분들이 너무 많은 오해를 하고 있거나 관심이 없는 것 같아서 적습니다.\u003c/p\u003e","title":"올바른 비밀번호 설정 방법"},{"content":"서문 Dotfiles를 관리하는 방법을 수동, Git 활용, 심볼릭 링크 활용, GNU stow 활용의 단계로 정리하였습니다.\nDotfiles 유닉스 관련 시스템(Unix, BSD, Linux 등)에서는 파일명 앞에 .을 붙이는 경우, 숨긴 파일이 되어 ls만으로는 파일을 보이지 않습니다. 이를 활용해, 각종 프로그램 설정이 담긴 일반 텍스트 파일을 .을 붙여 활용해왔습니다.\n예를 들어, Hello 라는 프로그램을 제작하는 단계에서,\n실행 시점에 덮어 씌울 각종 설정을 담은 텍스트 파일을 .hello로 요구하기로 하고, (설정 파일이 기본 명령어인 $ls에 까지 보일 필요가 없으므로, \u0026lsquo;. \u0026rsquo; 을 붙이기로 함)\n혹시 해당 파일이 있는지 확인 할 경로로 ~(유저 홈 디렉터리)를 결정한 경우, (사용자가 특별히 요구하는 설정이 있으면 기본 옵션이 아니라 그것을 적용해 실행해야 하므로)\n사용자들은 ~/.hello라는 파일을 생성하고 본인의 입맛에 맞는 설정값들을 해당 파일에 적어둘 수 있게 됩니다.\n이렇게 설정 파일들이 대부분 dotfile(점을 붙인 파일)이기 때문에 설정 파일들을 모두 통틀어 dotfiles(점을 붙인 파일들)로 부르게 되었습니다.\n홈 디렉터리 초기에는 설정 파일을 저장해야 하는 위치를 지정함에 있어서 규약이라고 할 것들이 없었습니다. 따라서, 대부분의 프로그램들이 홈 디렉터리에서 설정 파일을 찾았고, 사용자들도 홈 디렉터리 아래에 저장해왔습니다.\n예를 들어, vim의 경우, 홈 디렉터리인 아래에 .vimrc라는 파일을 통해 기본 설정을 관리하고, bash의 경우, 마찬가지로 홈 디렉터리 아래에 .bashrc를 갖게 되는 것입니다.\nrc?\n설정 파일에 자주 붙는 접미어 \u0026lsquo;rc \u0026lsquo;는 \u0026lsquo;run command \u0026lsquo;에서 따왔다고 알려져있습니다. 이 \u0026lsquo;run command \u0026lsquo;는 1965년 MIT의 CTSS(Compatible Time-Sharing System)의 \u0026lsquo;runcom \u0026lsquo;에서 유래되었다고 합니다.\n그러나, Eric S. Raymond는 그의 저서 \u0026lsquo;The Art of Unix Programming \u0026lsquo;에서 지속적으로 \u0026lsquo;run control \u0026lsquo;로 지칭하고 있습니다.\n이 외에 소수설로, \u0026ldquo;resource control이다 \u0026ldquo;, \u0026ldquo;runtime configuration이다 \u0026quot; 하는 말들도 있습니다.\n~/.config/ ? 그렇다면 리눅스 시스템에 조금 익숙하신 분들은 의아하실 겁니다. 대부분의 프로그램들은 각자의 설정 파일을 \u0026lsquo;홈 디렉터리 아래 .config 디렉터리(~/.config/) \u0026lsquo;에 저장하기 때문이죠.\n특히, 이 디렉터리 내부에는 각 프로그램의 이름으로 디렉터리를 생성하여 모든 해당 프로그램 설정 파일을 그 디렉터리 내부에서 관리하고 있습니다.\n예를 들어, 이메일 클라이언트인 mutt 혹은 neomutt를 사용하시는 분들이라면 홈 아래에 바로 설정파일을 생성하는 경우도 있지만, ~/.config/mutt를 만들어, 그 아래에 muttrc를 저장하시는 경우도 많을겁니다.\n또는, i3 윈도우 매니저를 사용하신다면, ~/.config/i3디렉터리 아래에 config파일 하나로 i3의 외관과 동작을 컨트롤 하고 계십니다.\n이 .config디렉터리는 XDG 재단에서 제정한 XDG Base Directory Specification -XDG 기본 디렉터리 제원에 따라 만들어집니다. 각 프로그램들이 실행시 읽어들이는 설정 파일의 위치를 제각각 다르게 요구하기 때문에 발생하는 복잡한 홈 디렉터리 상태를 깔끔하게 유지하고자 제원을 만든 것입니다.\n따라서, XDG 제원을 성실히 이식하는 소프트웨어의 경우, 기본적으로 .config 디렉터리 아래에 생성된 본인 소프트웨어 이름의 디렉터리에서도 설정 파일을 읽어들일 수 있어야만 합니다.\nXDG\nXDG 재단(현: freedesktop 재단 / 전: X Desktop Group)은 2000년 3월 레드햇(Red Hat)에서 일하던 그놈(Gnome) 개발자 하복 페닝턴(Havoc Pennington)에 의해 설립되었습니다.\nXDG는 리눅스를 더불어 다른 유닉스 유사 시스템의 X 윈도우 시스템과 웨이랜드 시스템의 환경이 서로 호환가능해질 수 있도록 다양한 일을 수행하고 있습니다.\n이런 방식을 취하는 경우, 상위에 숨겨진 디렉터리를 거치기 때문에 굳이, 점을 붙여 설정 파일 자체를 숨길 필요는 없어집니다. 그러나 여전히 \u0026lsquo;설정 파일 \u0026lsquo;임에는 변함이 없으므로, 설정 파일들을 의미하는 것으로 굳어진 dotfiles로 지칭하고 있습니다.\n결과물 결과적으로 사용자의 홈 디렉터리는 아래와 같은 모양을 띄게 됩니다.\n$ tree -a ~ . ├── .bashrc └── .vimrc └── .config └── mutt └── muttrc └── i3 └── config 이식 컴퓨터를 단 한 대만 사용한다면, 이 글에 나오는 내용은 쓸모가 없습니다.\n문제는 새로운 PC나 노트북에 내 개인 설정을 이식해야할 때 발생합니다. 가장 간단한 방법은, 위의 파일들을 각각 USB와 같은 이동식 저장 매체에 담아둔 이후, 새 기기에 붙여넣는 방법입니다. (물론, 이메일을 사용하는 사람도 있습니다;)\n사실, 위와 같은 방법도 설정 파일을 옮기는 것 자체에는 조금의 번거로움을 제외하면 아무 문제가 없습니다. 그러나 설정 파일에 수정이나 변경을 할 때 또 다른 문제가 생깁니다. 예를 들어, .vimrc파일을 처음 생성했을 때는 vim 에디터를 잘 활용할 줄 몰라 매우 기초적인 설정만 적혀있었다고 합시다. 그러나, 시간이 흘러 vim 에디터의 각종 기능에 익숙해졌고, 그 과정에서 vim plugin을 사용하기 시작했습니다. 이 과정에서 매번 설정을 변경할 때마다 USB에 새 버전을 저장할 수도 없는 노릇입니다.\n이런 문제는 이미 알려진 다른 문제 상황과 매우 유사합니다. 사실상 \u0026lsquo;버전 관리 문제 \u0026lsquo;인 셈이죠. 그리고 우리는 매우 획기적인 해결 방법을 가지고 있습니다.\nGit Git 레파지토리를 생성합니다. 그 안에 깔끔하게 정리해서 설정 파일을 저장합니다.\n$ tree -a ~/Git/dotfiles . ├── .git ├── .bashrc └── .vimrc └── .config └── i3 └── config └── mutt └── muttrc 디렉터리 구조도 복사하기 편하도록, 향해야 하는 위치와 동일하게 만들었습니다. 바로 보이는 것들은 홈 디렉터리에 복사하면 되고, .config디렉터리에 있는 것들은 ~/.config아래에 복사하면 되니까 이식 문제는 깔끔하게 해결되었습니다.\n버전 관리 문제는 어떨까요? 가끔씩 생각이 날 때마다, 지금 사용하고 있는 설정 파일과 깃 레파지토리에 있는 파일이 얼마나 다른지 $diff ~/.bashrc ~/Git/dotfiles/.bashrc등의 명령을 통해 확인하고, 달라진 것들은 깃에 적용하면 그만입니다. 버전 관리 문제도 해결되었습니다.\n보통의 일반 사용자는 실제로 이 정도 설정을 갖추면 문제가 없습니다.\n그런데, 굉장히 많은 기기를 관리해야 하거나 아니면 저같은 배포판 널뛰기(distro hopper)를 하는 사람들은 새로운 기기를 설정해야할 때마다 파일들을 복사 붙여넣기 하는 것조차 귀찮습니다.\nSymlinks 리눅스에는 \u0026lsquo;hard link \u0026lsquo;와 \u0026lsquo;symbolic link \u0026lsquo;라는 것이 있습니다. 관심 있는 것은 \u0026lsquo;symbolic link \u0026lsquo;, 줄여서 \u0026lsquo;symlink \u0026lsquo;입니다. \u0026lsquo;symlink \u0026lsquo;는 C언어에서 포인터와 매우 유사하게 작동합니다. 파일처럼 보이는 심볼릭 링크를 생성해둔 이후, 사용자가 그 심볼릭 링크에 (파일인 줄로 알고) 접근하는 경우, 해당 링크가 가리키는 실제 파일로 향하게 해줍니다.\n따라서, 사용자는 요구했던 파일에 접근한 것으로 느끼지만, 실제로는 그 자리를 차지하는 이정표를 따라 참조하고 있는 파일을 수정한 것이 됩니다.\n심링크(symlink)는 아래와 같은 문법으로 적용할 수 있습니다.\n홈 디렉터리의 A.rc라는 파일이 사실은 깃 디렉터리의 B.rc라는 파일로 링크되기를 희망할 때,\n$ ln -s ~/Git/B.rc ~/A.rc 이를 활용해 깃에 올려둔 각종 설정 파일을, 원래 있어야 할 위치에 링크 시키는 방법이 있습니다.\n그런데, 아직도 해결되지 않은 문제가 하나 있습니다. 설정 파일을 활용하는 프로그램이 10개, 20개가 넘어가기 시작하면 그 많은 파일의 링크를 언제 다 생성하고 관리할까요?\n귀찮음이 이 정도 수준에 이르면 우리는 다른 해결책을 찾아 나섭니다. 자동으로 심볼릭 링크를 생성할 수 있어야겠습니다.\n인자로 주어지는 파일의 순서가 항상 헷갈립니다. 그럴 때, 외우기 매우 쉬운 힌트로 리눅스 명령어는 자주 \u0026lsquo;이미 있는 것 \u0026lsquo;, \u0026lsquo;없는 것 \u0026rsquo; 순서로 쓰인다는 것을 알면 유용합니다.\n예시 →$mv existing_file not_existing_yet,$cp existing_file not_existing_yet,$ln existing_file not_existing_yet\n그 대안은 2가지 입니다.\nGit Bare Repository GNU Stow Software 2가지를 천천히 살펴보시고 더 입맛에 맞는 방법을 찾으시면 됩니다.\nGit Bare Repository git init은 현재 디렉터리를 깃 관리 디렉터리로 만듬과 동시에 .git이라는 디렉터리도 생성합니다. 이 .git에는 각종 커밋 정보와 파일 해쉬값들이 들어가는 git명령어의 두뇌에 해당합니다. 따라서, 일반적인 상황에서는 현재 디렉터리를 실제 작업하는 환경으로 활용하기 위해 git init을 사용합니다.\n여기서 적고 있는 설정 파일(dotfiles) 관리는 사실 위와 같은 전체 구조가 필요한 것은 아닙니다. 단순히 어떤 파일들을 트랙킹(계속 주시하며 변경사항을 관리)해야 하는지가 중요할 뿐이죠. 그 말은, 현재 이 디렉터리 아래에서 어떤 새로운 기능을 추가하거나 하는 등이 작업이 이루어지지 않아도 된다는 뜻입니다.\n그런데 깃은 이런 스타일의 디렉터리를 관리하기 위한 기능이 이미 있습니다. 바로 bare repository입니다.\nbare repository(이하: 배어 레파지토리)는 통상적으로 다양한 사람들의 작업 환경을 원격 레파지토리에서 관리하기 위해서 사용합니다. 따라서, 추가된 파일들이나 삭제된 파일을 트랙킹할 뿐, 이 레파지토리 내부에서 어떤 작업을 하지 않습니다.\n이 배어 레파지토리를 활용한 닷 파일 관리는 아래와 같습니다.\n$ git init --bare $HOME/.dotfiles $ echo \u0026#34;alias config=\u0026#39;/usr/bin/git \\ --git-dir=$HOME/.dotfiles \\ --work-tree=$HOME\u0026#39;\u0026#34; \u0026gt;\u0026gt; $HOME/.bashrc $ source $HOME/.bashrc 본인의 쉘이 다르면 .bashrc 말고 각자 쉘의 환경 설정 파일에 추가하면 됩니다. $ config config --local status.showUntrackedFiles no 예를 들어, .vimrc 를 관리한다고 하면 $ config add .vimrc $ config commit -m \u0026#39;added .vimrc\u0026#39; $ config push 당연하지만 원격 레파지토리(github, gitlab 등)이 설정되고나서 진행합니다. 즉, 기존 상황에서 git명령어를 입력할 상황을 config명령어로 대체 설정해둔 다음, config명령어를 통해 깃 레파지토리를 관리할 수 있습니다.\n배어 레파티토리이므로, 깃 디렉터리 자체는 여기에 있으나 실제 작업 환경은 저쪽에 있다는 설정을 수행합니다.(alias config)\n이렇게 관리하고 있는 설정파일을 실제 새로운 컴퓨터에 설치하기 위해서는 아래의 명령들을 수행합니다.\n$ echo \u0026#34;.dotfiles\u0026#34; \u0026gt;\u0026gt; .gitignore $ git clone --bare \u0026lt;REPOSITORY-URL\u0026gt; $HOME/.dotfiles $ echo \u0026#34;alias config=\u0026#39;/usr/bin/git \\ --git-dir=$HOME/.dotfiles/ \\ --work-tree=$HOME\u0026#39;\u0026#34; \u0026gt;\u0026gt; $HOME/.bashrc $ source $HOME/.bashrc 본인의 쉘이 다르면 .bashrc 말고 각자 쉘의 환경 설정 파일에 추가하면 됩니다. $ config config --local status.showUntrackedFiles no $ config checkout 이미 눈치 채셨겠지만, git checkout기능을 적극 활용하는 방식입니다. 새로운 PC 환경은 새로운 브랜치와 다름 없으므로, 원격 레파지토리를 이 PC의 작업 환경으로 지정한 $HOME으로 체크아웃 하여 작업하는 것입니다.\nStow 기본 개념 stow는 원래 심볼릭 링크 관리자로 만들어진 프로그램 입니다. GNU stow 프로젝트에서 소개하고 있는 예시를 그대로 가져오자면, /usr/local/bin아래에 /usr/local/stow/emacs/bin, /usr/local/stow/perl/bin을 향하는 심볼릭 링크를 생성할 수 있게 해줍니다.\nstow의 기본 행동은 현재 있는 디렉터리 아래의 구조와 파일을 파악한 후, 한 단계 위의 디렉터리로 가서 그대로 심볼릭 링크들을 설정하는 것 입니다.\n추가 개념 추가적으로 꼭 알아야 할 점이 있습니다.\n디렉터리 폴딩 stow는 디렉터리 폴딩이라는 개념을 사용합니다. 적용하고자 하는 디렉터리 구조가, /usr/lib/test/A/A.rc로 존재한다고 가정했을 때, /usr/lib/디렉토리가 test디렉터리를 제외하고 아직 그 어떤 파일이나 디렉터리를 포함하지 않은 경우, /usr/lib/test/으로 이동해서 $stow를 실행하면 /usr/lib/A자체가 /usr/lib/test/A 를 가리키는 심볼릭 링크로 생성됩니다.\n상위 디렉토리와 지시한 디렉토리 구조를 맨 상위부터 비교해가며 가장 빠르게 구분할 수 있는 차이가 발생하는 시점에 그냥 심볼릭 링크를 생성하고 멈춥니다. 즉, 디렉터리 구조 맨 아래에 있는 파일까지 똑깥이 복사되고 파일만 심볼릭 링크가 생성되는 것이 아닙니다.\n아래는 그것을 보여주는 예시입니다.\n$ tree -a . . └── test └── A └── .config └── A.rc 인 상황에서 $ cd test 이후, $ stow A 를 하고 $ cd .. 다시 나와서 확인했을 때, 아래와 같이 적용됩니다. $ tree -a . . ├── .config -\u0026gt; test/A/.config └── test └── A └── .config └── A.rc 위에서 확인하실 수 있듯이, .config/A.rc -\u0026gt; test/A/.config/A.rc가 아니라 .config자체를 링크해버렸습니다.\n패키지 개념 패키지 개념은 어렵지 않습니다. 위에서 이미 보셨겠지만 $stow A와 같이 현재 디렉터리 내부의 특정한 디렉터리를 명령 대상으로 삼을 수 있습니다. 실제 stow 프로그램이 개발될 당시에는 라이브러리와 명령어, 매뉴얼 페이지를 포함하는 각종 perl 패키지를 설치하기 용이하게 하는데에 목적이 있었습니다. 즉, A라는 디렉터리 아래에 lib, bin, man 등의 디렉터리가 또 존재하고, 각각의 디렉터리 내부에 실제 파일이 존재하였던 것입니다. 이 때, 구조를 모두 포함하는 최종 디렉터리인 A를 패키지로 삼을 수 있습니다.\nstow 매뉴얼에서의 정의에 따르면 \u0026ldquo;패키지란, 하나의 단위로 관리하고 싶은 파일이나 디렉터리의 집합 \u0026ldquo;입니다.\n그렇기 때문에, 위 예시에서 $stow A옵션으로 실행이 가능한 것입니다.\n옵션 하지만 이것은 그냥 사실상 심볼릭 링크와 다를 바가 없습니다. stow의 강점은 옵션에 있습니다. stow의 옵션들은 가장 대표적으로 아래와 같습니다.\n-S DIR, (--stow=DIR, 소스 디렉터리/패키지를 지정)\nstow를 실행했다는 것은 어쨌든 무언가를 집어넣으려고 한 것이기 때문에 이 옵션 플래그 자체는 생략 가능합니다. 다시 말해서, 그냥 소스 디렉터리/패키지를 쭉 나열만 해도 -S가 켜진 것과 동일하게 이해합니다. 그러나 무엇을 집어 넣으려고 하는 건지 그 소스 디렉터리/패키지 자체는 항상 명시해야 합니다. ., *일지라도 명시 -D, -R등과 혼합 사용할 시에는 반드시 지정해서 켜야 함\n-t DIR(--target=DIR)\n옵션을 지정하지 않은 경우, 타겟 디렉터리의 기본값은 바로 한 단계 상위 디렉터리 입니다.\n소스 디렉터리는 현재 위치이고, 타겟 디렉터리는 홈 디렉터리 일 때, 위 옵션들을 활용해 $stow *혹은 $stow -t ~ *로 사용할 수 있습니다. -t옵션이 사용되는 경우, 먼저 나오는 경로가 타겟 디렉터리, 뒤에 나오는 경로(들)는 소스 디렉터리 입니다.\n하나의 설정 파일만 연결하면 되더라도, 해당 파일을 필요로하는 프로그램의 이름으로된 디렉터리를 생성하여 그 아래에 저장하시면 문제가 없습니다.\n추가적으로 매우 유용한 옵션은 아래와 같습니다.\n결과를 상세히 출력하도록 하는 -v(--verbose=N)옵션을 함께 활용하면 어떤 변화가 생겼는지 출력을 통해 다시 확인할 수 있습니다. -n(--no, --simulate) 옵션을 붙여, 가상으로 실행해보고 나서, n옵션을 제거한 명령어로 실제 수행을 하는 방법도 있습니다. $stow .와 $stow *의 차이점\n.은 현재 디렉터리 자체를 패키지로 인식시킵니다. 즉, 현재 디렉터리 내부의 A/A.rc는 상위 디렉터리에 A -\u0026gt; ./test/A로, B.rc는 상위 디렉터리에 B.rc -\u0026gt; ./test/B.rc로 연결됩니다.\n*은 현재 디렉터리 내부의 디렉터리들을 패키지로 인식시킵니다. 따라서, 파일도 함께 포함되어 있는 디렉터리에서 그 디렉터리 자체를 인자로 수행하는 경우 패키지로 인식하지 못해 다음과 같은 에러를 뿜습니다. stow: ERROR: The stow directory stow does not contain package B.rc\n결론적으로, $stow -nvt ~ *로 결과가 예상한 것과 같은지 확인한 뒤, $stow -vt ~ *롤 하게 됩니다.\n뿐만 아니라, 특정 디렉터리들만 생성하고 싶을 때는, $stow -vt ~ this_dir that_dir also_dir을 통해, 나머지 디렉터리는 무시하고 this_dir, that_dir, also_dir 아래의 설정 파일만을 심볼릭 링크로 생성할 수 있습니다.\n즉, 본인 입맛에 따라 아무대나 깃 레파지토리를 클론해둔 다음, 설정 파일을 적용/관리할 수 있는 셈입니다.\n예시 아래와 같은 test디렉터리를 기준으로 다양한 명령어를 수행한 결과들을 보여드리겠습니다.\n$ tree -a . . └── test ├── A │ └── .config │ └── A.rc ├── B │ └── .config │ └── B.rc └── C └── C.rc 각각의 결과 항목은\ntest디렉토리 내부로 이동하여 각 항목 제목에 있는 명령을 수행한 이후, 실행 결과를 복사하였습니다. 이후, 다음 예시를 위해, 생성된 링크를 모두 삭제하고 진행했습니다. 각 항목 명령어를 보고 결과를 예상해보시는 것을 추천드립니다.\n$ stow C $ tree -a . . ├── C.rc -\u0026gt; test/C/C.rc └── test ├── A │ └── .config │ └── A.rc ├── B │ └── .config │ └── B.rc └── C └── C.rc $ stow B $ tree -a . . ├── .config -\u0026gt; test/B/.config └── test ├── A │ └── .config │ └── A.rc ├── B │ └── .config │ └── B.rc └── C └── C.rc 기존에 상위 디렉토리에서 .config를 가지고 있지 않다는 이유로, B.rc가 아닌 .config자체를 링크한 것을 확인할 수 있습니다.\n$ stow A $ tree -a . . ├── .config -\u0026gt; test/A/.config └── test ├── A │ └── .config │ └── A.rc ├── B │ └── .config │ └── B.rc └── C └── C.rc A만 실행해도 마찬가지입니다.\n$ stow -nv A $ stow -nv A LINK: .config =\u0026gt; test/A/.config WARNING: in simulation mode so not modifying filesystem. n옵션, v옵션을 활용해 결과 미리 확인\n$ stow -nvS A $ stow -nvS A LINK: .config =\u0026gt; test/A/.config WARNING: in simulation mode so not modifying filesystem. S를 켜도 암묵적으로 실행중이었으므로 변화가 없음\n$ stow -nvt A B $ stow -nvt A B LINK: .config/B.rc =\u0026gt; ../../B/.config/B.rc WARNING: in simulation mode so not modifying filesystem. t옵션을 활용해, 반드시 바로 위 디렉터리가 아니라 타겟 디렉터리를 자유자재로 설정 가능. 여기서는 목적지가 A로 설정되었습니다.\n인자들의 적용 순서는 타겟_디렉터리 소스_디렉터리 입니다. 이러한 적용 순서 덕분에, 실행하고자 하는 소스 디렉터리를 여러개 나열할 수 있게 됩니다.\nex) $stow -vt ~ Dir1 Dir2 Dir3\n타겟 디렉터리를 A로 지목하였으므로, 여기서 표시하는 .config는 A/.config입니다! 따라서 아래 예시와 같은 결과가 생깁니다.\n$ stow -vt A B $ tree -a . . └── test ├── A │ └── .config │ ├── A.rc │ └── B.rc -\u0026gt; ../../B/.config/B.rc ├── B │ └── .config │ └── B.rc └── C └── C.rc n옵션을 제거하여 실제로 수행할 수 있습니다.\n위에서 언급한 것처럼 타겟을 A로 지정하였으므로, A디렉터리 내부에 도달하여 이미 .config디렉터리가 있는 것을 확인, B.rc의 링크만 새로 생성한 것을 확인할 수 있습니다.\n$ stow -nvt .. * $ stow -nvt .. * LINK: .config =\u0026gt; test/A/.config UNLINK: .config (reverts previous action) MKDIR: .config LINK: .config/A.rc =\u0026gt; ../test/A/.config/A.rc LINK: .config/B.rc =\u0026gt; ../test/B/.config/B.rc LINK: C.rc =\u0026gt; test/C/C.rc WARNING: in simulation mode so not modifying filesystem. 아웃풋을 눈여겨보시면 첫 줄에 A 패키지 순서에 상위 디렉터리엔 .config자체가 없음을 알고 귀찮아서 .config를 링크했다가, B 패키지 순서에 해당 디렉터리를 또 필요로 하는 것을 알고 화들짝 놀라, UNLINK하는 모습을 볼 수 있습니다. 그리고나서, .config디렉터리를 생성해 각각의 rc파일을 링크합니다.\n$ stow -vt .. * $ tree -a . . ├── .config │ ├── A.rc -\u0026gt; ../test/A/.config/A.rc │ └── B.rc -\u0026gt; ../test/B/.config/B.rc ├── C.rc -\u0026gt; test/C/C.rc └── test ├── A │ └── .config │ └── A.rc ├── B │ └── .config │ └── B.rc └── C └── C.rc 이 명령어는 결과적으로 test디렉터리 내부에서 실행한 $stow *와 동일합니다.\n최종 정리 최종 정리를 하자면, 깃 아래에\n$tree -a ~/Git/dotfiles . └── Stow ├── Bash │ └── dot-bashrc ├── i3 │ └── .config │ ├── i3 │ │ └── config └── Neomutt └── .config └── neomutt └── neomuttrc 와 같이 정리해둔 경우, $cd ~/Git/dotfiles로 해당 깃 디렉터리에 이동한 다음, $stow -vt ~ *를 실행하면,\n$ tree -a ~ . ├── .bashrc -\u0026gt; ~/Git/dotfiles/Stow/Bash/.bashrc └── .config └── i3 -\u0026gt; ~/Git/dotfiles/Stow/i3/.config/i3 └── neomutt -\u0026gt; ~/Git/dotfiles/Stow/Neomutt/.config/neomutt/neomuttrc 이렇게 적용할 수 있습니다.\n결론적으로, stow를 활용해 깃에 저장된 설정 파일로 향하는 심볼릭 링크를 만들게되어, 깃에 있는 설정 파일 변경만으로 시스템에 적용되고 있는 설정까지 한번에 변경되며, (이미 깃에 있는 파일을 수정하는 것이므로) 버전 관리가 용이해집니다.\n이미 생성된 dotfile 레파지토리도 없었고, stow도 이제서야 사용해보기로 하시는 분들은, --adopt옵션을 살펴보시기 바랍니다. ($stow --adopt -nvt ~ *)\n수동으로 복사/이동할 필요 없이, stow가 현재 디렉터리로 문서를 옮기는 것을 도와줄지도 모릅니다!\n이미 생성해버린 심볼릭 링크를 제거하거나, 여러가지 다른 이유로 심볼릭 링크를 제거하고 싶으신 분들은, $stow -D옵션을 활용하시면 됩니다! 생성 때와 마찬가지로 -n옵션을 유용하게 활용하시기 바랍니다. 아마도 결론적으로 사용하고자 하시는 명령어는, 설정 파일이 담긴 깃 디렉터리로 이동 후, $stow -D ${TARGET_PACKAGES}일 것으로 예상됩니다! 적용했을 파일들을 알아서 다시 연산한 후에, 그것들을 찾아다니면서 링크를 제거해줍니다.\nOthers\u0026rsquo; Repository 다른 사람들 설정 파일 레파지토리 구경하기\nNixOS\n여기서 그치지 않고, 더 하드코어한 방식을 찾다 보면, Nix 패키지 매니저 혹은 아예 NixOS를 마주하게 됩니다.\nNix는 설정 파일에 그치지 않고, 내 시스템 전반에서 사용할 프로그램, 내 사용자가 사용할 프로그램 등 시스템 관련 설정을 *.nix파일로 저장해두고, 새 PC를 설치할 때, *.nix파일을 불러와 그대로 적용할 수 있습니다.\n","permalink":"http://ptrtoj.com/kr/stow/","summary":"\u003ch2 id=\"서문\"\u003e서문\u003c/h2\u003e\n\u003cp\u003eDotfiles를 관리하는 방법을 수동, Git 활용, 심볼릭 링크 활용, GNU stow 활용의 단계로 정리하였습니다.\u003c/p\u003e\n\u003ch2 id=\"dotfiles\"\u003eDotfiles\u003c/h2\u003e\n\u003cp\u003e유닉스 관련 시스템(Unix, BSD, Linux 등)에서는 파일명 앞에 \u003ccode\u003e.\u003c/code\u003e을 붙이는 경우, 숨긴 파일이 되어 \u003ccode\u003els\u003c/code\u003e만으로는 파일을 보이지 않습니다. 이를 활용해, 각종 프로그램 설정이 담긴 일반 텍스트 파일을 \u003ccode\u003e.\u003c/code\u003e을 붙여 활용해왔습니다.\u003c/p\u003e","title":"Stow로 Dotfiles 관리"},{"content":"서문 아치 리눅스 설치 가이드를 작성할 때도 마찬가지였지만, 기본적으로 새 글을 작성할지 결정할 때는 \u0026lsquo;내가 실제로 공부하기 까다로웠는가\u0026rsquo;를 기준으로 설정합니다. 이미 영문/한글로 작성된 양질의 가이드가 충분히 존재해서 스스로 공부하는데도 어려움이 없었고, 뒤에 공부할 사람들도 쉽게 배울 수 있을 것으로 예측되는 것들에 대해 작성하는 것은 \u0026lsquo;내가 이만큼 신기한 것도 안다\u0026rsquo;하는 따위의 자랑밖에 안된다고 생각했기 때문입니다.\nGPG는 \u0026lsquo;매우\u0026rsquo; 까다로웠습니다. 온갖 자료가 분산되어 흩뿌려져 있습니다. 특히 한글 자료는 전무하다고 봐도 무방합니다. 이는 교보문고, yes24에서 \u0026lsquo;gpg\u0026rsquo;를 검색해도 쉽게 알 수 있습니다. 따라서 뒤에 이 주제를 공부할 분들이 기본 개념을 쉽게 파악하는 것을 돕고자 공부한 자료를 교차 검증하고 재검토하여 한 문서에 모았습니다.\n개념 파트에서는 이어지는 실제 예시들을 읽을 때 처음 접하는 정보가 없도록 하기 위해 세세하게 정리하였습니다. 당장 따라해야할 명령어들만 필요하신 분들은 생략하시면 됩니다.\n부디 도움이 되기를 기대합니다.\n감사 말씀 이 작은 글이 기념비적 업적을 남기는 다른 글과 비교하면 보잘 것 없지만 작성자 본인에게는 의미가 큽니다. 이 짧은 글을 작성하는 데도 많은 분들의 도움이 있었습니다. 아래에 특별히 언급한 분들뿐아니라 온라인과 오프라인으로 접근할 수 있었던 각종 문서를 앞서 작성하여 지식을 전해준 모든 분들께 감사할 따름입니다.\nMichael W. Lucas의 책이 아주 큰 도움이 되었습니다.\n준비, 작성, 수정 과정에 도움을 준 경희대학교 행정학과 김진영 학우께 특별히 감사 말씀을 드립니다. 까다롭고 수준 높은 기준으로 글을 검토하고 수정할 사항들이 있을 때마다 가감 없이 건의해주었습니다.\n마지막으로, 혼자 뭔가 하는가 싶더니 뜬금없이 \u0026lsquo;이건 정리가 필요하다\u0026rsquo;면서 컴퓨터 앞에 앉아 며칠이고 자판을 두드리고 문서와 책을 옮겨 뒤져가며 무언가를 작성하는데도 응원해준, 또, 관심 분야가 아닌데도 불구하고 비전공자 입장에서 이해가 어려울만한 부분을 지적해준 와이프에게 감사하다는 인사를 전합니다.\n미리 알아야 하는 것 수학, 컴퓨터 관련 배경 지식이 없어도 이해하기 쉽게 작성했습니다. 수학적인 개념이 등장할 때도 그 자리에서 쉽게 설명했습니다. 더 설명이 필요한 부분이 있으시면 \u0026lsquo;jeon@ptrtoj.com\u0026lsquo;으로 알려주시기 바랍니다.\n개념 배경 모든 것의 시작점이 되는 PGP(Pretty Good Privacy; 꽤 좋은 보안)는 1991년 필 짐머만(Phil Zimmermann)에 의해 개발되었습니다. 이는 당시 냉전 상황에서 적국이 수준 높은 보안 기술을 갖게 될 것을 우려한 미국 정부의 각종 규제에 직접적으로 반하던 것입니다. 짐머만은 소프트웨어의 외부 반출을 금하는 법의 허점을 이용해 출판물로써 PGP 기술들을 반출합니다. PGP 기술을 이식하기 위한 소스 코드와 개념이 적힌 책을 출판한 것입니다. 이로 인해 상당한 기간 법정 소송에 휘말렸으나 오히려 정부의 소 제기로 인해 짐머만은 자유 진영의 영웅이 되었습니다. 더 자세한 역사는 링크를 통해 확인하시면 좋겠습니다.\n용어 정리 GPG를 포함한 다양한 암호 관련 문서에서는 용어가 상당히 혼란스럽게 쓰입니다. 따라서, 이 글에서만큼은 통일성을 유지하기 위하여 본문에서 사용할 용어들을 미리 정리하겠습니다. 이미 GPG를 이해하고자 여러 글들을 읽으며 씨름하셨던 분들은 오히려 \u0026lsquo;용어 정리\u0026rsquo;를 읽으며 개념이 이해될 수도 있습니다. 아래 용어 정리를 읽으며 무슨 뜻인지 전혀 이해가 되지 않더라도 본문을 읽으신 후 재확인하시면 이해가 수월할 것으로 기대합니다.\n평문: 지금 이 문서처럼 글을 이해할 수 있는 사람이 보는 즉시 내용을 파악할 수 있게 노출된 글 암호문: \u0026lsquo;R3i21+UlSPUlOVcT6AJ98popJr4TA5mlUSX\u0026rsquo;과 같이 특수한 방법을 이용하지 않고는 그 내용을 파악하기 힘든 글 암호: 상호 간에 정한 약속이나, 혹은 내가 암호문을 만들거나 해독하기 위해 만든 \u0026lsquo;단어\u0026rsquo; 혹은 \u0026lsquo;구절\u0026rsquo; 등 (예: \u0026ldquo;발송한 암호화된 문서의 비밀번호는 \u0026lsquo;1234\u0026rsquo;입니다.\u0026ldquo;에서 \u0026lsquo;1234\u0026rsquo;\u0026rsquo;) 대칭 암호: \u0026lsquo;Symmetric Cryptography\u0026rsquo;로 표현하며 상대와 내가 동일하게 알고 있는 \u0026lsquo;암호\u0026rsquo;를 통해 구현하는 기법. (예: \u0026ldquo;발송한 암호화된 문서의 비밀번호는 \u0026lsquo;1234\u0026rsquo;입니다.\u0026rdquo; 에서 사용하고 있는 기법) 비대칭 암호: \u0026lsquo;Asymmetric Cryptography\u0026rsquo;로 표현하며 상대와 내가 암호화된 문서 교환을 위해 서로 다른 키를 갖는 기법. 공개키: \u0026lsquo;Public Key\u0026rsquo;로 표현하며 외부에 알려져도 되고 통신 상대방이 알아야 활용할 수 있는 키 개인키: \u0026lsquo;Private Key\u0026rsquo;로 표현하며 외부에 절대 알려져서는 안되는 나의 비밀키 키 쌍: \u0026lsquo;Key Pair\u0026rsquo;로 표현하며 공개키와 개인키가 하나의 쌍으로 동시에 생성되고 관리됨 키 링: \u0026lsquo;Key Ring\u0026rsquo;으로 표현하며 하나의 키 링에 여러개의 키 쌍(주요키 한 쌍과 다수의 서브키 쌍들)을 가질 수도 있고, 그냥 하나의 키 쌍(주요키 한 쌍)만을 가질 수도 있음 주요키: \u0026lsquo;Primary Key\u0026rsquo; 혹은 \u0026lsquo;Master Key\u0026rsquo;, \u0026lsquo;Main Key\u0026rsquo; 등으로 혼용되고 있으며 키 링 자체를 만들 때 반드시 한 쌍 생성됨. 가장 기본이 되고 중요한 키 쌍. 주요키는 중요하다는 강조로 해석될 경우 마치 \u0026lsquo;중요한 키\u0026rsquo;처럼 이해될 우려가 있습니다. 이 문서에서 주요키는 마스터키로 사용되고 있는 해당 \u0026lsquo;키\u0026rsquo;를 지칭합니다. 주의하시기 바랍니다(하단 표 참조). 서브키: \u0026lsquo;Sub Key\u0026rsquo;로 표현하며 주요키로 관리되는 키 링 아래에 한 개 혹은 여러개로 존재할 수 있는 키 쌍(들)을 \u0026lsquo;서브키 쌍\u0026rsquo;이라고 부름 해쉬: \u0026lsquo;Hash\u0026rsquo; 함수로 표현하며 길든 짧든, 문자든 숫자든 인풋을 받아 \u0026lsquo;고정 크기(길이)\u0026lsquo;의 값으로 반환하는 함수. 대표적인 것들은, \u0026lsquo;MD5\u0026rsquo;, \u0026lsquo;SHA-256\u0026rsquo;, \u0026lsquo;SHA-512\u0026rsquo; 등. 키 서명: \u0026lsquo;다른 사람의 키를 안전한 것으로 확인한다\u0026rsquo;는 \u0026lsquo;인증(Certificate)\u0026lsquo;을 표현하고자 \u0026lsquo;키 서명(Signing a key)\u0026lsquo;이라는 표현을 씁니다. 이것은 다른 기능을 하는 \u0026lsquo;서명(S)\u0026lsquo;이라는 표현과 중복됨에도 함께 쓰이고 있습니다. 실제로 \u0026lsquo;키 서명\u0026rsquo; 과정에서는 \u0026lsquo;인증\u0026rsquo;에 해당하는 \u0026lsquo;C\u0026rsquo; 기능이 부여된 키가 활용됩니다. 문제는 하필, 이 \u0026lsquo;C\u0026rsquo; 기능이 부여된 키가 \u0026lsquo;S\u0026rsquo;도 함께 부여받는 경우가 잦다는 것입니다(하단 표 참조). 여기서의 \u0026lsquo;서명(C)\u0026lsquo;은 암호화(E)와 함께 활용하는 \u0026lsquo;서명(S)\u0026lsquo;과 다릅니다. \u0026lsquo;서명\u0026rsquo;이 쓰인 곳 앞이나 뒤에 \u0026lsquo;타인의 키\u0026rsquo;, \u0026lsquo;키\u0026rsquo; 같은 말이 같이 쓰이는 경우 \u0026lsquo;그 키가 안전하다는 것을 서명한다\u0026rsquo;는 의미(C)로 사용됩니다. 혼란을 유발하는 가장 근본적인 개념으로 보이는 것이라서 다시 한번 강조하고 넘어가겠습니다. 공개키/개인키와 주요키/서브키는 서로 다른 기준에서 구분됩니다.\n주요키 공개키 외부에 공개 가능 보통 \u0026lsquo;C\u0026rsquo;기능(다른 키의 신뢰를 인증하는 \u0026lsquo;키 서명\u0026rsquo;에 활용) 부여 보통 \u0026lsquo;S\u0026rsquo;기능(문서가 발송자의 것임을 확인할 수 있도록 \u0026lsquo;서명\u0026rsquo;하는데 활용됨)도 부여 개인키(\u0026lt;\u0026ndash; 비밀키) 외부에 절대 알려져서는 안됨 주요키에 서명 기능이 부여된 경우, 서명 과정에서 실제로 활용되는 키 서브키 공개키 외부에 공개 가능 GPG는 통상적으로(gpg --full-generate-key사용시) \u0026lsquo;E\u0026rsquo;기능(문서 암호화)만을 갖는 서브키를 자동으로 생성함 개인키(\u0026lt;\u0026ndash; 비밀키) 외부에 절대 알려져서는 안됨 상대방이 내 공개키로 암호화한 문서를 발송한 경우, 해당 문서를 복호화(암호를 품)하는데 사용하는 키 대칭 암호 암호의 종류는 크게 두 가지로 나눌 수 있습니다. 대칭 암호와 비대칭 암호입니다. 대칭 암호의 경우, 학생 시절에 친구와 비밀 쪽지를 주고 받기 위해서 사용한 경험이 있을겁니다. 예를 들어, 각 알파벳에 순차적으로 숫자를 부여하는 기법을 상호 간에 미리 규약하는 방법입니다. 따라서, A를 1로 시작하고 각 알파벳에 순차적으로 숫자를 부여하기로 약속한 경우, \u0026lsquo;3, 1, 18\u0026rsquo;의 쪽지를 보내면 친구가 자연스럽게 \u0026lsquo;CAR\u0026rsquo;로 해독할 수 있는 것입니다.\n학생들도 자연스레 비밀을 주고 받기 위해 떠올릴만큼 단순하고 명료한 방법입니다. 그리 중요하지 않은 문서를 주고 받을 때에는 매우 효과적인 방법일 수 있습니다. 문서 자체를 특정 숫자로 암호화한 후 발송하고 수신자에게 전화 혹은 문자 등을 이용해 비밀번호만을 전송해도 수신자가 해당 문서를 풀 수 있기 때문입니다.\n이 단순해보이는 알고리즘도 쉽게 복잡도를 증대시킬 수는 있습니다. 쪽지 암호화 기법에서 한 단계 더 나아간 것이 군대에서 활용한 암구호입니다. 거동이 수상한 사람을 발견할 경우, 초소 근무 병사가 묻는 \u0026lsquo;문어\u0026rsquo;와 해당 \u0026lsquo;문어\u0026rsquo;에 적합한 답인 \u0026lsquo;답어\u0026rsquo;로 구성하는 방법입니다. 이를 더욱 발전시켜, \u0026lsquo;답어\u0026rsquo;를 여러 가지로 구성한 이후, 각 \u0026lsquo;답어\u0026rsquo;를 제시하는 \u0026lsquo;부서\u0026rsquo;가 다르게 하여 정체를 파악하는 방법으로 나아갈 수도 있고, 혹은 24시간으로 재설정되는 간격을 더욱 짧게 하여, 노출 위험의 지속 시간을 줄이는 방법이 있습니다. 물론, 관리의 비용도 증가할 것입니다.\n대칭 암호의 약점 하지만 진짜 문제는, 관리 비용 증가 같은 \u0026lsquo;불편한\u0026rsquo; 수준의 번거로움이 아니라, 대칭 암호 자체를 관통하는 위험이 도사리고 있다는 점입니다. 이는 중간에서 정보를 탈취하는 공격에 매우 취약하다는 문제입니다. 친구간의 쪽지 암호화에서 알파벳 \u0026lsquo;A\u0026rsquo;가 어떤 숫자로 변환될지를 가운데 앉은 친구가 들은 경우 전달 과정에서 모든 암호를 해독할 수 있고, 암구호의 경우 아무리 자주 변경하더라도 해당 암구호 자체를 적에게 알리는 첩자가 존재하는 경우 보안은 아예 무효화됩니다.\n비대칭 암호 이 문제를 도대체 어떻게 해결할 수 있을까요? 해당 문제를 해결하기 위해 매우 적합한 암호화 기법이 바로 두 번째 구분으로 소개할 비대칭 암호(Asymmetric encryption)입니다. 이름은 어렵지만 개념은 매우 간단합니다. 남들에게 알려져도 전혀 무방한 공개키와 절대 알려져서는 안되는 개인키 두 개를 활용하는 기법입니다. 따라서, 비대칭 암호는 \u0026lsquo;공개키 암호\u0026rsquo;로 통칭되기도 합니다. A가 B에게 암호화된 쪽지를 전달하고자 하는 경우 알려진 B(수신자)의 공개키를 이용해 쪽지를 암호화한 이후 B에게 전달하면 B가 본인만 알고 있는 개인 키를 이용해 이를 해독하는 것입니다. 중간에 아무리 많은 도청자들이 있다고 하더라도 도청될 것들은 A도 마찬가지로 알고 있는 B의 공개키 뿐이므로 해독에 전혀 도움이 되지 않습니다.\n아주 효과적인 방법을 찾아내었습니다! 다만 이런 기법이 실제로 가능할까요? B의 공개키로 암호화된 문서가 어떻게 B의 공개키로 해독되지 않고 B의 개인키로만 해독이 된다는 말일까요? 이 해답은 \u0026lsquo;수학\u0026rsquo;이 제시하였습니다. 도저히 이런 것이 가능하다고 믿기지 않고 직접 확인해보고 싶으신 분들은 \u0026lsquo;알고리즘 종류\u0026rsquo; 단락을 읽어보시면 되고 \u0026lsquo;난 납득할 수 있다\u0026rsquo; 하시는 분들은 \u0026lsquo;알고리즘 종류\u0026rsquo; 단락을 생략하시면 됩니다.\n알고리즘 종류 마술과 같은 공개키/개인키 방법을 실제로 구현하기 위해서는 \u0026lsquo;알고리즘\u0026rsquo;이 필요합니다. 즉 해당 방법이 가능케할 \u0026lsquo;실제 방법론\u0026rsquo;이 필요한 것이죠. 개념상으로 아무리 완벽하다고 하더라도 구현할 방법이 없다면 의미가 없으니까요. 그런데 이를 구현할 아주 다양한 알고리즘이 실제로 제작되고 발전해왔습니다.\n각 알고리즘 종류의 이름 끝 알파벳인 \u0026lsquo;A\u0026rsquo;가 영문으로 \u0026lsquo;알고리즘(Algorithm)\u0026lsquo;에 해당하기 때문에 \u0026lsquo;DSA 알고리즘\u0026rsquo;식의 표기 대신 \u0026lsquo;DSA\u0026rsquo; 자체로 표기합니다.\n과거에는 \u0026lsquo;DSA(Digital Signature Algorithm; 디지털 서명 알고리즘)\u0026lsquo;를 활용하였습니다. 현재는 \u0026lsquo;RSA\u0026rsquo;를 가장 널리 사용하고 있습니다. \u0026lsquo;RSA\u0026rsquo;의 경우, 제작자의 이름인 \u0026lsquo;Rivest, Shamir, Adleman\u0026rsquo; 세 명의 이름 앞글자를 따왔습니다. 그리고, 앞으로 쓰일 것으로 예측되는 \u0026lsquo;ECDSA(Elliptic Curve Digital Signature Algorithm)\u0026lsquo;를 벌써부터 적극적으로 사용하는 사람들이 늘어나는 추세입니다. \u0026lsquo;ECDSA\u0026rsquo;는 \u0026lsquo;ECC(Elliptic-Curve Cryptography)\u0026lsquo;로 불리는 기하학적 방법론으로 \u0026lsquo;DSA\u0026rsquo;를 개선한 알고리즘입니다. \u0026lsquo;ECC\u0026rsquo;는 다양한 암호학 분야에서 아주 관심이 많은 새로 등장한 접근법입니다.\n여기서는 현재 가장 광범위하게 쓰이고 있는 RSA에 대해서 설명하겠습니다.\n원리 쉬운 설명을 위해 단순화한 것으로 원리상으론 올바르지만 실제 사례와 괴리가 있습니다.\n다른 암호화 기법도 마찬가지지만, RSA도 \u0026lsquo;소수\u0026rsquo;를 활용합니다. 여기서 소수란 \u0026lsquo;1.2345..\u0026lsquo;와 같이 매우 작은 수(小數)가 아니라 1과 자기 자신을 제외하고는 나누어 떨어지지 않는 수(素數, prime number)를 의미합니다. 예를 들어, 2, 3, 5, 7, 11, 13, 17 등이 있습니다. 정의한 것처럼 나열한 숫자들은 1과 자신만을 약수로 가집니다.\nRSA는 두 개의 소수를 가지고 시작합니다. 실제 상황에서는 엄청나게 긴 소수 두 개를 가지고 연산하지만, 예를 들기 위해 작은 소수 2와 7을 가지고 설명하겠습니다. p, q를 각각 2, 7로 하겠습니다.\n우선, 두 소수의 곱인 \u0026lsquo;N\u0026rsquo;을 연산합니다. 즉, N=p×q=2×7=14N = p \\times q = 2 \\times 7 = 14N=p×q=2×7=14 입니다.\n그리고나서, 1부터 N까지의 수 중 N과 서로 소수 관계(coprime with N)인 것을 찾습니다. 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14 중 2는 14를 나눌 수 있으므로 제외합니다. 마찬가지로 2의 배수들도 14와 공약수(2)를 가지므로 제외합니다. 지금까지 남는 것은 1, 3, 5, 7, 9, 11, 13 입니다. 7도 14와 공약수를 가지므로 제외합니다. 결과적으로, 1, 3, 5, 9, 11, 13이 남습니다. 개수는 6개 입니다.\n이 서로 소수 관계인 것들의 개수를 찾는 함수(φ)가 존재합니다. 그 함수는 \u0026lsquo;φ(n)=(p−1)×(q−1)\\varphi(n) = (p - 1) \\times (q - 1)φ(n)=(p−1)×(q−1)\u0026lsquo;입니다. p, q로 약속한 2, 7을 대입해보면 1×61 \\times 61×6 으로 6개라는 것을 알 수 있습니다.\n이제 암호 키를 만들 차례입니다. 암호키 e는 두 가지 조건을 만족해야 합니다.\n1보다 크면서 φ(n)보다 작고 ( 1 \u0026lt; e \u0026lt; φ(n) ) N, φ(n)과 소수 관계여야 합니다. φ(n)은 6이었습니다. 따라서, 첫 번째 조건은 어렵지 않습니다. 2, 3, 4, 5면 충분합니다. 14, 6과 소수 관계여야 한다는 두 번째 조건에 따르면 2의 배수는 제외됩니다. 3, 5가 남지만 3은 6과 공약수를 가지므로 제외됩니다. 따라서, e = 5 입니다.\n암호키는 (e, N)으로 구성합니다. 즉, (5, 14) 입니다. 왜 두 가지가 필요한지, 각각이 무슨 역할인지는 \u0026lsquo;적용\u0026rsquo; 단락에서 확인하실 수 있습니다.\n추가로, 이 암호키 (5, 14)가 \u0026lsquo;공개키 암호 방식\u0026rsquo;에서 공유할 \u0026lsquo;공개키\u0026rsquo;에 해당합니다.\n이제 해독키를 만듭니다. 해독키 d는 e와의 곱 이후 φ(n)과 mod 연산이 1인 값으로 정합니다. 수식으로 쓰자면\n(d×e) mod φ(n)=1(d \\times e) \\bmod \\varphi(n) = 1(d×e)modφ(n)=1이어야 합니다.\n\u0026lsquo;mod\u0026rsquo; 연산은 나머지 연산입니다. 시계를 연상하시면 쉽습니다. 시간을 표기하는 것은 mod(12) 연산입니다. 1부터 11까지는 12로 나눈 나머지가 스스로이고, 13부터는 다시 1로 돌아갑니다. 다시 말해서, 1과 13은 mod(12) 연산에서 합동인 셈입니다.\n원래 수식으로 돌아가서 이미 결정된 변수인 e, φ(n) 자리를 채워보면, (d×5) mod 6=1(d \\times 5) \\bmod 6 = 1(d×5)mod6=1입니다. 이것을 만족하는 d를 설정해야 합니다. d를 1부터 차례로 증가시켜보면, d×5d \\times 5d×5는 5, 10, 15, 20, 25, 30, 35로 늘어납니다. 이를 6으로 나눈 나머지들은 각각 5, 4, 3, 2, 1, 0, 5가 됩니다. 처음으로 만족하는 25를 만드는 d 값인 5는 너무 작으므로 그냥 11로 정하겠습니다. 11도 5를 곱하면 55, 6으로 나눈 나머지가 1로 수식을 만족합니다.\n해독키는 (d, N)으로 구성합니다. 따라서, 해독키는 (11, 14)입니다. 이것은 공개키 암호 방식에서 공유하면 안되는 \u0026lsquo;개인키\u0026rsquo;에 해당합니다.\n적용 암호키 (5, 14)로 텍스트 B를 암호화합니다. 컴퓨터가 알파벳 순서로 인식한다고 예를 들겠습니다. 그럼 \u0026lsquo;B = 2\u0026rsquo;가 됩니다.\n변환된 2에 암호키 앞자리(5) 제곱을 한 후, 뒷자리(14)로 나머지 연산을 합니다. 즉, 25 mod 142^5 \\bmod 1425mod14입니다. 252^525은 32이므로 14로 나눈 나머지는 4입니다. 따라서 암호문은 \u0026lsquo;D\u0026rsquo;로 전송됩니다.\n수신자가 해독을 시작합니다. 해독에 쓰이는 연산 방법은 동일합니다. 단지 쓰이는 숫자가 다를 뿐입니다. 해독키는 (11, 14)입니다. \u0026lsquo;D = 4\u0026rsquo;를 받아 411 mod 144^{11} \\bmod 14411mod14를 연산합니다. 411=4,194,3044^{11} = 4{,}194{,}304411=4,194,304이고, 14로 나눈 나머지는 2 입니다. 즉, \u0026lsquo;B\u0026rsquo;로 정상적인 해독에 성공하였습니다.\n정리하면 아래 그림과 같습니다.\n(image source: How does RSA work?)\n비대칭 암호의 약점 하지만 비대칭 암호 혹은 공개키 암호에 약점이 전혀 없는 것은 아닙니다. 가장 유명한 것으로 중간자 공격(Man In The Middle attack; MITM attack)이 있습니다. A와 B가 통신을 원할 때, 이를 알게된 X가 중간에 본인의 공개키를 서로에게 상대방인 것처럼 전달합니다. A가 B로 발송한 메시지가 실제로는 B의 것으로 알려진 X의 공개키로 암호화되어 있고, 이를 X가 본인의 개인키를 이용해 해독, 내용을 파악한 이후에 실제 B의 공개키로 암호화하여 재발송하는 경우 B는 중간에 가로채진 내용이 있지는 않은지 확인할 수가 없습니다.\n이것을 방지하고자 \u0026lsquo;서명\u0026rsquo; 방법이 사용됩니다. 즉, 암호화된 메시지의 해쉬값(메시지의 길이와 관계없이 특정한 길이로 반환되는 섞기 함수의 반환값) 자체를 발송자가 본인의 \u0026lsquo;개인키\u0026rsquo;로 암호화해서 \u0026lsquo;서명\u0026rsquo;으로써 함께 동봉합니다. 수신자는 발송자의 \u0026lsquo;서명\u0026rsquo;은 발송자의 공개키로, \u0026lsquo;메시지\u0026rsquo; 자체는 수신자 본인의 개인키로 해독합니다. 해독한 메시지를 같은 해쉬 함수를 이용해 산출되는 해쉬값과 비교하여 동일하면, 이는 발송자가 보낸 메시지임이 확실합니다. \u0026lsquo;서명\u0026rsquo;은 \u0026lsquo;개인키\u0026rsquo;로 암호화되고 \u0026lsquo;개인키\u0026rsquo;는 본인만 가지기 때문입니다.\n사실, 서명에 쓰이는 공개키/개인키 알고리즘은, 눈치 채셨을 수도 있지만, 암호화와 동일한 것을 사용해도 무방합니다. 즉, RSA를 서명을 위해서도 활용하고 암호화를 위해서도 활용할 수 있죠. 다만, 하나는 발송자의 \u0026lsquo;개인키\u0026rsquo;, 다른 하나는 수신자의 \u0026lsquo;공개키\u0026rsquo;를 활용하기만 하면 됩니다.\nGPG를 더 자주 활용하는 사람들은 둘을 위한 키 각각을 생성해 사용하기도 합니다. GPG 소프트웨어는 이러한 사항을 위해 암호화에 사용될 키는 \u0026lsquo;E\u0026rsquo;(Encryption)로 서명에 사용될 키는 \u0026lsquo;S\u0026rsquo;(Signing)로 약자를 활용합니다. 추가로, \u0026lsquo;A\u0026rsquo;는 \u0026lsquo;승인(Authentication)\u0026rsquo;, \u0026lsquo;C\u0026rsquo;는 \u0026lsquo;인증(Certification)\u0026lsquo;을 의미합니다.\n키링 그렇다면, 고급 사용자의 경우 E/S/A/C 각각에 해당하는 키를 관리하고자 할 것입니다. GPG의 기본 명령을 활용하면 하나의 주요키(마스터키)가 생성되는 이유가 바로 이것입니다. 주요키 쌍인 공개키/개인키 아래에 각각의 역할을 할 서브키를 생성할 수 있습니다. 해당 서브키는 주요키 키링에 딸려오는 것이 됩니다.\n정리하자면, \u0026lsquo;인증\u0026rsquo;기능만을 가질 주요키 한 쌍(공개키/개인키)을 생성합니다. 보통 이 주요키는 유효 기간을 두지 않습니다. \u0026lsquo;인증\u0026rsquo;기능을 갖는 만큼 타인이 이 키가 본인이 맞다는 것을 주기적으로 확인할 필요가 없도록 하기 위해서입니다. 다만, 그만큼 보안에 훨씬 신경을 써야할 것입니다. 이 주요키가 변형된다면 피해는 상상할 수 없습니다.\n해당 주요키 키링에 E/S/A 각각을 수행할 서브키들을 만듭니다. 이 서브키들은 유효기간을 가지는 것이 보통입니다. 유효 기간이 지나면 새로운 키를 생성하여 보안을 유지합니다.\n주요키와 서브키 총 4개는 각각 KEY-ID가 다릅니다.\nGPG의 경우 서브키가 여러개일 경우, 연산에 필요한 것을 스스로 찾아서 동작합니다. 서명이 필요한 경우, \u0026lsquo;S\u0026rsquo;가 부여된 키를 이용합니다. 또, 동일한 역할을 수행하는 서브키가 여러개일 경우, 가장 최근에 생성된 것을 사용합니다.\n보통 \u0026lsquo;C\u0026rsquo; 연산인 인증을 위해 활용하는 주요키의 역할은 새로 가져온 상대방의 공개키를 인증할 때 씁니다. 내가 새로 공유받은 상대방의 공개키가 아래에서 확인할 \u0026lsquo;지문 확인\u0026rsquo; 등의 방법으로 상대방 본인의 것이 맞음을 확신할 때, 그 인증을 하기 위함입니다.\n신뢰망 GPG와 같은 공개키 암호화 방식은 상호 간의 신뢰망(Web of Trust)을 통해 구축됩니다. A가 B라는 사람의 공개키를 본인이 실제로 지인이고 지문도 확인했다고 인증한 경우, A를 아는 C도 B라는 사람의 공개키를 신뢰할 수 있게 되는 것입니다. 이것은 바꾸어 말하면, 본인이 타인의 공개키를 인증할 때에 매우 신중을 기해야 함을 뜻합니다. 내가 제대로 확인하지 않고 인증한 공개키가 사실 그 사람의 것이 아님이 나중에 알려진 경우에는 본인의 공개키마저도 신뢰를 져버리게 됩니다.\n키서버 공개키는 공유할 때 의미가 있습니다. 나에게 보내고자 하는 메시지를 암호화할 때 필수적으로 요구되기 때문입니다. 그런데, 나에게 처음 메시지를 보내는 사람마다 나에게 연락을 취해 공개키를 요구할 수는 없는 노릇입니다. 따라서, \u0026lsquo;키서버\u0026rsquo;가 존재합니다. GPG 프로그램을 이용해서 쉽게 키서버에 본인의 공개키를 공유할 수도 있고, 웹 브라우저를 통해 접속해서 등록할 수도 있습니다.\n다만, 키서버의 기본 동작 원리를 이해해야만 합니다. 키서버에 한번 등록된 키는 \u0026lsquo;삭제\u0026rsquo;할 수 없습니다. 파기되었다는 정보를 추가하여 나중에 공개키를 검색하는 사람에게 이 키를 더이상 사용하고 있지 않음을 알릴 수는 있으나, 서버에서 키 자체를 삭제하는 기능은 없습니다. 이는, 여러 개의 키서버가 서로의 키서버 상에 있는 정보를 복사하여 저장하는 기본 동작 원칙에 의해서도 불편한 기능입니다. 한 서버에서 삭제한다고 해도, 금방 다른 서버의 목록과 대조하여 없는 것을 채우기 때문에 다시 추가될 것입니다.\n따라서, 키서버에 키를 등록할 때에는 내가 정말 이것을 관리할 것인지 등을 잘 따져보시기 바랍니다.\n마지막으로, 공개키에 사용자 정보를 넣는 것이 일반화 되어있다는 점을 이용해 스팸 메일 발송을 위한 이메일 주소 수집 목적으로도 자주 활용됩니다. 키서버에 본인의 공개키를 등록함에 따라, 추후에 상대적으로 더 잦은 스팸 메일을 받게 될 수도 있다는 점을 기억하시기 바랍니다.\n지문 사람의 신원을 확인할 때 지문을 확인하는 이유는 단순합니다. 지문이 같은 사람이 없기(64조 분의 1)때문이지요. 공개키를 공유하고 나서도 이 키가 상대방 것이 맞는지 확인하기 위한 방법으로 지문을 활용합니다. 물론, \u0026lsquo;키\u0026rsquo;의 지문을 사용합니다. 여기서의 지문은 키 ID로도 활용합니다. 일반적으로, 키 ID를 필요로할 때는 공백이 없이, 지문을 확인할 때는 4자리(1바이트)씩 끊어서 활용합니다.\n공개키를 공유 받은 후, 상대방과 통화, 메신저 등 본인임을 확신할 수 있는 방법으로 지문을 한글자씩 대조하여 확인하실 것을 당부드립니다.\nGPG: 기본 PGP? GPG? OpenPGP?\nPGP는 암호화 제품을 판매하는 회사로 발전하였습니다. 1991년 처음 쓰인 공개 키 암호화 방법인 PGP를 기반으로 암호화 관련 제품을 판매하는 상업 회사입니다. GPG는 GnuPG로, 각종 암호화 도구들을 무료로 배포, 활용할 수 있는 소프트웨어입니다. 다만, GNU의 유틸리티가 모두 그러하듯이, 라이선스가 매우 공격적입니다. 따라서, 상업적으로 판매할 제품에 GPG를 활용한다면, GPL(그누 공개 라이센스)를 사용해야만 합니다. GPL은 해당 라이센스가 붙은 제품을 활용하여 부차적인 제품을 제작하는 경우, 마찬가지로 GPL을 사용하도록 하고 있습니다. 소스 코드를 반드시 공개할 것을 강제하는 라이센스입니다. OpenPGP란 PGP, GPG를 아울러 공개키 암호화 알고리즘을 칭하는 말입니다.\nPGP 제품을 GPG라고 하면 화낼 것이고, GPG 제품을 PGP라고 하면 자유 소프트웨어 진영에서 화를 내겠지만 OpenPGP라고 하면 양쪽 다 적당히 수긍합니다.\n설명을 돕기 위한 허술한 비유\n주요키, 특히 주요키의 지문은 본인이 초등학생 때부터 사용했고 앞으로도 변경할 의사가 전혀 없는 네이버 아이디라고 생각하시면 됩니다. 학교 생활을 마치고 대학 생활 중에도, 직장 생활 중에도 사용하던 \u0026lsquo;아무개13579\u0026rsquo;는 이제 본인의 분신과도 같습니다.\n자 이때, 트위터에 관심이 생겨 계정을 하나 만들었습니다. 트위터 계정 \u0026lsquo;아무개111\u0026rsquo;에서 아무리 본인이라고 알려도 의심이 많은 지인들은 수상할 수 밖에 없습니다. 하지만, 네이버 계정으로 \u0026ldquo;트위터 \u0026lsquo;아무개111\u0026rsquo;이라고 계정 만들어봄 ㅋㅋ\u0026quot;라는 메일을 연락처에 모두 전송하면, 해당 메일을 받은 사람들은 \u0026lsquo;아무개13579\u0026rsquo;로부터 수신한 이메일을 통해 \u0026lsquo;아무개111\u0026rsquo;도 당신이라는 것을 확신할 수 있습니다.\n여기서 트위터 계정 \u0026lsquo;아무개111\u0026rsquo;이 서브키 입니다. 서브키는 새로운 것을 만들수도, 원래 것을 삭제할 수도, 원래 것의 유효 기간을 늘릴 수도 있지만, 그 작업이 본인으로부터 이루어졌음을 주변에서 확신하기 위해서는 \u0026lsquo;주요키\u0026rsquo;가 잘 보관되어야 가능합니다.\n키 생성 그럼 실제로 GPG 키를 만들어보겠습니다. ($ gpg --version 으로 gpg 출력이 없는 경우 설치가 되어 있지 않은 것입니다. 맥 에서는 $brew install gnupg, 리눅스에서는 본인의 패키지 매니저를 이용해 #emerge gpg 등을 통해 설치할 수 있습니다. $ gpg --help 를 통해 다양한 옵션을 확인할 수 있습니다.)\ngpg --full-generate-key 아래와 같은 출력이 나옵니다.\ngpg (GnuPG) 2.2.27; Copyright (C) 2021 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (14) Existing key from card Your selection? 해석해보면\ngpg (GnuPG) 버전; 저작권 자유 소프트웨어입니다: 변형하거나 재배포할 수 있습니다. 법적으로 허용된 이상의 어떤 보증도 하지 않습니다. 어떤 종류의 키를 원하는지 선택하십시오: (1) RSA 와 RSA (기본) (2) DSA 와 Elgamal (3) DSA (서명만) (4) RSA (서명만) (14) 카드에 존재하는 키 선택? 3번이나 4번 선택지에서 제공하는 \u0026lsquo;서명만\u0026rsquo;의 의미는 \u0026lsquo;더 자세히\u0026rsquo; 단락에서 설명하겠습니다. 여기서는 이해를 위해 기본값인 1번을 선택하겠습니다. 1을 입력하고 Enter.\n추가로 2 줄의 출력이 나옵니다.\nRSA keys may be between 1024 and 4096 bits long. What keysize do you want? (3072) 4096 RSA 키의 길이를 묻습니다. 설명을 위해 4096을 입력하고 Enter.\nRSA 2048? 3072? 4096?\nRSA 키 사이즈를 2048비트로 해야할까요? 아니면 깃허브, 깃랩의 gpg 키 추가 도움말 페이지에서 추천하듯 4096비트로 해야할까요? GPG 자주 묻는 질문의 11.2 항목부터 그 아래 11.3, 11.4 에서 상세히 설명하고 있듯이, 4096은 약간의 보안을 증대시켜 주지만 연산 속도, 파일 크기 측면에서의 비용 증가와 비교했을 때, 무의미합니다. 즉, 보안적 측면에서 우려가 되어 4096을 쓰겠다는 사람들은 차라리 ECC 알고리즘을 고려하라고 하고 있습니다.\n추가 출력이 나옵니다.\nRequested keysize is 4096 bits Please specify how long the key should be valid. 0 = key does not expire \u0026lt;n\u0026gt; = key expires in n days \u0026lt;n\u0026gt;w = key expires in n weeks \u0026lt;n\u0026gt;m = key expires in n months \u0026lt;n\u0026gt;y = key expires in n years Key is valid for? (0) 첫 줄을 통해 입력 키 사이즈가 4096 비트라는 것을 확인합니다.\n그 아래부터는 이 키가 유효한 기간을 설정합니다. 여기서는 학습을 하는 중이므로, 7를 입력해 7일동안만 유효하도록 합니다. 0을 입력하면 파기되지 않고, 숫자만 입력한 경우 해당 숫자\u0026rsquo;일\u0026rsquo; 동안, w는 \u0026lsquo;주\u0026rsquo;, m은 \u0026lsquo;개월\u0026rsquo;, y는 \u0026lsquo;년\u0026rsquo;동안 유지됩니다.\n연습을 하는 동안에는 파기 기한이 없는 키는 제작하지 않기를 권장합니다. 즉, 0만을 입력하지 마십시오. 추후, 파기용 키를 잃어버리거나, 이미 키서버에 업로드한 키에 접근 방법이 없어지는 경우, 키를 제거할 수 없습니다. 따라서, 충분한 이해를 하기 전에는 가급적 짧은 시간 동안만 유효한 키를 만들기를 권장합니다.\n추가 출력은 설정한 7일이 지난 시점에 파기되는 정확한 날짜와 시간이 표기됩니다.\nKey is valid for? (0) 7 Key expires at Mon 13 Sep 2021 11:56:46 AM KST Is this correct? (y/N) y를 입력합니다.\n추가 출력은 개인 정보를 입력하기 위함입니다.\nReal name: WooHyung Jeon Email address: jeon@ptrtoj.com Comment: You selected this USER-ID: \u0026#34;WooHyung Jeon \u0026lt;jeon@ptrtoj.com\u0026gt;\u0026#34; Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? 실명과 이메일 주소를 입력하고, 코멘트 부분에는 아무것도 입력하지 않습니다. 마지막에 O를 입력해 완료합니다.\n비밀번호를 입력하는 창이 나옵니다. 이 비밀번호가 공개키 암호화 기법에서 가장 취약한 부분에 해당합니다. 따라서, 신중히 어려운 비밀번호를 선택하시기 바랍니다.\n이제 아래 명령어를 통해 생성된 키를 확인할 수 있습니다.\n일반적인 옵션인 --list-keys, --list-secret-keys 등은 마지막 keys를 key로 입력해도 작동합니다.\nPassword? Passphrase?\n국내에서는 일반적으로 \u0026lsquo;비밀번호\u0026rsquo;로 통용되지만, 엄밀히 \u0026lsquo;비밀번호\u0026rsquo;는 각각 \u0026lsquo;비밀 단어\u0026rsquo;와 \u0026lsquo;비밀 구절\u0026rsquo;로 구분할 수 있습니다. 우리가 평소 사용하는 것은 \u0026lsquo;비밀단어\u0026rsquo;에 해당하고 \u0026lsquo;비밀구절\u0026rsquo;은 빈 칸(스페이스바)를 허용하고 그 길이도 문장~단락 수준까지 허용됩니다.\n뿐만 아니라 --list-keys의 경우 -k 옵션으로 줄여서 사용 가능합니다.\ngpg --list-keys 여기서 출력되는 결과는 모두 공개키입니다. 즉, 다른 사람과 공유해도 되는 것들입니다.\n키가 저장된 기본 설정 디렉터리인 /home/(유저이름)/.gnupg/pubring.kbx가 출력됩니다. (.gpg 확장자는 이제 사용되지 않습니다. .kbx(키박스)가 아닌 파일은 별도의 검색을 통해 .kbx로 변환할 수 있습니다.)\n그 아래에 pub는 \u0026lsquo;public(공개)\u0026lsquo;키임을 표현합니다.\n이어서 사용된 알고리즘과 키 길이가 등장합니다(rsa4096).\n제작된 날짜가 나오고 마지막에 알파벳이 나옵니다.\n길게 숫자와 알파벳으로 이어지는 것이 키 ID 입니다. 키 지문/긴 형식 ID/짧은 형식 ID는 모두 이 키 ID의 일부입니다. $ gpg --list-key --keyid-format long과 $ gpg --list-key --keyid-format short를 보시면 각 16자리, 8자리로 줄어든 것을 확인할 수 있습니다.\n그리고 sub는 서브키의 공개키 부분입니다. 이 서브키는 GPG가 키를 생성할 때, 암호화만을 이용하기 위해 기본적으로 추가 생성됩니다. 우측의 \u0026lsquo;[E]\u0026lsquo;를 통해 암호화용 키라는 것을 확인할 수 있습니다.\n개인키는 --list-keys와 유사하지만 대문자 -K 옵션으로 줄일 수 있습니다.\ngpg --list-secret-keys 이번엔 개인키의 목록을 보겠습니다.\n주요키의 개인 부분은 \u0026lsquo;sec\u0026lsquo;로 표기되고, 서브키는 \u0026lsquo;ssb\u0026lsquo;로 표기됩니다. \u0026lsquo;ssb\u0026lsquo;는 \u0026lsquo;secret subkey\u0026rsquo;의 줄임으로 알려져있습니다.\n지문 확인 내 키, 혹은 상대방의 공유받은 키 지문을 확인하기 위해서 아래의 명령을 활용합니다.\ngpg --fingerprint your@email.address 키 가져오기 키서버에서 키를 가져오는 방법입니다. 지인의 이메일 계정 등을 알 때 키서버에서 해당 이메일을 검색하여 공개키를 가져올 수 있습니다.\ngpg --keyserver pgp.mit.edu --recv OTHERS_KEY_ID 타인의 공유 받은 공개키를 인증(키 서명)하고자 하는 경우 아래의 명령을 활용합니다.\ngpg --sign-key someone@email.address 다음은 별도의 USB등에 저장해 두었던 본인의 개인키를 가져오는 방법입니다. 이 방법은 손상된 키링을 복구할 때 뿐만 아니라 본인의 다른 기기에 같은 키를 저장하기 위해서도 유용합니다.\ngpg --import ./my-secret-gpg-key.asc 키 내보내기 개인키의 경우 절대로 노출되어서는 안되기 때문에, USB 등에 옮겨 두는 사용자가 많습니다. 다른 무엇보다도 절대로 네트워크에 노출되지 않도록 주의하시기 바랍니다. 즉, 웹 브라우저, 클라우드 저장소 등에 절대로 옮기면 안됩니다. 네트워크를 통하는 순간 항시 패킷을 확인하고 있는 맬웨어(악성 프로그램) 등에는 노출된다고 봐도 무방합니다.\nGPG의 경우, 일반 키 출력값은 사람이 읽을 수 없는 쓰레기 값으로 보입니다. 따라서, 사람이 읽기 쉽도록 출력하는 --armor 옵션을 추가합니다(-a로 줄여 사용 가능). 이로 출력된 값을 파일에 추가할 때는 나중에 알아보기 편하게 하기 위해서 \u0026lsquo;ascii\u0026rsquo;의 줄임인 \u0026lsquo;asc\u0026rsquo; 확장자로 보통 저장합니다.\ngpg --export-secret-keys --armor YOUR_KEY_ID \u0026gt; ./my-secret-gpg-key.asc 작업 환경 디렉터리를 보시면 my-secret-gpg-key.asc파일이 생성된 것을 확인할 수 있습니다. 이 파일을 절대 네트워크에 노출하지 않고 본인의 안전한 환경에 저장하시기 바랍니다.\n별도로 paperkey 등의 소프트웨어를 활용해 출력에 용이하게 만들 수 있습니다.\n파기용 키 제작 키가 위험한 환경에 노출되었음을 나중에 알게 되거나, 아예 본인의 키를 잃어버린 경우, 기존 키를 효과적으로 파기하기 위해서 파기용 키가 필요합니다. 이를 위해 생성된 파일 역시, 위에서 마련한 안전한 개인키 저장 공간에 함께 보관하시길 권장합니다. 작업 디렉터리 안에 my-revoc-key.asc 파일이 생성됩니다.\nGnuPG 2.1 Update\n2017년 7월 출시 GPG 2.1 버전부터 키 생성 시 파기용 키를 자동 생성합니다. 이 파기용 키는 openpgp-revocsc.d 디렉터리 안에 저장됩니다. 따라서, 앞으로 파기용 키 제작 과정은 강한 권장 사항에서 선택 사항으로 바뀔 것 같습니다.\ngpg --output my-revoc-key.asc --gen-revoke YOUR_KEY_ID 키 삭제 키의 파기가 아니라 기기에서 키를 삭제하기 위한 방법입니다. 모든 키를 삭제하기 위함이라도 반드시 개인키 먼저 삭제해야 합니다.\ngpg --delete-secret-keys YOUR_KEY_ID 다음은, 공개키 삭제입니다.\ngpg --delete-keys YOUR_KEY_ID 키서버로 내보내기 앞에서 설명했듯이 공개키가 서버에 등록되고 나서는 파기 표시를 하는 것 외에 \u0026lsquo;삭제\u0026rsquo;를 하는 방법은 없습니다. 내용을 충분히 이해하고 진행하시기 바랍니다.\n키서버에 공개키를 내보내는 방법입니다.\ngpg --keyserver hkp://pool.sks-keyservers.net --send-key YOUR_KEY_ID 키서버의 종류는 다양하니 별도로 검색해보셔도 무방합니다. 다만, 어차피 키서버가 서로를 확인하여 같은 상태로 유지하기 때문에 어디에 업로드하더라도 결과는 같아집니다.\n암호화 대칭 암호화 GPG 키로 반드시 비대칭 암호화만 할 수 있는 것은 아닙니다. 대칭 암호화를 공유하는 비밀번호로 하는 방법은 아래와 같습니다.\ngpg --symmetric message.txt 이후, 출력에서 비밀번호를 입력합니다.\n--cipher-algo 옵션을 통해 다른 알고리즘을 활용할 수 있습니다. --sign 옵션을 통해, 서명을 할 수도 있습니다. 비대칭 암호화 원래 목적인 비대칭 암호화 방법입니다. --encrypt 옵션은 -e로 줄여 사용할 수 있습니다.\ngpg --encrypt message.txt --recipient 옵션을 통해 받는 사람의 이메일 주소를 명시할 수 있습니다. --sign 옵션을 여기서도 활용할 수 있습니다. 해독 암호화된 문서를 수신하고 해독하는 방법입니다.이 작업은 서명을 해독하는데에도 똑같이 적용됩니다.--decrypt 옵션은 -d로 줄여 사용할 수 있습니다.\ngpg --decrypt message.txt.gpg \u0026gt; decypted.txt 서명 gpg --sign message.txt 다른 작업과 마찬가지로 --symmetric, --encrypt, --recipient 등의 옵션을 활용할 수 있습니다.\n서명의 해독만을 위해서는 --decrypt 옵션을 활용할 수 있지만 해독을 넘어 확인을 한 번에 처리하고자 하는 경우 --verify 옵션을 쓸 수 있습니다.\nGPG: 더 자세히 아래는 E/S/A/C 키를 각각 관리하고자 하는 분들을 위한 명령어들을 소개합니다.\n참조하시면 좋은 데비안 서브키 문서입니다. 아래 과정은 Yubikey 가이드를 참조하였습니다.\n주요키 생성 키를 생성할 때 --expert옵션을 함께 줍니다. 주요키(마스터키)는 굳이 유효기간을 설정하지 않는 것이 일반적입니다. 평소에 대부분의 작업으로 서브키를 이용하기 때문입니다. 주요키는 지문만 이용하더라도 본인이라는 것을 알릴 수 있을 정도로 오랜 기간 메인으로 활용합니다. 따라서 관리에 더 주의해야 합니다.\ngpg --expert --full-generate-key Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (9) ECC and ECC (10) ECC (sign only) (11) ECC (set your own capabilities) (13) Existing key Your selection? (8)을 입력하여 RSA를 활용하되 기능은 직접 선택하는 것으로 알립니다.\nexpert 옵션이 부여된 경우 작동 방식은 토글입니다. 결과 출력값들 중에서 입력한 기능이 미포함되어 있다면 추가되고, 이미 포함되어 있다면 제거됩니다. 아래 예를 직접 확인하겠습니다.\nYour selection? 8 Possible actions for a RSA key: Sign Certify Encrypt Authenticate Current allowed actions: Sign Certify Encrypt (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? \u0026lsquo;Current allowed actions\u0026lsquo;를 참조하시면 기본값으로 Sign, Certify, Encrypt가 포함되어 있습니다. 처음 만드는 주요키는 Certification 기능만을 줄 것이므로, Sign과 Encrypt는 제거해야 합니다. 우선, (E)를 입력하여 Encrypt를 제거합니다.\nYour selection? E Possible actions for a RSA key: Sign Certify Encrypt Authenticate Current allowed actions: Sign Certify (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? Encrypt가 없어진 것을 확인할 수 있습니다. 이제(S)를 입력하여 Sign도 제거합니다.\nYour selection? S Possible actions for a RSA key: Sign Certify Encrypt Authenticate Current allowed actions: Certify (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? (Q)를 입력해 완료합니다.\nYour selection? Q RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 4096 Requested keysize is 4096 bits Please specify how long the key should be valid. 0 = key does not expire \u0026lt;n\u0026gt; = key expires in n days \u0026lt;n\u0026gt;w = key expires in n weeks \u0026lt;n\u0026gt;m = key expires in n months \u0026lt;n\u0026gt;y = key expires in n years Key is valid for? (0) 0 Key does not expire at all Is this correct? (y/N) y 이후 과정은 expert 옵션이 없는 것과 동일하게 이루어집니다. 개인 정보를 입력해 줍니다.\nGnuPG needs to construct a user ID to identify your key. Real name: Dr Duh Email address: doc@duh.to Comment: [옵션 사항 - 빈 칸으로 두기 가능] You selected this USER-ID: \u0026#34;Dr Duh \u0026lt;doc@duh.to\u0026gt;\u0026#34; Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: /tmp.FLZC0xcM/trustdb.gpg: trustdb created gpg: key 0xFF3E7D88647EBCDB marked as ultimately trusted gpg: directory \u0026#39;/tmp.FLZC0xcM/openpgp-revocs.d\u0026#39; created gpg: revocation certificate stored as \u0026#39;/tmp.FLZC0xcM/openpgp-revocs.d/011CE16BD45B27A55BA8776DFF3E7D88647EBCDB.rev\u0026#39; public and secret key created and signed. pub rsa4096/0xFF3E7D88647EBCDB 2017-10-09 [C] Key fingerprint = 011C E16B D45B 27A5 5BA8 776D FF3E 7D88 647E BCDB uid Dr Duh \u0026lt;doc@duh.to\u0026gt; 서브키 생성 이제 S/E/A 각각의 키를 생성합니다. 서브키는 유효기간을 생성하는 경우가 일반적입니다.\n이미 생성한 키의 변경이나 수정을 위해서는 아래의 명령어를 활용합니다.\ngpg --expert --edit-key YOUR_KEY_ID 서명용 서브키 생성 서명용과 암호화용 서브키 모두 별도의 옵션으로서 제공됩니다. 아래 예시에서 어떤 종류의 키를 원하는지 묻는 앞 부분을 보시면 (4)옵션에 서명만을 위한 RSA와 (6) 옵션에 암호화만을 위한 RSA 옵션이 있습니다. 각 단계에서 필요한 것을 입력하면 됩니다.\ngpg\u0026gt; addkey Key is protected. You need a passphrase to unlock the secret key for user: \u0026#34;Dr Duh \u0026lt;doc@duh.to\u0026gt;\u0026#34; 4096-bit RSA key, ID 0xFF3E7D88647EBCDB, created 2016-05-24 Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) Your selection? 4 RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 4096 Requested keysize is 4096 bits Please specify how long the key should be valid. 0 = key does not expire \u0026lt;n\u0026gt; = key expires in n days \u0026lt;n\u0026gt;w = key expires in n weeks \u0026lt;n\u0026gt;m = key expires in n months \u0026lt;n\u0026gt;y = key expires in n years Key is valid for? (0) 1y Key expires at Mon 10 Sep 2018 00:00:00 PM UTC Is this correct? (y/N) y Really create? (y/N) y We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. sec rsa4096/0xFF3E7D88647EBCDB created: 2017-10-09 expires: never usage: C trust: ultimate validity: ultimate ssb rsa4096/0xBECFA3C1AE191D15 created: 2017-10-09 expires: 2018-10-09 usage: S [ultimate] (1). Dr Duh \u0026lt;doc@duh.to\u0026gt; 출력된 마지막 내용을 유심히 보시면, \u0026lsquo;sec\u0026lsquo;에 해당하는 주요키+개인키 하나가 사용처: C로 생성되었고, 그 아래에 \u0026lsquo;ssb\u0026lsquo;에 해당하는 서브키+개인키 하나가 사용처: S로 생성되었습니다.\n암호화용 서브키 생성 gpg\u0026gt; addkey Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (10) ECC (sign only) (11) ECC (set your own capabilities) (12) ECC (encrypt only) (13) Existing key Your selection? 6 RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 4096 Requested keysize is 4096 bits Please specify how long the key should be valid. 0 = key does not expire \u0026lt;n\u0026gt; = key expires in n days \u0026lt;n\u0026gt;w = key expires in n weeks \u0026lt;n\u0026gt;m = key expires in n months \u0026lt;n\u0026gt;y = key expires in n years Key is valid for? (0) 1y Key expires at Mon 10 Sep 2018 00:00:00 PM UTC Is this correct? (y/N) y Really create? (y/N) y We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. sec rsa4096/0xFF3E7D88647EBCDB created: 2017-10-09 expires: never usage: C trust: ultimate validity: ultimate ssb rsa4096/0xBECFA3C1AE191D15 created: 2017-10-09 expires: 2018-10-09 usage: S ssb rsa4096/0x5912A795E90DD2CF created: 2017-10-09 expires: 2018-10-09 usage: E [ultimate] (1). Dr Duh \u0026lt;doc@duh.to\u0026gt; 출력된 마지막 내용을 유심히 보시면, 기존에 있던 두 개 아래에 \u0026lsquo;ssb\u0026lsquo;에 해당하는 서브키+개인키 하나가 사용처: E로 생성되었습니다.\n승인용 서브키 생성 승인용 키는 조금 다릅니다. GPG 유틸리티가 승인 기능을 기본 제공하지 않기 때문에 마치 --expert 옵션을 통해 새 키를 만들 때 처럼 접근하여 승인용 기능만 켜주고 나머지는 모두 꺼 주어야 합니다.\ngpg\u0026gt; addkey Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (10) ECC (sign only) (11) ECC (set your own capabilities) (12) ECC (encrypt only) (13) Existing key Your selection? 8 Possible actions for a RSA key: Sign Encrypt Authenticate Current allowed actions: Sign Encrypt (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? S Possible actions for a RSA key: Sign Encrypt Authenticate Current allowed actions: Encrypt (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? E Possible actions for a RSA key: Sign Encrypt Authenticate Current allowed actions: (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? A Possible actions for a RSA key: Sign Encrypt Authenticate Current allowed actions: Authenticate (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection? Q RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 4096 Requested keysize is 4096 bits Please specify how long the key should be valid. 0 = key does not expire \u0026lt;n\u0026gt; = key expires in n days \u0026lt;n\u0026gt;w = key expires in n weeks \u0026lt;n\u0026gt;m = key expires in n months \u0026lt;n\u0026gt;y = key expires in n years Key is valid for? (0) 1y Key expires at Mon 10 Sep 2018 00:00:00 PM UTC Is this correct? (y/N) y Really create? (y/N) y We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. sec rsa4096/0xFF3E7D88647EBCDB created: 2017-10-09 expires: never usage: C trust: ultimate validity: ultimate ssb rsa4096/0xBECFA3C1AE191D15 created: 2017-10-09 expires: 2018-10-09 usage: S ssb rsa4096/0x5912A795E90DD2CF created: 2017-10-09 expires: 2018-10-09 usage: E ssb rsa4096/0x3F29127E79649A3D created: 2017-10-09 expires: 2018-10-09 usage: A [ultimate] (1). Dr Duh \u0026lt;doc@duh.to\u0026gt; 출력된 마지막 부분에 C(인증)를 위한 주요키+개인키 하나와 S/E/A 각각의 기능을 위한 서브키+개인키(ssb)가 생성되었습니다.\n개인 정보 추가 앞에서 서브키 추가할 때 한 것처럼 --edit-key 옵션을 통해 프롬프트에 진입합니다.\n$ gpg --expert --edit-key YOUR_KEY_ID\n프롬프트에 adduid 를 입력해 추가 정보 입력으로 들어갑니다.\n아래 예시에서는 추가 이메일 주소를 입력하고 승인합니다.\ngpg\u0026gt; adduid Real name: Dr Duh Email address: DrDuh@other.org Comment: You selected this USER-ID: \u0026#34;Dr Duh \u0026lt;DrDuh@other.org\u0026gt;\u0026#34; sec rsa4096/0xFF3E7D88647EBCDB created: 2017-10-09 expires: never usage: C trust: ultimate validity: ultimate ssb rsa4096/0xBECFA3C1AE191D15 created: 2017-10-09 expires: never usage: S ssb rsa4096/0x5912A795E90DD2CF created: 2017-10-09 expires: never usage: E ssb rsa4096/0x3F29127E79649A3D created: 2017-10-09 expires: never usage: A [ultimate] (1). Dr Duh \u0026lt;doc@duh.to\u0026gt; [ unknown] (2). Dr Duh \u0026lt;DrDuh@other.org\u0026gt; gpg\u0026gt; trust sec rsa4096/0xFF3E7D88647EBCDB created: 2017-10-09 expires: never usage: C trust: ultimate validity: ultimate ssb rsa4096/0xBECFA3C1AE191D15 created: 2017-10-09 expires: never usage: S ssb rsa4096/0x5912A795E90DD2CF created: 2017-10-09 expires: never usage: E ssb rsa4096/0x3F29127E79649A3D created: 2017-10-09 expires: never usage: A [ultimate] (1). Dr Duh \u0026lt;doc@duh.to\u0026gt; [ unknown] (2). Dr Duh \u0026lt;DrDuh@other.org\u0026gt; Please decide how far you trust this user to correctly verify other users\u0026#39; keys (by looking at passports, checking fingerprints from different sources, etc.) 1 = I don\u0026#39;t know or won\u0026#39;t say 2 = I do NOT trust 3 = I trust marginally 4 = I trust fully 5 = I trust ultimately m = back to the main menu Your decision? 5 Do you really want to set this key to ultimate trust? (y/N) y sec rsa4096/0xFF3E7D88647EBCDB created: 2017-10-09 expires: never usage: C trust: ultimate validity: ultimate ssb rsa4096/0xBECFA3C1AE191D15 created: 2017-10-09 expires: never usage: S ssb rsa4096/0x5912A795E90DD2CF created: 2017-10-09 expires: never usage: E ssb rsa4096/0x3F29127E79649A3D created: 2017-10-09 expires: never usage: A [ultimate] (1). Dr Duh \u0026lt;doc@duh.to\u0026gt; [ unknown] (2). Dr Duh \u0026lt;DrDuh@other.org\u0026gt; gpg\u0026gt; uid 1 sec rsa4096/0xFF3E7D88647EBCDB created: 2017-10-09 expires: never usage: C trust: ultimate validity: ultimate ssb rsa4096/0xBECFA3C1AE191D15 created: 2017-10-09 expires: never usage: S ssb rsa4096/0x5912A795E90DD2CF created: 2017-10-09 expires: never usage: E ssb rsa4096/0x3F29127E79649A3D created: 2017-10-09 expires: never usage: A [ultimate] (1)* Dr Duh \u0026lt;doc@duh.to\u0026gt; [ unknown] (2). Dr Duh \u0026lt;DrDuh@other.org\u0026gt; gpg\u0026gt; primary sec rsa4096/0xFF3E7D88647EBCDB created: 2017-10-09 expires: never usage: C trust: ultimate validity: ultimate ssb rsa4096/0xBECFA3C1AE191D15 created: 2017-10-09 expires: never usage: S ssb rsa4096/0x5912A795E90DD2CF created: 2017-10-09 expires: never usage: E ssb rsa4096/0x3F29127E79649A3D created: 2017-10-09 expires: never usage: A [ultimate] (1)* Dr Duh \u0026lt;doc@duh.to\u0026gt; [ unknown] (2) Dr Duh \u0026lt;DrDuh@other.org\u0026gt; gpg\u0026gt; save 주요키에서 개인키 제거 주요키의 개인키를 내보내두고, 서브키만을 활용하기 위해 기기에서 주요키의 개인키를 삭제합니다. 이를 위해서 주요 개인키의 키그립 ID를 확인한 이후 아래의 명령을 수행합니다.\nWarning\n반드시 파기용 키와 개인키들을 안전한 곳에 보관한 이후 수행하시기 바랍니다. 아예 USB에 $HOME/.gnupg디렉터리 자체를 복사해 두는 것도 좋은 방법입니다.\n네트워크에 노출이 안되도록 반드시 주의해주세요. 클라우드 저장소 등을 많이 쓰게 되면서 실수로 클라우드 등에 올리는 실수를 자주 확인합니다.\n아래에서 쓰일 KEY_GRIP_ID는 다음을 입력해 얻을 수 있습니다.\ngpg --with-keygrip --list-key your@email.address 출력 중에서 주요키에 해당하는 Keygrip 값을 복사하고 아래 명령을 수행합니다.\nrm -i $HOME/.gnupg/private-keys-v1.d/KEY_GRIP_ID.key 이후, $ gpg -K를 통해 주요 개인키 부분에 표기되는 sec 옆에 #에 추가되었는지 확인합니다. 이 #이 해당 값에 해당하는 개인키가 실제로 존재하지 않음을 의미합니다.\n혹시, 기본 GPG 디렉터리(보통$HOME/.gnupg) 아래에 secring.gpg 디렉터리가 있다면 그 디렉터리도 삭제해줍니다.\nUSB의 주요키로 작업 USB에 복사한 .gnupg디렉리의 주요+개인키를 이용해 작업이 필요한 경우 (예를 들어, 새로 들여오기한 지인의 공개키를 승인하는 경우 등) 아래를 통해 작업합니다. 우선, USB를 마운트한 이후,\nexport GNUPGHOME=/media/USB_MOUNT_POINT gpg -K 혹은, 환경값 변경 필요 없이 아래와 같이 작업하는 방법도 있습니다.\ngpg --homedir=/media/USB_MOUNT_POINT -K 서브키 비밀번호 변경 데비안 문서는 여기서 한 걸음 더 나아갑니다. 주요키의 개인키를 삭제하고 서브키의 비밀번호를 변경합니다. 혹시 비밀번호 자체가 변형되어도 주요키의 비밀번호는 살아남도록 계획합니다. 원하는 분은 이 과정까지 진행하시면 됩니다.\ngpg --edit-key PRIMARY_KEY_ID passwd 문제 발생 시 이 방법들은 (1) 주요+개인 키가 USB 등 안전한 매체에 저장되어 있고, (2) 이는 공격받지 않았음, (3) 마지막으로 이미 키서버에 키가 업로드 되어있음을 전제로 합니다.\nUSB를 마운트 합니다.\nmount /dev/USB_DEVICE_PARTITION /mnt/usb USB나 본인의 개인키가 저장된 디렉터리를 임시 홈 환경으로 지정합니다.\nexport GNUPGHOME=/mnt/usb/DIRECTORY 키 수정 환경으로 진입합니다.\ngpg --edit-key YOUR_KEY_ID GPG 프롬프트에서 목록을 확인 후 해당 하는 키를 선택합니다. 파기 인증을 생성하고 저장합니다.\ngpg\u0026gt; list ...(list)... gpg\u0026gt; key 123 ...(select key)... gpg\u0026gt; revkey 업데이트 된 키 목록을 키서버에 업로드합니다.\n키서버 재검토 위에서 초보자의 실수를 방지하고자 키서버를 아주 위험하고 악랄한 것처럼 묘사하였습니다만, 사실 이는 오해의 소지가 있습니다. 키서버 중에는 외부와 대조/복사를 하지 않는 독립망도 있고, 최근에는 수신된 메일의 링크를 클릭해 본인임을 인증하는 사실상의 가입 단계를 거치는 서버도 존재합니다.\n필자는 keys.openpgp.org를 사용하고 있습니다. (1) 공개키를 등록하면, 이메일 주소로 승인 확인용 링크가 전송됩니다. 링크를 클릭해야 정상 등록됩니다. (2) 자주 묻는 질문에 의하면 SKS 풀과 독립적으로 작동하며 앞으로도 일부가 될 계획이 없다고 합니다.\n여전히 등록을 원하시는 경우, 아래 명령어를 활용하시면 되겠습니다.\ngpg --export-options export-minimal --export YOUR_KEY_ID | curl -T - https://keys.openpgp.org 참조 마이클 루카스(Michael W. Lucas): PGP \u0026amp; GPG: Email for the Practical Paranoid (ISBN: 1593270712) RFC 4880 - OpenPGP Message Format 젠투 리눅스 개발자 정책인 GLEP의 63번째 항목 - OpenPGP 키 제원 섹션에서 최소 요구 사항과 권장 사항을 번역하겠습니다. (GLEP 63: Gentoo OpenPGP policies) 최소 요구 사항 아웃풋 다이제스트는 SHA-2 일 것 (SHA-1 다이제스트도 내부적으로 허용됨), 최소 256 비트여야 함. 모든 서브키는 반드시 이 다이제스트를 이용해 셀프-서명 되어야 함. 서명용 서브키는 주요키와 달라야만 하고, 다른 어떠한 기능도 부여되어서는 안됨 주요키와 서명용 서브키는 둘 모두 아래의 타입 중 한가지여야 함: RSA, \u0026gt;=2048 bits (OpenPGP v4 키 양식이나 더 최근 버전), ECC 25519. 모든 서브키의 유효 기간은 900일 이상 남지 않았을 것 키 유효 기간은 마지막 유효 기간으로부터 최소 2주 전에는 갱신되어야 함. 키에는 @gentoo.org를 사용하는 이메일 주소가 UID로 포함되어야 함. [권장] 키는 반드시 젠투 키서버에 업로드 될 것 주요키는 Certify(인증) 기능만 설정되어 있을 것 주요키와 서명용 서브키는 모두 RSA, 2048 bits여야함. (OpenPGP v4 key 양식이나 더 최근 버전). 키 유효 기간은 매해의 일정한 날짜로 갱신될 것 파기 인증서를 제작하고 안전한 곳에 물리적인 형태로 보관할 것( ~300 바이트 정도 크기일 것임) 개인키의 암호화된 백업이 존재할 것 SKS나 다른 키서버에 업로드할 것 Added Contents (2026-04-14): GPG Key Update Summarized by ‘Google Gemini’ To extend a GPG key\u0026rsquo;s expiration date, use the\ngpg --edit-key \u0026lt;KEYID\u0026gt; command, then type expire and enter the new expiration time (e.g., 1y for one year).\nAfter saving with save, you must re-upload your updated public key to any keyservers or services where it is shared, such as GitHub, using commands like\ngpg --keyserver keyserver.ubuntu.com --send-keys \u0026lt;KEYID\u0026gt; Step 1: Edit the key\nOpen the GPG key editor by running gpg --edit-key \u0026lt;KEYID\u0026gt; In the editor, you can see the current expiration for the primary key. If you need to update a subkey, you may need to first select it using key \u0026lt;number\u0026gt; (e.g., ‘key 0’ or ‘key 1’). Step 2: Set the new expiration date\nOnce the correct key is selected, type expire and press Enter. Enter the new expiration time. Common formats include: 1y for one year 6m for six months YYYY-MM-DD for a specific date Step 3: Save and exit\nType save and press Enter to apply the changes and exit the editor. Step 4: Upload the updated public key\nTo make the change public, you must upload the updated key to all public keyservers you use. For example, to upload to keyserver.ubuntu.com: gpg --keyserver keyserver.ubuntu.com --send-keys \u0026lt;KEYID\u0026gt; You may also need to update your key on services like GitHub. You can export your public key and copy/paste it into the service\u0026rsquo;s settings. Also from Krisleech Backup the key:\ngpg -a --export jeon@ptrtoj.com \u0026gt; YY.gpg.pub gpg -a --export-secret-keys jeon@ptrtoj.com \u0026gt; YY.gpg.sec Move the keys on to something like a USB drive and store it safely in another location. Publish the public key:\ngpg --keyserver keyserver.ubuntu.com --send-keys KEYID gpg --keyserver pgp.mit.edu --send-keys KEYID Also from Openpgp #Retrieve gpg --auto-key-locate keyserver --locate-keys user@example.net #Refresh gpg --refresh-keys #Upload gpg --export jeon@ptrtoj.com | curl -T - http://localhost:8080 ","permalink":"http://ptrtoj.com/kr/gpg/","summary":"\u003ch2 id=\"서문\"\u003e서문\u003c/h2\u003e\n\u003cp\u003e아치 리눅스 설치 가이드를 작성할 때도 마찬가지였지만, 기본적으로 새 글을 작성할지 결정할 때는 \u0026lsquo;내가 실제로 공부하기 까다로웠는가\u0026rsquo;를 기준으로 설정합니다. 이미 영문/한글로 작성된 양질의 가이드가 충분히 존재해서 스스로 공부하는데도 어려움이 없었고, 뒤에 공부할 사람들도 쉽게 배울 수 있을 것으로 예측되는 것들에 대해 작성하는 것은 \u0026lsquo;내가 이만큼 신기한 것도 안다\u0026rsquo;하는 따위의 자랑밖에 안된다고 생각했기 때문입니다.\u003c/p\u003e","title":"GPG 첫 걸음부터"},{"content":" This is a translated work. The original post was written by Eric S. Raymond, and you can read it here.\nAccording to Eric S. Raymond\u0026rsquo;s copying policy, permission is granted, already.\n이 문서는 번역본입니다. 원본은 에릭 S. 레이몬드에 의해 작성되었으며, 다음 링크를 통해 읽을 수 있습니다.\n에릭 S. 레이몬드의 복사 정책에 의하면, 추가적인 번역 허가 절차는 별도로 필요하지 않습니다.\nEric Steven Raymond, Thyrsus Enterprises esr@thyrsus.com\nRick Moen respond-auto@linuxmafia.com\nCopyright © 2001,2006,2014 Eric S. Raymond, Rick Moen\nRevision History Revision 3.10 New section on Stack Overflow May 21, 2014 esr Revision 3.9 URL fixes. April 23, 2013 esr Revision 3.8 URL fixes June 19, 2012 esr Revision 3.7 Helpful hints for ESL speakers. December 6, 2010 esr Revision 3.7 Several translations have disappeared. November 2, 2010 esr Revision 3.6 Minor update and new links. March 19, 2008 esr Revision 3.5 Typo fix and some translation links. January 2, 2008 esr Revision 3.4 New section, “When asking about code”. March 24, 2007 esr Revision 3.3 Folded in a good suggestion from Kai Niggemann. September 29, 2006 esr Revision 3.2 Folded in edits from Rick Moen. January 10, 2006 esr Revision 3.1 Document ‘Google is your friend!’ October 28, 2004 esr Revision 3.0 Major addition of stuff about proper etiquette on Web forums. February 2, 2004 esr 번역 만일 이 문서를 복사, 미러, 번역 혹은 발췌 하고자 한다면 다음 복사 정책 문서를 확인해 주십시오.\n사전 고지 많은 프로젝트들이 도움 요청 방법 부분에 이 문서 링크를 답니다. 링크 다는 것 자체는 괜찮습니다. 그리고 우리가 의도한 사용이기도 하죠. - 다만, 이 글을 읽는 당신이 본인 프로젝트 페이지에 링크를 달려는 웹페이지 주인이라면, 해당 링크 주변에 이 링크는 당신 프로젝트의 문의 창구가 아님을 명확히 보여주는 경고를 게재하시기 바랍니다.\n그런 경고가 없다 보니 이 문서를 작성했다는 이유 하나만으로 마치 우리의 임무가 전세계 모든 기술적 문제를 해결하는 것이라고 생각하는 수많은 멍청이들을 상대하게 된다는 점을 고생 끝에 깨달았습니다.\n만약 도움이 필요해 이 문서를 읽고 있으며, 이 문서의 작성자들로부터 직접 도움을 받을 수 있으리라는 인상을 받고 있다면 당신이 우리가 얘기하는 그 멍청한 놈들 중 하나 입니다. 우리 한테 질문하지 마십시오. 우린 그냥 무시할 겁니다. 우리가 여기 제시하는 것들은 당신이 다루고 있는 소프트웨어나 하드웨어를 실제로 잘 아는 사람에게서 도움을 받는 방법을 제공할 뿐, 99.9%의 경우 우린 그 전문가가 아닙니다. 당신이 다루고자 하는 문제의 전문가가 작성자 중 한 명이라는 확신이 있지 않는 이상, 우릴 그냥 내버려 두세요. 모두가 더 행복해질 수 있습니다.\n소개 해커들의 세계에서는, 당신이 올린 기술적 질문에 달리는 답변의 질은 그 질문의 난이도 뿐만 아니라 질문하는 방식에도 의존합니다. 이 가이드는 더 만족스러운 답변을 받기 위한 질문 방법을 가르쳐주고자 합니다.\n오픈 소스 사용이 점차 확대되어가는 요즘, 해커 수준의 좋은 대답을 해커는 아니지만 경험 많은 사용자로부터 받을 때도 많습니다. 이건 좋은 일입니다; 직접 사용자들은 초보자가 겪는 실패에 대해 조금이나마 더 참을성이 많은 경향이 있습니다. 그럼에도 불구하고, 일반적으로, 해커 수준으로 경험 많은 유저들을 대할 때도 여기서 제공할 방법으로 하는 것이 유용한 대답을 얻을 수 있는 가장 효과적인 방법일 것입니다.\n가장 먼저 이해해야 하는 것으로, 해커들은 사실 어렵거나 양질이면서 생각 하게 만드는 질문을 좋아합니다. 그렇지 않았다면, 우린 이 자리에 있지 않았을 겁니다. 만약 당신이 우리가 고민할만한 흥미로운 질문을 제공한다면 오히려 우리가 감사할 일입니다; 좋은 질문은 고무적이고 선물과도 같습니다. 좋은 질문들은 우리의 이해를 더 발전시키거나, 혹은 자주 생각지 못했던, 아니면 아직은 알아차리지 못했던 문제들을 드러내곤 합니다. 해커들 사이에선, \u0026ldquo;좋은 질문이군요!\u0026ldquo;는 아주 강하고 진심이 담긴 칭찬입니다.\n그런데 해커들은 간단한 질문을 마주할 때 적대적이거나 거만해 보인다는 명성을 가지게 되었습니다. 간혹 초보자임을 알고서 무례하게 대하거나 거만하게 행동하는 것처럼 여겨지곤 합니다만 이것은 사실이 아닙니다.\n분명히 말하는데, 우리는 질문하기 전에 본인이 스스로 해야만 하는 것들조차 하지 않거나, 생각하기조차 싫어하는 사람에게 적대적입니다. 그런 사람들은 시간만 축내요 - 그들은 되갚음도 없이 답만 가져가거나, 더 흥미로운 질문이나 대답을 해줄 가치가 있는 다른 사람에게 할애할 수 있었을 시간을 낭비하는 상황을 초래합니다. 우린 이런 사람을 \u0026ldquo;루저\u0026quot;라고 부릅니다(역사적인 이유로 간혹 \u0026ldquo;lusers\u0026quot;로 표기하곤 합니다).\n우리는 많은 사람들이 우리가 만든 소프트웨어를 그저 사용하고자 하거나 기술적인 상세 내용에 관심이 없다는 점을 알고 있습니다. 대부분의 사람들에겐, 컴퓨터는 전적으로 도구이자 결과물을 만들어 내기 위한 수단일 뿐이죠; 대중은 해야만 하는 더 중요한 일들이 있고 또 다른 나름대로의 삶이 있죠. 우리는 그 점을 인정하고, 우리를 신나게 하는 기술적 문제에 대해서 모두가 관심을 갖기를 기대하지는 않습니다. 그럼에도 불구하고, 우리의 답변 방식은 그런 흥미로운 것들을 인지하고 문제-해결에 능동적으로 참여할 의지가 있는 사람들에게 맞추어져 있습니다. 그 점은 변하지 않을 것입니다. 변해서도 안되고요; 만약 변한다면, 우리가 잘하는 분야에 있어서 덜 효율적인 사람들이 될테니까요.\n우린 (대부분) 봉사자들입니다. 우린 바쁜 삶 와중에 질문에 답변하고자 시간을 내고 간혹 그 질문의 양에 압도되기도 합니다. 따라서 거침없이 걸러냅니다. 특히, 우리의 질문-답변 시간을 승자들에게 더 효율적으로 사용하고자 루저들의 것으로 보이는 질문은 과감히 버립니다.\n만약 이런 태도가 몹시 불쾌하고, 기분 나쁘고 거만하다고 생각한다면, 당신의 전제를 재확인하세요. 우린 당신에게 굽신거리라고 요구하는 것이 아닙니다 - 사실상, 우리 중 대부분은 당신을 동등하게 대하려고 노력하고 해커 문화로 환영하고 싶지만, 이는 당신도 그런 대접을 받을 수 있도록 스스로 노력할 것을 요구합니다. 그러나 스스로를 돕지 않는 사람들까지 돕기를 바라는 것은 순전히 비효율적입니다. 무지한 것은 괜찮습니다; 멍청하게 구는 것은 괜찮지 않습니다.\n자, 우리에게 관심을 받기 위해서 이미 기술 분야에 능통할 필요는 없지만, 완벽으로 이끄는 태도를 보이는 것은 필요합니다 - 깨어있고, 사려 깊고, 관찰력 있고, 해답을 찾는 과정에 능동적으로 참여하고자 하는 의지 말이죠. 이런 불평등을 도저히 견딜 수 없다면, 해커들이 개인적으로 당신을 돕기 위해 봉사하기를 바라지 말고 상업적인 지원 계약을 체결하여 도와줄 직원에게 비용을 지불할 것을 권장합니다.\n만약 도움을 받기 위해 우리에게 오고자 최종적으로 결정했다면, 그런 루저들 중 하나가 되지 않기를 바랍니다. 당신 스스로도 그렇게 보여지긴 싫을 겁니다. 빠르고 즉각적인 답변을 받는 최고의 방법은 똑똑하고, 확신에 차있고, 단서도 가지고 있는 사람이 마침 특정 문제와 관련해서 도움이 필요한 것처럼 행동하는 것입니다.\n(이 문서에 대한 개선점은 환영합니다. 제안 사항은 esr@thyrsus.com 이나 respond-auto@linuxmafia.com로 메일주세요. 주의할 점은 이 문서가 네티켓을 가르치기 위한 문서로 제작된 것이 아니라는 점입니다. 또한 기술 관련 포럼에서 유용한 답변을 이끌어내기 위한 방법과 관련이 없는 제안들은 거절합니다.)\n질문 전에 기술적 질문들을 이메일이나 뉴스 그룹 혹은 웹사이트 채팅에 질문하기 전에, 다음을 지키세요:\n작성하려는 포럼이나 메일링 리스트의 과거 문서에서 답을 찾아볼 것 인터넷 검색을 통해 답을 찾아볼 것 매뉴얼을 읽어 답을 찾아볼 것 FAQ(자주 묻는 질문)란을 읽어 답을 찾아볼 것 검사, 실험을 통해 답을 찾아볼 것 숙련된 친구에게 물어 답을 찾아볼 것 프로그래머라면, 소스 코드를 읽어 답을 찾아볼 것 질문을 할 때는, 이러한 것들은 먼저 했다는 것을 명확히 보이십시오; 이것은 당신이 게으른 스폰지가 아닐 뿐만 아니라 다른 사람 시간을 낭비하려는 것이 아님을 확인하는데 도움이 됩니다. 더 좋은 방법은, 이런 과정을 통해서 당신이 무엇을 배웠는지 명시하는 것입니다. 우린 제공할 해답을 통해 추가적으로 무언가 배울 능력이 있는 사람이라는 것을 스스로 증명한 사람에게 답변하는 것을 선호합니다.\n본인에게 주어진 에러 메시지든 뭐든 간에 구글에 검색해보는 등의 전략을 취하세요 (웹 페이지 뿐만 아니라 구글 그룹도 검색하세요). 이 방법은 당신의 질문에 대한 답이 있는 문서나 메일링 리스트 쓰레드로 곧바로 연결될 수도 있습니다. 그렇지 않더라도, \u0026ldquo;구글에 다음과 같은 구절을 검색했지만 괜찮아 보이는 결과를 얻지 못했음\u0026quot;을 언급하는 것은 이메일이나 뉴스 포스팅에서 도움을 구하기 좋은 방법입니다. 어떤 검색들은 도움이 되지 않았는지를 기록해 둔다는 측면에서라도 말이죠. 뿐만 아니라, 그런 내용을 추가함으로써 당신과 유사한 문제를 가지고 있는 사람들은 검색어를 통해 곧장 현재 쓰레드로 연결될 수 있도록 하여 문제와 해결책을 찾을 수 있게 합니다.\n시간을 가지세요. 복잡한 문제를 구글링 몇 초로 해결할 수 있을거라고 기대하지 마세요. FAQ를 읽고 이해하고, 편히 앉아서, 차분히 마음을 가라앉히며, 전문가에게 문의하기 전 해당 문제에 대해 생각할 조금의 시간을 갖길 바랍니다. 우릴 믿어요, 우린 당신이 얼마나 많이 읽고 고민했는지를 질문에서 식별해낼 수 있으며, 충분히 준비된 채로 왔다면 더욱 진심으로 돕고자 할 것입니다. 단지 첫 검색 결과가 적절한 대답을 제공하지 않았거나 (혹은 너무 많은 결과를 제공했다고) 즉각적으로 질문 포화를 열지 말기를 바랍니다.\n질문을 준비하세요. 숙고하세요. 서두른다는 느낌이 드는 질문은 대강의 답변을 받거나 아예 답을 받지 못합니다. 도움을 구하기 전에 문제를 해결하고자 노력과 고민을 했다는 점이 더 드러날수록, 실제로 도움을 받을 확률은 더 높아집니다.\n잘못된 질문을 할 가능성을 인지하세요. 만일 틀린 전제 하에서 질문을 한다면, 아무개 해커는 아마도, 업로드 된 잘못된 질문 그 자체에는 올바른 답이지만 실질적으로 아무 도움이 안 되는 답변을 달며 \u0026ldquo;멍청한 질문이네\u0026hellip;\u0026ldquo;라고 생각할 것입니다. 그리고 나선, 실질적으로 필요한 것이 아닌 본인이 잘못 물은 질문에 답변을 받은 경험을 통해 당신이 교훈을 얻기를 기대할 겁니다.\n당신이 답변을 받을 자격이 있다고 생각하지 마세요. 아닙니다; 어쨌든, 당신은 비용을 지불하는 서비스 이용자가 아닙니다. 만일 당신이 답변을 제공 받는다면, 단지 수동적으로 타인의 지식을 요구하는게 아니라, 오히려 집단에게 추가 지식을 제공할 수도 있는 주요하고, 흥미롭고, 생각할 거리를 제공하는 질문을 했기 때문에 답변을 얻게 되는 겁니다.\n한편, 답변을 찾아가는 과정에서 도움을 주고자 하는 의지가 있고 능력도 있음을 명확히 밝히는 것은 좋은 출발입니다. \u0026ldquo;혹시 누가 링크라도 제공해줄래요?\u0026rdquo;, \u0026ldquo;내 예시에서 빠진게 뭐죠?\u0026rdquo;, 그리고 \u0026ldquo;어떤 사이트를 추가로 체크해봤어야 좋았을까요?\u0026rdquo; 등이 \u0026ldquo;내가 하면 되는 정확한 절차만 순서대로 적어주세요.\u0026ldquo;보다 정답을 얻기 유리합니다. 왜냐하면 당신은 누군가 정확한 방향만 제공한다면 답 찾는 과정을 완수할 거라는 진실된 의지를 명확히 보였기 때문이죠.\n질문할 때 포럼을 신중히 선택할 것 어디에 질문할지 선택하는 것은 중요합니다. 아래의 행동을 하면 무시 당하거나, 루저 취급을 받을 겁니다:\n주제에서 벗어난 포럼에 질문하는 행위 상당한 수준의 기술적 질문이 예상되는 포럼에 매우 기초적인 질문을 하거나 혹은 그 역에 해당하는 행위 서로 다른 뉴스 그룹에 너무 많이 포스팅하는 행위 당신과 아는 사이도 아니고, 당신의 문제에 책임이 있지도 않은 사람에게 개인 이메일을 보내는 행위 해커들은 관련 없는 것들로부터 본인들의 커뮤니케이션 채널이 잠식 당하는 것을 막기 위해서 부적절한 질문들은 날려버립니다. 당신도 이런 일이 발생하기를 원하진 않겠지요.\n따라서, 첫 번째 단계는 올바른 포럼을 찾는 것입니다. 다시 말하지만, 구글이나 다른 웹 검색 방법은 당신의 친한 친구입니다. 당신에게 어려움을 주고 있는 하드웨어나 소프트웨어와 가장 밀접한 관련이 있는 프로젝트 웹페이지를 찾기 위해 그 방법을 사용하세요. 보통 그런 웹사이트는 FAQ(자주 묻는 질문) 목록의 링크나, 프로젝트 메일링 리스트 링크, 혹은 과거 문서 링크가 있습니다. (FAQ등을 읽는 것을 포함한) 당신의 노력을 통해 해결책을 찾지 못한 경우라면, 메일링 리스트가 마지막으로 도움을 요청할 장소입니다. 프로젝트 페이지들은 보통 버그 신고 절차를 제시하고 있거나, 그에 대한 링크를 제공합니다; 제공한다면, 절차대로 진행하세요.\n익숙하지 않은 포럼이나 사람에게 이메일부터 발송하는 것은, 어떤 경우라도 위험합니다. 예를 들어, 정보 제공 웹페이지의 저자가 당신의 무료 상담사라고 가정하지 마십시오. 당신의 질문이 환영받을 거라는 낙관적인 추측을 하지 마세요 - 불확실하다면, 다른 곳으로 발송하거나 발송 자체를 하지 마세요.\n웹 포럼이나 뉴스 그룹, 메일링 리스트를 고를 때에는 이름 자체를 너무 과하게 신뢰하지 마세요; FAQ나 공지 등을 통해 당신의 질문이 주제에 적합한지 확인하기 바랍니다. 이전에 포스팅된 기존 트래픽을 몇 개 읽어서 그 곳에서는 어떤 식의 대화가 이루어지는지 확인하기 바랍니다. 사실, 뉴스 그룹이나 메일링 리스트에 포스팅하기 전에 그곳에서도 문제에 관련된 키워드를 검색해보는 것이 좋은 방법입니다. 정답을 찾을 수 있을 뿐더러, 그렇지 않더라도 더 좋은 질문을 구성하는데 도움이 되기 때문입니다.\n도움이 될 것으로 보이는 다수의 채널에 한꺼번에 질문을 올리지 마세요. 그것은 마치 소리지르는 것과 같아서 사람들을 짜증나게 합니다. 하나 하나 차근차근 진행하세요.\n어떤 주제인지 정확히 알기를 바랍니다! 오래되고 잦은 실수 중 하나는 유닉스나 윈도우즈 프로그래밍 인터페이스 관련 질문을 두 운영체제 모두에서 사용 가능한 도구, 라이브러리, 언어 관련 포럼에 올리는 실수입니다. 이게 왜 문제가 되는지 이해를 못하겠다면, 이해할 때까지 질문을 하지 않는게 최선입니다.\n일반적으로, 잘 선택된 공개 포럼에 질문하는 것이 사적인 포럼에 하는 것보다 유용한 답변을 받을 확률이 높습니다. 이에는 다양한 이유가 있습니다. 하나는 잠재적 답변자의 수가 많다는 점입니다. 다른 이유는 보고 있는 사람이 많다는 점입니다; 해커들은 소수의 사람에게 도움이 되는 것 보다는 다수의 사람을 가르칠 수 있는 질문에 대답하는 것을 선호합니다.\n어느 정도 이해는 되지만, 숙련된 해커나 유명 소프트웨어 제작자들은 잘못 타게팅된 메시지들을 적당한 수준을 넘어서 너무나 많이 받고 있습니다. 이 메시지 홍수에 하나를 더 보탬으로써, 당신이 드디어 낙타의 등을 부러뜨리는 마지막 지푸라기가 되는 극단적인 경우일지도 모릅니다. - 꽤나 자주, 유명 프로젝트 공헌자들이 더 이상 견딜 수 없는 수준의 쓸모 없는 이메일 트래픽 등의 부수적 피해로 도움을 중단하는 경우가 발생합니다.\n스택 오버플로우 검색하세요, 그리고나서 스택 익스체인지에 질문하세요.\n최근 수 년동안, 스택 익스체인지 커뮤니티 사이트들은 기술적이거나 여타 다른 질문에 대한 대답을 제공하는 주요한 자원이 되었고, 심지어 꽤 많은 오픈-소스 프로젝트의 선호되는 포럼이기도 합니다.\n스택 익스체인지를 찾기 전에 구글 검색부터 시작하세요; 구글은 실시간으로 색인을 합니다. 누군가 유사한 질문을 이미 했을 확률이 매우 높고, 스택 익스체인지 사이트들은 검색 결과 최상단 근처에 위치합니다. 구글 검색 결과로부터 별다른 것을 찾지 못했다면, 당신의 질문과 가장 관련 있는 사이트로 특정해 재검색하세요(아래 참조). 태그로 검색하는 것도 검색 결과를 좁히는데 유용합니다.\n그래도 아무것도 찾지 못했다면, 가장 주제에 맞는 하나의 사이트에 질문을 남기십시오. 코드와 관련해서는 특히, 형식을 맞춰주는 도구(pre-formatting tools)를 사용하고, 본인의 질문과 가장 본질적으로 관련 있는 태그를 추가하시기 바랍니다 (특히 프로그래밍 언어 이름, 운영 체제, 또는 문제가 있는 라이브러리를 적으세요). 만약 누군가가 댓글로 더 자세한 정보를 요구한다면, 해당 정보를 포함할 수 있도록 메인 포스트 자체를 수정하시기 바랍니다. 특정 답변이 도움이 된다면, 윗 방향 화살표를 클릭해 추천하세요; 특정 답변이 해결책이었다면, 추천 화살표 아래의 체크 표시를 클릭해 답변으로 채택하기 바랍니다.\n스택 익스체인지는 100개가 넘는 사이트로 발전하였습니다, 그러나 아래에 후보로 가장 적합한 것들을 제시합니다.\nSuper User는 일반 사용자의 컴퓨팅과 관련한 질문에 적합합니다. 당신의 질문이 코드나 네트워크 환경 하에서만 사용하는 특정 프로그램과 연관이 없다면 이 곳이 적합합니다. Stack Overflow는 프로그래밍 관련 질문에 적합합니다. Server Fault는 서버와 네트워크 관리 질문에 적합합니다. 몇몇의 프로젝트는 본인들만의 사이트를 가지고 있습니다. 예를 들어, 안드로이드, 우분투, TeX/LaTeX 그리고 SharePoint등이 그러합니다. 스택 익스체인지 사이트를 통해 최신 리스트를 확인하길 바랍니다.\n웹과 IRC 포럼 지역 사용자 모임이나 리눅스 배포판은 초보 사용자들이 도움 받을 수 있는 웹 포럼이나 IRC 채널을 홍보할 것입니다. (비 영어권 국가들의 경우, 초보 사용자 포럼은 메일링 리스트일 확률이 높습니다.) 이러한 곳들은, 특히 본인이 상대적으로 간단한, 혹은 공통적인 문제에 걸려 넘어졌다고 판단한다면 질문하기에 적합한 곳들입니다. 홍보 중인 IRC 채널은 아무나 입장해서 질문할 수 있고 실시간 답변을 받을 확률이 높습니다.\n사실, 문제를 일으키는 프로그램을 리눅스 배포판(최근에 더 흔해졌기 때문에)으로부터 제공 받았다면, 해당 배포판의 포럼/리스트에 질문하는 것이 프로그램의 프로젝트 포럼/리스트에 질문하는 것보다 낫습니다. 프로젝트 해커들은 아마도 \u0026ldquo;우리 빌드를 사용하세요\u0026quot;라고 답하고 말 것입니다.\n어떤 웹 포럼이든 포스팅하기 전에, 검색 기능이 있는지 확인하십시오. 있다면, 당신의 문제와 관련된 몇 개의 검색어를 시도하세요; 혹시 도움이 될지 모릅니다. 일반적인 웹 검색을 마쳤더라도(그랬어야만 하고), 포럼에서도 어쨌든 검색해보십시오; 웹 전반 검색 엔진이 해당 포럼까지 최근에 색인하지는 않았을지도 모릅니다.\n프로젝트들 사이에서 사용자 지원은 웹 포럼이나 IRC 채널을 통해 하고 이메일을 기반으로 하는 대화는 개발 트래픽을 위해 아끼는 경향이 늘어나고 있습니다. 따라서 특정한 프로젝트와 관련된 도움을 구하는 것이라면 그런 채널을 찾아보길 바랍니다.\nIRC에서는, 입장 하자마자 본인의 문제 상황과 관련된 설명을 길게 늘어놓지 않는 것이 좋습니다; 몇몇 사람은 이 행동을 채널-도배로 받아들입니다. 최고의 방법은 채널에서 대화를 열기 위해 우선 한 줄 정도로 상황 설명을 하는 것입니다.\n두 번째 단계로써, 프로젝트 메일링 리스트를 활용할 것 프로젝트가 개발 메일링 리스트를 가지고 있다면, 비록 당신의 질문에 대답해줄 최선의 사람이 누구인지 알 것 같더라도 개인에게 메일을 보내지 말고 리스트에 작성하십시오. 프로젝트 문서나 홈페이지를 통해 프로젝트 메일링 리스트 주소를 찾은 후 그 것을 사용하세요. 이러한 방법을 권장하는 이유가 여럿 있습니다:\n한 명의 개발자에게 좋은 질문은 모든 그룹에게도 가치가 있습니다. 반대로, 질문이 메일링 리스트에 올리기는 너무 멍청하다고 스스로 추측한다면, 그 역시도 개별 개발자를 괴롭힐 변명이 될 수 없기는 마찬가지 입니다. 리스트에 질문 하는 것은 개발자 부담을 분산 시킵니다. 개별 개발자(특히, 프로젝트 리더)는 당신의 질문에 대답하기에는 너무 바쁠지도 모릅니다. 대부분의 메일링 리스트는 보관되고, 일반적으로 보관된 메일들은 검색 엔진에 의해 색인됩니다. 만약 당신이 리스트에 질문을 올리고 답변이 달린다면, 미래의 질문자는 질문을 찾을 수 있고 다시 질문할 필요 없이 웹상에서 답변을 구할 수 있게 됩니다. 만약 특정 질문이 자주 반복되는 것으로 보인다면, 개발자들은 해당 정보를 활용하여 소프트웨어나 문서를 덜 헷갈리게 개선할 수 있습니다. 그러나 개별적으로 질문한다면, 아무도 해당 질문이 어느 정도나 반복되는지에 대한 전체적인 그림을 그릴 수 없게 됩니다. 만약 프로젝트가 \u0026ldquo;사용자\u0026quot;와 \u0026ldquo;개발자\u0026rdquo;(또는 \u0026ldquo;해커\u0026rdquo;) 메일링 리스트나 포럼을 모두 가지고 있다면, 코드를 해킹하고 있지 않는 이상, \u0026ldquo;사용자\u0026rdquo; 리스트/포럼에 질문하기 바랍니다. 개발자 리스트에서도 환영받을 거라고 기대하지 마시기 바랍니다. 그 곳에선 아마도 해당 질문을 소음이나 개발자 트래픽 낭비 정도로 취급할 것입니다.\n그러나, 당신의 질문이 사소한 것이 아니라고 확신 할 수 있거나, \u0026ldquo;사용자\u0026rdquo; 리스트/포럼에서 수 일간 답변이 달리지 않는 경우라면, \u0026ldquo;개발자\u0026rdquo; 리스트/포럼을 시도하시기 바랍니다. 포스팅 전에 해당 프로젝트만의 방식 등을 배우기 위해 수 일 동안 있었던 메시지나 보관된 메시지를 읽으며 며칠 간 숨어있기를 권장합니다. (사실 이것은 사적이거나 사실상 사적인 리스트에도 해당하는 좋은 충고입니다)\n만약 프로젝트의 메일링 리스트 주소는 찾을 수 없고 해당 프로젝트 관리자의 주소만 보인다면, 관리자에게 작성하기 바랍니다. 하지만 그런 경우일지라도, 메일링 리스트가 존재하지 않는다고 추측하지 마십시오. 이메일에 분명하게, \u0026lsquo;메일링 리스트를 찾아 보았으나 적절한 것을 찾지 못했음\u0026rsquo;을 명시하기 바랍니다. 또한, 당신의 메일이 다른 사람들에게 전달되는 것을 개의치 않음을 밝히십시오. (많은 사람들이 사적인 이메일은 사적인 것으로 남아야 한다고 믿습니다. 그 안에 사적인 것이 아무 것도 없더라도 말이죠. 전달을 허락함으로써 응답자가 당신의 이메일을 어떻게 다루어야 할지 선택할 기회를 제공합니다)\n의미있고 특정적인 제목 헤더를 사용할 것 메일링 리스트, 뉴스 그룹, 웹 포럼을 막론하고, 제목 부분은 50 글자 이하로 숙련된 전문가의 관심을 끌 수 있는 최상의 기회입니다. 그런 기회를 \u0026ldquo;제발 저 좀 도와주세요\u0026quot;등의 헛소리로 낭비하지 않기를 바랍니다 (\u0026ldquo;쫌 도와줘!!!!\u0026rdquo; 따위는 바로 버려집니다). 당신의 괴로움 수준으로 우리를 놀래키려 하지 마십시오; 해당 공간은 상당히-구체적인 문제 설명을 위해 사용하기 바랍니다.\n제목 란의 좋은 예시는, 많은 기술 지원 단체들이 사용하고 있듯이, \u0026ldquo;목적 - 편차\u0026rdquo; 입니다. \u0026ldquo;목적\u0026rdquo; 부분은 문제점이나 문제들의 그룹을 명시하고 \u0026ldquo;편차\u0026rdquo; 부분은 예측된 행동으로 부터 벗어난 편차를 설명하는 부분입니다.\n멍청함: 도와줘! 내 노트북 비디오가 제대로 작동하질 않아!\n현명함: X.org 6.8.1 에서 마우스 커서 동작 이상, 아무개제조사 MV1005 비디오 칩셋\n더 현명함: 아무개제조사 MV1005 비디오 칩셋에서 X.org 6.8.1 마우스 커서 - 이상 행동\n\u0026ldquo;목적 - 편차\u0026rdquo; 방식으로 설명하는 과정 자체가 스스로 문제를 더욱 자세히 생각하게 만들어줍니다. 무엇이 영향을 받았나요? 단지 마우스 커서인가요 아니면 다른 그래픽도 문제인가요? 이 문제가 X의 X.org 특정 버전에서만 그런가요? 그 버전이 6.8.1 인가요? 아니면 이 문제가 아무개제조사 비디오 칩셋에서만 문제인가요? 아니면 모델 MV1005만 문제인가요? 결과를 읽는 해커는 당신이 무슨 문제를 겪고 있는지 뿐만 아니라 어떠한문제를 겪고 있는지를 한 눈에 알 수 있습니다.\n더 일반적으로, 제목들만 보이는 질문 보관 색인을 보고 있다고 상상해보기 바랍니다. 제목 부분을 본인의 질문과 더 잘 부합하도록 적음으로써 비슷한 질문을 검색하고 있는 다음 사람이 추가적인 질문을 다시 올리는 것보다 더 쉽게 답변이 달린 쓰레드를 찾을 수 있도록 만들어줍니다.\n답변에 추가 질문을 한다고 하면, 질문을 하고 있다는 것을 확실히 하기 위해 제목 부분을 수정하는 것을 확실히 하기 바랍니다. \u0026ldquo;답변: 테스트\u0026quot;나 \u0026ldquo;답변: 새로운 버그\u0026rdquo; 처럼 보이는 제목은 유용할 만큼의 관심을 받을 확률이 줄어듭니다. 또한, 새로운 독자들에게 문맥을 파악할 최소한의 일관성을 위해 이전 답변의 일부를 인용하기 바랍니다.\n완전히 새로운 쓰레드를 시작할 것임에도 단순히 리스트의 메시지에 답변을 클릭하지 마십시오. 이것은 당신의 답변 대상을 제한합니다. 일부 메일 리더 프로그램은, 예를 들어 mutt의 경우, 유저가 쓰레드로 정렬하고 쓰레드를 접음으로써 일부 메시지들을 가릴 수 있도록 합니다. 그런 기능을 사용 하는 사람들은 당신의 메시지를 영원히 보지 못합니다.\n제목 변경으로는 충분하지 않습니다. Mutt와 다른 메일 리더 프로그램들은 이메일을 쓰레드에 편입하기 위해 제목 뿐만 아니라 다른 정보들도 확인합니다. 차라리 완전히 새로운 이메일을 작성하십시오.\n웹 포럼에서의 좋은 방법에 해당하는 규칙은 약간 다른데, 이는 메시지들이 더 엄격한 논의 쓰레드 규정에 의해 관리되기 때문에 다른 쓰레드에서는 잘 보이지 않기 때문입니다. 답변에서 질문을 할 때는 제목 변경이 불필요합니다. 모든 포럼이 답변에 제목 부분을 허용하는 것은 아닐 뿐더러, 허용하더라도 그것을 아무도 읽지 않습니다. 어쨌든, 답변에서 질문을 하는 것이 바보 같은 짓인 이유는 그 쓰레드를 읽는 사람 외에는 누구도 읽지 않을 것이기 때문입니다. 따라서, 해당 쓰레드 인원만 질문을 읽기를 본인 스스로 바라지 않는 이상 새로운 쓰레드를 시작하기 바랍니다.\n답변하기 쉽도록 할 것 질문을 \u0026ldquo;대답은 여기로 보내주세요\u0026hellip;\u0026ldquo;로 마치는 것은 대답을 받을 확률을 낮춥니다. 이메일 프로그램에서 회신란을 정확히 수정하는 몇 초 조차도 감수하기 싫은거라면, 답변자들오 질문을 해결하고자 고민하는 몇 초를 감수하기 싫을 것입니다. 만약 사용 중인 프로그램이 이런 기능을 지원하지 않는다면, 더 나은 프로그램을 사용하기 바랍니다. 만약 당신의 운영체제가 이런 기능을 지원하는 이메일 프로그램을 단 하나도 지원하지 않으면, 더 나은 운영 체제를 사용하기 바랍니다.\n웹 포럼에서 정보가 민감한 것들이라고 생각하지 않는 이상, 답변을 이메일로 요구하는 것은 예의 없는 행위입니다. (누군가는 알 수 없는 이유로 그렇게 해줄지도 모르나, 전체 포럼은 아닙니다.) 만약 쓰레드 답변에 대한 복사본을 이메일로 받기를 원한다면, 웹 포럼 자체가 발송하도록 설정하기 바랍니다; 이 기능은 대부분의 포럼이 \u0026ldquo;쓰레드 즐겨찾기\u0026quot;나 \u0026ldquo;답변 이메일로 보내기\u0026rdquo; 등의 옵션을 통해 지원하고 있습니다.\n깔끔하고 문법적으로 올바르고 오/탈자가 없도록 쓸 것 우리는 부주의하고 대충 글을 쓰는 사람들이 생각이나 코딩에 있어서도 부주의하고 대충일 가능성이 (내기할 수 있을 만큼) 크다는 것을 경험을 통해 발견하였습니다. 부주의하고 대충 생각하는 사람들을 위해 답변하는 것은 가치가 없습니다; 차라리 우리 시간은 다른 곳에 쓰는게 낫습니다.\n따라서 당신의 생각을 명확하게 표현하는 것이 중요합니다. 그렇게 하기 귀찮다면, 우리도 관심을 갖기 귀찮습니다. 당신의 표현을 다듬을 별도의 노력을 취하세요. 딱딱하거나 격식을 차릴 필요까진 없습니다 - 사실, 해커 문화는 적재적소에 잘 사용된 격식 차리지 않은, 혹은 심지어 (비)속어인, 유머러스한 언어를 더 가치 있게 생각합니다. 하지만 적절히 사용되어야 합니다; 당신이 생각하고, 집중하고 있다는 것을 나타내는 무언가가 필요하기 때문입니다.\n맞춤법, 문장부호와 대문자를 정확히 사용하십시오. \u0026ldquo;않\u0026quot;을 \u0026ldquo;안\u0026quot;으로, \u0026ldquo;돼\u0026quot;를 \u0026ldquo;되\u0026quot;로 \u0026ldquo;데\u0026quot;를 \u0026ldquo;대로 혼동하지 마십시오. 쩐뿌 떄문짜로 짞썽하찌(TYPE IN ALL CAPS) 마십시오. 이는 소리지르는 것으로 읽히고 무례하다고 여겨집니다. (모두 소문자로 적는 것은 덜 짜증나지만, 읽기 어렵습니다. Alan Cox는 괜찮아도 너는 안돼요)\n더 일반적으로, 문맹처럼 쓰면 무시될 것입니다. 따라서 카톡 줄임말 같은 것들을 사용하지 마십시오. \u0026ldquo;맞아요\u0026quot;를 \u0026ldquo;ㅇㅇ\u0026quot;로 쓰는 행위들이 몇 글자 덜 입력하는 것을 위해 문맹처럼 보이게 만듭니다. 더 심각한 경우: 댕댕이, 머머리와 같은 인터넷 용어를 사용하는 것은 사망 선고나 다름없고 그 어떤 대답 없이 차가운 침묵만이 돌아올 것임을 보장합니다. (혹은, 경멸이 섞인 도움이나 비꼬는 대응이 있을지도 모름)\n본인의 모국어가 아닌 포럼에서 질문을 하는 경우, 약간은 느슨한 맞춤법 검사나 문법 검사가 이루어질지는 모르나 게으름에 대해선 그런 느슨함은 없습니다. (맞아요, 우린 그런 차이를 구분해낼 수 있습니다) 또한, 응답자의 모국어가 무엇인지 알지 못하는 경우, 영어로 쓰십시오. 바쁜 해커들은 이해하지 못하는 언어로 된 질문은 치워버리는 경향이 있고 영어는 인터넷에서 인정받는 언어입니다. 영어로 씀으로써 질문이 안 읽히고 버려지는 경우를 최소화할 수 있습니다. 만약 외국어로써 영어로 작성하고 있다면, 잠재 응답자들에게 언어상의 어려움을 알리고 그런 애로사항을 피하는 좋은 형식들이 있습니다. 예를 들어:\n영어는 제 모국어가 아닙니다; 타이핑 오류는 양해를 구합니다. English is not my native language; please excuse typing errors. 만약 \u0026lsquo;$언어\u0026rsquo;를 할 줄 안다면, 제게 이메일/쪽지 주세요; 제 질문을 번역하기 위한 도움이 필요합니다. If you speak $LANGUAGE, please email/PM me; I may need assistance translating my question. 기술적 용어는 익숙하지만, 일부 속어 표현이나 숙어는 아직 어렵습니다. I am familiar with the technical terms, but some slang expressions and idioms are difficult for me. 제 질문을 \u0026lsquo;$언어\u0026rsquo;와 영어로 올렸습니다. 만약 둘 중 하나의 언어만 사용하시더라도, 답변을 주시면 제가 번역하고자 합니다. I\u0026rsquo;ve posted my question in $LANGUAGE and English. I\u0026rsquo;ll be glad to translate responses if you only use one or the other. 질문은 접근 가능하고 표준적인 형식으로 보낼 것 질문을 일부러 읽기 어렵게 만들면, 쉬운 질문을 위해 지나칠 가능성이 큽니다. 따라서:\nHTML이 아닌, 일반 텍스트 메일(plain text)을 보내십시오. (HTML을 끄는 것은 어렵지 않습니다) MIME 첨부는 일반적으로 괜찮습니다. 그러나 그 안에 실질적인 내용이 있을 경우에만 그렇습니다. (소스 파일이나 패치 파일 첨부 등의 경우) 그러나 메일 클라이언트에 의해 작성된 양식은 괜찮지 않습니다 (예를 들어, 본인 메시지의 복사본 등). 전체 문단이 한 줄이고 줄넘김이 여러차례 된 이메일을 보내지 마십시오. (이는 메시지 일부에 대한 답변을 하기 너무 어렵게 만듭니다.) 응답자가 80 글자 혹은 그 이하 너비의 텍스트 화면에서 메일을 읽을 거으로 가정하고, 줄넘김을 그에 맞게 설정하기 바랍니다. 그러나, (로그 파일이나 세션 정보 등)처럼 고정된 열 너비에서 출력된 데이터는 줄 넘기기 하지 마십시오. 데이터는 있는 그대로 포함되어야 합니다. 따라서 응답자들이 당신이 본 것과 같은 것을 보고 있다고 확신할 수 있어야 합니다. MIME Quotes-Printable 인코딩을 영어 포럼에 보내지 마십시오. 이 인코딩은 ASCII가 제공할 수 없는 언어 사용자의 포럼에서는 필요할지 모르나 대부분의 이메일 프로그램은 지원하지 않습니다. 이 인코딩이 부서질 경우, 깨진 글자들의 나열은 보기 어렵고 거슬립니다 - 어쩌면 전송한 내용의 원래 의미를 해칠수도 있습니다. 절대, 절대로 해커들이 마이크로소프트 워드나 엑셀처럼 특허권 있는(proprietary) 문서 양식을 읽을 수 있으리라 기대하지 마십시오. 대부분의 해커들은 당신이나 제공한 파일에 대해서 문짝에 던져진 아지랑이 피어오르는 돼지 거름을 본 것처럼 반응할 것입니다. 비록 어떻게 열어볼 수는 있을지언정, 그래야 한다는 점에 분개할 것입니다. 만약 윈도우 기계에서 이메일을 보내야 한다면, 마이크로소프트의 문제가 많은 \u0026ldquo;Smart Quotes\u0026quot;기능을 끄기 바랍니다. (Tools\u0026gt;AutoCorrect Options, AutoFormat As You Type 아래의 smart quotes 체크박스 해제) 이로써 당신의 메일이 쓰레기 글자들로 변하는 것을 막을 수 있습니다. 웹 포럼에서, \u0026ldquo;웃는 이모티콘\u0026quot;이나 \u0026ldquo;HTML\u0026quot;기능을 (제공된다면)남용하지 마십시오. 한 개나 두 개는 괜찮지만 여러개의 색깔까지 있는 화려한 글자들은 너를 찐따처럼 보이게 만듭니다. 진지하게, 과도한 이모티콘 사용, 색깔, 특이한 폰트 사용은 실실대는 10대 소녀처럼 보이게 할 뿐, 답변보다 섹스에 관심있는게 아니라면 좋은 아이디어가 아닙니다. 만약 넷스케이프 메신저, MS 아웃룩과 같은 그래픽 환경 이메일 클라이언트를 사용한다면, 기본 설정으로 사용될 경우 규칙들을 어길 수도 있음을 인지하십시오. 대부분 그런 클라이언트들은 메뉴 기반의 \u0026ldquo;소스 보기\u0026quot;가 있습니다. 보낸 메일함에 있는 메일 등에 사용하여, 쓸데 없는 것들이 포함되지 않고 일반 글자(Plain Text) 양식으로 전송되는지 확인하시기 바랍니다.\n문제에 대해 정밀하고 정보가 충분히 제공되도록 할 것 문제의 증상이나 버그를 조심스럽게 그리고 명확하게 묘사할 것 (기기, 운영 체제, 프로그램, 뭐든지) 그 것이 발생하는 환경을 묘사할 것. 제조사의 배포판이나 출시 버전을 제공할 것. (예, \u0026ldquo;Fedora Core 7\u0026rdquo;, \u0026ldquo;Slackware 9.1\u0026rdquo;, 등) 질문 전에 문제를 이해하기 위해 시도했던 검색 과정을 서술할 것 질문 전에 문제를 스스로 규정하고 해결해보고자 했던 진단 절차를 서술할 것 관련 있을 가능성이 있는 컴퓨터 변화나 소프트웨어 설정 변경을 서술할 것 가능하다면, 통제된 환경에서 해당 문제를 재발생 시킬 수 있는 방법을 제공할 것 해커들이 물을 만한 것들에 대해서 심사숙고 하는데 최선을 다하고, 도움 요청에 앞서 그런 질문에 대한 답을 하십시오.\n만약 코드의 버그를 신고하는거라면 통제된 환경하에서 해당 문제를 재발생시킬 수 있는 방법이 해커들에게 특히 중요합니다. 이렇게 한다면, 유용한 답변을 받을 확률과 속도가 동시에 월등히 개선됩니다.\nSimon Tatham은 버그 신고 효율적으로 하는 방법에 대해서 훌륭한 에세이를 작성하였습니다. 읽어보기를 강력히 권장합니다.\n양은 정확도가 아니다 정확하고 정보를 충분히 제공해야만 합니다. 이 목적은 도움 요청을 위한 데이터나 엄청난 양의 코드를 단순히 쏟아붇는다고 달성되지 않습니다. 프로그램 작동을 멈추는 크고 복잡한 테스트 케이스가 존재한다면, 가능한 작게 줄이는 것을 시도하기 바랍니다.\n이것은 최소 세 가지의 이유로 유용합니다. 째: 질문을 단순화하고자 노력한 것을 보이는 것은 답변을 받을 확률을 높인다, 둘째: 질문을 단순화하는 것은 유용한 답변을 받을 확률을 높인다, 셋째: 버그 신고를 다듬는 과정에서 해결 방법을 스스로 찾을 가능성이 있다.\n버그를 찾았다고 섣불리 판단하지 말 것 소프트웨어 사용상 문제가 발생했을 때, 아주 아주 확신하지 않는 이상 버그를 발견했다고 주장하지 마십시오. 힌트: 문제를 해결할 수 있는 소스 코드 패치를 제공할 수 없거나, 이전 버전과 비교해 잘못된 행동을 유발하는 부분을 찾는 회귀 테스트(regression test)를 진행하기 전에는 확신하지 못하는 겁니다. 이는 웹페이지나 문서에서도 적용됩니다; 문서에서 \u0026ldquo;버그\u0026quot;를 발견했다면, 대체 텍스트를 제공하거나 원래 있어야 할 페이지를 제공해야만 합니다.\n당신이 겪는 문제를 다른 수많은 사람들은 겪지 않는다는 점을 기억하기 바랍니다. 그게 아니라면, 웹 검색 과정이나 문서를 읽는 도중에 학습할 수 있었을 겁니다(불평 전에 이 과정을 거쳤겠죠, 아닌가요?). 이는 매우 높은 확률로 당신이 뭔가를 잘못한 거지, 소프트웨어 탓이 아님을 의미합니다.\n소프트웨어 제작자들은 가능한 잘 작동하도록 매우 노력합니다. 만약 버그를 찾았다고 주장한다면, 그것이 사실이라고 하더라도 그 개발자들 일부에 대한 공격이 될 수도 있고, 그들의 노력을 물거품으로 만드는 것입니다. 특히 제목 부분에 \u0026ldquo;버그\u0026quot;라고 소리치는 것은 현명하지 못합니다.\n질문을 할 때는, 당신 스스로가 무언가 잘못했다고 적는 것이, 비록 속으로 진짜 버그를 찾았다고 꽤나 확신할지라도 현명할지도 모릅니다. 실제로 버그였다면, 답변에서 그와 관련해 소식을 들을 수 있습니다. 그런 식으로 행동하는 편이, 실제 버그가 있었을 때 관리자가 당신에게 사과하는 상황이 되며, 버그가 아니라서 당신이 관리자에게 사과해야 하는 상황이 되는 것보다 낫습니다.\n굽신거리는 것은 숙제를 대신해주지 않는다 답변을 요구하는 사람 중에, 무례하거나 거만하게 행동해서는 안된다는 것을 이해하는 사람 중 일부는 오히려 후퇴하여 반대로 극단적인 굽신거리는 모습을 보입니다. \u0026ldquo;나도 내가 찐따 뉴비 루저라는 걸 알아요, 하지만\u0026hellip;\u0026rdquo;. 이건 의미 없고 도움이 되지 않습니다. 이 모습은 특히 실제 문제에 대해 애매모호한 태도와 동시에 발생할 때 짜증을 유발합니다.\n순전히 정치적인 목적으로 당신의 시간이나 혹은 우리의 시간을 낭비하지 마십시오. 차라리, 배경 상황이나 질문을 가능한 명확하게 드러내십시오. 그러는 쪽이 비굴한 것보다 나은 상황을 만듭니다.\n가끔 웹 포럼은 초보 사용자 질문을 위한 별도의 공간을 제공합니다. 초보 사용자 질문이라고 느끼면 그 공간으로 가세요. 그렇다고 거기서 굽신거리라는 뜻은 아닙니다.\n추측이 아니라, 문제의 증상을 묘사할 것 해커들에게 당신이 생각하는 문제의 원인을 알리는 것은 도움이 되지 않습니다. (만약 당신의 진단 이론이 그렇게 대단하다고 생각되면 왜 타인의 도움을 필요로 하나요?) 따라서, 무언가 정상적으로 작동하지 않는 증상의 있는 그대로를 말하고 있는지 확실시 하고, 당신의 해석이나 이론을 늘어놓지 마십시오. 해커들이 알아서 해석하고 진단하도록 내버려 두세요. 만일 당신의 추측이 주요하다고 느껴지면, 추측이라는 점을 명백히 명시하고 그 해답이 왜 작동하지 않는지 서술하십시오.\n멍청함: 계속해서 커널 컴파일 과정에 SIG11 에러를 마주하는데 마더보드의 미세한 크랙이 원인인 것 같아요. 맞는지 확인하는 제일 좋은 방법이 뭐죠?\n현명함: 집에서 빌드한 256MB 커세어 PC133 SDRAM + (Apollo VP2 칩셋을 가진) FIC-PA2007 마더보드의 K6/233머신이 커널 컴파일 과정에서 파워-온 이후 20분간 SIG11에러를 빈번하게 쏟아냅니다. 다만, 첫 20분 동안은 안그랬습니다. 재부팅은 클럭을 재시작하지 않는데, 밤사이 전원을 내려두는 것은 클럭 재시작을 유발합니다. RAM을 모두 바꾸는 것도 도움이 되지 않았습니다. 컴파일 세션과 일반적으로 연관있다고 여겨지는 로그 부분은 다음과 같습니다.\n앞서 보여준 예시가 대부분의 사람들에게 잘 와닿지 않을 것으로 판단되기 때문에, 한 구절을 상기시켜 드립니다: \u0026ldquo;모든 진찰 전문의는 미주리 주 출신이다\u0026rdquo;. 미주리 주의 공식 모토는 \u0026ldquo;보여라\u0026quot;입니다. (1899년 유래, 하원 의원 Willard D. Vandiver가 \u0026ldquo;나는 옥수수, 목화, 우엉과 민주당원을 기르는 주에서 왔다. 의미 없는 허풍은 나를 설득시키지도 만족시키지도 못한다. 나는 미주리주 출신이다. 내게 실체를 직접 보여달라\u0026quot;고 함) 진찰 전문의에겐 시각적으로 즉각 확인할 수 있는 직접적 증거가 추측이나 요약보다 \u0026lsquo;확인할만한 가치가 있는 것\u0026rsquo;입니다. 그냥 보여주십시오.\n문제의 증상을 시간 순서대로 묘사할 것 무언가 고장난 것을 해결하기 위해 가장 유용한 단서는 보통 바로 직전에 일어난 사건에 있습니다. 따라서, 부서지기 전에 당신이 무슨 짓을 했는지, 혹은 기계나 소프트웨어가 무슨 짓을 했는지 묘사하는 것이 당신 설명의 중점이 되어야 합니다. 커맨드 라인의 경우, 세션 로그(예를 들어, 스크립팅 유틸을 활용)나 20여 줄 정도의 관련 인용을 보이는 것이 유용합니다.\n부서진 프로그램이 (예를 들어, 더욱 상세한 출력을 요구하는 -v와 같은) 진단에 쓰일 옵션을 가진다면, 기록을 위한 디버깅 자료에 추가될 수 있도록 그런 옵션을 선택하는 것을 시도하십시오. 하지만 많은 것이 반드시 더 좋은 것은 아님을 기억하십시오; 정보를 충분히 제공할 뿐, 읽는 이를 쓰레기더미에 질식시키지 않을 수준의 디버그 레벨을 잘 선택하기 바랍니다.\n설명이 (대략 4개 문단을 넘어서) 매우 길어진다면, 차라리 문제를 가장 상단에 명시하고, 시간 순서대로 있었던 일들은 그 아래에 나열하는 것이 도움이 됩니다. 그런 경우엔, 해커들이 당신의 설명을 읽으며 무엇을 찾아야 할지 알 수 있습니다.\n단계가 아니라 목적을 설명할 것 만약 당신이 (버그를 신고하는 것과 다르게) 어떤 것을 하는 방법을 찾고자 시도중이라면, 그 목적을 묘사하는 것으로부터 출발하십시오. 그래야만 당신이 가로막힌 곳으로부터 목적으로 가는 길을 단계별로 설명할 수 있습니다.\n기술적 도움을 필요로 하는 사람들은 자주 더 상위 수준의 목표를 마음에 가지고 있고 그 목표를 향한 단 하나만의 특정한 경로가 있다고 생각합니다. 그 경로에 대해 도움을 구하러 오지만, 경로가 틀렸을거란 생각은 하지 못합니다. 이것을 해결하기 위해 상당한 노력을 필요로 합니다.\n멍청함: 아무개 그림판 프로그램에서 16진수 RGB 값을 얻기 위해 색 선택기를 어디서 찾을 수 있나요?\n현명함: 이미지의 컬러 표에서 원하는 색상으로 색을 교체하려고 시도중입니다. 현재로서 제가 생각할 수 있는 유일한 방법은 각 표의 칸을 수정하는 것이지만 아무개 그림판에서 16진수 RGB 값을 얻기 위한 색 선택기를 찾을 수가 없네요.\n두 번째 버전의 질문이 더 똑똑한 것입니다. 임무를 수행하기 위한 더 좋은 도구를 제안할 수 있도록 하기 때문입니다.\n개인 이메일로 회신을 요구하지 말 것 해커들은 \u0026lsquo;문제 해결이란 앞서 달린 답변이 불완전하거나 부정확하다는 것을 더 전문가인 뒷 사람이 알아차린 경우엔 수정할 수도 있고, 수정해야만 하는 공개적이고 투명한 과정\u0026rsquo;으로 믿습니다. 또한, 도운 사람들은 그의 동료들에게 유능하고 박식한 것으로 보여졌다는 점에서 답변 행위의 보상을 얻습니다.\n개인 회신의 요청은, 과정과 보상을 모두 망치는 것입니다. 하지 마십시오. 사적으로 회신할 것인지의 선택은 응답자의 몫입니다 - 그리고 답변자가 만약 그렇게 하기로 했다면, 본인이 보기에 다른 사람이 흥미를 느끼기에는 너무도 당연한 것이거나 질문의 형식 자체가 틀렸기 때문일 것입니다.\n이 규칙엔 한 가지의 예외가 있습니다. 본인이 생각하기에 질문이 서로 유사한 답변을 너무나 많이 받을 것으로 생각되는 경우, \u0026ldquo;이메일 주시면 그룹을 위해 제가 답변들을 요약하겠습니다\u0026quot;라는 마법의 단어들을 추가하면 됩니다. 메일링 리스트나 뉴스 그룹을 동일한 포스팅의 엄청난 양의 홍수로부터 구하려는 시도는 공손한 것입니다 - 하지만 요약하겠다는 약속은 반드시 지켜야 합니다.\n질문을 명확히 밝힐 것 열린 질문은 보통 끝이 없는 시간 낭비로 여겨집니다. 당신에게 답을 줄 수 있을 것으로 여겨지는 사람들도 대개 (그 사람들도 생업이 있기 때문에) 엄청나게 바쁜 사람들입니다. 그런 사람들은 끝없는 시간 낭비에 알레르기 반응을 일으키기 때문에 마찬가지로 열린 질문에도 알레르기 반응을 보입니다.\n당신이 응답자들에게 원하는 것(링크 제공, 소스 코드 제공, 패치 확인 등 뭐든지)에 대해서 분명히 밝힌다면 유용한 대답을 확보할 가능성이 큽니다. 이는 당신을 돕기 위해 응답자들이 가용한 최대 범위의 시간과 노력을 기울이게 합니다. 좋은 일이죠.\n전문가들이 사는 세상을 이해하고자 한다면, 아주 사소한 것에 응답하기 위한 엄청난 양의 자료와 시간을 필요로 하는 전문 분야를 생각해보세요. 당신이 구하고자 하는 헌신의 양이 적을수록, 굉장히 바쁜 사람들로부터 양질의 답을 구할 확률이 더 높아집니다.\n따라서 해당 분야 전문가에게 필요로 될 시간 소모를 줄이도록 질문을 다듬는 것이 유용합니다 - 그러나 이건 꼭, 질문을 \u0026lsquo;단순화\u0026rsquo;하라는 것과 같은 의미는 아닙니다. 결국은, 예를 들자면, \u0026ldquo;X를 이해하기 위해 유용한 링크를 알려줄 수 있나요?\u0026ldquo;라는 질문이 \u0026ldquo;X좀 설명해줄래요?\u0026ldquo;보다 현명한 질문입니다. 정상 작동하지 않는 소스 코드가 있다면, 누군가 어디가 틀린 것 같은지 묻는 것이 고쳐 달라고 하는 것보다 보통 현명한 질문이 될 것입니다.\n코드에 대해 질문할 때 어떤 문제에 관해 이상이 있는지에 대한 힌트도 없이 당신이 만든 고장난 소스코드를 디버깅해달라고 요구하지 마십시오. 수백 줄의 소스 코드를 업로드하고선 \u0026ldquo;작동이 안되요\u0026quot;라고 떠드는 것은 무시당할겁니다. 열댓 줄의 소스 코드를 업로드한 후, \u0026ldquo;7번째 줄 이후 를 기대하고 있습니다만, 가 발생하는데요\u0026quot;라고 질문하는 것이 대답을 들을 확률을 높여줍니다.\n코드 문제에 관해 상세히 질문할 수 있는 가장 효과적인 방법은 버그임을 보여주는 최소한의 테스트 케이스를 제공하는 것 입니다. 최소한의 테스트 케이스란 무엇을 의미할까요? 이는 문제 상황 묘사를 뜻합니다; 딱 원치 않는 행동을 드러내기 위해 충분할 정도면 됩니다. 어떻게 최소 테스트 케이스를 만들까요? 코드의 어느 줄이나 섹션이 문제의 행동을 생성하는지 알고 있다면, 그 부분을 복사한 후 완벽한 예시가 될 수 있도록 보충 부분을 추가합니다. (예를 들어, 코드 처리를 위한 컴파일러/인터프리터/뭐든간에 작동할 정도면 됩니다.) 만약 특정 섹션을 지목할 수 없는 상황이라면, 소스 코드의 복사본을 만든 후 문제 행동을 생성하는데 영향을 주지 않는 부분을 제거해나갑니다. 최소 테스트 케이스가 작을수록, 좋습니다. (\u0026ldquo;양은 정확도가 아니다\u0026quot;부분을 참고하세요)\n아주 작은 최소 테스트 케이스를 만드는 것이 항상 가능한 일은 아니지만, 그렇게 하고자 시도하는 것은 아주 좋은 훈련이 됩니다. 간혹 스스로 문제를 해결하는 방법을 찾게 도와주기도 하고 - 그렇지 않더라도 해커들은 뭔가 시도했다는 점을 확인할 수 있어서 좋습니다. 해커들이 더 협력적일 수 있도록 만들죠.\n만약 단순히 코드 리뷰를 원하는 것이라면, 미리, 리뷰가 필요한 특정 부분과 왜 필요한지를 명확히 명시하시기 바랍니다.\n숙제 문제를 올리지 말 것 해커들은 숙제 문제를 아주 잘 찾아냅니다; 대부분이 이미 풀어본 것이기 때문이죠. 그런 문제들은 당신이 경험으로부터 학습할 수 있도록, 당신이 직접 풀라고 만든 것입니다. 힌트를 구하는 것은 좋지만, 전체 해답은 안됩니다.\n숙제는 통과할 것으로 예상되지만, 어쨌든 풀지 못했을 때는, 유저 그룹 포럼이나 (최후의 수단으로) 프로젝트의 \u0026ldquo;사용자\u0026rdquo; 리스트/포럼에 도움을 구하시기 바랍니다. 해커들은 알아차리겠지만, 숙련된 사용자들이 최소한 힌트를 제공할 겁니다.\n의미 없는 질문을 제거할 것 \u0026ldquo;누구든 절 도와줄 수 있나요?\u0026ldquo;라든지 \u0026ldquo;정답이 있나요?\u0026ldquo;와 같은 구문상 아무 의미 없는 질문으로 요청을 마무리하고 싶은 욕망을 참으십시오. 우선: 문제 서술을 절반정도만 완벽히 했다면, 그런 추가 질문은 헛소리에 불과합니다. 둘째: 헛소리이기 때문에 해커들은 성가시다고 여깁니다 - \u0026ldquo;네, 도움 받을 수 있습니다\u0026quot;라든지 \u0026ldquo;아니요, 여기선 당신을 도울 사람이 없네요\u0026quot;같이 별 달리 분쟁을 일으키진 않지만 무시하는 듯한 답변을 받을 겁니다.\n일반적으로, 예-아니오 대답을 듣고자 하는 것이 아니라면, 그런 질문을 피하는 것을 권장합니다..\n아무리 본인에게 긴급하더라도, \u0026ldquo;긴급\u0026quot;등의 라벨을 붙이지 말 것 당신 문제지, 우리 문제가 아닙니다. 긴급하다고 주장하는 것은 역효과를 일으킬 확률이 높습니다: 대부분의 해커들은 그런 메시지를 즉각적이고 특별한 관심을 이끌어내려는 이기적이고 무례한 시도로 판단해 삭제하고 말 것입니다. 더욱이, \u0026lsquo;긴급\u0026rsquo;(이나 유사한 주의를 끄는 단어가 제목에 배치되면)은 거의 스팸 필터에 걸립니다 - 대답해주길 기대한 사람들은 정작 아예 못 볼지도 모릅니다!\n한 가지 준-예외가 있습니다. 해커들이 흥분할만큼 세간을 끄는 곳에서 프로그래밍을 사용하는 경우라면 언급할 가치가 있겠습니다; 그런 경우라면, 시간이 얼마 남지 않았음을 정중하게 표현한다면, 사람들이 더 급하게 답을 해줄만한 이목을 끌 수 있습니다.\n그러나, 해커들의 관심도는 당신이 생각하는 것과 다를 확률이 크기 때문에, 이는 매우 위험한 행동입니다. 예를 들어, 국제 우주 정거장에서 글을 쓰는 것은 해당하겠으나, 자선 단체나 정치적 이유로 쓰는 것은 확실히 해당하지 않겠죠. 사실, \u0026ldquo;긴급: 아기 물개를 살리는데 도움을 주세요\u0026quot;는 아기 물개가 중요하다고 생각하는 해커들로부터 생각지도 못한 뜨거운 관심을 받을 수도 있죠.\n이게 혼란스럽다면, 이 방법론 파트를 글을 올리기 전에 몇 번이고 반복해서 다시 읽기를 권합니다.\n공손함은 해치지 않는다, 간혹 도움이 된다 예의를 갖추세요. \u0026ldquo;부탁드립니다\u0026rdquo; 라든지 \u0026ldquo;관심을 보여주셔서 감사합니다\u0026rdquo; 혹은 \u0026ldquo;해결해주셔서 감사합니다\u0026quot;를 사용하시기 바랍니다. 무료로 당신을 돕고자 다른 사람들이 시간을 썼다는 점에 감사하고 있음을 명확히 보이세요.\n솔직히 말하자면, 이는 문법이 올바르고, 명확하고, 정밀하고 충분히 설명하고, 사적 포맷(proprietary format)을 사용하지 않는 것보다 중요하지 않습니다. (그리고 대체되지도 않습니다.); 일반적으로 해커들은 허무맹랑한 예의차림 보다는 차라리 무뚝뚝하지만 기술적으로 아주 날카로운 버그 리포트를 선호합니다. (이게 혼란스럽다면, 우린 우리 스스로가 뭔가 배울 것이 있는 질문에 가치를 둔다는 점을 기억하기 바랍니다.)\n그러나, 만약 기술적 해결이 필요한 질문이 연속으로 필요하다면, 정중함은 유용한 답변을 받을 확률을 증가시킨다는 점은 확실합니다.\n(이 방법론(HOWTO)과 관련해 베테랑 해커들로부터 받은 진지한 반대 의견은 \u0026ldquo;앞서 감사드립니다(Thanks in advance)\u0026ldquo;에 대한 이 글의 추천에 관한 것임을 밝힙니다. 일부 해커들은 이 표현을, 문제가 해결된 이후로는 감사하지 않음을 암시하는 것으로 받아들입니다. 저희의 권고는 \u0026ldquo;앞서 감사드립니다\u0026quot;를 먼저 밝히면서 뿐만 아니라, 예를 들자면, \u0026ldquo;관심 보여주셔서 감사드립니다\u0026quot;라든지 \u0026ldquo;해결해주셔서 감사합니다\u0026quot;와 같이 다른 방법으로도 감사함을 표하는 것입니다.)\n해결책에 대한 간단한 노트를 남길 것 문제가 해결되고 난 뒤에는 도움을 준 사람들에게 노트를 남기세요; 어떻게 진행되었고 그들의 도움에 감사하다는 점을 다시금 상기시켜 주시기 바랍니다. 메일링 리스트나 뉴스 그룹에서 다수의 관심을 받은 문제였다면, 결과 보고성 포스트를 그 곳에 남기는 것이 적절합니다.\n이상적인 모습은 원래의 질문을 시작했던 포스트에 답변으로써, \u0026lsquo;고침(FIXED)\u0026lsquo;나 \u0026lsquo;해결함(RESOLVED)\u0026rsquo; 또는, 비슷한 수준으로 명확한 태그를 제목에 붙이는 것입니다. 굉장히 답신이 많은 메일링 리스트에서는, \u0026ldquo;문제 X\u0026quot;로 시작해서 \u0026ldquo;문제 X-해결됨\u0026quot;으로 끝나는 쓰레드는 보자마자 (본인 스스로가 문제 X에 관심이 있는 경우를 제외하고서는) 시간을 낭비할 필요가 없음을 알 수 있어서, 그 시간을 다른 문제 해결에 사용할 수 있게 됩니다.\n결과 보고성 포스트는 길고 복잡할 필요가 없습니다; 단순히 \u0026ldquo;잘 지내셨나요 - 그냥 네트워크 선 고장이었어요! 고마워요, 다들! - 빌\u0026rdquo; 정도면 없는 것보다는 낫습니다. 사실, 실제로 기술적으로 의미 있는 경우를 제외하고서는 긴 논문 같은 답변보다 짧고 달달한 요약이 더 좋습니다. 문제 해결 과정을 다시 되풀이 나열할 필요 없이 어떤 방법으로 해결할 수 있었는지만 밝히세요.\n꽤 깊이 있는 문제의 경우에는 문제 해결 기록의 요약을 남기는 것이 적합합니다. 마지막 문제점을 명시하세요. 어떤 방법이 해결책이었는지 서술하고 그 이후에 해서는 안되는 사항을 명시하기 바랍니다. 결과 보고성 포스트를 수사물로 만들지 않기 위해, 해서는 안되는 행동인 막다른 행동에 대한 글은 올바른 해결책 부분과 다른 요약 부분 뒤에 배치하기 바랍니다. 도움을 준 이들의 이름을 밝히세요; 그렇게 서로 친구가 될 수 있습니다.\n감사 표시와 정보 제공 측면을 제외하고서도, 이런 종류의 결과 보고성 포스트는 메일링 리스트/뉴스그룹/포럼에서 해당 문제를 검색하는 다른 사람들이 정확히 어떤 해결책으로 도움을 받았는지 정확히 파악할 수 있게 함으로써 그들에게도 도움이 됩니다.\n마지막으로 중요한 점은, 이런 결과 보고성 포스트는 문제 해결을 도왔던 사람들 모두에게 문제가 잘 마감되는 만족스러운 기분을 느끼게 해줍니다. 만약 당신 스스로가 기술자나 해커가 아니라면, 이런 기분이 당신이 도움을 위해 노크당한 전문가나 고수들에게 매우 중요하다는 우리 말을 믿으세요. 문제가 해결되지 않고 허무하게 남아있는 흔적을 바라보는 것은 실망스러운 일입니다; 해커들은 그게 해결되는 모습을 보고싶어 몸이 간질거립니다. 그 간지러움을 긁어주는 선의는 다음에 혹시 질문을 할 필요가 있을 때 해커들이 성심성의껏 도와주리라는 것을 의미합니다.\n미래에 같은 질문을 다른 사람들이 하는 것을 예방하기 위해 무엇을 할 수 있는지도 고려하십시오. 문서나 FAQ에 패치하는 것이 도움이 될지 자문해보고, 도움이 될 것으로 보인다면 관리자에게 패치를 발송하기 바랍니다.\n해커들 사이엔 이런 결과 보고성 포스팅이 통상적인 정중함보다 더 중요한 행동으로 여겨집니다. 이는 매우 귀중한 자산이라고 할 수 있는 타인과 잘 지내는 사람이라는 명성을 얻게 해줍니다.\n답변 해석하는 방법 RTFM과 STFW: 제대로 말아먹었음을 구분하는 방법 아주 오래 전부터 내려오는 전통이 있습니다; 답변에 \u0026ldquo;RTFM\u0026quot;이라고 적혀있다면, 답변한 사람은 당신이 \u0026lsquo;X발 매뉴얼 좀 읽어(\u0026lsquo;Read The Fucking Manual\u0026rsquo;)라고 생각하는 것입니다. 답변자가 분명히 맞습니다. 가서 읽고 오세요.\nRTFM은 어린 사촌이 있습니다. 답변에 \u0026ldquo;STFW\u0026quot;이라고 적혀있다면, 답변한 사람은 당신이 \u0026lsquo;X발 인터넷 검색 좀 해봐라(\u0026lsquo;Search The Fucking Web\u0026rsquo;)고 생각하는 것입니다. 답변자가 분명히 맞습니다. 가서 검색하고 오세요. (이것의 부드러운 버전은 \u0026ldquo;구글은 친구야!(Google is your friend!\u0026quot;)입니다.)\n웹 포럼의 경우에는 포럼 보관소를 검색하라는 말을 들을 수도 있습니다. 사실, 몇몇 사람은 기존에 같은 문제가 해결된 쓰레드의 링크를 제공할만큼 친절할지도 모릅니다. 하지만 이런 배려에 의존하지 마십시오; 묻기 전에 스스로 보관소-검색을 하시기 바랍니다.\n꽤 자주, 매뉴얼 읽으라고 하거나 인터넷 검색하라고 답변하는 그 사람들이 해당 답변을 입력하면서 당신이 필요로 하는 정보가 담긴 해당 매뉴얼이나 웹페이지를 열어둔 경우가 많습니다. 이런 답변은 따라서 (a) 당신이 필요로 하는 정보가 너무 찾기 쉽거나, (b) 이 정보를 떠 먹이기 보다는, 스스로 찾는 과정에서 당신이 더 배울게 많다는 점을 의미합니다.\n이런 점에 상처 받지 마십시오; 해커들 기준에서는 당신의 응답자는 최소한 무시하지 않은 만큼, 나름대로의 존중을 보인 것입니다.당신은 오히려 이런 할머니 스타일의 친절함에 감사함을 느껴야 합니다.\n이해가 안되면 답변이 이해가 안된다고 곧바로 더 명확히 알려달라고 요구하지 마십시오. 평소에 시도하던 동일한 방법들을 통하여 원래의 질문에 (매뉴얼, FAQ, 인터넷, 숙련된 친구 등) 답변을 이해하기 위해 스스로 답해보시기 바랍니다. 그리고 나서도 더 명확해야 할 필요가 있다면 그 과정에서 추가로 배운 것을 보여주시기 바랍니다.\n예를 들어, 이렇게 말해주었다고 합시다: \u0026ldquo;젠트리에서 막힌 것 같은데; 뚫어봐\u0026rdquo;. 그리고, 이것이 나쁜 추가 질문입니다: \u0026ldquo;젠트리가 뭐임?\u0026rdquo;. 다음은 앞의 것 보다는좋은 추가 질문입니다: \u0026ldquo;ㅇㅋ, 매뉴얼 패이지 읽어봤는데 젠트리는 -z랑 -p 스위치 관해서만 언급되고 있어. 어디에도 젠투리 뚫는것 관련해서는 얘기가 없는데. 쟤네 중에 하나 말한거임 아님 내가 뭔가 빼먹은거임?\u0026rdquo;.\n무례함 다루기 해커 문화에서 무례한 것으로 보여지는 것들은 상처 주기 위한 의도가 아닙니다. 그보다는, 상대를 따듯하게 만드는 것보다 문제 해결에 더 관심이 있는 사람들에겐 자연스러운, 직접적이고, 헛소리는 집어치우는(cut-through-the-bullshit) 대화 방식에 의한 부산물입니다.\n무례한 대응을 받으면, 침착하게 반응하려고 애쓰세요. 만약 누가 정말로 과하게 행동하면, 해당 리스트 뉴스 그룹에서 고위급의 사람이 그/그녀를 나무랄 것입니다. 만약 그런 일이 벌어지지 않고, 당신이 화를 낸다면, 당신이 화내고 있는 대상이 해커 커뮤니티의 규범에 맞게 행동한 것이고 당신이 틀렸다고 판단될 것입니다. 이는 당신이 원하는 도움을 받을 기회에 악영향을 미칩니다.\n반면에, 가끔은 무례함을 마주하여 신경 쓰지 않는 태도를 보일 수도 있습니다. 이 태도의 장점은, 실제 범죄자를 강하게 반격하고 날카로운 도구로 그들의 틀린 행동을 해부해버릴 수 있다는 점입니다. 그러나, 이런 자세를 취하기 전에 본인 입장을 아주 아주 명확히 인지하기 바랍니다. 무례함을 바로잡는 것과 의미 없는 불꽃 전쟁 사이의 선은 매우 얇고 해커들은 그 선을 자주 넘지 않는 편입니다; 만약 당신이 초보자이며 외부인이라면, 그 선 넘은 수준을 알아차리기란 쉽지 않습니다. 당신이 흥미거리가 아니라 정보를 쫓는 거라면, 이런 위험을 감수하기보다는 차라리 키보드에서 손가락을 떼는 것이 좋습니다.\n(일부 사람들은 다수의 해커들이 약한 수준의 자폐 혹은 아스퍼거 증후군을 겪고 있어서 \u0026ldquo;정상적인\u0026rdquo; 사람들의 사회적 교류의 뇌 일부가 정상 작동하지 않는 것 같다고 주장합니다. 이는 사실일수도, 아닐 수도 있습니다. 만약 당신이 스스로 해커가 아니라면, 우리의 태도를 뇌 다친 환자의 행위로 여기면 좀 편할지도 모릅니다. 그렇게 하세요. 우린 관심 없습니다; 우린 우리답기를 좋아하고, 의학적 라벨링에는 일반적으로 건강한 비판을 가지고 있습니다.)\n눈치 필터에 관한 제프 비글러(Jeff Bigler)의 관찰도 관련 있을 뿐더러 읽어볼 가치가 있습니다.\n다음 섹션에서는 다른 이슈에 대해 말하고자 합니다; 당신이 잘못 행동 했을 때 겪게 될 다양한 \u0026ldquo;무례함\u0026quot;에 관해서 다루겠습니다.\n루저처럼 반응하지 않기에 대하여 여기서 상세히 밝힐 방법, 혹은 유사한 방법으로 - 당신이 몇 번이고 해커 커뮤니티 포럼에서 말아먹을 확률이 높습니다. 그리고 아주 다양한 방법으로 어떻게 말아먹었는지 전해듣겠죠. 공개적으로요.\n이런 일을 겪고 당신이 취할 최악의 대처는 해당 경험에 대해 징징거리거나, 모욕을 당했다고 주장하거나, 사과를 요구하거나, 소리지르거나, 숨을 참거나, 고소할거라고 위협하거나, 다른 고용인에게 불평을 하거나, 변기 커버를 올려놓은 채 떠나거나, 등등입니다. 자 당신이 할일을 보여드리죠:\n그냥 넘어가요. 정상입니다. 사실, 건강하고 적절한 겁니다.\n커뮤니티의 기준은 기준 스스로 관리되는 것이 아닙니다: 기준은 공개적으로, 그리고 가시 범위에서 그 기준을 능동적으로 적용하는 사람들에 의해 관리됩니다. 모든 비난은 사적인 이메일로 이루어져야만 한다고 징징대지 마세요: 이제 그런식으로 하지 않습니다. 당신의 주장이 틀렸다거나 누군가가 당신과 다르게 생각한다는 댓글을 달았다고 개인적으로 모욕을 당했다고 주장하는 것도 도움이 되지 않습니다. 그게 바로 루저의 태도예요.\n초-긍정적이고, 타인의 포스트에서 실수를 지적하는 포스팅은 금지되며 \u0026ldquo;돕지 않을거면 아무말도 하지 마라\u0026quot;를 권장하는 포럼이 있었습니다. 이것은 실제로 도움을 줄 수 있는 참여자들이 다른 곳으로 떠나는 결과를 낳았고 의미 없는 다독임만 남게 되어 결국 기술 포럼으로써 무용지물이 되었죠.\n(그런 의미의) 과장된 \u0026ldquo;친근함\u0026rdquo;, 혹은 \u0026ldquo;유용함\u0026rdquo;: 하나만 고르세요.\n기억하기 바랍니다: 해커가 당신이 말아 먹었다고 말하고 (얼마나 무뚝뚝 했든지간에) 그러지 말라고 하면, (1) 당신과 (2) 커뮤니티를 위한 걱정에서 하는 말입니다. 해당 답변자한테도 마찬가지로 무시하고 본인의 삶을 위해 당신을 필터링하는 편이 훨씬 쉬운 방법입니다. 그런 면에서 감사할 줄도 모르면, 최소한의 존엄이라도 가지고 징징대지 마세요. 그리고 무슨 자격이 있는 마냥 망상에 빠진, 과장된 초예민 영혼을 가진, 신입이라는 이유로 부서지기 쉬운 인형처럼 대해 주기를 기대하지 마십시오.\n간혹 사람들은 당신이 말아먹지 않았음에도 (혹은 그들의 상상 속에서나 말아먹었는데도) 별다른 이유도 없이 불타오르거나 개인적으로 공격하는 일이 있습니다. 이 경우에는, 불평하는 것이 실제로 말아 먹는 방법입니다.\n이런 분탕종자들은 실제로는 해결법도 없으면서 전문가인체하는 사람들이거나 당신이 말아먹는지 아닌지 실험하는 심리학자들일 겁니다. 다른 독자들은 그런 사람들을 무시하거나, 혹은 알아서 그런 사람들을 다루는 법을 찾을 겁니다. 분탕종자는 스스로를 향한 문제나 만들 뿐이지, 당신이 걱정할 필요는 없습니다.\n함께 불꽃 전쟁에 휘말리지 않도록 주의하세요. 대부분의 불꽃 전쟁은 무시하는 게 최선입니다 - 다만, 진짜 불꽃 전쟁인지, 말아 먹은 이유에 대한 링크는 아닌지, 혹은 (간혹 실제로 일어나지만) 아주 교묘하게 숨겨진 당신 질문에 대한 진정한 답변인지를 확인하고 나서요.\n묻지 말아야 하는 질문 여기 고전적인 멍청한 질문들과 해커들이 무시할 때 속으로 생각하는 것을 소개합니다.\nQ: X 프로그램 혹은 X 자료는 어디에서 구할 수 있나요?\nA: 내가 찾은 데랑 같은데서, 임마 - 검색! 하나님, 아직도 사람들은 구글 사용법을 모르나요?\nQ: Y하려면 X 어떻게 써야 하나요?\nA: Y를 하고 싶은 거라면, 부적절할지도 모르는 방법을 미리 전제하고 물어서는 안됨. 이런 형태의 질문들은 보통 프로그램 X에 대해 완전히 무지하거나, 풀고자 하는 Y 문제에 대해 혼란스러운 경우, 그리고 특정 상황의 세부 사항에 너무 집중한 경우에 일어남. 본인 문제를 더 명확하게 설명하기 전까진 그냥 무시하는 게 최선임.\nQ: 쉘 프롬프트는 어떻게 설정하나요?\nA: 이 질문 올릴 수 있는 지능이면 RTFM 하고 직접 찾을 듯.\nQ: AcmeCorp 문서를 Bass-o-matic 파일 변환기를 활용해 TeX 파일로 변환할 수 있나요?\nA: 해보세요. 되면, (a) 답을 찾은거고, (b) 내 시간낭비좀 그만하세요.\nQ: 내 {프로그램, 설정, SQL 명령어} 가 작동을 안함.\nA: 이건 질문도 아니고, 해야 할 더 중요한 일들이 있어서 - 실제 질문을 찾기 위한 스무고개 하고 싶지도 않음. 이런 걸 목격하면, 내 반응은 보통 다음 중 하나임: 더 추가할 건 없음? 아 안됐네, 빨리 고쳐지길 빌게. 그리고 이게 나랑 정확히 무슨 상관임?\nQ: 제 윈도우 PC에 이상이 있어요. 도와주실 수 있나요?\nA: 넹. 마이크로소프트는 갖다 버리고 Linux나 BSD같은 오픈 소스 운영체제를 설치하세요. 주의: 공식적으로 윈도우 빌드를 지원하는 프로그램이나 윈도우 PC와 상호작용 해야하는 (예를 들어, Samba처럼) 프로그램에 대한 질문이라면 물어볼 수는 있습니다. 다만 문제가 프로그램이 아니라 윈도우라는 답변에 놀라지 마십시오. 윈도우는 고장나기 매우 쉽고 대부분의 경우에 고장난게 이유이기 때문입니다.\nQ: 제 프로그램이 작동하지 않아요. 제 생각엔 시스템 기능 중 X가 고장난 것 같아요.\nA: 수백 수천명이 사용하는 시스템의 라이브러리나 시스템 콜의 확실한 결점을 발견한 첫 번째 사람이 당신일 가능성이 분명 존재하긴 하지만, 차라리 무슨 소리 하고 있는지 모를 확률이 더 높습니다. 대단한 주장에는 대단한 증거를 필요로 합니다; 이런 주장을 할 거라면, 분명하고 확실히 명시된 실패 케이스를 근거로 제시해야만 할 것입니다.\nQ: Linux 혹은 X를 설치하는데 문제가 있어요. 도와주실 수 있나요?\nA: 아니요. 그거 해결하려면 기기에 직접 접속할 수 있어야 합니다. 지역 리눅스 사용자 모임에 가서 직접적인 도움을 요청하기 바랍니다. (여기에서 사용자 모임 리스트를 확인할 수 있습니다. [역자 주: 현재 접속 불가]) 주의: 리눅스 설치에 관한 질문은 해당 배포판 메일링 리스트나 포럼, 혹은 지역 사용자 모임 포럼에선 적절할지도 모릅니다. 그리고 문제는 해당 배포판입니다; 이러한 경우, 문제의 정확한 상세 정보를 서술하고 있는지 명확히 하기 바랍니다. 다만, 질문에 앞서서 \u0026ldquo;리눅스\u0026quot;와 모든 의심스러운 하드웨어를 포함하는 검색을 하기 바랍니다.\nQ: 관리자 계정/채널 관리자 권한 훔치기/타인 이메일 훔쳐일기는 어떻게 하나요?\nA: 그런 짓을 하고싶을만큼 후진 삶을 살고 해커들한테 그런거 도와달라고 할만큼 멍청한 사람\n좋은 질문과 나쁜 질문 마지막으로, 예시를 통해 현명한 질문을 하는 방법을 보여드리겠습니다; 같은 문제에 대한 멍청한 방법 하나와 똑똑한 방법 하나로 구성되어 있습니다.\n멍청함: Foonly Flurbamatic 제품은 어디서 찾을 수 있나요? 이 질문은 답신으로 \u0026ldquo;STFW\u0026rdquo;만이 달릴 것입니다.\n현명함: \u0026ldquo;Foonly Flurbamatic 2600\u0026rdquo; 검색을 구글을 활용해 시도했는데, 유용한 결과가 없습니다. 이 기기에 대한 프로그래밍 정보를 얻기 위한 링크를 구할 수 있을까요? 이 질문은 이미 인터넷 검색을 해보았고 진짜 문제가 있는 것처럼 들립니다.\n멍청함: foo 프로젝트의 코드가 컴파일되지 않습니다. 왜 고장났나요? 의뢰인은 타인이 말아 먹었음을 전제로 하고 있습니다. 거만한 놈\u0026hellip;\n현명함: Nulix version 6.2에서 foo 프로젝트 코드가 컴파일되지 않습니다. FAQ를 확인했지만, Nulix 시스템 관련된 문제는 보고되어 있지 않습니다. 아래는 컴파일 시도 관련된 로그입니다; 제가 잘못한 부분이 어디일까요? 이 의뢰인은 작업 환경 명시, FAQ 확인, 에러 명시, 자신의 잘못으로 전제를 모두 만족합니다. 이 질문은 주목을 받을 가치가 있어보입니다.\n멍청함: 제 메인보드에 문제가 있습니다. 아무나 도와주실 수 있나요? 김 아무개씨가 받을 것으로 예상되는 답변은 \u0026ldquo;좋아. 혹시 트림이랑 기저귀 교체도 도와줄까?\u0026ldquo;이며 뒤이어 딜리트 키 연타가 이어집니다.\n현명함: S2464 메인보드에서 이미 X, Y 그리고 Z까지 시도했습니다. 그래도 안되서, A, B 그리고 C도 시도하였습니다. C를 시도했을 때 발생한 흥미로운 증상도 참고해주세요. 분명히 일부 부품이 깜빡이지만, 결과는 예상과 다릅니다. 애슬론 MP 메인보드의 깜빡임 증상의 일반적인 원인은 무엇인가요? 문제 해결을 위해 시도해볼 다양한 테스트 아이디어를 아무나 제공해주실 수 있나요? 반면에, 이 사람은답변할 가치가 있어 보입니다. 그/그녀는 답변이 하늘로부터 떨어지기를 수동적으로 기다리는 것이 아니라, 문제-해결 지식을 보였습니다.\n마지막 질문과 관련해서, \u0026ldquo;답변을 주세요\u0026quot;의 요구와 \u0026ldquo;번뜩이는 해답을 얻기 위해 필요한 추가적인 진단 방법을 찾게 도와주세요\u0026rdquo; 사이의 미묘하지만 주요한 차이를 알차리시길 바랍니다.\n사실, 마지막 질문의 형태는 2001년 8월 리눅스-커널 메일링 리스트(lkml)에서 있었던 사건을 거의 그대로 반영합니다. 나(에릭)은 질문했던 당사자입니다. 나는 S2462 메인보드에서 미스테리한 락업을 목격했습니다. 리스트 멤버들은 그 문제를 해결하기 위해 필요한 주요한 정보를 제공하였습니다.\n보여드린 방식으로 질문을 함으로써, 사람들에게 생각할거리를 제공하였습니다; 관심 갖고 참여하기에 매력적이고 쉬워 보이게 만든 것이죠. 동료들의 능력을 존경함을 보이고 동료로써 문제 해결 상담에 초대하였습니다. 이미 시도하였으나 막다른 골목이었던 항목을 말해줌으로써 그들의 시간의 가치를 존중한다는 점도 추가로 드러냈습니다.\n결국, 모두에게 감사함을 표하고 문제가 얼마나 잘 해결되었는지 표현하자, 한 lkml 멤버는 해당 문제가 리스트의 \u0026ldquo;유명인\u0026quot;이 질문했기 때문이 아니라, 해당 질문을 구성한 양식이 좋았기 때문에 도움을 받은 것으로 생각했습니다.\n해커들은 어떤 면에선 자비 없이 능력주의입니다; 그가 맞았음을 확신합니다. 만약 제가 스폰지처럼 행동했다면 제가 누구인지와 관계없이 무시 당하거나 질문이 불타올랐을 겁니다. 이 일련의 사건을 다른 사람들을 위한 설명으로써 작성하는 것이 어떠냐하는 그의 제안에 이 가이드가 구성되었습니다.\n답을 구할 수 없다면 답을 구할 수 없다면, 우리가 당신을 돕지 않는다고 감정적으로 받아들이지 마십시오. 가끔은 질문 받은 그룹의 멤버들이 답을 모를 때도 있습니다. 무반응이 무시당하는 것과 동일하지 않습니다. 물론 외부에서 보기에 그 차이를 구분하기는 어렵지만 말이죠.\n일반적으로, 단순히 질문을 재포스팅하는 것은 안좋은 생각입니다. 이는 의미없이 짜증나는 일로 보입니다. 참을성을 가지세요: 답변을 해줄만한 사람이 다른 시간대에 살고 있어서 취침중일지도 모릅니다. 아니면 애초에 당신의 질문이 잘 구성되어 있지 않을지도 모릅니다.\n도움을 요청할 다른 곳이 있을지도 모릅니다, 간혹 초심자의 필요에 더 잘 맞는 곳이 있을 때가 있습니다.\n세상엔 소프트웨어를 스스로 만들어본적이 없음에도 불구하고, 소프트웨어의 열정적인 팬이 구성하는 온라인이나 지역 사용자 그룹이 많습니다. 이런 그룹은 서로를 돕고 새로운 사용자를 돕는 방향으로 구성되어 있을 때가 많습니다.\n크든 작든 도움을 위해 계약할 수 있는 상업 회사도 상당히 많습니다. 일정 도움을 받기 위해 비용을 지불해야 한다는 생각에 언짢아하지 마십시오. 결국, 자동차 엔진의 헤드 가스켓이 고장나면, 아마도 정비소에 가서 고치기 위한 비용을 지불할 것임을 매한가지입니다. 비록 소프트웨어가 어떤 비용 지출도 유발하지 않았더라도, 지원조차 항상 무료로 제공될거라는 기대는 하지 마십시오.\n리눅스처럼 인기있는 소프트웨어의 경우 개발자당 10,000명의 사용자가 있습니다. 각 개발자가 10,000명의 사용자의 지원 문의를 처리하는 것은 불가능합니다. 지원을 위해 비용을 지불하게되더라도, 소프트웨어까지 구매하기 위해 지출해야 하는 것에 비하면 적은 양이라는 점을 반드시 기억하기 바랍니다. (그리고 비공개 소프트웨어 지원은 오픈 소스 소프트웨어 지원에 비해 불완전하면서도 훨씬 비쌉니다.)\n도움이 되는 방향으로 질문에 답하는 방법 친절하세요. 문제와 관련된 스트레스는 그들이 실제로 아니더라도 사람을 무례하거나 멍청하게 보이게 합니다.\n초범에게의 회신은 오프라인으로. 누군가 솔직한 실수를 했다고 해서 공개적인 망신을 줄 필요는 없습니다. 진정한 초보자는 문서 보관에서 어떻게 검색해야 하는지, 어디에 FAQ가 있는지 모를지도 모릅니다.\n확실하지 않으면, 그렇다고 하십시오! 틀렸으면서 권위주의적으로 들리는 답변은 안하느니만 못합니다. 단지 전문가처럼 보이는게 재미있어서 누군가를 틀린 방향으로 안내하지 마십시오. 겸손하고 솔직하십시오; 요청자와 동료 모두에게 선례를 남기시기 바랍니다.\n돕지 못할거면 방해하지 마십시오. 사용자의 설정을 쓰레기로 만들 수도 있는 농담을 하지 마십시오. - 불쌍한 초보자는 당신의 농담을 지시사항으로 해석할 수도 있습니다.\n더 상세한 정보를 이끌어내기 위해 추가 질문을 하십시오. 이 것을 잘해내면, 질문자는 무언가를 배울 수 있습니다. - 당신도 마찬가지입니다. 안 좋은 질문을 좋은 것으로 바꾸도록 시도해 보십시오; 우리도 한 때는 초보였다는 것을 기억하기 바랍니다.\nRTFM을 외치는 것이 때때로 게으름벵이에게 답변한다는 핑계로 정당화되지만, 문서 링크(심지어 구글에 검색할 키워드 제안이라도)가 훨씬 낫습니다.\n어쨋든 물음에 답할거라면, 좋은 답변을 주십시오. 누군가 안좋은 도구나 접근법을 활용중이라면 대충 해결책을 제안하지 마십시오. 좋은 도구를 제안하세요. 질문을 재구성하기 바랍니다.\n실제 질문에 답하십시오! 질문자가 너무 성실해서 본인이 해야할 검색을 마쳤고, 질문에 X, Y, Z, A, B, C를 모두 시도하였음에도 좋은 결과가 없었다는 점을 밝혔다면, \u0026ldquo;A나 B를 시도해보세요\u0026quot;나 \u0026ldquo;X, Y, Z, A, B 또는 C를 시도해보세요\u0026quot;를 담는 링크를 제공하는 것들은 전혀 도움이 되지 않습니다.\n질문으로부터 커뮤니티가 무언가를 배울 수 있도록 도와주세요. 누군가 좋은 질문을 했다면, \u0026ldquo;관련 문서나 FAQ를 어떻게 수정하면 누구도 이 질문을 다시 할 필요가 없을까?\u0026ldquo;하는 식으로 스스로 질문해보십시오. 그리고 문서 관리자에게 패치를 전송하십시오.\n질문에 대한 답을 하기 위해 검색을 했다면, 당신의 기술을 보여줘야지 답이 엉덩이에서 갑자기 튀어나온 것처럼 답을 작성하지 마십시오. 좋은 질문에 답하는 것은 배고픈 사람에게 한끼를 대접하는 것과 같지만, 예시로 검색 방법을 가르치는 것은 일생동안 식량을 재배하는 방법을 보이는 것과 같습니다.\n관련 자료 PC(personal computer), 유닉스, 인터넷이 어떻게 작동하는지 기본적인 가이드가 필요하다면, 유닉스와 인터넷 기초(The Unix and Internet Fundamentals HOWTO)를 참조하십시오.\n소프트웨어를 출시하거나 소프트웨어를 위한 패치를 작성할 때, 소프트웨어 출시 연습(Software Release Practice HOWTO)을 참조하십시오.\n감사 인사 Evelyn Mitchell은 멍청한 질문들의 일부 예시를 제공하였고 \u0026ldquo;도움이 되는 방향으로 질문에 답하는 방법\u0026rdquo; 섹션을 작성할 동기를 부여하였습니다. Mikhail Ramendik은 개선을 위한 일부 가치 있는 공헌을 하였습니다.\n","permalink":"http://ptrtoj.com/kr/smart-questions/","summary":"\u003cblockquote\u003e\n\u003cp\u003eThis is a translated work. The original post was written by Eric S. Raymond, and you can read it \u003ca href=\"http://www.catb.org/~esr/faqs/smart-questions.html\"\u003ehere\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eAccording to Eric S. Raymond\u0026rsquo;s \u003ca href=\"http://www.catb.org/~esr/copying.html\"\u003ecopying policy\u003c/a\u003e, permission is granted, already.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cblockquote\u003e\n\u003cp\u003e이 문서는 번역본입니다. 원본은 에릭 S. 레이몬드에 의해 작성되었으며, 다음 \u003ca href=\"http://www.catb.org/~esr/faqs/smart-questions.html\"\u003e링크\u003c/a\u003e를 통해 읽을 수 있습니다.\u003c/p\u003e\n\u003cp\u003e에릭 S. 레이몬드의 \u003ca href=\"http://www.catb.org/~esr/copying.html\"\u003e복사 정책\u003c/a\u003e에 의하면, 추가적인 번역 허가 절차는 별도로 필요하지 않습니다.\u003c/p\u003e\n\u003c/blockquote\u003e","title":"현명하게 질문하는 방법"},{"content":" This is translated work. The original post is written by \u0026lsquo;Gabriel Gambetta\u0026rsquo;, the link is here.\nThe translation was permitted on 2020/12/06. This is a combined long HTML version of each series.\n이 문서는 번역본입니다. 원본은 \u0026lsquo;Gabriel Gambetta\u0026rsquo;가 쓴 것으로, 링크를 통해 확인할 수 있습니다.\n번역은 2020/12/06에 허가되었습니다. 이 문서는 각 시리즈를 하나의 HTML 파일로 편집한 것입니다.\n파트 1: 클라이언트-서버 게임 아키텍쳐 소개 이 문서는 빠른 진행 멀티플레이어 게임을 만드는 것을 가능케 할 기술과 알고리즘을 소개하는 연재의 첫 번째 문서입니다. 만약 멀티플레이어 게임을 위한 컨셉들에 익숙하다면, 이 파트는 스킵하셔도 문제가 없을 것입니다. 이어지는 것은 소개를 위한 논의입니다.\n어떤 종류의 게임을 개발하든 그것은 어렵습니다; 그러나, 멀티플레이어 게임은 완전히 새로운 차원의 문제들을 추가로 해결해야 합니다. 흥미롭게도, 핵심 문제들은 인간 본성과 물리학이죠!\n부정 행위(cheating) 문제 부정 행위와 함께 모든 것은 시작됩니다.\n게임 개발자로서 보통 싱글-플레이어 게임에서의 부정 행위는 신경 쓰지 않죠. 그가 취하는 행동이 스스로에게 영향을 줄 뿐이고 타인에게는 영향이 없기 때문입니다. 부정 행위자는 개발자가 설계한대로 게임을 경험하지 않을지 모르지만 부정 행위자 스스로의 게임인만큼 각자 원하는 방식으로 즐길 권리가 있죠.\n하지만, 멀티 플레이어 게임은 다릅니다. 그 어떤 경쟁적 게임에서든, 부정 행위자는 스스로의 경험만을 더 낫게 만드는 것을 넘어서 타인의 경험을 더 나쁘게 만듭니다. 개발자로서, 그런 부정행위가 다른 유저를 떠나게 만들기 때문에 이런 상황을 피하기를 원할 것입니다.\n부정행위를 막기 위한 수많은 방법이 있겠으나, 가장 중요한 방법(그리고 아마도 가장 의미있는 것)은 간단합니다: 플레이어를 신뢰하지 마세요. 항상 최악을 상정하세요 - 플레이어는 부정 행위를 시도할 것이라고 말이죠.\n권한 있는 서버(authoritative servers)와 의존 클라이언트(dumb client) 이것은 어느 정도 간단한 해결책을 제시합니다 - 게임 내 모든 것은 중앙 서버에서 개발자 통제 아래 이루어지도록 만들고 클라이언트는 단지 승인 받은 게임 관찰자로 설계하는 것이죠. 다시 말해서, 게임 클라이언트가 인풋(눌린 키 값, 커맨드)을 서버로 보내고, 서버가 게임을 진행시킨 뒤, 그 결과를 클라이언트에게 재전송합니다. 일반적으로 이것을 권한 있는 서버라고 부릅니다. 왜냐하면 모든 일이 일어나는 것에 대한 단 하나의 권한을 서버가 쥐고 있기 때문이죠.\n물론, 서버가 위험에 노출되어 무용지물이 될 수도 있겠지만 그 부분은 이 글의 범주를 벗어납니다. 그렇지만 권한 있는 서버를 활용하더라도 넓은 범위의 해킹을 예방할 수 있습니다. 예를 들어, 플레이어 체력치에 대해 클라이언트를 신뢰하지 않는다고 봅시다; 해킹된 클라이언트는 해당 값의 로컬 카피를 수정하여 플레이어가 10000%의 체력을 가지고 있다고 할지 모르지만 서버는 오직 10%만 남았음을 알고 있습니다 - 해킹된 클라이언트가 뭐라고 생각하든지 관계없이 플레이어는 공격당할 경우 사망할 것입니다.\n게임 세계에서 플레이어 위치와 관련해서도 당신은 플레이어를 신뢰하지 않습니다. 만약 신뢰한다면 해킹된 클라이언트는 서버에게, 아마도 벽을 뚫고 지나가거나 다른 플레이어보다 빠른 이동 속도를 통해 \u0026ldquo;나는 (10,10)에 있어\u0026ldquo;와 잠시 후 \u0026ldquo;나는 (20,10)에 있어\u0026ldquo;를 전송할 것입니다. 대신에, 서버가 플레이어의 위치 (10,10)을 알고 있다면, 클라이언트는 서버에게 \u0026ldquo;나는 한 칸 우측으로 이동하고 싶어\u0026ldquo;를 전송할 것이고, 서버는 내부 상태를 플레이어 위치 (11,10)으로 업데이트 후 플레이어에게 \u0026ldquo;너는 (11,10)에 있어\u0026ldquo;를 전송할 것입니다:\n요약하자면: 게임 상태는 서버 홀로 관리합니다. 클라이언트는 그들의 행동을 서버에 전송합니다. 서버는 주기적으로 게임 상태를 업데이트하고 새로운 게임 상태를 클라이언트에게 회신합니다. 클라이언트는 그 회신을 단순히 화면에 새로 그려낼 뿐입니다.\n네트워크 처리 의존적 클라이언트 계획은, 예를 들어 전략 게임 혹은 포커와 같이 느린 턴 베이스 게임에서는 무난히 작동합니다. 또한 모든 실용적인 목적 하에서 커뮤니케이션이 즉각적으로 이루어지는 랜 세팅에서도 작동합니다. 하지만 인터넷 등의 네트워크에서 이루어지는 빠른 진행 게임에서는 제대로 작동하지 않습니다.\n물리 얘기를 해봅시다. 당신이 샌프란시스코에 있다고 가정하고 뉴욕의 서버에 연결되었다고 합시다. 대략 4,000km 혹은 2,500 마일 거리입니다(또한 대강 리스본부터 모스코바의 거리이기도 하죠. [역자주: 서울에서 네팔의 히말라야 거리]). 그 무엇도 빛보다 빠를 순 없고, 인터넷상의 바이트 정보도 마찬가지입니다(원론적으로 바이트도 빛의 진동, 케이블의 전자, 전자기장 파동이지만 말이죠). 빛은 대략적으로 초당 300,000km를 이동하므로 4,000km를 이동하려면 13ms가 소요됩니다.\n이는 꽤 빠르다고 느껴질지 모르지만, 굉장히 낙관적인 설정이기도 합니다 - 설정은 데이터가 빛의 속도로 직선 거리를 이동한다고 가정하는 것이지만 실제로는 거의 그렇지 않죠. 실상은 데이터가 라우터와 라우터 사이마다 연속적인 점프(네트워크 용어로는 hops라고 하는)를 거치고 그 점프는 대부분 빛의 속도로 이루어지지 않습니다; 라우터는 잠깐의 딜레이를 수반하는데 이는 패킷을 복사, 검사하고 재전송하는데 소요되죠.\n논의를 위해 클라이언트로부터 서버까지 데이터 전송에 50ms가 소요된다고 합시다. 이것은 최선의 시나리오에 불과합니다 - 만약 뉴욕에 있는데 도쿄 서버에 연결된다면 얼마나 소요될까요? 모종의 이유로 네트워크 혼잡이 발생한다면 어떨까요? 100ms, 200ms 혹은 심지어 500ms의 지연은 생소한 일이 아닙니다.\n우리의 예시로 돌아가서, 클라이언트가 어떤 인풋 (\u0026ldquo;오른쪽 방향키를 눌렀어\u0026rdquo;)를 서버로 전송했다고 합시다. 서버는 이것을 50ms 후에 받게 됩니다. 서버가 이 정보를 즉각적으로 처리하고 업데이트된 상태 전송도 순식간에 처리한다고 합시다. 그럼 클라이언트는 새로운 게임 상태(\u0026ldquo;플레이어는 현재 (1,0)에 있음\u0026rdquo;)을 50ms 후에 받게 되는 것이죠.\n플레이어 관점에서, 오른쪽 방향키를 누르고도 1/10초 동안 아무일이 없다면 무슨 일이 벌어질까요?; 그리고 나서 갑자기 한 칸 우측으로 캐릭터가 이동합니다. 이런 인풋과 결과값 사이의 인지된 랙(lag)은 대단한 것으로 여겨지지 않을지 모르지만 주목할만합니다. - 그리고 물론, 이 랙이 0.5초 수준이 된다면 주목할만한 수준을 넘어서 게임을 플레이할 수 없을 지경에 이르게 됩니다.\n요약 네트워크로 이루어지는 멀티플레이어 게임은 큰 재미를 주지만 완전히 새로운 수준의 도전 과제들을 안겨 주었습니다. 권한 있는 서버 아키텍쳐는 대부분의 부정 행위를 멈추는데 꽤 도움이 되지만 있는 그대로 실현하게될 경우 플레이어들에게 반응성이 떨어지는 게임을 만들 수 있습니다.\n이어지는 내용에서 로컬이나 싱글 플레이 게임과 구분이 불가능할 수준까지 플레이어가 경험하는 지연을 최소화하는 시스템을 어떻게 권한 있는 서버 모델을 통해 구현할 수 있을지 살펴보겠습니다.\n파트 2: 클라이언트 측 예측과 서버 측 조정 소개 파트 1 에서, 권한 있는 서버와 단지 인풋을 서버에 전달하고 회신받은 업데이트된 게임 상태를 그려낼 뿐인 의존 클라이언트 모델을 살펴보았습니다.\n이 모델을 순진하게 있는 그대로 도입할 경우 유저 커맨드와 화면상 변화 사이에 지연이 생깁니다; 예를 들어, 플레이어가 오른쪽 방향키를 누를 경우, 캐릭터가 움직이기 시작하기까지 0.5초가 소요되는 등 말이죠. 이것은 클라이언트가 인풋을 반드시 서버로 먼저 전송시키고, 서버는 인풋을 전달받아 새로운 게임 상태를 업데이트한 후, 그 업데이트된 상태가 클리이언트에 재전달되어야만 하기 때문에 발생합니다.\n인터넷과 같은 네트워크 환경에서는 지연이 1/10초 수준에서 생겨날 수 있고, 이는 최선의 경우 게임의 반응성이 떨어지는 것처럼 느껴지고, 최악의 경우는 플레이하지 못하는 수준이 될 수도 있습니다. 이번 파트에서는 해당 문제를 최소화하거나 심지어 제거할 수 있는 방법을 찾아보겠습니다.\n클라이언트 측 예측 일부 부정 행위 플레이어가 존재하긴 하지만 대부분의 경우 게임 서버는 유효한 요청을 처리합니다 (비 부정행위 클라이언트로부터의 요청이나 혹은 그 시점에는 부정 행위를 하고 있지 않은 부정 행위 클라이언트의 요청). 이는 대부분의 요청받은 인풋값은 유효하고 게임 상태도 예상되는대로 업데이트될 것임을 의미합니다; 캐릭터가 (10,10)에 있고 오른쪽 방향키가 입력된 경우, 결국에는 (11,10)으로 이동하게 될 겁니다.\n이것을 우리에게 유리하게 사용할 수 있습니다. 게임 세계가 충분히 결정론적(deterministic)이라면 말이죠(말하자면, 현재의 게임 상태와 입력이 가능한 모든 인풋 집합이 주어진 경우, 그 결과가 완벽히 예측가능한 상태입니다).\n우리가 100ms의 랙을 가지고 있고 현재 칸에서 다음 칸으로의 캐릭터 이동 애니메이션이 100ms 걸린다고 합시다. 있는 그대로 설계할 경우, 모든 움직이에는 총 200ms가 소요됩니다:\n게임 세계가 결정론적이라 가정했기 때문에, 서버로 전송한 인풋이 성공적으로 실행될 것임을 예상할 수 있습니다. 이 예측 하에서, 클라이언트는 인풋 처리 후 업데이트될 게임 상태를 미리 예측할 수 있고 대부분의 경우 이는 들어맞습니다.\n인풋을 전송하고 결과를 그려내기 전에 업데이트된 새로운 게임 상태를 기다리기보다, 인풋을 전송함과 동시에, \u0026ldquo;참\u0026quot;인 게임 상태 결과를 서버로부터 회신받기 전까지, 참일 경우에 해당하는 결과값을 그려낼 수 있습니다. 그리고 대부분의 경우에는 그 예측값이 참일 뿐 아니라, 내부에서 게산한 게임 상태와 동일하겠죠.\n이를 통해 서버는 여전히 권한 있는 서버이면서도 플레이어와 액션과 화면의 결과값 사이에 지연율을 완벽히 제거해낼 수 있습니다. (만일 해킹된 클라이언트가 무효한 인풋을 전송하더라도, 그 클라이언트가 원하는대로 화면은 그려질지 모르나, 서버의 게임 상태에서는 효과가 없으므로, 무효한 상태로 다른 플레이어에게 보여집니다.)\n동기화 문제 위의 예시에서, 저는 모든 것이 작동함에 문제가 없도록 수치를 섬세하게 선택했습니다. 그러나, 약간 수정된 상황을 고려하죠: 서버로 250ms의 랙이 존재하고, 칸 이동에 100ms이 소요된다고 합시다. 여기에 더해, 플레이어가 오른쪽 방향키를 2번 연속으로 눌러, 우측 칸으로 2칸 이동을 시도한다고 합시다.\n지금까지의 기술을 사용하면, 아래와 같은 일이 발생합니다:\n새로운 게임 상태가 회신될 때, t = 250ms인 경우에는 아주 흥미로운 문제를 마주합니다. 클라이언트의 예측 상태는 x = 12인데 반해, 서버는 새로운 게임 상태가 x = 11라고 하죠. 서버에게 권한이 있기 때문에, 클라이언트는 캐릭터를 한 칸 좌측인 x = 11로 되돌려야 합니다. 그러나 그 때, 새로운 서버 상태가 t = 350에 회신되고, x = 12라고 주장합니다. 따라서 캐릭터는 다시 이동을 하고, 이번에는 우측으로 되돌아갑니다.\n플레이어 입장에서 보면, 오른쪽 방향키를 두 번 눌렀더니; 캐릭터가 우측으로 [정상적으로] 두 칸 움직이고, 50ms 동안 머물렀다가, 한 칸 좌측으로 이동하더니, 100ms 머무르고, 다시 우측으로 한 칸 움직입니다. 당연히 이건 받아들일 수 없습니다.\n서버 측 조정 이 문제를 해결하는 열쇠는 클라이언트가 현재 시점을 바라보고 있으나 랙으로 인해 서버로부터 회신되는 게임 상태는 사실상 과거의 상태라는 점을 깨닫는데 있습니다. 서버가 업데이트된 게임 상태를 회신할 때는 클라이언트로부터 전송된 모든 커맨드를 처리한 것은 아니라는 것이죠.\n하지만, 이 문제를 해결하는 것은 엄청 난해하지는 않습니다. 먼저, 클라이언트는 각각의 요청에 연속 숫자를 부여합니다; 예를 들어, 첫 키 입력에는 요청 #1을 부여하고 두 번째 키 입력은 요청 #2를 부여합니다. 그러면, 서버가 회신할 때, 마지막으로 처리된 인풋의 요청 번호를 포함할 수 있습니다.\n이제, t = 250에, 서버는 \u0026ldquo;요청 #1에 따라, 위치는 x =11이다\u0026ldquo;라고 할 수 있게 됩니다. 서버에게 권한이 있기 때문에, 캐릭터 위치를 x = 11로 설정합니다. 자, 클라이언트가 서버로 전송한 요청의 복사본들을 가지고 있다고 해보죠. 새로 회신된 게임 상태에 따르면, 클라이언트는 서버가 요청 #1을 이미 처리한 것임을 알 수 있으므로 해당하는 복사본은 삭제할 수 있습니다. 하지만 클라이언트는 서버가 요청 #2의 처리값을 회신해야함도 알 수 있게 됩니다. 따라서 클라이언트 측 예측 모델을 다시 적용하면, 클라이언트는 권한 있는 서버가 마지막으로 회신한 게임 상태에 기반하고, 추가로 아직 서버가 처리해주지 않은 인풋을 고려하여 \u0026ldquo;현재\u0026rdquo; 게임의 상태를 계산할 수 있습니다.\n그러므로, t = 250에, 클라이언트는 \u0026ldquo;마지막 처리된 요청 = #1, 현재 위치 x = 11\u0026ldquo;를 얻게 됩니다. 클라이언트는 전송된 입력값 요청 #1까지의 복사본을 삭제하지만 #2의 복사본은 유지합니다. 이는 서버로부터 아직 승인되지 않았기 때문입니다. 클라이언트는 서버 회신 게임 상태인 x = 11로 업데이트한 후 서버로부터 아직 회신되지 않은 모든 인풋을 적용합니다 - 이 경우는, 인풋 #2이고 \u0026ldquo;오른쪽으로 이동\u0026quot;입니다. 따라서, 결과값은 x = 12이며 맞는 결과값이기도 합니다.\n우리의 예시를 계속 살펴보면, t = 350이 되서야 서버로부터 새로운 게임 상태가 회신됩니다. 이번에는 \u0026ldquo;마지막 처리된 요청 = #2, 현재 위치 x = 12\u0026ldquo;가 회신되죠. 이 시점에, 클라이언트는 #2까지의 모든 인풋 복사본을 삭제하고 게임 상태는 x = 12로 업데이트합니다. 더 이상 미처리된 인풋이 없음을 확인하고, 올바른 결과값과 함께 처리는 종료됩니다.\n사소한 세부사항 논의한 예시들은 이동 상황을 예로 들지만 동일한 원칙은 다른 대부분의 경우에도 적용될 수 있습니다. 예를 들어, 턴 베이스 전투 게임에서는 플레이어가 다른 캐릭터를 공격하는 경우에 적용되는 데미지값을 보이는 수치와 체력치를 보일 수 있으나 서버가 허락하기 전까지 캐릭터의 체력 상황을 실제로 업데이트해서는 안 될 것입니다.\n항상 쉽게 되돌릴 수는 없다는 게임 상황의 복잡도 때문에, 아무리 클라이언트 게임 상태에서 체력 수치가 0 이하로 내려간 캐릭터라도 서버가 허락하기 전까지는 해당 캐릭터를 죽이는 것을 피하고자 할 것입니다(만일 공격 당한 캐릭터가 마지막 일격을 당하기 전에 응급상자 아이템을 사용했으나 서버가 아직 공격자 클라이언트에 해당 상태를 전하지 않았다면 어떤 일이 발생할까요?).\n이 것은 흥미로운 점을 시사합니다 - 아무리 게임 세계가 결정론적이고 그 어떤 클라이언트도 부정 행위를 하지 않는다고 가정하더라도 클라이언트 예측 상태와 서버가 회신한 상태가 조정 후에도 일치하지 않을 가능성이 존재한다는 점입니다. 이 경우는 이전에 언급한 것처럼 싱글 플레이어인 경우 불가능하지만, 서버에 한번에 다수가 접속하는 게임의 경우 발생하기 쉽습니다. 이 문제가 다음 파트의 주제입니다.\n요약 권한 있는 서버 모델을 사용하는 경우 사용자에게 반응성이 있는 것과 같은 착각을 제공해야 합니다. 실제로는 서버가 실제로 인풋을 처리한 결과값을 기다리는 중이더라도 말이죠. 이를 위해서, 클라이언트는 인풋 결과값을 예측해야 합니다. 업데이트된 서버 상태가 도착하면 클라이언트는 서버가 업데이트해준 상태와 아직 승인되지 않은 요청등을 모두 고려하여 상태를 재산출해야 합니다.\n파트 3: 객체 삽입(entity interpolation) 소개 앞선 파트들에서 권한 있는 서버 개념과 부정 행위 방지를 위한 유용성을 보였습니다. 그러나, 이를 있는 그대로 구현하는 경우 플레이성과 반응성 측면에서 사용이 불가능한 수준의 버그를 만들어낼 수 있습니다. 파트 2 에서는 클라이언트 측 예측을 이러한 한계 보완을 위한 방법으로써 제시하였습니다.\n이 두 파트의 결과는 전송 지연이 있는 인터넷 연결 하에서도 권한 있는 서버를 활용해 마치 싱글 플레이어 게임을 하는 것과 동일한 느낌을 받을 수 있는 캐릭터 움직임 통제를 가능케 할 개념과 기술이었습니다.\n이번 파트에서는, 동일 서버에 다른 플레이어의 통제를 받는 캐릭터가 있는 경우의 결과를 살펴보고자 합니다.\n서버 시간 단계(server time step) 이전 파트들에서 서버들의 행동은 상당히 단순했습니다 - 클라이언트 인풋을 읽고 게임 상태를 업데이트 하고 클라이언트에게 회신하였죠. 그러나 하나 이상의 클라이언트가 연결되는 경우, 메인 서버 루프는 다소 달라집니다.\n이 경우, 다수의 클라이언트는 인풋을 동시에 그리고 매우 빠른 속도로 전송할지도 모릅니다(플레이어가 커맨드를 입력하는 속도 또는 방향키 입력이나 마우스 이동, 화면 클릭 속도 수준을 말합니다). 각각의 클라이언트로부터 인풋이 입력될때마다 게임 상태를 업데이트하고 업데이트된 결과를 모든 클라이언트에 전역 회신하는 것은 너무 많은 CPU와 네트워크 대역폭을 소비합니다.\n더 나은 접근 방법은 클라이언트 인풋을 처리 없이 수신된 순서대로 정렬하는 것(queue)입니다. 대신에, 게임 상태는 낮은 빈도로 때때로 업데이트 됩니다. 예를 들어, 초당 10회처럼 말이죠. 이 경우의 100ms처럼 업데이트 사이의 지연율을 시간 단계(time step)라고 부릅니다. 매 업데이트 루프 단계마다 모든 미처리 클라이언트 인풋이 적용됩니다(역학을 더 예측 가능하도록 하기 위해 시간 단계보다 적은 시간의 인풋이 연산됩니다). 그리고 새로운 게임 상태는 클라이언트들에 전역 회신합니다.\n요약하자면, 예측 가능한 속도로, 현재 시점이나 클라이언트 인풋의 양과 독립적으로 게임 상태가 업데이트됩니다.\n저-빈도 업데이트 다루기 클라이언트 관점에서는 이 접근법도 기존처럼 부드럽게 작동합니다. 클라이언트 측 예측은 업데이트 지연과 독립적으로 작동하므로 상대적으로 빈도가 낮더라도 예측가능한 상태 업데이트 하에서도 정상 작동할 것이 분명합니다. 그러나, 게임 상태가 저-빈도(예시대로 진행하면, 매 100ms 마다)로 전역 회신되기 때문에 클라이언트들은 게임 세계에서의 다른 객체들의 정보가 너무 부족합니다.\n첫 번째 구현은 게임 상태를 회신할 때마다 캐릭터 위치를 업데이트 하는 것입니다; 이는 즉각적으로 끊기는 움직임이라는 문제를 일으키는데, 연속적인 부드러운 움직임이 아니라 100ms 마다 발생하는 이산적인 점프를 보이기 때문입니다.\n개발하고 있는 게임의 종류에 따라 이를 해결하기 위한 다양한 방법이 존재합니다; 일반적으로, 더 예측 가능한 객체들이 존재하는 경우 바로잡기 더 쉬워집니다.\n추측 항법(dead reckoning) 자동차 레이싱 게임을 만들고 있다고 합시다. 굉장히 빠른 속도의 차는 예측하기 쉽습니다 - 예를 들어, 초당 100m를 전진하고 있는 경우, 1초 뒤에는 대략 시작 시점의 100m 앞에 위치할 것입니다.\n왜 \u0026ldquo;대략\u0026quot;이라고 할까요? 그 1초 사이에 차는 조금 더 가속을 하거나 감속을 할수도, 방향을 왼쪽이나 오른쪽으로 조금 틀 수도 있습니다 - 여기서 중요한 단어는 \u0026ldquo;조금\u0026quot;입니다. 차량의 기동성이란, 플레이어가 실제로 무엇을 하는지와는 관계 없이, 고속에서 특점 시점이 지난 후의 위치는 그 이전 시점의 위치, 속도와 방향에 상당히 의존합니다. 다시 말해서, 레이싱 자동차는 즉각적으로 180° 회전할 수 없습니다.\n이게 100ms마다 업데이트되는 서버와 무슨 상관이 있을까요? 클라이언트는 권한으로부터 경쟁 차량의 속도와 방향을 전송받습니다; 다음 100ms동안은 그 어떤 정보도 주어지지 않지만, 그들이 달리고 있는 모습을 어떻게든 보여야합니다. 가장 간단한 해결책은 해당 차량들이 이전에 주어진 변수를 상수로 유지한채 100ms동안 달리는 것으로 가정하고 차량 역학을 계산하는 것입니다.그리고 100ms가 지난 후에 서버 업데이트가 회신되면 차량의 위치를 수정합니다.\n수정량은 여러가지 요인으로 인해 클 수도 있고 상대적으로 작을 수도 있습니다. 만약 플레이어가 차량을 직선으로 유지했고 속력도 변화시키지 않았다면 예측된 위치는 정확하게 일치할 것입니다. 반면에 플레이어가 무언가에 차량을 들이받았다면 예측된 위치는 완전히 틀린 것이 됩니다.\n예측 항법은 낮은 속도의 상황에 적용된다는 것을 기억하세요. 예를 들어, 함선 등이 해당합니다. 사실, \u0026ldquo;예측 항법\u0026quot;이라는 용어는 해군 항해에서 비롯되었습니다.\n객체 삽입 예측 항법이 전혀 사용될 수 없는 상황들이 존재합니다 - 특히, 플레이어의 방향이나 속력이 즉각적으로 변화되는 모든 경우에 그러합니다. 예를 들어, 3D 슈팅 게임에서 플레이어는 보통 매우 빠른 속도로 뛰고, 멈추며 코너를 돌아나갑니다. 이 경우 예측 항법 방식은 쓸모가 없게 됩니다. 위치와 속력이 이전 데이터로부터 유의미하게 예측될 수 없기 때문이죠.\n그렇다고 권한 있는 서버의 데이터를 회신할 때마다 업데이트할 수는 없습니다; 플레이어들이 매우 짧은 거리를 100ms마다 순간이동하는 결과를 낳게 되어 게임을 즐길 수 없는 상태로 만들기 때문이죠.\n우리가 가진 것은 매 100ms마다의 권한 위치입니다; 속임수는 그 사이에 벌어지는 일들을 어떻게 플레이어에게 보일 것인가 하는 것이죠. 열쇠는 사용자의 캐릭터보다 상대적으로 과거의 타 플레이어를 보이는 것입니다.\nt = 1000에 위치 정보를 받는다고 가정합시다. 이미 t = 900에서 데이터를 수신했습니다. 따라서 당신은 플레이어가 t = 900일 때 어디에 위치했는지와 t = 1000일 때 어디에 위치하는지를 알고 있습니다. 따라서, t = 1000과 t = 1100 시점에 t = 900에서부터 t = 1000사이동안 다른 플레이어가 한 것을 보여줍니다. 이를 통해, 사용자의 실제 움직인 데이터를 보여줄 수 있습니다. 다만, 100ms \u0026ldquo;늦게\u0026rdquo; 보여줄 뿐이죠.\n객체 삽입을 위해 사용한 t = 900부터 t = 1000사이의 위치 데이터는 게임에 의존합니다. 그래도 삽입은 일반적으로 잘 작동합니다. 그렇지 않다면, 매 업데이트마다 서버가 더 상세한 이동 데이터를 제공하도록 하면 됩니다 - 예를 들어, 플레이어 진행 방향에 있는 일련의 직선 분할 또는 10ms 단위로 샘플링 된 위치 데이터는 삽입시 더 부드러워 보일 수 있습니다(이것이 곧 10배의 데이터를 전송해야 된다는 의미는 아닌데, 이는 매우 작은 움직임들에 해당하는 델타 값을 전송하는 것이기 때문에 전송시의 형식이 특정 케이스에 적합하도록 신중히 최적화될 수 있기 때문입니다).\n이러한 기술을 사용할 경우, 모든 플레이어는 살짝 다른 게임 세계 렌더링 결과를 마주하게 되며, 이 것은 각 플레이어 본인은 현재 시점으로 적용되지만 타 플레이어는 아주 약간의 과거를 객체로 하기 때문입니다. 그러나, 빠른 진행의 게임일지라도 타 객체를 100ms로 보는 것은 일반적으로 크게 알아차릴만하지 않습니다.\n예외는 존재합니다 - 예를 들어, 플레이어가 타 플레이어를 쏠 때 처럼, 부분적이고 일시적인 정확도가 요구될 때 입니다. 타 플레이어는 과거위치로 렌더링되기 때문에 100ms의 지연율을 가지고 조준하게 됩니다 - 즉, 100ms 이전의 타겟을 조준하는 것이죠! 이 문제는 다음 파트에서 다루도록 하겠습니다.\n요약 권한 있는 서버를 이용하는 서버-클라이언트 모델에서는 잦지 않는 업데이트와 네트워크 지연율 하에서도 사용자에게 부드러운 움직임과 연속성의 착각을 제공해야만 합니다. 파트 2에서는 클라이언트 측 예측과 서버 측 조정을 통해 유저가 컨트롤하는 플레이어의 움직임을 실시간으로 적용하는 방안을 보았습니다; 이것은 로컬 플레이어에게는 즉각적인 인풋 결과가 발생하는 것을 보장하지만 게임을 플레이하기 힘들정도로 지연되는 렌더링을 제거할 수 있게 해주었습니다.\n그러나, 다른 객체는 여전히 문제입니다. 이번 파트에서는 그 문제를 해결하기 위한 2가지 방법을 보았습니다.\n첫 째는, 예측 항법 입니다. 이 방법은 객체의 이전 정보인 위치, 속도와 가속도 등을 바탕으로 수용가능한 수준으로 예측된 객체의 위치 정보를 가상화하는 방법입니다. 몇 가지 조건들이 마땅치 못할 경우 이 방법은 실패합니다.\n둘 째는, 객체 삽입법 입니다. 이 방법은 미래를 전혀 예측하지 않습니다 - 단지, 서버로부터 제공받은 실제 객체 데이터만을 활용하며, 약간 지연된 시점의 객체를 보여줄 뿐입니다.\n결과적으로 유저의 플레이어는 현재 시점으로 보여지고 다른 객체는 과거로 보여집니다. 이 방법들로 완벽한 경험을 만들어내곤 합니다.\n그러나, 다른 해결책이 없을 경우, 이동하는 타겟을 사격하는 등의 부분적이고 일시적인 정밀함이 요구되는 경우에 이러한 착각은 모두 산산조각이 납니다: 클라이언트 2가 렌더링하는 클라이언트 1의 위치 정보는 서버의 것이든 클라이언트 1의 것이든 그 어떤 것의 위치 정보와도 일치하지 않으므로, 헤드샷은 불가능한 일이 됩니다! 그 어떤 게임도 헤드샷이 없이는 완벽할 수 없으므로 우리는 다음 파트에서 이 이슈에 대해 다루어볼 것입니다.\n파트 4: 지연 보상(lag compensation) 소개 이전 파트들에서는 아래와 같이 요약이 가능한 클라이언트-서버 게임 설계를 설명했습니다:\n서버는 모든 클라이언트로부터 시간정보가 담긴 인풋을 받는다. 서버는 인풋을 처리하고 게임 세계 상태를 업데이트한다. 서버는 일반적인 세계 상태 정보를 모든 클라이언트에 전송한다. 클라이언트는 인풋을 전송하며 그 효과를 지역적으로 가상화한다. 클라이언트는 세계 업데이트 정보를 회신하고 예측된 상태와 권한 상태를 동기화한다. 타 객체의 과거 상태로 알려진 정보를 삽입한다. 플레이어 입장에서는, 두 개의 주요한 결과를 갖습니다:\n플레이어 본인은 현재 상태를 본다. 플레이어는 타 객체의 과거 상태를 본다. 이 상황은 일반적으로 괜찮지만, 시간/공간적으로 민감한 이벤트에 있어서는 문제가 발생할 소지가 있습니다; 예를 들어, 적의 머리를 조준하는 경우처럼 말이죠.\n지연 보상 당신은 저격총으로 적의 머리를 정확히 조준하였습니다. 발사하였습니다 - 실패할 수가 없는 저격이죠.\n그러나 실패합니다.\n이런 일은 왜 발생할까요?\n앞서 설명한 클라이언트-서버 설계 때문에, 사격 전 100ms 이전의 적 머리를 조준한 것입니다 - 발사할 시점의 위치가 아니라요!\n표현하자면, 빛의 속도가 매우, 매우 느린 세계에서 게임을 하는 경우와 유사합니다; 적의 이전 위치에 조준하지만, 방아쇠를 당기는 순간 적은 이미 멀리 사라지고 난 이후인 것이죠.\n운이 좋게도, 이를 위한 매우 간단한 해결책이 있고, 이는 대부분의 플레이어를 대부분의 경우에 만족시킬 수 있습니다(아래에서 설명할 단 하나의 예외 상황을 제외하고 말이죠).\n작동 원리는 아래와 같습니다:\n사격을 하면, 클라이언트는 이 사격과 관련된 완전한 정보를 서버에 전송합니다: 사격의 정확한 시간과 무기가 조준한 정확한 조준점에 대한 정보입니다. 가장 중요한 단계입니다. 서버는 시간 정보가 담긴 인풋을 제공받기 때문에, 권한을 활용해 과거 어느 시점이든 관계없이 즉각 게임 세계를 재건설할 수 있습니다. 특히, 그 어떤 클라이언트든 특정 시점에 어떤 상황을 보고 있을지를 정확하게 재현해낼 수 있죠. 이 것은 서버가 당신이 무기를 발사하는 정확한 시점에 무기 시야에 어떤 것이 보이고 있는지를 알 수 있다는 뜻입니다. 그 것이 적 머리의 과거 시점일지라도, 서버는 그것이 당신의 현재 시점에서 본 적 머리의 위치라는 것을 알고 있습니다. 서버는 그 시점 에서의 사격을 처리하고 클라이언트들을 업데이트합니다. 그리고 모두는 행복하죠!\n서버는 서버라서 행복합니다. 서버는 항상 행복해요.\n당신은 적 머리를 조준하고 사격했는데 헤드샷 보상을 받을 수 있게 되어서 행복합니다.\n적은 전적으로 행복하지만은 않은 유일한 사람이겠네요. 사격 당시 적이 가만히 서있었다면 그건 적의 잘못이죠, 맞죠? 움직이고 있었다면\u0026hellip; 와 당신이 대단한 저격수네요.\n하지만 만약 그가 열린 공간에 있다가, 벽 뒤로 숨게 되고, 매우 미세한 시간이 지나고 나서야 저격을 당했다면 어떨까요? 그는 안전하다고 생각했을텐데 말이죠.\n흠, 이런 일이 발생할 가능성은 충분하죠. 그 부분이 감수해야할 부분입니다. 과거의 사격이기 때문에, 피격자는 안전한 곳으로 대피한 수 밀리세컨드 이후에 사격으로 사망할 수도 있게 됩니다.\n다소간 불공정하지만 모두가 동시에 동의할 수 있는 해결책임은 확실합니다. 못 맞출 수가 없는 저격을 실패했다는 판정을 받는 것 보다 나으니까 말이죠!\n결론 이 것으로 빠른 진행 멀티플레이어 시리즈가 막을 내립니다. 이런 종류의 일들은 정확하게 구현하기 어렵지만 개념적으로 명확히 이해하고 난다면 불가능할정도로 어려운 일은 아닙니다.\n비록 이 내용이 게임 개발자를 대상으로 하지만, 다른 그룹의 독자들에게도 유용할 것 같아요: 게이머들이요! 게이머 입장에서도 특정 일들이 도대체 왜 벌어지는가에 대해 이해하는 것은 흥미로운 일이죠.\n추가 읽을거리 이 기술들이 너무 현명한 방법인만큼, 일부라도 제 공으로 돌리기는 참 어렵네요; 여기 쓰여진 내용들은 제가 다양한 포스트와 소스 코드 그리고 일부 실험을 통해 배운 개념들을 알기 쉽게 설명한 가이드일 뿐입니다.\n가장 관련있는 글 들은 게임 네트워크에 관해 모든 프로그래머가 알아야 할 것들과 클라이언트/서버 인게임 프로토콜 디자인과 최적화에서의 지연 보상 방법론 입니다.\nTlanslators Note - 역자주\n추가적으로 원본 글에서는 \u0026lsquo;Live Demo\u0026rsquo;가 제공됩니다. 이는 별도로 여기에 번역하지 않았으며, 링크를 통해 확인하시기 바랍니다\n","permalink":"http://ptrtoj.com/kr/multiplayer/","summary":"\u003cblockquote\u003e\n\u003cp\u003eThis is translated work. The original post is written by \u0026lsquo;Gabriel Gambetta\u0026rsquo;, the link is \u003ca href=\"https://www.gabrielgambetta.com/client-server-game-architecture.html\"\u003ehere\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eThe translation was permitted on 2020/12/06. This is a combined long HTML version of each series.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cblockquote\u003e\n\u003cp\u003e이 문서는 번역본입니다. 원본은 \u0026lsquo;Gabriel Gambetta\u0026rsquo;가 쓴 것으로, \u003ca href=\"https://www.gabrielgambetta.com/client-server-game-architecture.html\"\u003e링크\u003c/a\u003e를 통해 확인할 수 있습니다.\u003c/p\u003e\n\u003cp\u003e번역은 2020/12/06에 허가되었습니다. 이 문서는 각 시리즈를 하나의 HTML 파일로 편집한 것입니다.\u003c/p\u003e\n\u003c/blockquote\u003e","title":"빠른 진행 멀티플레이어"},{"content":"약간의 역사 이야기 1991년 Linus Torvalds(라이너스 토르발즈)가 \u0026lsquo;Linux Kernel, ver.0.01\u0026rsquo;을 발표합니다.\n이후 Richard Stallman(리처드 스톨먼)의 \u0026lsquo;GNU(GNU is Not Unix)\u0026lsquo;의 유틸리티를 내장하며 명실상부 운영체제(OS)로써 자리잡습니다.\n1991년 H. J. Lu의 \u0026lsquo;부트 루트\u0026rsquo;가 리눅스 커널을 포함하는 디스크 이미지로 탄생합니다.\n극 초기(91-92년)의 어려운 설치 과정과 패키지 관리 한계를 보완하고자 \u0026lsquo;SLS(Softlanding Linux System)\u0026lsquo;가 등장합니다. X 윈도우 시스템을 통해 그래픽 환경을 포함하고 있었다고 합니다. 현재까지 이어지는 배포판 형태의 첫 등장이라고 할 수 있습니다.\nLinux? LinuxOS? GNU/Linux?\n리눅스는 언제나 커널(Kernel)만을 의미합니다.\n흔히 \u0026lsquo;리눅스’ 혹은 ‘리눅스 OS\u0026rsquo;라고 표현하는 것은 \u0026lsquo;GNU/Linux\u0026rsquo;가 올바른 표현이라는 주장이 있습니다!\n”Let me interject for a moment. What you guys are referring to as Linux, is in fact, GNU/Linux …(후략)”\n→ Richard M. Stallman\n1992년 12월, 이그드라실 리눅스/그누/X(Yggdrasil Linux/GNU/X)가 상업 배포판으로 출시됩니다.\nSLS의 단점(시스템 전반에 걸친 버그)을 보완하고자 1993년 Slackware(슬랙웨어-패트릭 볼커딩)가 나타나더니, 이안 머독이 지금까지도 유명한 Debian(데비안)을 출시하게 됩니다. 데비안을 기점으로 Ubuntu(우분투) 등 엄청난 양의 배포판이 쏟아져 나오기 시작했고, 뿐만 아니라, 독립 진영에서도 Red Hat(레드 햇), Arch Linux(아치 리눅스), Gentoo Linux(젠투 리눅스) 등 다양한 배포판이 출시되었습니다.\n세가지 구분 기준 리눅스는 구분을 하는 기준이 크게 세 가지 존재합니다.\n첫 번째로는 계열입니다.\n이에 따른 기준으로 나누면 데비안/우분투/민트로 이어지는 부류와 레드햇/페도라/센트OS/최근의 로키 등, 그리고 독립 계열(다른 배포판을 기반으로 만들어지지 않고, 아예 처음부터 만든 배포판)인 아치 리눅스, 젠투 리눅스, 보이드 리눅스 등으로 구분할 수 있습니다.\n두 번째로는 패키지 매니저입니다.\n사용하는 패키지 매니저인 apt, rpm/yum/dnf, pacman, emerge, zypper, xbps, pkg, eopkg와 같은 구분도 유용하지만 바이너리 패키지 매니저인지 소스 패키지 매니저인지도 유용합니다. 현재 99%의 배포판은 바이너리 패키지 매니저를 활용하여 매우 빠른 설치를 돕습니다. 그러나, 젠투 리눅스, CRUX, LFS 등, 그리고 BSD 계열에서 port를 사용하는 경우 소스 코드를 다운로드 받아 직접 컴파일 하는 패키지 매니저도 있습니다.\n마지막으로 출시 방식입니다.\n최근에는 기술적 한계를 많이 보완하게되어 \u0026lsquo;롤링 릴리즈\u0026rsquo;가 매우 빠른 성장을 거듭하고 있습니다. 이는 정해진 버전이 없이, 평소에 하는 시스템 업그레이드 만으로 컴퓨터를 최신 상태로 유지하는 방식입니다. 따라서, 일정한 업데이트/업그레이드를 해주기만 한다면 모두가 같은 버전에서 사용하고 있는 것입니다. 일반적으로 롤링 릴리즈의 대명사로 알려진 리눅스는 \u0026lsquo;아치 리눅스\u0026rsquo;입니다. 롤링 릴리즈 배포판들의 경우 각 패키지 개발자들이 출시하는 것들을 매우 빠르게 가져오는 경향이 있습니다. \u0026lsquo;픽스드 릴리즈\u0026rsquo;로 불리는 고정형 출시 방식은 우분투가 대표적입니다. 연도.월로 이루어진 버전으로 통상적으로 정해진 시기에 새 버전이 출시될 것임을 짐작할 수 있습니다. 그리고 일정한 기준에 따라 LTS(Long Term Support; 장기 지원 버전)라고 하여, 일반적인 버전들의 지원 기간보다 훨씬 긴 버전을 제공하여 서버 등에서 활용하기에 유리한 면이 있습니다.\n출시 방식을 기준으로 아래는 출시 방식을 기준으로 정리하였습니다.\n롤링 릴리즈(Rolling Release) 정기적인 배포판이 존재하기 보다는, 언제든지 새로운 버전이 출시되면 업데이트가 가능한 배포판의 종류입니다. \u0026lsquo;Bleeding Edge\u0026rsquo; 라고 하는 특징을 가지고 있습니다. \u0026lsquo;Bleeding Edge\u0026rsquo;란 흔히 \u0026lsquo;첨단 기술\u0026rsquo;로 번역되곤 합니다. 항상 최신 버전의 패키지(소프트웨어)를 사용하고 싶은 유저들이 애용하고 있습니다. 고정형 버전 방식(Fixed Release)나 장기 지원 버전(LTS; Long Term Service) 타입의 경우, 새로운 버전이 출시되면 다시 다운로드 받아 설치하고 본인에게 맞는 환경 설정을 해야하는 부담이 있지만, 롤링 릴리즈 타입의 OS가 설치된 PC라면 누구라도 최신 버전의 커널과 패키지들을 항상 유지 관리할 수 있다는 장점이 있습니다. 안정성이 충분히 검증되지 않은 최신 기능과 특징을 설치하고 운용하는 롤링 릴리즈 자체가 갖는 특성상 간혹 문제를 일으키는 경우도 발생합니다.\n아치 리눅스 설치 과정이 난해하기로 악명이 높습니다 (하지만 잘 정돈된 가이드가 있다면 어떨까요?). 부팅 가능한 매체로 부팅이 성공하면 CLI(커맨드라인 인터페이스)에 던져지고, 유저가 직접 드라이브의 파티션, 포맷, 베이스, 부트로더 등을 설치합니다. 유저가 PC의 모든 빌드를 직접 진행할 수 있는 만큼 자유도가 높습니다.\n패키지 매니저로는 PACMAN(PACkage MANager)을 사용합니다. C로 설계된 PACMAN은 다른 배포판들의 패키지 매니저와 비교하여 속도와 유연함 면에서 앞선다고 생각합니다. AUR(Arch User Repository)의 존재 덕분에 소스를 다운로드 받아 직접 빌드해 사용하는 것도 가능합니다.\n한국 아치 리눅스 위키, 아치 리눅스 홈페이지, 아치 리눅스 포럼 등을 기반으로 하는 거대하고 강력한 커뮤니티는 아치 리눅스의 또다른 자랑거리중 하나입니다. 아치 리눅스를 사용중 문제가 발생하였을 경우 구글 검색어 앞에 \u0026lsquo;arch\u0026rsquo;를 붙여 검색하면, 다양한 해결 방법이 검색됩니다. 검색 결과가 마음에 들지 않거나, 내 상황에 맞는 해결 방법이 없을 경우에는 위의 커뮤니티에 접속해서 질문을 하면 커뮤니티 유저들이 기꺼이 도와줄 겁니다. 설치 과정에서 GUI 인스톨러의 부재로 인해 Manjaro(만자로), Antergos(중단-\u0026gt;EndeavourOS로 포크) 등이 탄생하게 됩니다.\n설치는 CLI(커맨드 라인 인터페이스)로 진행하며, 기본 설치가 완료되어도 베이스만 설치되어있을 뿐, Xorg와 데스크탑 환경이나 윈도우 매니저도 직접 설치하여야 합니다. 따라서, 본인이 성공적으로 데스크탑을 완성하더라도 이 것이 어느정도나 안정적이고 보안에 취약한지는 확신할 수가 없습니다. 일반적으로 커뮤니티에선 \u0026ldquo;작동한다면 된거다\u0026quot;라고 하지만 완벽을 추구하는 성격인 분들은 상당히 성가신 부분일 수 있습니다. 롤링 릴리즈타입으로 특정 버전이 존재하지 않으며, 지속적으로 업데이트를 하면서 굴려 나가는 배포판입니다. 따라서, 롤링 릴리즈가 아닌 배포판들이 갖는, 메이저 버전 업데이트 때의 충돌 위험 등을 고려하면 상당히 마음 편한 배포판입니다.\n해외 포럼에서는 아치 리눅스가 수동 설치라는 점 때문에 아치 리눅스 사용자임을 은근히 드러내고자 하는 사람이 많음을 비꼬아 \u0026lsquo;BTW I Use ARCH(참고로 나는 아치를 씀)\u0026rsquo; 밈을 사용합니다. 근데 사용자 본인들도 씁니다.\n젠투 리눅스 젠투 리눅스는 보통 아치 리눅스보다 설치 과정이 더 어렵기로 유명합니다. 젠투 리눅스 사용자는 커널까지도 직접 컴파일하여 빌드합니다. 따라서 매우 유연하고, 본인이 가진 하드웨어에 최적화된 리눅스를 만드는 것이 가능합니다. PC의 연산 속도(CPU의 성능)가 떨어질수록 빌드 시간이 오래 걸린다는 단점이 있습니다. 패키지 매니저의 경우도 소스를 컴파일 하는 방식이다 보니 시간이 조금 더 걸리는 단점이 있습니다. 하지만, 본인이 리눅스의 깊은 곳까지 직접 관리하고 싶거나 혹은, 직접 쌓아올리는 OS에 호기심과 매력을 느낀다면 사용해볼만한 가치가 충분합니다.\n젠투도 롤링 릴리즈입니다. 아치 리눅스와 마찬가지로 모든 설치는 CLI에서 진행하며, 설정도 직접 해주셔야 합니다. 아치보다 더 나아가 모든 패키지는 소스 코드를 다운 받아 직접 컴파일 합니다. 재밌는 점은 하드웨어가 받혀준다면 사용하는데 큰 문제는 없다는 것입니다. USE 플래그를 활용하여 각 패키지별로 본인이 사용할 추가적 기능과 그렇지 않은 기능을 포함/미포함하여 컴파일 할 수 있습니다. 개인적으로, CPU가 워크스테이션 급이 아닌 분들은 한 번쯤 사용은 해보시되 바이너리 배포판(젠투를 제외한 대부분의 일반 배포판)을 사용하시는 것을 추천합니다.\n픽스드 릴리즈(Fixed Release) 이 배포판들은 일정 시기를 기점(Fixed Release)으로 새로운 배포판이 출시 됩니다. 출시한지 꽤나 시간이 지났더라도 아직 서비스 지원 기간에만 속한다면 지원(최신 버전의 패키지를 사용하기는 힘들 수 있으나, 최소한 보안 패치 등은 모두 지원 받을 수 있음)을 받을 수 있습니다. 과거엔 신규 버전 배포판 출시 때 업그레이드 관련해 많은 어려움이 있었지만, 레드햇 등의 회사에서 다양한 방법으로 해결을 시도하였고 실제로 그런 불편함은 많이 해소되었습니다. 꼭 최신 버전 패키지들의 새로운 기능을 사용해 보고 싶은 욕심이 없고, 안정적인 배포판을 사용하고 싶은 유저들이 사용하고 있습니다.\n데비안 현대적 리눅스 배포판들 중의 원조라고 생각합니다. 90년대 초반 SlackWare(슬랙 웨어) 등과 함께(엄밀히 말하면, 슬랙웨어가 먼저 등장하였습니다.) 등장한 데비안은 아직까지도 그 단단한 기반에 많은 유저들을 확보하고 있습니다. 오래되고 가장 인기있는 OS 중 하나로 군림하다보니 패키지의 양도 굉장히 많습니다. 다만, 너무 안정적이려는 특성 때문에 새로운 배포판 출시까지의 기간이 길고 서버에서 주로 쓰이는 특징이 있습니다. 우분투라는 유명한 아들 배포판을 배출해 냈습니다.\n우분투 리눅스는 너무 식상하다거나, 조금 더 자세히 알아보고 싶다고 생각하시는 분들은 데비안 리눅스를 추천합니다. 데비안 리눅스는 오래 되어서 구식이라고 편견을 가지실 수도 있는데, 아직도 건재한 배포판입니다. 오히려 성숙했다는 표현이 적합할 정도죠. 데비안 리눅스는 견고(solid)하기로 유명합니다. 상당히 체계적인 검토와 테스팅을 거쳐 레파지토리(패키지 모음)에 올려지기 때문에, 데비안에서 기본적으로 제공하는 레파지토리에서 설치 가능한 패키지라면 꽤나 신뢰하고 사용하셔도 무방합니다. 다만, 위와 같은 특징 때문에 타 배포판보다 훨씬 오래된 버전의 패키지들을 사용하게 될 수도 있습니다. 이 부분은, etc/apt/source.list를 편집하여 testing 버전으로 사용시 롤링 릴리즈 배포판처럼 사용할 수 있습니다.\n우분투 데비안을 기반으로 제작되어 영국 \u0026lsquo;캐노니컬\u0026rsquo;이라는 회사 지원을 받고 있는 배포판으로, 윈도우나 맥OS사용자가 리눅스 계열을 처음 사용하고자 할 때 자주 추천을 받게 되는 배포판 중 하나입니다. 설치 과정이 간편하고, 사용도 직관적인데 게다가 중요 기능에 부족함이 없는 훌륭한 배포판입니다. 각종 데스크탑 환경을 기반으로 Ubuntu Mate(Mate), Kubuntu(KDE), Xubuntu(XFCE), Lubuntu(LXDE)로 뻗어나갔습니다.\n리눅스에 입문을 하시려는 분들은 우분투 리눅스나 혹은, 그 계열인 민트를 사용하시는 것을 추천합니다. 대부분의 사용은 GUI(그래픽 UI 환경)에서 처리가 가능하고 설치도 용이합니다.\n민트 우분투 기반으로 제작됨(최근에는 데비안 베이스도 활발히 개발 중; LMDE). Windows와 유사한 데스크탑 환경을 갖고 있어 많은 사랑을 받고 있습니다. 초보자가 설치, 유지 관리하기에도 부족함이 없습니다.\n페도라 Red Hat 사 로고에 등장하는 Shadowman의 모자인 페도라에서 이름을 따왔습니다. 픽스드 릴리즈의 특성상 새로운 배포판이 나오면 업데이트를 진행해야 합니다. 많은 발전으로 업데이트 도중 문제가 생기는 경우가 현저히 줄어들었습니다. 또, ‘가장 완벽에 근접한 오픈 소스 철학을 실현하고 있다’고 주장합니다. 따라서, 공식 레파지토리에는 철저히 오픈 소스의 철학을 가진 패키지들이 실립니다. 하지만, proprietary(개인이나 단체가 소유권을 가지는, 오픈 소스가 아닌) 패키지를 설치하고자 한다면 그것도 가능합니다. 유명한 RPM 패키지 매니저(Fedora: \u0026lsquo;DNF package manager\u0026rsquo; / Red Hat: \u0026lsquo;YUM package manager\u0026rsquo;)를 사용합니다.\n레드 햇의 주요 파생 배포판 중 하나입니다. 레드 햇 리눅스(현 RHEL과 다름)가 중단(2003년)되면서 페도라가 공식적으로 시작되었고, 페도라를 베이스 라인으로 하는 RHEL(Red Hat Enterprise Linux)이 레드 햇의 유일한 공식 지원을 받게 됩니다(페도라는 커뮤니티 기반으로 운영됩니다. 이런 운영 방식의 배포판을 \u0026lsquo;community driven distribution\u0026rsquo;이라고도 합니다). 리눅스 진영에서의 혁신적인 시도를 자주 시행한 훌륭한 배포판입니다. 레드 햇 리눅스가 서버에서 압도적으로 많이 활용되고 있는 만큼, 서버 관련 업종에 종사하시거나, 종사할 계획이 있는 분들은 페도라 리눅스가 적합하다고 생각합니다. (간혹 인터넷 커뮤니티에서는 RHEL의 베타 테스팅 버전이라고 놀림을 받기도 함)\n페도라부터 블리딩 엣지(최신 기술, 첨단 기술)의 영역으로 보는 사람이 많습니다. 엄밀히 Out of the Box 형태의 배포판이지만 최신 기능이나 패키지들을 탑재하기로 유명합니다. 페도라는 최신 패키지들을 적극적으로 공식 레파지토리에 올려두기로도 유명합니다. 어느 정도 버그가 있을 순 있겠지만 사용자에게 가장 최신 버전의 패키지들을 사용가능하도록 제공합니다. Out of the Box 진영과 Bleeding Edge진영의 사이에서 정확한 스윗 스팟을 자극한 배포판으로 생각합니다. 리눅스 커널의 창시자이자 개발자인 Linus Torvalds가 과거 인터뷰에서 \u0026ldquo;데비안 설치는 너무 어렵고, 나는 개발자이지 배포판 설치 전문가가 아니라\u0026quot;면서 페도라를 사용하고 있음을 언급한 적이 있습니다. (토르발즈가 언급했던 어려운 설치 버전의 데비안은 아마도 \u0026lsquo;우디\u0026rsquo; 시절로 추정하며, 그 당시엔 GUI 인스톨러가 아니었습니다.) 개인적인 생각으로도 개발을 위한 환경까지 아울러, 리눅스에 경험이 어느정도 쌓였다면 최적화된 배포판이 아닐까 생각해봅니다.\nRHEL(Red Hat Enterprise Linux) 레드햇 기업 지원 유료 리눅스. Red Hat Cetification Program(RHCP)이라고 불리는 레드햇 국제 자격증 과정으로도 유명합니다. RHCP는 레드햇 서버 혹은 데스크탑 사용 자격이 있는가를 검증해주는 자격증 프로그램을 말합니다.\n개발 목적으로 등록하는 경우 피지컬 머신 1대 가상 머신 16대까지 무료로 사용 가능합니다.\n오픈수사 유럽 발(독일) 리눅스 배포판. LEAP 버전은 Fixed Release이고, Tumbleweed 버전은 Rolling Release입니다.\n엘레멘터리 OS 아름답기로 유명한 배포판. 맥 OS와 시각적 유사점이 많아서 맥 OS에서 리눅스 진영으로 넘어온 다수의 사용자를 흡수 하고 있는 것으로 보입니다.\n슬랙웨어 슬랙웨어입니다. 리눅스의 역사에 더 매료되시는 분들은, 슬랙웨어를 추천합니다. 가장 오래된 배포판입니다. (사실 데비안과 3개월(?) 정도 차이밖에 나지 않습니다. 다만 데비안과 슬랙웨어를 제외하고는 당시 출시된 배포판은 대부분 소멸되거나 다른 방향으로 변화해왔습니다. 원래의 철학과 모습을 유지하는 배포판은 슬랙웨어와 데비안 뿐으로 생각합니다.) 엄밀히 말하면, 최초의 배포판을 \u0026lsquo;Boot Root\u0026rsquo;로 생각할수도 있지만, 지금과 같은 형태의 배포판으로써는 슬랙웨어가 확실히 최초라고 알려져 있습니다. 패키지 매니저는 pkgtool 과 slackpkg가 있습니다. 의존성을 직접 체크, 컴파일해야하는 패키지 매니저와 현대적인 의존성 체크와 바이너리 인스톨을 가능하게하는 패키지 매니저 둘 모두를 지닌 매력적인 배포판입니다. 데비안과 마찬가지로 올드한 패키지들을 보유하고 있습니다. 한 번쯤, 경험해보면 좋을 배포판입니다.\n기타 - LFS(Linux From Scratch) 책의 형태로 존재하는 배포판입니다. 사실 배포판이라고 불러야 하는지 애매한 위치에 있습니다. 홈페이지에서 LFS 부터 시작합니다. LFS를 완성하고 나면 BLFS(Beyond LFS) , CLFS(Cross-compile LFS) 등 다양한 줄기로 더 심화된 빌드를 할 수 있습니다. 보통, 리눅스 시스템 학습용으로 매우 훌륭하다는 평가를 듣고 있습니다. 리눅스 기반의 호스트 PC에서 GCC 등 OS설치를 위한 기본 준비를 모두 마친 후에 리부트를 통해 설치 환경으로 진입합니다. 일반적인 환경에서 사용하기에는 한계가 많아 보입니다. 리눅스 시스템에 대한 전반적이고 깊은 이해를 필요로 하는 경우에는 충분히 참고하거나 공부해볼만한 배포판인 것 같습니다.\nLFS는 완전히 학습용이라고 생각합니다. 설치 이미지(iso)파일도 제공되지 않고, 책을 보면서 설치합니다. 설치 환경 조성을 위해 \u0026lsquo;/mnt/lfs/tools\u0026rsquo; 디렉토리를 생성하여 그 곳에 GCC등의 필수 패키지를 컴파일(호스트 PC의 GCC와 다른 필수 패키지들의 설정과 버전 등을 신뢰할 수 없기 때문에) 해 놓은 후, /tools의 패키지들을 이용해 /mnt/lfs의 베이스(다시, GCC와 나머지 필수 패키지)를 설치하고나서, 추가로 필요한 패키지들을 베이스 시스템의 GCC를 이용해 컴파일합니다. 추후에, BLFS 등에서 Xorg와 데스크탑 환경 등 까지도 컴파일할 수 있습니다. 젠투를 위시한 여러 배포판들은 사실상 LFS와 BLFS, CLFS 등과 같거나 유사한 과정을 통해 탄생한 배포판 들 입니다. 배포판 제작에 관심이 있으신 분들은, LFS를 통해 공부,연구 하셔도 무방할 듯 합니다. 컴파일을 해야하다보니, 젠투처럼 CPU의 영향을 매우 크게 받습니다.\n마치며 여기까지 굵직한 배포판들의 간략한 소개를 드렸습니다. 이 글을 통해, 여러분들이 사용하실 배포판 선택에 도움이 되었기를 바랍니다. 개인적인 소망이지만 대한민국에 일반 사용자(Daily Machine)로써 리눅스 사용자가 더욱 더 많아지기를 기대합니다!\n","permalink":"http://ptrtoj.com/kr/distro/","summary":"\u003ch2 id=\"약간의-역사-이야기\"\u003e약간의 역사 이야기\u003c/h2\u003e\n\u003cp\u003e1991년 Linus Torvalds(라이너스 토르발즈)가 \u0026lsquo;Linux Kernel, ver.0.01\u0026rsquo;을 발표합니다.\u003c/p\u003e\n\u003cp\u003e이후 Richard Stallman(리처드 스톨먼)의 \u0026lsquo;GNU(\u003cstrong\u003eG\u003c/strong\u003eNU is \u003cstrong\u003eN\u003c/strong\u003eot \u003cstrong\u003eU\u003c/strong\u003enix)\u0026lsquo;의 유틸리티를 내장하며 명실상부 운영체제(OS)로써 자리잡습니다.\u003c/p\u003e","title":"리눅스 배포판 종류"},{"content":"서문 UNIX 역사에 대해서는 따로 궁금하지 않으신 분들은 바로 ‘리눅스 배포판 종류’로 이동하시면 됩니다.\nUNIX UNIX(이하 \u0026lsquo;유닉스\u0026rsquo;)의 역사를 설명하기 위해서는 1960년대 중반까지 거슬러 올라갑니다. 당시 MIT, AT\u0026amp;T의 벨 연구소, GE(제너럴 일렉트릭)은 GE-645 메인프레임에서 사용하기 위한 Multics(이하 \u0026lsquo;멀틱스\u0026rsquo;)라는 실험적인 시-분할 운영 체제(현대에 당연한 다중 동시 사용자, 멀티 태스킹이 가능한 운영 체제의 조상) 개발에 참여 중이었습니다. 멀틱스의 크기나 복잡도에 실망한 벨 연구소는 차츰 연구에서 손을 떼기 시작했습니다만, 마지막까지 연구에 관심을 갖던 켄 톰슨, 데니스 리치, 덕 매킬로이, 조 오산나는 그렇지 않았습니다. 넷은 시기적으로 일렀을 뿐이라는 판단 아래, 조금 더 작은 규모로 실험을 계속 해보고자 했습니다.\nUNIX® ?\n→ UNIX(유닉스)는 The Open Group의 공식 상표입니다.\n이는 제7차, 오픈 그룹 기본 제원 (POSIX.1-2008 또는 IEEE Std 1003.1 - 2008)에 부합하는 컴퓨터 운영 체제 및 도구를 가리킬 때 사용됩니다.\n1969년 켄 톰슨은 거의 사용되지 않던 DEC(Digital Equipment Corporation)사의 PDP-7을 연구소에서 발견합니다. 이 PDP-7을 통해 톰슨, 리치 등이 계층 파일 시스템(Hierarchical File System)을 구현합니다. 이것이 유닉스 계열 운영 체제에 아직도 전해져내려오는 /, /bin, /usr, /etc 등이 됩니다. 거기서 멈추지 않고 컴퓨터 프로세스, 디바이스 파일(/dev 아래), 커맨드 라인 인터프리터, 어셈블러, 에디터, 쉘 등을 개발해냅니다. 마지막으로 더글라스 매킬로이가 TMG 컴파일러-컴파일러를 PDF-7 어셈블리어로 포팅하며 최초의 유닉스 고레벨 언어를 탄생시킵니다. 톰슨은 이 도구를 활용해 B 프로그래밍 언어의 첫 버전을 개발합니다.\n이렇게 탄생한 첫 운영 체제는 벨 연구소의 지원으로 개발된 것도 아니었고, 멀티 태스킹이 가능하지도 않았으며, 이름마저도 없었습니다. 단지 기술자들이 이루고자 했던 목표를 달성하기 위해 밤낮을 가리지 않고 노력한 결과물일 뿐이었습니다. 처음 지어진 이름은 Unics(Uniplexed Information and Computing Service; 유넉스로 읽음)였지만, 이후 \u0026ldquo;어차피 아무도 기억 못할테니까\u0026quot;라는 농담을 덧붙이며 브라이언 커니건이 유닉스(UNIX)라는 이름의 출처가 본인이었다고 주장합니다. 데니스 리치와 덕 매킬로이도 나중에 커니건에게 작명의 공을 돌렸습니다.\n이제 PDP-7보다 더 큰 하드웨어에서 멀티태스킹까지 가능한 운영체제를 만들어보고자 했던 컴퓨터 연구원들은 당시 법률 관련 부서에서 문서 편집기가 필요하다(당시 벨 연구소는 수많은 특허 출원을 위해 변호사/변리사들의 특허 관련 서류 작성량이 어마어마했다고 알려짐)는 점을 알고, PDP-11을 사주면 문서 편집을 위한 환상적인 소프트웨어를 제작해 줄 것임을 약속하여 재정 지원을 받아냅니다.\n1970년 처음으로 PDP-11/20을 받게 된 연구원들은 순식간에 roff로 알려진 문서 양식 편집 소프트웨어를 만들고 문서 에디터까지 추가합니다. 이 프로그램들은 모두 PDP-11/20 어셈블리어로 작성되었습니다. 벨 연구소에서는 이 프로그램들을 활용해 편리하게 특허 관련 서류들을 작성하기 시작했습니다. (roff는 금방 troff로 진화함)\n벨 연구소의 다른 부서에서 DEC PDP-11을 구매하게 되었을 때는 이미 DEC에서 제공하는 자체 운영 체제가 아니라 유닉스를 활용하기로 결정합니다. 유닉스의 복잡성은 계속 커져가는데 사용하고자 하는 부서와 연구팀은 증가하면서 매뉴얼의 필요성이 대두됩니다. 이로써 1971년 11월 3일 유닉스 프로그래밍 매뉴얼이 만들어집니다. 현재까지 사용되는 man 명령어의 시작이 이때였습니다.\n1973년 유닉스 버전 4가 고레벨 언어인 C로 다시 쓰입니다. 이로써 어셈블리어 자체는 버전 8 까지도 살아남았으나, 소프트웨어의 이식성(다른 명령어 세트를 가진 컴퓨터에서도 컴파일을 통해 쉽게 사용할 수 있는 기능)이 제시됩니다. 같은 해, AT\u0026amp;T의 유닉스 버전 5가 출시되면서 교육 기관에 라이선스를 제공하게 됩니다 (기업에는 1976년 유닉스 버전 6부터 라이선스가 제공됨 - 상업 라이선스는 미화 2만달러, 2020년 가치로 96,190$로 알려짐). 외부에 제공되기 시작한 버전 5, 버전 6를 통해 라이언이 쓴 소스 코드를 포함 UNIX 버전 6 주석이라는 전설적인 책을 남길 수 있게 됩니다.\nBSD 애초에 BSD는 유닉스 복사본도, 심지어 확연히 다른 버전인 것도 아니었습니다. 단지 AT\u0026amp;T가 소유하는 소스 코드 위에 몇 개의 추가적으로 도움이 될 유틸리티를 추가했을 뿐이었습니다.\n1975년 켄 톰슨은 휴식차 벨 연구소를 떠나 방문 교수겸 버클리, 캘리포니아 대학에 옵니다. 이 때 유닉스 버전 6의 설치를 돕고 시스템에 파스칼을 이식하기 시작했습니다. 대학원생이었던 척 해일리와 빌 조이는 톰슨의 파스칼을 개선하는 한편 향상된 텍스트 에디터인 ex를 개발합니다. 이런 개선 사항에 관심이 생긴 주변 대학들이 생기자 조이는 첫 번째 버클리 소프트웨어 배포판(1BSD)를 제작하여 1978년 3월 9일 처음으로 배포합니다. (1BSD는 유닉스 버전 6의 애드온 정도였으며 하나의 독립적이고 완전한 형태의 운영 체제가 아니었습니다.)\n2BSD는 1979년 5월 발매됩니다. 1BSD로부터 업데이트를 하였고 2개의 신규 프로그램을 포함하였습니다. 하나는 조이가 쓴 vi 텍스트 에디터이고 다른 하나는 C 쉘이었습니다.\n유닉스 전쟁 서막 유닉스를 만든건 AT\u0026amp;T였으나, 1980년대에 들어서자 캘리포니아 대학, 버클리 컴퓨터 시스템 연구소가 비상업적 유닉스 개발자들을 이끌고 있는 형국이 되었습니다.\n1984년, System V를 기준으로 만들고자 AT\u0026amp;T가 노력하던 시점에 일부 제조사들이 모여 X/Open Standard(X/열린 표준)를 구성하면서 본격적으로 갈등으로 전환됩니다. X/Open Standard는 유닉스의 통일성을 더욱 증대시키고자 BSD 유닉스의 리드 아래에 썬 마이크로시스템즈 등이 함께 통일된 시스템 구축을 위해 시작되었습니다. 문제는 현재까지 네트워크 기술의 기준으로 자리잡고 있는 TCP/IP등이 System V에서는 구현이 안되어 있었으나 BSD 4.2에는 이식되어 있었다는 점입니다.\n1985년, AT\u0026amp;T는 System V Interface Definition(SVID; 시스템 5 인터페이스 정의) 기준을 정립합니다. 그리고 다른 유닉스 기반 운영 체제들이 System V를 기준으로 브랜드화 하기를 요구합니다.\n1988년 IEEE는 POSIX 제원을 설립하여 BSD와 System V 플랫폼 간의 호환성을 위한 기준들을 규정합니다. POSIX는 미 정부에 의해 다양한 시스템의 기준으로 강제되었습니다. X/Open Standard에 썬 시스템(SUN Microsystems)이 참여했고, 썬 시스템의 라이선스가 두려웠던 일부 제조사들은 따로 모여 Open Software Foundation(OSF; 자유 소프트웨어 재단)을 설립합니다. 이에 뒤질세라 1988년 AT\u0026amp;T는 UNIX International(UI; 국제 유닉스)를 만듭니다. 그리고 AT\u0026amp;T는 썬과 협업을 불사하며 다른 배포 버전보다 앞서나가기 위해 공격적인 전략을 펼칩니다. (그런데 썬이 System V.4로 독자노선..)\n고소 이런 다툼이 1990년대까지 그대로 이어집니다. 그런데 BSD는 별 신경 쓰지 않고 본인들 운영 체제 개발에만 몰두합니다. 운영 체제를 POSIX 규격에 맞게 변형하기 시작하고 네트워크 관련 코드를 더 깔끔하게 정리합니다.\n그런데, 돈 실리, 마이크 카렐스, 빌 졸리츠, 트렌트 하인 등 BSD 개발자들이 캘리포니아 대학을 나와 버클리 소프트웨어 디자인(BSDi)를 설립합니다. BSDi는 인텔 플랫폼을 위해 제작된 BSD 유닉스의 상업 버전을 팔기 시작합니다. 이때, AT\u0026amp;T의 무료 코드인양 홍보를 합니다.\n1992년 결국, AT\u0026amp;T가 BSDi + 다른 BSD 관계자들을 고소합니다.\n캘리포니아 대학이 맞고소를 하였습니다.\n빌 졸리츠는 BSDi를 떠나 386BSD를 개발하고자 떠났고, 이 386BSD가 현재 FreeBSD, OpenBSD, NetBSD의 조상격입니다.\n1994년 1월 버클리 측의 판정승으로 소송이 종료됩니다. 합의 조건은 \u0026ldquo;AT\u0026amp;T측이 다가오는 4.4BSD 출시와 관련해 버클리측이나 사용자, 배포자들을 더 이상 고소하지 않을 것\u0026quot;입니다.\n리눅스 개발을 시작할 당시 386BSD가 있었다면 아마도 리눅스는 생겨나지 않았을지도 모릅니다. → Linus Torvalds, 1993\n결과 소송으로 인해 BSD의 개발 속도가 둔화되었음은 따로 설명하지 않아도 당연한 부분입니다. 거기에 그치지 않고 잠재적 소비자가 될 수 있었던 많은 고객들이 추가적인 소송에 직접 휘말리거나 별 의미 없는 피해를 볼 것이 두려워 많은 점유율을 확보하는데 실패하였습니다.\n리눅스는 종국에 x86 유닉스 시장을 차지할 궤도에 올랐다.\n… (중략) …\n가까운 미래에 NT 보다는 오히려 리눅스가 SCO의 가장 큰 위협이 될 것이라고 본다\n→ 마이크로소프트 기밀 메모, 1998\n와중에 1991년 라이너스 토르발즈라는 핀란드의 대학원생이 리눅스라는 커널을 개발하였습니다. 사용자들도 소송으로 시끄러운 BSD를 떠나 리눅스 커널을 들여다보기 시작합니다. 리눅스가 우연하다면 우연한 계기로 큰 부분을 점유하기 시작합니다.\nBSD 종류 개요 BSD는 리눅스 배포판들과는 다르게 하나의 운영 체제를 모두 제작합니다. 다시 말하면, 각종 소프트웨어 제작자의 패키지를 다운 받아 배포판 위에 설치할 수 있는 패키지 매니저를 제공하는 리눅스 배포판의 개념과 다릅니다. BSD는 설치할 수 있는 공식 레파지토리에 적극적인 검토 과정을 거쳐 안정적이라고 판단되는 패키지들을 모두 포함하여 배포됩니다. (슬랙웨어를 생각하시면 편합니다.)\nBSD \u0026lsquo;배포판\u0026rsquo;??\n사실, BSD 진영에서는 \u0026lsquo;배포판\u0026rsquo;이라는 말을 싫어합니다. 아래에서도 적었지만 BSD는 하나의 전체 운영 체제를 개발하여 배포하기 때문입니다. BSD 진영에서는 계속해서 \u0026lsquo;운영 체제\u0026rsquo;로 부를 것을 요구합니다.\nBSD 계열은 현재까지 명맥을 이어가는 배포판을 꼽아보면 굵직한 삼형제가 가장 유명합니다. FreeBSD, NetBSD, OpenBSD가 바로 그것입니다.\n삼형제로 갈라지게된 이유는 운영체제 개발의 목적이 달랐기 때문입니다. FreeBSD는 일반 사용자에게 적합한 BSD로 나아가고자 했고, NetBSD는 그 어떤 하드웨어에서도 실행 가능한 BSD로, OpenBSD는 호환성을 조금 포기하더라도 가장 안전한 BSD로 가고자 했습니다.\n시기상으론 NetBSD가 제일 먼저 386BSD로부터 포크되어 나왔습니다. 거의 동시에 FreeBSD가 386BSD의 느린 개발 속도에 불만을 품은 사용자들로부터 개발되었습니다. 조금의 시간이 지나고 Theo de Raadt가 NetBSD 개발진과의 목표, 의견차이를 좁히지 못하고 OpenBSD로 포크해 나옵니다.\n물론, 위의 3개의 배포판만 있는 것이 아니라 다양한 소규모 배포판이 있습니다. 예를 들어, DragonFlyBSD, GhostBSD, NomadBSD, FuryBSD 등입니다. 각각 일반 사용자 편이성 확대, 그래픽 환경 설치 편이성 확대, 보안을 위한 USB용 운영 체제, 일반 사용자 편이성 확대를 위해 제작되었습니다.\n그리고 각종 서버 특화 운영 체제를 개발할 때, 안정성에 방점을 찍는 BSD 계열을 적극적으로 활용합니다. 예를 들어, pfSense, TrueNas, OPNsense 등이 BSD 계열로부터 제작되었습니다.\n그러나 많은 분들이 불편해하시는대로 BSD는 일상용 운영 체제로는 극히 일부 결함이 있습니다. 현재로서 가장 대표적인 것은 DRM 지원 불가로 인한 넷플릭스 시청을 할 수 없다는 점 (정작 넷플릭스 서버 시설은 FreeBSD를 활용하는 것으로 잘 알려져있다고\u0026hellip;), 최신 출시 하드웨어 지원이 적다는 점 등이 있습니다.\n개인 의견 FreeBSD 패키지 관리자 명령어 \u0026lsquo;BSD는 실제 UNIX 계보이다\u0026rsquo;, \u0026lsquo;FreeBSD는 리눅스 배포판과 달리 전체 OS의 형태로 배포된다\u0026rsquo; 등의 자주 듣는 이유를 벗어나, FreeBSD의 패키지 관리 명령어가 말그대로 pkg라는 점에서 가장 큰 매력을 느꼈습니다. apt, apt-get, dnf, yum, emerge, pacman, xbps-install, eopkg, zypper, nixpkg, cards 등 결국 유사하거나 같은 기능을 하는 것들임에도 온갖 미사여구 스타일의 이름을 사용하는 것에 어느 순간 환멸이 들어, 가장 간단한 패키지 매니저 명령어를 찾는 것을 기준으로 배포판 옮겨다니기를 멈추기로 했습니다. (Alpine Linux의 apk도 고려해 볼만 합니다. 다만, 데스크탑 환경 운영체제로 사용하기에 아직 무리가 많아 보입니다. 컨테이너 이미지 용도로 자주 씁니다.) OpenBSD의 pkg_add 명령어도 좋지만, 한 술 더 뜨는 FreeBSD의 pkg명령어가 단연코 가장 아름답고 UNIX 철학에 부합한다고 생각합니다.\nNetBSD NetBSD가 필요 할만큼 다양한 하드웨어를 일반인이 접할 기회가 적어서, 굳이 오래 사용해본 적이 없습니다.\nOpenBSD 우선, 제가 기기를 운용하는 목적의 제 1 목표가 \u0026lsquo;보안\u0026rsquo;인 것은 아닙니다. OpenBSD는 보안적인 측면에서 강한 매력을 가진 것이 사실입니다. 추가적인 매력으로는 다른 모든 BSD 계열 혹은 리눅스 배포판들과 달리, 새로운 유저를 유입하기 위해 홍보를 하는데도 관심이 없고, 포럼 등에서도 유저들에게 친화적이기를 강제하지도 않습니다. 너무 단순하거나 쉬운 질문의 경우 드러내놓고 무시하는 경향이 보일 정도입니다.\n다시 말해서, OpenBSD는 철저히 관심사가 동일한 \u0026lsquo;괴짜(Geek)\u0026lsquo;들이 모여 개발하는 BSD 입니다. (그래서 NetBSD의 창립자 중 하나였던 De Raadt가 같은 창립자들의 마지막 결재 하에, 쫓겨났을지도; -94년 12월) 그러한 경향성의 문제로 ZFS 같은 혁신적인 파일시스템도 아직 포팅이 되지 않고 있습니다.\nZFS 포팅 관련해서는 내부적으로 다른 의견이 있습니다. 일부 리눅스 배포판에서도 겪고 있듯이, 인력 부족을 이유로 들기도 합니다. ZFS의 경우 엄청난 양의 소스 코드를 자랑하는데 이를 OpenBSD 기준의 코드 검사를 충족하려면 지금 공헌하는 인원수로는 엿부족인 것도 사실이긴 합니다.\n","permalink":"http://ptrtoj.com/kr/unix/","summary":"\u003ch2 id=\"서문\"\u003e서문\u003c/h2\u003e\n\u003cp\u003eUNIX 역사에 대해서는 따로 궁금하지 않으신 분들은 바로 ‘\u003ca href=\"http://ptrtoj.com/kr/distro/\"\u003e리눅스 배포판 종류\u003c/a\u003e’로 이동하시면 됩니다.\u003c/p\u003e\n\u003ch2 id=\"unix\"\u003eUNIX\u003c/h2\u003e\n\u003cp\u003eUNIX(이하 \u0026lsquo;유닉스\u0026rsquo;)의 역사를 설명하기 위해서는 1960년대 중반까지 거슬러 올라갑니다. 당시 MIT, AT\u0026amp;T의 벨 연구소, GE(제너럴 일렉트릭)은 GE-645 메인프레임에서 사용하기 위한 Multics(이하 \u0026lsquo;멀틱스\u0026rsquo;)라는 실험적인 시-분할 운영 체제(현대에 당연한 다중 동시 사용자, 멀티 태스킹이 가능한 운영 체제의 조상) 개발에 참여 중이었습니다. 멀틱스의 크기나 복잡도에 실망한 벨 연구소는 차츰 연구에서 손을 떼기 시작했습니다만, 마지막까지 연구에 관심을 갖던 켄 톰슨, 데니스 리치, 덕 매킬로이, 조 오산나는 그렇지 않았습니다. 넷은 시기적으로 일렀을 뿐이라는 판단 아래, 조금 더 작은 규모로 실험을 계속 해보고자 했습니다.\u003c/p\u003e","title":"유닉스 역사"},{"content":"서문 아치 리눅스를 써야 하는 이유가 무엇인지에 대한 질문이 등록되는 것을 자주 목격합니다. 저도 객관적으로 똑부러지게 \u0026lsquo;이런 점이 장점이고 이런 점은 약점이지만 이런 점에서 매력을 느낀다\u0026rsquo;라고 설명하지 못합니다 (물론, 제가 느끼는 강점과 매력은 분명하지만 이는 매우 주관적이기 때문입니다).\n하지만, 제가 명확히 알고 있고 여러분들께 소개해 드릴 수 있는 것은 \u0026lsquo;아치 리눅스의 설치 과정이 그렇게 당혹스러우리만큼 어렵지는 않다\u0026lsquo;라는 것입니다.\n일반적으로 윈도우 혹은 맥 진영에서 리눅스를 경험해 보고 싶은 신규 유저들에게 쉬운 배포판으로 우분투를 소개합니다. 충분히 이해할 수 있습니다. 설치 과정은 GUI로 표현되기 때문에 매우 편합니다. 하지만 그 과정들이 어떤 작업인지 이해하지 못하고 \u0026lsquo;Next\u0026rsquo; 만을 클릭하는 것을 \u0026lsquo;쉽다\u0026rsquo;고 표현하는게 올바른가에 대해서는 고민이 됩니다.\n아치 리눅스는 설치 과정이 커맨드 라인 기반(CLI)입니다. 모든 것을 키보드를 이용해 명령하여 설치해야 합니다. 하지만 그 과정 덕분에 리눅스가 어떻게 빌드되는지에 대해서 정확히 이해할 수 있고, 내 시스템이 어떻게 구성되어 있는지를 파악하기 유리합니다 (더 깊은 이해는 Gentoo, CRUX 혹은 LFS를 통해 성취할 수 있습니다).\n제가 처음 아치 리눅스에 관심을 가지게 되었을 때에도 설치 과정이 불편했습니다. 여기서, \u0026lsquo;불편했다\u0026rsquo;라는 것은 번역되어 있는 자료의 부재가 크게 작용했습니다. 영어로된 자료에만 의존해 설치해야 한다는 점이 힘들었습니다. 설치 당시 \u0026lsquo;한글로 된 양질의 자료가 필요하다\u0026rsquo;라고 절감했습니다.\n한글 아치 리눅스 위키 페이지의 설치 가이드를 추천하실지 모르겠습니다. 매우 훌륭하게 정리되어있고, 아래에서 소개할 설치 과정도 그 페이지를 기반으로 합니다. 다만, 초급 사용자가 사용하는 데에 있어서도 그 페이지로 충분하다는 데에는 동의할 수가 없었습니다. 저는 아치 리눅스가 한국에서 더욱 확산되고, 특히 \u0026lsquo;초보 사용자의 설치 환경에 큰 도움을 주고 싶다\u0026lsquo;라는 데에 방점을 찍었습니다.\nKISS, 즉, Keep it Simple, Stupid! 이것은 유닉스 계열의 정통 철학일 뿐만 아니라 아치 리눅스 진영에서도 핵심적으로 추구하는 철학입니다. 아치 리눅스는 단순함을 추구합니다. 흥미로운 점은 그 단순함을 위해서 얼마나 많은 복잡함을 응축해야 하는가 입니다. 우측의 스크롤 바를 보시면 당황스러우실 수 있습니다. \u0026lsquo;초보자를 위해 글을 작성했다고 제창하면서 얼마나 자세히 적어두고 있는거냐\u0026rsquo;라고 반문하실 수도 있습니다.\n반전은 이 스크롤 바를 읽어 내려가면서 직접 설치해야 하는 패키지의 수는 오히려 5개로 단순화했다는 점입니다. 물론 이는 수동으로 입력하여 설치하는 패키지(dependency 제외)를 뜻합니다. 그 5가지는 base, xorg-wayland, gnome, google-chrome, ibus-hangul입니다.\n보신 바와 같이 그 5개의 패키지 중에서도 한 개는 실제 사용에 필수가 아니지만, 여러분들이 아치 리눅스를 사용하는데 유용할만한 지식(AUR 사용법)까지 전달 드리기 위해 설치하는 것(google-chrome)입니다.\n이 한 페이지를 통해 독자분들은 기본 시스템 구축과 관련된 분야(파티션, 포맷, 파일시스템 테이블, 부팅 과정과 부트 로더의 역할), 데스크탑 환경 구축, 웹 브라우저 설치 과정을 통한 AUR 학습 그리고 아치 리눅스에서 한글을 사용하는 것이 얼마나 쉬운지 느끼실 수 있습니다.\n그 단순함을 성취하기 위해 모순적이게도 오히려 상당히 많은 내용을 담을 수 밖에 없었습니다.\n설치 전 주의 사항 공식 아치 리눅스 설치 가이드는 단 한 가지 버전만 존재합니다.\n그 외 모든 가이드는, 이 페이지를 포함, 특정 목적(사용자 편의/작성자 편의/강의 목적)을 위해 편집된 내용입니다. 그러므로, 우선 공식 위키의 내용을 이해한 후, 이 가이드를 보면서 입맛에 맞게 수정/적용하시는 것을 권장하는 바입니다.\n본 글에서 설명드리는 내용을 모두 이해하신 분들은 2021년 4월 1일부터 Arch Install이라는 이름으로 배포되는 설치 도움 프로그램을 활용하셔서 전보다 수월히 설치하실 수도 있습니다!\n설치 준비 설치 이미지 파일(iso) 다운로드 방법은 아래와 같습니다. (참조: 카이스트 미러)\n카이스트 미러 접속 \u0026gt; 목록 중 \u0026gt; archlinux-YYYY.MM.DD-x86_64.iso 를 클릭하여 다운로드 Windows에서 Rufus를 이용해 제작합니다. 자세한 내용은 생략합니다.\nLinux에서 리눅스 시스템에서 USB 마운트 이후, 아래의 명령을 실행합니다.\n# lsblk 명령어 설명\nlsblk: list block device → 블록 디바이스 목록을 출력합니다.\n결과 출력을 통해 내 USB 디바이스 장치명을 확인합니다.\n보통, 용량을 통해서 확인합니다. sdb, sdc처럼 사용자에 따라 다른 이름이 표시됩니다.\n아래 명령어를 통해 USB를 포맷하고 새로운 iso를 작성할 준비를 합니다.\n주어진 예시 명령어의 /dev/sdb에서 sdb부분을 본인 환경에 맞게 입력해야 합니다. 위에서 확인한 본인 USB 장치의 이름을 넣어줍니다.\n아래 명령어는 USB 내부의 모든 파일을 삭제합니다.\n중요한 파일이나 삭제가 용인되지 않는 파일은 반드시 백업을 하시고 진행하시길 바랍니다.\n# sudo wipefs --all /dev/sdb 아래 명령어를 통해 준비된 USB에 iso 파일을 구워줍니다.\nif 이후에 (iso 파일 다운로드 위치)/archlinux-(날짜)-x86_64.iso를 본인 환경에 맞게 입력합니다.\n해당 경로에 아치 리눅스 iso 파일이 하나밖에 없다고 가정할 경우, archli와 같이 앞 부분을 입력한 후, Tab 키를 이용해 자동 완성이 가능합니다.\n다만, Enter 입력 전에 반드시 자동 완성된 파일 이름이 원하는 결과로 입력되었는지 확인하시기 바랍니다.\n아래 명령어에서 of부분 이후에는 위에서 준비한 USB 경로를 본인 환경에 맞는 것을 입력합니다.\n# sudo dd bs=4M if=~/Downloads/archlinux.iso of=/dev/sdb status=progress \u0026amp;\u0026amp; sync 명령어 설명\ndd: dd라는 이름의 프로그램을 이용합니다. (과거 UNIX 시절에는 ‘잘못 사용하면 디스크를 사용 불가능하게 만드는 프로그램’이라는 의미로 \u0026lsquo;Disk Destroyer\u0026rsquo;라는 별명이 있었습니다.) bs(block size): 블락 크기는 4M (생략 가능) if(input file): 인풋 파일 (지금은 아치 리눅스 iso 파일) of(output file): 작성할 대상인 아웃풋 디바이스의 경로 이제 재부팅해줍니다.\n재부팅 도중에 본인 메인 보드에 맞는 바이오스/UEFI진입 키를 이용합니다. 제 경우는 F2 입니다. 보통은 F2, F10, F11, Del 등입니다.\n바이오스/UEFI 진입 키를 통해 부팅 할 미디어 중, 방금 제작한 USB를 찾아 선택합니다.\n이 USB를 통해 정상적으로 부팅이 이루어지면 리눅스 부팅 중과 부팅 후의 선택 화면에서는 일반적으로 디폴트 값으로 가리키고 있는 것을 통해 부팅하시면 됩니다 (Boot Arch Linux혹은 x86_64같은 것이 포함되어 있음).\n또, 키 맵을 선택하라는 알림이 등장할 수도 있는데 디폴트가 US로 선택되어 있는 경우가 많으므로 그냥 Enter를 입력하시면 됩니다.\n설치 미디어 USB 부팅 자체가 안되는 경우!\n설치화면 진입 자체가 안되는 문제는 BIOS/UEFI 세팅 문제일 가능성이 큽니다.\nsecure boot가 사용 안함(Disabled)으로 되어있는지 확인하시기 바랍니다.\nfast boot, 혹은 CSM 모드(LEGACY/BIOS MODE)에서 발생하는 오류일 수도 있습니다.\n추천드리는 것은 모두 사용 안함(Disabled)입니다.\n베이스 시스템 설치 UEFI 여부 확인 우선, UEFI로 설치해야 하는지 그리고 UEFI로 설치가 가능한지 확인하도록 하겠습니다.\n아래 파티션 계획 파트에서 다시 말씀드리겠지만, UEFI로 부팅된 것이 맞고 UEFI로 설치할 생각인 경우의 파티션과 그렇지 않은(BIOS로 부팅된 경우) 파티션이 다릅니다.\nUEFI의 경우, 권장 설치 설정은 디스크 타입을 GPT로 그리고 반드시 ESP 파티션을 가질 것을 요구합니다.\n이 가이드는 대부분의 일반 사용자 부팅 환경이 UEFI이므로 UEFI 설치용 파티션만을 설명합니다.\n확인은 아래 명령어를 통해 할 수 있습니다.\n# ls /sys/firmware/efi 명령어 설명\nls: list. 주어지는 경로(/sys/firmware/efi) 내부 파일들을 보여줌\n결과에 efivars라는 디렉터리가 보이면 UEFI로 설치하실 수 있습니다.\n인터넷 연결 확인 인터넷 연결 상태를 확인합니다.\n# ping -c 3 www.google.com 명령어 설명\nping 명령어를 통해 뒤에 명시된 서버에 핑을 보냅니다. c이후의 숫자 3을 다른 숫자로 변경해 사용하셔도 무방합니다. c옵션을 안 넣었거나 숫자를 빼먹어서 ping이 계속 실행될 경우 당황하지 마시고, ctrl + c(SIGINT; 시스템 인터럽트 시그널)를 이용해 작동을 중단하실 수 있습니다! 무선 환경의 경우, 아치 리눅스 설치 프로그램은 iwctl 유틸리티를 동봉합니다.\n# iwctl [iwd]#device list // 본인 디바이스명 확인 [iwd]#station YOUR_DEVICE scan [iwd]#station YOUR_DEVICE get-networks // 공개 네트워크(비밀번호 없음)의 경우 [iwd]#station station YOUR_DEVICE connect NETWORK_SSID // 비밀번호 아는 비공개 네트워크의 경우 \u0026#39;ctrl+d\u0026#39;로 나와서 # iwctl --passphrase NETWORK_PASSWD station YOUR_DEVICE connect NETWORK_SSID 위 과정을 통해, 네트워크에 연결된 이후, 제대로 작동하는지 ping으로 연결 상태를 확인합니다.\n파티션 계획 이 과정은 드라이브 구획을 나누고 계획을 잡아두는 것으로 그 계획에 맞는 포맷은 다음 단계에서 진행 됩니다.\n파티션은 대용량 저장 장치를 어떤 구획으로 나누어 사용할지에 대해서 정하는 순서입니다.\n일반적으로는 세 파트로 나눕니다.\n각각 부팅을 위한 구획, 데이터들이 저장될 구획, 그리고 리눅스 스왑으로 쓸 구획입니다.\n가장 먼저, 부팅을 위한 파티션 관련해서 UEFI로 부팅했고, 설치하려는 경우 ESP로 불리는 EFI System Partition을 계획해야 합니다. ESP를 계획하지 않으면 UEFI 환경에서 부팅을 설정해주는 것이 굉장히 까다로워집니다.\nESP는 ‘타입: EFI System Partition’으로 설정되어 있고 ‘포맷: FAT 파일 시스템’으로 된 파티션입니다. ESP는 /boot디렉터리에 마운트 됩니다.\n더 깊이 관심 있으신 분들은 /boot에 마운트 하는 것과 /efi에 마운트 하는 것 간에 어떤 차이가 있는지 검색해보시면 좋습니다[읽을거리].\n두 번째 구획인 데이터 저장 구획은 단순하게 Linux File System이라는 타입으로 사용할 예정입니다. 이 두 번째 파티션은 /, 즉 root 디렉토리에 마운트 되어 모든 데이터가 저장될 구역이라고 생각하시면 됩니다.\n마지막 스왑 파티션은 이름처럼 Linux Swap이라는 타입을 붙이면 되겠습니다.\n(본인 사용 환경, 혹은 입맛에 맞게 추가적인 파티션을 계획하셔도 좋습니다. 별개로 계획된 /home 등)\nSWAP 굳이 필요? 사이즈 굳이 그만큼?\n리눅스 스왑이란 램 환경이 모자랄 때 하드디스크의 스왑으로 설정된 부분에 자료를 로드해두고 램처럼 활용하는 것을 의미합니다.\n일부 사용자는 \u0026ldquo;스왑이 사용되는 순간부터 이미 램이 모자란 것과 같은 것이므로 스왑을 쓰기보다는 차라리 하드웨어를 업그레이드 하겠다\u0026quot;라고 하며 스왑을 사용하지 않는 경우도 있습니다.\nLFS 유저들 중 이런 견해가 많이 보입니다. 공식 매뉴얼에서도 이렇게 기재해두었습니다. LFS 공식 매뉴얼 \u0026gt; 2.4.1.2. The Swap Partition \u0026gt; “Swapping is never good. (이하 생략)”\n반대로, 4G 넘는 램을 갖고 있더라도 시스템에서는 실제 램 사이즈와 관계없이 4G 정도의 스왑을 구획하는 경우도 많습니다.\nhibernation (노트북 등의 장치에서 덮개를 닫아 수면 상태로 보내는 것) 등의 기능을 위해 램 사이즈 만큼의 스왑 파티션을 꼭 챙겨야 한다는 의견도 있습니다.\n이 문서에서는 가장 널리 쓰이는 설정대로 진행합니다.\n아래 명령어를 통해 내 드라이브로 어떤 것들이 있는지 확인해보겠습니다.\n# lsblk 결과 출력에 sda, sdb 혹은 hda와 같은 대용량 저장 장치가 보이실 겁니다.\n대용량 장치가 여러 개일 경우 sda,sdb,sdc순으로 출력 됩니다.\nhda는 기존의 IDE 방식 커넥션으로 연결된 하드디스크, sda는 최근 SCSI/SATA방식으로 연결된 HDD 혹은 SSD입니다.\n부팅을 위해 마운트한 USB가 아닌지 확실히 확인하셔야 합니다. 확인은 보통 용량으로 하면 큰 문제가 없습니다.\n가장 일반적인 sda라고 가정하고 계획을 잡아보겠습니다.\n이번 설치 과정에서는 총 세 구획으로 쪼개려고 합니다.\n쪼개고 나면 sda1,sda2,sda3으로 나누어집니다.\n만약 sdb였다고 하면 sdb1,sdb2,sdb3이 되겠죠?\n보통 /dev/sda1, /dev/sda2처럼 경로명을 표기하는데 앞의 dev는 \u0026lsquo;device\u0026rsquo;를 뜻합니다.\n아래처럼 계획을 잡아보겠습니다.\n계획은 사람마다 다를 수 있지만 본인 파티션의 몇 번째가 어떤 것으로 쓰일지 제대로 기억하고 계셔야 합니다. 특히,부팅 파티션/스왑 파티션/루트 파티션으로 정확히 개념을 잡고 그게 각각 1,2,3 중에 어느 것으로 쓰일 것인지 기억하시고 아래 예제를 따라오셔야 합니다.\n적용 파티션 타입 코드명 사이즈 용도 /dev/sda1 EFI System Partition EF00 512M ESP(/boot) /dev/sda2 Linux Swap 8200(82) 4G 스왑파티션(swap) /dev/sda3 Linux FileSystem 8300(83) 나머지 용량 루트파티션(/) 파티션 사이즈?\nESP, 흔히 말하는 \u0026lsquo;부트 디렉터리\u0026rsquo;에 마운트 시킬 파티션 용량 그리고 스왑 용량 관련해서 정답도 없고, 추천하는 크기도 다 다르다는 점은 충분히 알고 있습니다. 다만 초보자의 관점에서 혼란스러움 없이 진행하기 위해서 우선은 위와 같이 가장 기본이라고 할 수 있는 용량으로 진행해 보도록 하겠습니다. 설치를 하고 계시는 여러분이 이미 각종 고급 설정에 익숙하시면 충분히 수정해서 설치하셔도 됩니다.\ncfdisk (gdisk 활용 파트 삭제하였음. cfdisk가 아닌 다른 프로그램을 활용하실 분들은 별도 문서를 참조하시기 바랍니다.)\n아래 명령어들은 하드디스크 내부의 모든 파일을 사용할 수 없게 만듭니다. 중요한 파일이나 삭제가 용인되지 않는 파일은 반드시 백업을 하시고 진행하시길 바랍니다.\n아래 명령어에 디스크 경로가 포함되는데 본인 환경에 맞는 것을 입력하시면 됩니다.\n# cfdisk /dev/sda UEFI 설치를 위해서는 라벨이 GPT라고 상단에 표기 있는지 확인합니다. MBR 혹은 DOS가 아니어야 합니다!\n만약 처음에 물어보면 GPT를 선택해주시면 됩니다.\n물어보는 경우, Primary로 진행합니다.\n표에 이미 있는 파티션이 출력되는 경우, 기존 파티션들을 한 줄씩 내려가면서 DELETE해줍니다. (키보드의 화살표 방향키를 이용합니다.)\n그리고 나서 모든 용량이 FREE SPACE가 되면 계획한 파티션을 만들겠습니다.\n처음 만들 파티션은 /dev/sda1, EFI System Partition, 512MB입니다.\n따라서,\nNEW 선택(Enter) 용량 크기를 입력: 512M 물어보는 경우, 앞으로 생성할 모든 파티션도 마찬가지로: Primary 선택 우측 방향키를 통해 TYPE으로 커서를 옮긴 후: Enter 보통 맨 위에 있는: EFI System을 선택 두번째 만들 파티션은 /dev/sda2, Linux swap, 4GB였습니다.\n방향키를 아래로 내려서 free space를 향하게 하면 아래에 NEW 버튼이 다시 활성화된 것을 볼 수 있습니다.\nNEW 용량 크기를 입력: 4G TYPE: Linux Swap 찾아서 선택 이제 /dev/sda3도 만들어보겠습니다.\nNEW 용량 크기는 디폴트로 출력되는 크기가 남아있어야 할 최대 용량인지 확인하고: Enter TYPE도 새로 선택할 필요 없이 아마 자동으로 Linux FileSystem일텐데 혹시 모르니 다시 표에서 확인해주시면 됩니다. 마지막으로 WRITE를 선택하시면 됩니다. QUIT 선택해서 나옴. 계획대로 작성되었으니 저장한다는 개념으로 WRITE 해주고 나오겠습니다.\n방향키를 이용해 WRITE로 이동, ENTER로 선택 QUIT 선택해서 나옴 이제 포맷 단계로 진행하시면 됩니다!!\n포맷 포맷은 파티션 각각의 계획에 맞는 파일 시스템으로 진행합니다.\nUEFI환경에서 ESP, 즉 부팅 파티션은 FAT32 파일 시스템을 원합니다. 따라서 아까 EFI시스템으로 파티션을 계획했던 sda1은 fat32로 포맷을 할 것이고, 기본 파일 시스템으로 쓰기로 했던 sda3는 가장 범용으로 쓰이는 ext4파일 시스템으로 포맷 하겠습니다.\n스왑 파티션은 다음 단계에서 포맷 합니다.\n/dev/sda2를 포맷하지 않도록 주의해주세요!\nvfat은 512MB를 잡았으니 금방 되고 ext4로 포맷 예정인 sda3는 본인이 부여한 용량에 따라 시간이 잠깐 소요되는 것이 정상입니다.\n아래 명령어에 디스크 경로가 포함되는데 본인 환경에 맞는 것을 입력하시면 됩니다.\n# mkfs.vfat -F32 /dev/sda1 # mkfs.ext4 -j /dev/sda3 명령어 설명\nmkfs: MaKe File System\n스왑 스왑 드라이브를 만들겠습니다.\n스왑 드라이브는 위에서와 같은 포맷 과정을 수행하고나서 켜주는 과정을 추가로 거칩니다.\n아래 명령어에 디스크 경로가 포함되는데 본인 환경에 맞는 것을 입력하시면 됩니다.\n# mkswap /dev/sda2 # swapon /dev/sda2 명령어 설명\nmkswap: MaKe Swap\n마운트 마운트는 리눅스 파일 체계 (/(루트 디렉토리)로부터 뻗어나오는 파일 트리) 각각의 디렉터리에 어떤 드라이브의 어떤 파티션을 이용하겠다고 연결하는 거구나 생각하시면 편합니다.\n이 가이드에서 소개한 계획을 따라하고 계시다면 루트 디렉터리(/)와 루트 아래의 부트 디렉터리(/boot)만 마운트하면 됩니다.\n당연한 얘기지만 /boot는 / 하위 디렉터리로 존재하는만큼, 파티션 계획에서는 3번째였던 / 파티션부터 마운트해야 정상적으로 /boot 디렉터리를 만들어 드라이브를 마운트할 수 있습니다. 아래 가이드는 이 시나리오를 기반으로 작성되어 있으니 걱정하지 않고 무작정 따라하셔도 정상 작동하긴 합니다.\n별도로 각자 파티선 계획 단계에서 구상한 계획에 따라 홈 디렉터리(/home)등을 따로 하나의 드라이브(예를 들어, /dev/sda4)로 마운트 하는 것도 당연히 가능합니다.\n설치 중의 /mnt이하 디렉터리 구조들이, 설치를 완료하고 재부팅하면 그대로 /이하 디렉터리 구조가 됩니다.\n설치용 USB의 역할\n/mnt 아래에 새로운 시스템 디렉토리들을 모두 마운트하거나 생성하고, 반드시 필요한 소프트웨어를 설치한 다음(pacstrap), 해당 시스템 내부로 진입합니다(chroot).\n다시 말해서, 설치 프로그램이 하는 역할은 라이브 리눅스 시스템을 제공하여 /mnt 아래에 또 다른 새로운 리눅스 환경을 만들 수 있는 도구를 제공하는 것 이상도 이하도 아닙니다.\n바로 이 점을 이용해, A 리눅스 iso 혹은 라이브 USB를 통해, B 리눅스 배포판을 설치하는게 가능한 것이죠!\n우선은 /mnt에 루트 디렉터리로서 쓸 Linux FileSystem 파티션(/dev/sda3)을 연결해보겠습니다.\n아래 명령어에 디스크 경로가 포함되는데 본인 환경에 맞는 것을 입력하시면 됩니다.\n# mount /dev/sda3 /mnt 이렇게 하고 나면 /mnt는 설치 완료 후 재부팅하면 /가 됩니다.\n그리고 나서 /mnt 아래에 부트 디렉터리를 만들어 줍니다.\n# mkdir /mnt/boot 명령어 설명\nmkdir: MaKe Directory\n마운트 하기 위해 미리 만들었던 /dev/sda1를 /mnt/boot에 마운트 해줍니다.\n# mount /dev/sda1 /mnt/boot 시간 설정 #timedatectl set-ntp true명령어를 통해 서버 시간과 동기화할 수 있습니다. 특히, 윈도우즈를 쓰던 컴퓨터에서 처음 리눅스를 설치할 때는 사용하는 시간 기준이 각각 localtime과 UTC 기반으로 다르기 때문에 꼭 수행하는 것을 추천합니다.\n더 고전적인 방법은 #date 명령어를 통해 직접 현재 적절한 시간을 입력하는 것입니다. 휴대폰 등의 별도 디바이스를 통해 구글에 \u0026lsquo;current utc time\u0026rsquo;을 검색해 현재 UTC 시간을 확인합니다. #date 명령어로 확인한 시간을 입력합니다. 순서는 \u0026lsquo;월일시분년\u0026rsquo; 입니다. 예를 들어, 2021년 12월 31일 14시 56분은 #date 123114562021로 입력합니다. 이 방법을 알아두는 것이 쓸모 없어 보일지도 모르지만 #timedatectl과 같은 명령어는 init 시스템으로 systemd를 지원해야만 가지고 있는 명령어입니다(물론 배포판 열에 아홉은 systemd이긴 함..). 따라서, 다른 방법도 알아두시면 혹시나 모를 상황에 도움이 될 수 있습니다.\n위 과정이 너무 귀찮거나 네트워크를 통해 자동으로 시간을 동기화 하는 것에 거리낌이 없으시다면 #ntpd -q -g를 통해서 생략 가능합니다. 서버 시간 자동 동기화는 ntp 서버에 내 기기의 IP가 드러난다는 점 등 개인 정보에 예민한 분들은 선호하지 않습니다. 그리고 아치 리눅스 설치 iso에는 ntp가 동봉 되지 않습니다. 이 방법으로 진행하실 분들은 #pacman -Syu이후, #pacman -S ntp를 통해 ntp패키지를 설치하시고 사용하시면 됩니다.\n// 편한 방법 하나를 선택 # timedatectl set-ntp true # 혹은 # date 123114562021 # 혹은 ntp를 설치해 # ntpd -q -g 시간을 맞춘다음, 아래 명령어를 통해 하드웨어 시간도 시스템 시간과 동기화해줍니다.\n# hwclock --systohc --utc 명령어 설명\n하드웨어 클락을 utc 기준인 현재 시스템 클락과 동기화함\nsystohc: 시스템 시간(system time)을(to) 하드웨어 시간(hardware clock)으로 utc: 로컬타임(localtime)을 기준으로 하지 않고 utc를 기준으로 함을 명시 hctosys: 하드웨어시간을 시스템 시간으로 밀어내기도 합니다. mirrorlist 기존 가이드의 내용대로 진행하셔도 됩니다만 최근 iso들은 네트워크가 연결된 상태에서 이미 적당한 mirrorlist를 작성해줍니다. 따라서 별도 수정 필요 없이 그냥 사용하셔도 무방한 것으로 확인됩니다.\n여기도 도움이 될 추가 정보가 있으니 한 번쯤 읽어보셔도 좋고, 그냥 넘어가실 분들은 한 챕터 아래인 pacstrap 항목부터 이어가시면 됩니다.\n미러 리스트는 아치에서 패키지 설치를 할 때 기본 데이터 베이스로 활용할 서버를 나열해 놓은 리스트입니다. 미러 리스트에 적힌, 사용할 서버가 가깝거나, 속도가 가장 빠르게 접속 되는 것으로 나열되어야 설치/사용 환경에서 유리합니다.\n따라서, 수정해 보도록 하겠습니다. nano 에디터를 사용해서 파일을 열겠습니다.\n// 기존 파일 백업은 필수 # cd /etc/pacman.d # cp mirrorlist mirrorlist.bak // 수정하기 위해 파일 열기 # nano -w /etc/pacman.d/mirrorlist 다 지우고 적으실 분들은 지우기 시작할 라인으로 커서를 옮기신 이후, Alt+Shift+T를 하시면 맨 끝줄까지 삭제됩니다.\n아치 리눅스 미러리스트 페이지에서 생성된 결과입니다.\n## ## Arch Linux repository mirrorlist ## Generated on 2024-01-11 ## ## South Korea Server = http://kr.mirrors.cicku.me/archlinux/$repo/os/$arch Server = https://kr.mirrors.cicku.me/archlinux/$repo/os/$arch Server = http://ftp.kaist.ac.kr/ArchLinux/$repo/os/$arch Server = http://mirror.funami.tech/arch/$repo/os/$arch Server = https://mirror.funami.tech/arch/$repo/os/$arch Server = https://seoul.mirror.pkgbuild.com/$repo/os/$arch Server = http://ftp.harukasan.org/archlinux/$repo/os/$arch Server = https://ftp.harukasan.org/archlinux/$repo/os/$arch Server = http://ftp.lanet.kr/pub/archlinux/$repo/os/$arch Server = https://ftp.lanet.kr/pub/archlinux/$repo/os/$arch Server = http://mirror.morgan.kr/archlinux/$repo/os/$arch Server = https://mirror.morgan.kr/archlinux/$repo/os/$arch Server = http://mirror.premi.st/archlinux/$repo/os/$arch Server = https://mirror.premi.st/archlinux/$repo/os/$arch Server = http://mirror.siwoo.org/archlinux/$repo/os/$arch Server = https://mirror.siwoo.org/archlinux/$repo/os/$arch Server = http://mirror.yuki.net.uk/archlinux/$repo/os/$arch Server = https://mirror.yuki.net.uk/archlinux/$repo/os/$arch nano 편집기를 사용하여 편집 후 저장하고 나오는 방법\nCtrl+X→y→Enter\nctrl+x : 종료 그리고 묻는 것: 수정된 사항이 있는데 수정하십니까? y 파일 명은 뭐로 합니까? (디폴트 값은 원래 파일명으로 되어 있으므로) Enter vim 편집기를 사용하여 편집 후 저장하고 나오는 방법\nEsc→:wq→Enter\nesc를 이용해 insert모드(입력 모드)에서 normal모드(일반 모드)로 나옵니다. :를 이용하여 명령어를 입력할 준비를 합니다. 화면 하단에 콜론이 입력된 것을 확인하실 수 있습니다. write, quit reflector가 뭔지 알고 어떻게 사용하는지 익숙하신 분들은 지금 단계에서 설치해서 속도(--rate)와 국가 코드(KR)에 따라, 혹은 본인 환경에 맞게 새로 작성하셔도 무방합니다. 뿐만 아니라, 설치하신 경우 systemd 서비스를 통해 부팅시마다 미러 리스트를 업데이트하도록 설정할 수도 있습니다. 원하시는 옵션을/etc/xdg/reflector/reflector.conf에 미리 적어두신 후,# systemctl enable reflector.service를 통해 켜줍니다.\npacstrap 이제 pacstrap 명령어를 통해 새로운 시스템이 될 /mnt에 필수 프로그램들을 설치합니다.\n반드시 설치해야 하는 것들을 포함하는 명령어는 아래와 같습니다만 명령어 아래 단락을 꼭 확인하시기 바랍니다!\n# pacstrap /mnt base linux linux-firmware networkmanager 추가적으로 아래 항목들은 위 linux-firmware 뒤에 추가할만한 것들입니다.\n예상하기로 여러분께 가장 필요할 것으로 생각되는 패키지부터 아마도 필요하지 않을 것 같은 패키지 순서로 나열합니다.\n# 에디터 프로그램 하나 이상 nano vim emacs # 대부분의 사용자에게 필요 base-devel man-db man-pages # 여기서부터는 무슨 패키지인지 모르시겠다면 불필요한 것입니다. # 하지만 본인 부팅 환경에 필요하다면 설치하시면 됩니다. # 물론, arch-chroot 이후 pacman으로도 설치 가능 mdadm lvm2 base 패키지 목록과 base-devel 패키지 목록은 링크에서 확인하시기 바랍니다.\ngenfstab /etc/fstab은 부팅할 때 어느 디렉토리에 어느 드라이브가 마운트 되야 하는지를 시스템이 알게 해주는 파일 시스템 테이블(File System Table) 파일입니다.\n아래 작업은 genfstab이라는 스크립트를 활용해 그 파일 시스템 테이블 파일(/etc/fstab)을 자동으로 생성하는 작업입니다. (Gentoo, LFS 등 더 귀찮은 수작업 시스템은 genfstab과 같은 유틸리티를 제공하지 않아 손으로 작성합니다.)\n# genfstab -U /mnt \u0026gt;\u0026gt; /mnt/etc/fstab 명령어 설명\ngenfstab : generate File System table U : U는 대문자(UUID로 작성하겠다는 의미, 검색: UUID vs PARTUUID) 현재 /mnt 아래 마운트 된 드라이브들을 그대로 \u0026gt;\u0026gt;: 뒤에 나오는 파일명에 추가로 작성(Append). 부등호를 한개만 사용하면(\u0026gt;) Overwrite 명령이 되어 파일이 이미 존재하더라도 내용을 지우고 새로 작성됩니다. /mnt/etc/fstab: 내용이 담길 파일명 # cat /mnt/etc/fstab 명령어를 통해서 어떤 내용이 적힌 건지 확인해 보실 수도 있습니다.\n명령어 설명\ncat: concatenate의 줄임\n인자로 주어지는 파일의 내용을 보이거나, 파이프(|→Shift+\\)를 활용해 다른 파일에 입력할 때 자주 활용합니다.)\n아치 리눅스 진입 루트 진입 # arch-chroot /mnt 명령어 설명 arch-chroot: arch-change root, /mnt를 /로 가정하는 환경으로 진입합니다.\n설치될 시스템 내부로 들어왔습니다! 추가적인 시스템 세팅을 진행하도록 하겠습니다.\n여기에서 추후 사용할 소프트웨어를 설치하시면 나중에 재부팅 후에도 설치된 채로 남아있습니다. 예를 들자면, vim 에디터를 사용하실 분들은 # pacman -Syu 이후, # pacman -S vim 명령어를 통해 설치하셔도 재부팅 이후, 아치 환경으로 부팅했을 때 해당 패키지가 설치되어 있습니다.\n설치 완료 후, 부팅이 안되는 경우 # arch-chroot /mnt를 활용해 오류 수정할 수 있습니다.\n설치 완료 후, 재부팅 해봤는데 문제가 있다. 다시 Live USB로 부팅 # mount -v -t ext4 /dev/sda3 /mnt /mnt에 마운트된 /dev/sda3에 디렉터리 구조가 정상적으로 존재하는지 확인 # ls /mnt 정상이면 (필요한 경우) 나머지 드라이브도 마저 마운트 # mount -v -t vfat /dev/sda1 /mnt/boot 다시 시스템 내부로 진입 # arch-chroot /mnt 필요한 보수 작업 실행 설치 완료 과정과 동일하게 빠져나오기 # cd # umount -lR /mnt # reboot 인터넷 확인 # ping -c 3 www.google.com 비밀번호 설정 # passwd 타이핑하시는 \u0026lsquo;설정할 비밀번호\u0026rsquo;는 원래 화면에 안보입니다. 놀라지 마세요!!\n확인차 총 두 번 입력하는게 맞습니다. 놀라지 마세요!!\n언어 생성 # nano -w /etc/locale.gen 파일이 뜨면 화살표 키를 이용해 아래로 내려가 en_US.UTF-8을 찾습니다. (vim 사용자 → /en_US.UTF, Enter, 찾는 부분 나올 때 까지 n, 해당 줄의 주석에서 x)\n앞의 주석(#)만 제거해주세요.\n/etc/locale.gen은 어떤 언어 시스템을 생성할지 결정합니다. 즉, 여기서 en_US.UTF-8과 ko_KR.UTF-8을 주석 해제 해 두어야 아래에서 locale.conf에 둘 중 어느 하나를 골라 적더라도 실제로 사용할 수 있습니다.\nko_KR.UTF-8을 사용하지 않으실 분들은 en_US.UTF-8만 주석 해제 하시고 생성하시면 됩니다.\n설정 파일대로 생성을 합니다.\n# locale-gen 언어 설정 locale.conf파일은 시스템 전반의 언어를 관리하는 파일입니다. 여기에 지금 en_US.UTF-8을 적어넣을텐데, 한글 디렉토리명, 터미널에서의 한글 오류 등을 선호하시는 분들은 ko_KR.UTF-8을 입력해주시면 됩니다.\n# echo LANG=en_US.UTF-8 \u0026gt; /etc/locale.conf 명령어 설명\necho 와 \u0026gt; 는 LANG=en_US.UTF-8 이라는 문장을 그대로 /etc/locale.conf 파일에 덮어 씌우겠다 라는 뜻입니다. 파일이 없을 경우 파일이 생성됩니다. \u0026gt;\u0026gt;를 이용해 기존 내용은 그대로 두고 추가할 수도 있습니다.\n이전처럼 이부분도 # nano -w /etc/locale.conf 혹은 # cat /etc/locale.conf 통해 확인해 보실수 있습니다.\n위 명령어와 다르게 # localectl set-locale LANG=en_US.UTF-8 과 같이 적용하는 방법도 있습니다. 이는 systemd init system에서만 사용 가능한 방법이므로 다양한 시스템을 활용하시는 분들은 원 글에 설명 드린 명령어를 활용하시면 더 유익할 것으로 생각합니다.\n(생략 무방) 아래의 명령어로 현재 진행하고 있는 쉘 환경에서의 언어도 en_US.UTF-8이라고 선언합니다.\n# export LANG=en_US.UTF-8 호스트네임 설정 아래 명령어로 원하는 호스트명, 즉, PC 이름을 설정\n# echo YOURHOSTNAME\u0026gt; /etc/hostname 로컬타임 설정 위에서 시간을 UTC 기준으로 맞춰뒀으니 이제 한국 시간으로 맞춥니다.\n# ln -sf /usr/share/zoneinfo/Asia/Seoul /etc/localtime 명령어 설명\nln: link 옵션 -s: symbolic -f: force /etc/localtime을 /usr/share/zoneinfo/Asia/Seoul에 링크 앞으로/etc/localtime을 참조할 때 실제론 /usr/share/zoneinfo/Asia/Seoul를 향하도록 해주는 작업입니다.\n리눅스에서의 심볼릭 링크 혹은 소프트 링크는 윈도우즈 환경의 바로가기 생성과 유사하다고 생각하시면 편합니다. 즉, ln -s A B하면 B를 참조할 때 A로 가라는 이정표를 꽂아둡니다. (마치 int* B = \u0026amp;A)\n인자 순서가 참 헷갈리는데, 유닉스 환경에서는 ‘있는 것 → 없는 것’ 순으로 쓴다고 암기하시면 됩니다. 이미 있는 A파일로 향하는, 아직 없는 이정표 B를 세웁니다. mv도 있는 것 → 없는 것, cp도 있는 것 → 없는 것.\n사용자 추가 아래 명령어의 SOMEUSERNAME 부분에 본인이 사용하실 이름을 입력합니다.\n# useradd -m -g users -G wheel -s /bin/bash SOMEUSERNAME 명령어 설명\nm : user라는 이름을 홈 디렉토리에 생성. 유저의 홈이 됨. g: 소문자 g는 기본 그룹을 의미, 따라서, users 그룹에 포함됩니다. G: 추가적으로 속할 그룹 설정(참조: 아치리눅스 그룹리스트) wheel: 관리자 그룹(su 명령 사용 가능 그룹) s: default 아닌 쉘을 사용하기 위한 옵션(zsh, fish를 사용하고자 할 때) /bin/bash: s로 다른 쉘을 사용하겠다고 했으니 그 다른 쉘로써 bash를 지정 새로 생성한 사용자의 비밀번호를 설정합니다.\n아래 명령어의 SOMEUSERNAME 부분을 본인이 지정한 유저 이름으로 변경해야 합니다.\n# passwd SOMEUSERNAME sudo sudo? doas? su -l?\n최근 해외 포럼에서 sudo에 대한 논란이 작게나마 발생합니다.\nBSD 계열에서 자주 보이는 \u0026lsquo;OpenBSD의 doas를 통해 더 미니멀하게 접근할 수 있다\u0026rsquo;는 의견과 원래 sudo가 개발된 목적이 다중 사용자 컴퓨터에서 활용하기 위함이었던 것을 감안하면 \u0026lsquo;1인 사용 환경에서는 sudo든 doas든 필요 없이 su -l등을 통해 직접 루트 환경이 되어 작업하는 것이 보안상 적절하다\u0026rsquo; 등이 주요 논지입니다.\n판단은 여러분 몫입니다.\n초보 사용자용 가이드인 만큼 대부분의 경우에 접하기 쉬운 sudo를 설치하겠습니다.\nsudo가 설치되지 않은 경우(# which sudo를 통해 확인→/bin/sudo 등 경로가 나오면 설치되어 있음), # pacman -S sudo를 통해 설치합니다.\nvim 에디터가 익숙하신 분들은 그냥 # visudo (EDITOR 환경 변수가 vi으로 잡혀 있는 경우) 하시거나 # EDITOR=vim visudo 하셔도 됩니다.\n# EDITOR=nano visudo sudoers 파일은 # nano /etc/sudoers커맨드로도 수정이 가능하지만 원칙은 # visudo를 통해 수정하는게 맞습니다. visudo가 sudoers파일의 문법적 오류 등을 점검하고 잠그는 기능을 하기 때문에 임의로 # nano /etc/sudoers를 직접 수정하는 것은 권장하지 않습니다.\nsudo 명령어 사용 가능 그룹에 새로 만든 사용자의 추가 그룹이었던 wheel을 추가하겠습니다.\n## ## User privilege specification ## root ALL=(ALL) ALL ## Uncomment to allow members of group wheel to execute any command # %wheel ALL=(ALL) ALL // 이렇게 주석 처리 되있던 것을 %wheel ALL=(ALL) ALL // \u0026#39;#\u0026#39;을 지워서 이렇게 되도록 주석 제거 처리 해주면 됩니다. ## Same thing without a password # %wheel ALL=(ALL) NOPASSWD: ALL // 위 설정의 주석을 제거하면, // wheel 그룹 소속 사용자가 \u0026#39;비밀번호마저도 필요없이\u0026#39; // sudo만 붙이면 명령 실행이 가능하도록 합니다. // 보안상의 이유로 강력히 반대합니다. // 어떤 변경을 하는 것인지 정확히 알고 계시는 분만 주석 제거하시기 바랍니다. 부트로더 부트로더 설치를 하겠습니다. 두 가지 중 하나를 선택해 이용할 수 있습니다.\ngrub은 대부분 배포판에서 사용하기 때문에 익혀두시면 다른 배포판을 다룰 때에도 익숙할 수 있습니다. 다만 grub과 더불어 efibootmgr과 같은 프로그램을 추가로 설치해서 진행합니다. systemd-boot는 systemd에 내장된 기능을 이용해 부트를 시도합니다. 첫 설치는 조금 더 까다롭다고 느끼실 수 있지만 추가 설치를 최소화하려는 아치 배포판의 철학과 매우 잘 부합한다고 생각합니다. (grub 파트 뒤에서 설명합니다.) 제 추천을 원하신다면 systemd-boot를 추천 합니다만 둘 다 어떤 것인지 처음 들어보셨거나, 들어봤다고 하더라도 다른 부트로더, 예를 들어, {e,}lilo가 뭔지 모르신다면 grub을 사용하시기 바랍니다.\n부트로더는 시스템을 부팅시키는게 핵심 역할이기 때문에 다양한 부트로더를 활용해봤거나 수정을 직접 해본 경험이 충분하지 않은 이상 많은 배포판에서 활용하고, 문서나 지원을 검색하기 용이한 패키지를 사용하는 것이 맞다고 봅니다.\ngrub'2\u0026rsquo;? gummiboot?\ngrub은 현재 grub2입니다. grub-legacy라고 하여 예전 BIOS환경일 때부터 쓰여온 훌륭한 소프트웨어입니다. 다만, 너무나 많은 기능을 제공하다보니 단지 UEFI 환경의 부트만을 원하는 사용자에게는 의미없는 기능들도 추가되어 있습니다. 이는 곧, 소프트웨어에 예기치 못한 충돌이나 문제가 발생할 소지가 많을지도 모른다는 의미로 받아들이기도 합니다.\nsystemd-boot는 bootctl혹은 gummiboot라고도 불리는데 그 이유는 systemd가 흡수를 하기 전 외부에 존재하는 소프트웨어일 때의 이름이기 때문입니다. 이제는 systemd와 완전히 합쳐져서 UEFI 부트만을 보조하는 기능을 수행합니다(물론, BIOS 부트를 설치할 수 있습니다만 추천하지 않습니다). 아치리눅스 설치 과정에서도 이미 default로 설치되는 프로그램이기도 합니다.\ngrub 설치를 합니다. 설치 전에 레파지토리(아치 리눅스 측 패키지 저장소)를 기준으로 로컬 레파지토리(설치 중인 컴퓨터가 가진 소프트웨어들의 정보)를 업데이트, 동기화 합니다.\n# pacman -Syu 명령어 설명\nS: 원격 레파티토리와 동기화 y(--refresh): S와 쓰일 수 있는 옵션으로 원격 레파지토리의 패키지 DB를 새로 다운로드 u(--sysupgrade): S와 쓰일 수 있는 옵션으로 다운로드한 DB에 맞게 시스템 패키지를 업그레이드 이제 사용할 패키지들을 가져와서 설치하겠습니다.\n# pacman -S grub efibootmgr 이제 grub을 이용해 부트가 가능하도록 설치하겠습니다.\n이 과정을 많은 분들이 혼란스러워 하시는데 이 과정은 \u0026lsquo;시스템에 부트로더 설치\u0026rsquo; 입니다. 즉, 부팅 과정을 책임질 grub이 시스템 설정을 확인하고 부팅이 가능하도록 만드는 과정입니다.\ngrub 패키지를 다운로드, 설치하는 것이 아님. 패키지 자체는 위 명령어로 설치하였습니다.\n# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=arch --recheck 명령어 설명\ngrub-install: 그럽 설치 명령 target=x86_64-efi: 타겟 아키텍쳐 x86_64-efi로 지정 efi-directory=/boot: efi디렉터리 위치 지정 bootloader-id=arch: 부트로더-이름은 arch로 recheck 이제, # nano -w /etc/default/grub을 통해, 부트로드의 기본 설정을 변경할 수 있습니다. 예를 들어, 부팅할 OS선택을 기다릴 시간을 0 또는 1초 처럼 짧게 변경하거나 할 수 있습니다. 여기서는 건드리지 않겠습니다. 설정이 완료된 경우, /etc/default/grub의 설정들을 기반으로 하여 부팅을 위한 \u0026lsquo;파일(/boot/grub/grub.cfg)\u0026lsquo;을 생성/설치합니다.\n# grub-mkconfig -o /boot/grub/grub.cfg 명령어 설명\ngrub-mkconfig: grub이 /etc/default/grub에 쓰인 설정대로 실제 부팅에 사용할 설정 파일(grub.cfg)를 생성합니다. o: UNIX 계열에서 o는 output의 줄임으로 생성 파일 경로/이름을 지정할 때 자주 쓰입니다. /boot/grub/grub.cfg: 가장 기본적으로 부팅시 확인하는 경로이자 파일명입니다. 추후에 여러가지 이유로 grub 설정을 변경한 때에도 사용하는 명령어입니다. 특히 커널 변수등을 실험해보거나 할 때 /etc/dafault/grub 파일을 수정한 후에 위 명령어를 통해 업데이트를 합니다.\n정리하자면\ngrub 패키지를 다운로드 받아 설치한 이후, grub 부트 로더를 시스템에 설치하면 /etc/default/grub이라는 추가 설정 가능 파일을 남기는데, 필요하다면 이 파일을 입맛에 맞게 수정하고 나서 # grub-mkconfig -o /boot/grub/grub.cfg를 통해 /boot/grub/grub.cfg를 만들어야 부팅 과정에서 /boot/grub/grub.cfg 설정을 읽어들여 부팅이 가능해집니다. systemdboot grub을 사용하지 않기로 하신 분들만 해당합니다.\n# bootctl --path=/boot install /boot/loader의 /loader.conf 파일을 수정해야 합니다.\n# nano -w /boot/loader/loader.conf 파일에 아래와 같이 작성\ndefault arch editor 1 timeout 3 파일 설정 설명\neditor: 부팅 중에 ‘e’키 등을 이용해 커널 변수 혹은 부팅 환경설정을 조정하는 경우가 있는데 0으로 설정 시에 이것을 방지합니다. 개인적인 권장으로는, 지금은 ‘1’로 설정해 두고 정상 작동한다는 것을 확인한 이후에 수정하는 것을 추천합니다. timeout 3 은 부팅 화면 중에 선택을 기다리는 시간입니다. 이것도 마찬가지로 지금은 설정해두되 나중에 ‘0’등으로 수정하셔도 됩니다. 디폴트 이후 arch에는 본인이 알아볼 이름을 넣으시면 됩니다. 보통은 arch를 이용합니다. 다만, 주의하실 점은 이 부분에 넣은 이름을 꼭 기억하셨다가 바로 뒤에 따라오는 과정에서 entries/abcd.conf 파일의 abcd부분인 파일명에 동일하게 작성해 주셔야 한다는 점입니다. 지금 arch로 작성하시면 나중에 그냥 entries/arch.conf 파일을 만드시면 됩니다.\n이제 loader 디렉터리 아래의 entries 디렉터리에 파일을 생성하고 수정하겠습니다.\n# nano -w /boot/loader/entries/arch.conf arch.conf파일에 내용을 추가하기 전에, 아래의 참고부분을 한번 읽어보시고, 참고란 끝에 예시 파일을 보여드리겠습니다.\n참고\n# ls /boot 해보시면 /boot 디렉터리 아래에 loader와 각종 이미지 파일(vmlinuz, initramfs-linux 등)이 있는 것을 확인하실 수 있습니다. 그것들을 파일 내용에 포함하는 것입니다.\ntitle에는 알아보기 쉬운 이름을 사용하시면 됩니다. 이 곳에 쓰인 이름은 다른 설정에서 추가로 필요하지는 않고 부팅 과정에서 메뉴 이름으로 활용됩니다. 보통 ArchLinux 등을 사용하는 편입니다.\nlinux 항목에서 vmlinu”z”에 주의하시기 바랍니다.\n추가적으로 저는 rw 옵션에 이어 quiet 등을 사용합니다. 그랬었는데, 다시 quiet 옵션은 그냥 안씁니다. 큰 이유는 없고 Failed가 뜨는지 보고 싶어졌습니다.\ntitle ArchLinux linux /vmlinuz-linux initrd /initramfs-linux.img options root=/dev/sda3 rw PARTUUID 쓰라는 사람 있던데 그게 뭐임??\noption 항목에서 권장 사항은 물론 PARTUUID를 이용하는 것입니다. 하지만 우선은 루트 파티션 경로를 지정해 주는것으로 대체하도록 하겠습니다. 위키에 따르면 “리포맷 되거나 경로 매핑이 변경되는 경우에 비해 PARTUUID가 장점을 가진다”라고 되어있는데, 일반 사용자, 초보 사용자 기준에 그럴 일이 드물 것으로 가정하고 경로를 지정합니다. 또는, 정상 부팅이 되는 것을 확인한 이후에 수정하는 것도 한 가지 방법이 될 것입니다.\nPARTUUID를 사용하고 싶으신 분들은\n(1) # blkid를 통해 루트파티션(지금은 sda3)의 PARTUUID를 복사하시거나 적어두신 후 위의 options 항목의 내용을 root=PARTUUID=123efg45-789 rw 로 해주시면 됩니다. 물론 123efg45-789이 부분에 본인의 PARTUUID가 들어갑니다. (원래 PARTUUID가 깁니다. 놀라지 마세요! / “(쌍따옴표) 같은게 추가되지 않았는지 잘 확인하시기 바랍니다!!)\n(2) 적어두는 것이 귀찮은 분들은 options 줄을 지운채로 저장하신 후 # echo \u0026quot;options root=PARTUUID=$(blkid -s PARTUUID -o value /dev/sda3) rw\u0026quot;\u0026gt;\u0026gt; /boot/loader/entries/arch.conf(본인 환경에 맞게 대체해야 되는 부분 없는 명령어임)를 활용하시면 됩니다. 무슨 방법을 사용하시든 반드시 다시 # cat /boot/loader/entries/arch.conf하셔서 추가한 내용들이 적절히 적혀 있는지 확인하시기 바랍니다.\n이렇게 PARTUUID를 이용한 경로를 추가하셔서 options가 두 줄이 된 경우, 기존에 /dev/sda3로 작성되어 있는 options줄은 삭제하는건 당연한겁니다;;\nexit 현재 상태로 아래에서 소개하는 # exit을 통해 chroot환경에서 나가고 재부팅을하면 네트워크 연결이 가능하지 않습니다. 따라서, 네트워크 매니저를 설치하고 켜주도록 하겠습니다.\n우선, 아직 설치하지 않았다면,\n# pacman -S networkmanager 그리고 네트워크 매니저를 재부팅시에 자동적으로 실행되도록 설정합니다.\n# systemctl enable NetworkManager.service 명령어 설명\nsystemd init 시스템에서 서비스(데몬)들을 관리하는 명령어가 systemctl입니다. 현재 부팅된 환경에서 바로 서비스를 켜고 사용을 시작하려면 start, 부팅 때마다 자동 실행되게 하려면 enable옵션을 사용합니다. 끝에는 대상 서비스의 이름을 적습니다.\n혹시, 이 부분을 놓치고 지나가셔서 네트워크가 안되는 분들은, chroot 방법을 통해 다시 시스템에 진입하셔서 설치가 가능합니다.\n설치 완료 후에 부팅이 안되는 경우에도 # arch-chroot /mnt를 활용해 오류 수정할 수 있습니다.\n// 설치 완료 후, 재부팅 해봤는데 문제가 있다. // 다시 Live USB로 부팅 # mount -v -t ext4 /dev/sda3 /mnt // /mnt에 마운트된 /dev/sda3에 디렉터리 구조가 정상적으로 존재하는지 확인 # ls /mnt // 정상이면 (필요한 경우) 나머지 드라이브도 마저 마운트 # mount -v -t vfat /dev/sda1 /mnt/boot // 다시 시스템 내부로 진입 # arch-chroot /mnt // 필요한 보수 작업 실행 // 설치 완료 과정과 동일하게 빠져나오기 # exit # cd # umount -lR /mnt # reboot # exit umount 각 디렉터리에 마운트 되어있던 장치들을 제거합니다.\n# umount -lR /mnt reboot 재부팅을 합니다!!!\n# reboot 장치가 종료되고 다시 시작되는 시점에 USB를 빼주시면 됩니다.\n재부팅이 되면 로그인 하라는 화면이 나올텐데 설치에 성공하신 겁니다! 축하드립니다!\n아마 기쁘신 분도 있고, 이게 뭐야 하시는 분도 있을텐데, 이게 뭐야 싶으신 분들은 그래픽 환경에 익숙하셔서 그런거라고 생각합니다. 서버와 같이 헤드리스(headless)로 작업하실 분들을 제외하고 앞으로 이어질 데스크탑 환경을 설치하시면 그래픽 환경에서 아치를 사용하실 수 있습니다.\n그래픽 환경 설치 (시대가 바뀌어서..) wayland를 설치하도록 하겠습니다.\n데스크탑 환경 부분, 즉 wayland와 gnome 부분만큼은 제가 항시 사용하는 소프트웨어가 아니다보니 최신화가 덜 될 수 있습니다.\n로그인 본인이 설정한 ID/Password로 로그인을 합니다.\n일반 사용자로 로그인하였으므로 프롬프트는 $로 변경됩니다. sudo를 활용해 실행합니다.\n인터넷 연결 재확인 $ ping -c 3 www.google.com 팩맨 설정 이제 설치할 것들이 몇 가지 있으니 pacman을 업데이트하겠습니다.\n$ sudo pacman -Syu /etc/pacman.conf 파일과 /etc/makepkg.conf를 살펴보시는 것도 좋습니다.\n기본 정보 가이드는 Gnome을 기준으로 소개합니다.\n필수 설치 추가로 제공되는 그놈 소프트웨어들도 사용하시고 싶으시면 gnome-extra를 설치하시면 됩니다.\n$ sudo pacman -S xorg-xwayland gnome (gnome-extra) $ sudo systemctl enable gdm 설치가 완료되고 나면 디스플레이 매니저를 사용할 수 있게 systemctl enable을 진행합니다. gnome 패키지에는 gdm을 포함한 Gnome 데스크탑 환경에서 사용하는 필수 소프트웨어가 포함되어 있습니다.\ngdm 은 \u0026lsquo;Gnome Display Manager\u0026rsquo;로써, 데스크탑 환경의 로그인 화면과 전반적인 그래픽 환경을 관리하는 프로그램입니다. 이전에 인터넷 연결을 위해 # systemctl enable NetworkManager 했던 것을 기억하시나요? 이번엔 gdm 서비스를 부팅시마다 사용하기 위해 enable을 사용하였습니다.\nreboot again 재부팅을 진행합니다.\n$ sudo reboot 자 어떤가요? 로그인 화면이 그래픽 환경으로 부팅 되셨나요?\n이제 사용자 비밀번호를 입력한 후에 아치 리눅스 Gnome 환경 준비가 모두 완료되었습니다.\n아! 하지만 권장 사항들이 몇 가지 더 있네요!\n웹브라우저 설치 파이어폭스 사용하고 싶은 웹 브라우저가 파이어폭스, 혹은 구글-크롬이라면 어떻게 해야 할까요? 파이어폭스라면 설치해주면 됩니다!\n$ sudo pacman -S firefox 파이어폭스 설치가 완료되었습니다!\n팩맨을 활용해서 설치할 수 있는 소프트웨어의 경우는 아치의 공식 레파지토리에 올라와 있는 것들입니다. 공식 레파지토리에는 아치 리눅스의 라이선스와 호환이 가능한, 즉, 오픈 소스/자유 진영 소프트웨어만 있습니다.\n크롬의 경우에는 공식 레파지토리에 chromium이라는 오픈소스 버전 크롬이 있습니다. 사실 둘의 차이점은 크지 않아요!(chromium 설치:$ sudo pacman -S chromium)\n하지만 나는 꼭 구글-크롬 을 사용하고 싶다하시면 아치의 자랑인 AUR을 사용해 보겠습니다!\nvscode가 이상해요!\n위에서 적은 이유로 공식 레파지토리를 통해 설치되는 visual studio code는 사실 Code-OSS라는 이름의 오픈 소스 버전입니다. MS에서 사용하시던 vscode와 완전히 동일한 사유 소프트웨어(proprietary software) 버전을 사용하고자 하신다면 아래에서 설명하는 AUR 사용 방법을 숙지하신 다음, \u0026lsquo;visual-studio-code-bin\u0026lsquo;이나 유사 패키지를 설치하시기 바랍니다.\n구글 크롬 AUR 이란 Arch User Repository로 아치 사용자들이 관리하고 업로드하는 패키지들의 모음입니다. AUR을 이용해 패키지를 빌드하는 방법은 확실히 알아두셔야 합니다. 나중에 ’부록’에서 찾으실 수 있는 AUR-helper(yay 등)를 사용하시더라도 오류는 언제든지 발생할 수 있습니다. 그 때는 부득이하게 수동으로 설치하셔야 합니다.\n아치리눅스 위키페이지에 따르더라도, AUR helper는 언제나 도움을 주는 제 3 자 소프트웨어일 뿐, 공식적으로 지원을 받는 프로그램이 아닙니다.\n기본 개념은\n\u0026ldquo;aur.archlinux.org\u0026quot;에 접속해서 내가 설치하려고 하는 패키지의 snapshot을 다운로드 받습니다. 다운로드 받은 스냅샷의 압축을 해제하면 PKGBUILD파일이 있는데, MAKEPKG라는 명령어를 통해 컴퓨터가 PKGBUILD의 내용대로 설치를 하는 것입니다. 자세한 내용은 아래를 통해 설명드리겠습니다.\nGit을 활용해 귀찮은 스냅샷 다운로드→압축 해제과정을 피하실 분들은 이 챕터 끝을 참조하세요!!\n지금은 \u0026lsquo;웹\u0026rsquo;소프트웨어 밖에 없으니 그것을 이용해서(혹은 파이어폭스를 설치하셨다면 파이어폭스를 이용해서)\n\u0026#34;https://aur.archlinux.org\u0026#34;를 접속한 후에 우측의 검색 창에 ‘google-chrome’을 입력하시면 구글-크롬에 해당하는 AUR페이지가 뜹니다. 우측의 작은 대화상자(Package Actions)에서 Download Snapshot 을 이용해 Downloads 디렉터리로 가져옵니다. 터미널 실행 후, $ cd Down[tab] 최근 모든 쉘은 키보드의 Tab 키로 자동 완성 기능을 제공합니다.\n$ ls google-chrome.tar.gz 를 확인할 수 있습니다. name.tar.gz은 gzip으로 압축되고 tar로 패키지된 파일 이라는 뜻입니다. 해제는 tar명령어를 이용하면 됩니다.\n$ tar -xvzf goog[tab] tar는 파일 압축 해제 프로그램이라고 생각하셔도 됩니다.\n명령어 설명\nx: extract(압축해제) v: verbose(과정 출력) z: gzip 으로 압축된 파일 f: 이어 입력할 이름의 압축 파일을 해제 Tab키를 이용해 나머지 이름은 자동완성해보았습니다. $ ls 완료되고 나서 다시 ls를 해보면 google-chrome 디렉터리가 생겼습니다!\n$ cd goog[tab] $ makepkg -risc 명령어 설명\nr: 빌드가 완성된 이후, 빌드 과정에서 필요로 했던 의존성으로 설치된 패키지들을 다시 제거합니다. 이 옵션으로 의존성으로 설치된 패키지를 제거한 경우, AUR 패키지 업그레이드 당시에 아직도 의존하는 패키지라면 해당 업그레이드 버전을 빌드할 때 다시 설치됩니다. 그러나 업그레이드가 자주 있지 않다는 점을 알거나 더 깔끔한 시스템을 원하는 경우, 옵션을 켜서 제거하는 것도 좋은 방법입니다. i: 빌드가 완성되면 자동으로 설치를 진행합니다. 이 옵션을 제거하는 경우, 이어지는 명령어로 $pacman -U pkgname-pkgver.pkg.tar.zst를 입력하여 설치해야 합니다. 이런 번거로움을 없애줍니다. s: 의존성 중, pacman으로 설치 가능한 공식 레파티토리 패키지들은 자동으로 설치합니다. AUR 패키지 중에서, 또 다른 AUR 패키지에 의존하는 경우는 수동으로 먼저 설치해주어야 합니다. c: 설치 이후, 빌드 과정에서 생성된 임시 파일을 삭제합니다. google-chrome 설치가 완료되었습니다! 상단 패널의 Activities\u0026gt;All을 통해서 확인하실 수 있습니다!\nGit 활용시\n// GIT 미설치 경우 $ sudo pacman -S git // AUR 디렉터리 등 생성하는 것을 추천 (AUR 패키지 관리 편의성) $ cd ~ $ mkdir ~/AUR $ cd ~/AUR // AUR 페이지 검색 결과 중, Git Clone URL 참조 // 클릭해 복사도 가능 -\u0026gt; 터미널에서 붙여넣기는 ctrl+shift+v // 레파지토리를 Chrome이라는 디렉터리로 클론 $ git clone https://aur.archlinux.org/google-chrome.git Chrome $ cd Chrome $ makepkg -risc // 추후 업데이트 있을 때 $ cd ~/AUR/Chrome $ git pull $ makepkg -risc 한글 폰트 한글 폰트가 시스템에 설치되어 있지 않아, 네이버 등을 접속해보면 네모난 박스로 표시됩니다. 이는, noto-fonts-cjk 등의 패키지를 설치하여 해결할 수 있습니다. ($sudo pacman -S noto-fonts-cjk)\n그러나 여기서는 AUR에 더 익숙해지고자 공식 레파지토리에는 없는 폰트를 AUR을 통해 설치해보겠습니다.\n(aur.archlinux.org에 접속 → ttf-nanum검색 → snapshot 다운로드) $ cd Down(tab) $ tar -xvzf ttf(tab) $ cd ttf(tab) $ makepkg -risc 위의 과정을 통해 한글 폰트 설치가 완료되었습니다. 여기까지 진행하면, 구글 크롬을 통해 유투브/네이버를 이용하더라도 한글 폰트가 깨지지 않고 출력됩니다.\n하지만, 한글로 검색을 하고 싶은데 한글 입력이 안됩니다. 어떻게 해야 할까요?\n한글 입력 한글 입력 과정에 대한 문의가 많아 별도 페이지를 신설했습니다.\n결론 이 긴 글에서 명령어만 추려내면 아래의 30줄 남짓이 전부입니다. 글이 길어서 정작 ‘아치 리눅스가 무슨 심플(?)’이라고 생각하셨을지 모르지만 이 명령어들을 모두 이해하고 외워져 있는 사용자들 입장에선 당장 사용해야 하는 랩탑/데스크탑을 제공받았을 때 설정에 따라 5~10분만에 자신이 원하는대로 시스템을 구축할 수 있습니다!\n어찌 보면 데비안 → 우분투, 혹은 레드햇 → 페도라보다 더 간결하고 우아한 배포판이라고 사람들이 떠드는 이유가 바로 여기에 있다고 생각합니다.\n긴 글 읽느라 수고하셨습니다! 🤩\n자! 그럼 아치 리눅스는 너무 쉬우니 젠투로..ㅋㅋㅋ\n# cfdisk /dev/sdx # mkfs.vfat -F 32 /dev/sdxN # mkfs.ext4 -j /dev/sdxN # mkswap /dev/sdxN # swapon /dev/sdxN # mount -v -t ext4 /dev/sdxN /mnt # mkdir -pv /mnt/boot # mount -v -t vfat /dev/sdxN /mnt/boot # timedatectl set-ntp true # hwclock --systohc --utc # reflector --sort rate -c KR \u0026gt;\u0026gt; /etc/pacman.d/mirrorlist # pacstrap /mnt base linux linux-firmware vim networkmanager # genfstab -U /mnt \u0026gt;\u0026gt; /mnt/etc/fstab # arch-chroot /mnt # passwd # vim -w /etc/locale.gen # locale-gen # echo LANG=en_US.UTF-8 \u0026gt; /etc/locale.conf # echo pcname \u0026gt; /etc/hostname # ln -sf /usr/share/zoneinfo/Asia/Seoul /etc/localtime # pacman -S grub efibootmgr # grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=arch --recheck # grub-mkconfig -o /boot/grub/grub.cfg # systemctl enable NetworkManager.service # exit # umount -lR /mnt # reboot 부록 독자 추가 사항 Davido(osh3606@gmail.com)님 추가 사항 (내용 기여 감사합니다!)\n// btrfs \u0026amp; timeshift // btrfs 관리 프로그램 설치 # pacman -S btrfs-progs // 파일시스템 포맷하기 # mkfs.btrfs /dev/sda3 // 서브 볼륨 생성 # mount /dev/sda3 /mnt # cd /mnt # btrfs subvolume create @ # btrfs subvolume create @home # cd / # umount /mnt // 서브볼륨 마운트 # mount -o rw,noatime,compress=lzo,space_cache=v2,subvol=@ /dev/sda3 /mnt # mkdir /mnt/home # mkdir /mnt/boot # mount -o rw,noatime,compress=lzo,space_cache=v2,subvol=@home /dev/sda3 /mnt/home # mount /dev/sda1 /mnt/boot // fstab 수정 // 스냅샷 프로그램 사용하기 위해서는 genfstab 이후 fstab에서 subvolid 없애줘야 함. // 안없애면 추후에 btrfs 복구시 복구 전 id를 찾으려 하기 때문에 정상적으로 복구 안됨… # nano /mnt/etc/fstab // /, /home 마운트 옵션에서 // → subvolid=#### 삭제 // → subvol=###/,subvol=### 중 하나 삭제 // timeshift를 이용한 스냅샷/복구 // 설치 종료 후 fresh installed 상태에서 btrfs 스냅샷 만들기(timeshift사용) # sudo pacman -S git # git clone https://aur.archlinux.org/timeshift.git # cd timeshift # makepkg -si # sudo timeshift --create --comments \u0026#34;Fresh install\u0026#34; // 복구시 # sudo timeshift --restore // 원하는 스냅샷 번호 선택 # sudo reboot btrfs의 스냅샷 기능을 이용해서 백업시 (참조: timeshift 개발자 레파지토리)\n# timeshift --btrfs커맨드를 통해 btrfs 모드로 설정해 주어야함 (기본 설정은 rsync 모드)\n이유: 백업 속도에서 차이가 많이 나고, 백업 자체도 byte-by-byte copy라 손실이 없다고 하네요.\nfstab에서 subvolid 지우는 이유 상세 설명 (참조: timeshift 개발자 레파지토리 이슈)\nfstab에는 반드시 @와 @home이 있어야 함. subvolid 대신 subvol=@를 반드시 사용해야 함. 디바이스는 반드시 UUID= 이나 /dev/xxx를 통해 명시되야 함. timeshift는 우분투 기반 배포판 위해 작성됨. 페도라 혹은 아치에서 사용하는 경우, 대부분 작동에는 문제가 없겠으나 그 목적으로 만들어진 프로그램이다보니 이슈가 발생할 수 있음. AUR 관련 당부 말씀 AUR Helper란 AUR 패키지들의 업데이트나 설치를 도와주는 소프트웨어입니다.\n일반적으로,\n현재 시스템에 설치된 패키지 버전보다 더 상위 버전이 레파지토리에 존재하는지 확인만 해주는 유틸리티 그보다 한 걸음 더 나아가 상위 버전이 존재한다면 다운로드 받아 주는 유틸리티(search and download) 빌드까지 책임져주는 유틸리티(search and build) 마지막으로 아예 pacman으로 설치한 패키지를 포함, 즉, AUR만이 아니라 공식 레파지토리까지 검색하여 설치와 업데이트를 진행해주기 때문에 평소에 pacman을 사용할 일이 없도록 해주는 유틸리티(pacman wrapper) 까지 다양한 종류가 있습니다.\n아치 위키에서는 분명히 AUR 헬퍼들은 공식 지원 대상이 아님을 밝히고 있습니다. 따라서, AUR 헬퍼를 사용하다가 발생하는 문제들에 있어서는 지원을 받지 못합니다.\n옛날 버전 글에서 yaourt가 디폴트 수준으로 많이 사용되어서 가장 앞에 적었습니다. 그런데 yaourt는 개발이 중단되었습니다. 그래서 \u0026ldquo;yaourt가 중단되어 다른 소프트웨어 추천을 원하신다면 cower를 추천합니다.\u0026ldquo;라고 수정해 놨었는데 cower도 개발이 중단되었습니다.\n현재 많은 인기를 끌고 있는 것은 auracle(search and download), yay(pacman wrapper)로 보입니다.\n제가 아치 리눅스를 사용한 기간이 그리 긴 시간도 아닌데(슬슬 길어지고 있네요;;) 그간 수많은 AUR 헬퍼 패키지가 등장했다가 인기를 끌고 사라져갔습니다. 그냥 Git 혹은 AUR 디렉터리를 홈 아래에 만드신 후, $git pull을 통해 업데이트 하면서 관리하시는 게 속편합니다.\n무엇보다 가급적 AUR 패키지를 아예 안 쓰거나, 최소화하는 것을 권장합니다.\nㄴ 2222\n작성자는 현재(2022/11/14) aurutils를 설치해서, 오직 $ pacman -Qm | aur vercmp 용도로만 활용하고 있습니다. 사용하지 않음.\n","permalink":"http://ptrtoj.com/kr/arch/","summary":"\u003ch2 id=\"서문\"\u003e서문\u003c/h2\u003e\n\u003cp\u003e아치 리눅스를 써야 하는 이유가 무엇인지에 대한 질문이 등록되는 것을 자주 목격합니다. 저도 객관적으로 똑부러지게 \u0026lsquo;이런 점이 장점이고 이런 점은 약점이지만 이런 점에서 매력을 느낀다\u0026rsquo;라고 설명하지 못합니다 (물론, 제가 느끼는 강점과 매력은 분명하지만 이는 매우 주관적이기 때문입니다).\u003c/p\u003e","title":"아치 리눅스 설치 가이드"},{"content":" This is a translated work. The original post was written by gg7 on Github, and you can read it via this link. Translate permission is granted by gg7.\n이 문서는 번역본입니다. 원본은 gg7에 의해 작성되었으며, 다음 깃허브 링크에서 읽을 수 있습니다. 원작자 gg7의 번역 허가를 받았습니다.\n세 줄 요약 kernel.org로부터 Git을 통해 관리되는 커널을 make oldconfig보다 나은 완전 자동화된 설정하는 방법\n./scripts/config --enable IKCONFIG ./scripts/config --module SENSORS_NCT6775 ./scripts/config --disable AUDIT ./scripts/config --set-val SND_HDA_PREALLOC_SIZE 2048 ./scripts/config --set-str UEVENT_HELPER_PATH \u0026#34;\u0026#34; 뿐만 아니라 다양한 팁들을 제공합니다. 더 이상 4,000+ 줄의 .config를 무작정 복사하거나, 불필요한 코드, 헛소리 등이 불필요합니다.\n개요 이 글은 제가 어떻게 젠투 리눅스 머신에 커널을 다운로드 받고, 설정한 후, 설치하는 지를 설명합니다.저는 이 방법이 온라인에 설명된 90% 방법 그리고 젠투 공식 문서보다도 낫다고 생각합니다. 비판은 환영합니다 🙂제 접근방법의 장점입니다. (요약; 아래의 총 설명란을 보세요):\n커널 얻기 깃 \u0026gt; 타르볼(tarball): 더 빠른 업데이트와 패치; 내장된 체인지로그 뷰어; \u0026lsquo;git-bisect\u0026rsquo;가 가능 더 많은 대안 접근 가능: 오래된 버전부터 가장 최신 배포 후보까지 업스트림으로부터 지원을 받기 쉬움 간결함과 투명성 수정 완전 자동화, 주석과 깃에 더 적합한 수정. 커널 시드나 .config 파일들을 복사하는 것보다 나음 커널을 업그레이드 할 때 적절한 디폴트값 관리 별도의 코드/복잡성이 존재하지 않음 \u0026mdash; scripts/config 는 커널의 일부라는 점 커널 빌드와 설치 컴파일은 루트 계정으로 이루어지지 않음 march=native 가 사용됨 제 접근방법의 단점입니다:\n~1.5GB의 여분공간이 .git 을 위해 필요 ( 버전 관계 없이, shallow clone을 사용하지 않는다면 고정 비용에 해당 ) 젠투 커널팀으로부터는 그 어떤 패치도 제공받을 수 없음 ( e.g. aufs, grsecurity, 작은 수정/기능 증진등 ) 필독 사항 저는 커널 수정과 관련된 기본적인 내용을 반복하지는 않으려고 합니다 \u0026mdash; 그 내용들은 아래 문서들에 이미 설명되어 있습니다.\nhttps://wiki.gentoo.org/wiki/Handbook:X86/Installation/Kernel/ko https://wiki.gentoo.org/wiki/Kernel/ko https://wiki.gentoo.org/wiki/Kernel/Configuration/ko https://wiki.gentoo.org/wiki/Kernel/Upgrade/ko 문서를 그대로 따라할 필요는 없습니다. 따라서, 페이지를 훑어보면서 혹시 아직 읽어보지 못한 내용이 있는지 확인하시기 바랍니다.\n가이드 커널 확보 커널 개발 방법: https://git.kernel.org/\n세줄 요약:\nlinux-next: 통합 리포; 컴파일 조차 안될수도 있음 mainline: \u0026ldquo;공식\u0026rdquo; 커널, 라이너스 스스로 관리함 stable: 백포트 수정을 포함하는 리포 우분투나 RHEL과 같은 배포판은 각자 버전의 커널을 가지고 있습니다 (e.g. 우분트의 제니얼 리포). 뿐만 아니라, 각자 백포트 방법으로 \u0026ldquo;스테이블\u0026rdquo; 버전이나 지원되는 버전에 수정을 가합니다. 그런 커널을 젠투에 사용하는 것도 가능은 하지만 그 이유는 그다지 매력적이지 않아 보입니다.\n젠투에서는 상당한 양의 여분의 패치와 지원을 받을 수 있는 다양한 \u0026ldquo;공식\u0026rdquo; 옵션을 제공합니다.\nsys-kernel/gentoo-sources \u0026mdash; 기본, 약간의 패치가 적용됨 sys-kernel/vanilla-sources \u0026mdash; 전혀 수정 없는 업스트림의 커널 sys-kernel/hardened-sources \u0026mdash; 고인 기타 \u0026mdash; sys-kernel 카테고리 참조 만약 당신이 gentoo-sources를 사용하게 되면 당신은 아래의 것들을 제공받습니다:\nCONFIG_GENTOO_LINUX를 사용함으로 설정했다면 반드시 필요로 하는 다양한 세팅들이 미리 자동으로 설정됩니다. 다양한 패치. 예를 들어, 4.12버전을 위한 모든 패치를 여기에서 확인하실 수 있습니다: https://dev.gentoo.org/~mpagano/genpatches/trunk/4.12/. 구체적인 예시: 당신의 /var/tmp/portage 가 tmpfs에 마운트된다면, 1500_XATTR_USER_PREFIX.patch 없이는 portage가 어마어마한 양의 Failed to set XATTR_PAX markings 에러를 뿜습니다. 젠투 커널 팀은 훌륭합니다.(Greh Kroah-Hartman도 멤버예요!). 확실히 그들은 가치를 더하고 저보다도 깊은 지식을 가지고 있습니다. 하지만, 그래도 저는 git을 통해 kernel.org로부터 제가 사용할 커널을 구하겠습니다. (맞아요, gregkh가 linux-stable도 관리하지만 말이죠) 왜일까요?\n젠투 커널 팀이 ebuild를 출시하기까지 기다릴 필요 없이 최신 커널을 git pull 명령을 통해 구할 수 있습니다. 지원을 받기가 수월합니다. kernel.org에서 인용하자면: \u0026ldquo;[배포판 커널을 사용중이라면,] 부디 커널 지원을 받기 위해 본인 배포판의 지원 채널을 이용해주시기 바랍니다.\u0026rdquo; 어느 방법을 선택하든지 커널 패치를 적용하는 것은 손쉽지만, 원하는 것만을 골라 적용하는데는 git 쪽이 더 쉽다고 느꼈습니다. 제 워크 플로우를 변경하지 않고서 필요하다면 mainline/linux-next 관계 없이, 아니면 다른 트리로라도 커널을 변경하는게 수월합니다. 더 다양한 버전에 접근이 가능합니다. linux-stable + mainline 만 해도 2,500+개의 태그를 가졌습니다. 반면에, vanilla-sources는 현재 7개의 ebuild만을 가지고 있습니다. git-pull은 emerge보다 빠릅니다. portage는 ebuild를 /var/db/pkg 등에 parse해야 합니다. 그 뿐만 아니라 90+MB의 tarball을 주요 버전 업데이트 때마다 다운로드 해야 합니다. 심지어 저는 package.env를 통해 FEATURES=buildpkg를 사용 안 함으로 설정할 필요도 없습니다. \u0026mdash; git-pull은 확실히 덜 짜증납니다. 어떤 커널 버전을 사용해야 하나요? https://www.kernel.org/ 에 접속하세요. 특정한 주요 버전(e.g. 4.9)를 오랫동안 사용하고 싶다면 longterm release를 고르세요. 그렇지 않다면 최신 stable 버전을 사용하세요. 마지막으로, 실제 가이드입니다. 저는 원격 트리마다 1개의 \u0026ldquo;마스터\u0026rdquo; bare repo를 갖고 있기를 선호합니다:\n/usr/src$ sudo mkdir -p linux-stable-git-bare \u0026amp;\u0026amp; sudo chown \u0026#34;$(id -un):$(id -gn)\u0026#34; linux-stable-git-bare /usr/src$ git clone --mirror --bare \u0026#39;https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git\u0026#39; linux-stable-git-bare 이후, 1+ 버전을 선택합니다.\n/usr/src$ git -C linux-stable-git-bare fetch --all --tags /usr/src$ git -C linux-stable-git-bare tag --sort=-creatordate # you can also consult https://www.kernel.org/ $ Example with v4.12.8: /usr/src$ v=\u0026#34;4.12.8\u0026#34; 버전 별로 디렉터리를 생성합니다.\n/usr/src$ sudo mkdir \u0026#34;linux-stable-git-$v\u0026#34; \u0026amp;\u0026amp; sudo chown \u0026#34;$(id -un):$(id -gn)\u0026#34; \u0026#34;linux-stable-git-$v\u0026#34; /usr/src$ git clone --single-branch --branch \u0026#34;v$v\u0026#34; linux-stable-git-bare/ \u0026#34;linux-stable-git-$v\u0026#34; .git디렉터리는 하드링크를 사용합니다. ( 누군가/어떤 것이 git-gc 명령을 실행하지 않는다면요 ), 그러므로 굉장히 공간상 효율적입니다.\n젠투 커널이 더이상 필요하지 않기 때문에:\n~$ sudo mkdir -p /etc/portage/profile/ ~$ echo \u0026#39;sys-kernel/vanilla-sources-4.12.8\u0026#39; | sudo tee --append /etc/portage/profile/package.provided ~$ sudo emerge -aC gentoo-sources vanilla-sources # ... 이건 아마도 나쁜 아이디어 일 수도 있습니다. 왜냐하면 이제 depclean명령이 일부 꼭 필요한 패키지를 제거할 수도 있기 때문입니다.\n~$ equery depgraph \u0026#39;=gentoo-sources-4.12.8\u0026#39; * dependency graph for sys-kernel/gentoo-sources-4.12.8 `-- sys-kernel/gentoo-sources-4.12.8 [~amd64 keyword] `-- sys-apps/sed-4.2.2 (sys-apps/sed) amd64 `-- sys-devel/binutils-2.28-r2 (\u0026gt;=sys-devel/binutils-2.11.90.0.31) amd64 `-- sys-libs/ncurses-6.0-r1 (\u0026gt;=sys-libs/ncurses-5.2) amd64 `-- sys-devel/make-4.2.1 (sys-devel/make) amd64 `-- dev-lang/perl-5.24.1-r2 (dev-lang/perl) amd64 `-- sys-devel/bc-1.06.95-r1 (sys-devel/bc) amd64 아마 이 것들을 @world에 추가하는 것이 나을겁니다.\nebuild 대안 만일 당신이 ebuild를 계속 사용하고 싶지만, 커널 수정은 자동으로 처리하려면 다음 페이지에 나오는 내용을 확인해보시면 방법이 떠오를겁니다. https://github.com/jollheef/jollheef-overlay/blob/3a59396be2cbbdb1202e30ac577c3676fa5d9a85/sys-kernel/linux/linux-4.17.4.ebuild\n커널 설정하기 커널을 다운로드하고 컴파일, 설치하는 것은 쉽습니다: 당신은 (거의) git pull \u0026amp;\u0026amp; make all install 만 하면 됩니다. 커널 설정은 스스로 빌드한 커널을 실행하는데 가장 어려운 작업입니다. 기본 설정(디폴트 값)으로부터 얼마나 깊이 수정하고 싶은지에 따라 수 시간까지 시간이 걸릴 수 있습니다.\n설정 단계는 하드웨어와 소프트웨어로 구분할 수 있습니다.\n하드웨어 지원과 옵션 만일 단순히 make defconfig 를 사용하면 정상적으로 작동하지 않는 컴퓨터가 될 수 있습니다.\n뿐만 아니라, 부분적으로만 지원되는 커널이 될 수도 있습니다. 아마도 가능하지만 설정이 켜져 있지 않는 하드웨어 센서가 있을 지도 모릅니다. 필요한 모든 것들이 켜져 있는지 어떻게 확인할 수 있을까요?\n하드웨어 지원을 위한 설정 옵션들입니다:\n쉬움: genkernel make allmodconfig .config를 우분투/페도라/등등으로부터 복사하여 사용. 예시: http://kernel.ubuntu.com/~kernel-ppa/configs/xenial/linux/ 사용하고자 하는 커널 버전을 사용하는 Live CD로 부팅한 후, make localmodconfig를 활용하고 config파일을 저장. 커널 시드. 예. http://www.elilabs.com/~pappy/ (테스트되지 않음; 권장하지 않음) AutoKernConf (테스트되지 않음; 권장하지 않음) 시간 소모: lspci / lsusb 를 훑으며 장치/제조사 번호와 관련 설정을 찾는 방법 make menuconfig의 모든 옵션을 훑으며 관련 있어 보이는 것을 사용으로 설정 genkernel, allmodconfig와 localmodconfig는 모두 유용하며 어떤 하드웨어 설정을 사용하기로 설정해야 할지 고민하기 싫을 때 사용하는 것을 권장합니다.\n반면에, 커널 시드는 anti-pattern 성격을 가진다고 봅니다. 제작자들은 \u0026ldquo;시드는 정상 작동하는 현실판 \u0026lsquo;make defconfig\u0026rsquo;\u0026ldquo;라고 주장합니다. 저라면 차라리 업스트림에서 기본값으로 설정된 것들을 신뢰하고 실제로 대다수의 $ARCH(해당 아키텍쳐) 사용자에게 주어진 기본값이 적정한지 고민하고 변경하는 수고를 하는 편을 택하겠습니다. 기본값도 무난하고 커널 시드를 사용할 필요가 없다고 생각합니다.\n\u0026ldquo;from-scratch(처음부터)\u0026rdquo; 설정하는 것들의 장점들:\n5-10배 빠른 컴파일(선택된 것들에 의존함). 예: 쿼드코어 Intel i7 7700K CPU @ 4.5GHz, Linux 4.12, gcc 5.4.0, 모두 램디스크 상에서 make -j4가 allnoconfig: 55s user, 6s system, 20s wall defconfig: 472s user, 38s system, 145s wall defconfig + 사소한 변경점: 624s user, 47s system, 190s wall 무작위 우분투 설정파일: 3950s user, 312s system, 1166s wall 200MB 까지 디스크 공간 절약 가능(불필요한 모듈 없을시) 부팅시 수 밀리초/수 초의 시간을 절약 가능 공략 면적 감소 작은 메모리 절약 좋은 학습 경험 대부분의 사람들의 경우, gentoo-sources + genkernel 혹은 다른 유명 배포판의 커널을 계속 사용하는게 낫다고 생각합니다.\n소프트웨어 지원과 옵션들 systemd와 같은 소프트웨어는 커널의 특정 기능이 정상적으로 작동할 것을 요구합니다.\n젠투 사용자로서 아마도 아래와 같은 메시지들을 자주 접하였을 것입니다:\nERROR: setup CONFIG_AUDITSYSCALL: is not set when it should be. 다시 말하지만, make defconfig는 이것을 잡아내지 못합니다.\n전통적인 접근방식은 .config를 만들어낸 후, 계속해서 make oldconfig 혹은 make olddefconfig를 하는 방법이었습니다. .config파일은 수 천줄을 가지고 있습니다. 배타적으로 켜거나 끈 옵션들이 기본값들과 함께 뒤섞여 있습니다.\n문제점 1: 만일 기본값 자체가 변경되면(이 유명한 라이너스의 불만처럼) 새로운 기본값은 효과가 없습니다. 당신은 과거에 영원히 머물게 됩니다.\n믿기지 않는다구요?\n~/linux$ git checkout \u0026#39;b4b8cbf679c4866a523a35d1454884a31bd5d8dc^\u0026#39; # note caret ~/linux$ make mrproper defconfig ~/linux$ grep CNN55XX .config CONFIG_CRYPTO_DEV_NITROX_CNN55XX=m ~/linux$ git checkout \u0026#39;b4b8cbf679c4866a523a35d1454884a31bd5d8dc\u0026#39; ~/linux$ make oldconfig ~/linux$ grep CNN55XX .config CONFIG_CRYPTO_DEV_NITROX_CNN55XX=m 문제점 2: CONFIG_TUN is required by openvpn과 같은 주석을 다는 것이 어렵고 결과적으로 아무도 .config파일은 문서화하지 않게됩니다.\n몇 개의 강한 반박들은:\n수정은 완벽히 자동화되어야 한다. 인생은 짧다. 가능한 자동화할 수 있는지 시도해야한다. 수정은 버전 관리가 가능해야 한다. 수정은 문서화 되어야 한다. ( 왜 X 옵션이 켜져야 하는지? ). 그래서 제가 하는 방식은:\n필요한 패키지를 emerge합니다.( 예. systemd, docker, openvpn ) 모든 에러/주의 메시지를 모읍니다. 커널의 scripts/config 스크립트를 통해 필요한 옵션을 켭니다. 하드웨어 수정은 직접 하기 때문에 제 스크립트는 아래와 같이 생겼습니다. $ per-machine hardware config \u0026#34;$(dirname \u0026#34;$0\u0026#34;)/hardware/$(hostname).sh\u0026#34; $ /proc/config.gz ./scripts/config --enable IKCONFIG # tristate ./scripts/config --enable IKCONFIG_PROC # boolean $ gentoo-sources ( https://gitweb.gentoo.org/proj/linux-patches.git/tree/4567_distro-Gentoo-Kconfig.patch ): ./scripts/config --enable DEVTMPFS # boolean ./scripts/config --enable TMPFS # boolean ./scripts/config --enable UNIX # tristate ./scripts/config --enable SHMEM # boolean $ gentoo/portage: ./scripts/config --enable CGROUPS # boolean ./scripts/config --enable NAMESPACES # boolean ./scripts/config --enable IPC_NS # boolean ./scripts/config --enable NET_NS # boolean ./scripts/config --enable SYSVIPC # boolean $ openrc/runit support ./scripts/config --enable BINFMT_SCRIPT # tristate $ Recommended by the Gentoo Handbook: \u0026#34;Also select Maintain a devtmpfs file $ system to mount at /dev so that critical device files are already available $ early in the boot process (CONFIG_DEVTMPFS and DEVTMPFS_MOUNT)\u0026#34;: ./scripts/config --enable DEVTMPFS # boolean ./scripts/config --enable DEVTMPFS_MOUNT # boolean $ required for CHECKPOINT_RESTORE ./scripts/config --enable EXPERT # boolean $ systemd -- gentoo ebuild: ./scripts/config --enable AUTOFS4_FS # tristate ./scripts/config --enable BLK_DEV_BSG # boolean ./scripts/config --enable CGROUPS # boolean ./scripts/config --enable CHECKPOINT_RESTORE # boolean ./scripts/config --enable CRYPTO_HMAC # tristate ./scripts/config --enable CRYPTO_SHA256 # tristate ./scripts/config --enable CRYPTO_USER_API_HASH # tristate $ ./scripts/config --enable DEVPTS_MULTIPLE_INSTANCES # removed -- https://github.com/torvalds/linux/commit/eedf265aa003 ./scripts/config --enable DMIID # boolean ./scripts/config --enable EPOLL # boolean ./scripts/config --enable FANOTIFY # boolean ./scripts/config --enable FHANDLE # boolean ./scripts/config --enable INOTIFY_USER # boolean ./scripts/config --enable IPV6 # tristate ./scripts/config --enable NET # boolean ./scripts/config --enable NET_NS # boolean ./scripts/config --enable PROC_FS # boolean ./scripts/config --enable SECCOMP # boolean ./scripts/config --enable SECCOMP_FILTER # boolean ./scripts/config --enable SIGNALFD # boolean ./scripts/config --enable SYSFS # boolean ./scripts/config --enable TIMERFD # boolean ./scripts/config --enable TMPFS_POSIX_ACL # boolean ./scripts/config --enable TMPFS_XATTR # boolean ./scripts/config --enable ANON_INODES # boolean ./scripts/config --enable BLOCK # boolean ./scripts/config --enable EVENTFD # boolean ./scripts/config --enable FSNOTIFY # boolean ./scripts/config --enable INET # boolean ./scripts/config --enable NLATTR # boolean $ systemd -- extra things from https://cgit.freedesktop.org/systemd/systemd/tree/README ./scripts/config --enable DEVTMPFS # boolean ./scripts/config --disable SYSFS_DEPRECATED # boolean ./scripts/config --set-str UEVENT_HELPER_PATH \u0026#34;\u0026#34; ./scripts/config --disable FW_LOADER_USER_HELPER # boolean ./scripts/config --enable EXT4_FS_POSIX_ACL # boolean ./scripts/config --enable BTRFS_FS_POSIX_ACL # boolean ./scripts/config --enable CGROUP_SCHED # boolean ./scripts/config --enable FAIR_GROUP_SCHED # boolean ./scripts/config --enable CFS_BANDWIDTH # boolean ./scripts/config --enable SCHEDSTATS # boolean ./scripts/config --enable SCHED_DEBUG # boolean ./scripts/config --enable EFIVAR_FS # tristate ./scripts/config --enable EFI_PARTITION # boolean $ ./scripts/config --disable RT_GROUP_SCHED # boolean, docker wants this $ ./scripts/config --disable AUDIT # boolean, conflicts with consolekit $ chromium ./scripts/config --enable PID_NS # boolean ./scripts/config --enable NET_NS # boolean ./scripts/config --enable SECCOMP_FILTER # boolean ./scripts/config --enable USER_NS # boolean ./scripts/config --enable ADVISE_SYSCALLS # boolean ./scripts/config --disable COMPAT_VDSO # boolean $ qemu for kernel dev ./scripts/config --module VIRTIO_PCI # tristate ./scripts/config --module VIRTIO_BLK # tristate ./scripts/config --module VIRTIO_NET # tristate ./scripts/config --module 9P_FS # tristate ./scripts/config --module NET_9P # tristate ./scripts/config --module NET_9P_VIRTIO # tristate $ lm_sensors ./scripts/config --enable I2C_CHARDEV # tristate $ cryptsetup, luks (according to gentoo wiki page) ./scripts/config --enable BLK_DEV_DM # tristate ./scripts/config --enable DM_CRYPT # tristate ./scripts/config --enable CRYPTO_AES_X86_64 # tristate ./scripts/config --enable CRYPTO_XTS # tristate ./scripts/config --enable CRYPTO_SHA256 # tristate ./scripts/config --enable CRYPTO_USER_API_SKCIPHER # tristate $ openvpn ./scripts/config --module TUN # tristate $ cups ./scripts/config --module USB_PRINTER # tristate $ pulseaudio ./scripts/config --set-val SND_HDA_PREALLOC_SIZE 2048 $ Docker (useful: contrib/check-config.sh) $ \u0026#34;Generally Necessary\u0026#34; ./scripts/config --enable NAMESPACES # boolean ./scripts/config --enable NET_NS # boolean ./scripts/config --enable PID_NS # boolean ./scripts/config --enable IPC_NS # boolean ./scripts/config --enable UTS_NS # boolean ./scripts/config --enable CGROUPS # boolean ./scripts/config --enable CGROUP_CPUACCT # boolean ./scripts/config --enable CGROUP_DEVICE # boolean ./scripts/config --enable CGROUP_FREEZER # boolean ./scripts/config --enable CGROUP_SCHED # boolean ./scripts/config --enable CPUSETS # boolean ./scripts/config --enable MEMCG # boolean ./scripts/config --enable KEYS # boolean ./scripts/config --module VETH # tristate ./scripts/config --module BRIDGE # tristate ./scripts/config --module NETFILTER_ADVANCED # boolean, implicit requirement for BRIDGE_NETFILTER ./scripts/config --module BRIDGE_NETFILTER # tristate ./scripts/config --module NF_NAT_IPV4 # tristate ./scripts/config --module IP_NF_FILTER # tristate ./scripts/config --module IP_NF_TARGET_MASQUERADE # tristate ./scripts/config --module NETFILTER_XT_MATCH_ADDRTYPE # tristate ./scripts/config --module NETFILTER_XT_MATCH_CONNTRACK # tristate ./scripts/config --module NETFILTER_XT_MATCH_IPVS # tristate ./scripts/config --module IP_NF_NAT # tristate ./scripts/config --module NF_NAT # tristate ./scripts/config --enable NF_NAT_NEEDED # boolean ./scripts/config --enable POSIX_MQUEUE # boolean $ \u0026#34;Optional Features\u0026#34; ./scripts/config --enable USER_NS # boolean ./scripts/config --enable SECCOMP # boolean ./scripts/config --enable CGROUP_PIDS # boolean ./scripts/config --enable MEMCG_SWAP # boolean ./scripts/config --enable MEMCG_SWAP_ENABLED # boolean ./scripts/config --enable LEGACY_VSYSCALL_EMULATE # boolean ./scripts/config --enable BLK_CGROUP # boolean ./scripts/config --enable BLK_DEV_THROTTLING # boolean ./scripts/config --module IOSCHED_CFQ # tristate ./scripts/config --enable CFQ_GROUP_IOSCHED # boolean ./scripts/config --enable CGROUP_PERF # boolean ./scripts/config --enable CGROUP_HUGETLB # boolean ./scripts/config --module NET_CLS_CGROUP # tristate ./scripts/config --enable CGROUP_NET_PRIO # boolean ./scripts/config --enable CFS_BANDWIDTH # boolean ./scripts/config --enable FAIR_GROUP_SCHED # boolean ./scripts/config --enable RT_GROUP_SCHED # boolean ./scripts/config --module IP_VS # tristate ./scripts/config --enable IP_VS_NFCT # boolean ./scripts/config --module IP_VS_RR # tristate ./scripts/config --enable EXT4_FS # tristate ./scripts/config --enable EXT4_FS_POSIX_ACL # boolean ./scripts/config --enable EXT4_FS_SECURITY # boolean $ \u0026#34;Network Drivers/overlay\u0026#34; ./scripts/config --module VXLAN # tristate $ \u0026#34;Network Drivers/overlay/Optional (for encrypted networks)\u0026#34;: ./scripts/config --enable CRYPTO # tristate ./scripts/config --enable CRYPTO_AEAD # tristate ./scripts/config --enable CRYPTO_GCM # tristate ./scripts/config --enable CRYPTO_SEQIV # tristate ./scripts/config --enable CRYPTO_GHASH # tristate ./scripts/config --enable XFRM # boolean ./scripts/config --enable XFRM_USER # tristate ./scripts/config --enable XFRM_ALGO # tristate ./scripts/config --module INET_ESP # tristate ./scripts/config --enable INET_XFRM_MODE_TRANSPORT # tristate $ \u0026#34;Network Drivers/ipvlan\u0026#34; ./scripts/config --enable NET_L3_MASTER_DEV # boolean, required for IPVLAN ./scripts/config --module IPVLAN # tristate $ macvlan ./scripts/config --module MACVLAN # tristate ./scripts/config --module DUMMY # tristate $ \u0026#34;ftp,tftp client in container\u0026#34; $ ./scripts/config --module NF_NAT_FTP # tristate $ ./scripts/config --module NF_CONNTRACK_FTP # tristate $ ./scripts/config --module NF_NAT_TFTP # tristate $ ./scripts/config --module NF_CONNTRACK_TFTP # tristate $ \u0026#34;Storage Drivers\u0026#34; ./scripts/config --enable BTRFS_FS # tristate ./scripts/config --enable BTRFS_FS_POSIX_ACL # boolean ./scripts/config --enable BLK_DEV_DM # tristate ./scripts/config --enable DM_THIN_PROVISIONING # tristate ./scripts/config --module OVERLAY_FS # tristate $ From the gentoo ebuild ./scripts/config --enable SYSVIPC # boolean ./scripts/config --enable IP_VS_PROTO_TCP # boolean ./scripts/config --enable IP_VS_PROTO_UDP # boolean $ libvirt ./scripts/config --module MACVTAP # tristate $ sys-auth/consolekit-1.1.2 ./scripts/config --enable AUDIT # boolean, required for AUDITSYSCALL ./scripts/config --enable AUDITSYSCALL # boolean $ SCSI disk support ./scripts/config --enable BLK_DEV_SD # tristate ./scripts/config --enable EXT2_FS # tristate ./scripts/config --disable EXT3_FS # tristate, \u0026#34;This config option is here only for backward compatibility. ext3 filesystem is now handled by the ext4 driver\u0026#34; ./scripts/config --enable EXT4_FS # tristate ./scripts/config --enable VFAT_FS # tristate ./scripts/config --module REISERFS_FS # tristate ./scripts/config --enable XFS_FS # tristate ./scripts/config --enable BTRFS_FS # tristate ./scripts/config --enable FUSE_FS # tristate ./scripts/config --enable ISO9660_FS # tristate ./scripts/config --enable PROC_FS # boolean ./scripts/config --enable TMPFS # boolean $ USB input devices ./scripts/config --enable HID_GENERIC # tristate ./scripts/config --enable USB_HID # tristate ./scripts/config --enable USB_SUPPORT # boolean ./scripts/config --enable USB_XHCI_HCD # tristate ./scripts/config --enable USB_EHCI_HCD # tristate ./scripts/config --enable USB_OHCI_HCD # tristate ./scripts/config --enable USB_UAS # tristate, \u0026#34;USB attached SCSI\u0026#34; $ support 32-bit executables ./scripts/config --enable IA32_EMULATION # boolean $ GPT, EFI, UEFI ./scripts/config --enable PARTITION_ADVANCED # boolean ./scripts/config --enable EFI_PARTITION # boolean ./scripts/config --enable EFI # boolean ./scripts/config --enable EFI_STUB # boolean ./scripts/config --enable EFI_MIXED # boolean ./scripts/config --enable EFI_VARS # tristate ./scripts/config --disable OSF_PARTITION # boolean, Alpha servers ./scripts/config --disable AMIGA_PARTITION # boolean ./scripts/config --disable SGI_PARTITION # boolean ./scripts/config --disable SUN_PARTITION # boolean ./scripts/config --disable KARMA_PARTITION # boolean ./scripts/config --enable MAC_PARTITION # boolean ./scripts/config --enable MAGIC_SYSRQ # boolean $ app-emulation/qemu ./scripts/config --module KVM # tristate ./scripts/config --module VHOST_NET # tristate $ https://lwn.net/Articles/680989/ $ https://lwn.net/Articles/681763/ ./scripts/config --enable BLK_WBT # boolean ./scripts/config --enable BLK_WBT_SQ # boolean ./scripts/config --enable BLK_WBT_MQ # boolean $ http://algo.ing.unimo.it/people/paolo/disk_sched/ ./scripts/config --module IOSCHED_BFQ # tristate $ https://www.youtube.com/watch?v=y5KPryOHwk8 $ https://en.wikipedia.org/wiki/Active_queue_management $ https://lwn.net/Articles/616241/ ./scripts/config --enable NET_SCHED # boolean ./scripts/config --module IFB # tristate ./scripts/config --module NET_SCH_HTB # tristate ./scripts/config --module NET_SCH_CBQ # tristate ./scripts/config --module NET_SCH_HFSC # tristate ./scripts/config --module NET_SCH_FQ # tristate ./scripts/config --module NET_SCH_FQ_CODEL # tristate ./scripts/config --module NET_SCH_SFB # tristate ./scripts/config --module NET_SCH_INGRESS # tristate ./scripts/config --module NET_CLS_U32 # tristate $ https://lwn.net/Articles/758353/ ./scripts/config --module NET_SCH_CAKE # tristate ./scripts/config --module NET_ACT_MIRRED # tristate ./scripts/config --module NET_SCH_PIE # tristate $ https://news.ycombinator.com/item?id=14813723 ./scripts/config --module TCP_CONG_BBR # tristate $ IP ECMP ./scripts/config --enable IP_ROUTE_MULTIPATH # boolean $ source-based IP routing ./scripts/config --enable IP_MULTIPLE_TABLES # boolean $ bridging ./scripts/config --module BRIDGE # tristate $ multicast ./scripts/config --enable BRIDGE_IGMP_SNOOPING # boolean $ speed up tcpdump ./scripts/config --enable BPF_JIT # boolean $ timing packets / ptp (Precision Time Protocol) ./scripts/config --enable NETWORK_PHY_TIMESTAMPING # boolean ./scripts/config --module IP_VS # tristate ./scripts/config --module BONDING # tristate $ boot_delay=X support ./scripts/config --enable BOOT_PRINTK_DELAY # boolean $ thp, compaction ./scripts/config --enable TRANSPARENT_HUGEPAGE ./scripts/config --enable TRANSPARENT_HUGEPAGE_ALWAYS $ dev-util/bcc ./scripts/config --enable BPF_SYSCALL # boolean ./scripts/config --module NET_CLS_BPF # tristate ./scripts/config --module NET_ACT_BPF # tristate ./scripts/config --enable BPF_EVENTS # boolean ./scripts/config --enable DEBUG_INFO # boolean ./scripts/config --enable FUNCTION_TRACER # boolean ./scripts/config --enable KALLSYMS_ALL # boolean $ https://lwn.net/Articles/759781/ ./scripts/config --enable PSI # bool ./scripts/config --enable PSI_DEFAULT_DISABLED # bool $ https://www.phoronix.com/scan.php?page=article\u0026amp;item=linux_2637_video\u0026amp;num=1 ./scripts/config --enable SCHED_AUTOGROUP # boolean $ and so on 적용:\n/usr/src/linux-stable-git-4.12.8$ make mrproper defconfig /usr/src/linux-stable-git-4.12.8$ ~/kernel-config.sh /usr/src/linux-stable-git-4.12.8$ make olddefconfig 주의점 1: 가끔 수정은 암시적입니다. \u0026mdash; 즉, 다른 수정에 의해 켜지는 경우가 있습니다:\nSymbol: TAP [=n] Type : tristate Defined at drivers/net/Kconfig:304 Depends on: NETDEVICES [=y] \u0026amp;\u0026amp; NET_CORE [=y] Selected by: MACVTAP [=n] \u0026amp;\u0026amp; NETDEVICES [=y] \u0026amp;\u0026amp; NET_CORE [=y] \u0026amp;\u0026amp; MACVLAN [=n] \u0026amp;\u0026amp; INET [=y] || IPVTAP [=n] \u0026amp;\u0026amp; NETDEVICES [=y] \u0026amp;\u0026amp; NET_CORE [=y] \u0026amp;\u0026amp; IPVLAN [=n] \u0026amp;\u0026amp; INET [=y] 만약 CONFIG_TAP 을 켜고 싶다면, \u0026ldquo;Selected by\u0026rdquo; 부분은 반드시 만족시켜야 합니다. ./scripts/config --enable TAP 명령을 통해 정상적으로 작동하는 것처럼 보이지만, make olddefconfig이 다시 되돌립니다.\n주의점 2: 일부 설정은 다른 것들에 의존합니다:\nSymbol: BRIDGE_NETFILTER [=n] Type : tristate Prompt: Bridged IP/ARP packets filtering Location: -\u0026gt; Networking support (NET [=y]) -\u0026gt; Networking options -\u0026gt; Network packet filtering framework (Netfilter) (NETFILTER [=y]) (1) -\u0026gt; Advanced netfilter configuration (NETFILTER_ADVANCED [=n]) Defined at net/Kconfig:187 Depends on: NET [=y] \u0026amp;\u0026amp; BRIDGE [=n] \u0026amp;\u0026amp; NETFILTER [=y] \u0026amp;\u0026amp; INET [=y] \u0026amp;\u0026amp; NETFILTER_ADVANCED [=n] 마찬가지로, 예를들어 만약 NET=n, ./scripts/config --enable BRIDGE_NETFILTER 가 NET을 가능 설정으로 만들지 않는다면 NET=n 과 BRIDGE_NETFILTER=n 이 되고 말것입니다.\n이런 깨진 의존성을 발견하여 해결하는 방법은:\n/usr/src/linux-stable-git-4.12.8$ grep -Po \u0026#39;(?\u0026lt;=--enable )[^# ]+\u0026#39; ~/kernel-config.sh | sed \u0026#39;s/^CONFIG_//\u0026#39; | while read kconf; do if ! grep -q \u0026#34;^CONFIG_$kconf=y\u0026#34; .config; then echo \u0026#34;$kconf not set\u0026#34;; fi; done 추가할것: 모든 것을 확인하는 스크립트 작성하기\n마이크로코드 업데이트를 잊지 마세요. 예: 인텔 CPU:\n$./scripts/config --enable FIRMWARE_IN_KERNEL $./scripts/config --set-str EXTRA_FIRMWARE \u0026#34;$(iucode_tool -L /lib/firmware/intel-ucode | grep \u0026#34;$(iucode_tool -S 2\u0026gt;\u0026amp;1 | grep -Po \u0026#39;(?\u0026lt;=signature ).*$\u0026#39;)\u0026#34; -B 1 | grep -Po \u0026#39;(?\u0026lt;=/lib/firmware/)intel-ucode/.*\u0026#39;)\u0026#34; $./scripts/config --set-str EXTRA_FIRMWARE_DIR \u0026#34;/lib/firmware\u0026#34; 커널 빌드와 설치 make install은 sys-apps/debianutils를 필요로 합니다.\n/usr/src$ eselect kernel list /usr/src$ sudo eselect kernel set \u0026#34;linux-stable-git-4.12.8\u0026#34; /usr/src$ cd linux /usr/src/linux$ git am -3 ~/kernel-patches/*.patch /usr/src/linux$ nice /usr/bin/time -v make KCFLAGS=\u0026#34;-march=native\u0026#34; -j \u0026#34;$(nproc)\u0026#34; olddefconfig all /usr/src/linux# (mountpoint -q /boot || mount /boot) \u0026amp;\u0026amp; make install modules_install /usr/src/linux# emerge -avtq \u0026#39;@module-rebuild\u0026#39; $ if you need an initrd: /usr/src/linux# dracut -a crypt -o zfs \u0026#34;/boot/initramfs-$(make kernelrelease).img\u0026#34; --kver \u0026#34;$(make kernelrelease)\u0026#34; $ optional cleanup: /usr/src/linux# eclean-kernel --list-kernels \u0026amp;\u0026amp; eclean-kernel --ask --destructive --exclude config /usr/src/linux# grub-mkconfig -o /boot/grub/grub.cfg $ optional tools: /usr/src/linux$ make KCFLAGS=\u0026#34;-march=native\u0026#34; -j \u0026#34;$(nproc)\u0026#34; -C ./tools/power/x86/turbostat /usr/src/linux$ make KCFLAGS=\u0026#34;-march=native\u0026#34; -j \u0026#34;$(nproc)\u0026#34; -C ./tools/perf 추후 계획 더 나은 scripts/config 앱, 적절한 의존성 관리 기능 추가 비판? 칭찬? 어떤 피드백이라도 감사하게 생각합니다\n","permalink":"http://ptrtoj.com/kr/vanilla/","summary":"\u003chr\u003e\n\u003cp\u003eThis is a translated work.\nThe original post was written by gg7 on Github, and you can read it via \u003ca href=\"https://github.com/gg7/gentoo-kernel-guide\"\u003ethis link\u003c/a\u003e.\nTranslate permission is granted by gg7.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003e이 문서는 번역본입니다.\n원본은 gg7에 의해 작성되었으며, 다음 \u003ca href=\"https://github.com/gg7/gentoo-kernel-guide\"\u003e깃허브 링크\u003c/a\u003e에서 읽을 수 있습니다.\n원작자 gg7의 번역 허가를 받았습니다.\u003c/p\u003e","title":"젠투 리눅스 바닐라 커널"},{"content":"Preface 젠투 리눅스 설치 가이드는 문서 방향성을 전면 수정합니다.\n설치에 익숙한 분들이 핸드북을 참조하기 번거로울 때 활용할 수 있도록 수정합니다.\n젠투 리눅스가 처음이신 분들이나 리눅스가 익숙하지 않으신 분들은 핸드북을 참고하시기 바랍니다.\n23년 12월부로 젠투 측에서 바이너리 패키지를 공식 지원합니다.\n바이너리 패키지 설치 방법을 위해 별도 포스트를 마련했습니다.\nPrerequisite 본인 Git에서 필요한 파일을 다운받아야 할 때, \u0026gt; Github $ wget https://github.com/YOUR_USER_ID/YOUR_REPOSITORY_NAME/raw/main/FILE_DIRECTORY/SOME_FILE \u0026gt; Gitlab $ wget https://gitlab.com/YOUR_USER_ID/YOUR_REPOSITORY_NAME/-/raw/master/FILE_DIRECTORY/SOME_FILE Live USB 젠투 위키의 미러\n# wipefs --all /dev/sdb # dd if=./Downloads/install-amd64-minimal-20211231T235901Z.iso of=/dev/sdb status=progress \u0026amp;\u0026amp; sync Base Ping # ping Partition UEFI 부팅 확인\n# ls /sys/firmware/efi # wipefs --all /dev/sda # parted /dev/sda # cfdisk /dev/sda Format /boot partition\n# mkfs.vfat -F 32 /dev/sdaN swap partition\n# mkswap /dev/sdaN # swapon /dev/sdaN / partition\n# mkfs.ext4 -j /dev/sdaN foramt as xfs or btrfs\n# mkfs.xfs /dev/sdaN # mkfs.btrfs /dev/sdaN Mount 다른 배포판 환경에서 설치하는 경우, /mnt/gentoo 디렉터리가 없으므로,\n# mkdir -pv /mnt/gentoo # mount -v -t ext4 /dev/sda3 /mnt/gentoo # mkdir -pv /mnt/gentoo/boot # mount -v -t vfat /dev/sda1 /mnt/gentoo/boot TIME # ntpd -q -g # hwclock --systohc --utc Stage 3 Tarball # cd /mnt/gentoo # links https://www.gentoo.org/downloads/mirrors/ # tar xpf stage3-*.tar.xz --xattrs-include=\u0026#39;*.*\u0026#39; --numeric-owner Edit make.conf # nano -w /mnt/gentoo/etc/portage/make.conf Mirror # mirroselect -i -o \u0026gt;\u0026gt; /mnt/gentoo/etc/portage/make.conf Copy repos.conf # mkdir --parents /mnt/gentoo/etc/portage/repos.conf # cp /mnt/gentoo/usr/share/portage/config/repos.conf /mnt/gentoo/etc/portage/repos.conf/gentoo.conf Copy resolv.conf # cp --dereference /etc/resolv.conf /mnt/gentoo/etc/ Mount /proc, /sys, /dev 아래 명령어중 --make-rslave옵션은 systemd 설치하실 분만 진행합니다\n# mount --types proc /proc /mnt/gentoo/proc # mount --rbind /sys /mnt/gentoo/sys # mount --make-rslave /mnt/gentoo/sys # \u0026lt;-- # mount --rbind /dev /mnt/gentoo/dev # mount --make-rslave /mnt/gentoo/dev # \u0026lt;-- # mount --bind /run /mnt/gentoo/run Chroot # chroot /mnt/gentoo /bin/bash # source /etc/profile # export PS1=\u0026#34;(chroot) $PS1\u0026#34; Portage # merge-webrsync # emerge -avuDN @world # emerge -av gentoolkit eix genlop News # eselect news list # eselect news read N Profile # eselect profile list # eselect profile set N Timezone # ls /usr/share/zoneinfo # echo \u0026#34;Asia/Seoul\u0026#34; \u0026gt; /etc/timezone # emerge --config sys-libs/timezone-data Locale # nano -w /etc/locale.gen \u0026#39;en_US.UTF-8 UTF-8\u0026#39; 주석 제거 # locale-gen # eselect locale list # eselect locale set N Update env # env-update \u0026amp;\u0026amp; source /etc/profile \u0026amp;\u0026amp; export PS1=\u0026#34;(chroot) $PS1\u0026#34; Kernel // 정품 # emerge --ask sys-kernel/gentoo-sources pciutils sys-kernel/linux-firmware // 진품 # git clone https://github.com/torvalds/linux.git # wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.14.1.tar.xz // 유사품 1 - 바이너리 [2020-09-15: Gentoo 업데이트] # emerge -a sys-kernel/gentoo-sources-bin # emerge -a sys-kernel/gentoo-kernel-bin // 유사품 2 - 컴파일 # emerge -a sys-kernel/gentoo-kernel # emerge -a sys-kernel/vanilla-sources # emerge -a sys-kernel/git-sources # cd /usr/src/linux # make mrproper # make defconfig # make menuconfig # make -jN # make modules_install # make install When updating the kernel\n# cp /usr/src/linux/.config /usr/src/linux/NEW_KERNEL # make olddefconfig If you need initramfs\n# genkernel --install --kernel-config=/usr/src/linux/.config initramfs Microcode (TIP: Enable \u0026#39;initramfs\u0026#39; USE Flag) ex) add \u0026#39;sys-firmware/intel-microcode initramfs\u0026#39; inside \u0026#39;/etc/portage/package.use/package.use\u0026#39; file # emerge -av sys-firmware/intel-microcode Edit fstab # blkid \u0026gt;\u0026gt; /etc/fstab # nano -w /etc/fstab # Inside file \u0026#39;/etc/fstab\u0026#39; /dev/sda1 /boot vfat defaults,noatime 0 2 /dev/sda2 none swap sw 0 0 /dev/sda3 / ext4 noatime 0 1 /dev/sda4 /home ext4 noatime 0 1 # UUID -\u0026gt; remove quotation(\u0026#34;) # PARTUUID -\u0026gt; remove quotation(\u0026#34;) Hostname # nano -w /etc/conf.d/hostname # nano -w /etc/conf.d/net # nano -w /etc/hosts Netifrc # emerge --ask --noreplace net-misc/netifrc # nano -w /etc/conf.d/net config_enp3s0=\u0026#34;dhcp\u0026#34; # cd /etc/init.d # ln -s net.lo net.enp3s0 아래엔 본인 드라이버의 이름을 넣어야 합니다.\n# rc-update add net.enp3s0 default TIP emerge -av ifplugd Passwd passwd Edit rc.conf nano -w /etc/rc.conf rc_logger=\u0026#34;YES\u0026#34; rc_log_path=\u0026#34;/var/log/rc.log\u0026#34; nano -w /etc/conf.d/keymaps nano -w /etc/conf.d/hwclock Install logroate, sysklogd, cronie # emerge --ask app-admin/sysklogd cronie mlocate # rc-update add sysklogd default # rc-update add cronie default # emerge --ask net-misc/dhcpcd or\n# emerge -av networkmanger # rc-update add NetworkManager default GRUB:2 # emerge --ask --verbose sys-boot/grub:2 # grub-install --target=x86_64-efi --efi-directory=/boot # grub-mkconfig -o /boot/grub/grub.cfg Reboot # exit # cd # umount -lR /mnt/gentoo # reboot Useradd # useradd -m -g users -G wheel,audio,video,portage -s /bin/bash USER_NAME # passwd USER_NAME Remove stage3*.tar.xz # rm /stage3*.tar.xz XORG # eselect profile list # eselect profile set N # emerge -avuDN @world # env-update \u0026amp;\u0026amp; source /etc/profile # emerge --ask x11-base/xorg-server # env-update \u0026amp;\u0026amp; source /etc/profile PLASMA Settings for Plasma\n# eselect profile set N # eselect profile list # emerge -avuDN --with-bdeps=y @world System Dependencies\n# emerge --noreplace -av elogind udev dbus polkit udisks # rc-update add dbus default # rc-update add elogind boot Install Packages\n# emerge -av plasma-meta kde-aps-meta SDDM\n# emerge --noreplace -av sddm # usermod -a -G video sddm # emerge --renoplace -av gui-libs/display-manager-init Enable SDDM\n# vim /etc/conf.d/display-manager CHECKVT=7 DISPLAYMANAGER=\u0026#34;sddm\u0026#34; # rc-update add display-manager default ","permalink":"http://ptrtoj.com/kr/gentoo/","summary":"\u003ch2 id=\"preface\"\u003ePreface\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003e젠투 리눅스 설치 가이드는 문서 방향성을 전면 수정합니다.\u003c/strong\u003e\u003cbr\u003e\n설치에 익숙한 분들이 핸드북을 참조하기 번거로울 때 활용할 수 있도록 수정합니다.\u003cbr\u003e\n젠투 리눅스가 처음이신 분들이나 리눅스가 익숙하지 않으신 분들은 \u003ca href=\"https://wiki.gentoo.org/wiki/Handbook:AMD64\"\u003e핸드북\u003c/a\u003e을 참고하시기 바랍니다.\u003c/p\u003e","title":"젠투 리눅스 설치 가이드"},{"content":"Updates 🔥 since 2017/11/01\n꼼꼼히 살펴보니, 잃어버린 기록들이 있어서 아쉽네요.. 😭\nDate Type Post Description 24/12/20 구조 변경 - 카스텐 추가 24/06/08 글 수정 - 영문 이름 수정 24/04/12 구조 변경 - Git 관련 글, 번역한 글 URL 변경 24/04/12 글 추가 Git tips - 24/04/04 글 추가 MacOS Tips - 24/01/11 글 추가 젠투 리눅스 바이너리 패키지 - 24/01/07 글 추가 Emacs Config - 24/01/05 서버 이전 - Jekyll → Hugo 23/11/03 글 추가 헷갈리는 Git 용어 - 23/10/17 구조 변경 - Obsidian → Github Pages + Jekyll 23/09/23 구조 변경 - 제텔카스텐으로 전환 23/09/22 서버 이전 - Github Pages + Jekyll → Obsidian 23/07/23 글 수정 - Jekyll에 맞지 않는 세부 모두 수정 23/07/10 서버 이전 - Notion → Github Pages + Jekyll 23/06/14 글 수정 업데이트 로그 불필요하게 상세하게 작성된 로그 삭제 23/06/12 글 수정 외부 링크 모음 데이터베이스로 변경 23/06/10 글 추가 Books 독서 기록 신설 23/06/09 서버 이전 - Github Pages + Hugo → Notion 23/06/09 글 수정 업데이트 로그 테이블 형식으로 변경 23/04/11 서버 이전 - Notion → Github Pages + Hugo 23/02/12 계정 변경 - 도메인: ptrtoj.com / 이메일: jeon@domain 23/01/30 글 추가 독학 커리큘럼 - 22/12/22 계정 변경 - 도메인: jeonality.com / 이메일: jeon@domain 22/11/26 계정 변경 - 도메인: staticintj.com / 이메일: mail@domain 22/11/17 구조 변경 - 컨텐츠 체계 정리 22/11/17 글 추가 FreeBSD - 22/11/07 글 추가 개인 서식 표준 이후 삭제함 22/11/05 글 추가 리눅스에서 한글 입력 정리 (이후 ‘한글 입력 방법’으로 제목 수정) 22/11/05 글 추가 옳게 된 키보드 레이아웃 - 22/11/05 글 추가 ISO 8601 이후 삭제함 22/11/02 구조 변경 - 버전 표기 삭제 22/11/02 글 수정 선호 소프트웨어 목록 제목 변경 → ‘통합 세팅 이론’ 22/11/02 글 추가 링크 창고 ‘Useful Links’를 옮김 22/10/31 글 추가 버전 표기 vRolling 버전 삭제 22/10/30 글 추가 Fedora 이후 삭제함 22/10/18 구조 변경 - 버전 명명법 변경 → [vYY.MM.DD] 22/09/06 글 수정 업데이트 로그 과거 기록의 양식들도 모두 통일함 22/09/05 글 수정 아치 리눅스 5년만에 ‘결론’ 생김 22/09/04 구조 변경 - ‘토글 목차’ 추가, CSS Update 22/09/03 글 수정 업데이트 로그 연도 양식 변경 22/08/30 글 수정 아치 리눅스 systemd-boot 추가 22/07/08 서버 이전 - Notion 이전 완료 22/07/06 계정 변경 - 도메인: j.day / 이메일: a@domain 21/12/03 글 수정 아치 리눅스 염준영님 추가 사항 업데이트 21/11/26 구조 수정 - 목차 수정 - 홈 컨텐츠 추가 21/10/26 구조 수정 - 21.10 버전 마무리 21/10/23 서버 이전 - 서버 재이전 21/10/20 글 추가 Password 현 ‘올바른 비밀번호 설정 방법’초판 작성 21/10/12 글 수정 업데이트 로그 작성 규칙 변경 → 대형 업데이트만 작성 21/10/11 서버 이전 - 서버 이전 완료 21/10/11 글 추가 Stow로 Dotfiles 관리 초판 작성 21/09/18 글 수정 아치 리눅스 xorg-xwayland로 수정 21/09/12 글 추가 도메인별 서버 상태 이후 삭제함 21/09/09 글 수정 GPG 정리 v2.1-2017.07 업데이트 사항 추가\n→ ‘파기용 키 자동 생성’ 이슈 21/09/08 글 수정 GPG 정리 오타 수정, 감사 말씀 추가 21/09/07 글 수정 아치 리눅스 ibus-hangul 변경 사항 적용, GUI 인스톨러 관련 사항 추가 21/09/07 글 수정 GPG 정리 오타 수정, 내용 추가, 참조 사항 추가, 표 추가 21/09/07 글 수정 젠투 리눅스 재작성 21/09/06 글 추가 GPG 정리 초판 작성 21/08/20 글 수정 업데이트 로그 표로 전환 21/07/20 글 수정 아치 리눅스 간소화 21/07/05 글 수정 아치 리눅스 공백, 취소선 등 난잡한 부분 삭제, 수정, 양식 개선 21/06/23 글 수정 아치 리눅스 양식 변경, 가독성 향상, 전체 내용 점검 21/06/23 글 수정 젠투 리눅스 가독성 향상 21/06/15 서버 이전 - 테스트 용도 jeon.dev 신설, jeonwh.com로 이전 21/03/21 글 수정 아치 리눅스 \u0026lsquo;부록 A - 댓글 건의 추가 정보\u0026rsquo;란 신설 21/02/19 구조 수정 - 목차 정비 21/02/19 글 수정 아치 리눅스 전면 업데이트, 댓글 수정 요청 반영, 커맨드 리스트 최신화 21/02/17 글 수정 젠투 리눅스 전체 업데이트 20/12/06 글 추가 빠른 진행 멀티플레이어 번역 완료 20/03/15 글 수정 젠투 리눅스 전체 업데이트 20/03/13 글 수정 아치 리눅스 커맨드 리스트 모음 수정 20/02/26 구조 수정 - 버전 표기법 변경 20/02/26 글 수정 아치 리눅스 whjeon.com 이전 과정에서 생긴 문제 수정 20/01/03 글 수정 젠투 리눅스 오타 수정 19/12/30 글 수정 아치 리눅스 일부 수정 19/12/30 글 수정 젠투 리눅스 genkernel 관련 사항 추가, etc-update 관련 사항 추가 19/12/17 글 추가 젠투 바닐라 커널 가이드 번역 완료 19/10/19 글 수정 아치 리눅스 pacstrap 패치 이슈 → 해당 부분 수정 19/08/17 구조 수정 - 모든 글 → ‘포스트’에서 ‘페이지’로 전환 19/08/06 구조 수정 - 양식 수정 19/08/06 글 수정 아치 리눅스 ftp 미러 수정, 오타 수정, 바뀐 명령어 수정 19/03/30 구조 수정 - 전면 업데이트 19/03/30 글 수정 젠투 리눅스 목차 추가, Git에 올려두었던 자료들 통합 19/03/29 글 수정 아치 리눅스 wordpress 에디터 업데이트, 전면 수정 19/01/01 구조 수정 - wordpress 구텐베르크 업데이트 이슈 18/12/03 글 수정 젠투 리눅스 커맨드 리스트 추가 18/11/10 글 수정 젠투 리눅스 ‘아치 리눅스 설치 가이드’와 양식 통일 18/11/07 구조 수정 - 메인 페이지 수정, 레이아웃 변경 18/11/06 글 수정 아치 리눅스 웹사이트 리뉴얼으로 인한 버전 스킴 변경 18/11/06 글 수정 젠투 리눅스 전면 업데이트, 업데이트 로그에 추가 18/07/25 글 수정 아치 리눅스 pacman-5.1.0 업데이트 관련 이슈로 수정 18/01/05 글 수정 아치 리눅스 신년 맞이 오타 및 구성 수정 17/12/05 글 수정 아치 리눅스 modesetting 이슈, xf86-video-intel 삭제 17/11/17 글 수정 아치 리눅스 오타 수정, 가독성 향상 17/11/15 글 수정 아치 리눅스 직접 재설치 후 수정 17/11/14 글 수정 아치 리눅스 ‘설치 전 주의 사항’ 수정, 버전 부여 17/11/13 글 수정 아치 리눅스 부록 B-각종 설정 변경 추가, 부록 C-커맨드 리스트 17/11/12 글 수정 아치 리눅스 ‘부팅 USB 제작 방법’ 추가, GDM 수정, gst-libav 추가 17/11/11 글 수정 아치 리눅스 ccache 추가, makepkg.conf 추가 17/11/11 글 수정 아치 리눅스 문서 이동, 문서 수정 17/11/07 글 작성 아치 리눅스 초판 작성, 구성 수정, 오타 수정, 이미지 추가 17/11/05 글 작성 젠투 리눅스 초판 작성 17/11/05 시작 - withjeon.com ","permalink":"http://ptrtoj.com/kr/log/","summary":"\u003ch1 id=\"updates\"\u003eUpdates\u003c/h1\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003e🔥 since 2017/11/01\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e꼼꼼히 살펴보니, 잃어버린 기록들이 있어서 아쉽네요..\u003c/em\u003e 😭\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003eDate\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eType\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003ePost\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003eDescription\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e24/12/20\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e구조 변경\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e카스텐 추가\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e24/06/08\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e영문 이름 수정\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e24/04/12\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e구조 변경\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGit 관련 글, 번역한 글 URL 변경\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e24/04/12\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGit tips\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e24/04/04\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eMacOS Tips\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e24/01/11\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e젠투 리눅스 바이너리 패키지\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e24/01/07\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eEmacs Config\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e24/01/05\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e서버 이전\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eJekyll → Hugo\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e23/11/03\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e헷갈리는 Git 용어\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e23/10/17\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e구조 변경\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eObsidian → Github Pages + Jekyll\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e23/09/23\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e구조 변경\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e제텔카스텐으로 전환\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e23/09/22\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e서버 이전\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGithub Pages + Jekyll → Obsidian\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e23/07/23\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eJekyll에 맞지 않는 세부 모두 수정\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e23/07/10\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e서버 이전\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eNotion → Github Pages + Jekyll\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e23/06/14\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e업데이트 로그\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e불필요하게 상세하게 작성된 로그 삭제\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e23/06/12\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e외부 링크 모음\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e데이터베이스로 변경\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e23/06/10\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eBooks\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e독서 기록 신설\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e23/06/09\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e서버 이전\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGithub Pages + Hugo → Notion\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e23/06/09\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e업데이트 로그\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e테이블 형식으로 변경\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e23/04/11\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e서버 이전\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eNotion → Github Pages + Hugo\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e23/02/12\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e계정 변경\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e도메인: ptrtoj.com / 이메일: jeon@domain\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e23/01/30\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e독학 커리큘럼\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/12/22\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e계정 변경\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e도메인: jeonality.com / 이메일: jeon@domain\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/11/26\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e계정 변경\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e도메인: staticintj.com / 이메일: mail@domain\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/11/17\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e구조 변경\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e컨텐츠 체계 정리\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/11/17\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eFreeBSD\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/11/07\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e개인 서식 표준\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e이후 삭제함\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/11/05\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e리눅스에서 한글 입력 정리\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e(이후 ‘한글 입력 방법’으로 제목 수정)\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/11/05\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e옳게 된 키보드 레이아웃\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/11/05\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eISO 8601\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e이후 삭제함\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/11/02\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e구조 변경\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e버전 표기 삭제\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/11/02\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e선호 소프트웨어 목록\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e제목 변경 → ‘통합 세팅 이론’\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/11/02\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e링크 창고\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e‘Useful Links’를 옮김\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/10/31\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e버전 표기\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003evRolling 버전 삭제\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/10/30\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eFedora\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e이후 삭제함\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/10/18\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e구조 변경\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e버전 명명법 변경 → [vYY.MM.DD]\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/09/06\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e업데이트 로그\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e과거 기록의 양식들도 모두 통일함\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/09/05\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e5년만에 ‘결론’ 생김\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/09/04\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e구조 변경\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e‘토글 목차’ 추가, CSS Update\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/09/03\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e업데이트 로그\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e연도 양식 변경\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/08/30\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003esystemd-boot 추가\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/07/08\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e서버 이전\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eNotion 이전 완료\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e22/07/06\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e계정 변경\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e도메인: j.day / 이메일: a@domain\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/12/03\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e염준영님 추가 사항 업데이트\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/11/26\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e구조 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e목차 수정 - 홈 컨텐츠 추가\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/10/26\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e구조 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e21.10 버전 마무리\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/10/23\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e서버 이전\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e서버 재이전\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/10/20\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ePassword\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e현 ‘올바른 비밀번호 설정 방법’초판 작성\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/10/12\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e업데이트 로그\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e작성 규칙 변경 → 대형 업데이트만 작성\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/10/11\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e서버 이전\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e서버 이전 완료\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/10/11\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eStow로 Dotfiles 관리\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e초판 작성\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/09/18\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003exorg-xwayland로 수정\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/09/12\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e도메인별 서버 상태\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e이후 삭제함\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/09/09\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGPG 정리\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ev2.1-2017.07 업데이트 사항 추가\u003cbr\u003e→ ‘파기용 키 자동 생성’ 이슈\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/09/08\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGPG 정리\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e오타 수정, 감사 말씀 추가\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/09/07\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eibus-hangul 변경 사항 적용, GUI 인스톨러 관련 사항 추가\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/09/07\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGPG 정리\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e오타 수정, 내용 추가, 참조 사항 추가, 표 추가\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/09/07\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e젠투 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e재작성\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/09/06\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eGPG 정리\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e초판 작성\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/08/20\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e업데이트 로그\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e표로 전환\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/07/20\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e간소화\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/07/05\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e공백, 취소선 등 난잡한 부분 삭제, 수정, 양식 개선\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/06/23\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e양식 변경, 가독성 향상, 전체 내용 점검\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/06/23\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e젠투 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e가독성 향상\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/06/15\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e서버 이전\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e테스트 용도 jeon.dev 신설, jeonwh.com로 이전\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/03/21\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u0026lsquo;부록 A - 댓글 건의 추가 정보\u0026rsquo;란 신설\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/02/19\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e구조 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e목차 정비\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/02/19\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e전면 업데이트, 댓글 수정 요청 반영, 커맨드 리스트 최신화\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e21/02/17\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e젠투 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e전체 업데이트\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e20/12/06\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e빠른 진행 멀티플레이어\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e번역 완료\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e20/03/15\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e젠투 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e전체 업데이트\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e20/03/13\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e커맨드 리스트 모음 수정\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e20/02/26\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e구조 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e버전 표기법 변경\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e20/02/26\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ewhjeon.com 이전 과정에서 생긴 문제 수정\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e20/01/03\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e젠투 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e오타 수정\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e19/12/30\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e일부 수정\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e19/12/30\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e젠투 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003egenkernel 관련 사항 추가, etc-update 관련 사항 추가\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e19/12/17\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 추가\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e젠투 바닐라 커널 가이드\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e번역 완료\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e19/10/19\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003epacstrap 패치 이슈 → 해당 부분 수정\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e19/08/17\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e구조 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e모든 글 → ‘포스트’에서 ‘페이지’로 전환\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e19/08/06\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e구조 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e양식 수정\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e19/08/06\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eftp 미러 수정, 오타 수정, 바뀐 명령어 수정\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e19/03/30\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e구조 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e전면 업데이트\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e19/03/30\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e젠투 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e목차 추가, Git에 올려두었던 자료들 통합\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e19/03/29\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ewordpress 에디터 업데이트, 전면 수정\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e19/01/01\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e구조 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ewordpress 구텐베르크 업데이트 이슈\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e18/12/03\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e젠투 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e커맨드 리스트 추가\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e18/11/10\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e젠투 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e‘아치 리눅스 설치 가이드’와 양식 통일\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e18/11/07\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e구조 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e메인 페이지 수정, 레이아웃 변경\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e18/11/06\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e웹사이트 리뉴얼으로 인한 버전 스킴 변경\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e18/11/06\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e젠투 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e전면 업데이트, 업데이트 로그에 추가\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e18/07/25\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003epacman-5.1.0 업데이트 관련 이슈로 수정\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e18/01/05\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e신년 맞이 오타 및 구성 수정\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e17/12/05\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003emodesetting 이슈, xf86-video-intel 삭제\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e17/11/17\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e오타 수정, 가독성 향상\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e17/11/15\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e직접 재설치 후 수정\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e17/11/14\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e‘설치 전 주의 사항’ 수정, 버전 부여\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e17/11/13\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e부록 B-각종 설정 변경 추가, 부록 C-커맨드 리스트\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e17/11/12\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e‘부팅 USB 제작 방법’ 추가, GDM 수정, gst-libav 추가\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e17/11/11\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eccache 추가, makepkg.conf 추가\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e17/11/11\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 수정\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e문서 이동, 문서 수정\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e17/11/07\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 작성\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e아치 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e초판 작성, 구성 수정, 오타 수정, 이미지 추가\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e17/11/05\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e글 작성\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e젠투 리눅스\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e초판 작성\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e17/11/05\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e시작\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e-\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003ewithjeon.com\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e","title":"Updates"},{"content":"“시간이 더 있었다면, 더 짧은 편지를 썼을 것이다.”\n→ 파스칼, 「시골 친구에게 보내는 편지(Lettres Provinciales)」, 1657 (맞아요, 그 수학자)\n이름 🔖 Ido Jeon (이전 이름은 WooHyoung Jeon이었으나, 법적으로 개명했습니다)\n거주지 🌏 대한민국 서울\n소셜 🌐 GitHub 💬 IRC: Libera Chat → @jeon\n전공 🎓 한양대학교\n→ 전공 → PPEL ( 철학, 정치, 경제 \u0026amp; 법 )\n→ 하지만 공부는 컴퓨터 공학을 했습니다\n철학 한 가지 일을, 잘 하라 (:= K.I.S.S. + 미니멀 + 헛소리 금지)\n→ 더글러스 매킬로이(Doug McIlroy), 벨 연구소 컴퓨팅 과학 연구 센터장\n둘은 하나이고, 하나는 없는 것이다\n→ 네이비 씰 (하지만 반론을 제기하는 글도 있습니다)\nMBTI 😛 INTJ ( ← 유료 검사도 😕 )\n","permalink":"http://ptrtoj.com/kr/author/","summary":"\u003cp\u003e“시간이 더 있었다면, 더 짧은 편지를 썼을 것이다.”\u003cbr\u003e\n→ 파스칼, 「시골 친구에게 보내는 편지(Lettres Provinciales)」, 1657\n(맞아요, 그 수학자)\u003c/p\u003e","title":"저자 소개"}]