शायद आपको Yocto की ज़रूरत नहीं है, और यह बिल्कुल ठीक है

• Yocto कोई distribution नहीं है, बल्कि अपना Linux distribution assembled करने का एक toolset है; अगर आपको इतना control नहीं चाहिए, तो इसे default choice बनाना मुश्किल है
• अपना distribution होने का मतलब है अपनी maintenance, और इसके साथ CRA जैसे regulations तथा product lifecycle भर security updates की ज़िम्मेदारी भी आती है
• Yocto अपनाने के साथ कई घंटे के builds, 100GiB से बड़े build directories, कई हफ्तों की learning curve, और quality में असमान BSP layers आते हैं
• अगर आपको applications चलाने के लिए एक मजबूत Linux base चाहिए, तो Debian और mkosi·ELBE·debos जैसे image tools बहुत कम project-specific काम के साथ पर्याप्त हो सकते हैं
• Yocto तभी बेहतर साबित होता है जब बहुत गहरी customization, size·boot time constraints, license exclusions, या मजबूत vendor Yocto support हो; अगर संदेह हो, तो मौजूदा distribution बेहतर है

---

Yocto असल में क्या है, और यह default choice क्यों बन जाता है

• Yocto “Yocto Linux distribution” नहीं है, बल्कि अपना Linux distribution बनाने के लिए tools का एक संग्रह है
• Yocto Project, bitbake, openembedded-core, meta-yocto से बना reference distribution Poky भी देता है
• Yocto embedded projects के लिए ज़रूरी Linux system को बहुत बारीकी से assemble करने की सुविधा देता है
  • पूरा user space target CPU के लिए compile किया जा सकता है
  • किसी भी component पर patch लगाया जा सकता है
  • हर recipe की features को on या off किया जा सकता है
  • सभी versions को pin या बदल सकते हैं
• कई SoC vendors और hardware partners ready-to-use BSP(Board Support Package) layers देते हैं, जो असली hardware पर चलने वाला शुरुआती base बनाते हैं
• इसी flexibility और vendor support के मेल की वजह से Yocto default choice बन जाता है, लेकिन अगर आपको इतना control नहीं चाहिए तो इसका बोझ ज़्यादा हो सकता है

अपना distribution होने का मतलब है अपनी maintenance

• Cyber Resilience Act(CRA) जैसे regulations यह मांगते हैं कि product supplier अपने distributed software को सुरक्षित रखे और product lifecycle भर security updates दे
• सामान्य Yocto releases अगली release आने तक, यानी लगभग 7 महीने तक maintain की जाती हैं
• Yocto 5.0 Scarthgap से, मौजूदा policy के तहत LTS releases को अधिकतम 4 साल updates मिलते हैं
• Yocto release एक खास version और metadata वाले bitbake recipes के set, और reference distribution Poky से मिलकर बनती है
• maintenance period के दौरान Yocto maintainers components और Poky पर bug fixes और security fixes लागू करते हैं, और software component fixes आम तौर पर नए upstream versions से backport किए जाते हैं
• असली products में Yocto को ज्यों का त्यों इस्तेमाल करने के बजाय अक्सर ये बदलाव किए जाते हैं
  • कुछ components पर non-trivial patches या local changes लागू करना
  • Yocto में न मिलने वाले अतिरिक्त components शामिल करना
  • fixes पाने या known-good state बनाए रखने के लिए versions upgrade या pin करना
• हर Yocto maintenance release आने पर यह verify करना पड़ता है कि local changes नई state पर साफ़-साफ़ apply हो रहे हैं या नहीं
• जो components आपने जोड़े या pin किए हैं, उनके बारे में Yocto maintainers को पता नहीं होता, इसलिए आपको खुद देखना पड़ता है कि उन्हें fixes मिलते रह रहे हैं या नहीं
• अगर आप Poky को लगभग बिना बदले इस्तेमाल कर रहे हैं, तो यह फिर से सोचना चाहिए कि आपको Yocto की ज़रूरत क्यों है

Linux kernel और vendor dependence

