이 아이디어를 깎아내리는 반응이 많은 게 꽤 답답함. HN 독자 다수가 아직도 TUI 우월주의에 갇혀 있고 GUI에는 별 관심이 없어 보임
두 가지가 핵심임. TUI가 GUI보다 본질적으로 우월한 것은 아니고, SSH는 전송 계층으로서 pty 전달, 즉 TUI 표시 계층뿐 아니라 GUI 표시 계층도 지원해야 함
사실 이 두 가지는 30년 전 UNIX에서 이미 실현됐고, X 프로토콜과 ssh -X라는 해법도 있었음. 하지만 X는 승리하지 못했고, 원격 머신에 ssh -X로 접속해 gnome-control-center를 실행하면 설정 창이 떠서 원격 컴퓨터를 설정할 수 있는 미래는 오지 않았음. 된다고 생각한다면 직접 해보면 되는데, 경험이 처참함
그래도 이런 필요는 계속 있었고, Jupyter Notebook 같은 앱은 웹 서버 형태로 개발되기 시작했음. 웹의 문서 형식, 스타일링, 클라이언트 스크립트 언어가 온갖 단점에도 불구하고 대화형 앱의 표시 계층으로 쓸 만해졌고, 애초에 원격 문서에서 출발했기 때문에 네트워크 투명성도 내장돼 있음
Electron 앱들을 보면 HTML/CSS/JS 스택이 데스크톱 앱에서도 지배적인 위치를 차지했다는 점을 인정하고, 이를 SSH를 통한 원격 앱 표시 계층으로 활용하는 게 자연스러움. 이 프로젝트도 그런 흐름으로 보임
Electron 앱도 X처럼 표시 서버와 클라이언트가 나뉘어 있고, 각각 “renderer process”와 “main process”라고 부르며 IPC로 통신함. 이론적으로는 적절한 IPC 전송 수단만 있으면 main process와 renderer process를 서로 다른 머신에서 실행할 수도 있을 텐데, 이 아이디어와 크게 다르지 않아 보임

Thinlinc, NoMachine, X2Go 같은 것도 있고, 전부 SSH를 주요 백엔드로 씀. 꽤 흔한 아이디어임

ssh -X는 사용하는 툴킷과 거리/지연 시간에 따라 잘 동작함. 예를 들어 Gtk는 렌더링 파이프라인 때문에 좋지 않음
거리와 지연 시간이 충분히 커지면 사용자에게 어떻게 보여줄지 고민해야 함. 매체와 상관없이 물리적 한계는 피할 수 없기 때문임. 원격 그래픽 접근을 약속하는 도구라면 어떤 것이든 지연 시간을 염두에 두고 설계해야 함. vim이 지연 시간에서도 잘 동작하는 건 사실상 명령을 큐에 쌓아 보내기 때문임

X 포워딩처럼 Wayland를 SSH 위에서 쓸 수 있고, waypipe라고 부름. 그러니 그 미래가 죽은 건 아님

개인적으로는 ssh -X로 원격 머신의 gnome-control-center를 띄워 서버를 설정하는 미래가 오지 않아서 다행임. GUI로 서버를 설정하는 건 혐오스러운 방식이고, Windows 세계에만 남았으면 함

첫 댓글이 항상 다른 댓글러들을 비난하고 그들의 생각을 깎아내리는 내용인 것도 꽤 짜증남

이건 과거에도 많았던, 문제를 찾는 해법처럼 보임. 아래 인용이 이 시도와 잘 맞는 듯함
“Unix를 이해하지 못하는 사람들은 그것을 형편없이 재발명할 운명이다.” ~Henry Spencer

프로그래머를 고용하고 Linux 노트북을 준 뒤 몇 가지 설정을 하게 했는데, 몇 시간 뒤 PuTTY를 어디서 받을 수 있냐고 물어봤음. 그때 면접에서 크게 놓친 부분이 있었다는 걸 깨달음

