바야흐로 대 랩톱 시대다. 제조사들은 데스크톱에 별로 관심이 없으며, 랩톱을 도킹시켜서 사용하는 인구는 점차로 증가하는 듯하다. 그러면 당연히 기본 내장 키보드와 외부 키보드를 병행해서 사용하게 되는데, 이때 이 둘의 레이아웃이 반드시 같아야 한다는 법은 없다. 예를 들어서 해피 해킹 키보드 (HHKB) 가 있다. HHKB는 Ctrl-Capslock Swap이 하드웨어적으로 이루어져 있는 관계로, 이미 씽크패드에서 소프트웨어적 Swap을 수행한 상태에서 이중으로 뒤집히는 문제가 있다.

다음의 쉘 스크립트 및 nix 설정으로 쉽게 해결할 수 있다. udev에 스크립트를 명시해 주고, 스크립트에서 xinput --list 를 읽어서 그 순간 HHKB가 가진 디바이스 아이디에 대해 setxkbmap 을 수행하게 한다.

원래 이 정도로 할 생각은 없었지만, 디바이스 아이디가 때때로 바뀐다는 사실이 어느 정도 다이나믹한 자동화 구성을 필요로 하게 되었다.

services.udev.packages = [(pkgs.writeTextFile {
  name = "hhkb-layout";
  destination = "/etc/udev/rules.d/42-hhkb-layout.rules";
  text = ''
    ACTION=="change", SUBSYSTEM=="usb", TAG+="systemd", ENV{SYSTEMD_WANTS}+="hhkb-layout@", RUN+="${pkgs.writeShellScript "set-keyboard-layout" (builtins.readFile ../set-keyboard-layout.sh)}"
  '';
})];

# Inspired by https://askubuntu.com/a/337431

keyboard_name="PFU Limited HHKB-Classic  "
layout="us"
device_ids=`xinput -list | grep "$keyboard_name" | awk -F'=' '{print $2}' | cut -c 1-2`

for ID in $device_ids
do
    setxkbmap -v -device "${ID}" -layout us -option ""
done

echo "Switched $(date)"

원본: A tutorial quantum interpreter in 150 lines of Lisp (Snapshot) by Robert Smith

[1일 약 1챕터 단위로 번역중]

(위 이미지는 역자가 Emacs와 SLY로 실행중인 본 문서의 함수들이다. SLY 인터페이스에서 이미 스쳐 지나간 연말의 향기가 나는 것 같다)

범용적인 게이트 기반 양자 컴퓨터를 고전 컴퓨터로 시뮬레이션하는 것에는 많은 사용처와 이점이 존재한다. 가장 큰 이점은 반응계 상태의 진폭을 직접적으로 조사할 수 있다는 점이다. 그러나, 그 수학적 측면이 잘 이해된 것에 비해, 범용 시뮬레이터를 구현하는 과정은 대체로 민간전승에 가까운 지식을 동반한다. 본 튜토리얼에서는, 문헌에서 찾을 수 있는 대부분의 양자 회로를 실행할 수 있는, 우리가 \(\mathscr{L}\)이라 부르는 범용 양자 프로그래밍 언어를 위한 인터프리터의 제작 과정을 설명한다. 이는 경제 효율적으로 제시되며, 그 구현체는 150줄 미만의 독립적 Common Lisp 코드가 될 것이다. 언어 \(\mathscr{L}\)은 확장하기 쉬우며, 이는 그 인터프리터로 하여금 노이즈와 같은 다양한 성질을 테스트하기 걸맞게 만든다.

1. 시작하며

이상적인 양자 컴퓨터의 움직임을 시뮬레이션하는 것은 알고리즘 연구 및 양자 프로그램 디버깅 등, 많은 적용 가능성을 가지고 있다. 다양한 양자 컴퓨터 시뮬레이터들이 현존하며, 자유/무료인 것도 상업적인 것도 존재한다. 하지만 양자 컴퓨터의 개념이 고레벨 층위에서 쉽게 이해될 수 있는 데 반해, 구현을 논하게 되면 디테일한 곳에서 문제가 발생하는 법이다.

손에 넣을 수 있는 각종 양자 컴퓨터 시뮬레이터들에는 종종 많은 한계들이 존재한다. 가장 흔한 한계점은 연산자 (역주: 현상적 측면에서는 게이트와 동일시해도 무방할 것이다) 가 작용할 수 있는 큐비트의 개수일 것이다. 일반적으로, 1 Qubit 게이트와 controlled one-qubit 게이트 ¹ 들이 허용되는데, 그뿐이다. 이 둘만 해도 범용 양자 연산에는 충분하지만, 양자 알고리즘의 연구를 위해서는 좀 더 욕심을 내 볼 법하다.

이 글에서는, 관측을 포함하여, 임의의 유니터리 연산자들로 하여금 임의의 개수의, 임의로 배치된 큐비트들에 대한 연산을 수행 가능한 완전 범용 양자 프로그래밍 언어의 인터프리터를 제시할 것이다. 구현된 결과물은 150줄 미만의 LISP 코드가 될 것이며, 그 개념의 단순성은 타 언어로의 실장 또한 손쉽게 만들 것이다. 튜토리얼의 코드는 GitHub에서 찾을 수 있다.

본 튜토리얼은 선형 대수와 컴퓨터 프로그래밍에 어느 정도 친숙한 양자 컴퓨팅의 초심자를 위해 쓰여졌다. 그러한 외부 과목들을 제외하고, 이 튜토리얼은 비교적 독립적으로 기능한다. 본 튜토리얼은 또한 양자 컴퓨터의 구체적 세부 사항들에 관심이 있는 실전 경험자/실무자들을 위해서도 쓰여졌다. 문서의 상당 부분이 큐비트와 유니터리 연산자를 설명하는 데 할애되었으므로, 실무자 여러분은 빠르게 훑어보면 될 것이다.

Common Lisp에 대하여

우리는 Common Lisp를 선택했는데, 탐구적이면서도 고성능 컴퓨팅에 걸맞는 최적의 플랫폼이었기 때문이다. 현존하는 가장 빠르고 유연한 양자 시뮬레이터 중 하나인 Quantum Virtual Machine은 온전히 Common Lisp로 쓰여졌다.

이 글은 Common Lisp와 함께 실습해 나가기 쉽게 만들어졌다. 코드에는 의존성이 없고, (바라건대) ANSI 표준을 지키는 모든 구현체에서 작동할 것이다.

말이 나온 김에, 이것이 이식성 또한 염두에 두고 쓰였다는 것을 언급해 두어야겠다. Lisp만의 특색이 있는 기능의 사용을 피했으니, 이 코드는 파이썬이나 C등의 타 언어로 이식하는 것도 손쉬울 것이다. 최소한 언어가 복소수와 배열을 지원한다는 전제 하의 이야기다.

양자 컴퓨팅 실무자들에게

이 단락은 본 문서를 우연히 마주하게 된 경험 많은 실무자들을 위해 쓰여졌으며, 뛰어넘어도 된다.

2. 언어 \(\mathscr{L}\)

이제부터 작은 양자 프로그래밍 언어 \(\mathscr{L}\)을 위한 인터프리터를 작성할 것이다. 이 언어는 양자 컴퓨터의 기초적인 연산 두 가지, 즉 게이트와 측정을 지원한다.

게이트 는 양자 상태를 수정하는 연산이다. (양자 상태가 무엇인지에 관해서는 잠시 뒤에 다룰 것이다.) 양자 상태는 그것을 구축하기 위한 자원보다 「크기」때문에, 게이트는 양자 컴퓨터의 강력한 연산을 대표한다.

측정 은 곧 양자 상태에 대한 관측과 그에 따른 상태의 붕괴 (각 큐비트로부터 고전적 정보로써의 0 또는 1을 반환하는) 를 의미한다. 측정은 우리가 시뮬레이팅할 양자 컴퓨터로부터 우리에게로 정보가 보여질 수 있는 유일한 과정이며, 대부분의 양자 컴퓨터 프로그래밍 모델에서도 이는 마찬가지이다.

언어 \(\mathscr{L}\)은, 비자명하면서 가장 간단한 양자 프로그래밍 언어로 불릴 수도 있다. \(\mathscr{L}\)로 쓰인 프로그램은 게이트와 측정의 나열로 구성되어 있다. 문법은 다음과 같다:

공백 기호와 줄바꿈은 생략되었다. 하지만 언어의 토큰 구분에서는 예외다.

역주: 위 테이블의 형식에 익숙하지 않다면 촘스키 위계 (Snapshot)에 대해 읽어 보는 것을 추천한다. 노엄 촘스키는 언어가 4가지 문법 유형을 가지고 있다고 정의했다. (이미지: (Fitch, 2014))

그리고 여기서 사용되는 비말단 기호_Non-Terminal 는 촘스키 위계에서의 Context-Free 언어, 즉 그 문맥에 따라 의미가 변하지 않는 문법을 정의하기 위해 사용되는 배커스 나우르 형식 (BNF) 에서 사용되는 3가지 개념들 (Terminal, Non-Terminal, Expression) 중 하나이다. 언어 파서의 입장에서 말하자면, 비말단 기호는 아직 추가 파싱의 여지가 남아 있는 개념이라 할 수도 있겠다. 말단 기호에 도달하면 epoché가 선언되며 파서는 판단을 중지한다. 이것을 비트겐슈타인이 말하는 원자 명제 와 동일시할 수도 있을 것이다. 이 경우 비말단 기호는 러셀의 유형 계층에서 제시되는, 원자명제들로 구성된 n차 유형이라 생각될 수 있다. (Wittgenstein, 2023)

