Muhtemelen Yocto’ya ihtiyacınız yok ve bu sorun değil

• Yocto, bir dağıtım değil; kendi Linux dağıtımınızı bir araya getirmenize yarayan bir araçtır ve bu düzeyde denetime ihtiyacınız yoksa varsayılan tercih yapmak zordur
• Kendi dağıtımınız, bakımını da kendiniz üstlenmeniz anlamına gelir; buna CRA gibi düzenlemeler ve ürün ömrü boyunca güvenlik güncellemesi sağlama sorumluluğu da dahildir
• Yocto kullanmaya başlamak; saatler süren derlemeler, 100GiB’ı aşan build dizinleri, haftalar süren öğrenme eğrisi ve kalitesi çok değişken BSP katmanları anlamına gelir
• Uygulama çalıştırmak için sağlam bir Linux temeli gerekiyorsa, Debian ve mkosi·ELBE·debos gibi imaj araçları çok daha az projeye özgü çalışmayla yeterli olabilir
• Yocto ancak güçlü özelleştirme, boyut/önyükleme süresi kısıtları, lisans hariç tutma ihtiyacı ve sağlam satıcı Yocto desteği olduğunda öne çıkar; emin değilseniz mevcut bir dağıtım daha iyi bir seçimdir

---

Yocto’nun gerçekte ne olduğu ve neden varsayılan tercih haline geldiği

• Yocto, bir “Yocto Linux dağıtımı” değil; kendi Linux dağıtımınızı oluşturmak için araçlar bütünüdür
• Yocto Project, bitbake, openembedded-core ve meta-yocto ile oluşturulmuş referans dağıtım Poky’yi de sunar
• Yocto, gömülü projelerin ihtiyaç duyduğu Linux sistemini ayrıntılı biçimde bir araya getirmeyi sağlar
  • Tüm kullanıcı alanı hedef CPU için derlenebilir
  • Herhangi bir bileşene patch uygulanabilir
  • Her tarifin özellikleri açılıp kapatılabilir
  • Tüm sürümler sabitlenebilir veya değiştirilebilir
• Pek çok SoC satıcısı ve donanım iş ortağı, gerçek donanımda çalışan bir başlangıç noktası sağlamak için kullanıma hazır BSP(Board Support Package) katmanları sunar
• Esneklik ile satıcı desteğinin birleşimi Yocto’yu varsayılan tercih yapar; ancak bu kadar denetime ihtiyacınız yoksa yükü daha ağır olabilir

Kendi dağıtımınız, bakımını da kendiniz üstlenmeniz demektir

• Cyber Resilience Act(CRA) gibi düzenlemeler, ürün tedarikçisinin dağıttığı yazılımı güvenli tutmasını ve ürün ömrü boyunca güvenlik güncellemeleri sağlamasını zorunlu kılar
• Tipik bir Yocto sürümü, bir sonraki sürüm çıkana kadar yaklaşık 7 ay boyunca bakım alır
• Yocto 5.0 Scarthgap itibarıyla, mevcut politika gereği LTS sürümleri en fazla 4 yıl güncelleme alır
• Bir Yocto sürümü; belirli sürümler ve metadata içeren bitbake tarifleri kümesinden ve referans dağıtım Poky’den oluşur
• Bakım süresi boyunca Yocto bakımcıları, bileşenlere ve Poky’ye hata ile güvenlik düzeltmeleri uygular; yazılım bileşenlerindeki düzeltmeler genellikle en güncel upstream sürümden backport edilir
• Gerçek bir üründe, Yocto’nun olduğu gibi kullanılması yerine şu tür değişiklikler sık görülür
  • Bazı bileşenlere basit olmayan patch’ler veya yerel değişiklikler uygulamak
  • Yocto’nun sağlamadığı ek bileşenleri dahil etmek
  • Düzeltme almak veya bilinen iyi bir durumu korumak için sürüm yükseltmek ya da sabitlemek
• Her Yocto bakım sürümü çıktığında, yerel değişikliklerin yeni durumun üzerine temiz biçimde uygulanabildiğini doğrulamanız gerekir
• Eklediğiniz veya sabitlediğiniz bileşenleri Yocto bakımcıları bilmeyeceği için, bunların düzeltme almaya devam edip etmediğini de bizzat takip etmeniz gerekir
• Poky’yi neredeyse hiç değiştirmeden kullanıyorsanız, neden Yocto’ya ihtiyaç duyduğunuzu yeniden düşünmelisiniz

