Pengenalan Sistem Linux yang Tidak Dapat Diubah

 (dataswamp.org)
3 poin oleh GN⁺ 2023-09-19 | 1 komentar | Bagikan ke WhatsApp
  • Distribusi Linux immutable menyiapkan upgrade bukan pada sistem yang sedang berjalan, melainkan untuk diterapkan saat boot berikutnya, sehingga menyediakan cara operasi yang bisa dikembalikan jika gagal
  • Berbeda dari nama “immutable”, banyak area sistem tetap bisa berubah, dan kesamaan nyatanya lebih dekat ke pembaruan transaksional dan rollback
  • NixOS·Guix berpusat pada konfigurasi deklaratif dan repositori hanya-baca, sedangkan keluarga OSTree·MicroOS·Vanilla OS masing-masing mendekati ini lewat /usr, snapshot btrfs, dan partisi root A/B
  • Kelebihannya adalah menjaga sistem tetap stabil saat perubahan paket berlangsung dan bisa membatalkan masalah, tetapi kebutuhan reboot·benturan dengan alat manajemen konfigurasi·sulitnya melacak perubahan masih tersisa
  • Hal yang benar-benar baru bukan snapshot itu sendiri, melainkan menerapkan perubahan pada lingkungan non-live lalu mengintegrasikannya dengan bootloader dan alat pengguna agar lebih mudah ditangani

Cakupan nyata dari nama “immutable”

  • Immutable pada awalnya berarti objek yang tidak berubah, tetapi saat diterapkan ke sistem operasi definisinya langsung menjadi kabur
  • Linux LIVE-CD tampak immutable karena selalu boot dengan program yang sama dan media disk-nya hanya-baca, tetapi saat berjalan tetap bisa membuat file dan direktori atau memasang paket
  • Saat ini, agar layak disebut distribusi Linux immutable, umumnya dibutuhkan tiga syarat
    • Upgrade sistem tidak dilakukan langsung pada sistem live
    • Perubahan paket diterapkan pada boot berikutnya
    • Dapat dilakukan rollback ke keadaan sebelumnya
  • Tiap implementasi punya fitur tambahan yang berbeda, tetapi tiga hal ini mendekati syarat minimum distribusi “immutable” saat ini

