Цього року FreeBSD може довести до ладу підтримку Rust в ядрі [екскурс досягнень за 4 квартал 2025 року]

Проєкт FreeBSD опублікував звіт про стан справ за 4 квартал 2025 року, в якому описується прогрес поліпшень за останній квартал. Тим часом, серед робіт, які очікуються цього року в FreeBSD - доведення до ладу підтримки Rust в ядрі.

-

Головний розробник Айртон Муньос, який з 2024 року займається підтримкою Rust в ядрі, днями представив простий, але робочий драйвер - звуковий драйвер virtio. Деякі інтерфейси, які він використовує, знаходяться в стадії зміни, але драйвер досить функціональний для відтворення музики в QEMU.

Наразі підтримуються тільки x86-64 і aarch64, а інші архітектури, що підтримуються LLVM, за наявності інтересу можуть бути додані.

Крім QEMU, він також тестував драйвери на Rust для ARM64 Apple. Це був початковий варіант використання і включає в себе взяття деяких незавершених низькорівневих драйверів, як, наприклад, драйвер HID DockChannel для клавіатури на MacBook M2.

-

Перейду до інших нововведень: було профінансовано роботу над Sylve - новим веб-інтерфейсом управління для серверів FreeBSD. Крім того, було вдосконалено аудіостек, підтримку OpenJDK Java, оновлено драйвери бездротових мереж, покращено функції призупинення/відновлення роботи тощо.

Розробники FreeBSD також продовжують роботу над підтримкою Software Bill of Materials, а також над подальшою модернізацією своєї інфраструктури.

Також, серед інших недавніх поліпшень FreeBSD можна відзначити роботу над прискорювачем QEMU vmm, розробку драйвера FreeBSD для Banana Pi R64, плани щодо переходу на OpenJDK 21 в якості стандартної версії Java, поліпшення робочого столу KDE Plasma в FreeBSD і багато іншого.

Embedded-Engineering-Roadmap - репозиторій з роадмапою, де послідовно зібрані всі матеріали, щоб увійти в Embedded Systems / Embedded Linux

Крім детально промальованої роадмапи, в репозиторії також представлені основні теми і концепції в embedded, покрокові навчальні шляхи від новачка до професіонала, список необхідних знань (інструменти, мікроконтролери, протоколи комунікації тощо) і рекомендовані ресурси (блоги, книги, статті, курси, тощо).

Гарний ресурс, щоб повторити або вивчити певну відсутню навичку.

https://github.com/m3y54m/embedded-engineering-roadmap

sudo-rs тепер за замовчуванням показує введення пароля, порушуючи 40-річні норми

Традиційно sudo не відображав пароль з міркувань безпеки, щоб не розкривати його довжину на випадок, якщо хтось дивиться/записує ваш екран. Але upstream sudo-rs тепер змінив стандартну поведінку з метою "поліпшення користувацького досвіду".

Це вирішує головну проблему UX для нових користувачів, але теоретично безпека погіршується, оскільки довжина пароля стає видимою для людей, які дивляться на ваш екран.

Після цього "нововведення" користувачі почали скаржитися: "Чому?! Це суперечить десятиліттям практики не повторювати довжину пароля, щоб захистити себе від поглядів інших людей". Але розробники не збираються відмовлятися від змін.

Парад маразму не закінчується: в Каліфорнії затверджено законопроєкт про інтеграцію в ОС API для перевірки віку

У штаті Каліфорнія схвалено сенатом і підписано губернатором законопроект, який набере чинності 1 січня 2027 року, що передбачає додавання в ОС можливості для вказання віку користувача на етапі реєстрації облікового запису і надання програмам інтерфейсу для визначення віку поточного користувача.

Розробник програми повинен використовувати отриману інформацію про вік для дотримання законопроєкта. За невиконання вимог передбачені штрафи до 2500 доларів за ненавмисне і до 7500 доларів за навмисне порушення щодо кожної постраждалої дитини.

І судячи з усього, дистрибутиви на базі Linux і використовувані ними репозиторії пакетів підпадають під дію прийнятого законопроекту, але поки що забезпечення підтримки законопроекту в Linux знаходиться на стадії обговорення.