Linux çekirdeği ve satıcı bağımlılığı

• Yocto, her sürümün parçası olarak Linux çekirdeği sağlar ve bakımını yapar; ancak gerçek ürünlerde bunun değişikliksiz kullanılması nadirdir
• Genellikle en azından satıcı patch’lerini uygulamanız ve gerekli sürücüleri ile düzeltmeleri içeren yeterince yeni bir çekirdek kullanmanız gerekir
• CVE takibi de eklendiğinde, çekirdek tek başına bile Yocto kullanıp kullanmamanızdan bağımsız olarak büyük bir bakım yükü oluşturur
• Bu yükü kontrol etmek için, kernel.org üzerindeki LTS çekirdek temel alınmalı ve tüm değişiklikler düzenli bir patch kuyruğu halinde tutulmalıdır
• Güvenlik düzeltmelerini takip etmek için yeni stable sürüme geçilir, ardından patch kuyruğu yeniden uygulanır
• kernel.org, LTS çekirdekleri yıllarca bakımda tuttuğu için, patch kuyruğu genelde temiz biçimde uygulanır ve asıl iş yalnızca yeni LTS sürümüne geçerken gerekir
• Yapılandırma ve güvenlik gereksinimlerine bağlı olarak aynı ilkeler bootloader için de geçerlidir; bootloader da genellikle büyük ölçüde satıcıya özeldir
• Satıcının sağladığı çekirdeği olduğu gibi korumak genellikle iyi bir yaklaşım değildir
  • vendor kernel çoğu zaman kernel.org’un yıllarca gerisindedir
  • Neredeyse hiç güncelleme almaz
  • Güvenlik düzeltmelerinin büyük kısmını kaçırır

Yocto’ya geçişin maliyeti

• Kendi dağıtımınızı oluşturma kararı, gerçek mühendislik zamanı gerektirir

• Derleme süresi

  • Yocto pratikte neredeyse her şeyi kaynaktan derler
  • Çok karmaşık olmayanın üstündeki bir imajın temiz derlemesi bile hızlı bir workstation’da saatler sürer
  • sstate-cache ve paylaşımlı DL_DIR, tekrar derlemeleri hızlandırır; ancak küçük bir tarif değişikliği bile cache’in büyük bir kısmını geçersiz kılabilir

• Disk ve CI maliyeti

  • Yocto build dizinleri kolayca 100GiB’ın üzerine çıkabilir
  • CI runner’larında yeterli depolama ve işler arasında sstate paylaşımı gerekir
  • sstate ve DL_DIR için mirror kullanmak acıyı azaltabilir, ancak bu altyapıyı sizin işletmeniz gerekir

• Öğrenme eğrisi

  • bitbake tarifleri, katmanlar, dinamik katmanlar, sınıflar, override’lar, bbappend dosyaları, PACKAGECONFIG, DEPENDS ve RDEPENDS arasındaki fark gibi öğrenilmesi gereken çok şey vardır
  • Mühendislerin Yocto kod tabanına alışması günler değil, haftalar alır

• BSP katmanı kalitesindeki değişkenlik

  • Bazı SoC satıcıları temiz ve iyi bakılan BSP katmanları sunar
  • Bazıları ise 5 yıllık çekirdek veya bootloader’a sabitlenmiş, makineye özel tarifleri yanlış katmana hard-code eden ve Poky yükseltildikçe bozulan meta-vendor katmanları sağlar
  • İyi bir başlangıç noktası gibi görünen bir BSP, build’in en kötü parçasına dönüşebilir
  • Bunlar Yocto’dan kaçınmanız gerektiğini değil, onu benimsemeden önce gerçekten gerekli olup olmadığını doğrulamanız gerektiğini gösterir

Alternatif: kanıtlanmış bir dağıtımı yeniden kullanmak