Perbedaan menurut implementasi

  • NixOS / Guix

    • NixOS dan Guix bergantung pada keluarga implementasi yang sama; Nix pertama kali muncul pada 2003, dan manajer paket Guix di-fork dari Nix pada awal 2010-an dengan tujuan menjadi 100% perangkat lunak bebas
    • Kedua sistem ini sangat berbeda dari sistem keluarga Unix tradisional, dan menjadikan immutability sebagai prinsip inti
    • Semua paket dan file hasil build disimpan sebagai entri unik di direktori khusus hanya-baca yang hanya dapat digunakan oleh manajer paket
    • Sistem operasi itu sendiri adalah keluaran dari manajer paket, dan pengguna menuliskan keadaan sistem yang diinginkan sebagai konfigurasi deklaratif
    • Konfigurasi mencakup pengguna, shell, paket yang dipasang, layanan yang berjalan beserta pengaturannya, partisi yang akan di-mount dan opsinya, dan lain-lain
    • Karena modul menyediakan nilai bawaan, saat membuat pengguna tidak perlu selalu menentukan sendiri UID, GID, shell, dan home directory
    • File seperti /etc/fstab atau /bin/sh juga hanya-baca, dan untuk mengubahnya harus melalui manajer paket
    • Peralihan konfigurasi mendekati perubahan symbolic link sehingga bisa langsung dilakukan, dan rollback dapat dilakukan dengan memilih konfigurasi sebelumnya saat boot
    • Selain direktori repositori khusus, /home, /etc, /var dan sebagainya tetap dapat diubah; symbolic link sistem bisa diganti dengan yang lain, tetapi sumber aslinya tidak bisa dimodifikasi
    • NixOS dinilai sebagai implementasi yang bagus, tetapi karena terlalu berbeda dari sistem yang ada, tingkat adopsinya tetap rendah meski punya banyak kelebihan

  • Endless OS

    • Endless OS adalah salah satu OS immutable awal yang dirilis untuk pengguna umum, dengan tujuan menjadi sistem yang tangguh bahkan di negara dengan cakupan internet atau listrik yang rendah
    • Berbasis Debian, tetapi menerapkan immutability dengan OSTree
    • OSTree mengelola image sistem inti dan menambahkan layer di atasnya seperti paket, serta dapat menyiapkan image sistem baru untuk boot berikutnya
    • Perubahan paket diterapkan ke versi sistem baru yang akan dipakai pada boot berikutnya, dan saat boot bisa dikembalikan ke versi sebelumnya
    • Partisinya umumnya dapat ditulis, tetapi /usr, yaitu area paket yang ditangani OSTree, di-mount sebagai hanya-baca
    • Tidak ada rollback untuk /etc
    • Program pengguna dipasang lewat Flatpak, sehingga tidak perlu reboot setiap kali memasang paket baru
    • Desktop GNOME yang dimodifikasi terlihat seperti menu ponsel pintar, dengan sasaran bentuk yang akrab bagi pengguna nonteknis
    • Memasang alat DevOps tidak praktis, tetapi bukan tidak mungkin

  • Fedora Silverblue

    • Fedora Silverblue berada dalam alur penerus Project Atomic yang berupaya membuat Fedora / CentOS / RHEL menjadi immutable
    • Menggunakan rpm-OSTree untuk menerapkan perubahan paket RPM di atas OSTree
    • Sistem terdiri dari satu image inti per rilis dan layer paket tambahan di atasnya
    • Layer paket yang terpasang bisa didaftar, dan saat paket dihapus seluruh stack dibuat ulang sehingga tidak ada sisa setelah penghapusan
    • Proses pembuatan ulang ini sangat lambat
    • Walau memasang paket, perubahan tidak diterapkan pada sistem yang sedang di-boot, sehingga pada dasarnya perlu reboot; saat boot, versi sistem sebelumnya bisa dipilih
    • rpm-OSTree menyediakan fitur untuk menggabungkan sementara perubahan boot berikutnya ke sistem live lewat overlay tmpfs
    • Kebijakan mount-nya hanya-baca kecuali /etc, /root, /var, dan home directory secara default berada di /var/home, yang bisa terasa tidak sesuai ekspektasi
    • /etc tidak dikelola rpm-OSTree sehingga tidak ikut di-rollback
    • /usr/local adalah symbolic link ke direktori di dalam /var, jadi cukup mudah menyuntikkan perubahan pengguna tanpa file RPM
    • Karena pemasangan paket lambat dan perlu reboot, penggunaan Flatpak atau toolbox dianjurkan
    • toolbox membuat kontainer Fedora tanpa hak root sehingga library atau alat pengembangan bisa digunakan dari terminal

  • OpenSUSE MicroOS / Aeon

    • OpenSUSE MicroOS adalah spin immutable dari OpenSUSE Tumbleweed yang rolling-release, dan memakai implementasi sendiri
    • Seluruh sistem, kecuali beberapa direktori seperti /home dan /var, berada di atas snapshot btrfs
    • Saat perlu mengubah sistem, snapshot saat ini digandakan menjadi snapshot baru, perubahan diterapkan di snapshot baru itu, lalu dipakai pada boot berikutnya
    • Berbeda dari sistem berbasis OSTree, /etc juga menjadi bagian snapshot sehingga bisa di-rollback
    • Di dalam snapshot baru, shell dapat digunakan untuk mengubah file apa pun di file system, berguna untuk pekerjaan seperti menyuntikkan file guna mengatasi masalah driver
    • Namun perubahan seperti ini tidak terlacak, sehingga sulit menjamin sistem tetap dalam keadaan “murni”
    • Perubahan dilakukan dengan perintah transactional-update; Anda bisa menambah atau menghapus paket, atau membuka shell di snapshot baru untuk melakukan perubahan yang diinginkan
    • /etc termasuk dalam snapshot tetapi selalu dapat dibaca, sehingga jika /etc diubah saat live lalu snapshot baru dibuat, perubahan itu langsung diwarisi
    • Pendekatan bawaannya adalah merencanakan reboot harian setelah update; karena rolling-release, ada update setiap hari dan manfaat paket baru belum didapat sebelum reboot
    • Reboot otomatis bisa dinonaktifkan
    • Seperti Silverblue, fitur untuk menerapkan perubahan ke sistem live saat ini masih eksperimental dan belum bisa digunakan
    • Sebagai gantinya, disarankan memakai distrobox untuk menggunakan kontainer tanpa hak root dari berbagai distribusi dan memasang alat pengguna di sana

  • Vanilla OS

    • Vanilla OS berbasis Ubuntu dan merupakan keluarga sistem immutable baru yang akan segera berpindah ke basis Debian
    • Immutability diimplementasikan dengan ABroot
    • ABroot memakai partisi root A, partisi root B, serta partisi untuk data persisten seperti /home atau /var
    • Alur boot dan perubahannya adalah sebagai berikut
      • Boot pertama dilakukan dari A dan A di-mount sebagai hanya-baca
      • Perubahan sistem seperti paket baru atau modifikasi file /etc diterapkan ke B, dan juga bisa diterapkan secara live lewat overlay tmpfs
      • Setelah reboot, sistem boot dari B, dan jika berhasil ABroot memindai perbedaan antara A dan B lalu menerapkan perubahan B ke A
      • Saat tidak ada perubahan baru, A dan B selalu identik
    • Kekurangannya adalah rollback hanya bisa dilakukan sampai sebelum boot ke versi baru
    • Setelah boot ke versi baru, perubahan juga diterapkan ke partisi boot sebelumnya sehingga rollback tidak lagi bisa dilakukan
    • Pendekatan ini terutama efektif untuk membatalkan upgrade yang gagal atau perubahan yang diuji secara live
    • Vanilla OS menyediakan manajer paket apx
    • apx adalah alat buatan penulis distrobox, yang memungkinkan pengguna non-root memasang paket dari berbagai distribusi seperti Arch Linux, Fedora, Ubuntu, Nix, dan lainnya, lalu mengintegrasikannya seperti instalasi lokal
    • Vanilla OS, ABroot, dan apx masih muda dan masih terasa kasar di beberapa bagian

  • Alpine Linux with LBU

    • Alpine Linux dapat membuat konfigurasi yang mendekati immutable dengan perintah lbu
    • Menggunakan installer Alpine sebagai sistem boot dasar, lalu membuat tarball “konfigurasi tersimpan” yang diterapkan otomatis saat boot
    • Setiap kali boot, direktori diekstrak ulang dan paket dipasang ulang, sementara semuanya sepenuhnya dapat ditulis di memori live
    • Sistem selalu mulai dari keadaan bersih lalu menerapkan perubahan di atasnya, dan perubahan bisa di-rollback untuk memulai ulang dari awal
    • Definisi immutable yang diberikan sebelumnya tidak sepenuhnya dipenuhi, karena perubahan diterapkan di atas sistem dasar
    • Karena seluruh sistem berada di memori dan Anda harus mengelola sendiri apa yang disimpan dan dipulihkan, dibutuhkan pemahaman yang tinggi, dan arsipnya bisa membesar
    • Dokumentasinya juga kurang

