asciinema CLI 3.0, Rust ile yeniden yazıldı; canlı yayın ve dosya formatı yükseltmesi sunuyor

(blog.asciinema.org)

11 puan yazan GN⁺ 2025-09-17 | 2 yorum | WhatsApp'ta paylaş

Terminal kayıt aracı asciinema CLI 3.0, baştan sona Rust ile yeniden yazıldı; buna dosya formatı yükseltmesi ve canlı terminal yayını özellikleri eklendi
Rust kullanımı sayesinde statik binary dağıtımı, hızlı başlangıç süresi sağlanırken; AVT entegrasyonu ile eşzamanlılık ve sistem çağrılarının işlenmesi kolaylaştı, yeni özelliklerin uygulanması için de bir temel oluşturuldu
Yeni asciicast v3 formatı, olay aralığına (delta) dayalı zamanlama, term alt meta veri yapısı, "x" çıkış olayı ve # satır yorumlarını getirerek düzenlenebilirliği ve ifade gücünü artırıyor
Canlı terminal yayını, yerel gömülü sunucu ve uzak relay (self-hosted/resmi sunucu) olmak üzere iki modda sunuluyor; ağ koşullarına göre uyarlanabilir buffering ile akıcı bir izleme deneyimi sağlıyor
Temel felsefe Local-first olarak yeniden düzenlendi; rec artık dosya adını zorunlu kılıyor ve yükleme işlemi ayrılıyor (upload <dosya>), kendi sunucusunu seçme istemi ile self-hosting dostu yapı ve istenmeyen veri sızıntısını önleme güçlendiriliyor

3.0 sürümü: Rust ile yeniden yazılan asciinema CLI ve başlıca iyileştirmeler

asciinema CLI 3.0 resmen yayımlandı
Bu sürümde tüm kod Rust ile yeniden yazıldı ve aynı anda kayıt dosyası formatı yükseltildi
Terminal oturumlarının canlı yayını gibi çeşitli özellikler eklendi/geliştirildi

Rust ile yeniden yazım ve genel iyileştirmeler

CLI'nin tamamen Rust ile yeniden yazılması, geliştirici deneyimini ve bakım yapılabilirliği artırdı; statik binary dağıtımıyla kurulum yolu sadeleşti, başlangıç hızı arttı ve özellik genişletilebilirliği sağlandı
- Yazarın deneyimine göre sistem çağrıları ve eşzamanlılık işleme Python'a kıyasla daha kolay olduğu için bu tercih yapıldı; ayrıca asciinema virtual terminal (AVT) CLI'ye entegre edilerek yeni özelliklerin uygulanması mümkün hale geldi
Sonuç olarak performans, dağıtım ve mimari açısından gelecekte eklenecek özellikler için bir temel oluşturuldu

asciicast v3 dosya formatı

