У ядрі Linux 7.1 гібернація може прискоритися в кілька разів при використанні повільних SSD-накопичувачів

Гібернація - енергозберігаючий режим ОС, при якому вміст ОЗУ зберігається на накопичувач перед вимкненням живлення. Після увімкнення живлення комп'ютера вміст пам'яті завантажується з диска в пам'ять, і користувач зможе продовжити роботу з того ж місця, на якому він зупинився, оскільки всі запущені раніше програми продовжать виконуватися.

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

Наприклад, для SSD Samsung 830, що використовує Serial ATA 2.0, ядро Linux 6.19 вимагає 324 секунди для переходу в режим гібернації, але з двома новими патчами цей час може скоротитися до 35 секунд! Практично в 9 разів швидше!

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

Патчі знаходиться на розгляді, але оскільки вже занадто пізно для циклу 7.0, швидше за все він буде включений у версію 7.1.

> https://lore.kernel.org/linux-mm/20260215-hibernate-perf-v2-0-cf28c75b04b7@tencent.com/

KDE спростувала чутки щодо обов'язкового використання systemd

Чутки почалися після оголошення KaOS, дистрибутива, давно відомого своєю глибокою прихильністю до робочого столу KDE Plasma, про те, що він планує відмовитися від нього. Основною причиною було названо використання залежності systemd в певному компоненті KDE.

Один з контриб'юторів заявив, що в Plasma 6.6 буде представлений новий Plasma Login Manager (PLM), який має замінити давно використовуваний SDDM. Однак, PLM має функціональну залежність від systemd. Це означає, що дистрибутиви Linux, які не використовують systemd, а також варіанти BSD, не зможуть його використовувати.

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

Хороша новина полягає в тому, що в своєму пості автор заявив, що KDE не планує робити основні компоненти залежними від systemd (як це зробили в GNOME). Таким чином, робоче середовище буде як і раніше функціонувати на системах без systemd і не Linux, таких як FreeBSD.

Дистрибутив Gentoo завершив перший етап міграції з GitHub на Codeberg

На початку цього року дистрибутив Gentoo Linux оголосив про плани перенести хостинг свого коду на Codeberg замість GitHub, і вони вже успішно реалізували можливості передачі змін в ebuild-репозиторій і підняли дзеркала для розробки portage, steve і gentoolkit.

Хоча підтримка Codeberg поки що реалізована на додаток до раніше використовуваної платформи GitHub, в подальшому планують поетапно повністю перевести процес передачі змін на Codeberg.

Бажання Gentoo відмовитися від GitHub було мотивоване навчанням Microsoft Copilot на GitHub репозиторіях.

> https://www.gentoo.org/news/2026/02/16/codeberg.html

P.S. Codeberg заснований на Forgejo і розміщений у Німеччині як некомерційний проект.

Цікава стаття про створення своєї нейронки з нуля на чистому Сі та математиці без сторонніх бібліотек

Стаття може навчити розуміти, як нейронка працює на рівні математики та коду без використання сторонніх ML-бібліотек (тільки стандартний набір GNU C), а також розуміння її архітектури.

Вихідний код і саму статтю можна знайти в репозиторії: https://github.com/vixhal-baraiya/microgpt-c

Опитування Bitwarden виявило найкращі інструменти для захисту приватності у 2026 році

Bitwarden опублікував результати опитування за 2026 рік, в якому показано, які браузери, поштові сервіси, VPN, месенджери, тощо найбільш популярні серед користувачів.

Серед браузерів перше місце посідає Brave (38%), за ним йде Mozilla Firefox (31%). У рейтингу також присутні LibreWolf (8%), Vivaldi (8%), DuckDuckGo (1%) і Tor Browser (1%), але з набагато нижчим рівнем використання.

У сфері електронної пошти лідирує Proton Mail (50%), за ним йдуть Tuta Mail (16%), Mozilla Thunderbird (13%) і FastMail (3%). SimpleLogin, DuckDuckGo і Addy.io - найпопулярніші сервіси електронної пошти з псевдонімами.

В месенджерах лідером є Signal (55%), за ним йде Telegram (19%), а за ними вже йдуть Session (3%), Threema (3%) і Element (2%).

Найулюбленіші пошукові системи - DuckDuckGo (35%) і Brave (26%), а потім йдуть StartPage (12%), Ecosia (5%) і Qwant (4%).

Також, в опитуванні вони торкнулися не менш важливої теми ШІ: 28% людей заявили, що не користуються ШІ, бо не хочуть щоб він вчився на їхніх даних, потім йде трійка лідерів Duck.ai (14%), Brave Leo (13%) і Ollama (11%), а далі Lumo (5%), Kagi (3%) і Venice AI (2%).

З кінця січня Microsoft Copilot через баг міг читати і підсумовувати конфіденційні листи, ігноруючи політику захисту від витоку даних

Баг отримав ідентифікатор CW1226324, і вперше його зафіксували 21 січня. Проблема стосується функції чату на вкладці Work в Copilot Chat. Саме там помічник некоректно обробляв листи з папок "Надіслані" та "Чернетки", включаючи ті, що містили позначки про конфіденційність. Такі позначки повинні забороняти автоматичним системам (включаючи Copilot) аналізувати вміст листів.

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

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

Ladybird почне переписувати движок браузера з C++ на Rust за допомогою ШІ

Засновник Андреас Клінг сказав, що команда розглядала Swift як можливу заміну C++. Однак Swift погано працював з C++ і мав обмежену підтримку за межами Apple. Rust, з іншого боку, має сильну спільноту і більш знайомий учасникам проєкту.

Портування згенерувало близько 25 тисяч рядків коду Rust і зайняло близько 2 тижнів. Процес очолили люди, але інструменти ШІ, такі як Claude Code і Codex, допомогли з сотнями невеликих підказок.

Тестування підтвердило, що команда досягла своєї мети. Версія Rust пройшла 52 898 тестів і 12 461 регресійних тестів Ladybird без будь-яких нових помилок. Розробники також заявили, що продуктивність залишилася колишньою для всіх відстежуваних завдань JavaScript.

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

> https://ladybird.org/posts/adopting-rust/

Цього року 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, щоб усе запрацювало. І цим він обійшов гарантії безпеки, які забезпечувала мова.

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

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