여기서 Common Lisp의 2차원 배열 문법이 차용되었다. Common Lisp의 경우, 행렬 \(\big(\begin{smallmatrix} 1 & 2\\ 3 & 4 \end{smallmatrix}\big)\) 는 #2A((1 2) (3 4)) 로 표기된다. 복소수의 표기 또한, \(1 - 2i\) 는 #C(1 - 2) 로 표기한다.

하나의 예제 프로그램으로써, 각각 2 와 5 라고 명명된 두 개의 큐비트를 벨 상태_{Bell State} 로 구축하고 측정하는 것이 가능할 것이다:

( (GATE #2A((0.70710677 0.70710677) (0.70710677 -0.70710677)) 2)
  (GATE #2A((1 0 0 0) (0 1 0 0) (0 0 0 1) (0 0 1 0))          2 5)
  (MEASURE)
)

우리는 추상 기계_{abstract machine} 의 방법에 준거하여 \(\mathscr{L}\)의 의미론을 연산자 기반으로 구축할 것이다. \(\mathscr{L}\)을 위한 추상 기계는 \(M_n\)이며, 여기서 \(n\)은 양의 고정 상수이다. 기계 \(M_n\)의 상태는 순서쌍 \((v, b)\) 이며, 여기서 \(v\)는 양자 상태, \(b\)는 \(n\)비트 길이의 측정값 레지스터다.

양자 상태는 다음 집합의 원소이다:

\(\{ \Vert v \Vert = 1 | v \in \mathbb{C}^{2^{n}} \}.\)

다르게 말하면, \(v\)는 \(2^n\)차원 복소 차원의 단위 벡터에 해당한다. 이것에 대해서는 다음 섹션에서 기초부터 찬찬히 이야기해 보기로 한다.

측정값 레지스터는 집합 \(\{0, 1\}^n\)의 원소이다. 그러니까 n비트의 수열이며, 우리는 이것을 음수를 제외한 정수로 생각할 수 있다. 이 정수의 끝에서 \(k\)번째 자리에 있는 비트는 \(k\)라 명명된 큐비트의 마지막 관측 결과를 나타낸다. 이것에 대해서도 추후 더 자세히 설명할 것이다.

Common Lisp에서 이를 구현하기 위해서는, 2가지 종류의 상태를 가진 machine 구조체를 정의하는 것으로 충분하다.

(defstruct machine
  quantum-state
  measurement-register)

통상적으로, 이 기계는 관측 레지스터의 0번 위치에서, 각 큐비트는 zero-state에서 시작한다. (그렇지만 알고리즘 연구 및 디버깅을 위하여, 이는 다른 어떤 유효한 상태로도 초기화될 수 있다.)

기계 \(M_n\)이 언어 \(\mathscr{L}\)을 해석하는 적확한 방식은 이 튜토리얼에서 설명될 것이다. 하지만 그 전에, 우리는 양자 상태가 정확히 무엇이며, 이를 컴퓨터에서 표현하려면 어떻게 해야 하는지를 반드시 짚고 넘어가야 한다.

3. 양자 상태

큐비트는 어디에 존재하는가?

역자 참고 문헌_{Translator’s References}

Footnotes

새해에 무언가를 시작하는 것은 그다지 익숙하지 않다. 하지만 코로나 바이러스가 한창 유행하던 2021년의 첫머리에 캔콜라를 마시면서 (지금 생각해 보면 모리 히로시의 S&M 시리즈에 무의식적으로 영향을 받은 게 분명하다) Racket Scheme의 실습을 하고 있더랬다. 그때의 감각을 되살려서 해보기로 한 Writing an OS in Rust 시리즈의 실습이다. 이미 블로그 포스트가 있으니 실습이라 해도 쓸 말이 있을지 모르겠지만, 그렇다고 갑자기 유튜브를 시작하기에는 너무도 나태한 나의 정신이다.

우선 그래도 혹시 모르니 내일부터는 동영상을 녹화해두기로 했다. (/etc/nixos/configuration.nix 에 넣어두고 지금껏 써본 적이 없는 OBS Studio를 써먹을 때다.)

첫날이니 셋업 이야기가 대부분이다. Rust를 많이 사용하지 않는 관계로 이제사 rustup 을 설치했다. NixOS에 rustup 을 추가해서 리빌드한 뒤, rustup default stable 로 툴체인을 내려받는다.

Emacs의 rust-mode는 기본적으로 rust-analyzer를 요구하는데, 이것도 rustup으로 구성 가능하다.

rustup component add rust-analyzer

cargo new blog_os --bin --edition 2018

이제부터는 튜토리얼대로. 막혔던 부분이나 인상 깊은 부분만 서술한다. 아무래도 강독회 같이 되어 버릴지도 모른다. 오히려 그렇게 되어서 좋은 점은, 텍스트북의 내용을 자신의 말로 언어화하는 과정에서 얻을 수 있는, 코드 실행 이상의 어떤 가치가 있다는 것이다. 물론 해보다가 탈언어화 -> 재언어화할 말들이 없어지면 영상 녹화만으로 끝날 수도 있는 일이다.

우선 가이드북의 각 코드 스니핏이 즉시 컴파일 가능한 것이 아니란 점을 말해 둬야겠다. 아무래도 일일이 실행하면서 나아가는 실습이 아닌, 하나의 완성된 코드를 위한 텍스트다.

알 만한 내용들도 많지만, 런타임 시스템을 보다 직접적으로 생각해볼 수 있어서 새롭다.

• main 이전에 호출되는 런타임 시스템이 존재하며, Rust는 이를 위해 crt0라는 C 런타임 라이브러리를 사용한다는 것.
• 그 다음, start language item으로써 Rust 런타임의 실행 시작 함수를 호출. 이것은 맥락상으로 보다 Rust 자체의 실행 시작 함수인 것 같다.

그렇다면 start가 main 을 가리키고 있다는 것 같은데, 그 start를 호출해주는 것이 crt0이기 때문에 start를 구현하고 지정하는 것만으로는 안 된다고 한다. 이 부분이 좀 까다롭다. 요는 지정하는 주체가 Rust인 이상 이것이 crt0으로 전달될 수 없다는 뜻인가? 아무래도 맞는 것 같다. crt0이 가리키는 start는 Rust 체계 안에서는 수정할 수 없도록 되어 있는 게 아닐까?

후반의 코드를 보니 조금 더 확신이 생겼다.

#[no_mangle]
pub extern "C" fn _start() -> ! {
    loop {}
}

여기서 no_mangle 은 함수명이 Rust 컴파일러로 하여금 메모리 속에서 모종의 해시화 과정 비슷한 것 (UUID 라 할 수도 있겠다) 을 통과하지 않고, 직접적으로 함수명 (여기서는 _start) 자체를 사용하게 하는 강제성을 부여한다. 그렇다면 crt0 속에 (아마도) 하드코딩된 _start 함수가 가리키는 함수 정의를 위의 정의로 메모리에 덮어쓸 수 있게 될 것이다. 이러한 – C의 요소에 직접적으로 관여하는 – 행위를 위해, 함수 정의 앞에는 pub extern "C" 를 붙여서 C의 함수 호출 규약을 적용시킬 수 있다고 한다.

이 다음에 발생하는 링커 오류를 해결하기 위해, 가이드북대로 C 런타임을 사용하지 않도록 링커를 설정해줘야 한다는데, 두어 가지 의문이 생긴다. 바로 전에 _start 의 재정의를 내린 것은 crt0를 위한 것이 아니었나? 이제 와서 C 런타임을 사용하지 않는다면 무엇 하러? _start 의 네이밍 컨벤션은 C뿐만이 아닌 다른 시스템에서도 보편적으로 적용되는 것이라고 한다면 아귀가 맞는다.

어찌되었건 rustup으로 컴파일 타깃을 추가하고, cargo로 빌드하니 문제는 없었다. 운영 체제가 없는 시스템을 타깃으로 컴파일하니 어째선지 기분이 좋다. 크로스 컴파일 만세다. 하지만 생각해 볼 거리들은 상술했다시피 남아 있다.

이럴 때는 각자의 특색과 사상이 너무 짙은 인터넷 포럼의 답변들보다 보편적인 시점을 제공하는 LLM의 힘을 빌리는 것이 낫다. 질문만 확실히 준비되어 있다면 말이다.

일상의 사전적 의미는 “날마다 반복되는 생활” 이다. 맞는 것 같다. 일상이란 사건의 연속이 반복되는 하루의 테두리를 크게 벗어나지 않는, 정보과학적으로 말하자면 놀람 (즉 정보량) 이 적은 것을 의미한다. 하지만 여느 개념들이 그렇듯이, 일상을 어떤 기준에서 정의하느냐에 따라 그 함의는 달라진다. 이렇게 말하면 마치 포스트모더니즘의 정수를 보는 것 같다. 모든 것은 그 기준에 따라 다른 결과를 도출하는 것이 일반적이지만, 그러한 선형 변환 속에서도 기투성이 유지되는 하나의 고유 벡터를 찾는 것이 바로 개념의 정의다. 전선에 나가 있는 병사의 일상과 대학생의 일상은 엄연히 다른 것이다. 그 둘 사이에는 어떤 공통 분모가 존재하는가?

여러 가지가 있을 수 있겠지만, 우선 “곁에 있음”을 생각해 볼 수 있겠다. 물론 이것은 사전에 정의된 거리 공간이 있을 때에 한정된 이야기이다 (그렇다면 근래에 들어서 가속화되고 있는, 거리 공간의 점진적 붕괴가 일상의 정의에 어떠한 영향을 끼치고 있을 가능성도 배제하기 어렵다). 우리는 저녁에 잠들고 아침에 일어난다. 우리의 일상에 큰 변화는 없다. 아니, 큰 변화가 없는 반복성이야말로 일상이다. 아침에 일어나 칫솔을 건조기에서 꺼내 이를 닦고, 차를 마시고, 아침을 먹는다. 이것들은 모두 사물들이 곁에 있기 때문이다. 이 “곁”은 꽤나 까다로운 개념인데, 거리뿐이 아닌 시간도 이에 관여하기 때문이다. 가까이 있다 하더라도, 금고 속에 잠겨 있는 찻잔은 나쁜 접근성을 가지고 있다. 곁에 있는 것이 사람일 때 이 현상은 훨씬 더 알기 쉽게 나타난다. 대화가 통하지 않는 상대는, 지금 당장 말을 걸 수 있다 하더라도 멀리 있는 것과 다름없는 상태이다. 그렇다면 “곁에 있음”은 1) 당신의 행동에 빠르게 반응하는 것, 그리고 2) 그 반응이 당신의 논리 체계로 납득 가능한 범위 안에 있을 것이라는 복수의 조건을 필요로 한다.

