Geleceğin terminali

• Mevcut terminal yapısının karmaşıklığına ve sınırlarına işaret ederek, girdi, çıktı ve süreç kontrolünü yeniden birleştiren yeni nesil bir terminal kavramı sunuyor
• Jupyter Notebook model alınarak, görüntü işleme, komutları yeniden çalıştırma, düzenlenebilir çıktı ve yerleşik editör gibi etkileşimli arayüzlerin nasıl mümkün olabileceği inceleniyor
• Warp ve iTerm2 örnekleri üzerinden, kabuk ile terminal arasındaki derin entegrasyon (shell integration), uzun süre çalışan süreç yönetimi, oturum ayırma ve kurtarma işlevleri somut biçimde açıklanıyor
• Veri akışı takibi (dataflow tracking) ve kalıcılık (persistence) temelinde, komutlar için undo/redo, otomatik yeniden çalıştırma ve işbirlikçi terminal gibi genişletilmiş özellikler tasarlanıyor
• Aşamalı bir yaklaşımla işlemsel CLI → kalıcı oturumlar → yapılandırılmış RPC → Jupyter benzeri frontend yönünde ilerleyen kademeli bir inşa stratejisi öneriliyor

---

Terminalin temel yapısı

• Terminal dört bileşenden oluşur: terminal emülatörü, sanal terminal (PTY), kabuk, süreç grubu
  • Terminal emülatörü, ekranda ızgara yapısını render eden programdır
  • PTY, çekirdek içindeki durumdur; girdiyi süreç grubuna iletir ve sinyal dönüşümünü üstlenir
  • Kabuk, girdiyi okuyup ayrıştıran ve süreç oluşturan bir olay döngüsü görevi görür
  • Süreçler, girdi ve çıktı üzerinden bu bileşenlerle etkileşime girer
• Girdi yalnızca basit metin değildir; sinyaller de içerir. Çıktı ise biçimlendirmeyi ifade eden ANSI kaçış dizilerinden oluşur

Daha iyi bir terminal tasarımı

