purge remaining stragglers

fsf has never had any say over libreboot; i have. it was all me, but i used to be part of their cult. i no longer am. this is housecleaning. Signed-off-by: Leah Rowe <info@minifree.org>
2024-05-07 19:44:53 +01:00 · 2024-05-07 19:44:53 +01:00 · cb8dbd0f38
parent 96e51ca06e
commit cb8dbd0f38
11 changed files with 27 additions and 2931 deletions
--- a/site/contrib.md
+++ b/site/contrib.md
@ -196,33 +196,13 @@ systems.
 Joshua Gay
 ----------
-Joshua is former FSF staff.
+Joshua was in a position during 2014-2016 to help promote Libreboot in the
 media, in his capacity working for the employer he worked for at the time;
 I credit him specifically. Joshua was one of Libreboot's earliest supporters.
-Joshua helped with the early founding of the Libreboot project, in his capacity
+He made sure everyone knew what I was doing, and he taught me a *lot* about
-(at that time) as the FSF's licensing and compliance manager. It was his job to
+licensing; many of Libreboot's practises today are still based on his lessons,
-review products sent into to the FSF for review; the FSF has a certification
+such as the pitfalls of GPL compliance and how to really audit everything.
 program called *Respects Your Freedom* (RYF) where the FSF will promote your
 company's products if it comes with all Free Software.
 I, Leah Rowe, was initially just selling ThinkPad X60 laptops with regular
 coreboot on them, and this included CPU microcode updates. At the time, I didn't
 think much of that. Joshua contacted me, in his capacity at the FSF, and asked
 if I would be interested in the FSF's RYF program; I was very surprised that the
 FSF would take me seriously, and I said yes. This is what started the early
 work on Libreboot. Joshua showed me all the problems my products had, and from
 that, the solution was clear:
 Joshua used his media connections at the FSF to heavily promote my work, and
 on December 13th, 2013, the Libreboot project was born (but not called that).
 Joshua made sure that everyone knew what I was doing!
 A few months later, the name *Libreboot* was coined, and the domain name
 *libreboot.org* was registered. At that point, the Libreboot project (in early
 2014) was officially born. Once again, Joshua provided every bit of help he
 could, heavily promoting the project and he even wrote this article on the FSF
 website, announcing it:
 <https://web.archive.org/web/20171222063358/https://www.fsf.org/blogs/licensing/replace-your-proprietary-bios-with-libreboot>
 Klemens Nanni
 -------------
@ -233,55 +213,17 @@ libreboot, and several tweaks to the build system.
 Lisa Marie Maginnis
 -------------------
-Lisa is a former sysadmin at the Free Software Foundation. In the early days of
+Lisa was one of Libreboot's early contributors to Libreboot. She personally
-the project, she provided Leah with a lot of technical advice. She initially
+helped me set up a lot of the early infrastructure, including things like IRC,
-created Libreboot IRC channel, when Leah did not know how to
+mailing list and so on. She provided a lot of technical guidance, while working
-use IRC, and also handed +F founder status to Leah for the channel. As an FSF
+in a sysadmin job for a certain free software organisation; she was both a
-sysadmin, it was Lisa's job to maintain a lot of the infrastructure used by
+mentor and a friend.
 Libreboot; at the time, mailing lists on the Savannah website were used by
 the Libreboot project. When Paul Kocialkowski was a member of the project in
 2016, she helped him get help from the FSF; he was the leader of the Replicant
 project at the time, which had funding from the FSF, and the FSF authorized him
 to use some of that funding for his work on Libreboot, thanks to Lisa's
 encouragement while she worked at the FSF.
-Lisa also stepped in when Leah Rowe missed her LibrePlanet 2016 talk. Leah was
+She got me in touch with a lot of people, and at one point was instrumental in
-scheduled to do a talk about Libreboot, but didn't show up in time. Lisa, along
+helping Paul Kocialkowski secure funding to work on the Veyron Speedy boards
-with Patrick McDermott (former Libreboot developer, who was present at that
+in Libreboot, e.g. ASUS Chromebook C201PA - at the time, this was using
-conference) did the talk in Leah's place. The talk was never recorded, but the
+Google's own Depthcharge payload, which you can find in 2016 Libreboot
-Free Software Foundation has these photos of that talk on their LibrePlanet
+releases.
 website (the woman with the blue hair is Lisa, and the long-haired dude with the
 moustache is Patrick):
 <http://web.archive.org/web/20170319043913/https://media.libreplanet.org/u/libreplanet/m/session-02-c-mws-png-libreplanet-2016-sessions/>
 <http://web.archive.org/web/20170319043915/https://media.libreplanet.org/u/libreplanet/m/session-02-c-wide-png-libreplanet-2016-sessions/>
 Fun fact: Patrick is also the lead developer of ProteanOS, an FSF-endorsed
 embedded OS project: <http://proteanos.com/> (uses BusyBox and Linux-libre)
 Leah Rowe ran *2* LibrePlanet workshops; one in 2015 and another in 2016, while
 visiting Boston, MA, USA on both occasions to attend these conferences. These
 workshops were for Libreboot installations. People came to both workshops, to
 have Libreboot installed onto their computers. As FSF sysadmin, at that time,
 Lisa provided all of the infrastructure and equipment used at those workshops.
 Without her help, those workshops would have not been possible.
 When the ASUS KGPE-D16 mainboard (high-end server board) was ported to Libreboot,
 Leah, working with Timothy Pearson (the one who ported it), shared patches back
 and forth with Lisa around mid 2016, mostly raminit patches, to get the board
 running at the FSF offices. This work ultimately lead to a most wonderful
 achievement:
 The FSF and GNU websites now run on
 Librebooted ASUS KGPE-D16 based servers, on a fully free GNU+Linux distro. This
 means that the FSF now has full software freedom for their hosting infrastructure.
 The FSF also provides access to this infrastructure for many other projects
 (besides GNU projects).
 Lisa was a strong supporter of Libreboot in the very early days of the project,
 and her contributions were invaluable. I, Leah Rowe, owe her a debt of gratitude.
 Lorenzo Aloe
 ------------
