Terminal Masa Depan

 (jyn.dev)
8 poin oleh GN⁺ 2025-11-13 | 1 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”
      Iklan

  • 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
    Iklan

  • 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
      Iklan
    • 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
    Iklan

  • 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

Bacaan terkait

1 komentar

 
GN⁺ 2025-11-13
Komentar Hacker News

  • Setelah membaca seluruh tulisan, pada awalnya ini tampak seperti sekadar daftar keinginan bergaya NIH
    Padahal sudah ada berbagai alternatif yang bisa menggantikan terminal, tetapi tidak disebutkan dalam tulisan itu
    Misalnya Emacs adalah VM berbasis Lisp, sehingga redefinisi fungsi itu mudah dan perintah merupakan fungsi yang diberi anotasi. Output dikelola sebagai buffer, dan banyak jendela serta frame bisa ditata dalam bentuk ubin. CLI bisa tetap digunakan apa adanya (vterm, eat, dll.), atau dialihkan ke alur REPL (shell-mode, eshell, dll.). Mendukung grafik juga, meski bukan konteks 2D penuh
    Contoh lain, Acme mirip Emacs, tetapi merupakan lingkungan teks interaktif di mana semua teks bisa menjadi perintah. Smalltalk juga punya filosofi serupa, tetapi lebih dekat ke IDE

    • Emacs memiliki Org-mode dan org-babel, sehingga bisa bekerja seperti Jupyter notebook. Bahkan bisa berkomunikasi dengan kernel Jupyter
      Saya memakai GPTel di Emacs untuk otomatis memotong PDF buku pelajaran Latin lama, lalu mengubahnya ke format org-mode melalui OCR. Hasilnya, saat memilih kata saya bisa langsung mencari kamus, dan saat memilih kalimat LLM akan melakukan analisis tata bahasa. Editor teks dari tahun 1970-an itu pun berubah menjadi platform belajar futuristik
    • Saya ingin tahu lebih banyak tentang Acme. Sulit dicari lewat pencarian.
      Platform seperti Emacs, Jupyter, dan VSCode memang kuat, tetapi lebih merupakan platform berbasis kustomisasi daripada aplikasi yang selesai jadi.
      Jika benar-benar inovatif, seharusnya didistribusikan dalam bentuk yang mudah direproduksi, seperti container Docker atau executable, bukan menuntut konfigurasi rumit
    • Saya rasa inti tulisannya adalah membuka model data terminal. Yang penting adalah bahwa berbagai fungsi bisa dibangun di atasnya
    • Hal unik dari Emacs adalah independensi UI. Aplikasi yang ditulis dalam Elisp berjalan sama baik di terminal maupun GUI. Dua puluh tahun lalu saya menulis Elisp di terminal, dan pengguna GUI sama sekali tidak merasakan perbedaannya. Tidak ada platform lain seperti ini

  • Saya ragu konsep penerus terminal harus tetap berbasis teks
    Terminal masa depan bisa saja berbentuk API, atau memungkinkan pemanggilan jarak jauh melalui autentikasi OAuth. Input dan output mungkin tak lagi berupa teks CLI.
    Sebagai gantinya, kita bisa beralih ke input/output berbasis objek, sehingga perintah dan struktur data bisa dijelajahi sebagai API.
    Terminal adalah warisan tahun 70-an, dan saat ini alternatif yang lebih baik sangat mungkin dibuat

    • Sebenarnya terminal bukan berpusat pada teks, melainkan berbasis aliran token dua arah. Kesederhanaan inilah yang memungkinkan komposisi ala Unix.
      Jika output JSON ditambahkan, pipeline bisa disusun dengan alat seperti jq.
      Berkat filosofi “worse is better” yang menjadikan kesederhanaan sebagai keunggulan, sistem ini terus berevolusi selama puluhan tahun
    • Saya juga setuju soal batasan standard input/output pada CLI. Fakta bahwa data dan representasi adalah hal yang sama membatasi komposabilitas.
      Jika yang dipertukarkan adalah objek yang mendeskripsikan dirinya sendiri seperti di PowerShell, komposisi bisa menjadi jauh lebih kuat
      Contoh terkait saya rangkum di tulisan blog saya
    • PowerShell menarik, tetapi ada kekurangan karena makin mendekati bahasa pemrograman.
      Alur intuitif berbasis perintah menghilang, dan kita harus menghafal struktur API.
      Jika ada autocomplete berbasis AI dan fitur penjelajahan struktur objek, kelemahan ini mungkin bisa diatasi
    • Saya juga sering memakai Nushell. Lebih rapi daripada PowerShell, dan tidak bergantung pada Microsoft
      https://www.nushell.sh/
    • Alternatif terminal non-teks sebenarnya sudah ada.
      Tetapi terminal evolusioner berbasis teks tetap menarik jika ada usulan konkret yang bisa dibayangkan

  • Alasan terminal bertahan sampai sekarang adalah kompatibilitas dan kemampuan otomasi
    Dibanding GUI, jauh lebih mudah discript, dan semuanya bisa direproduksi serta bisa dicari
    Dulu saya merasa pergantian alt-screen di Neovim tidak nyaman, dan detail UX semacam ini juga penting
    Saat pertama kali mengenal komputer, dan saat kemudian belajar terminal, saya jatuh cinta dua kali

  • Proyek terkait antara lain

    • Arcan — mengusulkan protokol baru untuk aplikasi TUI
    • Shelter — shell filesystem yang bisa di-branch seperti Git
    • Shelter membutuhkan snapshot filesystem, tetapi idenya benar-benar keren
    • Saya rasa tulisan yang tidak menyebut Arcan itu tidak lengkap. Ini sudah bisa dipakai
      • Baru pertama kali mendengarnya, dan benar-benar menarik. Terima kasih atas tautannya

  • Delapan belas bulan lalu saya mencoba eksperimen serupa di Windows Terminal
    Tercatat dalam komentar GitHub
    Tetapi setelah mencoba Polyglot Notebooks, saya beralih karena itu terasa jauh lebih alami
    Mengganti backend imperatif menjadi kernel Jupyter lalu memakainya sebagai dokumen interaktif bergaya notebook jauh lebih efisien

    • Saya juga sedang mencari sistem seperti ini. Sepertinya lebih cocok untuk LLM atau lingkungan kerja pribadi
    • Memasukkan konsep notebook ke Windows Terminal benar-benar ide yang keren. Semoga ada lebih banyak percobaan seperti ini

  • Dulu saya membuat shell+terminal berbasis pemrograman fungsional lewat proyek bernama TopShell
    https://github.com/topshell-language/topshell#readme
    Ada potensinya, tetapi masih perlu banyak pekerjaan sebelum bisa menjadi alternatif yang lengkap

  • Saya sedang mencari terminal yang bisa menampilkan gambar atau video
    Akan bagus jika ada terminal yang sekadar bertindak seperti browser.
    Misalnya langsung membuka sesuatu secara interaktif lewat perintah seperti browser google.com/maps

    • Tetapi fungsi seperti itu bukan peran terminal, melainkan program terpisah (fbi, omxplayer, dll.)

  • Ini adalah usulan untuk memperluas pseudo-terminal (PTY) dengan menambahkan kanal out-of-band berbasis JSON-RPC
    Escape sequence yang ada sekarang punya banyak keterbatasan.
    Dengan cara ini, transisi bisa dilakukan secara bertahap dan tetap kompatibel ke belakang.
    Seperti LSP atau MCP, negosiasi fitur bisa dilakukan, dan kernel cukup menyediakan kanalnya saja

    • JSON tidak cocok untuk tujuan ini. Format biner seperti DER atau SDSER jauh lebih efisien
    • Pendekatan modern adalah mengirim pesan untuk pengguna ke stderr, dan JSON yang ramah mesin ke stdout
      Dengan begitu pipeline dan redirection tetap berfungsi seperti biasa, dan output berwarna juga tetap terjaga