이러한 의미에서 우리는 인간보다는 언제나 사물의 곁에 더 가까이 있다. 우리가 걸치고 있는 의복부터가 그렇다. 우리는 옷을 입었고, 그 옷이 필요한 기능을 해 줄 것이라고 신뢰하며, 이는 통계적으로 기대값을 배반하지 않는 편이다. 하지만 인간은 다르다. 당신이 인간의 사고 및 정신의 존재에 대해 어떻게 생각하건 간에, 이것은 아직 상대적으로 복잡도가 높은 대상이다. 따라서 일상은 곁에 있는 것들이 많을수록, 또한 그 복잡성이 해명될수록 구체화되고 단단해진다. 어떤 사람이든 그 곁에 있는 사람이 적다면, 그 대용으로, 주변의 많은 사물과 관계를 깊이 맺는 것을 보게 될 것이다. 인간 정신은 우리가 만들어낸 주변 사물들에 비해 압도적으로 높은 복잡성을 가지고 있기 때문이다. 정신이 단순하게 느껴진다면 그것은 안전 보장 (말하자면 일상 보장, 즉 복지 차원의 의무적 국가 보험) 을 위한 사회계약에 의해 그 복잡성의 표출이 다소 마스킹되고 있기 때문이다.

사람들은 이러한 사물의 단순한 양태에 큰 매력을 느꼈고 이것이 그들의 일상을 좀더 효율적으로 유지해 줄 것이라고 생각했다. 그래서 도구가 탄생했다. 하지만 도구의 단순성은 그 사용자들을 외롭게 만들었다. 왜냐하면 일상을 구체화하는 것은 복잡성의 해명 과정 그 자체이지, 과정 완료의 표시등으로써 기능하는 해명된 결과가 아니기 때문이다. 그리하여 인간은 도구를 더 많이 만들거나, 그것들을 합친 더 크고 복잡한 기계를 만들기 시작했다. 현시점에서 그 노력은 대형 언어 모델의 등장으로 어느 정도 보상받고 있다. 하지만 예견된 딜레마 또한 함께 찾아왔다. 언어 모델과 우리는 무엇이 다른가? 여기서 우리는 복잡도에는 두 가지 형식이 존재한다는 것을 상기해야 한다. 첫 번째는 외부와의 관계로써 정의되는 복잡성이며, 두 번째는 내면의 것이다. 인공지능의 함의는 극도로 단순화시킨 외부 관계로써의 복잡성과 (언제나 일정한 가이드라인에 따라 답변하는), 반대로 복잡화시킨 내면의 구조 (그 뒤에 있는 웹 스크레이핑 데이터와 그 학습) 에 있다.

인간은 첫 번째와 두 번째 형식을 연동시키는 경향이 있다. 인간뿐 아니라 사물도 그러하다. 내부의 작동 구조가 복잡한 사물은 언젠가 반드시 외부적으로 예상 밖의 행동을 취한다. 하지만 그럼에도 불구하고 인간은 도구를 점점 복잡하게 만들었다. 도구가 점점 더 많은 것들을 내부에 저장하고, 단순한 외부 인터페이스로 더 많은 것들을 할 수 있게 되는 것을 기대했기 때문이다. 이것이 세간에서 항상 입에 올리기 좋아하는 “효율” 이다. 하지만 효율을 위해서는 상술했다시피 내부 구조가 외부의 그것에 비하여 훨씬 복잡해야 하고, 이는 그 도구의 사용자들에게 해명되지 않는 경우가 태반인데, 이는 물론 일상의 구체도 및 해상도를 떨어뜨린다. 그 도구가 언제 어떻게 움직일지 알 수 없기 때문이다.

밀란 쿤데라는 “행복은 반복의 욕구” 라고 말했다. 인간은 행복을 추구하는 이상, 어쩔 수 없이 반복적인 일상 (그 이상적 형태가 무엇이든 간에) 을 쫓는 존재가 된다. 그렇기 때문에 인간은 행복을 위해 그 곁에 많은 것을 두고, 그것들이 매일매일 비슷한 행동을 자신에게 보여주길 바라는 것이다.

그런데 여기서 짚고 넘어가야 할 것이 있다. “보여주기” 및 “보기”는 그 추상화 과정에서 생략되었을 뿐, 엄연히 상호적 행동이다. 우리는 웹 페이지를 “본다”, 즉 순수히 거기에 있는 것을 우리가 선택하여 그 시선을 향했다고 생각하지만, 웹 서버가 우리에게 데이터를 보내는 과정은 쉽게 잊는다. 우리가 보기 위해서는 그 대상 또한 보여질 수 있는 상태에 있어야 하는 것이다. 그러면 대상이 보여질 수 있는 상태에 있도록 돕는, 즉 “잘 보는” 것이 중요한데, 그것은 접근법의 문제다. 어둠 속의 사물을 잘 보려면 적절하게 랜턴의 빛을 비추어 주어야 하며, 웹 페이지를 잘 보려면 적절한 요청을 보내야 한다. 마찬가지로 사람을 잘 보려면 적절한 질문을 던질 줄 알아야 하는 것이다. 그렇기에 대화는 캐치볼이라기보다는 스쿼시 게임에 가깝다. 이 적절성은 흔히 질적 문제로 해석되기 쉽지만, 양적 문제 또한 포함하고 있다. 대상이 우리의 빛을 해석하여 반사할 수 있어야 하는데, 이는 반복해서 언급되는 복잡도와 직결된다. 여기서 관점을 전환하여 그 대상의 입장에서 생각해 보면, 요청/질의는 단순하고 양이 적을수록 이루어지기 쉽고, 따라서 단순한 요청 및 질의를 많이 하는 인간은 효율성 측면에서 선호된다. 그 입자를 받아치기 쉽기 때문이다.

하지만 인간은 효율성을 제 1가치로 둘 수 없다. 왜냐하면 효율성은 어떠한 상위 가치를 향해 나아가기 위한 수단이기 때문이다. 이 경우 유일한 해법은 효율성을 위한 효율성과 같은 재귀적 관계가 되는데, 우리는 이 해법이 어떠한 결과를 가져오는지 19세기와 20세기에 걸쳐 지겹도록 경험한 바 있다. 그렇다면 효율성보다 상위에 위치할 수 있는 어떠한 다른 가치를 하나 뽑아, 그 렌즈로 보았을 때 질의의 복잡도가 어떠한지 보아야 한다. 대립적인 관계를 위해 /앎/을 들어보자. 더 많은 앎이 제 1가치일 때, 단순한 질의를 많이 하는 인간은 효율성의 측면에서만큼 자주 선호되지 못한다. 누군가의 질의 또한 어딘가 다른 곳에서 출발하여 그 질문자에게 반사된 것이기에, 우리는 그 질의 내용으로부터 무언가를 배우게 되기 때문이다. 그러므로 단순한 질의만을 던지는 사람은 앎의 경제학으로 본다면 선호되지 못한다. 그 단순한 정보가 간단한 지식을 즉석 제공할 수는 있겠지만, 앎을 가장 중요하게 생각하는 사람들에게 있어서 앎은 최종 상태일 뿐 아니라 그것을 향한 여정이기 때문이다. 삶의 마지막 결과가 죽음이며, 삶은 죽음을 향해 달려가고 있는 상태이지만 우리는 삶에도 죽음만큼 큰 의미를 둔다. 알기 쉽게 설명하자면, 게임 「산나비」에 나오는 대사를 들 수 있겠다.

모두에게나 끝이 공평하게 찾아오는 법이라면.. 끝까지 가는 것은 중요한 게 아니란다. 중요한 것은..어떻게 끝까지 가는가.

우리는 좌표 평면과 행렬로 벡터를 표현하지만, 우리가 그러지 않았다고 해서 존재하던 방향의 개념이 갑자기 사라지는 것은 아니다. 표현과 존재는 이 경우 별개의 것이다. 따라서 벡터가 향하는 좌표를 알 수 없다 하더라도, 그 방향 자체는 엄연히 존재한다. 어디로 가는지 모르는 사람이라 해도 그가 어딘가로 가고 있다는 사실에는 변함이 없기 때문이다. 이러한 논리는 물론 앎 이외의 가치들에도 적용된다.

