8 poin oleh GN⁺ 2025-11-13 | Belum ada komentar. | Bagikan ke WhatsApp
  • Menunjukkan kompleksitas dan keterbatasan struktur terminal yang ada, lalu mengajukan konsep terminal generasi berikutnya yang mengintegrasikan input, output, dan kontrol proses dengan cara baru
  • Menjadikan Jupyter Notebook sebagai model untuk mengeksplorasi kemungkinan penerapan antarmuka interaktif seperti rendering gambar, menjalankan ulang perintah, output yang dapat diedit, dan editor bawaan
  • Melalui contoh Warp dan iTerm2, menjelaskan secara konkret integrasi mendalam antara shell dan terminal (shell integration), pengelolaan proses jangka panjang, serta fitur pemisahan dan pemulihan sesi
  • Berdasarkan pelacakan aliran data (dataflow tracking) dan persistensi (persistence), merancang fitur lanjutan seperti undo/redo untuk perintah, eksekusi ulang otomatis, dan terminal kolaboratif
  • Menawarkan strategi pembangunan bertahap yang berkembang dari CLI transaksional → sesi persisten → RPC terstruktur → frontend bergaya Jupyter

Struktur dasar terminal

  • Terminal terdiri dari empat komponen: emulator terminal, terminal virtual (PTY), shell, dan grup proses
    • Emulator terminal adalah program yang merender struktur grid ke layar
    • PTY adalah status internal kernel yang meneruskan input ke grup proses dan menangani konversi sinyal (signal)
    • Shell berperan sebagai event loop yang membaca dan mem-parsing input lalu membuat proses
    • Proses-proses berinteraksi dengan komponen di atas melalui input dan output
  • Input bukan sekadar teks sederhana, tetapi juga mencakup sinyal (signal), sementara output tersusun dari ANSI escape sequence yang merepresentasikan format

Rancangan terminal yang lebih baik

  • Terminal saat ini memiliki banyak batasan fungsional sehingga kurang memiliki ekstensibilitas dan interaktivitas
  • Jupyter Notebook menyediakan fitur yang tidak mungkin dilakukan pada emulator VT100 tradisional
    • Rendering gambar resolusi tinggi
    • Tombol “jalankan ulang dari awal” yang mengganti output lama tanpa menambahkannya
    • “Tampilan” yang memungkinkan kode sumber dan output ditulis ulang di tempatnya (misalnya menampilkan Markdown sebagai sumber atau HTML yang telah dirender)
    • Editor bawaan dengan penyorotan sintaks, tab, panel, dukungan mouse, dan sebagainya
  • Namun, konsep notebook Jupyter yang menggunakan shell sebagai kernel menghadapi sejumlah masalah
    • Shell menerima perintah sekaligus, sehingga tab completion, penyorotan sintaks, dan saran otomatis tidak berfungsi
    • Masalah dalam menangani proses yang berjalan lama: Jupyter pada dasarnya menjalankan hingga sel selesai; pembatalan mungkin dilakukan, tetapi menjeda, melanjutkan, berinteraksi, atau melihat proses yang sedang berjalan tidak dimungkinkan
    • Tombol “jalankan ulang sel” dapat menimbulkan masalah pada status komputer, terutama bila memuat perintah seperti rm -rf
    • Undo/redo tidak berfungsi

