Asciinema는 정말 멋진 도구임, 나는 TerminalTextEffects 데모를 모두 캡처할 때 사용함, Asciinema GIF Generator(AGG)가 asciicast 파일을 고품질 터미널 GIF로 변환해줌, 그래서 TerminalTextEffects 저장소나 문서에 데모를 쉽게 올릴 수 있음
raw 파일 출력이나 termsvg 류의 방법은 stdout에 엄청난 데이터가 출력되기 때문에 TTE에 맞지 않음 AGG 문서와 TerminalTextEffects 저장소 링크를 참고하면 좋음
서버 motd나 스타트업 메시지를 매번 랜덤한 TTE로 꾸며서 넘길 때마다 즐거움을 느끼는 중임
내가 만든 예시는 여기에서 볼 수 있음
이 프롬프트 효과는 진짜 아름다움, 쓸 데가 있든 없든 그냥 계속 만들었으면 좋겠음, 넋을 잃게 보는 중임
TTE는 오래 전 Compiz 윈도우 매니저에서 처음 리눅스를 쓰게 만든 그 환상적인효과가 터미널에서 구현된 느낌임
TTE를 tmux나 vim에 스크린 세이버처럼 간헐적으로 적용하는 방법이 궁금함, 파이프로 연결해야 하는지, alias로 쓰는 게 나은지 등 고민이 있음
보통 어떻게 쓰고, 제작할 때는 어떤 용도였고 지금은 어떻게 활용하고 있는지 궁금함
계속해서 발전시켜주었으면 하는 바람임
t-rec도 굉장히 유용한 툴임, 원하는 윈도우를 녹화해서 비디오나 gif로 만들 수 있음
완전히 같진 않지만, 단순히 터미널 gif를 빨리 공유하려면 t-rec가 더 쉬운 경우도 있음
15MB짜리 GIF 파일은 도저히 감당이 안 됨
탐색도 불가능하고, 텍스트 선택도 불가, 15배의 대역폭 낭비까지 감수해야 함
부드럽게 압축되고, 탐색 쉽고, 접근성 높은 텍스트를 가장 끔찍한 형식의 비디오로 옮기는 건 너무 아쉬움
최소한 raw asciinema 파일이나 웹뷰어로의 링크도 같이 주면 좋겠음, 그러면 짧은 시간에 불러오고, 멈춤/탐색/복사-붙여넣기까지 다 가능함
루프만 빠르게 도는 GIF는 만든 사람 외엔 의도가 거의 전달되지 않음
asciinema.org 사이트가 너무 인기가 많아 현재 트래픽 폭주 현상임, btop 스트림이 연결된 서버의 CPU 점유율이 무려 95%임
해당 스트림 예시는 여기에서 볼 수 있음
그래도 BEAM 위에 올린 Elixir/Phoenix 서버는 많은 요청과 CPU 사용에도 무난하게 서비스 중임 — 이것이 바로 BEAM의 힘임
현 시점에서 2GB RAM짜리 VM 2대만으로도 버티지만, 조만간 확장할 필요를 느낌
모든 인프라가 클라우드로 쏠리는 시대에 이렇게 유명한 서비스가 단 두 대의 2GB VM에서 안정적으로 돌아가는 모습이 놀라움
요즘 중급 노트북의 램보다도 적은 자원임에도 원활함
인프라를 바로 확장한 결과, 다시 안정적이고 반응도 좋아진 상태임
현재 btop 스트림이 심하게 끊기고 CPU 점유율도 0% ~ 100% 사이에서 계속 급변함
혹시 서비스가 계속 크래시 후 재시작 중인지 궁금증이 있음
BEAM이여 영원하라!
팁을 주자면 btop의 새로고침 주기를 줄이는 게 좋을 것 같음, 100ms로 돌리면 btop이 CPU를 많이 쓰게 됨
Asciinema 클라이언트가 Python → Golang → Python → Rust로 계속 바뀜 변천사 문서와 관련 블로그도 참고 가능함
이런 프로젝트는 어떤 언어로 구현해도 딱히 상관 없을 것 같음, 모든 언어가 비슷한 성능을 내기 때문임
코드베이스가 작다보니 어떤 언어로 옮겨도 기능적 영향이 미미해서, 개발자가 동기부여되는 언어로 계속 재작성해도 무방하다고 생각함
흥미로운 점임
Go의 문제점 대부분은 코드를 쓰기도 전에 미리 파악할 수 있어야 한다고 생각함, 단순 조사만 했어도 packaging 이슈 같은 것들은 2016년에 정당한 불만이었으나 Go 모듈로 이후 해결됨
그 후에는 ClojureScript, Elixir, Rust로 계속 재작성하는 건 기술 트렌드 쫓기라는 느낌을 지울 수 없음
이런 잦은 언어 교체는 엔지니어링 신뢰도를 떨어뜨림
Asciinema에 애정을 갖고 있으며, 작은 기여와 기부를 통해 프로젝트를 후원함 기부 안내와 리눅스 시스템 문제 해결에 Asciinema가 어떻게 보일지 (사드서버스 리플레이)도 한 번 확인해보길 추천함
Asciinema는 내가 사용해 본 도구·제품 중에서 단연 최고임
CLI로 인증/업로드하는 플레이가 깔끔하고 직관적이라, 여러 번 단계를 거쳐야 해도 절대 불편함이 없음
다른 CLI에서도 비슷한 설계가 있긴 하지만 Asciinema는 방해받는 느낌이 전혀 없었음
정말 멋진 성과임을 축하함
다만 asciinema가 SVG나 GIF로 바로 저장하는 기능이 내장되면 좋겠다는 바람임
별도의 변환 앱 없이도 마크다운 파일에 삽입할 수 있게 되니까 사용성이 더욱 좋아질 것임
Asciinema의 열렬한 팬으로서 이번 작업이 정말 멋지다고 생각함
라이브 스트리밍 기능 관련해서는, 내가 공동 창업자인 s2.dev의 스트림 위에 비슷한 것을 해킹해서 올린 적이 있는데, 이런 구조라면 중간 릴레이 없이도 가능할 것 같음
개인적으로 btop을 실시간으로 보여주는 게 멋졌음
라이브 스트리밍 구조 참고는 이 문서가 도움될 것임
터미널 실시간 스트리밍 기능이 도입된 만큼, 누군가 ASCII 아트 vtuber 아바타를 터미널 위에 오버레이로 얹어주면 재밌을 것 같음
Max Headroom v0.2를 떠올리게 하는 아이디어임
내가 가장 좋아하는 elixir 프로젝트인 asciinema가 이제 Rust로도 재작성됨
이 발전이 정말 마음에 듦
혹시 명령어에서 시크릿, 키 같은 민감 정보를 자동 정제/감시하는 기능도 추가했는지 궁금함, 요즘은 가벼운 LLM도 많으니 이전보다 더 쉬워졌을 것 같음
CLI는 Rust로 재작성되었지만 서버는 여전히 Elixir/Phoenix 임, 이 부분은 민감 정보 필터링 같은 기능에 딱 맞는 구조임
예전엔 Python으로 먼저 만들어지지 않았었는지 궁금함
명령어에서 시크릿/키 자동 필터링 기능 문의는 혹시 농담이 아닌지 의문임
트위치 스트리머들이 보통 두 대의 컴퓨터로 방송을 하는 이유는 하나는 방송 화면을 보여주는 용, 다른 하나는 OBS와 HDMI 캡처를 돌리기 위함임
Asciinema의 새로운 라이브 스트리밍 기능을 활용한다면, 콘솔(terminal)에서만 작업하는 개발자라면 HDMI 캡처기 없이도 dev 머신의 터미널 화면을 OBS 머신으로 바로 스트리밍할 수 있을 것 같음
아주 소수의 프로그래밍 스트리머에게는 Asciinema 3가 진정한 대안이 될 수 있을 것임
Asciinema 스트리밍이라면 성능에 영향이 거의 없어서 이런 듀얼 장비 구성은 필요 없음
2PC 세팅이 태동된 건 x264 인코딩의 CPU 부하 때문이었으나, 요즘은 GPU로 인코딩(Nvidia NVENC)하면 부담이 거의 없어짐
OBS x264는 오프라인 녹화용(유튜브 영상 등)이 아니면 필요 없어짐
트위치 스트리머들이 2PC를 쓰는 이유는 GPU를 많이 쓰는 게임 방송 시 리소스 충돌을 막기 위함임
또, 게임 도중 드라이버 크래시가 스트림에 영향을 미치는 걸 방지함
이런 방송 장비 세팅은 대부분 영상 인코딩 부하 분산 용도여서, 콘솔에서만 작업하는 프로그래밍 스트리머라면 굳이 필요 없다고 생각함
Hacker News 의견
Asciinema는 정말 멋진 도구임, 나는 TerminalTextEffects 데모를 모두 캡처할 때 사용함, Asciinema GIF Generator(AGG)가 asciicast 파일을 고품질 터미널 GIF로 변환해줌, 그래서 TerminalTextEffects 저장소나 문서에 데모를 쉽게 올릴 수 있음
raw 파일 출력이나 termsvg 류의 방법은 stdout에 엄청난 데이터가 출력되기 때문에 TTE에 맞지 않음
AGG 문서와 TerminalTextEffects 저장소 링크를 참고하면 좋음
서버 motd나 스타트업 메시지를 매번 랜덤한 TTE로 꾸며서 넘길 때마다 즐거움을 느끼는 중임
내가 만든 예시는 여기에서 볼 수 있음
이 프롬프트 효과는 진짜 아름다움, 쓸 데가 있든 없든 그냥 계속 만들었으면 좋겠음, 넋을 잃게 보는 중임
TTE는 오래 전 Compiz 윈도우 매니저에서 처음 리눅스를 쓰게 만든 그 환상적인효과가 터미널에서 구현된 느낌임
TTE를 tmux나 vim에 스크린 세이버처럼 간헐적으로 적용하는 방법이 궁금함, 파이프로 연결해야 하는지, alias로 쓰는 게 나은지 등 고민이 있음
보통 어떻게 쓰고, 제작할 때는 어떤 용도였고 지금은 어떻게 활용하고 있는지 궁금함
계속해서 발전시켜주었으면 하는 바람임
t-rec도 굉장히 유용한 툴임, 원하는 윈도우를 녹화해서 비디오나 gif로 만들 수 있음
완전히 같진 않지만, 단순히 터미널 gif를 빨리 공유하려면 t-rec가 더 쉬운 경우도 있음
15MB짜리 GIF 파일은 도저히 감당이 안 됨
탐색도 불가능하고, 텍스트 선택도 불가, 15배의 대역폭 낭비까지 감수해야 함
부드럽게 압축되고, 탐색 쉽고, 접근성 높은 텍스트를 가장 끔찍한 형식의 비디오로 옮기는 건 너무 아쉬움
최소한 raw asciinema 파일이나 웹뷰어로의 링크도 같이 주면 좋겠음, 그러면 짧은 시간에 불러오고, 멈춤/탐색/복사-붙여넣기까지 다 가능함
루프만 빠르게 도는 GIF는 만든 사람 외엔 의도가 거의 전달되지 않음
asciinema.org 사이트가 너무 인기가 많아 현재 트래픽 폭주 현상임, btop 스트림이 연결된 서버의 CPU 점유율이 무려 95%임
해당 스트림 예시는 여기에서 볼 수 있음
그래도 BEAM 위에 올린 Elixir/Phoenix 서버는 많은 요청과 CPU 사용에도 무난하게 서비스 중임 — 이것이 바로 BEAM의 힘임
현 시점에서 2GB RAM짜리 VM 2대만으로도 버티지만, 조만간 확장할 필요를 느낌
모든 인프라가 클라우드로 쏠리는 시대에 이렇게 유명한 서비스가 단 두 대의 2GB VM에서 안정적으로 돌아가는 모습이 놀라움
요즘 중급 노트북의 램보다도 적은 자원임에도 원활함
인프라를 바로 확장한 결과, 다시 안정적이고 반응도 좋아진 상태임
현재 btop 스트림이 심하게 끊기고 CPU 점유율도 0% ~ 100% 사이에서 계속 급변함
혹시 서비스가 계속 크래시 후 재시작 중인지 궁금증이 있음
BEAM이여 영원하라!
팁을 주자면 btop의 새로고침 주기를 줄이는 게 좋을 것 같음, 100ms로 돌리면 btop이 CPU를 많이 쓰게 됨
Asciinema 클라이언트가 Python → Golang → Python → Rust로 계속 바뀜
변천사 문서와 관련 블로그도 참고 가능함
이런 프로젝트는 어떤 언어로 구현해도 딱히 상관 없을 것 같음, 모든 언어가 비슷한 성능을 내기 때문임
코드베이스가 작다보니 어떤 언어로 옮겨도 기능적 영향이 미미해서, 개발자가 동기부여되는 언어로 계속 재작성해도 무방하다고 생각함
흥미로운 점임
Go의 문제점 대부분은 코드를 쓰기도 전에 미리 파악할 수 있어야 한다고 생각함, 단순 조사만 했어도 packaging 이슈 같은 것들은 2016년에 정당한 불만이었으나 Go 모듈로 이후 해결됨
그 후에는 ClojureScript, Elixir, Rust로 계속 재작성하는 건 기술 트렌드 쫓기라는 느낌을 지울 수 없음
이런 잦은 언어 교체는 엔지니어링 신뢰도를 떨어뜨림
Asciinema에 애정을 갖고 있으며, 작은 기여와 기부를 통해 프로젝트를 후원함
기부 안내와 리눅스 시스템 문제 해결에 Asciinema가 어떻게 보일지 (사드서버스 리플레이)도 한 번 확인해보길 추천함
Asciinema는 내가 사용해 본 도구·제품 중에서 단연 최고임
CLI로 인증/업로드하는 플레이가 깔끔하고 직관적이라, 여러 번 단계를 거쳐야 해도 절대 불편함이 없음
다른 CLI에서도 비슷한 설계가 있긴 하지만 Asciinema는 방해받는 느낌이 전혀 없었음
정말 멋진 성과임을 축하함
다만 asciinema가 SVG나 GIF로 바로 저장하는 기능이 내장되면 좋겠다는 바람임
별도의 변환 앱 없이도 마크다운 파일에 삽입할 수 있게 되니까 사용성이 더욱 좋아질 것임
Asciinema의 열렬한 팬으로서 이번 작업이 정말 멋지다고 생각함
라이브 스트리밍 기능 관련해서는, 내가 공동 창업자인 s2.dev의 스트림 위에 비슷한 것을 해킹해서 올린 적이 있는데, 이런 구조라면 중간 릴레이 없이도 가능할 것 같음
개인적으로 btop을 실시간으로 보여주는 게 멋졌음
라이브 스트리밍 구조 참고는 이 문서가 도움될 것임
터미널 실시간 스트리밍 기능이 도입된 만큼, 누군가 ASCII 아트 vtuber 아바타를 터미널 위에 오버레이로 얹어주면 재밌을 것 같음
내가 가장 좋아하는 elixir 프로젝트인 asciinema가 이제 Rust로도 재작성됨
이 발전이 정말 마음에 듦
혹시 명령어에서 시크릿, 키 같은 민감 정보를 자동 정제/감시하는 기능도 추가했는지 궁금함, 요즘은 가벼운 LLM도 많으니 이전보다 더 쉬워졌을 것 같음
CLI는 Rust로 재작성되었지만 서버는 여전히 Elixir/Phoenix 임, 이 부분은 민감 정보 필터링 같은 기능에 딱 맞는 구조임
예전엔 Python으로 먼저 만들어지지 않았었는지 궁금함
명령어에서 시크릿/키 자동 필터링 기능 문의는 혹시 농담이 아닌지 의문임
트위치 스트리머들이 보통 두 대의 컴퓨터로 방송을 하는 이유는 하나는 방송 화면을 보여주는 용, 다른 하나는 OBS와 HDMI 캡처를 돌리기 위함임
Asciinema의 새로운 라이브 스트리밍 기능을 활용한다면, 콘솔(terminal)에서만 작업하는 개발자라면 HDMI 캡처기 없이도 dev 머신의 터미널 화면을 OBS 머신으로 바로 스트리밍할 수 있을 것 같음
아주 소수의 프로그래밍 스트리머에게는 Asciinema 3가 진정한 대안이 될 수 있을 것임
Asciinema 스트리밍이라면 성능에 영향이 거의 없어서 이런 듀얼 장비 구성은 필요 없음
2PC 세팅이 태동된 건 x264 인코딩의 CPU 부하 때문이었으나, 요즘은 GPU로 인코딩(Nvidia NVENC)하면 부담이 거의 없어짐
OBS x264는 오프라인 녹화용(유튜브 영상 등)이 아니면 필요 없어짐
트위치 스트리머들이 2PC를 쓰는 이유는 GPU를 많이 쓰는 게임 방송 시 리소스 충돌을 막기 위함임
또, 게임 도중 드라이버 크래시가 스트림에 영향을 미치는 걸 방지함
이런 방송 장비 세팅은 대부분 영상 인코딩 부하 분산 용도여서, 콘솔에서만 작업하는 프로그래밍 스트리머라면 굳이 필요 없다고 생각함