C++23으로 작성. 낮은 지연 시간, 빠른 시작, 예측 가능한 자원 사용을 목표로 만든 터미널 에뮬레이터

터미널 상태를 CPU에 유지하고 셀을 네이티브 컴퓨트 백엔드(Linux는 Vulkan, macOS는 Metal)로 렌더링

Apple 실리콘 MacBook에서 100MB를 GUI로 출력하는 벤치마크(모든 터미널을 동일 조건으로 정렬)에서 가장 빠른 처리량 기록

출력 가능한 ASCII 스크롤 경로에서 wall time 0.81s / 처리량 약 118 MiB/s로, alacritty(0.96s), kitty(1.28s), ghostty(1.49s)보다 앞섬

랜덤 바이트(파서 최악 상황, 전체가 잘못된 UTF-8)에서도 1.88s / 약 51 MiB/s로 alacritty(3.07s), ghostty(4.63s)보다 빠름

5,000개 이상의 테스트를 kitty, esctest, xterm vttests, vttest, tack, libvterm, libtsm, alacritty, ghostty, contour, konsole, mosh 등 여러 스위트에서 수집해 실제 PTY를 통한 블랙박스 방식으로 검증

프레임 리사이즈를 경계 변경과 같은 트랜잭션 내에서 렌더링하는 깜빡임 없는(flicker-free) 처리와, 손상 기반(damage-driven) 갱신 지원

파서 상태 머신이 완전(total)하고 커밋된 코퍼스로 퍼징되어, cat /dev/urandom이 크래시가 아닌 벤치마크로 취급될 정도의 견고성 확보

셀을 코드포인트가 아닌 그래핌 클러스터로 다뤄 이모지 시퀀스, 변형 선택자, 결합 문자, 넓은 CJK 문자를 올바르게 처리

윈도잉 툴킷 없이 폰트를 내장한 단일 소형 바이너리로, 폰트가 전혀 설치되지 않은 머신에서도 실행됨

기본적으로 애플리케이션이 명시적 허용 없이는 선택 영역을 읽거나 호스트 창을 제어할 수 없는 기본 잠금(locked down) 정책 적용

제공 기능들

VT52부터 VT5xx까지의 제어 시퀀스와 널리 쓰이는 xterm 확장 지원

주 화면·대체 화면, 주 화면 스크롤백, 여백(margins), 탭, 사각형 연산(rectangular operations), 보호 셀(protected cells), 동기화 출력(synchronized output) 지원

터미널 너비가 바뀔 때 주 화면 스크롤백을 다시 흐르게 하는 reflow 처리

유니코드 그래핌 클러스터, 결합 문자, 이모지 시퀀스, 두 배 너비 문자 처리

DEC 규격의 단일 너비, 두 배 너비, 두 배 높이 라인 지원

16색·256색·24비트 색상 지원, 밑줄 색상 및 확장 밑줄 스타일 포함

Legacy, modifyOtherKeys, Kitty 키보드 프로토콜 지원

X10, VT200, UTF-8, SGR, SGR-pixel, urxvt 마우스 프로토콜 지원

선형·사각형 선택, 주 선택(primary selection), 클립보드 통합, OSC 52 정책, OSC 8 하이퍼링크 지원

셸 통합, 알림, 진행 보고(progress reports), 대역 내 리사이즈 보고(in-band resize reporting) 지원

지연 글리프 래스터화, 영구 GPU 글리프 캐시, 손상 기반(damage-driven) 컴퓨트 렌더링 지원

내부적으로 UTF-8을 사용하고 자식 프로세스에 TERM=xterm-256color를 export (호스트에 해당 terminfo 항목 필요)

현재 양방향 텍스트 레이아웃과 sixel 같은 인라인 그래픽 프로토콜은 미구현

Zutty(원작자 Tom Szilagyi)의 하드 포크이자 완전 재작성이며, GPL 기반에서 MIT 전용 코드베이스로 전환 중

