Anda Mungkin Tidak Membutuhkan Yocto, dan Itu Tidak Masalah

• Yocto bukanlah sebuah distribusi, melainkan alat untuk merakit distribusi Linux Anda sendiri, sehingga sulit dijadikan pilihan default jika Anda tidak membutuhkan tingkat kontrol tersebut
• Distribusi buatan sendiri berarti pemeliharaan oleh sendiri, beserta tanggung jawab atas pembaruan keamanan sepanjang umur produk dan kepatuhan terhadap regulasi seperti CRA
• Mengadopsi Yocto berarti menghadapi build yang memakan waktu berjam-jam, direktori build lebih dari 100GiB, kurva belajar berminggu-minggu, serta lapisan BSP dengan kualitas yang tidak konsisten
• Jika yang dibutuhkan hanyalah fondasi Linux yang kokoh untuk menjalankan aplikasi, Debian dan alat image seperti mkosi, ELBE, dan debos sering kali sudah cukup dengan pekerjaan spesifik proyek yang jauh lebih sedikit
• Yocto unggul hanya saat diperlukan kustomisasi kuat, batasan ukuran atau waktu boot, pengecualian lisensi, atau dukungan Yocto vendor yang solid; jika ragu, distribusi yang sudah ada biasanya lebih baik

---

Sifat Sebenarnya Yocto dan Mengapa Sering Menjadi Pilihan Default

• Yocto bukan “distribusi Yocto Linux”, melainkan kumpulan alat untuk membuat distribusi Linux Anda sendiri
• Yocto Project juga menyediakan distribusi referensi Poky yang dibangun dengan bitbake, openembedded-core, dan meta-yocto
• Yocto memungkinkan Anda merakit sistem Linux yang dibutuhkan proyek embedded secara sangat rinci
  • Seluruh user space dapat dikompilasi untuk CPU target
  • Patch dapat diterapkan ke komponen mana pun
  • Fitur tiap recipe bisa diaktifkan atau dinonaktifkan
  • Semua versi bisa dipatok atau diubah
• Banyak vendor SoC dan mitra hardware menyediakan lapisan BSP (Board Support Package) siap pakai yang menjadi titik awal agar sistem berjalan di hardware nyata
• Karena kombinasi fleksibilitas dan dukungan vendor ini, Yocto sering menjadi pilihan default, tetapi jika Anda tidak membutuhkan tingkat kontrol sebesar itu, bebannya bisa lebih besar

Distribusi Buatan Sendiri Berarti Pemeliharaan oleh Sendiri

• Regulasi seperti Cyber Resilience Act (CRA) menuntut pemasok produk untuk menjaga keamanan perangkat lunak yang mereka distribusikan dan menyediakan pembaruan keamanan sepanjang masa pakai produk
• Rilis Yocto biasa umumnya hanya dipelihara sekitar 7 bulan sampai rilis berikutnya keluar
• Sejak Yocto 5.0 Scarthgap, menurut kebijakan saat ini rilis LTS menerima pembaruan hingga 4 tahun
• Rilis Yocto terdiri dari sekumpulan recipe bitbake dengan versi dan metadata tertentu, serta distribusi referensi Poky
• Selama masa pemeliharaan, maintainer Yocto menerapkan perbaikan bug dan keamanan ke komponen dan Poky, dan perbaikan komponen perangkat lunak biasanya di-backport dari versi upstream terbaru
• Dalam produk nyata, Yocto sering tidak digunakan apa adanya, melainkan mudah berubah seperti berikut
  • Menerapkan patch non-sepele atau perubahan lokal pada sebagian komponen
  • Menyertakan komponen tambahan yang tidak disediakan Yocto
  • Menaikkan versi atau mematok versi untuk menerima perbaikan atau mempertahankan kondisi yang diketahui baik
• Setiap kali rilis pemeliharaan Yocto keluar, Anda harus memeriksa apakah perubahan lokal masih bisa diterapkan dengan bersih di atas keadaan baru
• Untuk komponen yang Anda tambahkan atau patok versinya, maintainer Yocto tidak mengetahuinya, jadi Anda juga harus memastikan sendiri apakah komponen itu masih menerima perbaikan
• Jika Anda menggunakan Poky hampir tanpa perubahan, Anda perlu meninjau lagi mengapa Yocto dibutuhkan