• Yocto हर release के हिस्से के रूप में Linux kernel देता और maintain करता है, लेकिन असली products में इसे बिना बदलाव के इस्तेमाल करना दुर्लभ है
• आम तौर पर कम से कम vendor patches लगाने पड़ते हैं, और ज़रूरी drivers व fixes वाला पर्याप्त नया kernel इस्तेमाल करना पड़ता है
• CVE tracking जोड़ दें, तो सिर्फ kernel ही Yocto इस्तेमाल करें या न करें, बड़ी maintenance cost बन जाता है
• maintenance बोझ को काबू में रखने के लिए kernel.org के LTS kernel पर build करना और सारे changes को एक व्यवस्थित patch queue में रखना सुझाया जाता है
• security fixes के साथ बने रहने के लिए नए stable releases पर जाना और patch queue को फिर से apply करना पड़ता है
• kernel.org LTS kernels को कई साल maintain करता है, इसलिए आम तौर पर patch queue साफ़-साफ़ apply हो जाती है और असली काम सिर्फ नए LTS release पर जाने में होता है
• configuration और security requirements के अनुसार यही सिद्धांत bootloader पर भी लागू होता है, और bootloader भी अक्सर vendor-specific होता है
• vendor द्वारा दिए गए kernel पर ही टिके रहना आम तौर पर अच्छा विचार नहीं है
  • vendor kernel अक्सर kernel.org से कई साल पीछे होता है
  • इसमें बहुत कम updates आते हैं
  • यह ज़्यादातर security fixes से चूक जाता है

Yocto अपनाने की लागत

• अपना distribution बनाने का फैसला वास्तविक engineering time मांगता है

• Build time

  • Yocto लगभग हर चीज़ source से compile करता है
  • साधारण स्तर से ऊपर की image का clean build भी तेज workstation पर कई घंटे लेता है
  • sstate-cache और shared DL_DIR repeated builds को तेज करते हैं, लेकिन recipe में छोटा बदलाव भी cache के बड़े हिस्से को invalidate कर सकता है

• Disk और CI cost

  • Yocto build directory आसानी से 100GiB से ज़्यादा हो सकती है
  • CI runners को पर्याप्त storage और jobs के बीच sstate share करने का तरीका चाहिए
  • sstate और DL_DIR को mirror करने से परेशानी कम हो सकती है, लेकिन वह infrastructure आपको खुद चलाना पड़ता है

• Learning curve

  • bitbake recipes, layers, dynamic layers, classes, overrides, bbappend files, PACKAGECONFIG, DEPENDS और RDEPENDS के अंतर जैसी बहुत सी चीज़ें सीखनी पड़ती हैं
  • किसी engineer को Yocto codebase पर onboard करने में कुछ दिन नहीं, बल्कि कई हफ्ते लगते हैं

• BSP layer quality में फर्क

  • कुछ SoC vendors साफ़-सुथरी और अच्छी तरह maintained BSP layers देते हैं
  • दूसरे vendors 5 साल पुराने kernel या bootloader को pin कर देते हैं, machine-specific recipes को गलत layers में hardcode करते हैं, और meta-vendor layers देते हैं जो हर बार Poky upgrade पर टूट जाती हैं
  • जो BSP अच्छा शुरुआती base लगता है, वही build का सबसे खराब हिस्सा बन सकता है
  • ये बातें Yocto से बचने का कारण नहीं, बल्कि अपनाने से पहले यह जांचने का कारण हैं कि इसकी सच में ज़रूरत है या नहीं

विकल्प: सिद्ध distribution का पुन: उपयोग

• अगर आपको सिर्फ applications चलाने के लिए एक मजबूत Linux base चाहिए, तो Debian GNU/Linux जैसी मौजूदा distribution वही समस्याओं का बड़ा हिस्सा बहुत कम project-specific effort के साथ हल कर सकती है
• Debian इस समय लगभग 70,000 binary packages देता है
• supported architectures में amd64, i386, arm64, armhf, riscv64, ppc64el आदि शामिल हैं
• कई SoC बिना recompilation के सीधे Debian binaries चला सकते हैं
• Debian सिर्फ systemd, udev, dbus वाला modern user space देने वाला distribution नहीं है
• archive में SysV-style init या BusyBox-based छोटे Linux systems बनाने के लिए ज़रूरी चीज़ें भी शामिल हैं
• आप पतला base चुनकर product के लिए ज़रूरी packages ही install कर सकते हैं, और फिर भी Debian package maintainers के काम का लाभ ले सकते हैं

