FTL v0.1.0 Rilis: OS Cloud yang Isolasi Container seperti VM, Kini dengan Rust Async

FTL v0.1.0 dirilis 3 Oktober 2026 oleh Seiya Nuta sebagai sistem operasi eksperimental untuk cloud yang menjalankan tiap container sebagai instance OS di ruang pengguna. Kernelnya hanya menyediakan antarmuka minimal mirip hypervisor, sementara sebagian besar konsep sistem operasi seperti proses Linux, VFS, dan TCP/IP hidup di dalam pustaka bersama yang bisa dikembangkan seperti aplikasi biasa. Rilis ini menambahkan dukungan async Rust lewat runtime Tokio multi-thread, sejumlah besar panggilan sistem Linux yang sebelumnya belum ada, dan dukungan QEMU microVM.

TL;DR

• FTL v0.1.0 dirilis 3 Oktober 2026 dan membawa runtime Tokio multi-thread ke dalam kernel.
• Setiap container berjalan sebagai instance OS di userspace, bukan sekadar proses yang berbagi kernel.
• Lapisan kompatibilitas Linux bertambah: thread, futex, epoll, signal, tty, brk, mmap, dup3, pipe, dan eventfd.
• Rilis November 2026 dijadwalkan membawa filesystem untuk beban stateless dan pembuatan container dinamis.

Apa Itu FTL dan Kenapa Pendekatannya Berbeda?

FTL adalah sistem operasi yang memperlakukan OS sebagai pustaka. Halaman resmi proyeknya menyebut dua hal sebagai inti desain: kamu bisa membangun OS sendiri sebagai library, dan kernelnya mengisolasi container atau instance OS userspace lebih baik daripada kernel monolitik yang ada. Konsekuensinya, menambah fitur, men-debug, dan meng-upgrade OS dilakukan seperti menulis aplikasi biasa, bukan seperti menambal kernel yang sedang berjalan.

Perbedaan utamanya ada di pembagian tanggung jawab. Pada Linux, namespace dan cgroup membatasi proses yang tetap berjalan di atas satu kernel bersama. Di FTL, kernel hanya menyediakan antarmuka kecil untuk mengimplementasikan panggilan sistem Linux di userspace, mirip cara hypervisor menyediakan perangkat virtual untuk tamu. Proses Linux, virtual filesystem, dan tumpukan TCP/IP diimplementasikan di dalam instance userspace tiap container, bukan di kernel bersama.

Proyek ini menyebut dirinya menggabungkan kelebihan microkernel yang fleksibel dan aman dengan kernel monolitik yang sederhana dan cepat. Isolasi yang dipakai berbasis user mode, jadi tidak memerlukan mesin bare-metal maupun akselerasi virtualisasi perangkat keras. FTL juga kompatibel dengan biner Linux: server HTTP berbasis Rust yang menyajikan situs ftl-os.org adalah aplikasi Linux yang berjalan di atas FTL, dan penulisnya menyebut blog pribadinya sendiri bisa segera dimigrasikan ke sana.

Yang menarik dari pendekatan ini bukan sekadar isolasi. Karena OS hidup sebagai pustaka, tiap container bisa membawa implementasi sistem operasinya sendiri tanpa harus menunggu patch masuk ke kernel upstream. Untuk platform yang harus menjalankan kode dari banyak penyewa berbeda, kemampuan memodifikasi perilaku OS per penyewa tanpa menyentuh kernel bersama adalah keuntungan struktural yang sulit ditiru model container biasa.

Apa Saja yang Baru di FTL v0.1.0?

Perubahan terbesar pada rilis ini adalah masuknya dukungan Rust async lewat runtime Tokio multi-thread. Sebelumnya, menulis kode yang menunggu I/O di FTL berarti harus mengakalinya sendiri; sekarang pola async standar ekosistem Rust bisa dipakai langsung di dalam kernel maupun aplikasi userspace. Bagi pengembang yang terbiasa dengan tokio, ini menghilangkan salah satu hambatan terbesar untuk memindahkan aplikasi ke FTL.

Selain itu, v0.1.0 menambahkan banyak bagian yang sebelumnya hilang dari lapisan kompatibilitas Linux. Daftarnya panjang: thread Linux, futex, epoll, signal, tty, brk, mmap, dup3, pipe, eventfd, dan lainnya. Ada juga panggilan sistem konsol untuk akses shell lewat port serial, API wall-clock time, serta dukungan virtio-mmio dan QEMU microVM. Halaman memori anonim sekarang dialokasikan secara lazy, dan rilis ini menambahkan pengerasan keamanan seperti SMEP dan SMAP pada arsitektur x86-64.

