Libreboot 26.10 «Ominous Olive» با پشتیبانی UEFI، Chromebook منتشر شد

می‌توانید نسخه امروز را در https://rsync.libreboot.org/stable/26.10/ بیابید یا می‌توانید از یکی از آینه‌ها استفاده کنید.

Libreboot یک سیستم عامل بوت منبع باز رایگان است که جایگزین میان افزار اختصاصی BIOS/UEFI در سخت افزار Intel/AMD و ARM64 پشتیبانی می شود. سخت‌افزار داخل رایانه شما مانند CPU یا کنترل‌کننده حافظه را راه‌اندازی می‌کند، دستگاه را به گونه‌ای پیکربندی می‌کند که امکان استفاده از سیستم عاملی مانند لینوکس یا BSD را در هنگام بوت فراهم کند - و اکنون مایکروسافت ویندوز نیز سازگار است زیرا Libreboot پشتیبانی کامل UEFI را از طریق MrChromebox EDK2 payload اضافه کرده است.

Libreboot امنیت و سفارشی سازی بیشتری را در مقایسه با سیستم عامل اختصاصی ارائه می دهد. هدف آن، به وضوح، خلاص شدن از دنیای نرم افزارهای اختصاصی است و برای انجام این کار، ما سعی می کنیم سیستم عاملی را ارائه دهیم که درک آن برای کاربران غیر فنی بسیار آسان باشد.

تغییرات انتشار امروز نسبت به نسخه قبلی Libreboot 26.01 است.

این یک نسخه بسیار ویژه است، با چندین تغییر عمده در طراحی بدون توجه به تغییرات سخت افزاری، بنابراین کاربران باید این تغییرات را با دقت مطالعه کنند - و آن را دو بار مطالعه کنند.

اولین چیز اول است (و بله، پاراگراف قبلی را درست خواندید)

یک خط مشی قوی ضد هوش مصنوعی به فایل جدیدی اضافه شد: AGENTS.md در lbmk. این مهم ترین تغییر در انتشار است. حالا همه چیز دیگر:

اخطار: تغییرات عمده ای در طراحی در این نسخه ایجاد شد، به گونه ای که ممکن است بر بسیاری از تنظیمات موجود تأثیر بگذارد. ما اکنون از EDK2 به عنوان محموله پیش فرض استفاده می کنیم، با GRUB/SeaBIOS که به صورت فلش به عنوان EFI بیلد برای سازگاری با عقب ارائه می شود. همه چیز کار می کند، اما برخی اخطارها وجود دارد، بنابراین لطفا این تغییرات انتشار را با دقت بخوانید.

لیست کامل تابلوها بسیار طولانی است، بنابراین در پایان این مقاله نشان داده شده است. همه 233 نفر!

MrChromebox تقریبا از هر Chromebook پشتیبانی می کند و این نسخه همه بردها را از آن پروژه وارد می کند. این شامل همه چیز تا جدیدترین سخت افزار اینتل و AMD می شود.

همه 233 دستگاه Chromebook که در حال حاضر پشتیبانی می‌شوند از توزیع اصلی MrChromebox وارد شده است. Baytrail (Kip) آزمایش شد - دیگران نیاز به آزمایش دارند. فقط منبع در این نسخه (باید از منبع ساخته شود، باینری ارائه نشده است).

این کار با ابزاری که در util/mrimport نوشتم انجام شد که تنظیماتی را برای lbmk ایجاد می‌کند، از جمله ویرایش‌ها و زیر ماژول‌ها. من ترفندهای بیشتری را به صورت دستی انجام دادم. به روز رسانی های بیشتر در بالادست را می توان در Libreboot با تغییر مجدد خروجی mrimport بین ویرایش ها، همگام سازی کرد، بدون در نظر گرفتن تغییرات نسخه دوم که تعداد آنها زیاد است - و در ادامه به آن پرداخته خواهد شد.

Libreboot این تغییرات را در coreboot MrChromebox در نسخه خود انجام می دهد:

محموله های اضافی، مانند بالا، در منوی بوت از طریق فشار دادن کلید ESC هنگام راه اندازی در دسترس هستند. iPXE نیز به‌طور پیش‌فرض فعال است، مانند upstream، در بردهای خاص. EFI GRUB و CSM SeaBIOS جایگزین نسخه‌های coreboot payload اینها شده‌اند. SeaBIOS/GRUB فلزی برهنه اکنون منسوخ شده است و ممکن است در نسخه آینده Libreboot حذف شود، اگرچه کسانی که مایل به ساخت Libreboot از منبع هستند می توانند دوباره فعال شوند.