• Yalnızca uygulama çalıştıracak sağlam bir Linux tabanına ihtiyacınız varsa, Debian GNU/Linux gibi mevcut bir dağıtım aynı sorunların büyük bölümünü çok daha az projeye özgü işle çözer
• Debian şu anda yaklaşık 70.000 ikili paket sunuyor
• Desteklenen mimariler arasında amd64, i386, arm64, armhf, riscv64, ppc64el ve diğerleri bulunur
• Birçok SoC, Debian ikililerini yeniden derleme olmadan doğrudan çalıştırabilir
• Debian, yalnızca systemd, udev, dbus içeren modern bir kullanıcı alanı sunan bir dağıtım değildir
• Arşivinde SysV tarzı init veya BusyBox tabanlı küçük Linux sistemleri kurmak için gerekli bileşenler de vardır
• İnce bir temel seçip ürüne gereken paketleri kurarak Debian paket bakımcılarının emeğinden yararlanabilirsiniz

Debian bakım modeli

• Debian stable, Debian Security Team’den yaklaşık 3 yıl güvenlik güncellemesi alır
• Ardından topluluk temelli Debian LTS projesi, yaygın mimarilerde desteği yaklaşık 2 yıl daha uzatır
• Böylece sürüm başına pratikte yaklaşık 5 yıl destek mümkün olur; bu, Yocto LTS ile benzer düzeydedir ama projeye özgü iş çok daha azdır
• En güncel düzeltmeleri almak için en yeni Debian paketlerini çekip imajı yeniden oluşturmanız yeterlidir
• Bu, Yocto’da upstream patch’leri bizzat backport etmekten veya yerel değişikliklerin bakım sürümleri üzerinde hâlâ uygulanabildiğini yeniden doğrulamaktan çok farklı bir iş modelidir

Gömülü imajın nasıl oluşturulduğu

• Debian tabanlı gömülü imaj, SoC üzerinde USB flash sürücüden açılıp Debian kurucusunu çalıştırmak anlamına gelmez
• Bunun yerine build host üzerinde flash’lanabilir bir imaj üretilir ve cihaza yazılır
• Gerekli parçalar şunlardır
  • Genellikle SoC’ye özgü bootloader, örneğin u-boot
  • Genellikle SoC’ye özgü Linux çekirdeği
  • Doğrudan Debian’dan alınmış Linux kullanıcı alanı tabanlı root filesystem
  • Bu üç parçayı flash’lanabilir bir imajda birleştiren imaj oluşturma aracı
• İmaj oluşturma araçları için yaygın seçenekler mkosi, ELBE, debos’tur
• Üçü de özgür yazılımdır ve donanıma flash’lanabilecek deterministik imajlar üretir
• Bakım işi ciddi biçimde azalır; güncellemelerin çoğu, tarif yeniden yazmaktan ziyade imaj içindeki paketleri apt tarzında yenilemeye dönüşür

debos tabanlı Debian build örneği

• debos, YAML tariflerini okur
• Tarifler; komut çalıştırma, root filesystem oluşturma ve yapılandırılmış kaynaklardan Debian paketleri kurma gibi aksiyonlardan oluşur
• Temel akış şöyledir
  • Gerekli tüm Debian paketlerinin bir kopyasını içeren yerel bir Debian mirror’u aptly ile işletirsiniz
  • Linux çekirdeğini ve gerekiyorsa bootloader’ı Debian paketi olarak build eder, sonra mirror’a eklersiniz
  • Mirror snapshot’ı oluşturur ve etiketlersiniz
  • Bu etiket sürümünüz olur
  • debos’u bu mirror’u kullanacak şekilde ayarlar ve hedef imajı oluşturan tarif aksiyonlarını yazarsınız
  • Gerekirse Debian kaynak paketlerini ve imajın SBOM’unu(Software Bill of Materials) imajla birlikte saklarsınız
• Kaynak paketleri ve SBOM saklamak, GPL kaynak sağlama yükümlülüklerini ve CRA’nın malzeme listesi gereksinimlerini karşılamaya yardımcı olur
• debsbom gibi araçlar SBOM’u doğrudan Debian sisteminden üretir

Ne zaman Yocto seçilmeli

• Yoğun biçimde özelleştirilmiş bir dağıtım gerekiyorsa Yocto uygundur
  • Özelleştirilmiş kullanıcı alanı
  • Özelleştirilmiş derleme bayrakları
  • Temel bileşenlerde derin değişiklikler