Gutenberg의 Moby Dick은 1.2MB임[0]. 가장 느린 터미널도 초당 약 53권, shitty는 약 98권을 표시할 수 있다는 뜻임
초당 몇 권이 필요한지는 모르겠지만 선택지가 많아서 좋음
[0] https://www.gutenberg.org/ebooks/2701

불과 25~30년 전에는 출력이 아주 많은 Java 빌드에서 터미널 창을 가리거나 최소화하면 더 빨라지기도 했음. 느린 콘솔 출력이 컴파일러를 지연시켰기 때문임

프로그램 속도를 떨어뜨리지 않으면서 콘솔에 대량의 디버그 출력을 쏟아내고 싶을 때가 있음. 실수로 1TB 파일에 cat을 실행할 수도 있음

대부분의 화면은 초당 60장만 표시하니, 초당 보여줄 수 있는 Moby Dick도 많지 않음

Ghostty 개발자임. 새 터미널은 언제나 반가움. 벤치마크 대상이 최신 릴리스인 Ghostty 1.3.1인 것은 타당하지만, 테스트한 영역의 입출력 처리량은 일부 장비에서 두 배 이상 개선됐으니 기회가 되면 main으로 다시 측정해 주길 바람
shitty보다 빠를지는 모르지만 1.3.1보다는 훨씬 빠를 것임. M4 MacBook Pro에서는 ASCII 처리가 약 2.8배 개선됐고, 이 결과가 해당 벤치마크에서도 유지된다면 shitty보다 빨라질 수 있음. 그래도 직접 측정해 주는 편을 선호함

현재 실제 경과 시간은 동률임. ASCII는 Ghostty가 낫고 무작위 입력은 더 느리지만, 두 경우 모두 내 쪽의 사용자 CPU 시간이 더 좋으므로 알고리즘 측면에서는 여전히 경쟁할 여지가 있음. 표도 갱신했음

새로운 터미널을 살펴볼 때 주로 어떤 항목으로 품질을 검증하는지 궁금함

릴리스되는 즉시 반드시 다시 측정하겠음

실행 파일 이름은 st, 데스크톱 앱과 아이콘 이름은 shitty인데, 이미 존재하는 suckless st와 충돌함
성능 수치는 인상적이지만 Alacritty나 Ghostty를 계속 사용해도 그다지 느리지 않겠다는 결론도 얻게 됨

누군가 알아봐 줘서 기쁨. Ragel은 들어본 사람이 거의 없는 매우 틈새 도구임. 내 파서는 터미널 출력 파서를 유한 상태 머신(FSM) 형태로 완전히 기술한 최초의 사례라고 보며, 그 자체로도 상당한 가치가 있음

원본 코드의 권리를 보유하지 않았다면 GPL 기반 코드를 MIT 전용으로 전환할 수 없음. 모든 줄을 다시 작성해도 100% 파생 저작물이므로 GPL을 유지해야 함

인터넷의 무작위 ‘GPL 광신자’보다 이 문제로 실제 자문한 변호사의 견해를 따르겠음
설명한 절차는 여러 번 실행됐고 문서화도 잘돼 있으며, 상당히 복잡하긴 해도 충분히 가능함. 처리할 수 있다고 봄. 원한다면 온라인 법정이 아니라 실제 법원에서 소송하면 됨

터미널에서는 처리량보다 키 입력부터 화면 표시까지의 지연 시간을 훨씬 중시하므로 관련 수치도 보고 싶음

측정하기가 매우 어려움. 다만 shitty는 foot, kitty, Alacritty, Ghostty 중 가장 정밀한 변경 영역 추적 모델을 갖췄다고 말할 수 있음. 셀 단위로 정확해 실제 변경된 부분만 화면에 그림
Linux에서는 Wayland 컴포지터가 돌려준 스왑체인 버퍼를 재사용하고, 버퍼를 창 시스템으로 보낸 뒤 변경된 영역만 갱신함. 즉 가능한 최소한의 작업만 수행한다는 것을 증명할 수 있음. macOS에서는 표시 중 Metal이 버퍼를 손상시킬 수 있고 실제로도 그런다고 문서에 명시돼 있어 불가능함
실제 측정값이 아닌 코드 구조만 보면 shitty가 변경 내용을 전달하는 지연 시간에서 가장 뛰어난 터미널임