Деякі учасники вважають, що буде достатньо написати на сайтах некомерційних дистрибутивів, що продукт не призначений для використання в Каліфорнії.

Стаття: Lisp в космосі
Оригінал: https://corecursive.com/lisp-in-space-with-ron-garret/

Deep Space 1 та Remote Agent

Адам: Його назвали Remote Agent, тому що він мав мати власну агентність. Так само як і прототипи ровера, він мав ціль і повинен був виконувати дії для досягнення цієї цілі. Але цього разу це був не контролер ровера, а контролер польоту.

Рон: Отже, програма New Millennium поділялася на дві категорії. Були місії далекого космосу, які виходили за межі земної орбіти, і були місії EO, що працювали на орбіті Землі. І нам випало летіти на першій місії далекого космосу - DS1, Deep Space 1, яка мала здійснити зближення з кометою та астероїдом. Крім того, на цій самій місії планувалося випробувати й продемонструвати цілу низку інших передових технологій. І спочатку планувалося, що всю місію повністю контролюватиме Remote Agent.

Проблеми управління проєктом

Адам: Але, на жаль, проблеми виникли ще до того, як усе зайшло так далеко.

Рон: І ось тут стає трохи делікатно. Мені потрібно бути дуже обережним, тому що я справді не хочу нікого образити - усі в команді були дуже здібними, розумними людьми і працювали надзвичайно наполегливо. Проблеми були радше управлінські, ніж технічні. У нас було чотири різні команди з трьох різних установ, яких зібрали разом, щоб побудувати цю систему, але ніхто насправді не відповідав за проєктування й інтеграцію фінальної системи. Усе ніби дозволили розвиватися "природним шляхом". І тому було багато перемовин, переконувань і, відверто кажучи, внутрішніх конфліктів та суперечок.

З технічного боку, зокрема, один із компонентів відрізнявся тим, що три з чотирьох компонентів були написані на LISP, а один із чотирьох - на C. І компонент, написаний на C, на початковому етапі постійно аварійно завершував роботу, тому що коли ти пишеш на C, ти мусиш дбати про всі ці низькорівневі деталі - і це просто типова річ, яка трапляється при програмуванні на C.

І зрештою вони все це владнали, але поки система постійно падала, це суттєво сповільнювало розробку. Ти запускаєш експеримент - і раптом усе аварійно завершується. Треба перезавантажуватися й знову все завантажувати, а це мінус 10 хвилин. Помнож це на кілька десятків разів на день - і ти вже серйозно відстаєш від графіка.

Адам: Тож я припускаю, що всі зробили висновок - не варто використовувати C.

Рон: Можна було б так подумати, але ні, саме такого висновку ніхто не зробив. Зараз, наскільки я знаю, бортове програмне забезпечення для керування польотом пишуть на C, просто дуже обережно - із великою кількістю тестів та інструментів аналізу, щоб усе працювало як слід. І їм вдалося змусити це працювати, і зробити систему надійною, але це вимагає колосальних зусиль. На жаль, у той час я не дуже вмів грати в політику, тому висловлювався різкіше, ніж варто було. Я образив багатьох людей, і, думаю, це мало не менший вплив на остаточний провал проєкту, ніж будь-що інше, тому що всі ці досвідчені фахівці, які знали, як керувати космічними апаратами, просто мене не любили й не хотіли мати справу з цим нахабним шмаркачем.

Адам: Так, упевненість Рона, мабуть, зачепила декого в JPL, але найбільші затримки спричинив саме час, потрібний для інтеграції цих чотирьох систем. У результаті автономну систему знизили до рівня льотного експерименту. Замість того щоб керувати Deep Space 1 протягом усього польоту, вона керувала ним лише три дні. Але навіть три дні керування космічним апаратом - це зовсім не проста справа. Тож різні команди наполегливо працювали, щоб зробити програмне забезпечення максимально надійним.

Виконавчий модуль

Адам: Частина Рона називалася "виконавчий модуль".

