| · | 17.10 | Исследователи из Anthropic воссоздали формирование seed-параметров стандартных эллиптических кривых ECDSA (51 +6) |
|
Группа исследователей из компании Anthropic объявила об успешном определении происхождения исходных seed-параметров, задающих форму эллиптических кривых ECDSA P-192, P-224, P-256, P-384 и P-521, стандартизированных Национальным институтом стандартов и технологий США (NIST). Воссозданный алгоритм генерации seed-параметров подтверждает надёжность ECDSA и опровергает популярную конспирологическую теорию о том, что исходные параметры для стандартизированных эллиптических кривых, изначально разработанных в АНБ, были специально подобраны для оставления слабых мест, компрометирующих алгоритмы цифровой подписи ECDSA.
Появлению подобной теории заговора способствовала непрозрачность процесса выбора seed-параметров на фоне выявление потенциального бэкдора в генераторе псевдослучайных чисел Dual_EC_DRBG, входившем в стандарт NIST. Информация о том, как были сгенерированы параметры для инициализации стандартизированных в NIST эллиптических кривых не раскрывалась. Предполагалось, что параметры были созданы в 1997 году на основе хэшей от фраз, экспромтом придуманных Джерри Солинасом (Jerry Solinas), но затем забытых. В ходе проведённого в Anthropic исследования AI-модель Claude определила, что seed-параметры были созданы с использованием псевдослучайных чисел, полученных при помощи входящей в стандартную Си-библиотеку функции lrand48, инициализированной значениями текущего эпохального времени. Наводкой на возможность использования случайных чисел, полученных через функцию lrand48, послужили характерные для её использования шаблоны, такие как возврат только старших 31 бит из 48-битного внутреннего состояния генератора псевдослучайных чисел. Для восстановления состояния генератора псевдослучайных чисел был применён алгоритм редукции базиса, после чего с имеющимися seed-параметрами перебором сопоставлялись SHA-1 хэши от получаемых через lrand48 наборов чисел необходимой длины. Попытки повторялись c переинициализацией генератора через функцию srand48() для моментов времени в 1997-1998 годах, в которых происходила разработка ECDSA. При этом оказалось, что не все подходящие для надёжных эллиптических кривых значения принимались создателями ECDSA, некоторые значения пропускались, но подобные единичные пропуски трактуются не как злонамеренные действия, а как отсутствие точных сведений о критериях выбора. ![]() Для шести вариантов эллиптических кривых ECDSA также удалось определить происхождение базовых точек, которые оказались сгенерированы с помощью генератора псевдослучайных чисел из библиотеки FreeLIP с использованием простых значений инициализации, таких как 20000 для P-192 и 20420 для prime239v1. За определение происхождения seed-параметров исследователям из Anthropic присуждена учреждённая три года назад премия в $36864, которую команда исследователей пожертвовала некоммерческой организации ISRG, развивающей проект Let’s Encrypt. Учредивший премию криптограф Филиппо Валсорда (Filippo Valsorda) заявил, что теперь лично ставит кривые ECDSA выше Curve25519, Ed25519 и X25519, и будет рекомендовать их в первую очередь.
| ||
|
Обсуждение (51 +6) |
Тип: К сведению |
Интересно
| ||
| · | 17.10 | Новые версии Wine 11.20 и Wine-staging 11.20 (6 +6) |
|
Опубликован экспериментальный выпуск открытой реализации Win32 API - Wine 11.20. С момента выпуска 11.19 был закрыто 24 отчёта об ошибках и внесено 341 изменение.
Наиболее важные изменения:
Параллельно сформирован выпуск проекта Wine Staging 11.20, предоставляющего расширенные сборки Wine, включающие не полностью готовые или рискованные патчи, пока непригодные для принятия в основную ветку Wine. По сравнению с Wine в Wine Staging предоставляется 279 дополнительных патчей. В новом выпуске Wine Staging осуществлена синхронизация с кодовой базой Wine 11.20 и обновлён код vkd3d. В основной состав Wine перенесены патчи, улучшающие в wininet обработку некорректных параметров в APPINFO_QueryOption и HTTPREQ_QueryOption.
| ||
|
Обсуждение (6 +6) |
Тип: Программы |
| ||
| · | 17.10 | ESP-KVM 0.65.0 и прошивка, превращающая планшет M5Stack Tab5 в экран для IP-KVM (23 +5) |
|
Выпущена новая версия ESP-KVM 0.65.0, открытой прошивки, превращающей плату на микроконтроллере ESP32-P4 в IP-KVM с доступом к экрану, клавиатуре и мыши удалённого компьютера через браузер. Устройство подключается перед HDMI целевой машины и прикидывается для неё USB-клавиатурой и мышью, а картинку и управление отдаёт в браузер. На целевую машину ничего ставить не надо, работает хоть в BIOS. Код написан на языке Си и распространяется под лицензией Apache 2.0.
Одновременно опубликован отдельный экспериментальный проект - ESP-KVM terminal, развивающий прошивку для планшета M5Stack Tab5, в котором используется тот же SoC ESP32-P4, что и в KVM. Терминал подключается к ESP-KVM по сети как обычный зритель, только вместо вкладки браузера у него пятидюймовый экран 1280x720. ![]() Кадры MJPEG разжимает аппаратный декодер JPEG, а блок PPA масштабирует их и поворачивает сразу в буфер дисплея. Выходит до 20 кадров в секунду, если KVM успевает отдавать их по WiFi. В ESP32-P4 нет аппаратного декодера H.264, поэтому на KVM нужно включить MJPEG. KVM в сети терминал находит сам. Для управления указателем используется сенсорный экран, а вводить текст можно на клавиатуре для Tab5 или на обычной USB-клавиатуре. Выпуск ESP-KVM 0.65.0 почти целиком сосредоточен оптимизации работы через медленные каналы. По WiFi устройство слало кадры быстрее, чем Tab5 успевал их принимать. Очередь росла, и экран отставал на пару секунд. Теперь устройство отображения подтверждает каждый кадр, а отправляющее устройство держит в пути не больше двух кадров. Без подобной синхронизации Tab5 в той же сети показывал около 3 кадров в секунду, а с подтверждениями - 8-9. ESP-KVM сначала сообщает, что понимает подтверждения, и только тогда клиент их шлёт. Через Tailscale видео шло ещё медленнее: 1-3 кадра в секунду между двумя ESP32-P4 в одной сети WiFi. Весь туннель идёт через один UDP-сокет, а его очередь приёма вмещала 6 пакетов, когда пачка видео - около 45. Отправка, которую обрывал таймаут, оставляла в соединении половину кадра WebSocket, и зритель терял разметку потока. Алгоритм Нейгла придерживал каждое короткое сообщение на 200-450 мс, из-за чего пинг между терминалом и KVM после TCP_NODELAY упал с 440 до 15 мс. После перезапуска одной стороны узлы не могли снова договориться, потому что новая попытка рукопожатия затирала предыдущую раньше, чем на неё приходил ответ. При каждом переходе между прямым путём и ретранслятором DERP рукопожатие начиналось заново, примерно раз в 15 секунд, хотя ключам сессии путь безразличен. После правок получилось 11-14 fps при 720p, почти как в локальной сети. Коротко об изменениях в ESP-KVM после прошлой новости о выпуске ESP-KVM 0.51.0:
Прошивка собирается для 15 плат на ESP32-P4. Чтобы было проще выбрать, на сайте появилось сравнение плат ESP32-P4 для IP-KVM: ревизия чипа, память, размер платы в масштабе, Ethernet, PoE и Wi-Fi, подходящий адаптер HDMI и замеренная частота кадров. Отдельно есть сравнение плат захвата HDMI - мост, шлейфы, проход HDMI на монитор, CEC и звук.
| ||
| · | 17.10 | В компиляторе Nimony для будущего Nim 3.0 реализованы самокомпиляция и JavaScript-бэкенд (22 +5) |
|
Андреас Румпф (Andreas Rumpf, Araq), автор языка программирования Nim, опубликовал серию отчётов о прогрессе разработки компилятора Nimony, создаваемого как основа для будущего релиза Nim 3.0. На данный момент уже доступен восьмой отчёт. Ключевое достижение последнего времени - переход к самокомпиляции: весь стек инструментов, включая фронтенд, прослойку (middle-end), оптимизатор и бэкенд, теперь может быть собран самим Nimony. Дополнительно реализованы JavaScript-бэкенд, поддержка всех четырёх актуальных режимов управления памятью и работа на платформе FreeBSD. Код проекта написан на Nim и распространяется под лицензией MIT.
Nimony - новая реализация языка Nim, практически не использующая кодовую базу существующего компилятора: с нуля написаны семантический анализ, обобщённые процедуры, разворачивание шаблонов, управление памятью и генерация кода. Цели проекта - инкрементальная перекомпиляция, полностью параллельные сборки, отказ от обязательных предварительных объявлений процедур и типов, типобезопасные дженерики и единая модель конкурентности на основе продолжений (continuations). Этапы компиляции обмениваются данными через текстовый формат NIF, а вместо исполнения макросов в виртуальной машине применяются плагины, компилируемые в нативные исполняемые файлы. Основные изменения за прошедшие месяцы:
При тестировании потребления памяти на системе с чипом Apple M1 самый требовательный к памяти процесс фронтенда занимает 45 МиБ, бэкенда - 111 МиБ, а суммарное потребление при восьми одновременно работающих процессах достигает 171 МиБ. Сборка тех же компонентов компилятором Nim 2 требует примерно в пять раз больше памяти, что в значительной мере обусловлено применением clang. Целью на текущий год в README проекта названа готовность компилятора к промышленному использованию для проектов, укладывающихся в задокументированный набор возможностей. В начале года темп разработки снизился из-за параллельной работы над системой инкрементальной компиляции в Nim 2. Модуль httpclient с собственной реализацией TLS создан для отработки применения Nim в роли встроенного ассемблера.
| ||
| · | 17.10 | Выпуск OpenRGB 1.1, инструментария для управления RGB-подсветкой (4 +1) |
|
После месяца разработки опубликован релиз проекта OpenRGB 1.1, развивающего инструментарий для управления RGB-подсветкой компонентов ПК и периферийных устройств. Код написан на C/C++ и распространяется под лицензией GPLv2. Готовые сборки сформированы для Linux (deb, rpm, appimage, flatpak), macOS и Windows.
Релиз сфокусирован на исправлении ошибок, выявленных после выхода версии 1.0. Среди исправленных проблем:
Одновременно выпущены плагины OpenRGB Effects Plugin 1.1 с исправлением ошибок и OpenRGB Skin Plugin с поддержкой версии OpenRGB 1.0. Обновление других плагинов не потребуется, пересоздавать профили не нужно, кроме случаев обновления с версий 0.9 или более старых. На платформе Windows, для взаимодействия с подсветкой ОЗУ или старых материнских плат, потребуется установить драйвер pawnio и запускать OpenRGB от имени администратора, или установить OpenRGB в качестве фонового сервиса. ![]() Проект OpenRGB сфокусирован на предоставлении унифицированного доступа к аппаратным возможностям контроллеров подсветки, будь то встроенные эффекты или прямое управление цветом. Функциональность пользовательских эффектов, не встроенных в контроллер, таких как визуализация звука, цветовое отображение температуры, AmbiLight, смена подсветки при переключении окон или просто красивое переливание как в лавовой лампе - вынесена в плагины. Дополнительные возможности по кастомизации подсветки предоставляет внешний API (сетевой SDK), позволяющий передавать команды на изменение подсветки из любой сторонней программы или скрипта. Среди прочего, пакет поддерживает материнские платы ASUS, Gigabyte, ASRock и MSI с RGB-подсистемой для подсветки корпуса, модули памяти с подсветкой (ASUS, Patriot, Corsair, HyperX и т.п.), графические карты (например, ASUS Aura/ROG, MSI GeForce, Sapphire Nitro, Gigabyte Aorus) и различные контроллеры светодиодных лент (ThermalTake, Corsair, NZXT Hue+), светящиеся кулеры, мыши, клавиатуры, наушники и аксессуары Razer с подсветкой. В списке поддерживаемых устройств часть контроллеров может быть подписана названиями, не совпадающими с торговыми (оперативная память Asus Aura и некоторых других производителей в списке подписана как ENE DRAM), и некоторые пункты объединяют под собой сразу несколько моделей устройств.
| ||
| · | 16.10 | Разработчик Firefox провёл сравнительное тестирование форматов JPEG XL и AVIF (53 +25) |
|
Джейк Арчибальд (Jake Archibald), участвующий в разработке Firefox, провёл исследование, в котором сравнил форматы JPEG XL и AVIF, используя стандартный кодек libavif, стандартный кодек libjxl и новый кодек jixel, написанный на Rust и задействованный в Firefox и Chrome. Форматы тестировались в одинаковых условиях, которые включали кодирование с потерями, а для анализа результатов использовались показатели SSIMULACRA2, определяющие степень отличия от исходного изображения без потерь. В большинстве тестов формат AVIF показал лучшие результаты и при аналогичном уровне качества позволял создавать файлы меньшего размера, которые требовали меньше процессорного времени для сжатия и распаковки.
При сжатии фотографий с потерями для веб-ресурсов с настройками эффективности сжатия (баланс между временем кодирования и уровнем сжатия) по умолчанию файлы JPEG XL получались обычно на 15-25% больше аналогичных файлов AVIF (libavif). При максимальных уровнях сжатия разрыв сокращался до 6-20%. В отдельных тестах JPEG XL приближался к AVIF (libavif) или даже превосходил его. При этом на результат JPEG XL влияет выбор кодировщика: новый кодировщик jixel, как правило, создаёт файлы меньшего размера, чем libjxl, за исключением случаев, когда изображение содержит сложную прозрачность. Для скриншотов и иллюстраций формат AVIF значительно лучше, чем JPEG XL. При настройках по умолчанию размер файлов JPEG XL был на 30-90% больше, а при максимальных уровнях сжатия - на 20-70% больше. Отмечается, что AVIF отлично справляется с такими изображениями при сжатии с потерями, поэтому использование форматов без потерь оправдано только в тех случаях, когда требуется абсолютная точность передачи данных (побитовое совпадение). Для изображений с прозрачностью AVIF также значительно превосходит JPEG XL. При использовании libjxl файлы получаются на 31-44% больше при настройках по умолчанию или на 61-70% больше при максимальных уровнях сжатия. Кодировщик jixel всегда сохраняет прозрачность без потерь, из-за чего его файлы в 2-3 раза превышают по размеру аналогичные файлы AVIF, созданные libavif. Как правило, AVIF (libavif) быстрее производит кодирование и потребляет меньше памяти с учётом размера итогового файла. Кодировщик jixel работает быстрее libavif и требует меньше памяти, однако создаваемые им файлы обычно значительно крупнее. Декодирование в AVIF происходит быстрее. Для JPEG XL декодирование обычно требует в 2-3 раза больше времени при среднем качестве, однако при очень высоком качестве разрыв сокращается - в таких случаях браузер Chrome иногда декодирует JPEG XL даже быстрее. Использование более высоких уровней сжатия оправдано для libavif и jixel, но не для libjxl. В случае с libjxl высокие уровни сжатия значительно замедляют процесс, требуют гораздо больше оперативной памяти и практически не улучшают результат. Иногда файлы, полученные при таких настройках, оказываются даже больше, чем при использовании настроек по умолчанию. Режим 4:2:0 в AVIF (с пониженным вдвое цветовым разрешением) редко приводит к уменьшению размера файла, но при этом затрудняет достижение высокого качества изображения. Но кодирование и декодирование в этом режиме происходят быстрее. Настройки качества работают предсказуемо во всех кодировщиках. При одном и том же значении параметра качество итогового изображения может немного варьироваться, но у всех кодировщиков эти отклонения происходят однородно и выглядят вполне логично. В JPEG XL при выборе высоких уровней сжатия использование прогрессивного вывода практически не требует дополнительных затрат. В jixel недавно появилась поддержка предварительного прогрессивного отображения: при максимальной интенсивности сжатия это почти не влияет на результат, однако при настройках по умолчанию размер файла увеличивается на 12%. Браузеры Firefox и Chrome поддерживают прогрессивный JPEG XL. Safari отображает финальное изображение, но не показывает промежуточные прогрессивные стадии. В AVIF с недавних пор тоже поддерживается прогрессивный вывод. Пока эта функция доступна только в Chrome, но работа над её внедрением в Firefox уже ведётся. Реализация этого механизма в AVIF сложнее, чем в JPEG XL, зато он даёт больше контроля над тем, как будет выглядеть предварительное изображение, а файлы обычно получаются меньше и декодируются значительно быстрее. Что касается HDR, то в JPEG XL отсутствуют "карты усиления" (gain maps), что является существенным недостатком по сравнению с AVIF. Формат JPEG XL поддерживает такие карты, но браузерные декодеры их пока не распознают, а процесс кодирования остаётся непроработанным или экспериментальным. При сравнении HDR-контента без использования карт усиления два применённых в тестах показателя качества дают противоречивые результаты, однако оба сходятся в том, что JPEG XL позволяет получить файлы меньшего размера, чем AVIF. JPEG XL даёт возможность уменьшить размер существующих JPEG-файлов на 9-20% без дополнительной потери качества. Скорость декодирования у него такая же или даже выше (за исключением изображений небольшого размера). В режиме сжатия без потерь (lossless) лидирует JPEG XL. Формат WebP (без потерь) позволяет получить файлы на 9-17% больше, а AVIF (без потерь) - на 30-120% больше. При настройках максимального сжатия без потерь в jixel зачастую создаются файлы, которые декодируются слишком медленно.
| ||
| · | 16.10 | Опубликована мобильная платформа Ubuntu Touch 24.04-2.1 (14 +9) |
|
Представлена прошивка Ubuntu Touch 24.04-2.1, продолжающая развитие ветки на пакетной базе Ubuntu 24.04. Прошивка развивается проектом UBports, взявшим в свои руки разработку мобильной платформы Ubuntu Touch, после того как от неё отстранилась компания Canonical. Проектом также развивается экспериментальный порт рабочего стола Unity 8, который переименован в Lomiri.
Среди изменений в Ubuntu Touch 24.04-2.1:
![]()
| ||
|
Обсуждение (14 +9) |
Тип: Программы |
| ||
| · | 16.10 | Проект GNOME представил предварительный выпуск GNOME OS для обычных пользователей (37 +1) |
|
Проект GNOME начал формирование сборок дистрибутива "GNOME OS Preview", основанных на последнем стабильном релизе GNOME 51.1 и предназначенных для ознакомления обычными пользователями. До этого публиковались только ночные сборки GNOME OS, основанные на срезе находящейся в разработке кодовой базы GNOME из Git и ориентированные на применение разработчиками и тестировщиками проекта. Размер предлагаемого для загрузки iso-образа 3.7 ГБ.
GNOME OS использует компонент systemd-sysupdate для организации атомарного обновления системы и формат пакетов flatpak для установки дополнительных программ. Для установки задействован прототип инсталлятора. Из недавних улучшений в GNOME OS отмечены:
Сборка GNOME OS Preview пока позиционируется как экспериментальная и будет объявлена стабильной после реализации недоделанных возможностей и поддержки механизмов подготовки, доставки и установки обновлений для поддержания системы в актуальном состоянии. Среди планов на будущее:
| ||
|
Обсуждение (37 +1) |
Тип: К сведению |
| ||
| · | 16.10 | PwnEscape - уязвимость в сетевом стеке ядра Linux, позволяющая обойти изоляцию гипервизоров и контейнеров (86 +28) |
|
В ядре Linux выявлена критическая уязвимость (CVE-2026-99999, PwnEscape) в стеке IPv4, позволяющая получить доступ к памяти хост-окружения из гостевой системы. При успешной эксплуатации уязвимости пользователь гостевой системы может выполнить код с правами ядра на стороне хост-окружения. Эксплуатация уязвимости продемонстрирована в окружении на базе гипервизора KVM, но так как уязвимость вызвана ошибкой не в гипервизоре, а в механизме обработки сетевых пакетов ядром Linux, потенциально эксплоит может быть адаптирован и для других гипервизоров и механизмов изоляции, в которых используется штатный сетевой стек Linux.
Проблема вызвана некорректной последовательностью операций при проверке контрольной суммы сетевого пакета, позволяющей изменить заголовок IPv4 в момент после проверки корректности информации, но до выполнения действий с ним (TOCTOU - Time-Of-Check-To-Time-Of-Use). При определённых условиях вычисление контрольной суммы выполняется в отложенном режиме, уже после разбора и проверки сетевого пакета, что может привести к изменению уже проверенных данных и чтению до 32 байт из области памяти вне буфера, в котором происходит обработка пакета. Атака производится через отправку из гостевой системы пакета с флагом CHECKSUM_PARTIAL, при котором контрольная сумма вычисляется не сразу, и специально подобранными значениями skb->csum_start и skb->csum_offset. Пакет проходит проверку в сетевом стеке, так как длина заголовка корректна и равна 20 байт. Завершение вычисления контрольной суммы осуществляется при обработке фрагментации, но из-за некорректных значений csum_start и csum_offset результат записывается в самое начало IPv4-заголовка и изменяет первый байт, хранящий размер, увеличивая его 20 до 60 байт. При дальнейшей обработке ядро считает, что размер заголовка теперь 60 байт, при копировании читает дополнительные 40 байт (c учётом хвостовых служебных 8 байт, читается 32 байта из области вне буфера) и отправляет обратно в составе секции с IP-опциями. В подготовленном эксплоите утечку 32 байт удалось использовать для контролируемой перезаписи 64 байт в памяти ядра и добиться выполнения кода на стороне хост-окружения с правами root. Исследователи пока не опубликовали технические детали данной стадии атаки и код эксплоита, чтобы дать пользователям время на установку обновления. Предположительно, утечка вначале используется для воссоздания раскладки памяти ядра в обход рандомизации KASLR, после чего создаются условия для выделения целевой структуры ядра с указателем сразу за памятью с буфером пакета и инициируется действие, приводящее к изменению данных в секции с IP-опциями, выходящими за границу буфера. Уязвимость устранена во вчерашних обновлениях ядра Linux 7.2.11, 6.18.57, 6.12.113, 6.6.159, 6.1.190, 5.15.223 и 5.10.272.
| ||
|
Обсуждение (86 +28) |
Тип: Проблемы безопасности |
| ||
| · | 16.10 | Выпуск загрузочной прошивки Libreboot 26.10 с добавлением поддержки 239 устройств (73 +19) |
|
Опубликован релиз свободной загрузочной прошивки Libreboot 26.10, который получил статус стабильного выпуска. Проект развивает готовую сборку проекта Coreboot, предоставляющую замену проприетарным прошивкам UEFI и BIOS, отвечающим за инициализации CPU, памяти, периферийных устройств и других компонентов оборудования, с минимизацией бинарных вставок.
Libreboot нацелен на формирование системного окружения, позволяющего обойтись без проприетарного ПО настолько, насколько это возможно, не только на уровне операционной системы, но и прошивки, обеспечивающей загрузку. Libreboot дополняет Coreboot средствами для упрощения применения конечными пользователями, формируя готовый дистрибутив, которым может воспользоваться любой пользователь, не имеющий специальных навыков. По сравнению с прошлым стабильным релизом добавлена поддержка 222 моделей Google Chromebook на базе процессоров Intel и AMD, 9 редакций ноутбуков Purism Librem 13/14/15/Mini, а также моделей Samsung Lumpy и Stumpy, ThinkPad X301, ThinkPad X270 и ThinkPad X280 Помимо этого добавлена поддержка ПК Dell OptiPlex 5050 SFF и Dell OptiPlex 3040 Micro, материнской платы Supermicro X11SSH-F. Совместимость с новыми устройствами удалось наладить благодаря интеграции payload на базе EDK2 из coreboot-дистрибутива MrChromebox, позволившем обеспечить полную поддержку UEFI и ReBAR (PCIe Relocatable BAR). Поддержка ReBAR решила проблемы с использованием современных видеокарт с объёмом памяти больше 4 ГБ. EDK2 (реализация UEFI) задействован по умолчанию даже на старых устройствах, таких как ThinkPad X200 и T500, а ReBAR по умолчанию оключён из-за возникновения проблем с выводом в библиотеке libgfxinit на системах с GPU Intel. Поддержка UEFI протестирована при загрузке Windows 10/11, 9front (форк Plan 9), Linux-дистрибутивы с UKI или systemd-boot, OpenBSD с EFI-загрузчиком и разделами GPT, FreeBSD в режиме UEFI и RedoxOS. ReactOS не загружается из-за отсутствия поддержки UEFI. Обособленное использование GRUB и SeaBIOS объявлено устаревшим, но для обратной совместимости в EDK2 встроены EFI-сборки GRUB и SeaBIOS, вызываемые через нажатие ESC при загрузке. В состав EDK2 включены MemTest86+ и iPXE. Значительно расширена поддержка материнских плат для процессоров AMD Fam15h, таких как KGPE-D16. Для инициализации подобных плат задействован форк coreboot от проекта 15h.org, использующий код протокола инициализации AMD Agesa (AMD Generic Encapsulated Software Architecture), ранее опубликованный компанией AMD. По умолчанию при сборке выставлен бит HAP (High Assurance Platform) для отключения Intel ME. Обновлены версии Coreboot (от 18 сентября 2026 г.), EDK2 26.09.2, GRUB 2.16 и SeaBIOS (от 28 июля 2026 г.). В репозиторий добавлен файл AGENTS.md с запретом любого применения AI при подготовке изменений. В качестве причин упоминается экономическая неустойчивость AI-инфраструктура, подконтрольность технологий узкой группе людей и негативное влияние на разработчиков. По мнению автора Libreboot AI-инструменты отупляют и лишают профессиональных навыков, превращая даже талантливых специалистов в зависимых и некомпетентных потребителей. Оборудование, поддерживаемое в Libreboot:
| ||
|
Обсуждение (73 +19) |
Тип: Программы |
| ||
| · | 16.10 | Началось тестирование 64-разрядной версии клиента Steam для Linux (28 +47) |
|
Компания Valve опубликовала бета-версию обновлённого клиента сервиса доставки игр Steam для Linux. Выпуск примечателен формированием 64-разрядных сборок и переходом к выполнению клиента Steam внутри контейнера со Steam Runtime. Изменение существенно упрощает организацию работы Steam в дистрибутивах Linuх. До сих пор клиент Steam распространялся только в 32-разрядных сборках, что мешало дистрибутивам полностью прекратить поддержку 32-разрядных CPU и вынуждало специально для Steam поставлять необходимые 32-разрядные зависимости или упаковывать Steam в самодостаточные пакеты в форматах snap и flatpak.
В новой версии также предложен новый интерфейс для отслеживания и управления достижениями при прохождении игр. Окно с настройками уведомлений адаптировано для работы на экранах любого размера. Улучшена работа с библиотекой в offline-режиме. В Remote Play реализованы настройки для масштабирования вывода с учётом разных соотношений сторон экрана на локальной и удалённой системах.
| ||
|
Обсуждение (28 +47) |
Тип: Программы |
| ||
| · | 16.10 | Документальный фильм о проекте KDE (82 +24) |
|
Опубликован документальный фильм "The Story of Free Software Underdogs", приуроченный к празднованию 30-летия проекта KDE. Фильм рассказывает историю сообщества KDE и включает воспоминания ведущих разработчиков, стоящих в истоках проекта. В фильме также затрагивается решение вопроса с лицензией на Qt, соперничество с GNOME и успех KHTML, который лёг в основу движков WebKit и Blink, применяемых в Safari и Chromium.
Днём рождения KDE считается 14 октября 1996 года. В этот день Маттиас Эттрих (Matthias Ettrich), будучи студентом, объявил о создании нового свободного десктоп-окружения, ориентированного на конечных пользователей, а не на системных администраторов, и способного конкурировать с доступными в то время коммерческими продуктами, такими как CDE. Первый стабильный релиз KDE 1.0 был выпущен 12 июля 1998 года, KDE 2.0 был выпущен 23 октября 2000 года, KDE 3.0 - 3 апреля 2002 года, KDE 4.0 - 11 января 2008 года, KDE Frameworks 5 и KDE Plasma 5 - в июле 2014 года, а KDE Plasma 6 - в феврале 2024 года. Проект GNOME, который появился спустя 10 месяцев после основания KDE, будет праздновать своё 30-летие 15 августа 2027 года.
| ||
|
Обсуждение (82 +24) |
Тип: К сведению |
| ||
| · | 16.10 | Доступен неофициальный порт игры Космические рейнджеры для Linux (112 +30) |
|
Разработан кросс-платформенный порт игры "Космические рейнджеры HD: Революция", реализованный с использованием библиотеки SDL и компилятора Free Pascal (FPC). Порт основан на восстановленных исходных кодах, полученных путём декомпиляции и при сборке, позволяющих сформировать исполняемый файл, байт в байт совпадающий с оригинальным Rangers.exe. При разработке использовались AI-агенты. Код опубликован под лицензией MIT. Сборки формируются для Linux, Android и Windows.
В процессе разработки использовался собственный форк компилятора FPC, созданный для улучшения поддержки LLVM-бекенда на разных платформах и обеспечения совместимости, чтобы игра вела себя абсолютно так же, как оригинальный исполняемый файл на Windows, вплоть до воспроизведения поведения x87 с 24-битной точностью. При задействовании форка FPC с LLVM бекендом порт игры просчитывает симуляцию галактики примерно в 2 раза быстрее оригинальной игры, если сравнивать на одинаковом оборудовании. К тому же, многие изменения в форке FPC позволили найти проблемы в самом FPC, сведения о которых отправлены на рассмотрение в оригинальный проект. На данный момент порт игры находится в стадии разработки и тестирования, но уже позволяет играть в основную игру так же, как в оригинале, за исключением редких ошибок. Подготовлен экспериментальный мобильный пользовательский интерфейс, который меняет масштабирование многих элементов для более комфортной игры на маленьких экранах с большим разрешением. Самое большое ограничение на текущий момент: отсутствие планетарных боёв, для которых использовался движок MatrixGame, написанный на C++ с DirectX 9 и открытый в 2019 году под лицензией GPLv2. В ближайшем будущем планируется портировать и его.
| ||
| · | 15.10 | Линус Торвальдс раскритиковал предвзятое отношение к AI-инструментам (302 +15) |
|
Линус Торвальдс принял участие в дискуссии по поводу отмены тега "Assisted-by", которым предписано помечать изменения, подготовленные с использованием AI-ассистентов. Участники конференции Maintainers Summit договорились удалить из правил оформления патчей требование по использованию данного тега, но при обсуждении патча, вносящего изменение в документацию, разработчик Лоран Пиншар (Laurent Pinchart) выступил против удаления.
Лоран аргументировал свою позицию тем, что даже если невозможно принудить людей всегда соблюдать правило о декларировании AI, так как часть разработчиков всё равно будет хитрить, сообщество всё равно должно формально зафиксировать свои ожидания и чётко обозначить, что допустимо, а что нет. Подобная попытка регулировать процесс разработки через ограничения на инструменты и апелляция к "установлению ожиданий" вызвала бурный ответ Торвальдса. По мнению Линуса, к "ожиданиям" это не имеет никакого отношения, а вызвано личными заскоками. Линус не признаёт концепцию "не используй AI для таких-то задач", которая сродни рекомендации не использовать компиляторы при подготовке кода, в контексте того, что если разработчик не разбирается в том как компьютер обрабатывает машинный код, то предложенное изменение не заслуживает внимания, а разработчик не компетентен, если не может писать код на языке ассемблера. Доводя ситуацию до абсурда также можно потребовать не использовать текстовые редакторы при написании пояснений к коммитам, чтобы допускать только разработчиков, способных в один заход грамотно набирать текст без инструментов, позволяющих исправлять допущенные при вводе ошибки. Линус против введения любых запретов на использование инструментов для упрощения работы и ожидает от людей, что они прикладывают максимум усилий и понимают, что делают. Но это понимание имеет мало общего с тем, какими инструментами они пользуются. По опыту Линуса, люди, которых он уважает и считает умными, не склонны сторониться новых и интересных инструментов.
| ||
| · | 15.10 | Выпуск системы тестирования памяти Memtest86+ 9.0 (23 +33) |
|
Доступен выпуск программы для тестирования оперативной памяти Memtest86+ 9.0. Программа не привязана к операционным системам и может запускаться напрямую из прошивки BIOS/UEFI или из загрузчика для проведения полной проверки оперативной памяти. В случае выявления проблем построенная в Memtest86+ карта сбойных участков памяти может использоваться в ядре Linux для исключения проблемных областей при помощи опции memmap. Код проекта распространяется под лицензией GPLv2.
Основные новшества:
![]()
| ||
|
Обсуждение (23 +33) |
Тип: Программы |
| ||
| Следующая страница (раньше) >> | ||