Debian maintenance model

• Debian stable को Debian Security Team से लगभग 3 साल तक security updates मिलते हैं
• इसके बाद community-driven Debian LTS project सामान्य architectures पर लगभग 2 साल और support बढ़ाता है
• व्यवहार में हर release को लगभग 5 साल support मिल सकता है, जो Yocto LTS के समान है, लेकिन project-specific काम कहीं कम है
• नए fixes पाने के लिए बस नए Debian packages लेकर image को फिर से build करना होता है
• यह Yocto में upstream patches को खुद backport करने या यह दोबारा verify करने से बहुत अलग है कि local changes maintenance releases पर लागू हो रहे हैं या नहीं

Embedded image बनाने का तरीका

• Debian-based embedded image का मतलब यह नहीं कि SoC पर USB flash drive से boot करके Debian installer चलाया जाए
• तरीका यह है कि build host पर flashable image बनाई जाए और उसे device पर लिखा जाए
• ज़रूरी components आम तौर पर ये होते हैं
  • आम तौर पर SoC-specific bootloader, जैसे u-boot
  • आम तौर पर SoC-specific Linux kernel
  • Debian से सीधे लिया गया Linux user space आधारित root filesystem
  • इन तीनों को flashable image में जोड़ने वाला image assembly tool
• image assembly tools के सामान्य विकल्प mkosi, ELBE, debos हैं
• तीनों tools free software हैं और hardware पर flash की जा सकने वाली deterministic images बनाते हैं
• maintenance का काम काफ़ी कम हो जाता है, और ज़्यादातर updates recipe दोबारा लिखने के बजाय image के packages को apt तरीके से refresh करने का मामला बन जाते हैं

debos आधारित Debian build का उदाहरण

• debos YAML recipe पढ़ता है
• recipe, commands चलाने, root filesystem बनाने, और configured sources से Debian packages install करने जैसी actions की सूची होती है
• बुनियादी flow कुछ ऐसा है
  • aptly से एक local Debian mirror चलाइए, जिसमें ज़रूरी सभी Debian packages की copy हो
  • Linux kernel और ज़रूरत हो तो bootloader को Debian packages के रूप में build करके mirror में जोड़िए
  • mirror snapshot बनाइए और उसे tag कीजिए
  • वही tag release बन जाता है
  • debos को उस mirror के उपयोग के लिए configure कीजिए और target image बनाने वाली recipe actions लिखिए
  • ज़रूरत हो तो Debian source packages और image का SBOM(Software Bill of Materials) image के साथ store कीजिए
• source packages और SBOM को store करना GPL source distribution obligations और CRA की materials-list requirements पूरी करने में मदद करता है
• debsbom जैसे tools सीधे Debian system से SBOM generate करते हैं

कब Yocto चुनना चाहिए

• जब बहुत ज़्यादा customized distribution चाहिए हो, तब Yocto उपयुक्त है
  • customized user space
  • custom compile flags
  • base components में गहरे बदलाव
• जब ऐसे सख्त size या boot time constraints हों जिन्हें ready-made distribution पूरा नहीं कर सकती, तब यह उपयुक्त है
• जब ऐसे license constraints हों जिनमें सामान्य license categories को exclude करना पड़े, तब यह उपयुक्त है
  • medical devices, automotive, और कुछ defence projects जैसे sectors में कुछ जगह GPLv3 components distribute नहीं किए जाते
  • Yocto का INCOMPATIBLE_LICENSE mechanism पूरी image से खास license families को हटाना आसान बनाता है
  • सामान्य Debian-based setup में packages को खुद audit और trim करना पड़ता है
• जब SoC vendor का official support path Yocto हो और BSP quality मजबूत हो, तब यह उपयुक्त है

