Mengapa Debian Menjadi Seperti Sekarang?
(blog.liw.fi)- Praktik unik Debian lahir dari pilihan-pilihan yang terakumulasi agar sistem operasi serbaguna berskala besar berusia 30 tahun dapat mempertahankan kualitas, keamanan, dan prinsip perangkat lunak bebas dalam jangka panjang
- Debian tidak mengarah pada distro untuk penggunaan tertentu, melainkan distro serbaguna yang cocok bagi sebagian besar orang dan tujuan; apakah sebuah paket disertakan terutama ditentukan oleh kebebasan perangkat lunaknya dan kualitas pemeliharaannya
- Konstitusi, kontrak sosial, dan DFSG muncul setelah pengelolaan longgar pada masa awal menunjukkan keterbatasannya, dan kemudian melembagakan pengambilan keputusan yang demokratis serta kewenangan pemimpin yang terbatas
- Build yang self-contained dan penghindaran library yang dibundel adalah strategi pemeliharaan agar Debian tidak bergantung pada repositori eksternal atau dependensi duplikat, serta tetap bisa melakukan perbaikan keamanan darurat, rebuild, dan porting ke arsitektur baru
- Proses peninjauan anggota, nama kode rilis, dan laju perubahan yang lambat adalah cara proyek dengan ribuan paket dan puluhan juta basis instalasi mengelola kepercayaan, biaya mirroring, dan biaya membangun konsensus
Sistem operasi yang dituju Debian
- Debian mengarah pada sistem operasi yang berkualitas tinggi, aman, dan serbaguna, serta ingin terdiri hanya dari perangkat lunak bebas dan open source yang berjalan pada sebagian besar komputer yang umum digunakan
- Tujuan sebagai sistem operasi serbaguna berarti Debian harus cocok untuk sebagian besar orang dalam sebagian besar tujuan
- Memang tidak mungkin cocok untuk semua situasi, tetapi ini layak dijadikan arah yang dituju
- Ini menghasilkan keputusan yang berbeda dari distro yang berfokus pada tujuan tertentu seperti desktop, server, game, atau riset ilmiah
- Apakah sebuah perangkat lunak dipaketkan lebih banyak ditentukan oleh kriteria berikut daripada oleh kegunaannya
- Apakah perangkat lunak tersebut perangkat lunak bebas
- Apakah Debian dapat memeliharanya sebagai paket berkualitas tinggi
Konstitusi dan tata kelola
- Debian secara eksplisit dekat dengan organisasi open source yang demokratis
- Prosedur pengambilan keputusan didefinisikan dengan baik
- Setiap tahun memilih Debian Project Leader
- Wewenang pemimpin proyek dibatasi secara ketat, dan banyak kewenangan yang biasanya dikaitkan dengan kepemimpinan secara eksplisit didelegasikan kepada orang lain
- Debian Project Leader pada masa awal pada dasarnya lebih dekat ke diktator dengan kekuasaan penuh sampai mereka mengundurkan diri sendiri
- Setelah seorang pemimpin proyek melewati batas, ia mundur karena penolakan, dan sebagai hasilnya demokrasi diperkenalkan
- Debian mendefinisikan aturan proyek melalui konstitusi resminya
- Sistem aturan saat ini berasal dari pengalaman pada awal sejarah proyek bahwa lebih sedikit aturan dan lebih sedikit birokrasi tidak berjalan baik di Debian
Kontrak sosial dan Debian Free Software Guidelines
- Pada pertengahan 1990-an, istilah “open source” belum diperkenalkan, dan “free software” memang didefinisikan oleh Free Software Foundation, tetapi masih memberi banyak ruang untuk penafsiran
- Debian menginginkan aturan yang lebih jelas, sehingga membuat Debian Free Software Guidelines (DFSG) dan menjadikannya bagian dari kontrak sosial
- Kontrak sosial adalah dokumen dasar yang menjadi janji Debian tentang apa dirinya dan apa yang dilakukannya terhadap dirinya sendiri dan dunia
- DFSG adalah bagian darinya
- Konstitusi Debian sengaja membuat kontrak sosial sulit diubah
- Aturan yang lebih rinci membuat lebih jelas apa yang akan diterima Debian dan menyederhanakan diskusi terkait
- DFSG kemudian menjadi dasar bagi Open Source Definition
Prinsip build yang self-contained
- Debian berpegang pada prinsip self-contained
- Semua yang dipaketkan Debian harus dibangun hanya dengan menggunakan dependensi yang ada di dalam Debian
- Semua yang ada di dalam Debian harus dibangun langsung oleh Debian
- Prinsip ini bisa menimbulkan banyak pekerjaan tambahan
- Tool pemrograman modern sering mengasumsikan bahwa dependensi diunduh dari repositori online pada saat build
- Di Debian, cara seperti itu tidak diizinkan
- Alasan utamanya adalah dependensi eksternal bisa hilang di kemudian hari
- Debian tidak mengendalikan repositori paket pihak ketiga
- Jika sebuah paket atau seluruh repositori hilang, Debian bisa jadi tidak dapat membangun ulang paket tersebut
- Upgrade compiler baru, perbaikan masalah keamanan, porting ke arsitektur baru, dan penerapan perbaikan bug semuanya memerlukan rebuild
- Jika tidak self-contained, pada saat perbaikan keamanan darurat Debian harus memastikan puluhan ribu paket beserta semua dependensinya tersedia, sehingga Debian memilih memaketkan semua dependensi tersebut
Mengapa menghindari library yang dibundel
- Debian menghindari penggunaan salinan library atau salinan dependensi lain yang disertakan di dalam perangkat lunak yang dipaketkan
- Banyak proyek upstream merasa lebih mudah untuk membundel dependensi atau melakukan vendor
- Dari sudut pandang Debian, ini bisa menghasilkan banyak salinan dari library populer
- Jika library tersebut memiliki masalah keamanan atau masalah serius lain, semua salinannya harus ditemukan dan diperbaiki
- Dalam masalah keamanan darurat, pekerjaan ini membuang waktu yang sangat berharga
- Dalam kasus zlib, Debian menemukan puluhan salinan zlib yang dibundel di dalam arsip, dan mengerahkan upaya besar agar paket-paket Debian hanya menggunakan versi zlib yang dipaketkan di Debian
- Karena itu, Debian lebih memilih mengerjakan ini sejak tahap pemaketan sebelum keadaan darurat terjadi, agar paket di Debian menggunakan versi library yang dipaketkan oleh Debian
- Pengembang upstream kadang hanya ingin menangani versi bundel yang telah mereka uji, sehingga pendekatan ini sesekali menimbulkan gesekan dengan Debian
Proses peninjauan anggota
- Karena Debian besar, kompleks, dan banyak digunakan sebagai sistem operasi, proyek ini harus dapat memercayai para anggotanya
- Kepercayaan ini sangat penting terutama bagi orang yang mengunggah paket baru
- Karena keterbatasan teknis Linux pada 1990-an, semua paket Debian memiliki akses root penuh selama proses instalasi
- Semua pengembang Debian secara potensial dapat menjadi pengguna root di mesin mana pun yang menjalankan Debian
- Mengingat Debian berjalan di puluhan juta mesin, ini adalah kewenangan yang besar
- Anggota baru diverifikasi dengan berbagai cara
- Idealnya mereka sudah cukup lama berpartisipasi dalam komunitas pengembang Debian sehingga dikenal oleh orang lain
- Mereka harus membangun kepercayaan di dalam komunitas
- Proses ini bisa terasa cukup membuat frustrasi bagi orang yang ingin berkontribusi ke Debian, terutama mereka yang terbiasa dengan proyek open source yang lebih kecil
Nama kode rilis
- Debian memberi nama kode pada setiap rilis utama
- Praktik ini awalnya muncul untuk menurunkan biaya mirroring arsip paket Debian
- Saat menyiapkan rilis Debian 1.0 pada pertengahan 1990-an, direktori dibuat dengan nama versi, bukan nama kode
- Karena pengembangan rilis baru memerlukan waktu, direktori “1.0” dibuat lebih dulu
- Seorang penerbit CD-ROM memproduksi massal lebih awal disk berlabel “1.0” sebelum Debian 1.0 benar-benar selesai
- Akibatnya, orang yang menerima CD-ROM Debian 1.0 sebenarnya menerima sesuatu yang bukan 1.0
- Solusi sederhananya adalah menyiapkannya di direktori seperti “1.0-not-released” lalu mengganti namanya menjadi “1.0” setelah rilis selesai
- Namun, jika nama direktori berubah, semua mirror harus mengunduh ulang rilis tersebut, dan pada skala Debian saat itu biayanya besar
- Skala saat itu berada pada tingkat “ratusan paket” dan “puluhan MB”
- Setelah itu, struktur pool ditambahkan ke arsip Debian
- File dari semua rilis berada dalam pohon direktori yang sama, dan file metadata menentukan file mana yang termasuk dalam setiap rilis
- Struktur ini membuat mirroring lebih mudah
- Saat ini mungkin saja Debian meninggalkan nama kode dan hanya memakai versi, tetapi belum jelas apakah Debian akan tertarik melakukannya
Mengapa Debian berubah dengan lambat
- Debian adalah proyek yang sangat besar, dan proyek besar berubah dengan lambat
- Perubahan yang memengaruhi banyak paket bisa memerlukan pekerjaan dari ratusan sukarelawan, sehingga sulit berjalan cepat
- Beberapa pekerjaan bisa ditangani oleh sedikit orang, dan Debian memiliki prosedur untuk memungkinkan itu
- Contohnya, ketika versi baru GNU C compiler diunggah, pekerjaan mencari perbaikan yang dibutuhkan di paket lain biasanya dapat dilakukan oleh sedikit orang
- Salah satu alasan perubahan memakan waktu lama adalah karena perlu membangun konsensus
- Konsensus memerlukan diskusi yang luas
- Diskusi seperti ini memerlukan waktu, dan hanya jarang bisa dipersingkat
- Pengembang Debian cenderung konservatif dalam keputusan teknis
- Mereka sering lebih menyukai solusi yang tidak menuntut perubahan besar
1 komentar
Opini Hacker News
Self-contained dan tanpa library yang dibundel adalah konsep penting yang diabaikan oleh sebagian ekosistem karena dianggap terlalu merepotkan.
Baru setelah mengalami lagi masalah-masalah yang muncul akibatnya, istilah seperti “rantai pasok perangkat lunak” ditempelkan; Debian sejak awal sudah bekerja dengan cara yang menghindari masalah seperti ini, sehingga lebih sedikit mengalami penderitaan yang sama.
Jika ingin mendistribusikan perangkat lunak ke berbagai distro dan sistem operasi, membundel dependensi itu rasional; dari sudut pandang pemelihara distro, shared library yang cukup diberi patch keamanan satu kali jelas lebih baik.
Di level sistem operasi muncul arus seperti Nix dan Silverblue, sementara di level aplikasi ada Snaps dan Flatpak. Saya tidak tahu solusinya, tetapi sepertinya Debian juga perlu segera melakukan sesuatu.
Untuk memakai versi lain, harus diuji dengan hati-hati dan bug yang ditemukan harus diperbaiki; saya tidak tahu apakah Debian punya sumber daya untuk itu. Pada akhirnya ini berarti memakai kombinasi library yang belum tervalidasi sambil berharap semuanya berjalan baik, dan sepertinya tidak akan begitu.
Sejak lama, firmware terbuka yang diambil dari repositori linux-firmware tidak dibangun dari source, melainkan hanya didistribusikan sebagai binary; kemungkinan ada lebih banyak contoh serupa di dalam arsip.
Debian juga tidak secara sistematis menghapus dan meregenerasi file hasil generasi dari semua tarball, dan khususnya di bidang AI/ML, besar kemungkinan bahkan data pelatihannya tidak bisa diperoleh, sementara biaya pelatihan juga sulit ditanggung.
https://wiki.debian.org/EmbeddedCopies
Beberapa organisasi perangkat lunak open source bukan sekadar agak hebat, tetapi luar biasa sampai menunjukkan bahwa cara orang berkolaborasi bisa jauh lebih unggul daripada model perusahaan yang lazim.
Saya sudah sangat lama memakai Debian, tetapi tidak banyak tahu tentang organisasinya, dan tulisan ini menjadi pengantar yang bagus.
IETF juga organisasi yang nyaris menciptakan internet, tetapi tidak punya anggota dan berjalan begitu saja; mengejutkan bahwa organisasi seperti ini tidak banyak dikenal.
Protocol Wars, ketika dunia korporat berusaha mengambil alih cara kerja internet dan bersaing dengan IETF, juga menarik: https://en.wikipedia.org/wiki/Protocol_Wars
Ada masa ketika OSI setiap bulan mengumumkan proyek untuk mengganti sebagian internet seperti TCP dengan protokol X., tetapi yang bertahan dan berkembang kira-kira hanya X.509.
Saya penasaran apakah organisasi kolaboratif yang demokratis seperti ini benar-benar jauh lebih unggul daripada model perusahaan tradisional.
Dilihat dari skala ekonomi, pendapatan IETF atau Debian tidak sebanding dengan perusahaan, tetapi dari sudut pandang kontributor dan kreator, pertanyaannya menjadi “siapa yang diuntungkan?”, sementara para kontributor bertahan pas-pasan.
Model seperti IETF atau Debian tampaknya layak diuji apakah bisa bersaing dengan model perusahaan, dan dalam Protocol Wars, model itu pernah benar-benar berhasil.
Di working group IETF ada banyak engineer dari vendor perusahaan yang ingin berkolaborasi demi interoperabilitas, sedangkan ISO lebih dekat dengan organisasi tradisional yang top-down dan digerakkan pemerintah.
Saya memakai Ubuntu sekitar 13 tahun, lalu tahun ini pindah ke Debian, dan cukup menyukainya.
Dulu saya menganggap model packaging dengan pembaruan global bukan cara yang paling kokoh secara teknis, karena sulit mengetahui apa yang sedang terjadi dan kadang terjadi konflik versi.
Namun seiring waktu, saya jadi sangat menghargai stabilitas Debian dan niat baik proyeknya.
Kadang tujuan dan sasaran sebuah proyek lebih penting daripada keunggulan teknis.
Saya punya keluhan terhadap beberapa pilihan teknis, seperti cara daemon otomatis dijalankan setelah instalasi, tetapi manfaat konsistensi paket dan upgrade secara keseluruhan lebih besar.
Apt juga benar-benar package manager yang hebat.
Dalam kondisi default pun cepat, dan mendukung skenario yang cukup rumit seperti membiarkan sistem di stable tetapi memakai versi Nginx yang lebih baru dari backports.
Saya suka rasanya: hanya satu-dua paket yang saya pedulikan mendapat fitur baru, sementara sisanya tetap stabil dan membosankan.
Alasan utamanya adalah karena Debian memakai teknologi yang membosankan dan tua, tetapi bekerja dengan baik, dan saya tidak perlu melihat netplan, snapd, serta systemd-resolver lagi.
Kecuali mengambil dari Sid atau melakukan hal-hal menarik seperti upgrade libc6, kalau semuanya dipasang lewat apt, konflik versi biasanya seharusnya tidak muncul.
LIW melewatkan satu bagian besar: Debian adalah organisasi sukarelawan, jadi tidak ada yang bisa memaksa sukarelawan melakukan sesuatu yang tidak ingin mereka lakukan.
Orang-orang yang tidak dipaksa membentuk struktur demokrasi yang longgar dan berputar untuk mengambil keputusan, dan kemandirian yang lahir dari penggunaan sumber daya secara hati-hati tampak sebagai inti organisasinya.
Bagi saya, konflik itu mengubah secara permanen konsep “apa itu Debian”, dan apakah itu baik atau buruk bergantung pada siapa yang Anda dengarkan.
Dalam organisasi seperti ini pun, kalau tidak melakukan apa yang diminta orang lain, tentu saja Anda akan keluar lewat pintu.
Kadang saya membayangkan punya uang sangat banyak sampai sama sekali tidak perlu khawatir soal uang
Pada saat seperti itu, saya selalu merencanakan proyek open source mana yang akan saya donasikan, dan Debian selalu masuk beberapa kandidat teratas
Sekarang tinggal punya uang saja; tentu saja selama ini pun saya tetap berdonasi ke Debian
Itu jauh lebih menyenangkan
Debian bisa saja bagus, tetapi ada masalah dukungan driver, dan tampaknya hanya mengakuinya secara pasif
https://www.reddit.com/r/debian/comments/paxj85/why_debian_w...
“Kami mengakui bahwa sebagian pengguna membutuhkan program yang tidak sesuai dengan Debian Free Software Guidelines. Untuk perangkat lunak seperti ini, kami membuat area contrib dan non-free di arsip FTP.”
Satu atau dua tahun lalu saya menjalankan Debian di beberapa mesin, lalu ketika ada pembaruan WiFi, semuanya jadi tidak berfungsi. Setelah melihat-lihat opsi rollback dan sebagainya, saya akhirnya pindah saja ke Ubuntu, tepatnya Kubuntu, dan itu berjalan baik tanpa masalah
Debian 12 bahkan membuat repositori non-free-firmware khusus agar para puris perangkat lunak bebas bisa berkompromi setidaknya untuk driver non-free yang diperlukan agar perangkat keras bisa digunakan
Kalau sistemnya sudah terpasang, mengaktifkan repositori non-free lalu memasang linux-firmware, atau paket firmware-* yang lebih spesifik sesuai perangkat keras, seharusnya menyelesaikan masalah
Saya pernah bekerja bersama Ian Murdock di Purdue pada masa rilis pertama
Ia adalah administrator sistem sekaligus developer, sementara saya adalah desainer web perpustakaan
Ia sungguh percaya pada cara GNU/Linux dan perangkat lunak “free” dalam arti “kebebasan berbicara”
Dorongan awalnya berasal dari sulitnya packaging dan manajemen paket, dan mungkin itulah kontribusi terbesarnya
Ia juga antusias dengan gagasan mirip infrastruktur P2P bernama Network-of-Workstations, atau NOW, tetapi itu tidak benar-benar mengakar
Bruce Perens, yang kepadanya ia menyerahkan proyek, adalah pemimpin otoriter yang disebut dalam tulisan itu
Saya menyukainya; gaya manajemennya ala old guard seperti Linus Torvalds, dan gaya seperti itu efektif dalam proyek besar dan kompleks dengan banyak sukarelawan
Masa-masa Linux dan Debian dulu benar-benar menyenangkan, dan meski saya tidak terjun sedalam orang lain, saya merindukan masa itu
Sekarang terlalu banyak orang yang masuk dengan bau uang, yah memang begitulah
Manifesto Ian menjelaskan semuanya: https://www.debian.org/doc/manuals/project-history/manifesto...
Saya belum pernah mendengar ceritanya dan Google juga tidak membantu
Jejaknya setelah mundur hingga kematiannya terlihat cukup tidak stabil
Tulisan itu bahkan lebih tua daripada saya
Debian itu seperti Toyota
Andal tetapi membosankan, dan apalagi dibuat oleh para sukarelawan
Karena kebijakan Debian, kadang yang disediakan adalah versi RetroArch yang sangat dibatasi, bukan versi sebenarnya
RetroArch memiliki fitur manajemen paket sendiri bernama “Core Updater” yang mengunduh dan memasang emulator dalam bentuk file pustaka, tetapi Debian melarangnya karena dianggap melewati seluruh sistem manajer paket
Namun, setelah memasang dependensi dari paket sumber Debian lalu membangun kode sumber upstream, Anda bisa membangun sendiri RetroArch dengan fitur lengkap
Saya mempelajarinya dengan susah payah saat mencoba menjalankan Kodi dan RetroArch, tetapi selain itu Debian adalah sistem operasi yang bagus
Secara pribadi saya menyukai dan menggunakan Debian karena prinsip serta stabilitasnya
Saya pernah mendengar pengguna distro lain atau beberapa proyek upstream mengeluh bahwa Debian “memodifikasi” paket
Saya ingin tahu apakah itu benar, dan jika benar pasti ada alasan yang baik, jadi saya ingin mendengar penjelasannya
Pertama, patch yang membuat perangkat lunak berperilaku sesuai cara yang diinginkan Debian: konfigurasi disimpan di /etc/, tidak melakukan unduhan tambahan saat berjalan, dan memakai library sistem alih-alih library yang dibundel
Kedua, backport keamanan
Debian membekukan fitur saat rilis dan hanya menyediakan pembaruan keamanan, tetapi belakangan banyak perangkat lunak mengemas perbaikan keamanan bersama fitur baru dalam rilis baru
Jika dua jenis ini digabungkan, perbedaan antara 1.2 versi Debian dan 1.2 yang “asli” menjadi besar, dan penanganan laporan bug jadi sulit
Misalnya, proyek upstream menerima laporan bug untuk 1.2-Debian, tetapi hanya mendukung 1.4 yang “asli” bersama kumpulan library yang telah diperbarui
Ketiga adalah cara yang kini sudah banyak berkurang, yaitu ketika Debian menilai dapat memperbaiki perangkat lunak lalu mem-patch-nya
Hal ini pernah menimbulkan masalah seperti hilangnya keacakan pada kunci SSH: https://github.com/g0tmi1k/debian-ssh
Salah satunya adalah model versi bertahap seperti Chrome, yang nyaris tidak memiliki rilis perbaikan bug terpisah dan memasukkan perbaikan bug ke versi baru
Yang lain adalah model berpusat pada versi utama, seperti semantic versioning: ada versi 1 dan 2, lalu bahkan setelah versi 2 keluar, versi 1 masih mendapat 1.1 yang hanya berisi perbaikan bug
Debian pada dasarnya hanya bekerja dengan baik pada model kedua
Karena menjaga stabilitas API, Debian tidak cocok dengan perangkat lunak yang dikembangkan dengan model pertama
Untuk menyiasatinya, Debian mem-backport “perbaikan” dari versi 3 ke versi 1 dan membuat 1.debian-2 versinya sendiri
Masalahnya, kini proyek upstream menerima bug untuk perilaku yang belum pernah mereka rilis sama sekali
Debian bebas melakukan itu, tetapi proyek upstream juga bebas merasa keberatan atas beban kerja tambahan yang dibebankan Debian kepada mereka
Jika perlu, Debian mem-patch proyek upstream yang tidak sesuai dengan ekspektasi itu, dan kemampuan untuk melakukan hal tersebut adalah inti dari perangkat lunak bebas
Lihat https://www.debian.org/security/2008/dsa-1571