그렇지 않음. 이제 더 많은 사람이 Linux를 쓰면서 40년 전에 내려진 사용자 경험 결정들이 더 많이 질문받게 된 것임
거의 모든 개발자 대상 머신에는 SSH 서버가 설치되어 있고 접근 가능함
왜 SSH 터미널은 1960년대식 문자 전용 쓰레기처럼 보여야 하는가? 왜 TUI가 SSH로 흘려보내는 최고의 대상이어야 하는가? 왜 터미널에서 4K 영화를 보거나 핀치 줌으로 웹을 탐색할 수 없는가?

좀 가혹한 평가로 보임. 실제로 사용성 공백이 있고, 이 프로젝트는 그걸 건드려 보는 시도임
SSH로 Linux 디렉터리를 네이티브 UI 컴포넌트로 보는 아이디어 같은 건 괜찮아 보임
다만 일부는 sshfs 마운트처럼 이미 다른 방식으로 해결된 문제 같기도 함

“Unix를 이해하지 못하는 사람들”이라는 부분이 오히려 여기서 진짜 근본 문제임
오래전 프로그래머블 온도조절기에 관한 글이 떠오름. 매우 깊게 설정할 수 있을 만큼 강력하지만 대부분의 사람에게는 쓰기 끔찍하다는 내용이었음. 요지는 “사람들은 당신의 난해한 시스템을 배우고 싶은 게 아니라, 그 시스템이 약속하는 이득을 원한다”는 것에 가까웠음. 좋은 UI는 그 간극을 최소화할 줄 알아야 함

이건 UNIX보다는 Plan 9에 더 가까워 보임. UNIX를 너무 받들 필요는 없음

그래픽 앱의 프런트엔드와 백엔드를 분리한다는 아이디어는 좋음. 하지만 새롭다고 보긴 어려운데, 뭔가 놓치고 있는지도 모르겠음 X11Forwarding yes나 html5 web app을 모르는 것으로 보임
브라우저가 Unix 소켓에 연결하는 기능 같은 건 극히 틈새 기능이라는 이유로 기각돼 왔음
그건 보안 문제라서 구현되지 않은 것임. 적어도 원시 Unix 소켓은 그렇고, WebSocket이나 HTTP로 제한된 다른 포트는 가능함

보안에 대해 짧게 답하자면, 여러 Mozilla 포럼에서 본 논의는 대략 이랬음
브라우저가 아무 소켓에나 연결하도록 허용할 수는 없음. 많은 소켓은 명시적으로 브라우저 연결을 원하지 않거나, 브라우저가 연결할 수 있다는 사실 자체를 의식하지 못하기 때문임
그래서 일종의 허용 목록을 추가해야 하고, 그러면 이런 틈새 기능치고는 너무 복잡해짐
그래서 핵심은 틈새성이었다고 봄
참고로 Outer Loop는 허용 목록을 추가함: https://outerloop.sh/unix-domain-sockets/

여기서 Outer Shell이 어떻게 동작하는지 이해하려고 하는 중임. 웹사이트에서는 동기를 이렇게 제시하고 있음
Jupyter나 TensorBoard 같은 앱은 원격 서버에서 실행 중이면 보통 표준 웹 브라우저에 보이지 않음. 인터넷 전체가 이 앱에 접근하도록 두는 건 매우 위험하기 때문임. 대신 서버의 로컬 포트에서 실행되며, 내 컴퓨터는 거기에 직접 접근할 수 없음
전통적으로는 여기에 접근하려고 새 터미널을 열고 ssh -L 24601:localhost:8889 mrcslws@lambda4.mycompany.com &, ssh -L 24602:localhost:6006 mrcslws@lambda4.mycompany.com & 같은 명령을 실행해야 했다고 함
이게 맞나? 보통은 프로토타이핑 때만 이런 SSH 포워딩을 쓰고, 배포할 때는 myjupyternotebook.com 같은 웹사이트를 만든 뒤 인증을 붙여서 다른 사람이 접근하지 못하게 하지 않나. HTTP 기본 인증도 그렇게 큰일은 아님
공개 노출 대상을 HTTP가 아니라 SSH로 하고 싶다면 VPN이나 터널 뒤에 두는 식의 다른 선택지도 있음
Outer Loop는 매우 멋지지만, 왜 필요한지 잘 모르겠음. 뭔가 놓치고 있는 것 같으니 왜 만들었는지 이해를 도와줬으면 함

