Стаття: 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 не оприлюднить вихідний код, вони готові подати новий позов до суду (на додаток до вже існуючих).

Проєкти Arch Linux 32 та MidnightBSD заблокували (перше, друге) доступ із Бразилії через закон про перевірку віку

17 березня в Бразилії набув чинності закон 15.211/2025 Digital ECA, який запроваджує систему контролю доступу неповнолітніх до цифрового контенту. На відміну від каліфорнійського закону, він передбачає вищі штрафи та суворіші вимоги. Закон передбачає штрафи в розмірі до 10 відсотків від річного доходу або від 2 до 200 доларів за кожного зареєстрованого користувача за відсутності доходу, але в сумі не більше 13 млн доларів.

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

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

При спробі звернення до сайтів, форумів, завантажень, пакетів та wiki проєктів з Бразилії тепер виводиться сторінка про блокування доступу.

P.S. Проєкт Arch Linux 32 розвивається як незалежний форк і не пов'язаний з Arch Linux.