Kelebihan dan batasan operasional

  • Kelebihan

    • Jika terjadi masalah, perubahan bisa di-rollback
    • Pembaruan transaksional membantu sistem tetap berjalan dengan benar bahkan saat perubahan paket sedang berlangsung

  • Kekurangan

    • Integrasi dengan alat manajemen konfigurasi seperti Ansible, Salt, dan Puppet sangat buruk
    • Bahkan jika alat itu diperbarui agar memahami cara penerapan perubahan paket, kebanyakan tetap akan menabrak batasan jika mencoba mengelolanya seperti sistem biasa
    • Kewajiban reboot setelah perubahan memang merepotkan, meski NixOS dan Guix tidak perlu reboot untuk setiap perubahan
    • Sistem berbasis OSTree tidak fleksibel
      • Misalnya pada netbook yang membutuhkan file tambahan di direktori ALSA untuk audio, file itu tidak bisa ditambahkan kecuali membuat paket yang mendistribusikannya
    • Rollback cenderung berupa blind rollback, sehingga sulit mengetahui perubahan apa yang ada pada tiap versi sistem
    • Program seperti Nix/Guix yang membutuhkan direktori di root file system, atau instalasi seluruh sistem untuk perangkat lunak yang tidak dipaketkan, bisa menjadi sulit