Bagaimana ini bisa bekerja?

  • Integrasi shell (Shell Integration)

    • Terminal Warp membangun integrasi native antara terminal dan shell
      • Terminal memahami awal dan akhir setiap perintah, output, serta input pengguna
      • Diimplementasikan menggunakan fitur standar (DCS kustom)
    • iTerm2 juga dapat menggunakan kode escape OSC 133 dengan pendekatan serupa
      • Menavigasi antarperintah dengan satu shortcut
      • Notifikasi saat perintah selesai
      • Jika output keluar dari layar, perintah saat ini ditampilkan sebagai “overlay”
  • Pengelolaan proses jangka panjang

    • Interaksi (interacting):
      • Untuk berinteraksi dengan proses yang berjalan lama dibutuhkan komunikasi dua arah
        • Contoh TUI: top, gdb, vim
        • Jupyter unggul dalam merancang output interaktif yang dapat diubah dan diperbarui
      • Fitur terminal yang diharapkan: selalu menyediakan “sel input bebas”
        • Proses interaktif berjalan di bagian atas jendela, dan sel input tersedia di bagian bawah
    • Menangguhkan (suspending):
      • “Menjeda” proses disebut “kontrol pekerjaan (job control)”
      • Terminal modern diperkirakan akan menampilkan proses yang ditangguhkan dan proses latar belakang secara visual dan persisten
        • Mirip seperti IntelliJ menampilkan “sedang mengindeks...” di bilah tugas bawah
    • Memutus koneksi (disconnecting): ada tiga pendekatan untuk pemisahan dan pemulihan sesi
      • Tmux / Zellij / Screen: menyisipkan emulator terminal tambahan di antara emulator terminal dan program. Server memiliki PTY dan merender output, sementara klien menampilkan output di emulator terminal yang sebenarnya. Klien dapat diputus, disambungkan kembali, dan banyak klien dapat terhubung secara bersamaan. iTerm dapat berfungsi sebagai kliennya sendiri yang melewati klien tmux dan berkomunikasi langsung dengan server
      • Mosh: pengganti SSH. Mendukung penyambungan ulang ke sesi terminal setelah gangguan jaringan. Menjalankan state machine di server dan memutar ulang perbedaan inkremental viewport ke klien. Multiplexing dan scrollback diasumsikan ditangani oleh emulator terminal. Karena klien benar-benar berjalan di sisi jaringan, pengeditan baris lokal terasa instan
      • alden/shpool/dtach/abduco/diss: hanya menangani pemisahan/lanjutkan sesi melalui model klien/server, tanpa jaringan, scrollback, atau emulator terminal sendiri. Tingkat pemisahannya lebih tinggi dibanding tmux dan mosh
  • Menjalankan ulang dan membatalkan

    • Solusinya adalah pelacakan aliran data
    • Saat ini hal ini diimplementasikan oleh pluto.jl dengan terhubung ke kompiler Julia
      • Memperbarui sel yang bergantung pada sel sebelumnya secara real-time
      • Tidak memperbarui sel jika dependensinya tidak berubah
      • Seperti Jupyter yang menyerupai spreadsheet, menjalankan ulang kode hanya saat diperlukan
    • Dapat digeneralisasi melalui persistensi ortogonal (orthogonal persistence)
      • Menyandbox proses dan melacak semua I/O, mencegah hal-hal yang “terlalu aneh” selama tidak berkomunikasi dengan proses lain di dalam sandbox
      • Proses dapat diperlakukan sebagai fungsi murni dari inputnya, dengan input berupa “seluruh file system, semua variabel lingkungan, semua properti proses”

Fitur turunan

  • Memerlukan frontend Jupyter:
    • Runbooks (sebenarnya dapat dibangun hanya dengan Jupyter dan primitif PTY)
    • Kustomisasi terminal menggunakan CSS biasa tanpa bahasa kustom aneh atau kode warna ANSI
    • Pencarian perintah berdasarkan output/timestamp: saat ini bisa mencari di seluruh output sesi atau riwayat semua input perintah, tetapi tidak ada filter pintar dan output tidak bertahan lintas sesi
  • Memerlukan integrasi shell:
    • Timestamp dan durasi eksekusi untuk setiap perintah
    • Pengeditan baris lokal bahkan saat melintasi batas jaringan
    • IntelliSense untuk perintah shell tanpa harus menekan tab, dengan rendering terintegrasi di terminal
  • Memerlukan pelacakan sandbox:
    • Semua kemampuan dari pelacakan sandbox: terminal kolaboratif, kueri file yang dimodifikasi oleh perintah, asciinema yang dapat diedit saat runtime, pelacakan build system
    • Memperluas pencarian pintar agar juga dapat mencari berdasarkan status disk pada saat perintah dijalankan
    • Memperluas undo/redo ke model percabangan mirip git (emacs undo-tree sudah mendukung ini), dan menyediakan beberapa “tampilan” untuk pohon proses
    • Dengan model undo-tree dan sandboxing, LLM dapat diberi akses ke proyek dan beberapa dijalankan secara paralel pada saat yang sama, tanpa saling menimpa status, serta hasil kerja dapat diperiksa, diedit, dan disimpan sebagai runbook untuk digunakan nanti
    • Terminal yang hanya memeriksa status yang ada tanpa memengaruhi keadaan mesin di lingkungan produksi