• Mevcut terminaller işlevsel açıdan çok sayıda kısıta sahip olduğu için genişletilebilirlik ve etkileşimlilik bakımından yetersiz kalır
• Jupyter Notebook, geleneksel bir VT100 emülatöründe mümkün olmayan işlevler sunar
  • Yüksek çözünürlüklü görüntü render etme
  • Geçmiş çıktıyı eklemek yerine değiştiren bir "baştan yeniden çalıştır" düğmesi
  • Kaynak kodun ve çıktının yerinde yeniden yazılabildiği "görünümler" (ör. Markdown'ı kaynak olarak ya da render edilmiş HTML olarak göstermek)
  • Sözdizimi vurgulama, sekmeler, paneller ve fare desteği içeren yerleşik bir editör
• Ancak kabuğu çekirdek olarak kullanma fikrine dayalı bir Jupyter notebook çeşitli sorunlarla karşılaşır
  • Kabuk komutları tek seferde aldığı için sekme tamamlama, sözdizimi vurgulama ve otomatik öneriler çalışmaz
  • Uzun süren süreçleri ele alma sorunu: Jupyter varsayılan olarak hücre tamamlanana kadar çalıştırır; iptal edilebilir ama duraklatma, sürdürme, etkileşim kurma ve çalışan süreçleri görüntüleme mümkün değildir
  • "Hücreyi yeniden çalıştır" düğmesi bilgisayarın durumunda sorunlara yol açabilir (özellikle rm -rf gibi komutlar içeriyorsa)
  • Geri alma / yeniden yapma çalışmaz

Bu nasıl çalışabilir?

• Kabuk entegrasyonu (Shell Integration)

  • Warp terminali, terminal ile kabuk arasında yerel entegrasyon kurar
    • Terminal, her komutun başlangıcını ve bitişini, çıktısını ve kullanıcı girdisini anlayabilir
    • Standart özellikler (özel DCS) kullanılarak uygulanır
  • iTerm2 de benzer biçimde OSC 133 kaçış kodlarını kullanabilir
    • Tek bir kısayolla komutlar arasında gezinme
    • Komut tamamlandığında bildirim
    • Çıktı ekranın dışına taştığında mevcut komutu "overlay" olarak gösterme

• Uzun süre çalışan süreç yönetimi

  • Etkileşim kurma (interacting):
    • Uzun süren bir süreçle etkileşim kurmak için çift yönlü iletişim gerekir
      • TUI örnekleri: top, gdb, vim
      • Jupyter, değiştirilebilir ve güncellenebilir etkileşimli çıktı tasarımında güçlüdür
    • Beklenen terminal özelliği: her zaman bir "serbest giriş hücresi" sunmak
      • Etkileşimli süreç pencerenin üst kısmında çalışırken alt kısımda giriş hücresi bulunur
  • Askıya alma (suspending):
    • Bir süreci "duraklatmak", "iş denetimi (job control)" olarak adlandırılır
    • Modern terminallerin, askıya alınmış ve arka plandaki süreçleri kalıcı görsel göstergelerle sunması beklenir
      • IntelliJ'nin alt görev çubuğunda "Dizin oluşturuluyor..." göstermesine benzer
  • Bağlantıyı ayırma (disconnecting): oturum ayırma ve kurtarma için üç yaklaşım vardır
    • Tmux / Zellij / Screen: terminal emülatörü ile program arasına ek bir terminal emülatörü yerleştirir. Sunucu PTY'ye sahip olur ve çıktıyı render eder; istemci ise çıktıyı gerçek terminal emülatöründe gösterir. İstemci ayrılabilir, yeniden bağlanabilir ve birden fazla istemci aynı anda bağlanabilir. iTerm, tmux istemcisini atlayıp doğrudan sunucuyla iletişim kuran kendi istemcisi gibi çalışır
    • Mosh: SSH yerine geçen bir araçtır. Ağ kesintisinden sonra terminal oturumuna yeniden bağlanmayı destekler. Sunucuda bir durum makinesi çalıştırır ve görünüm alanındaki artımlı farkları istemciye oynatır. Multiplexing ve scrollback'in terminal emülatörü tarafından ele alınması beklenir. İstemci ağ tarafında fiilen çalıştığı için yerel satır düzenleme anlıktır
    • alden/shpool/dtach/abduco/diss: yalnızca istemci/sunucu modeliyle oturum ayırma ve sürdürmeyi ele alır; ağ desteği ya da scrollback içermez, kendi terminal emülatörünü de barındırmaz. tmux ve mosh'a kıyasla daha yüksek düzeyde ayrışma sağlar

• Yeniden çalıştırma ve geri alma

  • Çözüm, veri akışı takibidir
  • Bu yaklaşım bugün pluto.jl tarafından Julia derleyicisine bağlanarak uygulanıyor
    • Önceki hücrelere bağımlı hücreleri gerçek zamanlı günceller
    • Bağımlılıklar değişmediyse hücreleri güncellemez
    • Gerektiğinde kodu yeniden çalıştıran, elektronik tablo benzeri bir Jupyter deneyimi sunar
  • Bunun ortogonal kalıcılık (orthogonal persistence) ile genellenmesi
    • Süreçleri sandbox içine alır, tüm I/O'yu izler ve sandbox içindeki başka süreçlerle iletişim kurmadıkları sürece "fazla tuhaf" şeyleri engeller
    • Süreçler, girdinin saf fonksiyonları olarak ele alınabilir; girdi ise "tüm dosya sistemi, tüm ortam değişkenleri, tüm süreç özellikleri"dir

Türetilen işlevler

• Jupyter frontend gerekli:
  • Runbook'lar (aslında yalnızca Jupyter ve PTY primitifleriyle inşa edilebilir)
  • Garip özel diller veya ANSI renk kodları olmadan, sade CSS kullanan terminal özelleştirmesi
  • Çıktı/zaman damgasına göre komut arama: mevcut oturumun tüm çıktısında ya da tüm komut girdi geçmişinde arama yapılabilir, ancak akıllı filtreler yoktur ve çıktı oturumlar arasında kalıcı değildir
• Kabuk entegrasyonu gerekli:
  • Her komut için zaman damgası ve çalışma süresi
  • Ağ sınırlarının ötesinde bile yerel satır düzenleme
  • Sekmeye basmadan kabuk komutları için IntelliSense ve terminale entegre render etme
• Sandbox takibi gerekli:
  • Sandbox takibinin tüm işlevleri: işbirlikçi terminal, komutlarla değiştirilen dosyuları sorgulama, çalışma anında düzenlenebilir asciinema, build sistemi takibi
  • Akıllı aramayı, komutun çalıştırıldığı andaki disk durumunda da arama yapacak şekilde genişletme
  • Geri alma / yeniden yapmayı git'e benzer bir dallanma modeline genişletme (emacs undo-tree bunu zaten destekler), süreç ağacının birden fazla "görünümünü" sunma
  • Undo-tree modeli ve sandboxing sayesinde LLM'lere proje erişimi verip birden fazlasını aynı anda paralel çalıştırmak mümkün olur; birbirlerinin durumunu ezmezler ve yapılan işleri inceleyip düzenleyebilir, daha sonra kullanılacak runbook'lar olarak kaydedebilirler
  • Üretim ortamında makinenin durumunu etkilemeden yalnızca mevcut durumu inceleyen terminaller

Adım adım inşa stratejisi

• 1. aşama: İşlemsel semantik (transactional semantics)

  • Terminali yeniden tasarlarken terminal emülatöründen başlamak yanlış bir yaklaşımdır
    • Kullanıcılar emülatörlerine bağlanır; yapılandırma, görünüm ve tuş atamalarını özelleştirir
    • Emülatör değiştirme maliyeti yüksektir
  • Doğru yöntem, CLI katmanından başlamaktır
    • CLI programlarını kurmak ve çalıştırmak kolaydır, geçiş maliyeti çok düşüktür
    • Tüm iş akışını değiştirmeden tek seferlik kullanılabilir
  • Terminal için işlemsel anlam taşıyan bir CLI yazmak
    • transaction [start|rollback|commit] gibi bir arayüz
    • start sonrasında yapılan her şey geri alınabilir
    • Yalnızca bununla bile tüm işi kurmak mümkün olabilir

• 2. aşama: Kalıcı oturumlar (Persistent Sessions)

  • İşlemsel semantik sağlandıktan sonra kalıcılığı tmux ve mosh'tan ayırmak
  • PTY kalıcılığı elde etmek için istemci/sunucu modeli gerekir
    • Çekirdek, PTY'nin iki tarafının da her zaman bağlı olacağını varsayar
    • alden benzeri komutlar ya da benzer kütüphaneler kullanılarak, terminal emülatörü veya PTY oturumu içinde çalışan programları etkilemeden basitçe uygulanabilir
  • Scrollback sağlamak için sunucu giriş/çıkışı süresiz olarak depolar ve istemci yeniden bağlandığında tekrar oynatır
    • Terminal emülatörü bunu diğer çıktılar gibi ele alınan yerel scrollback olarak sunar
    • Rastgele bir başlangıç noktasından oynatma ve sürdürme mümkündür
    • ANSI kaçış kodlarını ayrıştırmak gerekir ama yeterli çabayla yapılabilir
  • Mosh benzeri ağ üzerinden sürdürme için Eternal TCP kullanmak (verimlilik için QUIC üzerinde inşa edilebilir)
    • PTY kalıcılığı ile ağ bağlantısı kalıcılığını ayırır
    • Eternal TCP saf bir optimizasyondur: ssh host eternal-pty attach komutunu döngüde çalıştıran bir bash betiği üzerine kurulabilir
  • Bu noktada, tmux'taki gibi tek bir terminal oturumuna birden fazla istemci bağlanabilir; pencere yönetimini ise hâlâ terminal emülatörü üstlenir
    • Tümleşik pencere yönetimi istenirse, terminal emülatörü iTerm gibi tmux -CC protokolünü kullanabilir
  • Bu aşamadaki her parça işlemsel semantikten bağımsız biçimde paralel yürütülebilir, ancak tek başına iş kurmak için yeterli değildir

• 3. aşama: Yapılandırılmış RPC

  • İstemci/sunucu modeline dayanır
  • Sunucu terminal emülatörü ile istemci arasına girdiğinde, I/O'yu metadata ile etiketleme gibi işlevler uygulanabilir
    • Tüm verilere zaman damgası eklenebilir
    • Girdi ile çıktı ayırt edilebilir
    • xterm.js benzer şekilde çalışır
  • Kabuk entegrasyonuyla birleştirildiğinde, veri katmanında kabuk istemi ile program çıktısı ayrıştırılabilir
  • Terminal oturumunun yapılandırılmış günlüğü elde edilir
    • Günlük asciinema gibi kayıt olarak tekrar oynatılabilir
    • Tüm komutları yeniden çalıştırmadan kabuk istemi dönüştürülebilir
    • Jupyter Notebook veya Atuin Desktop'a içe aktarılabilir
    • Komutlar kaydedilip daha sonra betik olarak yeniden çalıştırılabilir
    • Terminal veriye dönüşür

• 4. aşama: Jupyter benzeri frontend

  • Terminal emülatörüne ilk kez dokunulan aşamadır ve bilinçli olarak en sona bırakılmıştır
    • Çünkü geçiş maliyeti en yüksektir
  • İnşa edilen tüm işlevlerden yararlanarak iyi bir arayüz sunar
  • transaction CLI'si, iç içe işlemler istenmediği sürece artık gerekli değildir
    • Tüm terminal oturumu varsayılan olarak bir işlemle başlar
  • Tüm parçalar birleştirildiği için yukarıda sözü edilen tüm türetilmiş işlevler sağlanır

Sonuç

• Bu yapı iddialı ve son derece hırslı; tamamının inşasının yaklaşık 10 yıla kadar sürebileceği öngörülüyor
• Sabırla, adım adım ilerlemek gerekiyor
• Bu yazının birine ilham verip bunu bizzat inşa etmeye başlamasını umuyor