कब Yocto से बचना चाहिए

• अगर आपको सिर्फ application चलाने के लिए modern Linux चाहिए, तो संभव है कि Yocto की ज़रूरत न हो
• अगर storage और memory budget सामान्य Debian-based image संभाल सकते हैं, तो Yocto के फायदे कम हो जाते हैं
  • एक उदाहरण baseline है: कुछ सौ MB flash और 256MB या अधिक RAM
• अगर product lifecycle लंबा है और अपनी maintenance करने के बजाय Debian Security Team पर निर्भर रहना बेहतर है, तो Yocto से बचना सही होगा

कब Debian से बचना चाहिए

• अगर आपको Debian packages में बहुत बदलाव या rebuild करने पड़ें, तो Debian कम अनुकूल हो जाता है
  • कुछ packages का rebuild संभाला जा सकता है
  • लेकिन हर rebuilt package आपकी अपनी maintenance responsibility बन जाता है
  • अगर आप दर्जनों upstream packages patch करते हैं, तो आप वही काम दोबारा बना रहे होते हैं जो Debian maintainers पहले कर रहे थे
  • इस स्तर पर Yocto का recipe model ज़्यादा साफ़ तरीके से काम संभालता है
• अगर आपको musl या uClibc जैसी non-glibc libc चाहिए, तो Debian सही विकल्प नहीं है
  • Debian का main archive व्यापक रूप से glibc पर आधारित है
  • इसे बदलने का मतलब archive के बड़े हिस्से को खुद rebuild करना होगा
• अगर आपको Debian stable से कहीं ज़्यादा नया software चाहिए, तो Debian कमज़ोर पड़ता है
  • backports कुछ packages में मदद कर सकते हैं
  • लेकिन अगर product को हाल का compiler या हाल का runtime चाहिए, तो यह Debian stable से टकराता है
  • Debian testing production target नहीं है

निर्णय के सिद्धांत और निष्कर्ष

• Yocto का फैसला सोच-समझकर, product के शुरुआती चरण में करना चाहिए
• यह ऐसा foundational choice है जिसे product के field में deploy होने के बाद बदलना मुश्किल होता है
• अगर संदेह हो, तो मौजूदा distribution से शुरू करना बेहतर है
• बाद में, जब वास्तविक कारण पैदा हो, Yocto पर जाना उस स्थिति से कहीं कम महंगा है जिसमें project के बीच में पता चले कि आपने बिना ठोस लाभ के वर्षों की maintenance अपने सिर ले ली
• Yocto एक शानदार engineering उपलब्धि है जो आपको ज़रूरत का Linux system बिल्कुल सटीक बनाने देती है, लेकिन वही सटीक control तब समस्या बन जाता है जब उसकी सच में ज़रूरत न हो
• Buildroot जैसे दूसरे source-based build tools पर भी यही तर्क लगभग समान रूप से लागू होता है
• जिस क्षण आप अपना distribution assemble करते हैं, उसी क्षण उसकी maintenance responsibility भी आपकी हो जाती है
• मुख्य निष्कर्ष साफ़ है
  • “अपना distribution” का मतलब वास्तव में अपनी maintenance है
  • CRA और इसी तरह के regulations इस लागत को वास्तविक बोझ बना देते हैं
  • बहुत बदला हुआ Yocto build upstream fixes को मुफ़्त में inherit नहीं करता
  • हर maintenance release review और rework बन जाती है
  • Debian जैसी मौजूदा distributions, जिन्हें mkosi, ELBE, debos से image किया जा सकता है, सामान्य मामलों को बहुत कम project-specific effort से संभाल लेती हैं
  • जब system पर surgical control चाहिए, तब Yocto जीतता है
  • बाकी स्थितियों में Yocto चुनना एक ऐसी समस्या को लंबे और महंगे तरीके से हल करना है जो वास्तव में है ही नहीं

[GN⁺]

Lobste.rs की राय