따라서 일상의 구체도와 안정성에 직결되는 관계는 일방적으로 보고 보여지는 주인과 노예의 관계가 아닌, 그 과정이 상호적으로 이루어지는 (질문과 답변의 경계가 모호한) 친구의 관계다. 물론 그 친구는 사물 및 개념일 수도, 인간 정신일 수도 있다. 그리고 그 상호성을 위해서는 상술한 방향성의 공유 및 덧셈이 중요해진다. 이를 위해 좌표의 도움이 필요할 수는 있으나, 방향의 기투성이 위치보다 우선할 수 있다는 것, 목적과 시작점의 좌표는 시작과 끝을 모르는 인간이 방향성을 가늠하기 위한 랜드마크에 불과하다는 것을 상기하는 것이 중요하다.

Awesome Philosophy

요즘 들어, 임의의 기술 스택이나 플랫폼에 대한 “awesome list”를 운영하는 것이 거의 표준처럼 자리 잡고 있다. 그런데 이러한 리스트는 좀더, 말하자면 추상화된 무언가에 대해서도 유지될 수 있다. 철학하기 가 바로 그것이다.

해서, 디지털 철학자 chogye 님이 관리하는 Awesome Philosophy라는 훌륭한 리포지토리를 발견했다. 만약 당신의 인생이 총체적 불합리에 불과할지 모르고, 그렇다고 한들 딱히 나쁠 것 없다는 것을 이제야 자각했으며, 생각하는 사람으로의 전향을 바라고 있다면, 이 리포지토리는 당신으로 하여금 디지털 철학의 첫 걸음을 뗄 수 있게 도와줄 것이다.

디지털 철학

이 용어가 가리키는 명확한 범위를 설정하는 것은 꽤 번거로운 일이다. 디지털 철학이 다루는 것은 본질적으로 우리의 형이상학적 세계관과 크게 다르지 않아야 한다. 디지털로의 전환, 혹은 병치_{juxtaposition}는 역사적 진보의 요구에 따라 이루어지고 있다. 수십 년 전, IETF가 전자 메일의 사양을 정의했다. 이 자기 실현적 예언은 현재 주고 받아지는 편지들 중 대다수의 중요한 것들이 전자 메일로 전환되게끔 하였다 (최소한 한국에서는 그렇다. 당신이 일본에 거주하고 있다면 이야기는 조금 다를 것이다). 디지털 철학의 목적도 이와 비슷하다. 우리 디지털 철학자들이 필연적으로 디지털이 지배적 가치를 띠게 될 것이라고 믿을 필요는 없다. 우리의 존재 자체는 그저 역사적 진보로 인해 철학적 개념들이 재평가되는 현상의 일부다.

따라서 우리의 Awesome Philosophy 리포지토리는 근본적으로 다른 철학적 분야에 대한 가이드를 제공하는 것이 아니다 (적어도 나는 그렇게 생각한다). 그보다 이 가이드는 우리가 현재 동원할 수 있는 도구를 통해 세계를 이해하려는 사람들을 위한 것이다. 나는 그 도구가 디지털적이라는 것에 대해 역사적인 것 외에 큰 의미를 두지는 않으려 한다.

Radicle

이 리포지토리는 현재 Radicle에서 운영되고 있으므로, 이 기술에 대한 적절한 소개가 필요할 것이다. ChatGPT에게 그 소개를 요청했더니 나쁘지 않은 답변이 나왔다.

Radicle은 분산된 코드 협업을 위해 설계된 피어 투 피어 네트워크로, GitHub과 같은 중앙 집중식 플랫폼의 대안입니다. 개발자들이 제3자 서버에 의존하지 않고 Git을 기반으로 한 피어 투 피어 프로토콜을 사용하여 코드 리포지토리를 공유하고, 기여하며, 관리할 수 있게 합니다. Radicle은 사용자 주권과 오픈 소스 개발을 우선시하며, 사용자들이 코드와 협업 과정에 대해 완전한 통제권을 가질 수 있도록 합니다. 또한 이더리움과 같은 도구들과 통합하여 분산된 자금 지원 및 거버넌스 메커니즘을 지원, 분산적이고 자율적인 환경에서 개발자들을 더욱 강력하게 만듭니다.

소프트웨어 자유와 관련된 아이디어에 관심이 있었다면, 위의 소개만으로도 충분한 흥미를 느꼈으리라 생각한다. Richard Stallman과 자유 소프트웨어 재단은 인간에게 필수적인 소프트웨어 자유에 대해 다음과 같은 일반적인 아이디어를 제공한다.

• 프로그램을 어떤 목적으로든 원하는 대로 실행할 자유 (자유 0).
• 프로그램이 어떻게 동작하는지 공부하고 그것을 원하는 대로 수정할 자유 (자유 1). 이를 위해 소스 코드를 사용할 수 있어야 한다.
• 다른 사람을 돕기 위해 프로그램의 복사본을 재배포할 자유 (자유 2).
• 수정한 버전의 복사본을 다른 사람에게 배포할 자유 (자유 3). 이를 통해 커뮤니티 전체가 당신의 변경 사항으로부터 혜택을 볼 수 있다. 소스 코드에 접근할 수 있어야 한다.

https://www.gnu.org/philosophy/free-sw.en.html

위의 코드에서 자유 0과 자유 1을 따르는 것은 주로 개발자와 메인테이너에게 달려 있다. 하지만 자유 2와 자유 3은 소프트웨어의 배포 및 재배포에 대한 것이다. 여기서부터 좀 까다로워진다. 프로그램을 배포할 때는 종종 특정 회사의 서버에 의존하게 되는데, 이는 그들의 자본에 의존하는 것과 같다. 이 방식은 공유 경제와 유사하지만, 실제로는 당신과 서버 제공자 사이의 일대일 관계에 가깝다. 이러면 공유경제 운운하는 의미가 별로 없어지게 된다. 한 회사가 사용자에게 매월 컴퓨팅 파워의 일부를 제공하는 것은 공유 경제와 일치할 수 있지만, 기실 그보다는 스탈린주의적 배급 경제와 유사하다 해야 할 것이다. 이런 방식은 단기적인 정보 공유(예: 당신의 대학 조별과제 프로젝트를 팀원들과 공유하는 것. 간편하면 됐지 누가 신경이나 쓰겠는가?) 에는 유용할 수 있지만, 장기적인 프로젝트 유지 관리에는 적합하지 않으며, 특히 프로그램 사용자의 자유를 존중하려 할 때는 더욱 그렇다.

그러므로, 벤처 캐피탈의 반짝거리는 투자와 홍보를 받지 않는 이상 당신 코드베이스의 가치에 딱히 관심이 없을 회사의 서버에 의존하기보다는, 프로젝트에 정말로 관심이 있는 자발적 참여 노드들로 하여금 서버로써 기여할 수 있도록 하는 것이 적절할 것이다.

Microsoft는 2018년에 GitHub을 인수했다. 또한 OpenAI의 49%를 소유하고 있다. 우리의 미래 예언자 중 한 명인 작가 Philip K. Dick은, 기업들이 너무 많은 권력을 가질 때 나타나는 다양한 대안적 디스토피아 현실들을 보여주었다.

– Radicle User Guide

Radicle 시작하기