• Hazır bir dağıtımla karşılanamayacak katı boyut veya önyükleme süresi kısıtları varsa uygundur
• Genel lisans kategorilerini hariç tutmayı gerektiren lisans kısıtları varsa uygundur
  • Tıbbi cihazlar, otomotiv ve bazı savunma projeleri gibi bazı sektörlerde GPLv3 bileşenleri dağıtılmaz
  • Yocto’daki INCOMPATIBLE_LICENSE mekanizması, belirli lisans ailelerini tüm imajdan çıkarmayı kolaylaştırır
  • Standart Debian tabanında paketleri tek tek denetleyip azaltmanız gerekir
• SoC satıcısının resmi destek yolu Yocto ise ve BSP kalitesi sağlamsa uygundur

Ne zaman Yocto’dan kaçınılmalı

• Yalnızca üzerine uygulama koyup çalıştıracağınız modern bir Linux gerekiyorsa, Yocto’ya ihtiyaç olmayabilir
• Depolama ve bellek bütçesi sıradan bir Debian tabanlı imajı kaldırabiliyorsa, Yocto’nun avantajı azalır
  • Örnek eşik; yüzlerce MB flash ve 256MB veya daha fazla RAM
• Ürün ömrü uzunsa ve kendi bakımınızı üstlenmek yerine Debian Security Team’e güvenmek daha mantıklıysa, Yocto’dan kaçınmak daha doğru olur

Ne zaman Debian’dan kaçınılmalı

• Çok sayıda Debian paketini değiştirmeniz veya yeniden build etmeniz gerekiyorsa Debian dezavantajlı hale gelir
  • Birkaç paketi yeniden build etmek yönetilebilir
  • Yeniden build edilen her paket, sizin üstlendiğiniz ayrı bir bakım işi olur
  • Onlarca upstream paketi patch’lemek, Debian bakımcılarının yaptığı işi yeniden üretmek anlamına gelir
  • Bu ölçekte Yocto’nun tarif modeli daha temiz bir çözüm sunar
• musl veya uClibc gibi glibc dışı libc gerekiyorsa Debian uygun değildir
  • Debian’ın ana arşivi büyük ölçüde glibc kullanır
  • Bunu değiştirmek için arşivin büyük kısmını kendiniz yeniden build etmeniz gerekir
• Debian stable’ın sunduğundan çok daha yeni yazılımlara ihtiyaç duyuyorsanız Debian dezavantajlıdır
  • backports bazı paketlerde yardımcı olabilir
  • Güncel derleyiciler veya yeni runtime’lar ürün için gerekliyse Debian stable ile çatışır
  • Debian testing, üretim hedefi değildir

Karar ilkesi ve sonuç

• Yocto kullanıp kullanmama kararı bilinçli biçimde ve ürünün erken safhasında verilmelidir
• Bu seçim, ürün sahaya çıktıktan sonra geri çevrilmesi zor olan temel bir karardır
• Emin değilseniz, mevcut bir dağıtımla başlamak daha iyidir
• Gerçek bir neden ortaya çıktıktan sonra daha sonra Yocto’ya geçmenin maliyeti, proje ortasında yıllarca sürecek bakım işini somut bir fayda olmadan üstlendiğinizi fark etmekten çok daha düşüktür
• Yocto, ihtiyaç duyduğunuz Linux sistemini tam olarak üretmenizi sağlayan mükemmel bir mühendislik ürünüdür; ancak tam da bu hassas denetime ihtiyacınız olmadığında sorun haline gelir
• Buildroot gibi diğer kaynak tabanlı build araçları için de neredeyse aynı mantık geçerlidir
• Kendi dağıtımınızı bir araya getirdiğiniz anda, onun bakım sorumluluğunu da doğrudan üstlenmiş olursunuz
• Temel sonuç nettir
  • “Kendi dağıtımınız” gerçekte bakımını da kendiniz üstlenmeniz demektir
  • CRA ve benzeri düzenlemeler bu maliyeti gerçek bir yük haline getirir
  • Büyük ölçüde değiştirilmiş Yocto build’leri upstream düzeltmeleri bedelsiz şekilde devralmaz
  • Her bakım sürümü, gözden geçirme ve yeniden çalışma anlamına gelir
  • mkosi, ELBE, debos ile imajlaştırılmış Debian gibi mevcut dağıtımlar, genel durumu çok daha az projeye özgü çabayla çözer
  • Sistemi cerrahi hassasiyetle kontrol etmeniz gerektiğinde Yocto kazanır
  • Böyle bir ihtiyaç yokken Yocto’yu seçmek, var olmayan bir sorunu uzun ve pahalı yoldan çözmeye çalışmaktır