• अगर SoC vendor का आधिकारिक सपोर्ट रास्ता Yocto है, तो BSP बहुत मजबूत न भी हो, तब भी यह आम तौर पर कम-गुणवत्ता वाले Ubuntu port से बेहतर लगता है
  Ubuntu port की वजह से RAUC integration या root filesystem immutability जैसे काम झंझट भरे हो जाते हैं। मुझे Yocto और उसकी बदली हुई bash/python dialect सच में पसंद नहीं, लेकिन आखिरकार उसी से बंधे हुए हैं

• मैं Yocto consulting बहुत करता हूँ, लेकिन लेख में जिन समस्याओं पर अफसोस जताया गया है, उन्हें लगभग कभी नहीं झेला। आम तौर पर उल्टा होता है, यानी जहाँ Yocto सबसे अच्छा विकल्प होता है, वहाँ भी ग्राहक उसे बेवजह टालना चाहते हैं, और तब management को समझाना पड़ता है
  फिर भी Yocto से नफरत क्यों होती है, यह समझ में आता है। यह कठिन है, उलझाऊ है, धीमा है, और tools बेहतर हो सकते हैं। लेकिन इसका कोई वास्तविक विकल्प है या नहीं, पता नहीं, और यह भी जिज्ञासा है कि BSD पक्ष में ऐसा कुछ है या नहीं

  • यह Yocto से कितना मिलता-जुलता है, पता नहीं, लेकिन FreeBSD में embedded system image बनाने का सामान्य तरीका NanoBSD है
    https://docs.freebsd.org/en/articles/nanobsd/
  • मैंने इसे production में गहराई से इस्तेमाल नहीं किया है, और यह Yocto से कम परिपक्व हो सकता है, लेकिन buildroot में काफी अच्छी चीजें हैं
    मैंने इसे ज़्यादातर Nerves के संदर्भ में इस्तेमाल किया है, और Nerves मूल रूप से buildroot + fwup + Erlang VM और support software का संयोजन है। embedded Linux system को develop करने और package/deploy करने के लिए यह काफी सुविधाजनक लगा
  • मैं embedded Linux/BSD systems के साथ सीधे काम नहीं करता, लेकिन NetBSD इस्तेमाल करने के अनुभव से मुझे लगता है कि उसका build system build.sh ही काफी है
    इससे kernel और user space को आसानी से cross-compile किया जा सकता है। अंत में अगर pkgsrc applications जोड़ने हों, या बनी हुई image में u-boot जैसा bootloader डालना हो, तो थोड़ा scripting चाहिए हो सकता है। यह application के हिसाब से तुरंत customize हो जाने वाला तैयार workflow न हो, लेकिन आधार के रूप में ठीक है
  • NetBSD सीमित environments को target करके cross-compilation के लिए अच्छी तरह बना है, और एक बार हाथ बैठ जाए तो काफी सुखद लगता है

• embedded दुनिया की भयावहता का थोड़ा अनुभव होने के आधार पर, ऐसे उपयोग के लिए NixOS काफी उपयुक्त लगा, और उसके build tools भी Yocto से कहीं बेहतर थे

  • सोच रहा हूँ कि क्या ARM devices पर भी ऐसा ही है। मुझे लगा था कि NixOS ecosystem अभी उन devices के लिए थोड़ा शुरुआती चरण में है

• संयोग से कंपनी में हमने Rockchip-आधारित devices के लिए custom Linux kernel और distribution की योजना बनाकर काम शुरू किया है, इसलिए यह लेख सही समय पर आया
  BSP में maintain करने लायक चीजें काफी दिखती हैं, और Debian को “बस इस्तेमाल करना” मेरे द्वारा खराब तरीके से लिखे गए bitbake tasks की तुलना में कहीं अधिक manageable लगता है। फिर भी Yocto ecosystem खुद में काफी अच्छा है, और शुरुआत आसान बनाने के लिए kas या isar जैसे tools हैं

  • isar README देखने पर यह Yocto नहीं बल्कि Debian-based लगता है। जिज्ञासा है कि क्या दोनों को मिलाकर इस्तेमाल करना आम है
    लेख में बात ऐसे की गई है मानो विकल्प Yocto या Debian हो, दोनों को मिलाकर कोई तरीका नहीं