Kernel Linux dan Ketergantungan pada Vendor

• Yocto menyediakan dan memelihara kernel Linux sebagai bagian dari tiap rilis, tetapi dalam produk nyata jarang dipakai tanpa modifikasi
• Biasanya setidaknya patch vendor perlu diterapkan, dan Anda harus memakai kernel yang cukup baru agar memuat driver dan perbaikan yang dibutuhkan
• Jika sampai mencakup pelacakan CVE, kernel saja sudah menjadi beban pemeliharaan besar, terlepas dari apakah Anda memakai Yocto atau tidak
• Untuk mengendalikan beban pemeliharaan, disarankan membangun di atas kernel LTS dari kernel.org dan menjaga semua perubahan dalam antrean patch yang rapi
• Untuk mengikuti perbaikan keamanan, pindah ke rilis stable baru lalu terapkan kembali antrean patch
• kernel.org memelihara kernel LTS selama beberapa tahun, jadi biasanya antrean patch bisa diterapkan dengan bersih dan pekerjaan nyata hanya muncul saat berpindah ke rilis LTS baru
• Bergantung pada kebutuhan konfigurasi dan keamanan, prinsip yang sama berlaku untuk bootloader, yang juga biasanya sangat spesifik vendor
• Menjaga kernel yang diberikan vendor apa adanya umumnya bukan pendekatan yang baik
  • kernel vendor sering tertinggal beberapa tahun dari kernel.org
  • Hampir tidak menerima pembaruan
  • Melewatkan sebagian besar perbaikan keamanan

Biaya Adopsi Yocto

• Memilih membuat distribusi sendiri menuntut waktu engineering yang nyata

• Waktu build

  • Yocto pada praktiknya mengompilasi hampir semuanya dari source
  • Build bersih untuk image yang lebih dari tingkat sederhana dapat memakan berjam-jam bahkan di workstation cepat
  • sstate-cache dan DL_DIR bersama memang mempercepat build berulang, tetapi perubahan kecil pada recipe pun bisa membatalkan sebagian besar cache

• Biaya disk dan CI

  • Direktori build Yocto mudah membesar menjadi lebih dari 100GiB
  • Runner CI membutuhkan storage yang memadai dan cara berbagi sstate antarpekerjaan
  • Mencerminkan sstate dan DL_DIR dapat mengurangi penderitaan, tetapi infrastruktur itu harus Anda operasikan sendiri

• Kurva belajar

  • Ada banyak hal yang harus dipelajari: recipe bitbake, layer, dynamic layer, class, override, file bbappend, PACKAGECONFIG, perbedaan antara DEPENDS dan RDEPENDS, dan lainnya
  • Engineer membutuhkan berminggu-minggu, bukan berhari-hari, untuk onboarding ke codebase Yocto

• Variasi kualitas lapisan BSP

  • Beberapa vendor SoC menyediakan lapisan BSP yang bersih dan terpelihara baik
  • Vendor lain bisa saja mematok kernel atau bootloader yang berumur 5 tahun, meng-hardcode recipe per-mesin ke layer yang salah, atau menyediakan layer meta-vendor yang rusak tiap kali Poky dinaikkan
  • BSP yang tampak seperti titik awal yang baik bisa menjadi bagian terburuk dari build
  • Faktor-faktor ini bukan alasan untuk selalu menghindari Yocto, melainkan alasan untuk memastikan terlebih dahulu apakah Anda benar-benar membutuhkannya

Alternatif: Menggunakan Kembali Distribusi yang Sudah Terbukti