Рон: Це було програмне забезпечення, яке вирішувало: добре, що ми робитимемо далі - залежно від вхідних даних і можливих варіантів розвитку подій. Воно визначало, що саме космічний апарат робитиме щомиті. Його запрограмували ще однією спеціально створеною мовою, написаною на LISP. І, що кумедно, я зараз не можу пригадати назву цієї мови, що дуже дивно, бо це ж було моє дітище. Чому я не можу згадати її назву?

Цю мову спроєктували так, що, подібно до LISP, сама її структура не дозволяла писати код із певними типами проблем. І найбільшою проблемою, від якої вона мала захищати, були труднощі, що виникають у багатопотоковому коді - тобто в коді, який виконує більше ніж одну дію одночасно. Такий код сумнозвісно складний в управлінні.

Можуть виникати різноманітні тонкі, підступні й неінтуїтивні проблеми, які призводять до таких явищ, як race condition та deadlock. Тож цю мову було спроєктовано так, щоб сама її структура унеможливлювала появу подібних труднощів. Більше того, код пройшов формальний аналіз - у нас був формальний доказ того, що інваріанти безпеки, які ця мова мала гарантувати, справді зберігаються.

Адам: Ого.

Рон: Отже, у нас був формальний доказ, і, звісно, ми провели масштабне наземне тестування. Систему тестували днями й днями в симуляції. І коли я кажу "в симуляції", це означає, що вона працювала на копії бортового обладнання; єдине, що симулювалося, - це те, що ми не перебували в космосі. Усе обладнання було тим самим або точною копією того, що мало летіти. Тож у нас був формальний доказ коректності й масштабні наземні випробування без жодних проблем.

Ми були абсолютно впевнені, що все спрацює. Але воно не спрацювало.

Збій у глибокому космосі

Це сталося приблизно на другий день із триденного експерименту. Люди в цей час спали, але дуже мало. Мої спогади про деталі трохи розмиті, але це була ситуація "всі до роботи", тому що сценарій було спроєктовано із запобіжниками, тож імовірність фактичної втрати космічного апарата була дуже низькою - навіть якщо Remote Agent припустився помилки.

Але сам факт, що він дав збій, - це вже був помаранчевий, якщо не червоний рівень тривоги.

Адам: Він перестав ухвалювати рішення чи просто завис?

Рон: Настав момент, коли він мав щось зробити. Цей момент настав і минув - а він не зробив того, що мав зробити. І пролунали тривожні сигнали

Адам: Де це було?

Рон: У космосі. За 150 мільйонів миль від нас. Затримка сигналу - година туди й назад.

Налагодження коду в космосі

Адам: Вау. Тобто тепер час налагоджувати інцидент у продакшені, але це не код, що працює на сервері в хмарі - цей код за світлову годину в обидва боки від нас. Це код у глибокому космосі. І щоб виправити проблему, є Рон, який написав мову програмування, і є хлопець, якого він найняв допомагати з кодом космічного апарата.

Рон: Я найняв цього хлопця частково для того, щоб передати йому відповідальність за кодування й трохи відійти від процесу, бо розумів, що не дуже ефективний. Я був молодий, недосвідчений і на той момент дуже поганий менеджер. І я не передав йому завдання належним чином. Я фактично просто сказав: ось що потрібно зробити - іди зроби.

Адам: І він зробив. Він усе реалізував. Але тепер цей код, який формально доведено як вільний від deadlock’ів, здається, завис за 150 мільйонів миль від дому. І Рону доводиться знову втрутитися й узяти все під контроль.

Рон: Цей хлопець був на мене роздратований. Місяцями він буквально був "в окопах", роблячи за мене чорнову роботу. Це була ситуація "всі до роботи", а я повертався як такий собі білий лицар, щоб знову врятувати становище, як я це нібито так майстерно робив раніше. Він сказав мені йти куди подалі, що стало для мене сюрпризом, бо я не усвідомлював, що напруження дійшло до такого рівня. Зараз, у ретроспективі, його реакція цілком зрозуміла, але тоді це стало для мене повною несподіванкою.

Адам: Емоції зашкалюють, і настав час налагоджувати проблему. І що більше минає часу, то більше Deep Space 1 відхиляється від курсу.

Надсилання S-виразів