2026년에 어떤 터미널 에뮬레이터를 쓰든 실제로 성능 문제를 겪는 사람이 있는지 궁금함. Terminal.app / zsh / tmux / vim을 15년간 사용하면서 한 번도 더 빨랐으면 좋겠다고 생각한 적이 없음

내게 가장 중요한 것은 실행 시간임. 일반적인 Linux 배포판의 기본 터미널 시작 속도가 믿기 어려울 만큼 느려서, 열릴 때쯤이면 하려던 일을 잊을 정도로 짜증 남
Alacritty는 터미널 하나만 처음 실행하고 이후 창은 alacritty msg create-window로 그 창에서 갈라져 나오듯 매우 효율적으로 생성할 수 있어 PC 사용이 훨씬 편해짐

속도 자체는 중요하지 않을 수 있지만, 최첨단 수준을 넘어설 수 있음을 스스로 증명하는 일은 흥미로운 도전임

일반적인 상호작용에서는 처리량보다 지연 시간이 더 중요하고, 가장 느린 터미널과 가장 빠른 터미널 사이에는 체감 가능한 차이가 있음. 그래도 성능에 어느 정도 신경 쓴 터미널이라면 모두 충분히 빠름
처리량이 중요한 때는 애플리케이션이 출력을 대량으로 내보낼 때임. 문제는 어차피 읽지 못할 만큼 빨리 표시되는 텍스트가 아니라, 버퍼가 가득 차면서 stdout 쓰기가 막혀 애플리케이션까지 느려지는 데 있음. 이때는 모든 텍스트를 렌더링하지 말고 대부분을 스크롤백 버퍼로 바로 보내며 일부 프레임만 그리는 편이 최선일 수 있음

늘 당시 사용하던 Linux 데스크톱에 기본으로 딸려온 터미널을 사용했음. 오히려 터미널은 열어 둔 GUI 앱 가운데 이미 가장 작고 빠른 편임
새로운 ‘엄청나게 빠른’ 터미널이 발표될 때마다 수년간 실용적인 이유를 물었지만, 현대 시스템에 적용되는 답은 아직 보지 못했음. 잘 알려져 있고 위험 부담이 적은 그래픽 프로그램을 최적화하는 과정 자체를 즐기는 사람이 있는 듯함

프로젝트의 유치한 이름 때문에 개발자가 앞으로 전문적으로 운영할 것이라는 신뢰가 생기지 않으며, 기업 네트워크에 설치하기도 어려워질 것임
저속한 재치 자체는 좋아하지만 이것은 그런 수준이 아니며, 기술 능력과 사회성이 반비례한다는 고정관념만 강화함

GPL인 zutty에 Claude로 생성한 코드를 얹고 MIT로 배포했으니 라이선스 위반임. 결국 다른 저품질 AI 생성물과 같은 더미에 들어갈 테니 이름은 잘 지었음

개발자가 기업 네트워크 설치를 신경 쓰지 않을 수도 있음. 나도 오픈소스 소프트웨어를 무료로 배포하면서 기업 정책 준수를 우선한 적은 없음

메모리 안전성을 포기한 태도까지 고려하면 Fox News와 Department of War의 공식 터미널이 될 수도 있음

이 제품은 매우 전문적으로 만들어졌다고 장담함. 터미널 동작 전반을 다루는 테스트 5,000개가 있고, AddressSanitizer와 UndefinedBehaviorSanitizer로 테스트하며 정기적인 퍼징과 코드 커버리지 감시까지 수행함
개발 방식만 보면 GitHub 프로젝트 중 상위 0.1% 에 확실히 듦. 기업 네트워크에 설치하기 어렵다는 점은 괜찮음