• Jika Anda hanya membutuhkan fondasi Linux yang kokoh untuk menjalankan aplikasi, distribusi yang sudah ada seperti Debian GNU/Linux dapat menyelesaikan banyak bagian dari masalah yang sama dengan pekerjaan spesifik proyek yang jauh lebih sedikit
• Debian saat ini menyediakan sekitar 70.000 paket biner
• Arsitektur yang didukung mencakup amd64, i386, arm64, armhf, riscv64, ppc64el, dan lainnya
• Banyak SoC kemungkinan besar dapat langsung menjalankan biner Debian tanpa kompilasi ulang
• Debian bukan sekadar distribusi yang menyediakan user space modern dengan systemd, udev, dan dbus
• Arsipnya juga memuat komponen untuk membangun sistem Linux kecil berbasis init gaya SysV atau BusyBox
• Anda dapat memilih fondasi tipis dan hanya memasang paket yang dibutuhkan produk, sambil memanfaatkan pekerjaan maintainer paket Debian

Model Pemeliharaan Debian

• Debian stable menerima pembaruan keamanan dari Debian Security Team selama sekitar 3 tahun
• Setelah itu, proyek Debian LTS berbasis komunitas memperpanjang dukungan sekitar 2 tahun lagi pada arsitektur umum
• Dalam praktiknya, dukungan sekitar 5 tahun per rilis dimungkinkan, mirip dengan Yocto LTS, tetapi dengan pekerjaan spesifik proyek yang jauh lebih sedikit
• Untuk mendapatkan perbaikan terbaru, Anda cukup mengambil paket Debian terbaru lalu membangun ulang image
• Sifat pekerjaannya sangat berbeda dari Yocto, di mana Anda mungkin harus men-backport patch upstream sendiri atau memeriksa ulang apakah perubahan lokal tetap bisa diterapkan di atas rilis pemeliharaan

Cara Menyusun Image Embedded

• Image embedded berbasis Debian bukan berarti SoC melakukan boot dari USB flash drive lalu menjalankan installer Debian
• Pendekatannya adalah membuat image yang bisa di-flash di host build, lalu menuliskannya ke perangkat
• Komponen yang dibutuhkan adalah sebagai berikut
  • Bootloader yang biasanya spesifik SoC, misalnya u-boot
  • Kernel Linux yang biasanya spesifik SoC
  • Root filesystem berbasis user space Linux yang diambil langsung dari Debian
  • Alat perakitan image yang menggabungkan ketiga elemen itu menjadi image yang bisa di-flash
• Pilihan umum untuk alat perakitan image adalah mkosi, ELBE, dan debos
• Ketiga alat ini adalah perangkat lunak bebas dan menghasilkan image deterministik yang bisa di-flash ke hardware
• Pekerjaan pemeliharaan berkurang drastis, dan sebagian besar pembaruan berubah menjadi penyegaran paket di dalam image dengan cara apt, bukan menulis ulang recipe

Contoh Build Debian Berbasis debos

• debos membaca recipe YAML
• Recipe terdiri dari daftar action seperti menjalankan perintah, membuat root filesystem, dan memasang paket Debian dari sumber yang dikonfigurasi
• Alur dasarnya seperti berikut
  • Menjalankan mirror Debian lokal dengan aptly yang menyimpan salinan semua paket Debian yang diperlukan
  • Membangun kernel Linux dan, bila perlu, bootloader sebagai paket Debian lalu menambahkannya ke mirror
  • Membuat snapshot mirror dan memberi tag
  • Tag ini menjadi rilis
  • Menulis action recipe agar debos memakai mirror tersebut dan membuat image target
  • Jika perlu, menyimpan paket source Debian dan SBOM (Software Bill of Materials) dari image bersama image itu sendiri
• Menyimpan paket source dan SBOM membantu memenuhi kewajiban penyediaan source GPL dan persyaratan daftar material dari CRA
• Alat seperti debsbom menghasilkan SBOM langsung dari sistem Debian

Kapan Harus Memilih Yocto

• Yocto cocok ketika Anda membutuhkan distribusi yang sangat dikustomisasi
  • User space kustom
  • Flag kompilasi kustom
  • Perubahan mendalam pada komponen dasar