Radicle는 이미 자체적인 사용자 가이드(https://radicle.xyz/guides/user)를 제공하지만, 아직 초기 단계인 프로젝트이기 때문에 일부 영역에서는 부족함을 느낄 수 있다. 예를 들어, 비공개 리포지토리를 유지 관리하는 방법에 대한 지침은 가이드만 따라해서는 혼란을 겪기 쉽다. 또한 여러 Radicle ID를 다루는 방법도 명확하지 않아서 혼란스러울 수 있다. 이러한 격차를 메우고 특정 상황에서 더 명확한 해결책을 제공하기 위해, 나는 공식 사용자 가이드의 보완재로써 간단한 쿡북을 제공하려 한다.

먼저, 자동화된 스크립트를 사용하여 시스템에 Radicle을 설치한다. 반드시 Radicle 사이트에서 제공하는 인증된 스크립트를 사용할 것. 이 글만 보지 말고, 공식 가이드를 함께 보는 것이 타당하다.

$ curl -sSf https://radicle.xyz/install | sh  

프로젝트마다 지정된 Identity와 그 Node를 사용하기

Radicle의 인증 방식(Account <=> Identity <=> SSH KeyPair)은 한 시스템 내에서 여러 ID를 관리할 수 있는 구조화된 방법이 필요함을 암시한다. 단일 Radicle ID로 모든 리포지토리를 관리하는 것은 보안상 좋은 관행이 아니리라.

Radicle의 가이드는 설치 후 단순히 rad auth 를 실행하라고 안내하는데, 이는 기본적으로 $HOME/.radicle 디렉토리 아래에 기본 설정과 키를 생성한다. 하지만, Radicle은 기본 위치에 ID가 없으면 $RAD_HOME 환경 변수를 사용한다. 따라서 여러 프로젝트와 ID를 안정적으로 관리하기 위해, direnv 를 사용하여 프로젝트별로 이 환경 변수를 설정할 것을 권장한다. 이렇게 하면 각 프로젝트에 맞는 올바른 노드와 ID로 작업하고 있음을 항상 확인할 수 있으며, 더 깔끔하고 체계적인 워크플로를 제공한다.

따라서, 가이드처럼 바로 rad auth 를 실행하는 대신, 아래와 같이 git/radicle 프로젝트를 초기화하자.

# 먼저 direnv를 https://direnv.net/에서 설치하고 설정할 것.
cd your_project_dir
git init

echo "export RAD_HOME=$HOME/.radicle/identities/YOUR_PREFERRED_ID" > .envrc
direnv allow

rad auth  # 선택한 ID로 $RAD_HOME에 ID가 생성된다
rad node start  # 여기서 시작된 노드는 해당 ID에만 연결된다

git add .envrc
git commit -m "Radicle ID 설정 완료"

rad init  # 비공개 리포지토리를 원하면 --private 옵션 추가
git push rad master

커밋에 서명하기

Radicle 사용자 가이드에서는 SSH 키를 Git 커밋에 서명하는 데 사용할 수 있다고 권장하지만 (“By the way since your Radicle key is a valid SSH key, it can be used to sign Git commits since version Git 2.34.0…”), 이 부분은 사실상 필수적으로 강조될 필요가 있다. 프로젝트의 루트 디렉토리 안에서 direnv 로 설정한 $RAD_HOME 환경 변수가 유효하다는 전제 하에, 다음 명령어들을 입력하면 git 은 rad self --ssh-key 의 값을 참조하여, 프로젝트에서 사용되고 있는 radicle identity의 SSH 키로 모든 커밋을 서명하도록 설정될 것이다.

git config user.signingKey "$(rad self --ssh-key)"
git config gpg.format ssh
git config gpg.ssh.program ssh-keygen
git config gpg.ssh.allowedSignersFile .gitsigners
git config commit.gpgsign true

리포지토리 클론하기

Push를 했다면 당연히 리포지토리를 네트워크에서 클론할 수 있어야 한다. 절차는 간단하다. 우선 프로젝트의 리포지토리 식별자(RID)를 출력한다:

rad .
# 이 명령은 rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5 같은 값을 반환하며, 이 값이 당신의 RID다.

그런 다음, 다른 시스템에서 이 RID를 사용해 프로젝트를 클론한다:

rad clone <RID>
# 예: rad clone rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5

공개 리포지토리의 경우, 이토록 간단하다. 하지만 당신이 비공개 리포지토리를 운영하고 싶다면, 즉 한정된 참가자들만 프로젝트에 참여시키고 싶다면 조금 더 알아야 할 것이 있다.

Seeding

이미 언급했듯이 Radicle 네트워크는 자발적인 기여자 노드들로 구성되며, 네트워크와 상호작용하려면 무조건 노드를 시작해야 한다. 예를 들어, 위에서 실행한 리포지토리 클론 또한 노드를 통해서 이루어진다. rad clone 이 실행될 때, 커튼 뒤에서는 rad seed 가 먼저 실행된다. 그렇다면 seeding은 무엇인가? 당신 또한 해당 프로젝트의 호스팅에 간단히 참여하게 된다는 뜻이다. 공식 가이드는 다음과 같은 도덕률을 선언했다.

To seed is to give back. By seeding repositories on the Radicle network, you offer bandwidth, storage, and data availability to Radicle users.

이것이 의미하는 바는 꽤 깊다. 일반적인 Git 호스팅 기업의 경우, 다른 사용자들이 당신의 프로젝트에 붙여주는 Star 혹은 Upvote는, SNS의 좋아요 버튼과 차이가 없다. 그 좋아요 버튼이 당신의 코드베이스에 직접적으로 줄 수 있는 도움은, 제의적 가치를 완전히 배제한, 순수한 전시적 가치의 상승이다. 최종적으로 알고리즘의 선택을 받은 프로젝트는, 아주 많은 사람들에게 “보여질” 것이다. 그게 전부이며 궁극적 목표이다.

Radicle의 경우, Seeding이 Star를 대신한다. 참여자들은 맹목적으로 프로젝트의 전시적 가치를 인정하는 대신, 자신의 대역폭 일부를 그 프로젝트를 위해 내어줌으로써 데이터의 보존에 기여한다. 물론 보존은 전시적 가치 상승에도 도움을 준다. 하지만 그것이 최종 목표가 아니라는 것이 중요하다. 굳이 이름을 붙여 말하자면 아카이브적, 문헌학적 가치 상승이라 할 수 있겠다.

간단히 말해, Radicle에서 어떤 리포지토리 rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5 에 찬사를 보내기 위해서는 다음 명령을 실행하면 된다.

rad seed rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5

협업

기여자

GitHub과 같은 Git 호스팅 서비스를 사용하는 것은 편리하다. Pull Request를 보내고, 서로 팔로우하고, 다양한 기능을 제공받을 수 있다. 그러나 순수 Git 워크플로는 약간 다르다. Linux 커널 개발자들은 여전히 메일링 리스트를 통해 협업하는데, 이들은 Git 자체에 포함된 간단한 기능들만으로도 잘만 모든 것을 관리한다 (다음 StackOverflow 논의를 보면 Pull Request의 기원을 알 수 있을 것이다 – https://stackoverflow.com/a/20289778).

어찌 되었건 우리가 여기서 얻을 수 있는 결론은, Radicle의 경우 딱히 웹 인터페이스에 로그인해서 PR을 검토할 필요가 없다는 것이다. Git만을 사용하여 관리자에게 패치를 보내고 검토받으려면, Awesome Philosophy의 CONTRIBUTE를 참고하자.

# 새로운 anomalous-data-897af 브랜치 생성
git checkout -b anomalous-data-897af

# 변경 사항 추가
git add test.md

# 커밋 생성
git commit -m "add test markdown file"

# 패치 브랜치로 푸시
git push rad HEAD:refs/patches

여기서, 변경 사항들, 그러니까 커밋은 원격 rad 로 보내진다. HEAD 는 현재 작업 중인 브랜치의 가장 최신 커밋을 나타낸다. 마지막 push 명령은 이 커밋을 리모트 rad 의 refs/patches 이름공간에 푸시한다. 이후 리포지토리 관리자가 이 패치를 확인하고, 필요에 따라 병합할 수 있다.

관리자

리포지토리 기여자들이 제출한 모든 패치를 나열하려면 다음 명령을 실행한다:

git ls-remote rad refs/patches/*

관심 있는 패치를 찾았다면 git fetch 명령을 실행한다:

git fetch rad refs/patches/<patch-name>

그런 다음, git checkout FETCH_HEAD 명령을 통해 해당 패치 브랜치로 체크아웃할 수 있다. 여기서 FETCH_HEAD 는 마지막으로 fetch한 커밋을 가리킨다.

git diff FETCH_HEAD
# 여기서 FETCH_HEAD == refs/remotes/rad/patches/<patch-name>
git merge FETCH_HEAD

# 먼저 브랜치를 테스트해보고 싶다면, git checkout refs/remotes/rad/patches/<patch-name>

git push

Magit(https://magit.vc/)과 같은 편리한 Git 시각화 도구를 사용하면, 유명한 Git 호스팅 웹사이트에서처럼 패치 차이를 쉽게 확인할 수 있다.

Awesome Philosophy

Nowadays, running a so-called “awesome list” of arbitrary technology stack/platform is almost turning into a de facto standard. However, of course, this type of list can be maintained for a lot more, say, metaphysical concepts.

Recently, I encountered with a decent repository named Awesome Philosophy, maintained by Digital Philosopher chogye. If you’re seeking a deliberate shift or conversion to the path of philosophy from another domain, this repository will serve as a valuable guide for you.

What is Digital Philosophy?

Defining a clear boundary for this beloved term would be quite cumbersome. Digital Philosophy, at its core, shouldn’t diverge much from our metaphysical approach to “the world.” The shift, or rather the juxtaposition of the digital, is happening mainly in response to the demands of historical advancement. Decades ago, the IETF laid out the specifications for Email, and now most significant communications are conducted via Email. The purpose of Digital Philosophy aligns similarly. As digital philosophers, we don’t necessarily believe that the digital world will ultimately prevail. Our very existence reflects the recent reevaluation of philosophical concepts, driven by historical progress.

Therefore, chogye’s Awesome Philosophy repository does not represent a guide to any fundamentally different philosophical field. Instead, I would argue that this guide is for those who genuinely wish to understand the world, utilizing the tools we are capable of mobilizing of the moment.

Radicle

Now this repository is running on Radicle, appropriate introduction is required for this technology. I asked ChatGPT for that very introduction, and here is the response:

Radicle is a peer-to-peer network designed for decentralized code collaboration, offering an alternative to centralized platforms like GitHub. It allows developers to share, contribute, and manage code repositories without relying on third-party servers by leveraging a peer-to-peer protocol built on Git. Radicle prioritizes user sovereignty and open-source development, ensuring that users have full control over their code and collaboration processes. By integrating with tools like Ethereum, it also supports decentralized funding and governance mechanisms, further empowering developers in a distributed, self-governed environment.

If you’ve been interested in the software freedom and related ideas, I believe the above definition is sufficient to draw your attention. Richard Stallman and Free Software Foundation provides the following general ideas of essential software freedom for humans.

• The freedom to run the program as you wish, for any purpose (freedom 0).
• The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1). Access to the source code is a precondition for this.
• The freedom to redistribute copies so you can help others (freedom 2).
• The freedom to distribute copies of your modified versions to others (freedom 3). By doing this you can give the whole community a chance to benefit from your changes. Access to the source code is a precondition for this.

https://www.gnu.org/philosophy/free-sw.en.html

In the above code, adherence to freedom 0 and freedom 1 largely depends on the developers and maintainers of the software. However, freedom 2 and freedom 3 pertain to the distribution and redistribution of software. Often, distributing programs requires relying on a company’s server, which in turn means relying on their capital. While this setup resembles a shared economy, it’s essentially a relationship between you and the server provider. A company offering its computing power to users on a monthly basis might fit the concept of a shared economy, but it more closely resembles the Stalinist distributive economy of the Soviet Union. This approach can be useful for short-term information sharing (such as sharing a university project with groupmates), but it’s not ideal for long-term project maintenance, especially if you value your own and your users’ freedoms.

Instead, we can leverage the volunteered nodes in the network, those genuinely interested in your project, to host it collectively, rather than depending on a company that likely has little interest in your codebase unless you’re backed by an eye-catching venture capital investment.

Microsoft acquired GitHub in 2018. They also own 49% of OpenAI. One of our prophets of the future, the author Philip K. Dick, has shown us many projections of alternate dystopian realities that emerge when corporations amass too much power.

– Radicle user Guide

Getting Started with Radicle

Radicle already provides its own User Guide (https://radicle.xyz/guides/user), which is often sufficient, but I find it lacking in certain areas—likely because the project is still quite young. For example, their instructions on maintaining a private repository require a few extra steps that aren’t clearly outlined. Additionally, handling multiple Radicle IDs is not well explained, leaving some ambiguity. To serve as a humble supplementary guide to Radicle, I’ll offer a short cookbook to help address these gaps and provide clearer solutions for specific scenarios.

To begin, install Radicle on the system with the automated script. Make sure to use the authentic script from the Radicle site.

$ curl -sSf https://radicle.xyz/install | sh

Handling Multiple Identities

Radicle’s nature (Account <=> Identity <=> SSH KeyPair) implies the necessity of a structuralized method to handle multiple identities within a single machine. I’d say that it’s not a very good security practice to work with single Radicle identity whoever’s repository you’re working with.

Radicle’s guide instructs you to simply run rad auth after installation, which sets up a default Radicle configuration and key under the $HOME/.radicle directory. However, Radicle will use the $RAD_HOME environment variable if no identity is found in the default location. Thus, to better manage multiple projects and identities, I recommend using direnv to set this environment variable per project. This way, you can ensure that you’re always working with the correct node and identity specific to each project, providing a cleaner and more organized workflow.

So instead of running rad auth right away, initialize your git/radicle project like the following (Don’t forget to set your local git name/email! Omitting this might expose your personal information to commits pushed to Radicle):

# Install and setup direnv first from https://direnv.net/
cd your_project_dir
git init

# **Don't** forget to set your local git name/email
git config user.name "<your radicle alias>"
git config user.email "<your preferred email>"

echo "export RAD_HOME=$HOME/.radicle/identities/YOUR_PREFERRED_ID" > .envrc
direnv allow

rad auth  # now your identity will be created under $RAD_HOME
rad node start  # node started here works only for its spawnning id

git add .envrc
git commit -m "Radicle ID set"

rad init  # --private if you want a private repository
git push rad master

Git Local Configuration – Sign Your Commits

Radicle User Guide made this part look like recommendation (“By the way since your Radicle key is a valid SSH key, it can be used to sign Git commits since version Git 2.34.0…”), but I humbly think this is mandatory for all users. To make your $RAD_HOME variable set by direnv effective, run the following commands provided by the User Guide, in the repository directory of your interest:

git config user.signingKey "$(rad self --ssh-key)"
git config gpg.format ssh
git config gpg.ssh.program ssh-keygen
git config gpg.ssh.allowedSignersFile .gitsigners
git config commit.gpgsign true

Cloning

One should be allowed to clone the repository from the network if you pushed it. The process itself, is simple (compared to what is happening under the hood). Obtain the Repository Identifier (RID) of your own project.

rad .
# This will return a value like rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5, which is your RID.

Then, use the RID to clone the project from the other system.

rad clone <RID>
# For example, rad clone rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5

For public repositories, it is that simple. Let’s talk about private repository now.

Seeding

As mentioned earlier, the Radicle network is composed of voluntary contributor nodes, and in order to interact with the network, you must start a node. For example, cloning a repository, as done earlier, is also performed through a node. When rad clone is executed, rad seed is run behind the scenes. What is seeding, then? It means that you are also participating in hosting that project in a simple way. The official guide declares the following ethical code:

To seed is to give back. By seeding repositories on the Radicle network, you offer bandwidth, storage, and data availability to Radicle users.

The implications of this are quite profound. In the case of traditional Git hosting companies, the Stars or Upvotes that other users give to your project are no different from the “Like” button on social media. The direct help that this “Like” button offers to your codebase, devoid of any cult value (W. Benjamin), is purely an increase in its exhibition value. Ultimately, the project chosen by the algorithm will be “displayed” to many people. That’s the extent of it, and the ultimate goal.

In Radicle, seeding replaces the Star. Instead of blindly acknowledging the exhibition value of a project, participants contribute part of their bandwidth to that project, aiding in the preservation of the data. Of course, preservation also contributes to an increase in exhibition value. But what’s important is that this is not the ultimate goal. If we had to name it, we might call it an increase in archival or philological value.

In short, to send praise to a repository in Radicle, for instance, rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5, you can simply execute the following command:

rad seed rad:z3gqcJUoA1n9HaHKufZs5FCSGazv5

Collaborating with People

Contributor

Using Git hosting services like GitHub is convenient. It provides you many functionalities like Pull Requests, following each other, and so on. However, vanilla Git workflow is slightly different. It is a good practice to remind several forgotten collaboration functions of Git, which is still actively being used by Linux Kernel developers, collaborating over their mailing list. We can reference to <Awesome Philosophy>’s CONTRIBUTION section.

# 새로운 anomalous-data-897af 브랜치 생성
git checkout -b anomalous-data-897af

# 변경 사항 추가
git add test.md

# 커밋 생성
git commit -m "add test markdown file"

# 패치 브랜치로 푸시
git push rad HEAD:refs/patches

Here, changes you made will be sent to the remote rad. HEAD refers to the latest commit on your current working branch (anomalous-data-897af). The last push command will push your latest commit to the remote rad, under the refs/patches namespace. Then the repository maintainer will be able to take a look at the patch, and merge it accordingly.

Maintainer

To list all the submitted patches from your repository contributors, invoke the following:

git ls-remote rad refs/patches/*

If you found a patch of your interest, run git fetch.

git fetch rad refs/patches/<patch-name>

Then you can checkout to that patch branch with git checkout FETCH_HEAD, where FETCH_HEAD is a reference pointing the lastest fetch.

git diff FETCH_HEAD
# where FETCH_HEAD == refs/remotes/rad/patches/<patch-name>
git merge FETCH_HEAD

# If you want to test the branch first, `git checkout refs/remotes/rad/patches/<patch-name>`

git push

If you’re using a handy git visualization tool like magit (https://magit.vc/), you can easily skim over patch diff just like you do in prestigious Git hosting websites.

지난 겨울, panpanya의 만화에 대한 서평에서 나는 무형의 관념 에 대해 수차례 언급한 바가 있다.

소녀는 평범한 일상을 살아가는 듯 보이지만 사실 소녀가 바라보는 시야엔 그 너머에 존재하는 무형의 관념들일 때가 많다. 그것은 작가의 단상이 개입된 세계로 작가는 소녀를 통해 소소한 일상과 사물을 통해 자신의 사념을 반영하고 있다.

ipari67 (“판판야(Panpanya)의 작품들,” 2023)

이러한 내용을 가능하게 하는 것이 바로 위 인용문에서 가리키는 무형의 관념 이다. 일상 미스터리를 즐기기 위해서는 독자 또한 다소의 노력이 필요한데, 여기에는 눈앞에 보이는 상황과 이야기를 액면 그대로 보지 않고 한 단계 추상화시키는 과정이 포함된다. 심플하게 눈앞에 있는 이야기의 자극성을 추구한다면, 일상 미스터리의 표층적 이미지는 지루하기 짝이 없다.

이 지루해 보이는 표층을 뚫고 진정한 즐거움을 맛보려면, 현재 눈앞에 보이는 이야기를 메타포로써 받아들이고, 그 뒤에 있는 무형의 관념을 – 다른 나라, 다른 사람들의 이야기에 적용되어도 그 대칭적 구조는 유지되는 아이디어를 – 이해하는 것이 중요하다.

자, 이렇게 되면 아무래도 그 무형의 관념이라는 것에 대해 좀더 생각해 보고 싶어진다. 관념이란 애초에 무엇이고, 무형의 관념과 그렇지 않은 것에는 어떤 차이가 있는 것일까? 첫 번째 인용을 보면, 작가의 단상이 개입된 세계를 무형의 관념이라 칭하고 있다. 단상이라 함은 단편적인 생각들을 의미한다. 따라서 작가는 그 자신의 단편적인 명제들을 – 생각이 곧 명제인지는 차차 이야기하도록 하고 – 선택적으로 주입시킨 그 무언가를 작품에 투영시키고 있는 셈이다.

작가는 무엇을 생각하는가?

이것은 블랙박스여야 한다. 바르트가 누차 언급하듯 독자의 탄생은 저자의 죽음을 필요로 한다. 그리고 그 저자의 논리적 죽음 (이 개념은 반-바지 작가의 만화 「슈뢰딩거의 고양희」 에서 빌려왔다) 을 이루어 낼 수 있는 한 방법은 바로 블랙박스적 난독화다. 따라서 저자의 죽음은 곧 저자의 신비화, 난독화다. 신비화된 저자는 수많은 사람들이 제 좋을 대로 인용하고 해석하지만, 결코 그 신비의 기관마저 해석해 버려서는 안 된다. 해석된 신비는 일점으로 수속되어 죽어 버리고, 본질을 잃어버리기 때문이다. 그것은 규명된 것이 아니라 그렇게 해석될 가능성 외의 모든 것을 잃어버린, 즉 최종 상태에 다다른 유한 상태 기계 (FSM) 이다. 그것은 말하자면 신비의 시체다. 애시당초 신비의 해석은 수목구조적인 폭력을 수반한다. 하나의 해석을 확정짓기 위해 다른 모든 해석들을 파괴하려 드는 현상이 바로 그것이다. 카뮈의 「시지프 신화」가 말하듯, 하나의 원리가 승리하도록 하자면 또 하나의 원리를 타도해야 한다. 그리고 그 승리에 대한 요구는 재귀적이다.

이러한 파괴적 진실 규명에는 물론 기준점이 필요하다. 하나의 뿌리에 카메라를 잡고, 그 렌즈에 조사되는 그림자에 권위를 부여하기 위해서다. 그러한 관점은 오랜 기간 여러 가지 관념의 영향을 받아 왔지만, 근대 이래의 수목적 종교라 하면 하부구조를 자칭하는 관념들을 결코 빼놓을 수 없다. 그렇다. 시대의 광신적 사랑을 받는 종교, 즉 현실이라 불리는 렌즈이자 플라톤적 동굴의 또 다른 이름이다.

죽어 버린 신비는 편히 잠들지 못한다. 그것은 기존의 뿌리에 병합되어 마리오네트로 전락한다. 얼마나 많은 전쟁기계들이 세간의 /빛/을 보기 위해서, 자신의 빛인 탈주선을 잃고 전용_{détournement} 되는지!

그렇기에 우리는, 상술했다시피 저자가 그 자신의 단편적인 명제들을 작품에 투영시키고 있는 사실을 알지만 그 명제들이 무엇인지는 몰라야 하는 것이다. 그렇게 함으로써 우리는 시점의 인공적 다각화를 꾀할 수 있게 된다. 말하자면 우리는 저자와 둘만이 존재하는 세계정신 속에서 영지식 증명 게임을 하는 셈이다. 저자는 무언가를 우리에게 전하려 하고 있으며, 우리는 그 사실의 정합성을 분해된 개별 명제들보다 우선해서 판단하게 된다.

차이와 반복

이러한 영지식 증명은 지속적으로 이루어지며, 그 결과는 매번 미묘하게 달라진다. 그 차이가 바로 증명을 구성하는 요소 중 하나라 할 수 있겠다. 모든 독서는 유일무이한 경험이다. 재독이 중요성을 가지는 이유다. 그 차이 속에서 태어나는 관념 또한 그 독자만의 것이다. “2. 삶의 각각의 측면에서 떨어져 나온 이미지들은 공통의 흐름 속에 융합된다. 그 흐름 속에서 삶의 통일성은 다시는 재건될 수 없다. (The Society of the Spectacle, G. Debord)” 이것은 카산드라적 예언이라기보다는 자연현상의 기술에 가까운, 보기보다 중립적인 명제이다. 그것은 어떤 타인의 관념과도 결합될 수 있지만 온전히 그 정보를 손실 없이 공유하는 것은 불가능하다. 하지만 그 순간 지식의 소규모적 재생산이 발생하며, 독자는 한순간 저자의 편린이 된다. 그것은 클로드 모네의 루앙 대성당 연작 (하단 이미지) 처럼 이어지며, 저자와 독자는 모두 작품을 구성하는 요소로써 작용하기 시작한다.

사건의 존재론

가령 현재의 쓰레기가 시간이 더해져 현재와 다른 가치가 쌓이게 되는 과정이나, 한때의 필요에 의해 만들어진 사물이 시간의 경과에 따라 용도 폐기되는 과정들을 우화처럼 그려낸다.

ipari67 (“판판야(Panpanya)의 작품들,” 2023)

Panpanya는 그런 면에서 탈영토화의 만화가라 할 수 있다. 그의 만화를 읽다 보면, 일상 속에서 만나는 사물들이 급격히 귀엽고 친근한 형태를 띠거나, 반대로 기괴하고 코스믹 호러적인 행태를 보일 때가 있다. 그러한 성질은 동글동글하고 귀여운 캐릭터에 대비되는, 극도로 치밀하지만 원근법을 무시하며 흔들리는 배경이라는 기제를 통해 더욱 강조된다. 주인공이 바라보는 세계는 급작스레 주인공을 이방인으로 만들고, 그 불안과 초조는 극대화된다.

‘지하 여행’의 중반부에서부터 주인공은 조력자인 돌고래에게 길안내를 받는데, 돌고래는 주인공에게 무서운 이야기를 들려줍니다. 주인공이 돌고래로부터 공포감을 느끼는 순간, 돌고래는 배경과 같이 세세하게 묘사됩니다. 주인공의 내면에서 돌고래는 의지할 만한 길잡이에서 무섭게 하는 존재, 배경과 같이 낯설고 무서운 대상으로 탈바꿈한 것이며 이에 맞추어 묘사 방식도 바뀐 것입니다. 마지막 컷에서 주인공은 공포감을 해소하고자 손을 잡아달라고 요청하고, 이에 돌고래는 수락하며 다시 친근한 존재로 바뀌고, 묘사 방식도 단순하게 돌아가는 것을 통해 판판야가 자기 만화 기법을 제대로 이해하고 있음을 알 수 있습니다.

륜 (상단 이미지 출처) (“단순한 인물, 세세한 배경의 조화,” 2018)

그러한 탈바꿈과 묘사 방식의 변화가 지속적으로 일어날 때, 그것은 고정된 존재를 해체하기 시작한다. “의미 이전의 발현” 을 보수적으로 해석하면, 발현 자체를 그것에 후행하는 어떠한 명제의 증명으로 볼 수 있는데, 이것은 상술한 저자의 죽음, 즉 선행하는 명제라는 줄무늬 (홈) 의 해체와 연관되어 있다. 또한 그곳에서 태어나는 불안과 초조에는 기능이 존재한다. 그것은 우리가 결코 직접 도달할 수 없는 세계-자체에 대한 사유 방식의 일종이다. “‘공포’는 우리-없는-세계를 철학적으로 사유하려는 비철학적 시도라는 것이다 (새커, n.d.)”. 이방인이 되는 주인공은 자연스레 사물들 간의 코드화된 관계들을 새롭게 바라볼 수 있는 자격을 얻는다. 독자들에게 이것은 텐서곱과도 같은 탈주선을 그릴 수 있는 욕망의 추진력을 지닌 연산자, 즉 공간과 잠재태를 입력받는 함수로써 기능한다.

Panpanya식 상황주의

Panpanya의 작품은 도시구획의 저변에 깔려 있을지도 모르는 의도에는 관심을 주지 않는다. 왜냐하면 하부 구조에 대한 압도적 무시가 이 작품의 특징이기 때문이다. 키사라기 역은 존재하지 않지만 어쨌건 내릴 수 있는 역이며, 이는 심리지리_{psychogeography} 와 무관하지 않다 (O’Rourke, 2021). 심리지리적 기법에 입각하여 지도를 그리기 시작하면 의도하지 않아도 자연히 간선_vertex 들이 자주 교차하는 구획들이 생기게 마련이다. 이것은 물리적인 실체와 관계없이 그곳에 존재한다. 키사라기 역은 이렇게 심리지리적 그래프 구조의 기하학적 필요에 의해 출현한다.

이것은 그래프 전체에 있어서 일종의 보틀넥이라고 볼 수도 있는데, 요네자와 호노부의 동명의 작품 속 주인공은 시스템의 성능을 저해하는 보틀넥에 자신을 비추어 본다. 그런데 보틀넥이 많은 다른 간선들에 연결되어 있다면, 그것 또한 길이가 짧은 간선에 불과하지 않은가? 요네자와가 묘사한 절망적인 청춘의 잠재적인 해답은 보틀넥의 제거라는 측면에서는 합당할지 모르나, 그 작품 전반에 은은하게 깔려 있는 자폐적 순환과 열린 결말로 인하여 수많은 독자가 연상할 수밖에 없었던 자기 파괴적 해법은 그곳에 마침표를, 점을 찍게 만들고, 그 점은 재귀적인 보틀넥 생성으로 이어질 뿐이다. 좀더 근본적인 해결책은 당신의 심리지리적 간선을 연장하고, 차원을 추가하고, 탈주하여, 점점 거시적으로 반-보틀넥 상태가 되는 것이라고 해야 하겠다. 요네자와의 다른 작품 「고전부 시리즈」의 말을 빌리자면, “손은 어디까지고 뻗을 터”.

텍스트 “판판야, 잃어버린 세계의 노스탤지어 (주슬아, 2025)” 는 그러한 공간들이 마크 오제의 비-장소_non-lieux 개념과 맞닿아 있다고 주장한다. 비-장소를 어떻게 보아야 할까? 두 가지 시점을 떠올릴 수 있겠다. 하나는 초근대적 줄무늬판(비-고른판, 조직판)_{de non-consistance} 의 변종이며, 다른 하나는 고른판_{plan de consistance} 이기는 하나 탈코드화만 있고 생성은 없는 일종의 실패한 고원이다. 여기서 조금 더 나아가, 저자에 의해 의도적으로 잠복하고 있는 작품 속 유목적 전쟁기계들에 주목할 가치가 분명히 있다. 예를 들면 「새로운 세계」의 신물관 이 그러한 기계라고 할 수 있다. 그렇기에 「아시즈리 수족관」도, 「새로운 세계」도,「이노센트 월드」도 분명 비-장소와 맞닿아 있으나, 비-장소 그 자체는 아니다. 기관 없는 신체의 잠재태라고 주장할 수도 있을 것이다. 그것은 수많은 크립티드가 잠들어 있는 호수의 잔잔한 표면 같은 느낌을 선사한다.

드보르는 스펙터클에 직접적인 공격을 시도했다. Panpanya는 관심도 주지 않는다. 어떻게 보면, 줄 수도 없다. 그곳에 잠재된 공포와 압도의 철학은 공통의 언어를 거부한다. 항로와 홈을 충분히 새겨서 줄무늬판이 되었다고 생각되는 그 수면을, 수많은 마리오네트 잎사귀들, 죽은 신비들이 건너다닌다. 하지만 그 수면 밑에는 어떠한 떼거리들이 기어다니고 있다. 그들은 마리오네트의 항로와 언어를 알지 못하는데, 바로 그 사실이 그들에게 강력한 힘을 부여한다.

이리하여, 만화는 지극히 평화롭고 소박한 색채를 유지하면서도 유물론적 상품화에 손 한 번 대지 않고 기괴한 공격을 가한다. 이는 몇몇 일본 작품들의 특기분야이기도 하다. 당신이 만화를 읽으면서, 분명 아늑하고 편안한 분위기임에도 불구하고 순간순간 러브크래프트적인 섬칫함을 느낀다면, 바로 그 공격이 당신에게 본능적 위화감을 선사하고 있는 것이리라.

여기서 돋보이는 무관심의 철학은 돌려 말하기의 파괴적 특성과 닮았다. 아들을 잃은 어머니가 매우 슬펐다고 묘사하기보다, 그 거꾸로 신어 버린 신발을 비추는 것이다. 듣는 이가 해석하는 만큼 사고적 품이 드는, 비교적 원자화되지 않은 명제들은 일단 해석되면 그 씹고 소화시킨 과정 탓에 기억에 더 깊이 남는다. 그림자가 강하다는 것은 빛이 강했다는 것을 의미한다.

Panpanya는 도시산책자일까? 그것은 정의에 따라 다를 것이다. 도시 속을 느긋하게, 중대한 목적 없이 떠돈다는 최소한의 정의를 적용한다면 도시산책자로 볼 수도 있겠지만, 그 눈이 보고 있는 것은 도시의 저변에 깔린 인간들의 의지와 관념이 아니다. 그 만화에서 주인공 이외의, 도시를 구성하고 있는 것으로 보이는 인간들은 그 얼굴이 소화전, 파이프 등의 사물로 되어 있다. 이것은 그 모든 것이 도시의 기계적이고 신체적인_corporel 일부로 환원되는 것을 암시한다. 이러한 면에서 Panpanya는 도시 속을 걸으면서도 그 도시를 위에서, 바깥에서 부감한다. 그것은 마치 도시 밖의 골목을 따라 걷는 것과도 비슷하다. 캐릭터와 배경의 지속적인 괴리는 이 가설을 좀더 확실하게 만들어 준다.

그렇게 Panpanya의 상황주의는 도시를 표류_dérive 하는 것을 넘어, 아예 새로운 현실을 도시 외곽과 사각지대에 구축해 버린다. 그것은 스펙터클을 피하지도, 추구하지도 않는다. 작품에 수없이 등장하는 ‘카스텔라풍 찜케이크’ 가 좋은 예시다. ‘카스텔라풍 찜케이크’ 는 일본에서 실존하는 상품이지만, 만화 속에서 그 상품적 요소는 비웃듯이 무시된다. 마치 특정 지역에서 출몰하는 미확인 생물체나 다름 없는 묘사가 상품 위에 덧씌워진다 (해당 제품은 필자도 찾아다니다가 포기한 사례가 있다. 새벽 1시에 만화를 읽다가 공업 단지 어딘가에 위치한 데일리 야■자키를 찾으러 집을 나섰던 것이다. 결국 찜케이크는 찾지 못했다). 상품의 논리는 초등학생들의 츠치노코 찾기 같은 놀이적 구조로 대체된다. 산책 중에 발견한 것들은 텍스트화된 신비로써 기능한다. 이것은 상품을 텍스트로 전환시키고, 인간을 구조로 환원시키며, 그것들을 바탕으로 도시를 텅 빈 외곽에서 다시 부풀리는 기묘한 상황주의이자 가장 소박한 초월주의로써의 전용이다. 만화에서 현실은 전복되지 않으며, 오직 창출될 뿐이다.

정리

작가가 무엇을 생각하는지는 알 수 없다. 그가 무형의 관념을 품고 있다는 사실은 텍스트로부터 유추할 수 있으나, 애초에 그것이 무엇인지는 알 수 없다. 그러나 그 기계는 명제의 구조 속 어딘가에 잠복해 있으며, 그것은 세계의 논리적 형상으로 간주될 수 있는 텍스트 구조 속에서, 확률공간 속을 기어다니다가 독자의 해석이라는 반복적 사건을 통해 잠깐잠깐 출현한다. 이 출현은 동일성의 반복이 아니라, 매번 새롭게 이루어지는 차이의 증명이다. 따라서 panpanya의 만화는 말할 수 없는 것을 침묵으로 지키면서도, 그 안에 존재하는 무형의 관념을 반복과 차이를 통해 독자에게 증명해 보이는 하나의 영지식적 예술 장치로 이해될 수 있다. 그 그림은 현실과 논리 형식을 공유하지 않는 불완전한 그림이다. 이때 관념은, 명제로서 표현되지 않지만, 여전히 존재론적 무게를 가지는 감응의 잔상이다. 더 나아가, 그 차이와 반복 자체야말로 우리가 논하는 무형의 관념에 가장 가까운 것이리라.

참고문헌

이맥스를 사용하는 구조주의자 및 라캉주의자 여러분이라면, 하찮은 일의 자동화에 카타르시스를 느끼는 것이 보통이라고 생각된다. 아시다시피 초보적 부조리주의를 추구하는 사악한 VSCode 사용자들은 “One must imagine Sisyphus happy” 와 같은 논리로 무장한 채 무의미한 반복 작업의 신성함을 설파하지만, 정작 이를 주창한 알베르 카뮈 (그 자신은 부조리주의자로써 불리는 것을 선호하지 않았지만) 는 구토가 나오는 온갖 부조리에 저항하는 것을 그 가치로 내걸었다.

이를 보아, 끝없이 이어지는 반복 작업을 일반화하고 단순화시켜 효율적 노동을 추구하는 것이야말로 부조리에 대한 인간의 신성한 저항이라 할 수 있겠다. 또한 이러한 사상에 그다지 흥미를 보이지 않는 구조주의자 여러분도, 무의미한 반복 작업을 추상화시키는 것이 이 징글맞은 세계를 관통하는 법칙에 한 발짝 다가가는 데 도움이 된다는 것을 부정하지는 않을 것이라 생각한다.

그참에 소개하는 이맥스의 개쩌는 함수, ndmacro다.

ndmacro의 기원은 1993년에 작성된 dmacro다. 필자는 본디 이맥스가 기본적으로 제공하는 키 매크로 기능을 사용하여 지루한 반복 작업을 타파하고는 했다. 예를 들면, 100행짜리 텍스트에서 각 줄의 첫 번째 단어 뒤에 $ 기호를 넣는다고 가정하자. 상상만 해도 끔찍하다. 이러한 작업을 일일이 직접 수행하는 것에 미덕을 느끼는 인간은 아마도 노동재화의 가치를 제 입맛에 맞게 임의로 조작하려 드는 사기꾼일 것이다. 생각들을 하시라. 노동이 그리도 신성한 것이라면 좀 아껴 써야 하지 않겠는가?

이맥스의 기본 매크로 기능은 이러한 반복 작업을 기록하여, Programming By Example (PBD), 혹은 Programming by Demonstration (PBD) 의 진수를 보여준다. C-x ( 를 입력하고, 특정 키 입력과 같은 행동을 시연한 뒤, C-x ) 를 입력하여 시연을 종료한다. 그 뒤, C-x e 로 시연했던 행동을 몇 번이고 재현할 수 있다.

하지만 이건 아무래도 부족하다. 시연 개시 / 시연 종료 / 재연 과 같은 흐름은 분명 깔끔하지만, 아무래도 불필요한 동작이 있다. 이맥스가 시연의 시작과 끝을 우리의 신호 없이도 파악할 수 있게 하는 것은 어떨까? 이를 위해서는 Emacs Lisp를 사용한 패턴 찾기가 중요해진다.

<작업중>

It is often a good security practice to automize the process to connect to a VPN and encrypt your traffic at least to your local network provider.

Following is my Nix expression to have a file ~/.insecure_wifi_list, which is a \n separated list of insecure SSIDs. Then the NetworkManager Dispatcher script will connect to the vpn when you use a network and the SSID is in the list.

  networking = {
  networkmanager = {
    enable = true;
    dispatcherScripts = [
      {
        type = "pre-up";
        source = pkgs.writeText "preUpHook" ''
          SSID=$(/run/current-system/sw/bin/iwgetid -r)

          while read line; do
              if [ "$SSID" == "$line" ]; then
                  /run/current-system/sw/bin/mullvad connect
                  break
              fi
          done < /home/<user>/.insecure_wifi_list
        '';
      }

      {
        source = pkgs.writeText "downHook" ''
          INTERFACE=$1
          ACTION=$2

          SSID=$(/run/current-system/sw/bin/iwgetid -r)

          if [ "$ACTION" == "down" ]; then
              while read line; do
                  if [ "$SSID" == "$line" ]; then
                      /run/current-system/sw/bin/mullvad disconnect
                      break
                  fi
              done < /home/<user>/.insecure_wifi_list
          fi
        '';
      }

    ];
  };
};