@ -316,10 +258,6 @@ relating to the [Intel Management Engine](../faq.md#intelme), in addition
 to making several improvements to the build system in libreboot. **Former
 libreboot project maintainer.**
 In 2016, Leah Rowe ran a Libreboot installation workshop at the FSF's
 LibrePlanet conference. Working alongside Leah, Patrick helped run the workshop
 and assisted with installing Libreboot onto people's machines.
 Paul Kocialkowski
 -----------------
--- a/site/contrib.uk.md
+++ b/site/contrib.uk.md
@ -1,467 +0,0 @@
 ---
 title: Учасники проекту
 x-toc-enable: true
 ...
 У цьому списку не обов'язково вказується, хто зараз працює над проектом,
 але в ньому вказано людей, які зробили значний внесок у проект.
 Якщо ми забули вас тут згадати, повідомте нам, і ми вас додамо. (або якщо
 ви не хочете, щоб вас згадували, повідомте нас, і ми видалимо ваш
 запис)
 Інформацію про те, хто працює над libreboot і як працює проект, можна
 знайти на цій сторінці: [who.md](who.md)
 Ви можете дізнатися історію проекту libreboot, просто прочитавши цю сторінку.
 Тут докладно розповідається про всі основні внески в проект і
 загалом про те, як створювався проект (і хто допоміг його створити).
 Лія Роу
 ---------
 **Засновник проекту Libreboot, а зараз провідний розробник** Лія
 працює над усіма аспектами libreboot, такими як:
 * Загальне керівництво. Лія обробляє всі зовнішні внески до libreboot,
  переглядає пул реквести, має справу із звітами про помилки, делегує завдання, коли це необхідно
  або бажано. Лія контролює серверну інфраструктуру libreboot.org, розміщену
  в її лабораторії.
 * Лія має останнє слово щодо всіх рішень, беручи внесок через обговорення з
  представниками громадськості, переважно на IRC. Лія контролює випуски libreboot
  і загалом підтримує проект. Без Лії не було би Libreboot!
 * Система збірки (lbmk, скорочення від libreboot Make). Це автоматизована
  система збирання, яка лежить в серці libreboot; він завантажує, патчить, налаштовує
  та компілює відповідні компоненти, такі як coreboot, GRUB, і генерує образи ROM
  libreboot, які ви можете знайти в архівах випусків.
 * Апстрім робота над coreboot, коли необхідно (та іншими проектами, які libreboot
  використовує). Це також означає роботу з людьми поза межами проекту libreboot,
  щоб об'єднати виправлення (між іншим) в апстрім проектах,
  які libreboot використовує
 * Надання підтримки користувачів на IRC
 Калеб Ла Гранж
 ---------------
 **Вторинний розробник, номер два для Лії.** Калеб - розробник libreboot на повний робочий день
 з вузьким фокусом. Калеб зосереджується на кількох напрямках розвитку:
 * Система побудови. Калеб відповідає за вдосконалення та виправлення системи побудови libreboot Make.
 Зокрема, управління бінарними блобами, автоматизація та відтворюваність. 
 * Апаратна модифікація. Калеб має пристрасть до переробки апаратного забезпечення; паяння,
 розпаювання, та тестування libreboot на отриманому обладнанні.
 * Перенесення плати. Все, що підтримується в Coreboot, можна перенести на libreboot, Калеб
 перевірить і перенесе будь-яку плату, до якої зможе потрапити. Крім того, будь-хто може
 зв'язатись з Калебом, щоб створити образи libreboot для тестування на своїй платі.
 * Документація. Калеб активно веде документацію щодо зазначених вище сфер
 інтересу. Додатково, Калеб відповідає за посібники з розбирання з власними
 малюнками та діаграмами для кількох плат.
 * Підтримка користувачів. Калеб активний в irc і готовий допомогти будь-якому користувачеві, який зацікавлений в
 використанні libreboot або потребує допомоги.
 * Цілі проекту. Калеб співпрацює з Лією над визначенням цілей проекту.
 Лія має останнє слово в кожному рішенні.
 Зовнішні проекти
 ================
 Проект Coreboot
 ----------------
 Без coreboot проект libreboot був би просто неможливий.
 Людей і компаній, які працюють над coreboot, багато, і вони роблять
 проект libreboot таким, яким він є. Проект libreboot активно використовує coreboot
 для ініціалізації обладнання.
 GRUB
 --------
 GRUB - це завантажувач, який використовується libreboot. Само собою зрозуміло, що
 розробники GRUB стимулюють libreboot своєю роботою.
 SeaBIOS
 -------
 Прошивка libreboot надає SeaBIOS як опцію корисного навантаження. SeaBIOS забезпечує
 застарілу реалізацію BIOS x86.
 U-Boot
 ------
 Libreboot використовує U-Boot як корисне навантаження coreboot на ноутбуках
 ARM Chromebook з підтримкою coreboot.
 Внески в алфавітному порядку
 ============================
 Алісса Розенцвейг
 -----------------
 Переключила веб-сайт на використання розмітки замість рукописного HTML та користувацького
 PHP. **Колишній супроводжувач проекту libreboot (системний адміністратор libreboot.org).**
 Алісса написала оригінальний генератор статичних сайтів (скрипти `sh`, що перетворюють
 markdown в html, через pandoc) для libreboot.org. Цей генератор статичних сайтів
 був значно змінений і відгалужений Лією Роу у формальний проект:
 <https://untitled.vimuser.org/> (untitled - це робота Лії, а не Алісси, але вона базується на
 оригінальній роботі Аліси над генератором статичних сайтів, який раніше використовував Libreboot;
 веб-сайт Libreboot тепер створено за допомогою Untitled)
 Альпер Небі Ясак
 ----------------
 Надав інтеграцію системи збірки та документацію для використання
 U-Boot в якості корисного навантаження, та початкові порти Libreboot деяких ARM Chromebook
 виходячи з того.
 Альпер також займається розробкою на U-Boot, напр. продовжив майже завершений
 порт плати `gru-kevin` і об'єднав його з апстрімом.
 Артур Хейманс
 --------------
 Об'єднав патч із coreboot у libreboot, дозволяючи режимам живлення C3 та C4
 правильно працювати на ноутбуках GM45. Це була давня проблема до внеску
 Артура. Артур також виправив розмір відеопам'яті на i945 на системах
 GM45, що дозволило максимально розподілити VRAM для вбудованих графічних процесорів
 у цих системах, ще одна давня проблема в libreboot.
 Артур також працював над системою збірки Libreboot, коли він був учасником
 проекту. Він досі працює над coreboot, і Libreboot отримує велику
 користь від його роботи. Його внесок у проект coreboot і Libreboot
 неоціненний.
 Володимир Сербіненко
 -------------------
 Перенес багато thinkpad, які підтримуються в libreboot, на coreboot, а
 також зробив багато виправлень у coreboot, які принесли користь проекту libreboot.
 Володимир написав багато вихідного коду ініціалізації відео, який використовується різними
 платформами Intel у Libreboot, під час прошивки (зараз переписаний
 іншими в Ada, для libgfxinit в coreboot, але спочатку він був написаний на
 C і включений безпосередньо в coreboot; libgfxinit є субмодуль третьої сторони).
 Демієн Замміт
 -------------
 Підтримує порт coreboot Gigabyte GA-G41M-ES2L, інтегрований у
 libreboot. Також працює над іншим апаратним забезпеченням на користь
 проекту libreboot.
 Демієн не працював безпосередньо над самим Libreboot, але він багато працював з
 Лією Роу, інтегруючи патчі та нові порти плати в Libreboot на основі
 попередньої роботи Демієна над coreboot.
 Денис Каріклі
 -------------
 На основі роботи, виконаної Пітером Стюджем, Володимиром Сербіненко та іншими
 в проекті coreboot, вдалось налагодити нативну ініціалізацію графіки для роботи
 на ThinkPad X60, що дозволяє підтримувати її в libreboot. Денис дав
 багато порад і допоміг створити проект libreboot.
 Денис був наставником Лії Роу в ранні дні, коли вона заснувала проект
 Libreboot. Багато прийнятих рішень, особливо щодо системи збірки
 Libreboot (lbmk), були натхненні розмовами з Денисом.
 Денис навчив Лію про регістри, які використовуються графічним процесором Intel для керування підсвічуванням.
 В ранні дні, ноутбуки ThinkPad X60 та T60 в Libreboot не мали працюючого
 контроля підсвічуванням, тому яскравість завжди була 100%. За допомогою Дениса,
 Лія змогла налаштувати керування підсвічуванням шляхом зворотньої розробки
 правильних значень для запису в ці регістри. На основі цього в coreboot
 було написано просте виправлення; однак виправлення перезаписувало безпосередньо регістр
 і не працювало з елементами керування яскравістю на основі ACPI. Інші в coreboot
 пізніше вдосконалили його, змусивши елементи керування підсвічуванням на основі ACPI працювати належним чином, на основі цієї
 попередньої роботи.
 Джерун Квінт
 ------------
 Додав кілька виправлень до документації libreboot, пов'язаної зі
 встановленням Arch з повним дисковим шифруванням у системах libreboot.
 Джошуа Гей
 ----------
 Джошуа колишній співробітник FSF.
 Джошуа допоміг із раннім заснуванням проекту Libreboot, будучи
 (на той час) менеджером з ліцензування та відповідності FSF. Його роботою було
 переглядати продукти, надіслані до FSF для перевірки; FSF має програму
 сертифікації, під назвою *Поважає Вашу Свободу* (Respects Your Freedom), за якою FSF рекламуватиме
 продукти вашої компанії, якщо вони постачаються з усім вільним програмним
 забезпеченням.
 Я, Лія Роу, спочатку просто продавала ноутбуки ThinkPad X60 із звичайним
 coreboot, і це включало оновлення мікрокоду ЦП. У той час
 я не дуже про це думала. Джошуа зв'язався зі мною, в своїх повноваженнях FSF, і спитав,
 чи зацікавить мене програма RYF FSF; Я була дуже здивована, що FSF
 сприйме мене серйозно, і я сказала так. Саме з цього почалася рання робота
 над Libreboot. Джошуа показав мені всі проблеми з моїми продуктами, і з
 цього, рішення було очевидним:
 Необхідно, щоб існував проект із повністю вільною версією coreboot без будь-яких
 бінарних блобів. У той час (і це актуально й сьогодні) coreboot не був
 повністю вільним програмним забезпеченням і за замовчуванням постачався з двійковими блобами. Зокрема,
 оновлення мікрокоду ЦП включено за замовчуванням на всіх машинах x86. Працюючи
 з Джошуа, я створила повністю вільну версію coreboot.
 Спочатку він не називався Libreboot, і робота була призначена виключно для моєї
 компанії (на той час вона називалася Gluglug), яку просувала FSF.
 Джошуа використовував свої медійні зв'язки в FSF, щоб активно рекламувати мою роботу, і
 13 грудня 2013 року народився проект Libreboot (але не названий так).
 Джошуа переконався, щоб всі знали, що я роблю!
 Через кілька місяців було створено назву *Libreboot* і зареєстровано доменне ім'я
 *libreboot.org*. У цей момент офіційно народився проект Libreboot (на початку
 2014 року). Знову Джошуа надав всю можливу допомогу,
 активно просуваючи проект, і навіть написав цю статтю на веб-сайті FSF
 оголосивши про це:
 <https://web.archive.org/web/20171222063358/https://www.fsf.org/blogs/licensing/replace-your-proprietary-bios-with-libreboot>
 Ендрю Роббінс
 --------------
 Працював над великими частинами старої системи збірки Libreboot і пов'язаною документацією.
 Ендрю приєднався до проекту Libreboot як штатний розробник у червні 2017,
 до моменту свого відходу в березні 2021 року.
 Я, Лія Роу, дуже вдячна Ендрю Роббінсу за його численні внески
 протягом багатьох років.
 Клеменс Нанні
 -------------
 Внесено багато виправлень і покращень у конфігурацію GRUB, яка використовується в
 libreboot, а також кілька змін у системі збірки.
 Ліза Марі Магінніс
 -------------------
 Ліза - колишній системний адміністратор Free Software Foundation. На перших днях
 проекту вона давала Лії багато технічних порад. Спочатку вона створила
 IRC-канал Libreboot, коли Лія не знала, як користуватися
 IRC, а також передала +F статус засновника для каналу. Як системний
 адміністратор FSF, роботою Лізи було підтримувати велику частину інфраструктури,
 яку використовує Libreboot; на той час списки розсилки на веб-сайті Savannah
 використовувалися проектом Libreboot. Коли Пол Коціалковскі був
 учасником проекту в 2016 році, вона допомогла йому отримати допомогу від FSF; на той час він був
 керівником проекту Replicant, який фінансував FSF, і FSF дозволив
 йому використати частину цього фінансування для його роботи над Libreboot, завдяки Лізи
 підтримці, коли вона працювала у FSF.
 Ліза також втрутилася, коли Лія Роу пропустила виступ на LibrePlanet 2016. Лія мала
 виступити з доповіддю про Libreboot, але не з'явилася вчасно. Ліза разом
 із Патріком Макдермоттом (колишнім розробником Libreboot, який був присутній
 на тій конференції) виступили замість Лії. Розмова ніколи не була записана, але
 Фонд вільного програмного забезпечення має ці фотографії цієї розмови на веб-сайті LibrePlanet
 (жінка з блакитним волоссям - Ліза, а довговолосий хлопець із вусами -
 Патрік):
 <http://web.archive.org/web/20170319043913/https://media.libreplanet.org/u/libreplanet/m/session-02-c-mws-png-libreplanet-2016-sessions/>
 <http://web.archive.org/web/20170319043915/https://media.libreplanet.org/u/libreplanet/m/session-02-c-wide-png-libreplanet-2016-sessions/>
 Цікавий факт: Патрік також є провідним розробником ProteanOS, проекту вбудованої
 ОС, схваленого FSF: <http://proteanos.com/> (використовує BusyBox і Linux-libre)
 Лія Роу провела *2* семінари LibrePlanet; один у 2015 році та інший у 2016 році,
 відвідуючи Бостон, Массачусетс, США в обох випадках для участі в цих конференціях. Ці
 семінари стосувалися встановлення Libreboot. Люди приходили на обидва семінари, щоб
 встановити Libreboot на свої комп'ютери. Як системний адміністратор FSF, на той час,
 Ліза забезпечила всю інфраструктуру та обладнання, яке використовувалося на цих семінарах.
 Без її допомоги ці майстер-класи були б неможливими.
 Коли материнська плата ASUS KGPE-D16 (серверна плата високого класу) була перенесена на Libreboot,
 Лія, працюючи з Тімоті Пірсоном (той, хто її переніс),
 приблизно в середині 2016 року поділилася з Лізою виправленнями, в основному виправленнями raminit, щоб отримати плату, яка працює в офісах FSF. Ця робота
 зрештою призвела до чудового досягнення:
 Веб-сайти FSF і GNU тепер працюють на, з встановленим Libreboot,
 заснованих на ASUS KGPE-D16 серверах, на повністю вільному GNU+Linux дистрибутиві. Це
 означає, що FSF тепер має повну свободу програмного забезпечення для своєї
 інфраструктури хостингу.
 FSF також надає доступ до цієї інфраструктури для багатьох інших проектів
 (крім проектів GNU).
 Ліза була сильною прихильницею Libreboot на перших днях проекту,
 і її внесок був неоціненним. Я, Лія Роу, у боргу перед нею.
 Lorenzo Aloe
 ------------
 Provided hardware testing for the [Dell OptiPlex 9020](docs/hardware/dell9020.md),
 also provided testing for proxmox with GPU passthrough on Dell Precision T1650,
 confirming near-native performance; with this, you can boot operating systems
 virtually natively, performance-wise, on a Libreboot system in cases where
 that OS is not natively supported.
 All round good guy, an honest and loyal fan.
 Маркус Мьоллер
 --------------
 Зробив логотип libreboot.
 Nicholas Chin
 -------------
 [Ported Dell Latitude E6400 to Libreboot](news/e6400.md).
 Патрік "П. Дж." Макдермотт
 ---------------------------
 Патрік також провів багато досліджень і написав розділ поширених запитань libreboot,
 пов'язаний із [Intel Management Engine](../faq.md#intelme), а також зробив кілька покращень у
 системі збірки libreboot. **Колишній супроводжувач проекту
 libreboot.**
 У 2016 році Лія Роу провела семінар зі встановлення Libreboot на конференції FSF
 LibrePlanet. Працюючи разом з Лією, Патрік допомагав вести семінар
 та допомагав установлювати Libreboot на комп'ютери людей.
 Пітер Стюдж
 -----------
 Допоміг написати [розділ поширених запитань про DMA](../faq.md#hddssd-firmware), та надав
 загальні поради на перших днях проекту. У той час Пітер був розробником coreboot
 і головним розробником проекту *libusb* (який flashrom
 активно використовує).
 NOTE: Libreboot standardises on [flashprog](https://flashprog.org/wiki/Flashprog)
 now, as of 27 January 2024.
 Пітер також написав утиліту *bucts*, яка використовується для встановлення біта Top Swap
 (TS) для керування резервним копіюванням (BUC) на ноутбуках i945, таких як ThinkPad X60/T60, яка є корисною для
 обхідного шляху для прошивки Libreboot без використання зовнішнього обладнання; на цій машині,
 з Lenovo BIOS, можна перепрошити все, крім головного завантажувального
 блоку, але платформи Intel мають 2 завантажувальні блоки, і ви вказуєте, який із них
 використовувати, встановленням біта TS. Потім ви завантажуєтеся лише з одним прошитим завантажувальним блоком
 (завантажувальним блоком проекту coreboot на цій машині), а потім скидаєте
 bucts перед повторною прошивкою ROM, щоб прошити основний завантажувальний блок. Libreboot
 розміщує копію його роботи, оскільки його веб-сайт, на якому розміщено bucts,
 більше не відповідає.
 Пол Коціалковський
 -----------------
 Переніс ноутбуки Chromebook на основі ARM (Rockchip RK3288 SoC) до
 libreboot. Також один із головних розробників [Replicant](http://www.replicant.us/).
 Пол Менцель
 -----------
 Дослідив та виправив помилку в coreboot на ThinkPad X60/T60, яку виявляло
 ядро Linux 3.12 і новіших версій, через яку прискорення 3D не
 працювало, а відео загалом ставало нестабільним. Проблема полягала в тому, що
 coreboot під час ініціалізації відеочіпсета Intel, відображав *GTT Stolen Memory* в
 не тому місці, оскільки код базувався на коді ядра, а в ядрі Linux
 була така сама помилка. Коли Linux це виправив, він виявив ту саму помилку в coreboot.
 Пол працював над цим із Libreboot,
 періодично надсилаючи патчі для тестування, доки помилку не було виправлено
 в coreboot, а потім допоміг ій інтегрувати виправлення в libreboot.
 Riku Viitanen
 -------------
 Added support for HP Elite 8200 SFF desktop PC to Libreboot. You can read
 about this in the hardware page:
 [HP Elite 8200 SFF](docs/hardware/hp8200sff.md)
 Стів Шентон
 -------------
 Стів виконав першу роботу зі зворотньої розробки Intel Flash Descriptor, який використовується
 на машинах ICH9M, таких як ThinkPad X200. Він створив структуру C, що визначає (використовуючи
 бітові поля в C) цю область дескриптора. За допомогою деяких хитрих трюків він зміг
 виявити існування біта в дескрипторі для *вимкнення* Intel ME
 (management engine) на цих платформах.
 Його початкове підтвердження концепції визначило лише дескриптор, і зробило би це:
 * Читання дескриптора за замовчуванням і регіонів GbE з ROM Lenovo X200 (прошивка
  за замовчуванням, не coreboot)
 * Вимкнення ME, встановивши 2 біти в дескрипторі
 * Вимкнення регіона ME
 * Переміщення дескриптора+GbE (загалом 12КБ) поруч
 * Виділення решти флеш-пам'яті для регіону BIOS
 * На основі цього створено 12КБ регіон дескриптор+область GBE для вставки
  в образ ROM coreboot.
 У перші дні, до того, як Libreboot підтримував платформи GM45+ICH9M, такі як
 ThinkPad X200/T400, ви могли використовувати ці машини, але щоб уникнути
 Intel ME, вам доводилося виконувати прошивку без області дескриптора. У ті часи це працювало нормально,
 тому що ME обробляв лише TPM та AMT на цих машинах, і система
 працювала нормально, але Intel Flash Descriptor також обробляє область Intel GbE NVM
 у флеш-пам'яті, яка використовується для інтерфейсу Intel Gigabit Ethernet.
 Отже, ви або мали Intel ME, або не підтримували ethernet. Стів зрозумів, як
 вимкнути Intel ME за допомогою 2 бітів перемикання в дескрипторі, а також як видалити область
 Intel ME з флеш-пам'яті.
 Ґрунтуючись на його дослідженні, я, Лія Роу, працюючи разом зі Стівом, також виконала зворотню розробку
 області Intel GbE NVM (енергонезалежна пам'ять) у
 завантажувальній флеш-пам'яті. Цей регіон визначає параметри конфігурації для вбудованої мережевої карти Intel
 GbE, якщо присутня.
 На основі цього я змогла взяти початкове підтвердження концепції та написати
 утиліту `ich9gen`, яка генерує Intel Flash Descriptor та регіон GbE NVM,
 з нуля, без визначення регіону Intel ME. Саме цей інструмент,
 інструмент `ich9gen`, використовує Libreboot для надання образів ROM для GM45+ICH9M
 платформ (таких як ThinkPad X200/T400/T500/W500), із повнофункціональним
 дескриптором та функціональним Gigabit Ethernet, але *без* необхідності мікропрограми Intel
 Management Engine (ME), що робить ці машини *вільними* (ME
 повністю вимкнено, коли ви використовуєте образ дескриптора+gbe, створене `ich9gen`).
 З *моїм* інструментом `ich9gen` (інструмент Стіва називався `ich9deblob`), вам більше
 не потрібен був дамп оригінальної мікропрограми Lenovo BIOS! Я не могла би написати цей інструмент
 без первинного підтвердження концепції Стіва. Я працювала з ним
 протягом багатьох місяців. Вся GM45+ICH9M підтримка (X200, T400 і так далі) в
 Libreboot стала можливою завдяки його роботі у 2014 році.
 Тімоті Пірсон
 ---------------
 Перенес плату ASUS KGPE-D16 до coreboot для компанії Raptor
 Engineering, генеральним директором якої є Тімоті.
 Тімоті підтримує цей код у coreboot, допомогаючи проекту,
 з його інтеграцією з libreboot. Контактні
 дані цієї людини є на сайті raptor.
 **Підтримку D16 було припинено 19 листопада 2022 року. Ви все ще можете використовувати
 старіші версії Libreboot, і старіші випуски.**
 Swift Geek
 ----------
 Додав патч для ich9gen для створення дескрипторів розміром 16MiB.
 Після цього Swift Geek повільно почав долучатися, поки не став розробником на повний
 робочий день. Внески Swift Geek насправді ніколи не були у формі *коду*,
 але те, що йому не вистачало в коді, він компенсував чудовою підтримкою як для користувачів,
 так і для інших розробників, допомагаючи іншим дізнатися більше про технології на
 низькому рівні.
 Коли Swift Geek був учасником проекту, його роль здебільшого полягала в
 наданні підтримки користувачам (на каналі IRC) і проведенні досліджень. Swift Geek знає
 багато про апаратне забезпечення. Swift Geek також зробив деяку апстрім розробку GRUB.
 Swift Geek неодноразово надавав технічні поради Лії Роу
 та допоміг їй покращити її навички паяння, а також навчив її
 деяким навичкам ремонту, до того моменту, коли вона тепер може виправляти більшість несправностей
 на материнських платах ThinkPad (під час перегляду схем та бордв'ю).
 Swiftgeek залишив проект у березні 2021 року. Я, Лія Роу, бажаю його всього найкращого в його
 починаннях і дуже вдячна за його численні внески протягом багатьох
 років.
 vitali64
 --------
 Додав підтримку cstate 3 на macbook21, що забезпечує тривалий термін служби батареї
 та нижчу температуру процесора під час простою. vitali64 на irc
--- a/site/footer.uk.include
+++ b/site/footer.uk.include
@ -8,7 +8,7 @@
 * [Ліцензія](/license.md)
 * [Шаблон](/template-license.uk.md)
 * [Логотип](/logo-license.uk.md)
-* [Автори](/contrib.uk.md)
+* [Автори](/contrib.md)
 -------------------------------------------------------------------------------
--- a/site/news/10.md
+++ b/site/news/10.md
--- a/site/news/MANIFEST
+++ b/site/news/MANIFEST
@ -6,7 +6,6 @@ libreboot20240126.md
 x201.md
 hp820g2.md
 audit4.md
 10.md
 libreboot20231106.md
 libreboot20231101.md
 libreboot20231021.md
--- a/site/news/audit3.md
+++ b/site/news/audit3.md
@ -156,7 +156,7 @@ are also repeated below but in more detail:
 * Don't use the `-B` option in make commands.
 * Where no-microcode ROM images are provided, ensure that the ROM hashes still
  match when running the vendor inject script. This is only useful on the
-  Dell Latitude E6400, which is otherwise FSDG-compatible but (in Libreboot)
+  Dell Latitude E6400, which is otherwise blob-free but (in Libreboot)
  comes with or without microcode updates, and with or without the Nvidia VGA
  ROM (handled by vendor inject/download scripts) for dGPU variants. Verification
  previously failed, under certain conditions, when inserting that VGA ROM.
@ -198,8 +198,8 @@ are also repeated below but in more detail:
  spaces in them.
 * Don't support removal of microcode (during release time) on untested targets.
  Set `microcode_required="y"` on most boards, but leave it set to `"n"` on
-  platfroms such as GM45 (ThinkPad X200/T400, Dell E6400, etc); anything FSDG
+  platfroms such as GM45 (ThinkPad X200/T400, Dell E6400, etc); anything that
-  compatible, in other words.
+  can run without blobs, in other words.
 * Improved Dell Latitude E6400 support; the same image now provides iGPU and
  dGPU support, since it's SeaBIOS-only anyway, so a VGA ROM is inserted into
  the same ROM that also enables libgfxinit, enabling the Intel or Nvidia GPU
--- a/site/news/libreboot20231021.md
+++ b/site/news/libreboot20231021.md
@ -303,7 +303,7 @@ logs, combined:
 * Don't use the `-B` option in make commands.
 * Where no-microcode ROM images are provided, ensure that the ROM hashes still
  match when running the vendor inject script. This is only useful on the
-  Dell Latitude E6400, which is otherwise FSDG-compatible but (in Libreboot)
+  Dell Latitude E6400, which is otherwise blob-free but (in Libreboot)
  comes with or without microcode updates, and with or without the Nvidia VGA
  ROM (handled by vendor inject/download scripts) for dGPU variants. Verification
  previously failed, under certain conditions, when inserting that VGA ROM.
@ -345,8 +345,8 @@ logs, combined:
  spaces in them.
 * Don't support removal of microcode (during release time) on untested targets.
  Set `microcode_required="y"` on most boards, but leave it set to `"n"` on
-  platfroms such as GM45 (ThinkPad X200/T400, Dell E6400, etc); anything FSDG
+  platfroms such as GM45 (ThinkPad X200/T400, Dell E6400, etc); anything that
-  compatible, in other words.
+  can be blob-free, in other words.
 * Improved Dell Latitude E6400 support; the same image now provides iGPU and
  dGPU support, since it's SeaBIOS-only anyway, so a VGA ROM is inserted into
  the same ROM that also enables libgfxinit, enabling the Intel or Nvidia GPU
--- a/site/news/policy.de.md
+++ b/site/news/policy.de.md
@ -176,365 +176,3 @@ exist, for example, the work done by Sam Zeloof and the Libre Silicon project:
 * <https://libresilicon.com/>
 (Sam literally makes CPUs in his garage)
 Problems with RYF criteria
 ==========================
 Libreboot previously complied with FSF RYF criteria, but it now adheres to a
 much more pragmatic policy aimed at providing more freedom to more people, in a
 more pragmatic way. You can read those guidelines by following this URL:
 * FSF Respects Your Freedom (RYF) guidelines:
 <https://web.archive.org/web/20220604203538/https://ryf.fsf.org/about/criteria/>
 Put simply, the RYF guidelines pertain to commercial products, with the
 stipulation that they must not contain proprietary software, or known privacy
 issues like backdoors.
 The total exclusion of all proprietary software is currently not feasible. For
 example, proprietary SDR firmware in WiFi chipsets, firmware in AHCI devices
 like HDDs or SSDs, and the like. The FSF RYF guidelines state the following
 exception, to mitigate this fact:
 * "However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software."
 *This should be
 rejected on ideological grounds*. The rest of libreboot's policy and overall
 ideology expressed, in this article, will be based largely on that rejection.
 The definition of *product software* is completely arbitrary; software is
 software, and software should always be *libre*. Instead of making such
 exceptions, more hardware should be encouraged, with help given to provide as
 much freedom as possible, while providing education to users about any pitfalls
 they may encounter, and encourage freedom at all levels. When an organisation
 like the FSF makes such bold exceptions as above, it sends the wrong message,
 by telling people essentially to sweep these other problems under the rug, just
 because they involve software that happens to run on a "secondary processor".
 If the software is possible to update by the user, then it should be libre,
 regardless of whether the manufacturer *intended* for it to be upgraded or not.
 Where it really *isn't* possible to update such software, proprietary or not,
 advice should be given to that effect. Education is important, and the FSF's
 criteria actively discourages such education; it creates a false hope that
 everything is great and wonderful, just because the software on one arbitrary
 level is all perfect.
 This view of the FSF's, as expressed in the quoted paragraph, assumes that
 there is primarily *one* main processor controlling your system. On many
 modern computers, this is *no longer true*.
 Libre *software* does not exist in a vacuum, but we had less freedom in the
 past, especially when it came to hardware, so *software* was our primary focus.
 The ability to study, adapt, share and use/re-use software freely is important,
 but there is a lot of nuance when it comes to *boot firmware*, nuance which is
 largely non-existent outside of firmware development, or kernel development.
 Most typical application/system software is high level and portable, but boot
 firmware has to be written for each specific machine, and due to the way
 hardware works, there are many trade-offs made, including by the FSF when
 defining what standards should apply *in practise*.
 The fact that almost nobody talks about the EC firmware is *because* of the
 Respects Your Freedom certification. In reality, the EC firmware is crucial
 to user freedom, and ought to be free, but it is completely disregarded by
 the FSF as *part of the hardware*. This is wrong, and the FSF should actively
 encourage people to free it, on every laptop!
 Other firmware currently outside the reach of the libreboot project are covered
 in the libreboot FAQ page. For example, HDD/SSD firmware is covered in the FAQ.
 Again, completely disregarded and shrugged off by the FSF.
 The libreboot project will not hide or overlook these issues, because they are
 indeed critical, but again, currently outside the scope of what the Libreboot
 build system does. At the moment, the Libreboot build system concerns itself
 just with coreboot (and payloads), but this ought to change in the future.
 Examples of FSF *sweeping blobs under the rug*
 ----------------------------------------------
 Over the years, there have been numerous cases where the FSF actively fails to
 provide incentive for levels of software freedom, such as:
 * TALOS II "OpenPOWER" workstation from Raptor Engineering USA. It contains a
  broadcom NIC inside it which requires firmware, and that firmware was non-free.
  The FSF were willing to ignore it, and certify the TALOS II product under RYF,
  but Timothy Pearson of Raptor Engineering had it freed anyway, without being
  told to. Hugo Landau reverse engineered the specification and Evan Lojewski
  wrote libre firmware. See:
  See: <https://www.devever.net/~hl/ortega> and <https://github.com/meklort/bcm5719-fw>
 * FSF once endorsed the ThinkPad X200, as sold by [Minifree Ltd](https://minifree.org),
  which contains the Intel ME; the bootrom is still there, as is the ME
  coprocessor, but the ME is put into a disabled state via the Intel Flash
  Descriptor, and the ME firmware in flash is removed. However, the ME is an
  entire coprocessor which, with libre firmware, could be used for a great many
  things. In the Libreboot and coreboot projects, there has always been interest
  in this but the FSF disregards it entirely. The X200 product they certified
  came with Libreboot pre-installed.
 * Libreboot has a utility written by I, Leah Rowe, that generates ICH9M flash
  descriptors and GbE NVM images from scratch. This is necessary to configure
  the machine, but these are binary blobs otherwise; the FSF would have been
  quite content to certify the hardware anyway since these were non-software
  blobs in a format fully documented by Intel (they are just binary configuration
  files), but I went ahead and wrote ich9gen anyway. With ich9gen, you can
  more easily modify the descriptor/gbe regions for your firmware image. See:
  <https://libreboot.org/docs/install/ich9utils.html> - libreboot also has this
 * FSF once endorsed the ThinkPad T400 with Libreboot, as sold by Minifree. This
  machine comes in two versions: with ATI+Intel GPU, or only Intel GPU. If ATI
  GPU, it's possible to configure the machine so that either GPU is used. If the
  ATI GPU is to be used, a binary blob is needed for initialization, though the
  driver for it is entirely libre. *The FSF* ignored this fact and endorsed the
  hardware, so long as Libreboot does not enable the ATI GPU or tell people how
  to enable it. The *Intel* GPU on that machine has libre initialization code by
  the coreboot project, and a fully libre driver in both Linux and BSD kernels.
  In the configuration provided by Libreboot, the ATI GPU is completely disabled
  and powered down.
 * All Libreboot-compatible ThinkPads contain proprietary Embedded Controller
  firmware, which is user-flashable (*and intended for update by the
  manufacturer*). The FSF chose to ignore the EC firmware, under
  their *secondary processor* exemption. See:
  <http://libreboot.org/faq.html#ec-embedded-controller-firmware>
 In all of the above cases, the FSF could have been stricter, and bolder, by
 insisting that these *additional* problems for freedom were solved. They did
 not. There are many other examples of this, but the purpose of this article is
 not to list all of them (otherwise, a book could be written on the subject).
 Problems with FSDG
 ------------------
 <img tabindex=1 src="https://av.libreboot.org/firmware.png" /><span class="f"><img src="https://av.libreboot.org/firmware.png" /></span>
 The FSF maintains another set of criteria, dubbed Free System Distribution
 Guidelines (GNU FSDG)]
 The FSDG criteria is separate from RYF, but has similar problems. FSDG is
 what the FSF-endorsed GNU+Linux distros comply with. Basically, it bans
 all proprietary software, including device firmware. This may seem noble, but
 it's extremely problematic in the context of firmware. Food for thought:
 * Excluding vendor blobs in the linux kernel is *bad*. Proprietary firmware
  is *also bad*. Including them is a wiser choice, if strong education is also
  provided about *why they are bad* (less freedom). If you expose them to
  the user, and tell them about it, there is greater incentive (by simple
  reminder of their existence) to reverse engineer and replace them.
 * Firmware *in your OS kernel* is *good*. The FSF simultaneously gives the OK
  for hardware *with those same binary blobs* if the firmware is embedded
  into a ROM/flash chip on the device, or embedded in some processor. If the
  firmware is on separate ROM/flash, it could still be replaced by the user via
  reverse engineering, but then you would probably have to do some soldering
  (replace the chip on the card/device). *If the firmware is loaded by the
  OS kernel, then the firmware is exposed to the user and it can be more
  easily replaced. FSF criteria in this regard encourages hardware designers
  to hide the firmware instead, making actual (software) freedom less likely!*
 Besides this, FSDG seems OK. Any libre operating system should ideally not
 have proprietary *drivers* or *applications*.
 Hardware manufacturers like to shove everything into firmware because their
 product is often poorly designed, so they later want to provide workarounds in
 firmware to fix issues. In many cases, a device will already have firmware on it
 but require an update supplied to it by your OS kernel.
 The most common example of proprietary firmware in Linux is for wifi devices.
 This is an interesting use-case scenario, with source code, because it could be
 used for owner-controlled *software defined radio*.
 The *Debian* way is ideal. The Debian GNU+Linux distribution is entirely libre
 by default, and they include extra firmware if needed, which they have in a
 separate repository containing it. If you only want firmware, it is
 trivial to get installer images with it included, or add that to your installed
 system. They tell you how to do it, which means that they are helping people
 to get *some* freedom *rather than none*. This is an inherently pragmatic
 way to do things, and it's now how Libreboot does it.
 More context regarding Debian is available in this blog post:
 <https://blog.einval.com/2022/04/19#firmware-what-do-we-do> - in it, the
 author, a prominent Debian developer, makes excellent points about device
 firmware similar to the (Libreboot) article that you're reading now. It's
 worth a read! As of October 2022, Debian has voted to include device firmware
 by *default*, in following Debian releases. It used to be that Debian excluded
 such firmware, but allowed you to add it.
 OpenBSD is very much the same, but they're clever about it: during the initial
 boot, after installation, it tells you exactly what firmware is needed and
 updates that for you. It's handled in a very transparent way, by
 their `fw_update` program which you can read about here:
 <https://man.openbsd.org/fw_update>
 *Banning* linux-firmware specifically is a threat to freedom in the long term,
 because new users of GNU+Linux might be discouraged from using the OS if their
 hardware doesn't work. You might say: just buy new hardware! This is often not
 possible for users, and the user might not have the skill to reverse engineer
 it either.
 More detailed insight about microcode
 =====================================
 [Releases after 20230423 will provide separate ROM images with microcode
 excluded, alongside the default ones that include microcode.](microcode.md)
 To be clear: it is preferable that microcode be libre. The microcode on Intel
 and AMD systems *are* proprietary. Facts and feelings rarely coincide; the
 purpose of this section is to spread *facts*.
 The libreboot build system now enables microcode updates *by default.*
 Not including CPU microcode updates is an absolute disaster for system
 stability and security.
 Making matters worse, that very same text quoted from the FSF RYF criteria in
 fact specifically mentions microcode. Quoted again for posterity:
 *"However, there is one exception for secondary embedded processors. The
 exception applies to software delivered inside auxiliary and low-level
 processors and FPGAs, within which software installation is not intended after
 the user obtains the product. This can include, for instance, microcode inside
 a processor, firmware built into an I/O device, or the gate pattern of an FPGA.
 The software in such secondary processors does not count as product software."*
 Here, it is discussing the microcode that is burned into *mask ROM* on the CPU
 itself. It is simultaneously not giving the OK for microcode *updates* supplied
 by either coreboot or the Linux kernel; according to the FSF, these are an
 attack on your freedom, but the older, buggier microcode burned into ROM is OK.
 The CPU already has microcode burned into mask ROM. The microcode configures
 logic gates in the CPU, to implement an instruction set, via special *decoders*
 which are fixed-function; it is not possible, for example, to implement a RISCV
 ISA on an otherwise x86 processor. It is only possible for the microcode to
 implement x86, or *broken* x86, and the default microcode is almost always
 *broken x86* on Intel/AMD CPUs; it is inevitable, due to the complexity of
 these processors.
 The FSF believes
 that these x86 microcode updates (on Intel/AMD) allow you to completely create
 a new CPU that is fundamentally different than x86. This is not true. It is also
 not true that *all* instructions in x86 ISA are implemented with microcode. In
 some cases, hardcoded circuitry is used! The microcode updates are more like
 tiny one liner patches here and there in a git repository, by way of analogy.
 To once again get in the head-space of the FSF: these updates cannot do the CPU
 equivalent of re-factoring an entire codebase. They are *hot fixes*, nothing
 more!
 Not including these updates will result in an unstable/undefined state. Intel
 themselves define which bugs affect which CPUs, and they define workarounds, or
 provide fixes in microcode. Based on this, software such as the Linux kernel
 can work around those bugs/quirks. Also, upstream versions of the Linux kernel
 can update the microcode at boot time (however, it is recommend still to do it
 from coreboot, for more stable memory controller initialization or “raminit”).
 Similar can be said about AMD CPUs.
 Here are some examples of where lack of microcode updates affected *Libreboot*,
 forcing Libreboot to work around changes made upstream in coreboot, changes
 that were *good* and made coreboot behave in a more standards-compliant manner
 as per Intel specifications. Libreboot had to *break* coreboot to retain
 certain other functionalities, on some GM45/ICH9M thinkpads:
 <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>
 These patches revert *bug fixes* in coreboot, fixes that happen to break other
 functionality but only when microcode updates are excluded. The most
 technically correct solution is to *not* apply the above patches, and instead
 supply microcode updates!
 Pick your poison. Not adding the updates is *irresponsible*, and ultimately
 futile, because you still end up with proprietary microcode, but you just get
 an older, buggier version instead!
 This shift in project policy does not affect your freedom at all, because you
 still otherwise have older, buggier microcode anyway. However, it does improve
 system reliability by including the updates!
 Such pragmatic policy is *superior* to the *dogma* that Libreboot users once
 had to endure. Simply put, the Libreboot project aims to give users as much
 freedom as is possible for their hardware; this was always the case, but this
 mentality is now applied to [a lot] more hardware.
 Other considerations
 ====================
 Also not covered strictly by Libreboot: OSHW and Right To Repair. Freedom at
 the silicon level would however be amazing, and efforts already exist; for
 example, look at the RISCV ISA (in practise, actual fabrication is still
 proprietary and not under your control, but RISCV is a completely libre CPU
 design that companies can use, instead of having to use proprietary ARM/x86 and
 so on). Similarly, Right To Repair (ability to repair your own device, which
 implies free access to schematics and diagrams) is critical, for the same
 reason that Libre Software (Right To Hack) is critical!
 OSHW and Right To Repair are not covered at all by RYF (FSF's Respects Your
 Freedom criteria), the criteria which Libreboot previously complied with.
 RYF also makes several concessions that are ultimately damaging, such as
 the *software as circuitry* policy which is, frankly, nonsensical. ROM is still
 software. There was a time when the FSF didn't consider BIOS software a freedom
 issue, just because it was burned onto a mask ROM instead of *flashed*; those
 FSF policies ignore the fact that, with adequate soldering skills, it is trivial
 to replace stand-alone mask ROM ICs with compatible flash memory.
 Conclusion
 ==========
 RYF isn't *wrong* per se, just flawed. It is correct in some ways and if
 complied with, the result *does* give many freedoms to the user, but RYF
 completely disregards many things that are now possible, including freedoms at
 the hardware level (the RYF criteria only covers *software*). Those guidelines
 are written with assumptions that were still true in the 1990s, but the world
 has since evolved. The libreboot project rejects those policies in their
 entirety, and instead takes a pragmatic approach.
 The conclusion that should be drawn from all of this is as follows:
 *Following* FSF criteria does not damage anything, but that criteria is very
 conservative. Its exemptions should be *disregarded* and entirely ignored.
 RYF is no longer fit for purpose, and should be rewritten to create
 a *more strict* set of guidelines, without all the loopholes or exemptions.
 As has always been the case, Libreboot tries to always go above and beyond, but
 the Libreboot project does not see RYF as a *gold standard*. There are levels
 of freedom possible now that the RYF guidelines do not cover at all, and in
 some cases even actively discourage/dis-incentivize because it makes compromises
 based on assumptions that are no longer true. 
 Sad truth: RYF actively encourages *less* freedom, by not being bold enough.
 It sets a victory flag and says *mission accomplished*, despite the fact
 that the work is *far* from complete!
 If followed *with exemptions unchallenged*, RYF may in some cases encourage
 companies to *sweep under the rug* any freedom issues that exist, where it
 concerns proprietary firmware not running on the host CPU (such as the
 Embedded Controller firmware).
 I propose that new guidelines be written, to replace RYF. These new guidelines
 will do away with all exemptions/loopholes, and demand that *all* software be
 libre on the machine, or as much as possible. Instead of only promoting products
 that meet some arbitrary standard, simply catalog all systems on a grand
 *database* of sorts (like h-node.org, but better), which will define exactly
 what *hardware* **and** software issues exist on each device. Include Right to
 Repair and OSHW (including things like RISCV) in the most "ideal"
 standard machine; the gold standard is libre *silicon*, like what Sam Zeloof
 and others are working on nowadays.
 This new set of criteria should not attempt to hide or ignore *anything*. It
 should encourage people to push the envelope and innovate, so that we can have
 much *more* freedom than is currently possible. Necessity is the mother of all
 invention, and freedom is an important goal in every aspect of life, not just
 computing.
 Don't call it "Respects Your Freedom" or something similar. Instead, call it
 something like: the freedom catalog. And actually focus on hardware, not just
 software!
 Other resources
 ===============
 Ariadne Conill's RYF blog post
 ------------------------------
 Ariadne Conill, security team chair of *Alpine Linux*, posted a very robust
 article about RYF, with similar points made when compared to *this* article.
 However, Ariadne goes into detail on several other examples of problems with
 the FSF RYF criteria; for example, it talks about the *Novena* product by
 Bunnie.
 It's worth a read! Link:
 <https://ariadne.space/2022/01/22/the-fsfs-relationship-with-firmware-is-harmful-to-free-software-users/>
--- a/site/news/policy.md
+++ b/site/news/policy.md
@ -168,375 +168,3 @@ exist, for example, the work done by Sam Zeloof and the Libre Silicon project:
 * <https://libresilicon.com/>
 (Sam literally makes CPUs in his garage)
 Problems with RYF criteria
 ==========================
 Libreboot previously complied with FSF RYF criteria, but it now adheres to a
 much more pragmatic policy aimed at providing more freedom to more people, in a
 more pragmatic way. You can read those guidelines by following this URL:
 * FSF Respects Your Freedom (RYF) guidelines:
 <https://web.archive.org/web/20220604203538/https://ryf.fsf.org/about/criteria/>
 Put simply, the RYF guidelines pertain to commercial products, with the
 stipulation that they must not contain proprietary software, or known privacy
 issues like backdoors.
 The total exclusion of all proprietary software is currently not feasible. For
 example, proprietary SDR firmware in WiFi chipsets, firmware in AHCI devices
 like HDDs or SSDs, and the like. The FSF RYF guidelines state the following
 exception, to mitigate this fact:
 * "However, there is one exception for secondary embedded processors. The exception applies to software delivered inside auxiliary and low-level processors and FPGAs, within which software installation is not intended after the user obtains the product. This can include, for instance, microcode inside a processor, firmware built into an I/O device, or the gate pattern of an FPGA. The software in such secondary processors does not count as product software."
 *This should be
 rejected on ideological grounds*. The rest of libreboot's policy and overall
 ideology expressed, in this article, will be based largely on that rejection.
 The definition of *product software* is completely arbitrary; software is
 software, and software should always be *libre*. Instead of making such
 exceptions, more hardware should be encouraged, with help given to provide as
 much freedom as possible, while providing education to users about any pitfalls
 they may encounter, and encourage freedom at all levels. When an organisation
 like the FSF makes such bold exceptions as above, it sends the wrong message,
 by telling people essentially to sweep these other problems under the rug, just
 because they involve software that happens to run on a "secondary processor".
 If the software is possible to update by the user, then it should be libre,
 regardless of whether the manufacturer *intended* for it to be upgraded or not.
 Where it really *isn't* possible to update such software, proprietary or not,
 advice should be given to that effect. Education is important, and the FSF's
 criteria actively discourages such education; it creates a false hope that
 everything is great and wonderful, just because the software on one arbitrary
 level is all perfect.
 This view of the FSF's, as expressed in the quoted paragraph, assumes that
 there is primarily *one* main processor controlling your system. On many
 modern computers, this is *no longer true*.
 Libre *software* does not exist in a vacuum, but we had less freedom in the
 past, especially when it came to hardware, so *software* was our primary focus.
 The ability to study, adapt, share and use/re-use software freely is important,
 but there is a lot of nuance when it comes to *boot firmware*, nuance which is
 largely non-existent outside of firmware development, or kernel development.
 Most typical application/system software is high level and portable, but boot
 firmware has to be written for each specific machine, and due to the way
 hardware works, there are many trade-offs made, including by the FSF when
 defining what standards should apply *in practise*.
 The fact that almost nobody talks about the EC firmware is *because* of the
 Respects Your Freedom certification. In reality, the EC firmware is crucial
 to user freedom, and ought to be free, but it is completely disregarded by
 the FSF as *part of the hardware*. This is wrong, and the FSF should actively
 encourage people to free it, on every laptop!
 Other firmware currently outside the reach of the libreboot project are covered
 in the libreboot FAQ page. For example, HDD/SSD firmware is covered in the FAQ.
 Again, completely disregarded and shrugged off by the FSF.
 The libreboot project will not hide or overlook these issues, because they are
 indeed critical, but again, currently outside the scope of what the Libreboot
 build system does. At the moment, the Libreboot build system concerns itself
 just with coreboot (and payloads), but this ought to change in the future.
 Examples of FSF *sweeping blobs under the rug*
 ----------------------------------------------
 Over the years, there have been numerous cases where the FSF actively fails to
 provide incentive for levels of software freedom, such as:
 * TALOS II "OpenPOWER" workstation from Raptor Engineering USA. It contains a
  broadcom NIC inside it which requires firmware, and that firmware was non-free.
  The FSF were willing to ignore it, and certify the TALOS II product under RYF,
  but Timothy Pearson of Raptor Engineering had it freed anyway, without being
  told to. Hugo Landau reverse engineered the specification and Evan Lojewski
  wrote libre firmware. See:
  See: <https://www.devever.net/~hl/ortega> and <https://github.com/meklort/bcm5719-fw>
 * FSF once endorsed the ThinkPad X200, as sold by [Minifree Ltd](https://minifree.org),
  which contains the Intel ME; the bootrom is still there, as is the ME
  coprocessor, but the ME is put into a disabled state via the Intel Flash
  Descriptor, and the ME firmware in flash is removed. However, the ME is an
  entire coprocessor which, with libre firmware, could be used for a great many
  things. In the Libreboot and coreboot projects, there has always been interest
  in this but the FSF disregards it entirely. The X200 product they certified
  came with Libreboot pre-installed.
 * Libreboot has a utility written by I, Leah Rowe, that generates ICH9M flash
  descriptors and GbE NVM images from scratch. This is necessary to configure
  the machine, but these are binary blobs otherwise; the FSF would have been
  quite content to certify the hardware anyway since these were non-software
  blobs in a format fully documented by Intel (they are just binary configuration
  files), but I went ahead and wrote ich9gen anyway. With ich9gen, you can
  more easily modify the descriptor/gbe regions for your firmware image. See:
  <https://libreboot.org/docs/install/ich9utils.html> - libreboot also has this
 * FSF once endorsed the ThinkPad T400 with Libreboot, as sold by Minifree. This
  machine comes in two versions: with ATI+Intel GPU, or only Intel GPU. If ATI
  GPU, it's possible to configure the machine so that either GPU is used. If the
  ATI GPU is to be used, a binary blob is needed for initialization, though the
  driver for it is entirely libre. *The FSF* ignored this fact and endorsed the
  hardware, so long as Libreboot does not enable the ATI GPU or tell people how
  to enable it. The *Intel* GPU on that machine has libre initialization code by
  the coreboot project, and a fully libre driver in both Linux and BSD kernels.
  In the configuration provided by Libreboot, the ATI GPU is completely disabled
  and powered down.
 * All Libreboot-compatible ThinkPads contain proprietary Embedded Controller
  firmware, which is user-flashable (*and intended for update by the
  manufacturer*). The FSF chose to ignore the EC firmware, under
  their *secondary processor* exemption. See:
  <http://libreboot.org/faq.html#ec-embedded-controller-firmware>
 In all of the above cases, the FSF could have been stricter, and bolder, by
 insisting that these *additional* problems for freedom were solved. They did
 not. There are many other examples of this, but the purpose of this article is
 not to list all of them (otherwise, a book could be written on the subject).
 Problems with FSDG
 ------------------
 <img tabindex=1 src="https://av.libreboot.org/firmware.png" /><span class="f"><img src="https://av.libreboot.org/firmware.png" /></span>
 The FSF maintains another set of criteria, dubbed Free System Distribution
 Guidelines (GNU FSDG)]. They recommend a special version of the Linux kernel,
 dubbed *linux-libre*, which removes all vendor code from upstream. These
 vendor files are required for certain hardware to work correctly.
 The FSDG criteria is separate from RYF, but has similar problems. FSDG is
 what the FSF-endorsed GNU+Linux distros comply with. Basically, it bans
 all proprietary software, including device firmware. This may seem noble, but
 it's extremely problematic in the context of firmware. 
 *Banning* linux-firmware specifically is a threat to freedom in the long term,
 because new users of GNU+Linux might be discouraged from using the OS if their
 hardware doesn't work. You might say: just buy new hardware! This is often not
 possible for users, and the user might not have the skill to reverse engineer
 it either. **Banning such firmware constitutes
 *[censorship](https://en.wikipedia.org/wiki/Book_burning)*, in the name of
 freedom, but all it does is reduce freedom of choice; somebody else has already
 made that decision for you, *against* you.** You should not use linux-libre at
 all. Some wisdom:
 * Excluding vendor blobs in the linux kernel is *bad*. Proprietary firmware
  is *also bad*. Including them is a wiser choice, if strong education is also
  provided about *why they are bad* (less freedom). If you expose them to
  the user, and tell them about it, there is greater incentive (by simple
  reminder of their existence) to reverse engineer and replace them.
 * Firmware *in your OS kernel* is *good*. The FSF simultaneously gives the OK
  for hardware *with those same binary blobs* if the firmware is embedded
  into a ROM/flash chip on the device, or embedded in some processor. If the
  firmware is on separate ROM/flash, it could still be replaced by the user via
  reverse engineering, but then you would probably have to do some soldering
  (replace the chip on the card/device). *If the firmware is loaded by the
  OS kernel, then the firmware is exposed to the user and it can be more
  easily replaced. FSF criteria in this regard encourages hardware designers
  to hide the firmware instead, making actual (software) freedom less likely!*
 Besides this, FSDG seems OK. Any libre operating system should ideally not
 have proprietary *drivers* or *applications*. Libreboot *previously* adhered
 to FSDG, but now takes a more pragmatic approach when it comes to things like
 CPU microcode or *EC firmware*.
 Hardware manufacturers like to shove everything into firmware because their
 product is often poorly designed, so they later want to provide workarounds in
 firmware to fix issues. In many cases, a device will already have firmware on it
 but require an update supplied to it by your OS kernel.
 The most common example of proprietary firmware in Linux is for wifi devices.
 This is an interesting use-case scenario, with source code, because it could be
 used for owner-controlled *software defined radio*.
 The *Debian* way is ideal. The Debian GNU+Linux distribution is entirely libre
 by default, and they include extra firmware if needed, which they have in a
 separate repository containing it. If you only want firmware, it is
 trivial to get installer images with it included, or add that to your installed
 system. They tell you how to do it, which means that they are helping people
 to get *some* freedom *rather than none*. This is an inherently pragmatic
 way to do things, and it's now how Libreboot does it.
 More context regarding Debian is available in this blog post:
 <https://blog.einval.com/2022/04/19#firmware-what-do-we-do> - in it, the
 author, a prominent Debian developer, makes excellent points about device
 firmware similar to the (Libreboot) article that you're reading now. It's
 worth a read! As of October 2022, Debian has voted to include device firmware
 by *default*, in following Debian releases. It used to be that Debian excluded
 such firmware, but allowed you to add it.
 OpenBSD is very much the same, but they're clever about it: during the initial
 boot, after installation, it tells you exactly what firmware is needed and
 updates that for you. It's handled in a very transparent way, by
 their `fw_update` program which you can read about here:
 <https://man.openbsd.org/fw_update>
 OpenBSD is great.
 More detailed insight about microcode
 =====================================
 [Releases after 20230423 will provide separate ROM images with microcode
 excluded, alongside the default ones that include microcode.](microcode.md)
 To be clear: it is preferable that microcode be libre. The microcode on Intel
 and AMD systems *are* proprietary. Facts and feelings rarely coincide; the
 purpose of this section is to spread *facts*.
 The libreboot build system now enables microcode updates *by default.*
 Not including CPU microcode updates is an absolute disaster for system
 stability and security.
 Making matters worse, that very same text quoted from the FSF RYF criteria in
 fact specifically mentions microcode. Quoted again for posterity:
 *"However, there is one exception for secondary embedded processors. The
 exception applies to software delivered inside auxiliary and low-level
 processors and FPGAs, within which software installation is not intended after
 the user obtains the product. This can include, for instance, microcode inside
 a processor, firmware built into an I/O device, or the gate pattern of an FPGA.
 The software in such secondary processors does not count as product software."*
 Here, it is discussing the microcode that is burned into *mask ROM* on the CPU
 itself. It is simultaneously not giving the OK for microcode *updates* supplied
 by either coreboot or the Linux kernel; according to the FSF, these are an
 attack on your freedom, but the older, buggier microcode burned into ROM is OK.
 The CPU already has microcode burned into mask ROM. The microcode configures
 logic gates in the CPU, to implement an instruction set, via special *decoders*
 which are fixed-function; it is not possible, for example, to implement a RISCV
 ISA on an otherwise x86 processor. It is only possible for the microcode to
 implement x86, or *broken* x86, and the default microcode is almost always
 *broken x86* on Intel/AMD CPUs; it is inevitable, due to the complexity of
 these processors.
 The FSF believes
 that these x86 microcode updates (on Intel/AMD) allow you to completely create
 a new CPU that is fundamentally different than x86. This is not true. It is also
 not true that *all* instructions in x86 ISA are implemented with microcode. In
 some cases, hardcoded circuitry is used! The microcode updates are more like
 tiny one liner patches here and there in a git repository, by way of analogy.
 To once again get in the head-space of the FSF: these updates cannot do the CPU
 equivalent of re-factoring an entire codebase. They are *hot fixes*, nothing
 more!
 Not including these updates will result in an unstable/undefined state. Intel
 themselves define which bugs affect which CPUs, and they define workarounds, or
 provide fixes in microcode. Based on this, software such as the Linux kernel
 can work around those bugs/quirks. Also, upstream versions of the Linux kernel
 can update the microcode at boot time (however, it is recommend still to do it
 from coreboot, for more stable memory controller initialization or “raminit”).
 Similar can be said about AMD CPUs.
 Here are some examples of where lack of microcode updates affected *Libreboot*,
 forcing Libreboot to work around changes made upstream in coreboot, changes
 that were *good* and made coreboot behave in a more standards-compliant manner
 as per Intel specifications. Libreboot had to *break* coreboot to retain
 certain other functionalities, on some GM45/ICH9M thinkpads:
 <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>
 These patches revert *bug fixes* in coreboot, fixes that happen to break other
 functionality but only when microcode updates are excluded. The most
 technically correct solution is to *not* apply the above patches, and instead
 supply microcode updates!
 Pick your poison. Not adding the updates is *irresponsible*, and ultimately
 futile, because you still end up with proprietary microcode, but you just get
 an older, buggier version instead!
 This shift in project policy does not affect your freedom at all, because you
 still otherwise have older, buggier microcode anyway. However, it does improve
 system reliability by including the updates!
 Such pragmatic policy is *superior* to the *dogma* that Libreboot users once
 had to endure. Simply put, the Libreboot project aims to give users as much
 freedom as is possible for their hardware; this was always the case, but this
 mentality is now applied to [a lot] more hardware.
 Other considerations
 ====================
 Also not covered strictly by Libreboot: OSHW and Right To Repair. Freedom at
 the silicon level would however be amazing, and efforts already exist; for
 example, look at the RISCV ISA (in practise, actual fabrication is still
 proprietary and not under your control, but RISCV is a completely libre CPU
 design that companies can use, instead of having to use proprietary ARM/x86 and
 so on). Similarly, Right To Repair (ability to repair your own device, which
 implies free access to schematics and diagrams) is critical, for the same
 reason that Libre Software (Right To Hack) is critical!
 OSHW and Right To Repair are not covered at all by RYF (FSF's Respects Your
 Freedom criteria), the criteria which Libreboot previously complied with.
 RYF also makes several concessions that are ultimately damaging, such as
 the *software as circuitry* policy which is, frankly, nonsensical. ROM is still
 software. There was a time when the FSF didn't consider BIOS software a freedom
 issue, just because it was burned onto a mask ROM instead of *flashed*; those
 FSF policies ignore the fact that, with adequate soldering skills, it is trivial
 to replace stand-alone mask ROM ICs with compatible flash memory.
 Conclusion
 ==========
 RYF isn't *wrong* per se, just flawed. It is correct in some ways and if
 complied with, the result *does* give many freedoms to the user, but RYF
 completely disregards many things that are now possible, including freedoms at
 the hardware level (the RYF criteria only covers *software*). Those guidelines
 are written with assumptions that were still true in the 1990s, but the world
 has since evolved. The libreboot project rejects those policies in their
 entirety, and instead takes a pragmatic approach.
 The conclusion that should be drawn from all of this is as follows:
 *Following* FSF criteria does not damage anything, but that criteria is very
 conservative. Its exemptions should be *disregarded* and entirely ignored.
 RYF is no longer fit for purpose, and should be rewritten to create
 a *more strict* set of guidelines, without all the loopholes or exemptions.
 As has always been the case, Libreboot tries to always go above and beyond, but
 the Libreboot project does not see RYF as a *gold standard*. There are levels
 of freedom possible now that the RYF guidelines do not cover at all, and in
 some cases even actively discourage/dis-incentivize because it makes compromises
 based on assumptions that are no longer true. 
 Sad truth: RYF actively encourages *less* freedom, by not being bold enough.
 It sets a victory flag and says *mission accomplished*, despite the fact
 that the work is *far* from complete!
 If followed *with exemptions unchallenged*, RYF may in some cases encourage
 companies to *sweep under the rug* any freedom issues that exist, where it
 concerns proprietary firmware not running on the host CPU (such as the
 Embedded Controller firmware).
 I propose that new guidelines be written, to replace RYF. These new guidelines
 will do away with all exemptions/loopholes, and demand that *all* software be
 libre on the machine, or as much as possible. Instead of only promoting products
 that meet some arbitrary standard, simply catalog all systems on a grand
 *database* of sorts (like h-node.org, but better), which will define exactly
 what *hardware* **and** software issues exist on each device. Include Right to
 Repair and OSHW (including things like RISCV) in the most "ideal"
 standard machine; the gold standard is libre *silicon*, like what Sam Zeloof
 and others are working on nowadays.
 This new set of criteria should not attempt to hide or ignore *anything*. It
 should encourage people to push the envelope and innovate, so that we can have
 much *more* freedom than is currently possible. Necessity is the mother of all
 invention, and freedom is an important goal in every aspect of life, not just
 computing.
 Don't call it "Respects Your Freedom" or something similar. Instead, call it
 something like: the freedom catalog. And actually focus on hardware, not just
 software!
 Other resources
 ===============
 Ariadne Conill's RYF blog post
 ------------------------------
 Ariadne Conill, security team chair of *Alpine Linux*, posted a very robust
 article about RYF, with similar points made when compared to *this* article.
 However, Ariadne goes into detail on several other examples of problems with
 the FSF RYF criteria; for example, it talks about the *Novena* product by
 Bunnie.
 It's worth a read! Link:
 <https://ariadne.space/2022/01/22/the-fsfs-relationship-with-firmware-is-harmful-to-free-software-users/>
--- a/site/news/policy.uk.md
+++ b/site/news/policy.uk.md
@ -170,363 +170,3 @@ Libreboot вирішує цю ситуацію *суворо* та *принци
 * <https://libresilicon.com/>
 (Сем буквально виробляє процесори в своєму гаражі)
 Проблеми з критеріями RYF
 ==========================
 Раніше Libreboot відповідав критеріям FSF RYF, але тепер він дотримується
 набагато більш прагматичної політики, спрямованої на надання більшої свободи більшій кількості людей у
 більш прагматичний спосіб. Ви можете прочитати ці вказівки, перейшовши за цією URL-адресою:
 * Рекомендації FSF Поважає Вашу Свободу (RYF):
 <https://web.archive.org/web/20220604203538/https://ryf.fsf.org/about/criteria/>
 Простіше кажучи, інструкції RYF стосуються комерційних продуктів із застереженням,
 що вони не повинні містити пропрієтарне програмне забезпечення чи відомі проблеми конфіденційності,
 як-от лазівки.
 Повне виключення всього пропрієтарного забезпечення наразі неможливе. Наприклад,
 пропрієтарне мікропрограмне забезпечення SDR у чіпсетах WiFi, мікропрограмне забезпечення пристроїв AHCI, таких як
 жорсткі диски або твердотілі накопичувачі тощо. В інструкціях FSF RYF зазначено наступний виняток, щоб пом'якшити цей факт:
 * "Однак є один виняток для вторинних вбудованих процесорів. Виняток стосується програмного забезпечення, що постачаєтья в бічних допоміжних і низькорівневих процесорах та FPGA, у яких встановлення програмного забезпечення не передбачається після того, як користувач отримає продукт. Це може включати, наприклад, мікрокод всередині процесора, мікропрограму, вбудовану в пристрій вводу-виводу, або структуру вентилів FPGA. Програмне забезпечення в таких вторинних процесорах не вважається програмним забезпеченням продукту."
 *та має бути відхилено
 з ідеологічних міркувань*. Решта політики libreboot і загальна
 ідеологія, виражена в цій статті, базуватиметься в основному на цьому неприйнятті.
 Визначення *програмного забезпечення продукту* абсолютно довільне; програмне забезпечення
 є програмне забезпечення, а програмне забезпечення завжди має бути *вільним*. Замість того, щоб робити такі
 винятки, слід заохочувати більше апаратного забезпечення, допомогаючи надавати якомога
 більше свободи, одночасно надаючи користувачам інформацію про будь-які підводні
 камені, з якими вони можуть зіткнутися, і заохочувати свободу на всіх рівнях. Коли така організація,
 як FSF, робить такі сміливі винятки, як вище, вона надсилає неправильне повідомлення,
 кажучи людям, по суті, заховати ці інші проблеми лише тому, що вони стосуються програмного забезпечення,
 яке працює на "вторинному процесорі".
 Якщо користувач може оновити програмне забезпечення, воно має бути вільним,
 незалежно від того, *передбачав* виробник оновлення чи ні.
 Там де справді *не* можливо оновити таке програмне забезпечення, пропрієтарне чи ні,
 слід надати поради щодо цього. Освіта важлива, і критерії FSF
 активно перешкоджають такій освіті; це створює помилкову надію, що
 все добре і чудово, лише тому, що програмне забезпечення на одному довільному
 рівні ідеальне.
 Цей погляд FSF, виражений у цитованому абзаці, припускає,
 що системою керує переважно *один* головний процесор. На багатьох
 сучасних комп'ютерах це *більше не відповідає дійсності*.
 Вільне *програмне забезпечення* не існує у вакуумі, але ми мали менше свободи в
 минулому, особливо коли справа стосувалася апаратного забезпечення, тому *ПЗ* було нашим основним фокусом.
 Здатність вільно вивчати, адаптувати, обмінюватися та використовувати/повторно використовувати ПЗ є важливою,
 але є багато нюансів, коли справа доходить до *завантажувального мікропрограмного забезпечення*, нюансів, які
 здебільшого не існують поза розробкою мікропрограмного забезпечення чи поза розробкою ядра.
 Більшість типового прикладного/системного програмного забезпечення є високорівневим і портативним, але
 завантажувальна мікропрограма має бути написана для кожної конкретної машини, і через те, як
 апаратне забезпечення працює, існує багато компромісів, зокрема FSF, коли
 визначає які стандарти слід застосовувати *на практиці*.
 Той факт, що майже ніхто не говорить про прошивку EC, *пов'язаний* із
 сертифікацією Поважає Вашу Свободу (Respects Your Freedom). Насправді мікропрограмне забезпечення EC має вирішальне
 значення для свободи користувачів і повинно бути вільним, але FSF повністю ігнорує його як
 *частину апаратного забезпечення*. Це неправильно, і FSF має активно
 заохочувати людей визволяти його на кожному ноутбуці!
 Інше мікропрограмне забезпечення, яке наразі не доступне для проекту libreboot, описано на
 сторінці поширених питань libreboot. Наприклад, прошивка жорстких дисків/твердотілих накопичувачів описана в розділі поширених запитань.
 Знову ж таки, повністю проігноровано та знизано плечима FSF.
 Проект libreboot не буде приховувати або пропускати ці проблеми, тому що вони
 справді є критичними, але, знову ж таки, наразі виходять за межі того, що робить система збірки 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,
  але ME переведено в вимкнений стан через Intel Flash
  Descriptor, а мікропрограму ME у флеш-пам'яті видалено. Однак ME - це цілий
  співпроцесор, який з вільною прошивкою можна було би використовувати для багатьох
  речей. У проектах Libreboot та coreboot завжди був інтерес до цього,
  але FSF повністю ігнорує це. Продукт X200, який вони сертифікували,
  постачався з попередньо встановленим Libreboot.
 * У Libreboot є утиліта, написана мною, Лією Роу, яка створює флеш-дескриптори ICH9M і образи
  GbE NVM з нуля. Це необхідно для налаштування
  машини, але інакше це двійкові блоб-файли; FSF був би цілком
  задоволений сертифікацією апаратного забезпечення в будь-якому випадку, оскільки це були непрограмні
  блоби у форматі, повністю задокументованому Intel (це лише двійкові конфігураційні
  файли), але я все одно пішла вперед і написала ich9gen. За допомогою ich9gen ви можете
  легше змінювати регіони дескриптора/gbe для вашого образу мікропрограмного забезпечення. Дивіться:
  <https://libreboot.org/docs/install/ich9utils.html> - libreboot також має це
 * FSF свого часу схвалив ThinkPad T400 з Libreboot, який продавав Minifree. Ця
  машина доступна в двох версіях: з графічним процесором ATI+Intel або лише Intel. Якщо ATI
  GPU, можна налаштувати машину так, щоб використовувався будь-який GPU. Якщо буде використовуватися
  графічний процесор ATI, для ініціалізації потрібен блоб мікропрограми, хоча драйвер для нього
  повністю вільний. *FSF* проігнорувала цей факт і схвалила апаратне забезпечення,
  доки Libreboot не вмикає графічний процесор ATI і не повідомляє людям, як його
  увімкнути. Графічний процесор *Intel* на цій машині має вільний код ініціалізації
  від проекту coreboot і повністю вільний драйвер в обох ядрах Linux та BSD.
  У конфігурації, наданій Libreboot, ATI GPU повністю вимкнено
  та виключено.
 * Усі ноутбуки ThinkPad, сумісні з Libreboot, містять невільне мікропрограмне забезпечення вбудованого контролера,
  яке можна прошивати користувачем (*і призначене для оновлення
  виробником*). FSF вирішила ігнорувати прошивку EC, відповідно до
  свого винятку *вторинного процесора*. Дивіться:
  <http://libreboot.org/faq.uk.html#прошивка-ec-вбудований-контролер>
 У всіх вищезазначених випадках FSF міг бути суворішим і сміливішим, наполягаючи
 на тому, що ці *додаткові* проблеми свободи були вирішені. Вони цього не
 зробили. Є багато інших прикладів цього, але мета цієї статті
 не перелічити їх усі (інакше на цю тему можна були б написати книгу).
 Проблеми з FSDG
 ------------------
 <img tabindex=1 src="https://av.libreboot.org/firmware.uk.png" /><span class="f"><img src="https://av.libreboot.org/firmware.uk.png" /></span>
 FSF підтримує ще один набір критеріїв, які називаються Правилами вільного
 розповсюдження системи (GNU FSDG)]
 Критерії FSDG відрізняються від RYF, але мають подібні проблеми. FSDG - це
 те, чому відповідають схвалені FSF дистрибутиви GNU+Linux. По суті, він забороняє
 все пропрієтарне програмне забезпечення, включаючи мікропрограму пристрою. Це може здатися благородним, але
 вкрай проблематично в контексті прошивки. Їжа для роздумів:
 * Виключення мікропрограмним блобів із ядра linux - це *погано*. Пропрієтарна прошивка
  є *також поганою*. Включення їх є мудрішим вибором, якщо також забезпечується сильна освіта
  про те, *чому вони погані* (менше свободи). Якщо ви відкриєте їх для
  користувача та повідомите йому про це, з'явиться більше стимулів (через просте
  нагадування про їх існування) провести зворотне проектування та замінити їх.
 * Прошивка *в ядрі вашої ОС* *хороша*. FSF одночасно дає дозвіл на
  апаратне забезпечення *з тими самими блобами прошивки*, якщо прошивка вбудована в
  ROM/флеш-пам'ять на пристрої або вбудована в якийсь процесор. Якщо
  вбудоване програмне забезпечення знаходиться на окремому ROM/флеш-пам'яті, його все одно можна замінити
  користувачем за допомогою зворотного проектування, але тоді вам, ймовірно, доведеться провести деяку пайку
  (замінити чіп на картці/пристрої). *Якщо мікропрограма завантажується ядром
  ОС, тоді вона відкрита для користувача, і її можна легше замінити.
  Критерії FSF у цьому відношенні заохочують розробників апаратного забезпечення
  приховувати вбудоване програмне забезпечення, що робить фактичну (програмну) свободу менш імовірною!*
 Окрім цього, FSDG здається нормальним. Будь-яка вільна операційна система має в ідеалі не містити
 пропрієтарних *драйверів* або *застосунків*.
 Виробники обладнання полюбляють заштовхувать все в мікропрограмне забезпечення, оскільки їх
 продукт часто має поганий дизайн, тому вони пізніше хочуть надати вирішення в
 прошивці для налагодження проблемних питань. В багатьох випадках, пристрій вже матиме прошивку в собі,
 але вимагає оновлення, надане йому вашим ядром ОС.
 Найбільш поширений приклад пропрієтарної прошивки в Linux для пристроїв wifi.
 Це цікавий сценарій використання, з джерельним кодом, тому що його може бути
 використано для контрольованого власником *software defined radio*.
 Шлях *Debian* є ідеальним. Дистрибутив Debian GNU+Linux повністю вільний
 за замовчуванням, і вони включають додаткову прошивку за необхідності, яку вони мають в
 окремому репозиторії, що містить її. Якщо ви хочете тільки прошивку, тривіально
 взяти образи встановлювача з нею доданою, або додати її до вашої встановленої
 системи. Вони розповідають вам, як зробити це, що означає, що вони допомогають людям
 отримати *деяку* свободу, *замість ніякої*. Це невід'ємно прагматичний
 спосіб робити справи, і це те, як це робить Libreboot.
 Більше контексту, стосовно 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 можуть бути відбиті від використання ОС, якщо їх
 апаратне забезпечення не працює. Ви можете сказати: просто купіть нове обладнання! Це часто неможливо
 для користувачів, і користувач також може не мати навичок для
 зворотного проектування.
 Більш детальна інформація про мікрокод
 =====================================
 [Releases after 20230423 will provide separate ROM images with microcode
 excluded, alongside the default ones that include microcode.](microcode.md)
 Щоб було зрозуміло: бажано, щоб мікрокод був вільним. Мікрокод систем Intel
 та AMD *є* пропрієтарним. Факти і почуття рідко збігаються; метою цього
 розділу є поширення *фактів*.
 Система збірки libreboot тепер дозволяє оновлення мікрокоду *за замовчуванням.*
 Відсутність оновлень мікрокоду ЦП є абсолютною катастрофою для стабільності
 та безпеки системи.
 Що ще гірше, той самий текст, цитований із критеріїв FSF RYF,
 насправді конкретно згадує мікрокод. Знову процитую для нащадків:
 *"Однак є один виняток для вторинних вбудованих процесорів. Виняток
 стосується програмного забезпечення, що постачається всередині допоміжних і низкорівневих
 процесорів та FPGA, у яких інсталяція програмного забезпечення не передбачається після того,
 як користувач отримає продукт. Це може включати, наприклад, мікрокод всередині
 процесора, мікропрограму, вбудовану в пристрій вводу-виводу, або структуру вентилів FPGA.
 Програмне забезпечення в таких вторинних процесорах не вважається програмним забезпеченням продукту."*
 Тут обговорюється мікрокод, який записується в *mask ROM* на самому
 ЦП. Одночасно він не дає ОК для *оновлень* мікрокоду, які надаються
 coreboot або ядром Linux; згідно з FSF, це напад на
 вашу свободу, але старіший мікрокод із більшими помилками, записаний на ROM, є нормальним.
 ЦП вже має мікрокод, записаний в mask ROM. Мікрокод налаштовує
 логічні вентилі в ЦП, для реалізації набору інструкцій через спеціальні *декодери*,
 які мають фіксовану функцію; неможливо, наприклад, реалізувати набір інструкцій RISCV
 на процесорі x86. Для мікрокода можливо тільки
 реалізувати x86, або *зламаний* x86, і мікрокод за замовчуваням майже завжди є
 *зламаним x86* на ЦП Intel/AMD; це неминуче через складність цих
 процесорів.
 FSF вважає,
 що ці оновлення мікрокоду x86 (для Intel/AMD) дозволяють повністю створити новий
 ЦП, який принципово відрізняється від x86. Це не правда. Також неправда,
 що *всі* інструкції в наборі інструкцій x86 реалізовано за допомогою мікрокоду. У
 деяких випадках використовується жорстко закодована схема! Оновлення мікрокоду більше нагадують
 крихітні одиничні патчі тут і там у сховищі git, за аналогією.
 Щоб знову потрапити у головний простір FSF: ці оновлення не можуть зробити ЦП
 еквівалентом рефакторингу всієї кодової бази. Це *гарячі виправлення*, нічого
 більше!
 Невиключення цих оновлень призведе до нестабільного/невизначеного стану. Intel
 сама визначає, які помилки впливають на які ЦП, і вони визначають обхідні шляхи або надають
 виправлення в мікрокоді. Виходячи з цього, таке програмне забезпечення, як ядро Linux
 може обійти ці помилки/примхи. Крім того, апстрім версії ядра Linux
 можуть оновити мікрокод під час завантаження (однак все одно рекомендується робити це
 з coreboot для більш стабільної ініціалізації контролера пам'яті або “raminit”).
 Подібне можна сказати і про ЦП AMD.
 Ось кілька прикладів того, як відсутність оновлень мікрокоду вплинула на *Libreboot*,
 змусивши Libreboot обійти зміни, внесені в апстрім coreboot, зміни,
 які були *хорошими* і зробили 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>
 Ці патчі повертають *виправлення помилок* у coreboot, виправлення, які порушують
 інші функції, але лише якщо оновлення мікрокоду виключено. Найбільш
 правильним з технічної точки зору рішенням є *не* застосування наведених вище патчів, а натомість
 оновлення мікрокоду!
 Виберіть свою отруту. Недодавання оновлень є *безвідповідальним* і, зрештою,
 марним, оскільки ви все одно отримуєте пропрієтарний мікрокод, ви просто отримуєте
 старішу, з більшими помилками, версію натомість!
 Ця зміна в політиці проекту зовсім не впливає на вашу свободу,
 тому що в іншому випадку ви все одно маєте старіший мікрокод із більшими помилками. Однак він покращує
 надійність системи, включаючи оновлення!
 Така прагматична політика *перевершує* *догму*, яку колись
 доводилося терпіти користувачам Libreboot. Простіше кажучи, проект Libreboot має на меті надати користувачам
 якомога більше свободи для їх апаратного забезпечення; так було завжди,
 але цей менталітет тепер застосовується до [набагато] більшої кількості обладнання.
 Інші міркування
 ====================
 Також Libreboot не покриває суворо: OSHW і Право на ремонт (Right To Repair). Однак свобода
 на рівні кремнію була б дивовижною, і зусилля вже є; наприклад, подивіться на RISCV ISA (на
 практиці фактичне виготовлення все ще є пропрієтарним і не під вашим контролем, але RISCV є повністю вільним
 дизайном ЦП, який компанії можуть використовувати замість того, щоб використовувати пропрієтарний ARM/x86 і
 так далі). Подібним чином, Право на ремонт (можливість відремонтувати свій власний пристрій, що
 передбачає вільний доступ до схем і діаграм) є критично важливим з тієї ж причини, що
 критично важливо вільне програмне забезпечення (Право на хакерство)!
 OSHW і Право на ремонт взагалі не охоплюються RYF (критерії FSF Поважає Вашу
 Свободу), критеріями, яких 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, але краще), яка точно визначатиме, які
 *апаратні* **і** програмні проблеми існують на кожному пристрої. Включіть Право
 на ремонт і OSHW (включно з такими речами, як RISCV) до найбільш "ідеальної"
 стандартної машини; золотим стандартом є вільний *кремній*, як те, над чим
 Сем Зелоф та інші працюють зараз.
 Цей новий набір критеріїв не повинен намагатися приховати або проігнорувати *щось*. Це
 має заохочувати людей розширювати рамки та впроваджувати інновації, щоб ми могли мати
 набагато *більше* свободи, ніж зараз можливо. Необхідність є матір'ю всіх
 винаходів, а свобода є важливою метою в кожному аспекті життя, не лише в
 обчисленні.
 Не називайте це "Поважає вашу свободу" чи щось подібне. Натомість назвіть це
 приблизно так: каталог свободи. І насправді зосередьтеся на апаратному забезпеченні, а не
 лише на програмному забезпеченні!
 Інші ресурси
 ===============
 Повідомлення в блозі 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/>
--- a/site/who.uk.md
+++ b/site/who.uk.md
@ -7,7 +7,7 @@ x-toc-enable: true
 проект, як приймаються рішення, і взагалі як проект функціонує.
 Ви можете знайти інформацію про великий внесок, зроблений у libreboot, на цій
-сторінці, яка перелічує таких людей: [Список учасників](contrib.uk.md)
+сторінці, яка перелічує таких людей: [Список учасників](contrib.md)
 Лія Роу (засновниця, провідний розробник)
 ===================================
@ -17,7 +17,7 @@ x-toc-enable: true
 і керує серверами libreboot.org зі своєї лабораторії у Великобританії.
 Ви можете дізнатися більше про участь Лії в libreboot, прочитавши її запис на
-[сторінці зі списком усіх учасників, минулих і теперішніх](contrib.uk.md)
+[сторінці зі списком усіх учасників, минулих і теперішніх](contrib.md)
 Калеб Ла Гранж
 ===============
@ -27,7 +27,7 @@ x-toc-enable: true
 та документацією.
 Ви можете дізнатись більше про участь Калеба в libreboot, прочитавши його
-запис на [сторінці зі списком усіх учасників, минулих і теперішніх](contrib.uk.md)
+запис на [сторінці зі списком усіх учасників, минулих і теперішніх](contrib.md)
 Альпер Небі Ясак
 ================
@ -37,7 +37,7 @@ x-toc-enable: true
 апстрім роботу над самим U-Boot. `alpernebbi` на Libera IRC.
 Ви можете дізнатись більше про участь Альпера в Libreboot, читаючи його
-запис на [сторінці зі списком усіх учасників, минулих і теперішніх](contrib.uk.md)
+запис на [сторінці зі списком усіх учасників, минулих і теперішніх](contrib.md)
 Потрібні розробники!
 ==================