서버, SSH 등을 쓰는 사람들에게는 서로 다른 군집이 있는 것 같음
나는 딥러닝 실험, GPU 커널 최적화, 로봇 개발 같은 용도에 더 가까움. 로봇은 움직이는 서버일 뿐이고, 이런 경우에는 명시적으로 원격 컴퓨터를 쓰고 있음
이 군집의 사람들에게는 제안한 흐름보다 이 도구가 더 직관적으로 느껴질 것 같음. 다만 내 생각을 투사하고 있는지도 모르겠음
나에게는 이게 존재할 수 있는 근본적인 것 중 하나처럼 느껴짐. 원격 우선 그래픽 운영체제 같은 느낌임

사용자가 한 명이고 그게 자기 자신이며, 데스크톱 운영체제에서만 서비스에 접근하는 용도라면 리버스 프록시와 TLS 인증서를 다루는 수고를 덜어주는 셈으로 보임

SSH로 포트를 많이 보내고 있다면, SSH가 SOCKS5 프록시를 시작하게 하는 선택지도 고려할 수 있음 ssh -D 4711 -q -C -N user@host
이렇게 하면 localhost:4711이 브라우저에 지정할 수 있는 SOCKS5 프록시가 됨
물론 WireGuard VPN이 더 좋음. 무엇보다 SSH는 단일 TCP 연결 위에서 다중화하므로, 패킷 하나가 손실되면 재전송될 때까지 모든 포워딩 트래픽이 막히는 선두 차단을 겪게 됨

HTTP 기본 인증은 안전하지 않음

SSH 포트 포워딩을 주로 쓰는 경우는 네트워크가 어떤 설정 실패로 망가졌을 때 구조할 때임

작성자가 Cockpit을 들어본 적이 없는 듯함
“없다”거나 “새롭다”고 말하는 것들은 10년 넘게 Cockpit에 들어 있었음. 소켓 기반 웹 서버 연결, 서버 앱의 백엔드-프런트엔드 분리, 셸 접근이 포함된 서버 콘솔이라는 발상까지 전부 해당됨
“이게 아직 없다는 게 이상하지 않나요?”라는 질문에는 아니라고 답하겠음. 이미 오래전부터 있었기 때문임

터미널에 익숙한 사람들은 대학에서 배우지 않은 사람에게 SSH가 얼마나 적대적인지 잊고 있음
이게 VPS를 관리하는 작은 팀이 플랫폼 담당자를 뽑지 않고도 진입 장벽을 낮출 수 있다면 성공임. 다만 키와 점프 호스트를 어떻게 처리하는지는 궁금함

대단함. 확실히 올바른 방향으로 가고 있음
앞단과 뒷단 사이의 분리 계층은 가능한 가장 작은 “조각”에서 잘라야 함
여기서 빈정대는 많은 사람도 지연 시간과 추가 오버헤드를 직접 “느끼면” 이해할 것임. 개별 사용 사례에 맞게 데이터를 조심스럽게 잘라내는 데 충분한 고민이 들어가지 않았음
더 나아가, 데모에서 “설정을 자주 움직여 부하를 만든다”고 했던 top 앱은 클라이언트 쪽에서 렌더링을 더 많이 JIT 처리했어야 한다고 봄. 그러면 Pi와 클라이언트 사이를 오가는 정보는 ps 출력의 압축된 델타 정도로 줄었을 것임

이렇게 하면 안 됨. 브라우저에 일반 소켓 권한을 허용하지 않는 데에는 오래된 훌륭한 보안 이유와 웹 제어 평면 격리 이유가 아주 많음
기계적으로 가장 가까운 비유는 3륜 ATV가 나쁜 아이디어인 이유임

다음 조건이라면 괜찮다고 봄
소켓은 기본적으로 차단되고, 서버 쪽에서 명시적으로 허용 목록에 추가된 뒤에만 열려야 함
진짜 sudo 인식이 있어서 sudo 비밀번호 없이는 root 소켓에 닿을 수 없어야 함. 이 기능이 중요한 이유는, 그렇지 않으면 사람들이 사용자 접근 가능한 소켓으로 root 백엔드를 실행하도록 유도하는 인센티브가 생기기 때문임
자세한 내용은 여기 있음: https://outerloop.sh/security/