[GN⁺]

Lobste.rs yorumları

• SoC üreticisinin resmî destek yolu Yocto ise, BSP çok sağlam olmasa bile genelde kalitesi düşük Ubuntu portlarından daha iyidir diye düşünüyorum
  Ubuntu portları, RAUC entegrasyonu ya da root filesystem’i değişmez hâle getirme gibi işleri uğraştırıcı kılıyor. Yocto’dan ve onun türev bash/python lehçelerinden gerçekten nefret ediyorum ama sonuçta ona bağlı kalıyorsunuz

• Oldukça fazla Yocto danışmanlığı yapıyorum ama yazıda yakınılan sorunları neredeyse hiç yaşamadım. Genelde tam tersi oluyor; Yocto’nun en iyi seçenek olduğu durumlarda bile müşteriler ısrarla kaçınmaya çalışıyor ve yöneticileri ikna etmek zorunda kalıyorum
  Yine de Yocto’dan nefret edilmesini anlıyorum. Zor, kafa karıştırıcı, yavaş ve araçlar da daha iyi olabilir. Ama gerçekten uygulanabilir bir alternatif var mı bilmiyorum; BSD tarafında da benzeri bir şey olup olmadığını merak ediyorum

  • Yocto’ya ne kadar benzediğini bilmiyorum ama FreeBSD’de gömülü sistem imajları oluşturmanın yaygın yolu NanoBSD
    https://docs.freebsd.org/en/articles/nanobsd/
  • Pratikte derinlemesine kullanmadım ve Yocto’dan daha az olgun olabilir ama buildroot içinde epey iyi şeyler var
    Bunu çoğunlukla Nerves bağlamında kullandım; Nerves temelde buildroot + fwup + Erlang VM ve destek yazılımlarının birleşimi. Gömülü Linux sistemleri geliştirmek, paketlemek ve dağıtmak için oldukça kullanışlıydı
  • Gömülü Linux/BSD sistemleriyle doğrudan uğraşmıyorum ama NetBSD kullanmış biri olarak, derleme sistemi build.sh tek başına bile yeterli görünüyor
    Kernel ve user space’i kolayca cross-compile edebiliyorsunuz. En sonda pkgsrc uygulamaları eklemek ya da oluşturulan imaja u-boot gibi bir bootloader koymak gerekiyorsa biraz betik yazmak gerekebilir. Uygulamanıza göre hemen özelleştirilebilen, tamamlanmış bir akış olmayabilir ama temel olarak gayet iyi
  • NetBSD, kısıtlı ortamları hedefleyerek cross-compile için iyi yapılandırılmış ve mantığını kavradıktan sonra kullanımı oldukça rahat

• Gömülü dünyanın berbat taraflarını biraz görmüş sınırlı deneyimime göre, bu tür işler için NixOS oldukça uygundu ve derleme araçları da Yocto’dan çok daha iyiydi

  • ARM cihazlarda da böyle mi merak ediyorum. NixOS ekosisteminin bu tür cihazlar için hâlâ biraz erken aşamada olduğunu sanıyordum

• Tam da şirkette Rockchip tabanlı cihazlar için özel bir Linux kernel’i ve dağıtımı planlayıp geliştirmeye başlamıştık; zamanlaması çok iyi bir yazı olmuş
  BSP’nin bakım gerektirecek epey şeyi var gibi görünüyor ve Debian’ı “öylece kullanmak”, benim kötü yazdığım bitbake görevlerinden çok daha yönetilebilir duruyor. Yine de Yocto ekosisteminin kendisi oldukça iyi; başlangıcı kolaylaştıran kas veya isar gibi araçlar var

  • isar README’sine bakınca bunun Yocto değil, Debian tabanlı olduğu anlaşılıyor. İkisini birlikte kullanmak yaygın mı merak ediyorum
    Yazı bunu Yocto ya da Debian gibi anlatıyor; ikisini birleştiren bir yaklaşım varmış gibi değil