2023-03-22 10:02:27 +00:00
% Політика зменшення бінарних блобів
% Лія Р о у
% 4 січня 2022 року (оновлено 15 листопада 2022 року)
Вступ
============
2023-03-26 16:39:44 +00:00
У *принципи* , які керують проектом Libreboot. Щоб отримати
інформацію про те, *як ці принципи застосовуються на практиці* , прочитайте
натомість цю статтю: [Статус свободи програмного та апаратного забезпечення для
кожної материнської плати, що підтримується Libreboot](../freedom-status.uk.md)
2023-03-22 10:02:27 +00:00
Політика Libreboot полягає в тому, щоб надати настільки, наскільки можливо, свободи
кожному користувачу, на кожному підтримуваному апаратному забезпеченні та *підтримувати
стільки апаратного забезпечення з coreboot, наскільки це можливо*; це означає, що ви повинні
мати можливість вивчати, змінювати та *ділитися* всім джерельним кодом, документацією
чи іншими подібними ресурсами, які роблять Libreboot таким, яким він є. Простіше кажучи, ви повинні
мати *контроль* над своїми власними обчисленнями.
*Мета* Libreboot полягає в тому, щоб
зробити саме це та допомогти якомога більшій кількості людей, автоматизувавши
конфігурацію, компіляцію та встановлення *coreboot* для *нетехнічних*
користувачів, ще більше спростивши це для звичайного користувача, надаючи користувачам
дружні інструкції для всього. По суті, Libreboot - це *дистрибутив
coreboot*, приблизно так само, як *Alpine Linux* є дистрибутивом Linux!
Метою цього документа є окреслення того, як це досягається, і
проект працює на цій основі. *Цей* документ здебільшого стосується
ідеології, тому він (переважно) нетехнічний; для отримання технічної інформації
ви можете звернутися до [документації системи збірки Libreboot ](../docs/maintain/ ).
Поточний обсяг проекту
=====================
Проект libreboot стосується того, що входить до основної мікросхеми завантажувальної флеш-пам'яті,
але є й інші компоненти мікропрограми, які слід взяти до уваги, про що йдеться
в [поширених запитаннях щодо libreboot ](../faq.uk.md#яке-ще-мікропрограмне-забезпечення-існує-за-межами-libreboot ).
Найбільш критичні з них це:
* Прошивка вбудованого контролера (EC)
* Прошивка жорстких дисків/твердотілих накопичувачів
* Прошивка Intel Management Engine / AMD PSP
Що таке двійковий блоб?
----------------------
Двійковий блоб у
який ви не можете досліджувати та змінювати розумним чином. З а
у с і *пропрієтарними* за своєю природою, і
Конкретні двійкові блоби також є проблематичними в більшості систем coreboot, але вони
відрізняються для кожної машини. Дізнайтесь більше в розділі поширених запитань і
як ми працюємо з двійковими блобами в проекті Libreboot.
Для інформації про Intel Management Engine та AMD PSP зверніться до поширених запитань.
Політика *зменшення* блобів
=======================
Конфігурації за замовчуванням
----------------------
Coreboot, на якому Libreboot базується, є здебільшого вільним програмним забезпеченням, але
на деяких платформах вимагає двійкових блобів. Найпоширенішим прикладом може бути raminit
(ініціалізація контролера пам'яті) а б о
coreboot використовує двійкові блоби для деяких з цих завдань, на деяких материнських платах,
але деякі материнські плати з coreboot можна ініціалізувати з 100% вільним джерельним
кодом, який ви можете перевірити та скомпілювати для свого використання.
Libreboot вирішує цю ситуацію *суворо* та *принципово* . Природа
цього - це те, що ви збираєтесь прочитати.
Проект libreboot має наступну політику:
* Якщо блоб *можна* уникнути, його слід уникати. Наприклад, якщо ініціалізація VGA ROM
в іншому випадку працює краще, але coreboot має *вільний* код ініціалізації
для певного графічного пристрою, цей код слід використовувати в libreboot під
час створення образу ROM. Подібним чином, якщо *ініціалізація контролера пам'яті* можлива
за допомогою бінарного блобу *а б о вільного коду в coreboot, *вільний* код
слід використовувати в ROM, створених системою збірки Libreboot, а *блоб*
для raminit не слід використовувати; однак, якщо вільний код ініціалізації недоступний
для зазначеного raminit, це дозволено, і
*блоб* .
* Необхідно звернути увагу на деякі нюанси: у а б о
зазвичай буде *два* графічних пристрої (наприклад, чіп nvidia та
чіп intel, використовуючи технологію nvidia optimus technology, на ноутбуці). Можливо,
один із них має вільний код ініціалізації в coreboot, а
прийнятно і
розміщував необхідний двійковий блоб на тому, якому бракує власної
ініціалізації.
* Виняток зроблено для оновлень мікрокоду ЦП: вони дозволені та фактично
*обов'язкові* відповідно до політики libreboot. Ці оновлення виправляють помилки ЦП, у
числі помилки безпеки, і
ROM в будь-якому випадку, єдиний вибір - *x86* а б о *зламаний x86* . Таким чином, libreboot
дозволить лише конфігурації материнської плати coreboot, де
*ввімкнено* оновлення мікрокоду, якщо доступно для ЦП на цій системній платі.
2023-06-20 06:02:54 +00:00
[Releases after 20230423 will provide separate ROM images with microcode
excluded, alongside the default ones that include microcode.](microcode.md)
2023-03-22 10:02:27 +00:00
* Intel Management Engine: у *повинні* бути написані
слова, щоб розповісти людям, як *нейтралізувати* ME, якщо це можливо на даній дошці.
Програма `me_cleaner` є дуже корисною та забезпечує набагато безпечнішу конфігурацію
ME.
* Бінарні блоби *ніколи* не слід видаляти, навіть якщо вони не використовуються.
У `3rdparty` з бінарними блобами
для завдань ініціалізації на багатьох платах. *У с і вони повинні бути включені до випусків
libreboot, навіть якщо вони не використовуються. Таким чином, навіть якщо система збірки Libreboot
ще не підтримує певну плату, хтось, хто завантажує libreboot, все одно
може внести зміни у
забажає, щоб надати конфігурацію свого апаратного забезпечення.
Загалом, застосовано здоровий глузд. Наприклад, винятком
із мінімізації може бути те, що *блоб* raminit та *вільний* raminit доступні, але
*вільний* так зламано, що його не можна використовувати. У
слід використовувати той, що з блобом, тому що в іншому випадку користувач може повернутися до
повністю пропрієтарної системи замість використання coreboot (через libreboot).
2023-04-23 22:56:45 +00:00
*Деякі* свободи *краще, ніж жодних* .
2023-03-22 10:02:27 +00:00
Нова прагматична політика Libreboot також може призвести до того, що в майбутньому більше людей стануть
розробниками coreboot, виступаючи в якості важливого *містка* між
*ним* і
Налаштування
-------------
Наведені вище принципи мають застосовуватися до конфігурацій *за замовчуванням* . Однак libreboot
має бути *конфігурованим* , дозволяючи користувачеві робити все, що заманеться.
Цілком природно, що користувач може захотіти створити *менш* вільний параметр, ніж
стандартний у
і *свободу вибору* користувача
також слід поважати та пристосовуватись до неї.
Іншими словами, не читайте лекції користувачеві. Просто спробуйте допомогти їм у
їхній проблемі! Метою проекту libreboot є просто зробити coreboot більш
доступним для нетехнічних користувачів.
КАТАЛОГ СВОБОДИ
===============
2023-04-23 23:08:01 +00:00
Також має бути доступна сторінка *[статусу блобів](../freedom-status.uk.md)* ,
яка інформуватиме людей про статус бінарних блобів на кожній машині, що
підтримується системою збірки Libreboot. Дивіться:
[Статус свободи програмного та апаратного забезпечення для кожної плати, яка
підтримується Libreboot](../freedom-status.uk.md)
2023-03-22 10:02:27 +00:00
Бажано бачити світ, де все апаратне та програмне забезпечення є вільним, під
тією ж ідеологією, що й проект Libreboot. Обладнання!?
Так, обладнання. RISC-V є чудовим прикладом сучасної спроби вільного апаратного забезпечення, яке
часто називають *Апаратним забезпеченням з відкритим кодом* .
Це ISA для виробництва мікропроцесора. Уже існує багато реальних
реалізацій, які можна використовувати, і
більше.
Таке *апаратне забезпечення* ще знаходиться в зародковому стані. Ми повинні почати проект, який
буде каталогізувати статус різних зусиль, у
рівні кремнію). Такі рухи, як OSHW і
важливими, включно з нашим власним рухом, який інакше зазвичай менше думатиме про свободу апаратного
забезпечення (хоча йому справді, справді
варто!)
Одного дня ми житимемо у
включаючи процесори, а
чіпів реальністю зараз знаходяться в зародковому стані, але такі зусилля існують,
наприклад, робота, виконана Семом Зелофом і
* < https: // www . youtube . com / channel / UC7E8-0Ou69hwScPW1_fQApA >
* < http: // sam . zeloof . xyz />
* < https: // libresilicon . com />
(Сем буквально виробляє процесори в своєму гаражі)
Проблеми з критеріями RYF
==========================
Раніше Libreboot відповідав критеріям FSF RYF, але тепер він дотримується
набагато більш прагматичної політики, спрямованої на надання більшої свободи більшій кількості людей у
більш прагматичний спосіб. Ви можете прочитати ці вказівки, перейшовши за цією URL-адресою:
2023-04-16 00:39:50 +00:00
* Рекомендації FSF Поважає Вашу Свободу (RYF):
< https: / / web . archive . org / web / 20220604203538 / https: / / ryf . fsf . org / about / criteria / >
2023-03-22 10:02:27 +00:00
Простіше кажучи, інструкції RYF стосуються комерційних продуктів із застереженням,
що вони не повинні містити пропрієтарне програмне забезпечення чи відомі проблеми конфіденційності,
як-от лазівки.
Повне виключення всього пропрієтарного забезпечення наразі неможливе. Наприклад,
пропрієтарне мікропрограмне забезпечення SDR у
жорсткі диски а б о В
* "Однак є один виняток для вторинних вбудованих процесорів. Виняток стосується програмного забезпечення, що постачаєтья в бічних допоміжних і у а б о
2023-04-16 13:35:18 +00:00
*та має бути відхилено
2023-03-22 10:02:27 +00:00
з ідеологічних міркувань*. Решта політики libreboot і
ідеологія, виражена в цій статті, базуватиметься в основному на цьому неприйнятті.
Визначення *програмного забезпечення продукту* абсолютно довільне; програмне забезпечення
є програмне забезпечення, а *вільним* . Замість того, щоб робити такі
винятки, слід заохочувати більше апаратного забезпечення, допомогаючи надавати якомога
більше свободи, одночасно надаючи користувачам інформацію про будь-які підводні
камені, з якими вони можуть зіткнутися, і
як FSF, робить такі сміливі винятки, як вище, вона надсилає неправильне повідомлення,
кажучи людям, по суті, заховати ці інші проблеми лише тому, що вони стосуються програмного забезпечення,
яке працює на "вторинному процесорі".
Якщо користувач може оновити програмне забезпечення, воно має бути вільним,
незалежно від того, *передбачав* виробник оновлення чи ні.
Там де справді *не* можливо оновити таке програмне забезпечення, пропрієтарне чи ні,
слід надати поради щодо цього. Освіта важлива, і
активно перешкоджають такій освіті; це створює помилкову надію, що
все добре і
рівні ідеальне.
Цей погляд FSF, виражений у
що системою керує переважно *один* головний процесор. Н а
сучасних комп'ютерах це *більше не відповідає дійсності* .
Вільне *програмне забезпечення* не існує у
минулому, особливо коли справа стосувалася апаратного забезпечення, тому *ПЗ* було нашим основним фокусом.
Здатність вільно вивчати, адаптувати, обмінюватися та використовувати/повторно використовувати ПЗ є важливою,
але є багато нюансів, коли справа доходить до *завантажувального мікропрограмного забезпечення* , нюансів, які
здебільшого не існують поза розробкою мікропрограмного забезпечення чи поза розробкою ядра.
Більшість типового прикладного/системного програмного забезпечення є високорівневим і
завантажувальна мікропрограма має бути написана для кожної конкретної машини, і
апаратне забезпечення працює, існує багато компромісів, зокрема FSF, коли
визначає які стандарти слід застосовувати *на практиці* .
Той факт, що майже ніхто не говорить про прошивку EC, *пов'язаний* із
сертифікацією Поважає Вашу Свободу (Respects Your Freedom). Насправді мікропрограмне забезпечення EC має вирішальне
значення для свободи користувачів і
*частину апаратного забезпечення*. Це неправильно, і
заохочувати людей визволяти його на кожному ноутбуці!
Інше мікропрограмне забезпечення, яке наразі не доступне для проекту libreboot, описано на
сторінці поширених питань libreboot. Наприклад, прошивка жорстких дисків/твердотілих накопичувачів описана в розділі поширених запитань.
Знову ж таки, повністю проігноровано та знизано плечима FSF.
Проект libreboot не буде приховувати а б о
справді є критичними, але, знову ж таки, наразі виходять за межі того, що робить система збірки Libreboot
Н а
coreboot (і
Приклади *замітання блобів під килим* FSF
----------------------------------------------
Протягом багатьох років було багато випадків, коли FSF активно не
заохочував рівень свободи програмного забезпечення, наприклад:
* Робоча станція TALOS II "OpenPOWER" від Raptor Engineering USA. Вона містить
мережеву плату Broadcom в с о б і і
FSF були готові проігнорувати це та сертифікувати продукт TALOS II відповідно до RYF,
але Тімоті Пірсон із Raptor Engineering все одно звільнив її, хоча йому навіть
про це не було сказано. Гуго Ландау розробив специфікацію, а
написав вільну прошивку. Дивіться:
< https: / / www . devever . net / ~ hl / ortega > та < https: / / github . com / meklort / bcm5719-fw >
* FSF свого часу схвалив ThinkPad X200, який продавав [Minifree Ltd ](https://minifree.org ),
який містить Intel ME; bootrom все ще там, як і
але ME переведено в вимкнений стан через Intel Flash
Descriptor, а у
співпроцесор, який з вільною прошивкою можна було би використовувати для багатьох
речей. У
але FSF повністю ігнорує це. Продукт X200, який вони сертифікували,
постачався з попередньо встановленим Libreboot.
* У Р о у і
GbE NVM з нуля. Це необхідно для налаштування
машини, але інакше це двійкові блоб-файли; FSF був би цілком
задоволений сертифікацією апаратного забезпечення в будь-якому випадку, оскільки це були непрограмні
блоби у
файли), але я все одно пішла вперед і З а
легше змінювати регіони дескриптора/gbe для вашого образу мікропрограмного забезпечення. Дивіться:
< https: / / libreboot . org / docs / install / ich9utils . html > - libreboot також має це
* FSF свого часу схвалив ThinkPad T400 з Libreboot, який продавав Minifree. Ця
машина доступна в двох версіях: з графічним процесором ATI+Intel а б о
GPU, можна налаштувати машину так, щоб використовувався будь-який GPU. Якщо буде використовуватися
графічний процесор ATI, для ініціалізації потрібен блоб мікропрограми, хоча драйвер для нього
повністю вільний. *FSF* проігнорувала цей факт і
доки Libreboot не вмикає графічний процесор ATI і
увімкнути. Графічний процесор *Intel* на цій машині має вільний код ініціалізації
від проекту coreboot і о б о х
У
та виключено.
* У с і
яке можна прошивати користувачем (*і
виробником*). FSF вирішила ігнорувати прошивку EC, відповідно до
свого винятку *вторинного процесора* . Дивіться:
< http: / / libreboot . org / faq . uk . html # п р о ш и в к а -ec- в б у д о в а н и й - к о н т р о л е р >
У і
на тому, що ці *додаткові* проблеми свободи були вирішені. Вони цього не
зробили. Є багато інших прикладів цього, але мета цієї статті
не перелічити їх у с і б
Проблеми з FSDG
------------------
2023-04-23 23:08:01 +00:00
< img tabindex = 1 src = "https://av.libreboot.org/firmware.uk.png" / > < span class = "f" > < img src = "https://av.libreboot.org/firmware.uk.png" / > < / span >
2023-03-22 10:02:27 +00:00
FSF підтримує ще один набір критеріїв, які називаються Правилами вільного
розповсюдження системи (GNU FSDG)]
Критерії FSDG відрізняються від RYF, але мають подібні проблеми. FSDG - це
те, чому відповідають схвалені FSF дистрибутиви GNU+Linux. По суті, він забороняє
все пропрієтарне програмне забезпечення, включаючи мікропрограму пристрою. Це може здатися благородним, але
вкрай проблематично в контексті прошивки. Їжа для роздумів:
* Виключення мікропрограмним блобів із ядра linux - це *погано* . Пропрієтарна прошивка
є *також поганою* . Включення їх є мудрішим вибором, якщо також забезпечується сильна освіта
про те, *чому вони погані* (менше свободи). Якщо ви відкриєте їх для
користувача та повідомите йому про це, з'явиться більше стимулів (через просте
нагадування про їх існування) провести зворотне проектування та замінити їх.
* Прошивка *в ядрі вашої О С *хороша* . FSF одночасно дає дозвіл на
апаратне забезпечення *з тими самими блобами прошивки* , якщо прошивка вбудована в
ROM/флеш-пам'ять на пристрої а б о
вбудоване програмне забезпечення знаходиться на окремому ROM/флеш-пам'яті, його все одно можна замінити
користувачем за допомогою зворотного проектування, але тоді вам, ймовірно, доведеться провести деяку пайку
(замінити чіп на картці/пристрої). *Якщо мікропрограма завантажується ядром
О С і
Критерії FSF у
приховувати вбудоване програмне забезпечення, що робить фактичну (програмну) свободу менш імовірною!*
Окрім цього, FSDG здається нормальним. Будь-яка вільна операційна система має в ідеалі не містити
пропрієтарних *драйверів* а б о *застосунків* .
Виробники обладнання полюбляють заштовхувать все в мікропрограмне забезпечення, оскільки їх
продукт часто має поганий дизайн, тому вони пізніше хочуть надати вирішення в
прошивці для налагодження проблемних питань. В с о б і
але вимагає оновлення, надане йому вашим ядром О С
Найбільш поширений приклад пропрієтарної прошивки в Linux для пристроїв wifi.
Це цікавий сценарій використання, з джерельним кодом, тому що його може бути
використано для контрольованого власником *software defined radio* .
Шлях *Debian* є ідеальним. Дистрибутив Debian GNU+Linux повністю вільний
за замовчуванням, і
окремому репозиторії, що містить її. Якщо ви хочете тільки прошивку, тривіально
взяти образи встановлювача з нею доданою, а б о
системи. Вони розповідають вам, як зробити це, що означає, що вони допомогають людям
отримати *деяку* свободу, *замість ніякої* . Це невід'ємно прагматичний
спосіб робити справи, і
Більше контексту, стосовно Debian, доступно в публікації цього блога:
< https: / / blog . einval . com / 2022 / 04 / 19 # firmware-what-do-we-do > - в ньому, автор,
відомий розробник Debian, робить чудовий акцент про прошивку
пристроїв, подібну до статті (Libreboot), яку ви зараз читаєте. Її
варто прочитати! Станом на жовтень 2022 року, Debian проголосував за включення прошивки пристроїв
за *замовчуванням* , в наступних випусках Debian. Раніше Debian виключав таке
мікропрограмне забезпечення, але дозволяв вам його додавати.
OpenBSD майже така сама, але вони розумні в цьому: під час початкового
завантаження, після інсталяції, він повідомляє вам, яке мікропрограмне забезпечення потрібно,
і
програмою `fw_update` , про яку ви можете прочитати тут:
< https: / / man . openbsd . org / fw_update >
*Заборона* прошивки linux конкретно є загрозою свободі в довгостроковій перспективі,
тому що нові користувачі GNU+Linux можуть бути відбиті від використання О С
апаратне забезпечення не працює. Ви можете сказати: просто купіть нове обладнання! Це часто неможливо
для користувачів, і
зворотного проектування.
Більш детальна інформація про мікрокод
=====================================
2023-06-20 06:02:54 +00:00
[Releases after 20230423 will provide separate ROM images with microcode
excluded, alongside the default ones that include microcode.](microcode.md)
2023-03-22 10:02:27 +00:00
Щоб було зрозуміло: бажано, щоб мікрокод був вільним. Мікрокод систем Intel
та AMD *є* пропрієтарним. Факти і
розділу є поширення *фактів* .
Система збірки libreboot тепер дозволяє оновлення мікрокоду *за замовчуванням.*
Відсутність оновлень мікрокоду ЦП є абсолютною катастрофою для стабільності
та безпеки системи.
Що ще гірше, той самий текст, цитований із критеріїв FSF RYF,
насправді конкретно згадує мікрокод. Знову процитую для нащадків:
*"Однак є один виняток для вторинних вбудованих процесорів. Виняток
стосується програмного забезпечення, що постачається всередині допоміжних і
процесорів та FPGA, у
як користувач отримає продукт. Це може включати, наприклад, мікрокод всередині
процесора, мікропрограму, вбудовану в пристрій вводу-виводу, а б о
Програмне забезпечення в таких вторинних процесорах не вважається програмним забезпеченням продукту."*
Тут обговорюється мікрокод, який записується в *mask ROM* на самому
ЦП. Одночасно він не дає О К *оновлень* мікрокоду, які надаються
coreboot а б о
вашу свободу, але старіший мікрокод із більшими помилками, записаний на ROM, є нормальним.
ЦП вже має мікрокод, записаний в mask ROM. Мікрокод налаштовує
логічні вентилі в ЦП, для реалізації набору інструкцій через спеціальні *декодери* ,
які мають фіксовану функцію; неможливо, наприклад, реалізувати набір інструкцій RISCV
на процесорі x86. Для мікрокода можливо тільки
реалізувати x86, а б о *зламаний* x86, і
*зламаним x86* на ЦП Intel/AMD; це неминуче через складність цих
процесорів.
2023-04-16 13:35:18 +00:00
FSF вважає,
2023-03-22 10:02:27 +00:00
що ці оновлення мікрокоду x86 (для Intel/AMD) дозволяють повністю створити новий
ЦП, який принципово відрізняється від x86. Це не правда. Також неправда,
що *всі* інструкції в наборі інструкцій x86 реалізовано за допомогою мікрокоду. У
деяких випадках використовується жорстко закодована схема! Оновлення мікрокоду більше нагадують
крихітні одиничні патчі тут і у
Щоб знову потрапити у
еквівалентом рефакторингу всієї кодової бази. Це *гарячі виправлення* , нічого
більше!
Невиключення цих оновлень призведе до нестабільного/невизначеного стану. Intel
сама визначає, які помилки впливають на які ЦП, і а б о
виправлення в мікрокоді. Виходячи з цього, таке програмне забезпечення, як ядро Linux
може обійти ці помилки/примхи. Крім того, апстрім версії ядра Linux
можуть оновити мікрокод під час завантаження (однак все одно рекомендується робити це
з coreboot для більш стабільної ініціалізації контролера пам'яті а б о
Подібне можна сказати і
Ось кілька прикладів того, як відсутність оновлень мікрокоду вплинула на *Libreboot* ,
змусивши Libreboot обійти зміни, внесені в апстрім coreboot, зміни,
які були *хорошими* і
специфікацій Intel. Libreboot довелося *поламати* coreboot, щоб зберегти деякі
інші функції на деяких Thinkpad GM45/ICH9M:
< https: / / browse . libreboot . org / lbmk . git / plain / resources / coreboot / default / patches / 0012-fix-speedstep-on-x200-t400-Revert-cpu-intel-model_10 . patch ? id = 9938fa14b1bf54db37c0c18bdfec051cae41448e >
< https: / / browse . libreboot . org / lbmk . git / plain / resources / coreboot / default / patches / 0018-Revert-cpu-intel-Configure-IA32_FEATURE_CONTROL-for- . patch ? id = 4b7be665968b67463ec36b9afc7e8736be0c9b51 >
Ці патчі повертають *виправлення помилок* у
інші функції, але лише якщо оновлення мікрокоду виключено. Найбільш
правильним з технічної точки зору рішенням є *не* застосування наведених вище патчів, а
оновлення мікрокоду!
Виберіть свою отруту. Недодавання оновлень є *безвідповідальним* і
марним, оскільки ви все одно отримуєте пропрієтарний мікрокод, ви просто отримуєте
старішу, з більшими помилками, версію натомість!
Ця зміна в політиці проекту зовсім не впливає на вашу свободу,
тому що в іншому випадку ви все одно маєте старіший мікрокод із більшими помилками. Однак він покращує
надійність системи, включаючи оновлення!
Така прагматична політика *перевершує* *догму* , яку колись
доводилося терпіти користувачам Libreboot. Простіше кажучи, проект Libreboot має на меті надати користувачам
якомога більше свободи для їх апаратного забезпечення; так було завжди,
але цей менталітет тепер застосовується до [набагато] більшої кількості обладнання.
Інші міркування
====================
Також Libreboot не покриває суворо: OSHW і
на рівні кремнію була б і
практиці фактичне виготовлення все ще є пропрієтарним і
дизайном ЦП, який компанії можуть використовувати замість того, щоб використовувати пропрієтарний ARM/x86 і
так далі). Подібним чином, Право на ремонт (можливість відремонтувати свій власний пристрій, що
передбачає вільний доступ до схем і
критично важливо вільне програмне забезпечення (Право на хакерство)!
OSHW і
Свободу), критеріями, яких Libreboot дотримувався раніше..
RYF також робить кілька поступок, які зрештою завдають шкоди, наприклад,
політика *програмне забезпечення як схема* , яка, чесно кажучи, є безглуздою. ROM все ще
програмне забезпечення. Був час, коли FSF не вважав програмне забезпечення BIOS проблемою
свободи, лише тому, що воно записане на mask ROM, а *прошито* ; ця
політика FSF ігнорує той факт, що, маючи відповідні навички паяння, легко замінити
автономні мікросхеми mask ROM на сумісну флеш-пам'ять.
Висновки
==========
RYF сам по с о б і *неправильним* , просто має недоліки. Певним чином це правильно, і
якщо його дотримуватися, результат *надає* багато свобод користувачеві, але RYF
повністю ігнорує багато речей, які зараз можливі, включаючи свободи на
апаратному рівні (критерії RYF охоплюють лише *програмне забезпечення* ). Ці вказівки
написані з припущеннями, які все ще були вірними в 1990-х
світ змінився. Проект libreboot повністю відкидає цю політику та натомість
використовує прагматичний підхід.
Висновок, який слід зробити з усього цього, такий:
*Дотримання* критеріїв FSF нічого не шкодить, але ці критерії є дуже
консервативними. Його винятки слід *ігнорувати* та повністю ігнорувати. RYF
більше не відповідає меті, і *більш суворий*
набір інструкцій без у с і х
Як завжди було, Libreboot намагається завжди виходити за межі, але
проект Libreboot не розглядає RYF як *золотий стандарт* . Зараз є
можливі рівні свободи, які вказівки RYF взагалі не охоплюють, а
в деяких випадках навіть активно не заохочують/перешкоджають, оскільки це робить компроміси
на основі припущень, які більше не відповідають дійсності.
Сумна правда: RYF активно заохочує *менше* свободи, не будучи достатньо сміливим.
Він встановлює прапор перемоги та говорить *місію виконано* , незважаючи на те, що
робота *далека* від завершення!
Якщо дотримуватись *з незаперечними винятками* , RYF може в деяких випадках заохочувати
компанії *приховувати* будь-які проблеми зі свободою, які існуюють,
коли це стосується пропрієтарного мікропрограмного забезпечення, яке не працює на центральному процесорі хоста (наприклад, мікропрограмне забезпечення
вбудованого контролера).
Я пропоную написати нові рекомендації, щоб замінити RYF. Ці нові правила
ліквідують у с і *все* програмне забезпечення
було вільним на машині а б о
які відповідають певним стандартам, просто каталогізуйте всі системи у
*базі даних* свого роду (наприклад, h-node.org, але краще), яка точно визначатиме, які
*апаратні* ** і
на ремонт і
стандартної машини; золотим стандартом є вільний *кремній* , як те, над чим
Сем Зелоф та інші працюють зараз.
Цей новий набір критеріїв не повинен намагатися приховати а б о *щось* . Це
має заохочувати людей розширювати рамки та впроваджувати інновації, щоб ми могли мати
набагато *більше* свободи, ніж зараз можливо. Необхідність є матір'ю всіх
винаходів, а
обчисленні.
Н е
приблизно так: каталог свободи. І а
лише на програмному забезпеченні!
Інші ресурси
===============
Повідомлення в блозі RYF Аріадни Конілл
------------------------------
Аріадна Конілл, голова групи безпеки *Alpine Linux* , опублікувала дуже серйозну
статтю про RYF, у *цією* статтею.
Однак Аріадна докладно розглядає кілька інших прикладів проблем із
критеріями FSF RYF; наприклад, йдеться про продукт *Novena* від
Bunnie.
Варто прочитати! Посилання:
< https: / / ariadne . space / 2022 / 01 / 22 / the-fsfs-relationship-with-firmware-is-harmful-to-free-software-users / >