این انشعابات MrChromebox نیست، که باید به عنوان نسخه بالادستی Libreboot در کروم‌بوک‌های Intel/AMD در نظر گرفته شود. مانند coreboot معمولی، تلاش خواهد شد تا تا حد امکان با آن هماهنگ باشد. من به طور گسترده با MrChromebox کار کرده‌ام و حتی چند اصلاح جزئی برای پروژه او ارائه کرده‌ام. او همچنین بر اساس درخواست من مدیریت VBT و GOP مبتنی بر CBFS را پیاده سازی کرد که من پس از انتشار آن را ادغام خواهم کرد.

صرف نظر از این، اسکریپت های نصب خود MrChromebox باید با تصاویر Libreboot کار کنند، بنابراین برای نصب، مستندات MrChromebox را بررسی کنید. با وجود تغییرات، تنظیمات Libreboot از نظر رفتاری با MrChromebox one سازگار است و بنابراین، ابزار MrChromebox همچنان باید در کنار اسناد مربوطه کار کند.

این امر با یک ویژگی جدید در سیستم ساخت لیبربوت امکان پذیر شده است: پشتیبانی از تعداد دلخواه بالادستی در هر پروژه. ما هنوز هم coreboot معمولی را در مادربردهای غیر Chromebook ارائه می دهیم.

بله 233. شمردم. همه خودکار اسکریپت نویسی و سخت کوشی من تضمین کرد که آنچه در lbmk وارد و پیکربندی کردم با بالادست مطابقت داشته باشد، و من در حفظ واگرایی خودم با آن در داخل Libreboot کاملا مراقب هستم.

به عنوان مثال KGPE-D16. ما اکنون از فورک coreboot از 15h.org در مادربردهای AMD Fam15h استفاده می کنیم. این از کد منبع AMD AGESA به جای کد اولیه سفارشی Timothy استفاده می کند. این رامینیت و تنظیم اولیه CPU بسیار قابل اعتمادتر است. رم بیشتر نیز پشتیبانی می شود. بسیاری از اشکالات رفع شده است. IOMMU کار می کند، من هم دیدم که گفتند TPM در نسخه آنها ثابت است، اکنون نسخه ما نیز.

باینری های منظم با بارهای SeaBIOS و GRUB ارائه شده - ما همچنین تصاویر آزمایشی مبتنی بر EDK2 را داریم که در حال حاضر فقط منبع هستند (هیچ باینری موجود نیست). EDK2 برای راه‌اندازی به یک فریم بافر نیاز دارد و تراشه AST2050 یکپارچه فقط در حالت متنی در مقدار اولیه اولیه شروع می‌شود. رام VGA فروشنده می تواند VESA را راه اندازی کند، اما ما از VGA ROM استفاده نخواهیم کرد. تصاویر مبتنی بر EDK2 فقط منبع بر روی این بردها هستند و برای استفاده با کارت های گرافیک در نظر گرفته شده اند.

اساسا این تابلوها برای اولین بار عمل می کنند.

EDK2 پیاده سازی مرجع اینتل از مشخصات UEFI برای بوت است. این معمولا توسط فروشندگان، در قالب‌های اختصاصی کد دارای مجوز BSD اینتل استفاده می‌شود، اما کد مرجع اینتل نرم‌افزار رایگان است. ما از کد مرجع آنها استفاده می کنیم و کد منبع کامل در این نسخه Libreboot ارائه شده است. EDK مخفف: EFI Development Kit است.

ما از یک چنگال EDK2 که توسط MrChromebox ارائه شده است استفاده می کنیم، که به طور خاص استفاده از EDK2 را به عنوان یک بار اصلی coreboot ارائه می دهد. این یک پیاده سازی کامل و استاندارد صنعتی UEFI است که می تواند هر سیستم عامل سازگار را بوت کند.