Strategi pembangunan bertahap

  • Tahap 1: semantik transaksional (transactional semantics)

    • Saat mendesain ulang terminal, memulai dari emulator terminal adalah pendekatan yang keliru
      • Pengguna cenderung terikat pada emulatornya, beserta konfigurasi, tampilan, dan pengaturan key binding
      • Biaya berpindah emulator tinggi
    • Cara yang benar adalah memulai dari lapisan CLI
      • Program CLI mudah dipasang dan dijalankan, sehingga biaya perpindahannya sangat rendah
      • Bisa digunakan sekali pakai tanpa mengubah seluruh workflow
    • Menulis CLI yang mengimplementasikan semantik transaksional untuk terminal
      • Antarmuka seperti transaction [start|rollback|commit]
      • Semua yang dijalankan setelah start dapat dibatalkan
      • Ini saja sudah cukup untuk membangun seluruh bisnis
  • Tahap 2: sesi persisten (Persistent Sessions)

    • Setelah semantik transaksional tersedia, pisahkan persistensi dari tmux dan mosh
    • Untuk mendapatkan persistensi PTY, perlu memperkenalkan model klien/server
      • Kernel mengasumsikan kedua sisi PTY selalu terhubung
      • Dapat diimplementasikan secara sederhana dengan perintah seperti alden atau pustaka serupa, tanpa memengaruhi emulator terminal atau program yang berjalan di dalam sesi PTY
    • Untuk mendapatkan scrollback, server menyimpan input/output tanpa batas dan memutarnya ulang saat klien tersambung kembali
      • Emulator terminal menyediakan scrollback native yang diperlakukan seperti output lainnya
      • Dapat memutar ulang dan melanjutkan dari titik awal mana pun
      • Perlu mem-parsing kode escape ANSI, tetapi ini cukup realistis untuk dikerjakan
    • Untuk melanjutkan koneksi jaringan seperti mosh, gunakan Eternal TCP (dapat dibangun di atas QUIC untuk efisiensi yang lebih baik)
      • Memisahkan persistensi PTY dan persistensi koneksi jaringan
      • Eternal TCP adalah optimasi murni: bisa dibangun di atas skrip bash yang menjalankan ssh host eternal-pty attach dalam loop
    • Pada titik ini, seperti tmux, banyak klien dapat terhubung ke satu sesi terminal, sementara manajemen jendela tetap ditangani oleh emulator terminal
      • Jika menginginkan manajemen jendela terintegrasi, emulator terminal dapat menggunakan protokol tmux -CC seperti iTerm
    • Semua bagian pada tahap ini dapat dilakukan secara paralel dan independen dari semantik transaksional, tetapi belum cukup untuk membangun bisnis
  • Tahap 3: RPC terstruktur

    • Bergantung pada model klien/server
    • Jika server berada di antara emulator terminal dan klien, fitur seperti penandaan I/O dengan metadata dapat diimplementasikan
      • Semua data dapat diberi timestamp
      • Input dan output dapat dibedakan
      • xterm.js bekerja dengan cara serupa
    • Jika digabungkan dengan integrasi shell, maka prompt shell dan output program dapat dibedakan pada lapisan data
    • Mendapatkan log terstruktur dari sesi terminal
      • Memutar ulang log sebagai rekaman seperti asciinema
      • Mengubah prompt shell tanpa menjalankan ulang semua perintah
      • Mengimpor ke Jupyter Notebook atau Atuin Desktop
      • Menyimpan perintah dan menjalankannya kembali nanti sebagai skrip
      • Terminal menjadi data
  • Tahap 4: frontend mirip Jupyter

    • Ini adalah tahap pertama yang benar-benar menyentuh emulator terminal, dan sengaja diletakkan paling akhir
      • Karena biaya perpindahannya paling tinggi
    • Menyediakan UI yang baik dengan memanfaatkan semua kemampuan yang telah dibangun
    • CLI transaction tidak lagi diperlukan kecuali jika ingin transaksi bertingkat
      • Seluruh sesi terminal dimulai sebagai transaksi secara default
    • Karena semua bagian telah digabungkan, semua fitur turunan yang disebutkan di atas dapat disediakan

Kesimpulan

  • Arsitektur ini berani, ambisius, dan diperkirakan membutuhkan hingga sekitar 10 tahun untuk dibangun sepenuhnya
  • Perlu dijalankan bertahap dengan kesabaran
  • Tulisan ini berharap bisa menginspirasi seseorang untuk mulai membangunnya sendiri

Belum ada komentar.

Belum ada komentar.