Ada satu catatan yang perlu diperhatikan siapa pun yang berencana memakai FTL untuk beban nyata: panggilan sistem Linux yang bersifat blocking belum bisa diinterupsi oleh signal. Untuk aplikasi yang mengandalkan pembatalan operasi lewat signal, batasan ini berarti perilakunya belum sama dengan Linux asli. Ini juga menjelaskan mengapa status proyek masih eksperimental meski daftar fiturnya sudah panjang.

Rilis berikutnya, yang dijadwalkan November 2026, disebut akan membawa filesystem yang dioptimalkan untuk beban stateless seperti ephemeral volume Kubernetes, pembuatan container Linux dinamis, dan konsep sandbox yang lebih baik untuk menjalankan kode tak tepercaya. Ketiganya mengarah ke satu tujuan yang sama: menjadikan FTL praktis untuk menjalankan beban kerja cloud, bukan hanya demonstrasi kemampuan teknis.

Apa Saja Keterbatasan FTL Saat Ini?

Batasan paling nyata adalah statusnya yang masih eksperimental. Pengumuman rilis menyebut lapisan kompatibilitas Linux baru saja mendapat potongan besar, yang berarti sebelum v0.1.0 banyak panggilan sistem yang belum tersedia. Proyek yang bergantung pada panggilan sistem langka, io_uring, atau fitur kernel yang sangat baru berisiko menemukan celah yang belum diimplementasikan.

Batasan kedua adalah soal signal. Panggilan sistem yang bersifat blocking belum bisa diinterupsi oleh signal. Pada Linux, banyak pola pemrograman mengandalkan signal untuk membatalkan operasi yang sedang menunggu, misalnya menutup koneksi yang macet. Di FTL, pola seperti ini belum bisa diandalkan, sehingga aplikasi yang memakainya perlu penyesuaian atau menunggu rilis berikutnya.

Batasan ketiga adalah ekosistem perkakas. Linux punya puluhan tahun alat observabilitas, tracing, dan debugging yang sudah matang. FTL masih membangun fondasinya, jadi kemampuan mendiagnosis masalah di produksi belum setara. Untuk tim yang bergantung pada eBPF, perf, atau alat serupa, ini hambatan yang tidak bisa diabaikan hanya karena arsitekturnya menarik.

Keempat, belum ada angka benchmark publik yang luas untuk beban produksi nyata. Pengumuman rilis berfokus pada fitur dan arah pengembangan, bukan pada perbandingan kinerja dengan container Linux atau VM. Tanpa data itu, klaim soal isolasi yang lebih baik dengan kinerja setara masih perlu diverifikasi secara mandiri sebelum dijadikan dasar keputusan arsitektur.

Meski begitu, keterbatasan ini wajar untuk proyek berusia satu tahun. Yang penting adalah arah perbaikannya jelas: tiap rilis menutup celah kompatibilitas, dan rilis November 2026 sudah punya target konkret berupa filesystem untuk beban stateless serta pembuatan container dinamis. Untuk sekarang, posisi FTL paling masuk akal adalah objek riset dan eksperimen, bukan pengganti langsung container produksi.

Kelima, soal dokumentasi dan jalur upgrade. Karena OS diperlakukan sebagai pustaka, setiap instance container bisa membawa versi logika sistem operasinya sendiri. Itu fleksibel, tetapi juga berarti operator harus memikirkan kompatibilitas antar versi pustaka OS yang berjalan berdampingan, sesuatu yang pada Linux biasanya ditangani sekali di tingkat kernel. Belum ada panduan publik soal bagaimana menangani campuran versi ini di lingkungan besar, sehingga tim yang mengadopsi lebih awal kemungkinan harus menyusun praktiknya sendiri.

Keenam, belum ada jalur dukungan komersial. Proyek ini dikembangkan oleh satu orang dengan lisensi terbuka, sehingga tidak ada SLA, tidak ada tim yang bisa dihubungi saat produksi bermasalah, dan tidak ada jaminan perbaikan cepat untuk bug yang menghambat. Untuk eksperimen pribadi itu bukan masalah, tetapi untuk beban bisnis faktor ini sering lebih menentukan daripada keunggulan arsitektur.

Bagaimana FTL Dibandingkan dengan Model Isolasi Lain?

Perbandingan ini berguna karena FTL tidak menjanjikan hal yang sama dengan container biasa maupun virtual machine. Tabel berikut merangkum perbedaan modelnya berdasarkan deskripsi resmi proyek di halaman ftl-os.org dan pengumuman rilisnya.