asciicast v3 dosya formatına geçişle birlikte, mevcut v2'de görülen çeşitli eksikler gideriliyor
v2'nin mutlak zaman damgaları, aralık (interval/delta) tabanlı zamanlama ile değiştirildi; böylece olay ekleme/silme sırasında sonraki zaman damgalarının topluca ayarlanması sorunu ortadan kalktı
Başlık yapısı yeniden düzenlenerek terminalle ilgili meta veriler term anahtarı altında gruplanıyor ve oturum çıkış durumunu kaydetmek için "x" (exit) olayı destekleniyor
Dosya içinde satır yorumlarına (#) izin verilerek okunabilirlik ve yönetim kolaylığı artırıldı
Verilen örnek snippet, yapı ve olay akışı bileşimini sezgisel biçimde gösteriyor
Yeni format asciinema server ve asciinema player tarafından zaten destekleniyor

Canlı terminal yayını

Yerel mod: Gömülü HTTP sunucusu ile aynı ağda izlenebilen bir yayın sunuyor; veriler yalnızca izleyici tarayıcısına aktarıldığı için gizlilik öncelikli bir mod
- CLI, en güncel asciinema player ile paketlenmiş geliyor; böylece anında oynatma mümkün oluyor, ancak güvenlik duvarında port açılması gerekebilir
Uzak mod: asciinema server (resmi ya da self-hosted) relay olarak kullanılarak paylaşılabilir URL üzerinden yayın dağıtılıyor
- İki mod aynı anda kullanılabildiği için duruma uygun dağıtım yapılandırması mümkün
Player, gerçek zamanlı ağ gecikmesi ölçümüne dayalı uyarlanabilir buffering ile düşük gecikme ve buffer underrun önleme arasında denge kuruyor
Sunucu yayını otomatik kaydetmeyi destekliyor; şu anda asciinema.org işletilen sunucusunda kayıt kapalı ve aynı anda 1 yayın sınırı politikası uygulanıyor
- Self-hosting durumunda kayıt varsayılan olarak açık ve eşzamanlı yayın sayısında sınır yok

Local-first yaklaşımına dönüş

Geçmişte asciinema rec, yükleme davranışını varsayılan akışa dahil ettiği için farkında olmadan herkese açma ve bilgi sızdırma riski taşıyordu
- 2.4 sürümünde yükleme öncesi seçim istemi ile bu geçişe hazırlık yapılmıştı; 3.0'da ise dosya adı zorunluluğu, rec içinden yükleme özelliğinin kaldırılması ve bunun upload <dosya> şeklinde açık bir komut olarak ayrılması sağlandı
Temel felsefe net biçimde local-first olarak tanımlanarak, kullanıcının yayınlama/paylaşma kararını bilinçli olarak vermesi için akış yeniden tasarlandı
- Yalnızca yerel kullanım tam olarak destekleniyor ve yalnızca gerektiğinde açıkça yayımlama yapılıyor

Self-hosting dostuluğunun güçlendirilmesi

upload / stream / auth ilk kez kullanıldığında sunucu URL'si seçme istemi gösteriliyor; varsayılan olarak asciinema.org öneriliyor ancak kullanıcının tercih ettiği instance seçimi kaydediliyor
- Bu zaten yapılandırma dosyası/ortam değişkeni ile belirtilebiliyordu; ancak etkileşimli ortamlarda (yeni VM, Dev container vb.) ayarlamak artık daha kolay
Bu değişiklik, self-hosting kullanılabilirliğini artırırken aynı zamanda istenmeyen dış yüklemeleri önleyen ek bir güvenlik önlemi işlevi görüyor

Dağıtım ve kullanım bilgisi

Paketlerin çeşitli dağıtım depolarına yansıması biraz zaman alabilir
Bu arada GNU/Linux ve macOS için önceden derlenmiş binary dosyaları GitHub releases üzerinden indirilebilir ya da kaynaktan derleme yapılabilir
Sürüm notları ve ayrıntılı değişiklik geçmişi GitHub'daki release notes ve CHANGELOG belgelerinde bulunabilir

2 yorum

xguru 2025-09-17

3.0 daha önce çıkmamış mıydı? diye düşünüp aratınca, 2021'de Player'ı Rust ile yeniden yazarken 4 kat daha küçük ve 50 kat daha hızlı olacağını duyurdukları yazıymış.

Asciinema - terminal ekranını kaydet ve paylaş
Asciinema 3.0 - 4 kat daha küçük, 50 kat daha hızlı

GN⁺ 2025-09-17

Hacker News yorumu

Asciinema gerçekten harika bir araç; tüm TerminalTextEffects demolarını kaydederken onu kullanıyorum. Asciinema GIF Generator (AGG), asciicast dosyalarını yüksek kaliteli terminal GIF'lerine dönüştürüyor; böylece demoları TerminalTextEffects deposuna veya dokümantasyonuna kolayca ekleyebiliyorum.
raw dosya çıktısı ya da termsvg benzeri yöntemler, stdout'a aşırı miktarda veri bastıkları için TTE için uygun değil.
AGG dokümantasyonu ve TerminalTextEffects deposu bağlantılarına göz atmak faydalı olabilir.
- Sunucu motd'sini ya da başlangıç mesajlarını her seferinde rastgele bir TTE ile süsleyip geçmek çok keyif veriyor.
  Yaptığım örneği burada görebilirsiniz.
- Bu prompt efektleri gerçekten çok güzel; işe yarasın ya da yaramasın, yapılmaya devam etmesini isterim. Resmen dalıp gidiyorum.
  TTE, bana yıllar önce Compiz pencere yöneticisinde Linux kullanmaya başlamama neden olan o büyülü efektlerin terminalde uygulanmış hali gibi geliyor.
  TTE'yi tmux ya da vim'e ekran koruyucu gibi aralıklı şekilde nasıl uygulayabileceğimi merak ediyorum; pipe ile mi bağlamak gerekir, yoksa alias olarak mı kullanmak daha iyi olur emin değilim.
  İnsanlar bunu genelde nasıl kullanıyor, geliştirirken amaç neydi ve şimdi nasıl değerlendiriliyor merak ediyorum.
  Geliştirilmeye devam etmesini umuyorum.
- t-rec de çok kullanışlı bir araç; istediğiniz pencereyi kaydedip video veya gif'e dönüştürebiliyorsunuz.
  Tam olarak aynı şey değil ama sadece terminal gif'ini hızlıca paylaşmak istiyorsanız bazen t-rec daha kolay olabiliyor.
- 15 MB'lık bir GIF gerçekten katlanılmaz.
  İçinde gezinemezsiniz, metin seçemezsiniz ve 15 kat bant genişliği israfını da göze almanız gerekir.
  Akıcı biçimde sıkıştırılabilen, kolayca gezilebilen ve erişilebilir metni alıp onu mümkün olan en kötü video formatına dönüştürmek çok yazık.
  En azından ham asciinema dosyasına ya da web görüntüleyicisine bir bağlantı da verilse iyi olur; böylece hızlı yüklenir, durdurma/ileri sarma ve kopyala-yapıştır da mümkün olur.
  Hızla dönen döngü GIF'leri, yapan kişi dışında neredeyse kimseye niyeti aktarmıyor.
asciinema.org sitesi şu anda o kadar popüler ki trafik patlaması yaşıyor; btop yayınının bağlı olduğu sunucuda CPU kullanımı %95'e çıkmış durumda.
İlgili yayın örneğini burada görebilirsiniz.
Buna rağmen BEAM üzerinde çalışan Elixir/Phoenix sunucusu, yoğun istek ve CPU kullanımına karşın hizmet vermeye devam ediyor — BEAM'in gücü bu işte.
Şu anda 2 GB RAM'li sadece iki VM ile ayakta duruyor ama yakında ölçekleme gerekeceğini hissediyorum.
- Her şeyin buluta yığıldığı bu çağda, bu kadar bilinen bir hizmetin yalnızca iki adet 2 GB VM üzerinde kararlı şekilde çalışması şaşırtıcı.
  Bugün orta seviye dizüstülerin RAM'inden bile daha az kaynakla gayet akıcı çalışıyor.
- Altyapıyı hemen büyüttükten sonra tekrar kararlı ve hızlı tepki veren bir hale geldi.
- Şu anda btop yayını ciddi şekilde takılıyor ve CPU kullanımı da %0 ile %100 arasında sürekli sert şekilde sıçrıyor.
  Acaba servis sürekli çöküp yeniden mi başlıyor diye merak ediyorum.
- Yaşasın BEAM!
- Bir ipucu olarak, btop'un yenileme aralığını düşürmek iyi olabilir; 100 ms'de çalıştırırsanız btop ciddi CPU tüketebilir.
Asciinema istemcisi Python → Golang → Python → Rust şeklinde sürekli değişmiş.
Geçmiş dokümanı ve ilgili blog yazısı da incelenebilir.
- Bu tür bir projenin hangi dilde yazıldığının çok önemli olmadığını düşünüyorum; çünkü tüm diller aşağı yukarı benzer performans verecektir.
  Kod tabanı küçük olduğu için hangi dile taşınırsa taşınsın işlevsel etkisi sınırlı kalır; bu yüzden geliştiricinin motivasyon duyduğu dile yeniden yazılması bence sorun değil.
- İlginç bir durum.
  Go'nun sorunlarının çoğunun, daha kod yazmadan önce öngörülebilir olması gerektiğini düşünüyorum; sadece biraz araştırma yapılsa bile packaging sorunları gibi şeylerin 2016'da haklı şikayetler olduğu ama sonrasında Go modules ile çözüldüğü görülebilirdi.
  Bundan sonra ClojureScript, Elixir ve Rust'a doğru sürekli yeniden yazılması, teknik trendlerin peşinden gitme izlenimi veriyor.
  Bu kadar sık dil değiştirmek, mühendislik güvenilirliğini düşürüyor.
Asciinema'ya sempati duyuyorum ve küçük katkılarla, bağışlarla projeyi destekliyorum.
Bağış bilgilerine ve Linux sistem sorunlarının Asciinema ile nasıl görüneceğine dair SadServers Replay örneğine de bakmanızı öneririm.
Asciinema, şimdiye kadar kullandığım araçlar ve ürünler arasında açık ara en iyisi.
CLI üzerinden kimlik doğrulama/yükleme akışı temiz ve sezgisel; birkaç adım olsa bile asla rahatsız edici hissettirmiyor.
Benzer tasarım başka CLI'lerde de var ama Asciinema'da hiç engelleniyormuşum gibi hissetmedim.
Gerçekten harika bir başarı, tebrikler.
Yine de asciinema'nın doğrudan SVG veya GIF olarak dışa aktarma özelliğini yerleşik sunmasını isterdim.
Böylece ayrı bir dönüştürme uygulaması olmadan Markdown dosyalarına gömülebilir ve kullanım daha da iyi olurdu.
Asciinema'nın büyük bir hayranı olarak bu çalışmayı gerçekten harika buluyorum.
Canlı yayın özelliğiyle ilgili olarak, kurucu ortağı olduğum s2.dev'in stream altyapısı üzerinde buna benzer bir şeyi kurcalayıp çalıştırmıştım; bu yapıdaysa arada bir relay olmadan da mümkün görünüyor.
Kişisel olarak btop'un gerçek zamanlı gösterimini etkileyici buldum.
Canlı yayın mimarisi için bu doküman yararlı olabilir.
Terminal için gerçek zamanlı yayın özelliği gelmişken, birinin terminal üzerine ASCII art vtuber avatarı bindirmesi eğlenceli olabilir.
- Bana Max Headroom v0.2'yi hatırlatan bir fikir.
En sevdiğim Elixir projelerinden biri olan asciinema artık Rust ile de yeniden yazıldı.
Bu gelişmeyi gerçekten çok sevdim.
Acaba komutlarda secret, key gibi hassas bilgileri otomatik ayıklayan/izleyen bir özellik de eklediler mi; artık hafif LLM'ler de bol olduğu için eskisine göre daha kolay olabilir gibi geliyor.
- CLI Rust ile yeniden yazıldı ama sunucu hâlâ Elixir/Phoenix, bu da hassas bilgi filtreleme gibi özellikler için oldukça uygun bir yapı.
- Eskiden önce Python ile yapılmamış mıydı acaba?
- Komutlardan secret/key otomatik filtreleme özelliği sorusu şaka değil miydi gerçekten merak ettim.
Twitch yayıncılarının genelde iki bilgisayarlı yayın kurmasının nedeni, birinin yayınlanan görüntüyü çalıştırması, diğerinin ise OBS ve HDMI capture işini üstlenmesidir.
Asciinema'nın yeni canlı yayın özelliği kullanılırsa, yalnızca konsolda çalışan geliştiriciler HDMI capture cihazı olmadan geliştirme makinesinin terminal ekranını doğrudan OBS makinesine aktarabilir gibi görünüyor.
Çok küçük bir programlama yayıncısı kitlesi için Asciinema 3 gerçek bir alternatif olabilir.
- Asciinema yayını söz konusuysa performansa etkisi neredeyse yok denecek kadar az olur, bu yüzden böyle bir çift cihaz kurulumuna gerek yok.
  2 PC düzeni aslında x264 kodlamasının CPU yükünden doğmuştu; ama bugün GPU ile kodlama (Nvidia NVENC) kullanıldığında yük neredeyse kalmıyor.
  OBS x264, çevrimdışı kayıtlar (YouTube videoları vb.) dışında artık pek gerekli değil.
- Twitch yayıncılarının 2 PC kullanmasının nedeni, GPU'yu yoğun kullanan oyun yayınlarında kaynak çakışmasını önlemektir.
  Ayrıca oyun sırasında sürücü çökmesi yaşanırsa yayının etkilenmesini de önler.
- Bu tür yayın ekipmanı kurulumları çoğunlukla video kodlama yükünü dağıtmak içindir; sadece konsolda çalışan programlama yayıncıları için gerçekten gerekli olduğunu sanmıyorum.