Fakta dan kesalahpahaman tentang sistem immutable

  • Immutability, secara ketat, hampir bisa disebut tidak benar, karena banyak bagian sistem tetap dapat diubah
  • Immutable bukan berarti stateless
  • NixOS dan Guix dinilai sebagai implementasi yang sejak awal memiliki filosofi yang benar, karena melacak seluruh sistem dengan manajer paket yang stabil dan sumbernya bisa memakai sistem kontrol versi
  • Immutability sering dikaitkan dengan manfaat keamanan, tetapi penyerang yang mendapatkan hak root tetap bisa memanipulasi sistem live dan bahkan menyentuh partisi /boot
  • Tidak ada yang mencegah pemasangan backdoor untuk dipakai pada boot berikutnya
  • Immutability menuntut disiplin dan pemeliharaan
    • Perlu memberi perhatian pada kontrol versi
    • Program tambahan seperti apx, distrobox, dan devbox harus diperbarui terpisah dari sistem
    • NixOS dan Guix mengintegrasikan bagian ini

Bagian yang benar-benar baru

  • Sistem operasi immutable sedang mendapat perhatian di komunitas sistem open source, tetapi di bawah istilah yang sama bercampur berbagai implementasi dan kasus penggunaan
  • Nama “immutable” membentuk ekspektasi tertentu bagi pengguna, tetapi kenyataannya lebih dekat ke pembaruan transaksional untuk sistem operasi
  • Pembaruan transaksional sendiri bukan konsep baru
    • Solaris dan ZFS sudah bisa memilih snapshot sistem saat boot
    • FreeBSD tampaknya juga mengimplementasikan fitur serupa sekitar 10 tahun lalu
    • Distribusi Linux biasa pun bisa memilih snapshot saat boot jika memakai snapshot btrfs
  • Hal yang benar-benar baru adalah menerapkan perubahan transaksional ke lingkungan non-live, mengintegrasikannya ke bootloader, dan menyediakan alat yang mudah dipakai pengguna
  • Untuk bacaan lanjut, direkomendasikan tulisan Colin Walters, “Immutable” → reprovisionable, anti-hysteresis

Bacaan terkait