Aspek	Container Linux biasa	VM penuh	FTL
Unit isolasi	Proses di atas kernel bersama	Mesin virtual dengan kernel sendiri	Instance OS di userspace
Mekanisme	Namespace dan cgroup	Virtualisasi perangkat keras	Antarmuka mirip hypervisor berbasis user mode
Kompatibilitas biner	Biner Linux asli	Biner Linux asli	Biner Linux asli
Fleksibilitas OS	Terikat kernel host	Kernel sendiri per VM	OS sebagai pustaka yang bisa dimodifikasi
Kebutuhan mesin	Host Linux	Host dengan virtualisasi	Tanpa bare-metal
Target keamanan	Bergantung kernel bersama	Paling kuat	Mendekati VM tanpa bare-metal

Klaim yang perlu diuji sendiri adalah soal performa. Proyek ini menyebut tidak mau mengorbankan kinerja demi isolasi, tetapi angka benchmark publik untuk beban produksi belum banyak tersedia saat rilis ini keluar. Untuk keperluan evaluasi, ada baiknya mengukur sendiri beban yang paling dekat dengan kasusmu, misalnya layanan HTTP kecil atau proses kompilasi, sebelum menyimpulkan FTL cocok atau tidak.

Satu hal yang tidak muncul di tabel: kematangan ekosistem. FTL belum punya bertahun-tahun perkakas pendukung seperti Linux, jadi biaya awal memakainya lebih tinggi. Nilai rilis v0.1.0 justru terletak pada pembuktian bahwa model OS sebagai pustaka bisa berjalan dengan dukungan async modern dan lapisan kompatibilitas Linux yang makin lengkap.

Bagaimana Cara Mencoba FTL v0.1.0?

Cara tercepat adalah mengikuti README di repositori resmi. Di macOS, langkahnya memasang Rust dan QEMU, mengkloning repo, lalu menjalankan skrip yang sudah disediakan. Di Linux, paket yang dibutuhkan serupa meski nama paketnya bisa berbeda antar distro, dan instruksi lengkapnya ada di README proyek.

Perintah yang ditulis di pengumuman resmi untuk macOS adalah brew install rustup qemu, dilanjutkan git clone https://github.com/nuta/ftl.git, lalu masuk ke direktori hasil klon dan menjalankan ./run.sh. Setelah boot, kamu bisa mencoba menjalankan aplikasi Linux biasa di dalam instance userspace dan membandingkan perilakunya dengan container biasa.

Karena statusnya masih eksperimental, jangan pakai FTL untuk beban produksi tanpa pengujian panjang. Nilai rilis ini lebih pada arah desainnya: memisahkan kernel minimal dari logika OS yang bisa di-upgrade seperti aplikasi, sebuah gagasan yang menarik untuk platform yang menjalankan kode tak tepercaya dalam jumlah besar. Kalau kamu memelihara infrastruktur container dan peduli pada batas isolasi, FTL layak masuk daftar pantau, bukan daftar produksi.

FAQ

Apakah FTL bisa menjalankan biner Linux biasa?

Ya. Situs resmi FTL menyatakan proyeknya kompatibel dengan biner Linux, dan server HTTP yang menyajikan situs tersebut adalah aplikasi Linux berbasis Rust yang berjalan di atas FTL.

Apakah FTL butuh mesin bare-metal?

Tidak. Isolasi FTL berbasis user mode dan tidak memerlukan mesin fisik khusus. Untuk mencoba di laptop, kamu cukup memakai QEMU, termasuk mode microVM yang didukung sejak v0.1.0.

Apa arti dukungan Tokio multi-thread di rilis ini?

Artinya kode Rust async yang memakai runtime Tokio bisa berjalan dengan banyak thread di dalam FTL. Sebelumnya pola async standar ekosistem Rust belum didukung penuh sehingga aplikasi harus mengakalinya sendiri.

Apakah panggilan sistem blocking sudah bisa diinterupsi signal?

Belum. Pengumuman rilis menyebut panggilan sistem Linux yang blocking belum bisa diinterupsi oleh signal, jadi perilakunya masih berbeda dari Linux asli.

Kapan fitur filesystem untuk beban stateless tersedia?

Rilis November 2026 dijadwalkan membawanya, bersama pembuatan container Linux dinamis dan konsep sandbox yang lebih baik untuk kode tak tepercaya.

Sumber utama: pengumuman FTL v0.1.0, halaman resmi ftl-os.org, dan repositori nuta/ftl di GitHub.