همه تقریبا همه بردها در حال حاضر از آن در Libreboot استفاده می کنند، حتی تخته های قدیمی به عنوان مثال. ThinkPad X200. تست شده بر روی تمامی پلتفرم ها مادربردهای قدیمی‌تر و فقط 32 بیتی هنوز از تنظیمات نسخه قبلی استفاده می‌کنند، در حالی که تقریبا همه سخت‌افزارهای سازگار با 64 بیت اکنون از EDK2 استفاده می‌کنند. ساخت‌های EFI GRUB و SeaBIOS به صورت فلش ارائه می‌شوند که از منوی تنظیم EDK2 قابل دسترسی است (در زمان راه‌اندازی در صورت درخواست، ESC را فشار دهید)، برای سازگاری با نصب‌های Linux/BSD موجود در Libreboot.

پشتیبانی EDK2 به عنوان یک پیش نیاز برای کروم‌بوک‌ها ادغام شد، اما پس از آن برای استفاده در تمام مادربردهای پشتیبانی شده قبلی در Libreboot گسترش یافت. حتی روی ماشین های واقعا قدیمی به خوبی اجرا می شود. ThinkPad T500.

همه بردهای Libreboot اکنون به طور پیش فرض از اجرای UEFI منبع باز استفاده می کنند، در صورت امکان. همه آنها، و به طور پیش‌فرض است - محموله‌های هسته‌ای فلزی GRUB و SeaBIOS حذف شده‌اند و با نسخه‌های EFI که سازگار با عقب هستند جایگزین شده‌اند.

ما قبلا به هیچ وجه UEFI ارائه نمی کردیم، به جز U-Boot در چند صفحه اصلی منتخب. ما اکنون UEFI کامل را با هر چهار آزادی دست نخورده، تقریبا در هر صفحه اصلی که Libreboot پشتیبانی می‌کند، ارائه می‌کنیم.

همه سیستم‌عامل‌های زیر در دستگاه‌های مختلف Libreboot با استفاده از EDK2 آزمایش و کارکردشان تأیید شد:

رایانه ها و سیستم عامل های مدرن همگی UEFI هستند و این راه اندازی جدید می تواند اساسا همه آن را به طور قابل اعتماد بوت کند. تست های بیشتری مورد نیاز است، اما این کد آزمایش شده در نبرد است و سال هاست که توسط بسیاری از کاربران به طور گسترده در coreboot استفاده می شود. بالاخره Libreboot نیز آن را دارد.

این تغییر به تنهایی بخشی از تلاش بسیار گسترده‌تر برای مدرن‌سازی Libreboot است و من تازه شروع کرده‌ام. نسخه‌های بعدی Libreboot به شدت از این موضوع استفاده می‌کنند، زیرا EDK2 تقریبا بار مورد انتظار در بسیاری از راه‌اندازی‌های coreboot مدرن این روزها است. ادغام EDK2 تمام محدودیت‌های Libreboot را حذف می‌کند و به ما امکان می‌دهد از سخت‌افزار بسیار جدیدتر پشتیبانی کنیم و اساسا استفاده از Libreboot را بسیار آسان‌تر می‌کند. من انتظار دارم Libreboot به مرور زمان بسیار محبوب تر و مفیدتر شود، در نتیجه.

برخی از اخطارها و یادداشت های اضافی در انتهای این صفحه انتشار برای اهداف مهاجرت ارائه شده است. به عنوان مثال، علیرغم اینکه همه چیز را به رخ می کشد، سخت افزارهای قدیمی فقط 32 بیتی هنوز از GRUB/SeaBIOS خالی استفاده می کنند. با این حال، تقریبا همه بردها از EDK2 استفاده می کنند!

در نهایت، نکاتی در مورد کارت‌های گرافیکی که ممکن است مورد توجه کاربران سخت‌گیر باشد.

EDK2 در کنار نوار قابل جابجایی PCI-E (میلگرد) به این معنی است که اکنون می توانید از کارت های گرافیک مدرنی که به تخصیص بالای 4 گیگابایت نیاز دارند استفاده کنید. Rebar به طور پیش فرض فعال نیست، اما می توانید آن را در منوی پیکربندی (coreboot) فعال کنید. فعال کردن آن باعث شکسته شدن خروجی ویدیوی پردازنده گرافیکی اینتل در libgfxinit در آزمایش می شود و هنوز هیچ مشکلی پیدا نشده است، بنابراین میلگرد به طور پیش فرض غیرفعال است.