Рон: Ми не мали жодного уявлення, що відбувається. Єдине, що ми знали, - це те, що телеметрія, яку апарат мав надіслати назад, не надійшла, і тепер треба було вирішувати, що робити далі. І кожного разу, коли ми щось вирішували, ми це робили - а потім сиділи й чекали годину на результат.

Адам: Тобто на той момент, коли ви дізналися, що він не зробив той маневр, це вже сталося годину тому.

Рон: Ну, це було пів години тому, бо пів години сигнал летить туди і пів години назад. З цими розрахунками часу все стає дуже дивним, розумієш? Тож фактично - так, це було годину тому.

Адам: А як це працює? Як ви з ним комунікуєте?

Рон: Гарне питання. Ти знайомий із Python, так?

Адам: Так.

Рон: Коли ти програмуєш на Python, у тебе є REPL - read-eval-print-loop. Тобто ти можеш програмувати інтерактивно, а не лише записувати код у файл і запускати його як звичайну програму. Так от, LISP був піонером цього підходу. Звичайний спосіб взаємодії з LISP - через REPL. Це була перша мова з такою можливістю, і протягом десятиліть - єдина. Саме тому вона давала величезну перевагу на ранніх етапах.

І в нас був REPL, що працював безпосередньо на космічному апараті. Ми могли взаємодіяти з апаратом через цей REPL. Але доступ до нього не означав, що можна просто сісти за термінал і щось надрукувати, бо щоб зв’язатися з цим REPL, потрібно було проходити через Deep Space Network і враховувати годинну затримку сигналу туди й назад.

Тож на практиці процес виглядав так: ми сиділи в конференц-залі, ламали голову, сперечалися й намагалися вирішити, які команди надіслати. Зрештою доходили згоди щодо пакета команд, який слід відправити. Потім ці команди проходили процедуру перевірки, що включала кілька рівнів керівництва - і всі вони мали це схвалити.

Після затвердження пакет передавався оператору, спеціально навченому працювати з Deep Space Network. Він сідав за консоль, підключену до мережі, вводив ці команди і натискав велику червону кнопку, щоб надіслати їх на космічний апарат.

Сигнал ішов із консолі в будівлі JPL через спеціальну виділену дротову мережу до однієї з антен Deep Space Network. Таких антен у світі три - щоб забезпечити покриття всього неба.

Це гігантські 70-метрові антени - справді величезні інфраструктурні об’єкти. Я, чесно кажучи, не знаю всіх деталей того, що відбувається на самій станції - чи є там ще людина в процесі, чи все автоматизовано. Але зрештою сигнал виходить із цієї величезної 70-метрової антени й летить крізь космос зі швидкістю світла. Його приймає антена на борту космічного апарата, він проходить через складну систему декодування, перетворюється на біти, і ці біти потрапляють у LISP-систему так, ніби ти фізично сидів за терміналом і вводив їх із клавіатури.

Це був дуже формалізований і складний процес: люди в гарнітурах, як у кіно, проходили через чітку процедуру - "ми зараз надішлемо цю команду на космічний апарат", хтось інший відповідав: "так, вам дозволено надсилати команду".

І зрештою хлопець, який сидів за консоллю, натискав велику червону кнопку - і ми знову сиділи й чекали на результат. Потім дивилися на отримані дані й повторювали весь процес спочатку.

Адам: Це божевілля. Ви що, надсилали туди якесь велике дерево LISP-виразу чи як?..

Рон: Так. Ми надсилали S-вирази.

Адам: А що саме ви йому казали? Ви казали йому перезавантажитися? Він же активно працює. Що ви робите?

Рон: Перше, що ми йому сказали, - це надіслати нам backtrace. Тобто дамп стану системи: усіх процесів, що виконуються. Процесів, які чекають на якусь подію - і на що саме вони чекають. Це було перше, що ми зробили. Ця інформація повернулася, ми її переглянули - і практично одразу стало зрозуміло, що відбувається, бо був один процес, який чекав на подію, що вже мала статися. І це стало великою підказкою.

У підсумку виявилося, що проблема таки була в race condition - умові гонки, яка, як вважалося, була неможливою.