• Cocok ketika ada batasan ukuran atau waktu boot yang ketat dan tidak dapat dipenuhi oleh distribusi jadi
• Cocok ketika ada batasan lisensi yang mengharuskan pengecualian kategori lisensi tertentu
  • Di beberapa industri seperti perangkat medis, otomotif, dan sebagian pekerjaan pertahanan, komponen GPLv3 tidak didistribusikan
  • Mekanisme INCOMPATIBLE_LICENSE di Yocto memudahkan pengecualian keluarga lisensi tertentu dari seluruh image
  • Pada pendekatan Debian biasa, paket harus diaudit dan dipangkas secara manual
• Cocok ketika jalur dukungan resmi vendor SoC adalah Yocto dan kualitas BSP-nya solid

Kapan Harus Menghindari Yocto

• Jika Anda hanya memerlukan Linux modern untuk menempatkan dan menjalankan aplikasi, Anda mungkin tidak membutuhkan Yocto
• Jika anggaran storage dan memori dapat menanggung image berbasis Debian biasa, keuntungan Yocto berkurang
  • Patokan contohnya adalah flash ratusan MB dan RAM 256MB atau lebih
• Jika umur produk panjang dan lebih baik mengandalkan Debian Security Team daripada melakukan pemeliharaan sendiri, maka menghindari Yocto adalah pilihan yang tepat

Kapan Harus Menghindari Debian

• Jika Anda harus banyak memodifikasi atau membangun ulang paket Debian, Debian menjadi kurang menguntungkan
  • Membangun ulang beberapa paket masih dapat dikelola
  • Tiap paket yang dibangun ulang menjadi pekerjaan pemeliharaan yang harus Anda tanggung sendiri
  • Jika Anda menambal puluhan paket upstream, itu berarti Anda sedang membangun ulang pekerjaan yang sebelumnya dilakukan maintainer Debian
  • Pada skala ini, model recipe Yocto menanganinya dengan lebih rapi
• Jika Anda membutuhkan libc non-glibc seperti musl atau uClibc, Debian bukan pilihan yang tepat
  • Arsip utama Debian pada dasarnya menggunakan glibc
  • Menggantinya berarti Anda harus membangun ulang sebagian besar arsip sendiri
• Jika Anda membutuhkan perangkat lunak yang jauh lebih baru daripada yang disediakan Debian stable, Debian juga kurang cocok
  • backports membantu untuk sebagian paket
  • Jika produk membutuhkan compiler baru atau runtime baru, itu akan berbenturan dengan Debian stable
  • Debian testing bukan target produksi

Prinsip Pengambilan Keputusan dan Kesimpulan

• Keputusan soal memakai Yocto harus dibuat secara sadar dan sejak awal produk
• Pilihan ini adalah keputusan fondasi yang sulit dibalik setelah produk dideploy ke lapangan
• Jika ragu, lebih baik mulai dari distribusi yang sudah ada
• Biaya pindah ke Yocto nanti saat memang ada alasan nyata jauh lebih rendah daripada mendapati di tengah proyek bahwa Anda telah menanggung pekerjaan pemeliharaan bertahun-tahun tanpa manfaat substansial
• Yocto adalah hasil engineering yang hebat karena memungkinkan Anda membangun sistem Linux yang dibutuhkan secara presisi, tetapi justru kontrol presisi itulah yang menjadi masalah ketika tidak benar-benar dibutuhkan
• Logika yang sama hampir sepenuhnya berlaku untuk alat build berbasis source lain seperti Buildroot
• Begitu Anda mulai merakit distribusi sendiri, Anda juga langsung memiliki tanggung jawab pemeliharaannya
• Kesimpulan intinya jelas
  • “Distribusi buatan sendiri” pada praktiknya berarti pemeliharaan oleh sendiri
  • CRA dan regulasi serupa membuat biaya itu menjadi beban nyata
  • Build Yocto yang dimodifikasi besar-besaran tidak otomatis mewarisi perbaikan upstream secara gratis
  • Setiap rilis pemeliharaan menjadi pekerjaan peninjauan dan pengerjaan ulang
  • Distribusi yang sudah ada seperti Debian yang di-image-kan dengan mkosi, ELBE, atau debos menangani kasus umum dengan usaha spesifik proyek yang jauh lebih kecil
  • Saat Anda perlu mengendalikan sistem secara bedah, Yocto memang unggul
  • Selain itu, memilih Yocto berarti menyelesaikan masalah yang sebenarnya tidak ada dengan cara yang panjang dan mahal