رام های گزینه PCI-E به صورت پیش فرض در صورت لزوم برای ساخت های EDK2 فعال می شوند. این بدان معناست که می توانید از آن روی دسکتاپ با کارت گرافیک استفاده کنید. تست شده بر روی چندین دسکتاپ (Dell OptiPlex 9020 SFF و 5050 SFF).

در بردهایی که فقط GPU خارجی دارند، میلگرد را می توان به طور پیش فرض فعال نگه داشت. در سیستم هایی با گرافیک یکپارچه کارکرده، فعال سازی تصادفی میلگرد را می توان با قرار دادن کارت گرافیک برطرف کرد. وقتی خروجی ویدیو در محموله خراب می شود، درایور ویدیوی لینوکس i915 همچنان فریم بافر ویدیو را به درستی در KMS/DRM راه اندازی می کند.

این به اسناد عمومی اضافه خواهد شد، در حال انتظار برای رفع مشکلات بالادست. توجه داشته باشید که حتی با این مشکل، خروجی ویدیوی لینوکس به خوبی کار می کند. در نسخه آتی Libreboot این مورد تصحیح می شود و میلگرد به طور پیش فرض فعال می شود.

درخت 4.11_branch coreboot حذف شد، زیرا ما اکنون از فورک 15h.org coreboot در سخت افزار AMD Fam15h استفاده می کنیم. این بسیار بهبود یافته است، با مقداردهی اولیه مناسب مبتنی بر AGESA که CPU ها و کنترل کننده حافظه را با اطمینان بیشتری مقداردهی اولیه می کند. رم بیشتر پشتیبانی می‌شود و چندین ویژگی نیز برطرف شده‌اند. IOMMU و TPM.

استفاده از چندین coreboot upstream با بهبود طراحی در lbmk امکان پذیر شد که همه پروژه ها را چند درختی می کند، فقط با وجود داشتن یک درخت در برخی از پروژه ها. اکنون می توانیم N تعداد بالادست در هر پروژه داشته باشیم که امکان استفاده از فورک ها را فراهم می کند.

به‌روزرسانی coreboot GCC 15.2، MPC 1.4.1، Nasm 3.02، acpica 20251212 و binutils 2.46.1 را در crossgcc ارائه می‌کند.

همه 233 کروم بوک که در حال حاضر توسط MrChromebox پشتیبانی می شوند، وارد شده و برای استفاده در Libreboot سازگار شده اند. همه آنها جمع آوری می کنند. همه آنها. تکرار میکنم:

ما ساخت‌های SeaBIOS CSM و GRUB EFI را در داخل EDK2 اضافه می‌کنیم تا با تنظیمات بارگیری قدیمی‌تر GRUB/SeaBIOS Libreboot برابری کنیم. محموله های EFI تقریبا یکسان کار می کنند.

استفاده از EDK2 پشتیبانی از ماشین‌های جدیدتر را آسان‌تر می‌کند، که از این به بعد تمرکز روی آن‌ها خواهد بود. EDK2 به عنوان بخشی از یک تلاش کلی برای نوسازی، اول شد. سخت افزارهای جدیدتر اینتل و AMD به مرور زمان اضافه می شوند و به طور پیش فرض از EDK2 payload استفاده می کنند.

این بسیار یک انتشار ویژگی است. تغییرات زیادی در ویژگی ایجاد شد!

بسیاری از تغییرات عمده در طراحی ایجاد شده است!

تغییرات زیادی در util/nvmutil/ اعمال شد تا جایی که شایسته گزارش انتشار خود باشد:

توجه: این برای نسخه مستقل nvmutil اعمال می شود. تلاشی برای بازنویسی آن در یک ابزار بسیار بزرگتر انجام شد که در بخش زیر در مورد تغییرات لغو شده برای این نسخه ذکر شد (به یادداشت های زیر در مورد libreboot-utils مراجعه کنید).

تقریبا هزار خط کد مرده از سیستم ساخت پاک شد، اما چند صد خط دیگر به دلیل تغییرات ویژگی جدید اضافه شد. به طور کلی، با وجود پیشرفت هایی که در این نسخه داشته است، مقدار کد در lbmk کاهش یافته است.

روی چند تغییر کار شد، اما در این نسخه مشاهده نشد. آنها مربوط به دو پروژه بزرگ هستند:

این افزونه‌ای از nvmutil بود که بعدا به مجموعه‌ای از ابزارهای عمومی در کنار کتابخانه‌ای برای مدیریت مواردی مانند نوشتن اتمی و کاهش فضای کاربر در برابر انواع مختلف حملات TOCTOU تبدیل شد. برای خود nvmutil خیلی مهم نیست، اما…