1 komentar

 
GN⁺ 2023-09-19
Komentar Hacker News

  • Senang melihat Silverblue masuk dalam daftar, tetapi sayang Fedora CoreOS tidak ada
    FCOS adalah OS yang bagus untuk dipakai di produksi, sudah banyak berkembang sejak akuisisi CoreOS, dan tampak seperti titik tengah yang baik: lebih mudah dipelajari dan digunakan dibanding Nix, sambil tetap mempertahankan sifat immutable
    CoreOS Layering yang ditambahkan tim pengembang FCOS adalah fitur kuat: jika Anda mendefinisikan status sistem dengan Dockerfile, FCOS akan melakukan rebase ke status tersebut, dan konfigurasi server cukup dilakukan dengan reboot
    Kalau proyek berikutnya membutuhkan VM, layak dicoba. Saya juga membuat Bupy, alat CLI berbasis Python yang memudahkan pembuatan file Butane secara lokal di workstation Linux, dan ada juga contoh menjalankan Paperless NGX dengan CoreOS Layering
    https://github.com/quickvm/bupy
    https://github.com/quickvm/fcos-layer-paperless-ngx
    https://coreos.github.io/rpm-ostree/container/
    https://github.com/coreos/enhancements/blob/main/os/coreos-l...
    https://github.com/coreos/layering-examples

    • Saya juga penasaran dengan pendapat tentang Flatcar, proyek lain dalam keluarga CoreOS
      Bagian tersulit bagi saya adalah bagaimana memakai proyek seperti ini di lingkungan bare metal. Membuat image VM memang keren, tetapi dalam praktiknya sering kali saya ingin memasangnya ke drive yang sudah ada, atau memasang dengan ZFS pool di bawahnya
    • CoreOS Layering terlihat sangat berguna. Saat ini saya memakai openSUSE MicroOS di beberapa Raspberry Pi dan server x86_64, dan salah satu alasan memilih MicroOS adalah instalasi Raspberry Pi-nya cukup sederhana
      Saya penasaran seberapa sulit memasang CoreOS di Raspberry Pi. Beberapa panduan instalasi di internet terlihat cukup rumit

  • Sumbu lain yang selalu terlewat dalam pengenalan sistem immutable seperti ini adalah pendekatan berbasis image
    Di https://universal-blue.org/ saya bekerja bersama orang-orang yang jauh lebih ahli daripada saya untuk membangun image container OCI di atas Fedora Silverblue dasar dan berbagai edisi desktop
    Image ini bisa di-boot dengan rpm-ostree, atau lebih tepatnya di-rebase, dan merupakan cara memperluas sistem yang lebih kokoh daripada layering; perubahan yang sama juga bisa dengan mudah diwarisi atau dimanfaatkan siapa pun. Membuat image sendiri pun sangat mudah
    VanillaOS dan SUSE sepertinya melakukan hal serupa, tetapi kami bukan proyek OS, hanya downstream dari Fedora. Dukungan resmi Fedora juga sedang berjalan, dan bahkan dengan cakupan yang sudah berfungsi sekarang, berdasarkan pengalaman ini adalah salah satu cara paling kokoh dan mudah untuk pekerjaan seperti menyediakan driver Nvidia

    • Sedikit berbeda, tetapi sekitar 2009 saya terkejut melihat hypervisor besar yang menjalankan host Windows Remote Desktop. Mungkin itu Citrix
      VM melakukan boot dari image, dan image serta disk delta semuanya berada di RAM. Profil pengguna berada di hard disk, tetapi host desktop untuk 25 orang bisa boot hingga siap menerima login jarak jauh dalam sekitar 4 detik
      Itu adalah sistem Windows yang paling tidak menyakitkan untuk dipatch
    • Saya agak bingung karena mengira Fedora Silverblue juga berbasis image
      Saya pikir instalasi dasarnya tidak memakai layering, dan layering baru dipakai ketika ingin memasang paket RPM tambahan
    • Sepertinya UBlue membangun ulang image secara berkala dengan GitHub Actions untuk memasukkan pembaruan paket. Saya penasaran siapa yang menanggung biayanya
      Saya juga penasaran apakah image disediakan dari GitHub, apakah GitHub mengenakan biaya untuk transfer keluar, dan apa yang terjadi jika banyak pengguna mencoba mengunduh image yang sama

  • Saya lebih tertarik pada sistem yang sudah diprakonfigurasi daripada sistem immutable
    Di sini NixOS dan Home Manager menonjol, tetapi cara konfigurasinya benar-benar buruk. Saya ingin seluruh konfigurasi dimasukkan ke source control dan tahu bahwa status sistem saat ini sama dengan konfigurasi itu, sementara perubahan lainnya dihapus saat reboot. Akan lebih baik jika perubahan sebelum reboot ditandai dengan jelas
    Dari pengalaman terbatas memakai sesuatu seperti Silverblue, sistem dasarnya bisa dikonfigurasi, tetapi begitu mulai menambahkan aplikasi seperti Firefox, akhirnya memakai Flatpak, dan saya belum tahu cara mendeklarasikan seluruh instalasi Flatpak yang diinginkan beserta konfigurasinya
    Mungkin ada cara untuk memasang Flatpak secara massal lalu menangani sisanya dengan dotfile
    https://universal-blue.org/tinker/mindset/#resist-the-urge-t...

  • Masalah yang saya alami dengan Flatpak dan pendekatan immutable secara umum adalah bahwa kita tidak bisa memodifikasinya dengan cara yang tidak didukung pengembang
    Misalnya, saya menyinkronkan kalender dengan decsync, dan setahu saya mustahil menambahkan plugin decsync ke Evolution Flatpak
    Sampai sistem immutable seperti ini mendukung penumpukan filesystem overlay kustom sebagai fitur kelas satu untuk kasus penggunaan yang tidak bisa atau tidak mau didukung pengembang, orang-orang akan terus memakai sistem mutable

    • NixOS justru menyediakan kendali semacam ini dengan berbagai cara
      Sebagian paket di nixpkgs serta sebagian besar modul NixOS dan Home Manager mengekspos banyak opsi untuk mengatur plugin, paket tambahan, dan sebagainya
      Nix juga menyediakan overlay dan override untuk menambahkan paket kustom atau varian dari paket yang sudah ada, dan bahkan bisa mengganti sebagian paket. Jika itu masih kurang, kita juga bisa langsung memasukkan patch ke kode atau membangun dari fork repositori upstream
      Dalam praktiknya, ini salah satu bagian yang paling saya sukai dari Nix. Mudah mengatakan “saat membangun paket ini, ganti dependensi ini dengan versi saya”, sehingga saya jadi lebih sering berkontribusi ke open source
    • Hal seperti “menambahkan plugin decsync ke Evolution Flatpak” sangat umum di software GUI Linux
      Di luar ranah ini, sebagian besar software hadir dengan menyertakan fitur yang dibutuhkan. Misalnya, Solidworks tidak pernah meminta saya mengunduh dependensi opsional, tetapi FreeCAD secara harfiah meminta sesuatu setiap 15 menit setiap kali berpindah ke tahap berikutnya dalam alur CAD/CAM/simulasi/rendering
      https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv... juga layak dibaca
      Intinya adalah “20% yang dipakai semua orang” itu tidak pernah sama. Selama 10 tahun terakhir saya mendengar puluhan perusahaan mencoba merilis pengolah kata “ringan” yang hanya mengimplementasikan 20% fitur, lalu seorang jurnalis menulis ulasan dan mencari fitur hitung jumlah kata, ternyata fitur itu masuk ke “80% yang tidak dipakai siapa pun”, sehingga akhirnya menulis “program ringan itu bagus dan bloat itu buruk, tapi benda sialan ini tidak bisa menghitung jumlah kata jadi tidak bisa dipakai”; kisah seperti ini sudah setua PC
    • Kalau sampai perlu menumpuk filesystem overlay kustom sebagai fitur kelas satu, rasanya lebih baik pakai sistem mutable saja
      Ini mengingatkan saya pada 10 tahun lalu ketika semua orang berlari ke NoSQL lalu segera menciptakan ulang skema di dalam masing-masing proyek
    • Aplikasi Flatpak juga bisa ditambahi plugin, dan plugin semacam ini bisa dibuat sebagai paket ekstensi
      OBS adalah contohnya. Di Flathub ada beberapa plugin OBS dengan bentuk com.obsproject.Studio.Plugin.*

  • Saya kira definisinya sebaiknya seperti ini: setelah memasang paket sebanyak apa pun, lalu menghapusnya dalam urutan apa pun pada suatu waktu di masa depan, sistem harus kembali ke keadaan yang setara dengan seolah-olah paket itu tidak pernah dipasang sejak awal
    Definisi ini mungkin mengecualikan beberapa distro, tetapi menurut saya bagian penting dari konsep ini justru sifat tersebut

    • Untuk sistem yang ditujukan bagi pengguna, poin utamanya tampaknya sifat itu pada dasarnya mustahil
      Saat menghapus pengolah kata atau editor teks, apakah Anda ingin semua file yang Anda tulis juga ikut hilang? Jika menghapus browser, apakah semua file yang diunduh juga harus hilang? Jika tidak, tidak ada cara yang andal untuk membedakan file mana yang dibuat otomatis oleh program dan file mana yang dibuat pengguna dengan program tersebut
      Hal-hal yang dibuat selama instalasi bisa dihapus dengan mudah, tetapi semua perubahan setelahnya tidak bisa
      Kita juga bisa membayangkan situasi ketika implementasi DNS diganti, lalu kemudian server DNS default diubah. Saat provider dihapus dan kembali ke implementasi sebelumnya, perlu dipilih apakah server lama juga dipulihkan atau konfigurasi server baru dipertahankan. Secara pribadi, saya ingin hanya providernya yang diganti dan server baru tetap dipertahankan
      Direktori yang dibagi oleh beberapa mesin juga membuat ini sulit. Jika /home/${USER} ditempatkan sebagai mount NFS atau Samba dan file yang sama dipakai di beberapa workstation, ketika suatu program membuat file di direktori konfigurasi XDG lalu program itu dihapus di satu workstation, apakah file di semua mesin juga harus dihapus? Package manager pada satu sistem tidak punya cara untuk mengetahui apakah semua perangkat harus identik, atau cukup home directory saja yang identik
    • Persoalannya adalah seberapa dalam Anda ingin menerapkan sifat itu
      Struktur data berrepresentasi unik dan struktur data independen-riwayat layak dilihat
      Block device, misalnya SSD, harus diberi perhatian khusus agar mengalokasikan blok tanpa bergantung pada riwayat
    • Itu adalah sifat yang disebut reproducibility, yang berarti konfigurasi yang sama selalu menghasilkan keadaan sistem yang sama
    • Saya suka definisi itu
      Bisa juga dikatakan bahwa himpunan paket membentuk lattice, dan apa pun jalur yang ditempuh untuk mencapai subset paket tertentu, statusnya hanya satu

  • Saya sudah memakai Fedora Silverblue sejak dirilis, dan ini jelas masa depan
    Menurut saya semua orang seharusnya memakai ostree

    • Saya merasa Silverblue kurang fleksibel untuk komputer pribadi
      Mungkin saya saja yang agak spontan dalam memakai Linux, tetapi tidak punya izin tulis ke folder seperti /usr atau /bin membuat saya kesal kira-kira dua minggu sekali
      Misalnya, ada skrip yang ditulis pengguna Ubuntu yang mencari library dengan nama dan lokasi ala Ubuntu, sementara Fedora memakai nama lain untuk library itu. Dalam situasi seperti ini, insting saya adalah membuat symbolic link dengan nama Ubuntu yang menunjuk ke library yang dikelola RPM Fedora
      Namun kenyataannya, agar bisa berjalan saya harus mem-fork skripnya, membuatnya bisa di-build secara lokal, memperbaikinya agar mencari kedua nama library, menjalankan pengujian lokal, mengirim PR ke upstream, dan seterusnya. Hal yang biasanya selesai dengan satu baris shell berubah menjadi pekerjaan 90 menit
    • Sudah setahun saya memakainya dan benar-benar bagus. Saya penasaran apakah Red Hat sadar apa yang mereka miliki. Bukan hanya Silverblue, tetapi Fedora itu sendiri juga
      Saya pernah membaca jawaban Quora yang memperkirakan anggaran pengembangan Windows OS berdasarkan gaji sekitar 18 miliar dolar. Bayangkan jika Red Hat menginvestasikan 2 miliar dolar ke Fedora dan menjadikannya Firefox-nya dunia OS desktop; mengambil pangsa 10% saja dari Microsoft sudah sangat besar
      Mereka bisa sampai sejauh ini dengan sumber daya sesedikit ini di atas ribuan paket open source. Uang itu bisa dipakai untuk terus menghidupi proyek-proyek seperti ini dan mensponsori pengembangannya. Karyawan Red Hat sudah terlibat dalam banyak proyek tersebut
    • Saya suka ide ostree, tetapi dari penelusuran sekilas, ia tidak terlihat seramah Docker untuk pengguna umum atau menengah. Docker bisa dipelajari pengguna pribadi dalam satu sore
      Tidak jelas bagaimana cara mencapai titik “mendistribusikan distro Debian sebagai snapshot ostree”
      Saya penasaran apakah ini memang dirancang hanya untuk admin sistem profesional atau pembuat sistem
    • Kalau pernah memakai Nix, saya penasaran bagaimana perbandingannya
      Saya belum pernah memakai Silverblue, tetapi Nix juga terasa seperti masa depan
    • Saat ini saya memakai Ubuntu di server dan melihat ada ostree di repositori, tetapi belum sempat mencobanya
      Kalau memungkinkan, saya ingin mulai melakukan versioning pada sistem yang ada apa adanya. Kalau itu terlalu sulit atau mustahil, suatu hari saya berencana memindahkan server ke Silverblue. Saya benar-benar suka ide ostree

  • Musim panas ini saya terpikat pada Tinycore
    Ini cocok melengkapi filosofi keamanan “satu OS untuk satu fungsi” yang mendasari Qubes, Tails, dan Whonix yang beberapa hari lalu dibahas di sini
    Karena sangat ringan, VM untuk server email, VM untuk database, dan VM untuk firewall/router masing-masing bisa dinyalakan hanya dalam beberapa detik
    Tinycore sendiri immutable, jadi cukup masukkan “paket” dan konfigurasi ke vdisk lalu tandai sebagai read-only. Satu skrip Virsh menangani start dan stop “layanan”, dan tiap layanan adalah instance Tinycore
    Menarik dan sejauh ini kokoh, tetapi saya belum yakin akan memasukkannya ke production milik orang lain

    • TinyCore selalu luput dalam pengantar Linux immutable seperti ini. Ia sudah ada sejak lama dan desainnya juga bagus
      Implementasinya punya beberapa kekurangan, dan mungkin tidak ada sponsor perusahaan yang bisa menjelaskan mengapa orang-orang kurang mengenalnya
      Berbeda dari distro Linux immutable lain, ia kokoh dan sederhana

  • Saya terus memakainya sejak Fedora Sericea keluar. Pada dasarnya ini Fedora Silverblue, tetapi memakai Sway-wm alih-alih Gnome-wm
    Secara praktik cukup layak dipakai, dan tidak perlu reboot setiap kali menjalankan perintah rpm-ostree install. rpm-ostree live-apply menanganinya dengan overlay berbasis systemd

    • Selama dua minggu terakhir saya memakai Fedora Workstation, dan sebagai orang yang kembali memakai Linux setelah 20 tahun, saya bisa bilang pengalamannya meningkat luar biasa
      Saya belum perlu boot kembali ke Windows. Kalau kondisi ini bertahan selama 6 bulan ke depan, saya akan pindah sepenuhnya ke Linux dan menghapus partisi Windows
    • Tapi bukankah untuk benar-benar menerapkan kernel baru tetap perlu reboot? Atau saya penasaran apakah kernelnya diganti lewat sesuatu seperti kexec

  • Menanggapi pernyataan “immutability itu bohong dan banyak bagian sistem tetap mutable. Hanya saja saya tidak tahu harus menyebut keluarga ini dengan istilah apa, sesuatu yang transaksional?”, dalam kasus Nix kedengarannya lebih berfokus pada reproducibility
    Maksudnya, jika file konfigurasi Nix diletakkan di komputer lain, seharusnya kita mendapatkan sistem yang sama, kecuali mungkin /home
    Yang lain tampak lebih mirip menyediakan fungsi snapshot dan rollback yang sudah diberikan alat lama, tetapi dengan implementasi berbeda

    • Istilah “immutable” terasa aneh untuk ditempelkan di sini
      Jika maksudnya tidak melakukan upgrade sistem pada live system, perubahan paket diterapkan pada boot berikutnya, dan perubahan bisa di-rollback, itu lebih mirip transaksi atomik seperti database. Hanya saja harus mematikan sistem untuk melakukan commit terasa agak berlebihan
      Microsoft beberapa tahun lalu memasukkan transaksi atomik ke filesystem, tetapi transaksi filesystem tidak banyak dipakai
      Akan bagus jika sistem instalasi bisa meng-commit semua perubahan sekaligus, dan jika ada masalah selama instalasi, ia bisa rollback ke kondisi sebelumnya tanpa meng-commit apa pun. Secara teori ini mungkin dengan filesystem transaksional, tetapi dalam praktiknya mungkin terlalu banyak state lain di luar filesystem yang ikut terlibat

  • Di sisi server ada Bottlerocket OS dari Amazon
    Idenya adalah memakai partisi A/B untuk upgrade, dan semua yang bukan sistem dasar dijalankan sebagai container
    Untuk konfigurasi kustom saat boot dipakai boot container, sementara untuk layanan jangka panjang memakai host-container, atau di Kubernetes memakai DaemonSet
    https://github.com/bottlerocket-os/bottlerocket