[GN⁺]

Opini di Lobste.rs

• Jika jalur dukungan resmi dari vendor SoC adalah Yocto, maka meskipun BSP-nya tidak terlalu solid, itu umumnya masih lebih baik daripada port Ubuntu yang biasanya berkualitas rendah
  Port Ubuntu membuat pekerjaan seperti integrasi RAUC atau membuat root filesystem menjadi immutable terasa merepotkan. Saya benar-benar tidak suka Yocto dan dialek bash/python turunannya, tapi pada akhirnya tetap terikat ke situ

• Saya cukup sering melakukan konsultasi Yocto, tetapi hampir tidak pernah mengalami masalah yang dikeluhkan dalam tulisan itu. Biasanya justru sebaliknya, dalam situasi ketika Yocto adalah pilihan terbaik, pelanggan malah berusaha keras menghindarinya sehingga saya harus meyakinkan pihak manajemen
  Namun, masuk akal jika Yocto dibenci. Sulit, membingungkan, lambat, dan tooling-nya masih bisa dibuat lebih baik. Meski begitu, saya tidak yakin ada alternatif yang benar-benar nyata, dan saya juga penasaran apakah ada hal serupa di sisi BSD

  • Saya tidak tahu seberapa mirip dengan Yocto, tetapi cara umum untuk membuat image sistem embedded di FreeBSD adalah NanoBSD
    https://docs.freebsd.org/en/articles/nanobsd/
  • Saya belum pernah memakainya secara mendalam di dunia nyata, dan mungkin memang kurang matang dibanding Yocto, tetapi buildroot punya cukup banyak hal bagus
    Saya terutama pernah memakainya dalam konteks Nerves, yang pada dasarnya merupakan kombinasi buildroot + fwup + Erlang VM dan software pendukung. Cukup nyaman untuk mengembangkan serta memaketkan/mendistribusikan sistem embedded Linux
  • Saya sendiri tidak langsung menangani sistem embedded Linux/BSD, tetapi sebagai orang yang pernah memakai NetBSD, rasanya sistem build build.sh saja sudah cukup memadai
    Dengan itu kita bisa melakukan cross-compile kernel dan user space dengan mudah. Pada tahap akhir, kalau perlu menambahkan aplikasi pkgsrc atau memasukkan bootloader seperti u-boot ke image yang dihasilkan, mungkin akan butuh sedikit scripting. Mungkin ini bukan alur jadi yang langsung bisa dikustomisasi sesuai aplikasi, tetapi cukup baik sebagai fondasi
  • NetBSD memang disusun agar cocok untuk cross-compiling ke lingkungan yang terbatas, dan setelah terbiasa rasanya cukup nyaman

• Dari pengalaman saya yang terbatas setelah sedikit merasakan horornya dunia embedded, NixOS ternyata cukup cocok untuk kebutuhan seperti ini, dan alat build-nya jauh lebih baik daripada Yocto

  • Saya penasaran apakah itu juga berlaku di perangkat ARM. Saya kira ekosistem NixOS masih agak terlalu dini untuk perangkat seperti itu

• Kebetulan di perusahaan kami baru mulai merencanakan dan membuat kernel Linux serta distribusi kustom untuk perangkat berbasis Rockchip, jadi tulisan ini terasa tepat waktunya
  BSP-nya tampak akan butuh cukup banyak perawatan, dan sekadar “memakai” Debian terlihat jauh lebih mudah dikelola dibanding tugas bitbake yang saya tulis berantakan. Meski begitu, ekosistem Yocto sendiri cukup bagus, dan ada alat seperti kas atau isar yang mempermudah untuk mulai

  • Melihat README isar, sepertinya itu berbasis Debian, bukan Yocto. Saya penasaran apakah lazim mencampur keduanya
    Tulisan itu terdengar seperti memosisikan Yocto atau Debian, bukan pendekatan gabungan keduanya