سعی شد نسخه سخت شده mktemp به نام mkhtemp پیاده سازی شود. چندین کاهش را در فضای کاربران در برابر حملات TOCTOU اجرا کرد، به عنوان مثال. جایگزینی دایرکتوری و حملات Symlink.

برای مشاهده موارد بیشتر، lbmk git log را برای util/libreboot-utils بررسی کنید (ممکن است util/libreboot_utils باشد.

Mkhtemp هنگام پیاده سازی atomic writes برای nvmutil شروع شد، اما پس از آن طبیعتا از tmpfiles برای آن استفاده کردم، و این باعث شد که هر پیاده سازی mktemp را ممیزی کنم. به این نتیجه رسیدم که می توانم بهتر عمل کنم - و این کار را هم کردم.

... این یک قطعه مزخرف بیش از حد مهندسی شده بود، و چندین مشکل حافظه مربوط به استفاده از حافظه پشته ای داشت، که در BSD مشکل زیادی داشت. می توان آن را مرتب کرد و تمام کرد، اما من به یک نتیجه رسیدم:

دیستروس هرگز آن را نمی پذیرد. Mkhtemp روی لینوکس خوب کار می کرد، اما عملکرد بسیار سخت تری داشت که اکثر سیستم های ساختی را که از آن استفاده می کردند، خراب می کرد. من آن را در lbmk امتحان کردم تا جایگزین mkhtemp شود و آن را در PATH سیملینک کنم، اما برای مثال GRUB عملا هیچ خطایی در بررسی mktemp نداشت. اکثر برنامه هایی که از mktemp به اشتباه استفاده می کنند، تصور می کنند که هرگز نمی تواند شکست بخورد، بنابراین اینطور نیست. پیاده سازی ها سعی می کنند خطاها را کاهش دهند و عملیات را ادامه دهند، به روش هایی که بسیار پیچیده است. Mkhtemp تلاشی پاک برای استفاده سخت‌گیرانه‌تر از TMPDIR بود.

از آنجایی که به این نتیجه رسیدم که اتلاف وقت است، فکر نمی‌کنم در این تغییرات بیشتر در مورد آن بنویسم. اگر علاقه دارید، lbmk git log را بررسی کنید.

یک نسخه بسیار توسعه یافته از util/spkmodem-recv که حفاظت از نویز بسیار قوی‌تری را پیاده‌سازی می‌کند، تلاش برای تشخیص خودکار تن و انتخاب فرکانس، به علاوه موارد دیگر. من کمی با آن زیاده روی کردم و به این نتیجه رسیدم که این یک تلاش مهندسی بیش از حد است. در هیچ مقطعی از سر گرفته نخواهد شد. می توانید آن را در lbmk git log پیدا کنید. (ممکن است util/spkmodem_decode باشد).

تلاش بیهوده پروتکل Spkmodem در اکثر تنظیمات غیرقابل استفاده است.

کاملا بی معنی کد ساده تر به خوبی کار می کند، بنابراین تلاش متوقف شد و بنابراین spkmodem-recv هنوز وجود دارد. این یک نسخه پاک شده از آنچه چندین سال پیش از GNU GRUB به ارث رسیده است است.

لغو سوم پنهان، زیرا همیشه یکی وجود دارد:

لینوکس بوت. اکنون با پشتیبانی EFI، اگر بخواهیم به راحتی می‌توانیم از هر تعداد UKI اضافه شده به فلش استفاده کنیم - و در نسخه‌های بعدی این کار را خواهیم کرد. اصطلاح Linuxboot به هر توزیع لینوکس مبتنی بر فلش اشاره دارد که می تواند هسته های لینوکس دیگر را از طریق Kexec بوت کند - ترجیح من ZFSBootMenu است یا حداقل چیزی که از آن الهام گرفته شده است زیرا سیستم ساخت ZFSBootMenu کاملا با اصول طراحی سختگیرانه Libreboot ناسازگار است.

(که روشی مودبانه برای گفتن این است که من با علاقه از پادمن/دوکر متنفرم)

UKIهای لینوکس در حال حاضر برای بوت رایج هستند و Libreboot EDK2 می تواند به راحتی آن را ادغام کند.

محموله ARM64 هنوز وجود دارد، اما EDK2 جایگزین U-Boot در x86 شده است.

این سزاوار بخش خاص خود در این نسخه است، زیرا یک تغییر عمده در طراحی است. EDK2 صرفا به عنوان یک گزینه اضافه نشده است. در x86 جایگزین U-Boot شده است. من می توانم این مقاله خود را بسازم. لیاقت یکی را دارد. این سزاوار قضاوت من است، زیرا اکنون می خواهم بدون عبارات نامشخص بیان کنم:

U-Boot برای پیاده سازی سبک وزن UEFI بر روی بردهای Intel/AMD استفاده شد، اما شخصی که مسئول اصلی محموله x86 coreboot برای U-Boot است، تا حد زیادی U-Boot را به یک پروژه جدید با کد vibe تبدیل کرده است. Libreboot به شدت با استفاده از هوش مصنوعی، طبق سیاست جدید مخالف است. هوش مصنوعی خوب نیست و پشتیبانی از x86 U-Boot تا حد زیادی کاهش یافته است، اگرچه چندین وصله جالب ادغام شدند.

بنابراین U-Boot یک تعهد در x86 است. EDK2 در حال حاضر کاملا کاربردی است، بنابراین به جای آن استفاده می شود. فکر می کنید هوش مصنوعی از شما یک هکر فوق العاده می سازد؟ دوباره فکر کن:

به هر حال U-Boot همیشه در x86 باگ بود. واقعا اصلا آماده نیست. بهتر است در RISCV و ARM64 (جایی که ما همچنان از آن استفاده می کنیم) استفاده شود.

U-Boot upstream خود به شدت ضد هوش مصنوعی است، حداقل در زمان انتشار، و بحث های زیادی در مورد موارد فوق در لیست پستی آنها وجود داشت. ارائه مجدد آن در این صفحه انتشار مفید نخواهد بود، اما باید گفت که پروژه Libreboot U-Boot را عملا در x86 مرده می داند. توسعه مبتنی بر ARM هنوز به شدت ادامه دارد، بالادست، و ما همچنان به استفاده از U-Boot برای UEFI در ARM64 (برای مثال کروم‌بوک‌ها) ادامه خواهیم داد.

من نام او یا نام چنگال او را نمی گویم، زیرا نمی خواهم او یا فورک U-Boot او را تبلیغ کنم. اگر نام یا پروژه او را می دانید، نباید آن را بگویید یا تبلیغ کنید. هوش مصنوعی بد است، بسیار بد، به دلایلی در اینجا:

فورک مورد بحث، U-Boot، به شدت با هوش مصنوعی کدگذاری شده است و بنابراین برای Libreboot بی فایده است. این یک حدس و گمان نیست. نویسنده در تاپیک لیست پستی U-Boot فوق الذکر چنین بیان کرد. ما به هیچ وجه استفاده از هوش مصنوعی را تشویق یا تسهیل نمی کنیم. مشخص شده است که چندین پروژه که Libreboot از آنها استفاده می کند، دارای تعهداتی با کمک هوش مصنوعی نیز هستند. GCC، GRUB، و غیره.

نویسنده چنگال اساسا با آن دیوانه شد و به U-Boot در بالادست پیشنهاد کرد که کارش "سرپرست" باشد و به آرامی در درخت U-Boot بالادست ادغام شد. او اساسا آنها را تحت فشار قرار می داد تا برخلاف میلشان کد هوش مصنوعی را بپذیرند. من به عنوان رهبر پروژه Libreboot می گویم که U-Boot هرگز نباید به هوش مصنوعی اجازه دهد پروژه آن را لکه دار کند. وقتی هوش مصنوعی را قبول می کنید، مهارت ندارید و اعتمادی را که بین شما و کاربرانتان وجود دارد از بین می برید.

شما ارتباط انسانی بین نگهبانان و کاربران را حذف می کنید، و پروژه شما شروع به وابستگی به فناوری انحصاری - بله - می کند که با خون پرداخت می شود. هوش مصنوعی یکی از بزرگترین مصرف کنندگان برق و آب در کره زمین است که منجر به کمبود منابع در سراسر جهان می شود و کنترل فزاینده آن بر اطلاعاتی که مردم در اخبار می بینند حتی تهدیدی برای دموکراسی در سراسر جهان است. این حتی قبل از بحث در مورد مجوزهای نامشخص، نقض حق چاپ و غیره است. تصمیم گرفته شد که Libreboot به جنگ صلیبی علیه تمام هوش مصنوعی بپیوندد.

کشورهایی که مسئول اصلی آموزش هوش مصنوعی و زیرساخت هستند، ایالات متحده (به رهبری چندین شرکت که در حال حاضر به دموکراسی در سراسر جهان حمله می کنند) و جمهوری خلق چین هستند. حتی اگر تمام مشکلات دیگر هوش مصنوعی وجود نداشته باشد، این ایده بسیار بدی خواهد بود که به این کشورها قدرت بیشتری بر محاسبات خود بدهیم.

نه Libreboot به هوش مصنوعی نه می گوید. بنابراین، ما به استفاده از U-Boot بالادست، همانطور که آنها می گویند نه، ادامه خواهیم داد، و از هیچ انشعابی ویبکد شده آن استفاده نخواهیم کرد. حتی اگر این باعث شود که مجبور شوم هفته ها را صرف یکپارچه سازی یک سیستم کاملا جدید برای جایگزینی آن کنم. این دقیقا، دقیقا و بدون شک تا کجا پیش خواهم رفت تا حرفم را ثابت کنم.

به همین دلیل است که من برای ادغام EDK2 به چنین تلاش شدیدی رفتم. به جای جایگزینی U-Boot با یک پیاده‌سازی ناقص UEFI، من به سادگی EDK2 را اضافه کردم که در حال حاضر ویژگی‌های کاملی دارد زیرا مرجع و استاندارد صنعتی استاندارد اجرای مشخصات UEFI است.

CrabEFI همان چیزی بود که من در ابتدا در نظر گرفتم، تا جایگزین U-Boot شود. این یک محموله جدید است که توسط Arthur Heymans نوشته شده است، و خود پروژه عالی است، اما rustc/cargo ذاتا به چند دلیل غیرقابل اعتماد است:

Rust عالی است، اما به نظر من هنوز آماده تولید نیست. ده سال دیگر به آن فرصت دهید. EDK2 بی نهایت پیچیده تر است، اما اندازه کد نگران کننده نیست زیرا به طور کلی پایدار است و به زبان C نوشته شده است (بعضی از بیت های کوچک آن در C++ هستند). بیشترین توجه را دارد و مرتبا ممیزی های امنیتی را دریافت می کند. این یکی از آزمایش‌شده‌ترین پایگاه‌های کد در اینترنت است و به خوبی کار می‌کند.

CrabEFI احتمالا در زمانی در آینده در Libreboot ادغام خواهد شد، زمانی که ابزار Rust در توزیع‌ها (از جمله BSD) تثبیت شود. طراحی بسیار بهتری دارد، حتی اگر هنوز ویژگی های آن کامل نشده باشد، و استفاده از Rust به این معنی است که اشکالات حافظه کمتری خواهد داشت. در حال حاضر، Libreboot از EDK2 برای جایگزینی U-Boot استفاده می کند و به طور پیش فرض در همه بردها فعال شده است.

در مورد ایمنی حافظه، برعکس می‌توان گفت که EDK2 حداقل پایدار است. اشکالات نیز پایدار هستند. این نکته است. ما کامپایلرهای C/C++ پایداری داریم که به درستی مطابق با استانداردهای رسمی تست شده اند (در واقع نه، زیرا GCC و LLVM نیز انواع کارهای بد را انجام می دهند، اما آنها همچنین سعی می کنند از نظر رفتاری با یکدیگر سازگار باشند). شما می‌خواهید که کد شما، هنگام کامپایل، دقیقا یکسان عمل کند، باگ‌ها نیز در آن گنجانده شده است. این امر با پروژه‌هایی که به زبان C و C++ نوشته شده‌اند به شدت تضمین می‌شود (مخصوصا پروژه‌های C خالص، و بیشتر EDK2 در واقع C خالص هستند).

در ابتدا قرار بود U-Boot به محموله اصلی Libreboot در x86 تبدیل شود، اما افسوس. گلوله با طعم اینتل را گاز گرفتم و با EDK2 رفتم.

به هوش مصنوعی نه بگویید هوش مصنوعی شما را احمق می کند. هوش مصنوعی دلیلی است که ما نمی توانیم چیزهای خوب داشته باشیم.