Доказ і припущення

Адам: Але ж було доведено, що це неможливо, правда?

Рон: Було доведено, що це неможливо - але доказ спирався на припущення. А припущення полягало в тому, що під час програмування використовуються лише конструкції цієї спеціально розробленої мови. Тобто доказ стверджував: якщо ви використовуєте конструкції цієї мови, то deadlock’ів не буде.

Це приблизно як сьогодні в Rust є "безпечна" частина мови й "небезпечна". У нас фактично було щось подібне, але ми не сформулювали це так явно. І чого ми не передбачили - так це того, що був розробник, якому доручили написати частину коду…

Адам: Це той самий хлопець, якого Рон найняв і який сказав йому "йди куди подалі"?

Рон: і йому потрібно було реалізувати певну функціональність. Він не зміг зрозуміти, як зробити це за допомогою конструкцій нашої мови, тому просто викликав нижчорівневу конструкцію в LISP, щоб усе запрацювало. І цим він обійшов гарантії безпеки, які забезпечувала мова.

І це була моя помилка. Я не пояснив достатньо чітко тому хлопцеві, якого найняв і який працював під моїм керівництвом, що так робити не можна. Я просто сказав: ось що потрібно зробити - іди зроби. І він зробив. Але я не наголосив, що не можна виходити за межі конструкцій мови.

На свій захист скажу: це навіть не було в мене в голові як щось, що потрібно окремо проговорювати. Я думав, що він сам це зрозуміє. І, очевидно, з перспективи часу це було нереалістичне очікування. Я недостатньо чітко пояснив, що так робити не слід. І він це зробив - не його провина, а моя. Саме це й стало причиною помилки.

Motorola оголосила про співпрацю з GrapheneOS

Компанія Motorola і проєкт GrapheneOS, що розробляє захищену вільну прошику на базі Android, домовилися про довгострокову співпрацю щодо посилення конфіденційності та безпеки смартфонів, а також розробку нових пристроїв, для яких буде надано офіційну підтримку прошивок на базі GrapheneOS.

На питання, чи буде на нових смартфонах Motorola можливість розблокування завантажувача, розробники GrapheneOS відповіли, що угода з Motorola включає підтримку встановлення сторонніх ОС на нові пристрої. Серед іншого, користувачі зможуть використовувати власні збірки GrapheneOS.

Відмінною рисою GrapheneOS є те, що він за замовчуванням не включає застосунки Google або служби Google Play. Користувачі можуть встановлювати служби Google Play як повністю ізольовані програми без спеціальних системних привілеїв, зберігаючи орієнтований на безпеку підхід проєкту.

Також в прошивці є можливість вибіркового управління доступом окремих програм до мережі, датчиків, адресної книги та периферії. За замовчуванням заборонено отримання інформації про IMEI, MAC-адресу, серійний номер SIM-карти та інші апаратні ідентифікатори. Читання з буфера обміну дозволено тільки програмам, в яких в даний момент активний фокус введення. Включені додаткові механізми ізоляції процесів, пов'язаних з Wi-Fi і Bluetooth, для запобігання витоків.

У GrapheneOS застосовується криптографічна верифікація завантажуваних компонентів і шифрування даних на рівні файлових систем ext4 і f2fs. Дані в системних розділах і в кожному профілі користувача шифруються різними ключами. На екрані блокування відображається кнопка завершення сеансу, після натискання якої ключі для розшифрування скидаються і сховище переводиться в неактивований стан.

Співробітник Wikimedia випадково запустив шкідливий JavaScript-хробак, який вразив Meta-Wiki

У процесі тестування обмежень на роботу з API з user scripts, інженер експериментував із завантаженням великої кількості випадкових скриптів, використовуючи реальні скрипти користувачів. Тестування при цьому здійснювалося з адмінського облікового запису, що мав доступ до редагування скрипта MediaWiki:Common.js і можливості завантажувати JavaScript-скрипти для всіх користувачів і сторінок.

Серед персональних скриптів виявився створений кілька років тому шкідливий скрипт test.js, який додає себе до всіх JavaScript-файлів "User:<username>/common.js" і "MediaWiki:Common.js", а також редагує або видаляє випадкові сторінки з приміткою про закриття проекту.

Запуск даного скрипта з адмінського облікового запису призвів до розміщення шкідливого коду в користувацьких JavaScript-скриптах на Meta-Wiki. Через запуск доданого хробака при відкритті сторінок Meta-Wiki іншими користувачами та адміністраторами Wikimedia виникла ланцюгова реакція - кілька тисяч сторінок було змінено, а у приблизно сотні користувачів було замінено персональні скрипти common.js.

Наразі стан постраждалих сторінок відновлено та повернуто можливість внесення змін.

На PlayStation 5 змогли запустити Linux і пограти в GTA 5

У підготовленій системі Ubuntu 24.04.4 повністю працює звук і відео з якістю 4K через HDMI, а також підтримуються всі USB-порти. Робоча конфігурація запущена з виставленням для ЦП частоти 3.2 ГГц, а для відеокарти - 2.0 ГГц. Також частота може бути додатково розігнана до 3.5 ГГц для ЦП і 2.23 ГГц для відеокарти, але в цьому випадку PS5 Slim швидко перегрівалася.

Продуктивності підготовленого Linuх-середовища виявилося достатньо для запуску гри GTA 5 з увімкненим трасуванням променів при роздільній здатності 1440p і частоті оновлення 60 кадрів в секунду.

Для обходу верифікації завантажувача і завантаження Linux-дистрибутива замість штатної прошивки задіяний експлойт Byepervisor, що працює тільки зі старими версіями прошивок (1.xx-2xx) і експлуатує дві уразливості в гіпервізорі. Для підтримки GPU AMD для PlayStation 5, підготовлено патч для Mesa, який запропоновано включити до основного складу Mesa.

Freedesktop закриває суперечливу пропозицію щодо впровадження API в XDG для перевірки віку

Останніми тижнями спільнота Linux зосередилася на дискусії щодо нового законодавства первірки віку у ОС, що викликало питання про те, як системи Linux можуть до цього пристосуватися.

У спробі вирішити це складне питання до XDG було подано запит на додання org.freedesktop.AgeVerification до інтерфейсу D-Bus (система міжпроцесної комунікації між програмою та ОС), щоб дозволити програмам запитувати в ОС вікову групу користувача.

Однак, як і слід було очікувати, пропозиція швидко викликала критику з боку розробників та членів спільноти. Серед занепокоєнь були питання щодо наслідків для конфіденційності, вбудовування політик, специфічних для певної юрисдикції, в інфраструктуру робочого столу, а також питання, чи повинна ця функціональність бути частиною основного простору імен Freedesktop.

Тож, зрештою, Freedesktop просто закрив запит на злиття і вказав, що подальша робота буде проводитися в рамках технологій таких як Flatpak.

Однак питання залишається відкритим, оскільки поки що не було зроблено жодних чітких заяв щодо того, як Linux і open source спільнота відреагують на це.

Фонд вільного ПЗ вимагає від Anthropic оприлюднити вихідний код ШІ Claude

У 2024 році автори книг подали позов проти Anthropic, звинувативши компанію у використанні понад 7 мільйонів книг із піратських бібліотек LibGen та Pirate Library Mirror для навчання своїх ШІ. Потім, у червні 2025 року, суд виніс рішення, що навчання ШІ на легально придбаних книгах є допустимим, а на піратських - ні.

Anthropic хотіла вирішити ситуацію легко й просто - грошима, але тут у справу втрутився Фонд вільного ПЗ.

Представники фонду, перебираючи викорстані книги, знайшли книгу "Free as in Freedom: Richard Stallman's Crusade for Free Software", авторські права на яку належать Фонду вільного ПЗ.

Ось тут і криється підводний камінь, адже книга видана за ліцензією GNU FDL, яка дозволяє вільне використання, але, у свою чергу, вимагає, щоб усі похідні роботи також залишалися вільними.

Фонд заявив, що гроші їх не цікавлять, і якщо Anthropic не оприлюднить вихідний код, вони готові подати новий позов до суду (на додаток до вже існуючих).