Профиль: Аноним (вход | регистрация) неRU opennet.me  
OpenNET

[ новости /+++ | форум | теги |    ]

·17.10 Исследователи из Anthropic воссоздали формирование seed-параметров стандартных эллиптических кривых ECDSA (56 +8)
  Группа исследователей из компании 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, и будет рекомендовать их в первую очередь.

  1. Главная ссылка к новости
  2. OpenNews: Представлена техника атаки для определения ключей ECDSA и DSA
  3. OpenNews: Новая техника атаки по сторонним каналам, позволяющая восстановить ключи ECDSA
  4. OpenNews: Уязвимость в реализациях постквантового алгоритма шифрования Kyber
  5. OpenNews: Дэниэл Бернштейн подал в суд из-за утаивания NIST информации о постквантовых криптоалгоритмах
  6. OpenNews: Опубликован прототип бэкдора в генераторе псевдослучайных чисел Dual_EC_DRBG, входившем в стандарт NIST
Обсуждение (56 +8) | Тип: К сведению | Интересно


·17.10 Новые версии Wine 11.20 и Wine-staging 11.20 (2 +6)
  Опубликован экспериментальный выпуск открытой реализации Win32 API - Wine 11.20. С момента выпуска 11.19 был закрыто 24 отчёта об ошибках и внесено 341 изменение.

Наиболее важные изменения:

  • Для архитектуры ARM64EC (ARM64 Emulation Compatible) реализована поддержка отладочного режима "WINEDEBUG=+relay", позволяющего отслеживать аргументы и возвращаемые значения вызываемых функций. Архитектура ARM64EC применяется для упрощения портирования на системы ARM64 приложений, изначально написанных для систем x86_64, и позволяет выполнять в окружении ARM64 отдельные модули с кодом x86_64 при помощи эмулятора.
  • Улучшена проверка данных в формате XML.
  • Реализация поддержки CDROM перемещена из ntdll в Mount Manager.
  • Закрыты отчёты об ошибках, связанные с работой приложений: MS Office 2013, Unigine Heaven 2.0, Toad for SQL Server 5.7, Intuit QuickBooks 2008-2010, QuickBooks SS 2008 R1, SumatraPDF 3.1.2, Microsoft Core XML Services 6.0, Neko Project 21, FL Studio, cmd.exe, Medicalc4, UE4 ElectraPlayer, MusicBee, OneDrive.
  • Закрыты отчёты об ошибках, связанные с работой игр: Star Wolves 3, UFO: Aftershock, UFO: Afterlight, Pure Pinball, Imperium Great Battles of Rome, Incoming, Battlefield 1942.

Параллельно сформирован выпуск проекта Wine Staging 11.20, предоставляющего расширенные сборки Wine, включающие не полностью готовые или рискованные патчи, пока непригодные для принятия в основную ветку Wine. По сравнению с Wine в Wine Staging предоставляется 279 дополнительных патчей. В новом выпуске Wine Staging осуществлена синхронизация с кодовой базой Wine 11.20 и обновлён код vkd3d. В основной состав Wine перенесены патчи, улучшающие в wininet обработку некорректных параметров в APPINFO_QueryOption и HTTPREQ_QueryOption.

  1. Главная ссылка к новости
  2. OpenNews: Новые версии Wine 11.19, Wine-staging 11.19 и D7VK 2.3
  3. OpenNews: Стабильный релиз Wine 11.0
  4. OpenNews: Стабильный релиз Proton 11.0, пакета для запуска Windows-игр в Linux
Обсуждение (2 +6) | Тип: Программы |


·17.10 ESP-KVM 0.65.0 и прошивка, превращающая планшет M5Stack Tab5 в экран для IP-KVM (10 +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:

  • 0.52-0.54: Прошивка заработала на M5Stack Unit PoE-P4 с модулем Add-on Display In на мосте LT6911D: питание по PoE, паять ничего не нужно. В консоли появилась экранная клавиатура, заработали карты microSD с exFAT и разметкой GPT. Alt+Tab и клавиша Windows теперь уходят на целевую машину, а не в браузер.
  • 0.55: Виртуальный CD-ROM отвечает на команды настоящего привода (READ TOC, GET CONFIGURATION и другие). UEFI и Linux грузились и без них, но Windows и macOS спрашивают их первыми. С карты exFAT работают образы больше 4 ГБ, так что влезает полный установщик на DVD.
  • 0.56-0.57: Обрывы по WiFi шли из-за того, что сопроцессору не хватало внутренней памяти P4 под буферы. Добавились вход с кодом TOTP и часы DS3231. Уведомления ждут, пока появится сеть. Обновления устройство проверяет, только если пользователь разрешил.
  • 0.58-0.59: На платах с TC358743 работает HDMI-CEC: кнопки пульта, ожидание, пробуждение. Steam Deck, правда, просыпаться по CEC отказывается - SteamOS эту команду игнорирует. Устройство умеет притворяться геймпадом для Switch и Xbox 360 и переходит с Ethernet на WiFi, если выдернуть кабель.
  • 0.60: Последовательная консоль целевой машины открывается в браузере - для NAS, роутеров и серверов без экрана. Журналы ядра можно слать на устройство по сети (netconsole, syslog), при панике оно пришлёт уведомление. Образ по ссылке устройство скачивает прямо на карту, netboot.xyz - в один клик.
  • 0.61-0.62: Добавлены модули M5Stack Unit OLED, Unit Glass2, Unit RTC и кнопка на корпусе. Сессии переживают перезагрузку. Задержка H.264 в браузере упала на 170 мс. B-кадров кодировщик не пишет, но в потоке об этом не говорилось, и декодер Chrome придерживал около четырёх кадров. Нажатия доходят до цели до 64 мс быстрее. Стеки задач занимали 220 КБ внутренней памяти и в основном пустовали, после их урезания свободной памяти стало вдвое больше.
  • 0.63: Устройство теперь может получать сертификат Let's Encrypt для своего имени в tailnet. Запись DNS публикует сервер управления Tailscale, поэтому не нужны ни домен, ни токен DNS, ни открытый порт. Все операции с протоколом ACME выполняются на самом P4.
  • 0.64: Режим геймпада оригинального Xbox (XID).

Прошивка собирается для 15 плат на ESP32-P4. Чтобы было проще выбрать, на сайте появилось сравнение плат ESP32-P4 для IP-KVM: ревизия чипа, память, размер платы в масштабе, Ethernet, PoE и Wi-Fi, подходящий адаптер HDMI и замеренная частота кадров. Отдельно есть сравнение плат захвата HDMI - мост, шлейфы, проход HDMI на монитор, CEC и звук.

  1. Главная ссылка к новости
  2. OpenNews: Выпуск ESP-KVM 0.51.0, открытой прошивки IP-KVM , с записью экрана на microSD
  3. OpenNews: Выпуск ESP-KVM 0.45.0, открытой прошивки IP-KVM на базе ESP32-P4
Обсуждение (10 +5) | Автор: Dexif | Тип: Программы |


·17.10 В компиляторе Nimony для будущего Nim 3.0 реализованы самокомпиляция и JavaScript-бэкенд (24 +5)
  Андреас Румпф (Andreas Rumpf, Araq), автор языка программирования Nim, опубликовал серию отчётов о прогрессе разработки компилятора Nimony, создаваемого как основа для будущего релиза Nim 3.0. На данный момент уже доступен восьмой отчёт. Ключевое достижение последнего времени - переход к самокомпиляции: весь стек инструментов, включая фронтенд, прослойку (middle-end), оптимизатор и бэкенд, теперь может быть собран самим Nimony. Дополнительно реализованы JavaScript-бэкенд, поддержка всех четырёх актуальных режимов управления памятью и работа на платформе FreeBSD. Код проекта написан на Nim и распространяется под лицензией MIT.

Nimony - новая реализация языка Nim, практически не использующая кодовую базу существующего компилятора: с нуля написаны семантический анализ, обобщённые процедуры, разворачивание шаблонов, управление памятью и генерация кода. Цели проекта - инкрементальная перекомпиляция, полностью параллельные сборки, отказ от обязательных предварительных объявлений процедур и типов, типобезопасные дженерики и единая модель конкурентности на основе продолжений (continuations). Этапы компиляции обмениваются данными через текстовый формат NIF, а вместо исполнения макросов в виртуальной машине применяются плагины, компилируемые в нативные исполняемые файлы.

Основные изменения за прошедшие месяцы:

  • Самокомпиляция и бэкенды
    • Бэкенд nativenif портирован и собирается при помощи Nimony. Вся цепочка инструментов, от фронтенда до генератора нативного кода, компилируется самим Nimony.
    • Архитектура перестроена вокруг промежуточного представления NJ ("No Jumps"), не содержащего операции break, continue и goto. NJ развивается для использования во фронтендах Nimony и Nim 2.x (текущей версии) и обеспечивает генерацию кода для C/C++, JavaScript и нативных бэкендов x86-64 и ARM64.
    • Добавлен JavaScript-бэкенд, включаемый подкомандой j (nimony j file.nim).
    • NIFC переименован в Leng для устранения постоянной путаницы между NIF и NIFC.
    • Обеспечена сборка DLL, позволяющая разрабатывать части программ на Nimony и подключать их к проектам на Nim 2.x,
    • Добавлена поддержка FreeBSD.
  • Управление памятью
    • В дополнение к имевшимся режимам управления памятью ARC и atomicArc портированы ORC и YRC. Доступна возможность подключения собственных реализаций через переключатель mm:<путь>.
    • По умолчанию задействованы типы ref и ptr, не допускающие значения nil. Для совместимости со старым кодом предназначена прагма {.feature: "lenientnils".}.
    • Среда выполнения доработана для устойчивости к нехватке памяти (OOM - out-of-memory).
  • Языковые возможности и стандартная библиотека
    • Реализованы суммарные типы (sum types) и сопоставление с образцом (pattern matching), на основе которых в стандартную библиотеку добавлены типы Opt[T] и Result[T, E] для поддержки функциональной парадигмы программирования.
    • Проверка диапазонов выполняется полностью на этапе компиляции: если корректность неявного преобразования не удаётся доказать, компиляция завершается ошибкой.
    • Семантика break и block приведена к поведению Nim 3 (RFC 576).
    • Реализованы явные циклические зависимости между модулями.
    • Решено допустить классические исключения в виде ref object с подтипами (heap-based exceptions) для совместимости с Nim 2.
    • Сохранена работоспособность макросов: std/macros отображается на систему плагинов Nimony, что позволяет использовать существующий код метапрограммирования без переписывания.
    • Добавлена параллельная форма цикла for ("for i in 0 || 1"), реализованная в виде плагина, интегрированного с пулом потоков и циклом событий. Корректность доступа к результатам проверяется статически:
      
       import std / [parfor, syncio]
      
       proc pfib(n: int): int =
         if n < 2:
           return n
         
         var r = [0, 0]
         for i in 0 || 1: # итерации выполняются параллельно
           r[i] = pfib(n - 1 - i)
         
         result = r[0] + r[1]
      
    • В стандартную библиотеку добавлены модули httpclient с собственной реализацией TLS, complex, base64 и heapqueue, а также sort. Блокировки переведены на вызовы, не зависящие от libc.
  • Инженерные улучшения
    • Кодовая база компилятора переведена на nifcore, очередную итерацию API для работы с NIF, что снизило потребление памяти.
    • Для повышения безопасности работы с памятью во внутренних структурах NIF задействован подсчёт ссылок и режим copy-on-write.
    • Реализована проверка плагинов перед выполнением. Для проверки во время разработки плагинов поставляется линтер.
    • Реализованы совместимые с Nim прагмы .compile, .link, .intdefine, .booldefine и .strdefine. Прагма .build сделана независимой от инструментария сборки, а новая прагма .bundle позволяет подключать собственные бэкенды, работающие поверх Leng.

При тестировании потребления памяти на системе с чипом Apple M1 самый требовательный к памяти процесс фронтенда занимает 45 МиБ, бэкенда - 111 МиБ, а суммарное потребление при восьми одновременно работающих процессах достигает 171 МиБ. Сборка тех же компонентов компилятором Nim 2 требует примерно в пять раз больше памяти, что в значительной мере обусловлено применением clang.

Целью на текущий год в README проекта названа готовность компилятора к промышленному использованию для проектов, укладывающихся в задокументированный набор возможностей. В начале года темп разработки снизился из-за параллельной работы над системой инкрементальной компиляции в Nim 2. Модуль httpclient с собственной реализацией TLS создан для отработки применения Nim в роли встроенного ассемблера.

  1. Главная ссылка к новости
  2. OpenNews: Релиз языка программирования Nim 2.2.12
  3. OpenNews: В языке Nim представлен YRC - потокобезопасный сборщик циклических ссылок
  4. OpenNews: Представлены принципы дизайна компилятора Nimony для будущего Nim 3.0
  5. OpenNews: Для Nim 3.0 развивается новый компиляторный бэкенд на основе формата NIF
  6. OpenNews: В openSUSE обеспечена полная поддержка языка программирования Nim
Обсуждение (24 +5) | Автор: Аноним | Тип: Обобщение |


·17.10 Выпуск OpenRGB 1.1, инструментария для управления RGB-подсветкой (4 +2)
  После месяца разработки опубликован релиз проекта OpenRGB 1.1, развивающего инструментарий для управления RGB-подсветкой компонентов ПК и периферийных устройств. Код написан на C/C++ и распространяется под лицензией GPLv2. Готовые сборки сформированы для Linux (deb, rpm, appimage, flatpak), macOS и Windows.

Релиз сфокусирован на исправлении ошибок, выявленных после выхода версии 1.0. Среди исправленных проблем:

  • Налажена работа опции "Не показывать снова", которая не сохраняла значение.
  • Устранена ошибка с сервером OpenRGB SDK, при которой в безоконном режиме (headless) сервер не отвечал на запрос списка плагинов.
  • Исправлена ошибка сервера при работе с очень старыми клиентами с протоколом ниже версии 6, из-за которой неправильно обрабатывались индексы устройств.
  • Исправлено несколько ошибок, связанных с обработкой опций командной строки, загружающих профили, устанавливающих параметр размера зон в устройствах, и применяющих другие настройки или цвета к устройствам через CLI.
  • Исправления в нескольких конкретных контроллерах устройств, улучшающие поведение горячего подключения и устраняющие потенциальные взаимные блокировки.

Одновременно выпущены плагины 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), и некоторые пункты объединяют под собой сразу несколько моделей устройств.

  1. Главная ссылка к новости
  2. OpenNews: Выпуск OpenRGB 1.0, инструментария для управления RGB-подсветкой
  3. OpenNews: Первый выпуск OpenRGB, инструментария для управления устройствами c RGB-подсветкой
Обсуждение (4 +2) | Автор: k1801 | Тип: Программы |


·16.10 Разработчик Firefox провёл сравнительное тестирование форматов JPEG XL и AVIF (61 +26)
  Джейк Арчибальд (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 зачастую создаются файлы, которые декодируются слишком медленно.

  1. Главная ссылка к новости
  2. OpenNews: Представлен формат изображений AVIF 1.2
  3. OpenNews: Опубликованы libavif 1.0 и SVT-AV1 1.7, библиотеки для форматов изображений AVIF и видео AV1
  4. OpenNews: Представлен формат сжатия изображений Spectral JPEG XL
  5. OpenNews: В спецификацию PDF добавлена поддержка формата изображений JPEG XL
  6. OpenNews: Google готов вернуть в Chrome поддержку формата JPEG-XL
Обсуждение (61 +26) | Автор: Artem S. Tashkinov | Тип: Обобщение |


·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:

  • Добавлена поддержка новых устройств:
    • Nothing Phone
    • OnePlus Nord N10
    • OnePlus Nord N100
    • Volla Tablet
    • Xiaomi Redmi Note 9 Pro (Global)
    • Xiaomi Redmi Note 9S/9 Pro (India)
    • Xiaomi Redmi Note 9 Pro Max
    • Xiaomi Poco M2 Pro
  • В браузере Morph задействован выпуск движка QtWebEngine 6.11.2, основанный на Chromium 140 с бэкпотированием исправлений уязвимостей из новых веток.
  • Устранена проблема, из-за которой указатель мыши не перемещался при повороте экрана.
  • Добавлена поддержка включения фонарика на смартфоне Volla Phone Plinius.
  • Повышена стабильность работы push-уведомлений.
  • Решена проблема с использованием экранной клавиатуры в приложениях, запускаемых через Libertine (утилита для запуска обычных немобильных desktop-программ).
  • Устранены уязвимости, позволявшие ограниченным приложениям получить дополнительные привилегии без ввода пароля. Например, в lomiri-download-manager устранена уязвимость, позволявшая выполнить произвольные команды с правами root и без аутентификации прочитать любые файлы в системе.

  1. Главная ссылка к новости
  2. OpenNews: Опубликована мобильная платформа Ubuntu Touch 24.04-2.0
  3. OpenNews: Релиз мобильной платформы Ubuntu Touch 24.04-1.3. Смартфон Volla Plinius с Ubuntu Touch
  4. OpenNews: Воссоздание пользовательской оболочки Unity с использованием Wayfire и Libadwaita
  5. OpenNews: Выпуск AsteroidOS 2.0, Linux-платформы для умных часов, использующей Qt
Обсуждение (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 отмечены:

  • Поддержка механизма zswap для сжатия памяти, претендующей на вытеснение в раздел подкачки, для повышения эффективности работы на системах с небольшим ОЗУ;
  • Поставка приложения Test Center для упрощения тестирования экспериментальных версий программ;
  • Создание проекта Toolpak для установки независимых от дистрибутивов сборок консольных утилит (как Flatpak и Flathub, но для консольных программ).

Сборка GNOME OS Preview пока позиционируется как экспериментальная и будет объявлена стабильной после реализации недоделанных возможностей и поддержки механизмов подготовки, доставки и установки обновлений для поддержания системы в актуальном состоянии. Среди планов на будущее:

  • Доработка инсталлятора до полнофункционального состояния;
  • Поддержка дельта-обновлений в systemd-sysupdate для загрузки при обновлении только изменений, а не всего образа;
  • Интеграция systemd-homed для организации работы с шифрованными переносимыми домашними каталогами;
  • Улучшение поддержки устройств на базе архитектуры ARM;
  • Более тесная интеграция с TPM и графический интерфейс для восстановления ключей;
  • Поставка предустановленных программ в формате Flatpak;
  • Создание новых порталов и возможностей Flatpak, например, для поставки VPN-приложений.

  1. Главная ссылка к новости
  2. OpenNews: Инициатива по упрощению тестирования экспериментальных версий программ в GNOME OS
  3. OpenNews: Дистрибутив GNOME OS перешёл на стадию тестирования на реальном оборудовании
  4. OpenNews: Превращение GNOME OS в дистрибутив для обычных пользователей
  5. OpenNews: Проект KDE опубликовал дистрибутив KDE Linux Testing Edition
  6. OpenNews: Первый альфа выпуск дистрибутива KDE Linux, развиваемого проектом KDE
Обсуждение (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.

  1. Главная ссылка к новости
Обсуждение (86 +28) | Тип: Проблемы безопасности |


·16.10 Выпуск загрузочной прошивки Libreboot 26.10 с добавлением поддержки 239 устройств (75 +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:

  • Серверные материнские платы:
    • ASUS KFSN4-DRE
    • ASUS KGPE-D16
    • Supermicro X11SSH-F
  • Десктоп-системы:
    • Gigabyte GA-G41M-ES2L;
    • Acer G43T-AM3, Q45T-AM;
    • Intel D510MO / D410PT;
    • Apple iMac 5,2;
    • HP Elite 8200 SFF/MT;
    • HP Elite 8300 USDT;
    • HP Pro 3500;
    • Topton XE2 N150;
    • ASUS KCMA-D8;
    • Dell Precision T1650, T1700 SFF/MT;
    • Intel D945GCLF
    • Dell OptiPlex 3050 Micro, 3040 Micro, 5050 SFF, 7010, 7020, 9010 и 9020 серии SFF, XE2 SFF, MT и XE2 MT, 780 USFF/MT.
  • Ноутбуки:
    • ThinkPad X60 / X60S / X60 Tablet;
    • ThinkPad T60;
    • Lenovo ThinkPad X200 / X200S / X200 / X220 / X230 / X230 eDP / X230 Tablet;
    • Lenovo ThinkPad X301;
    • Lenovo ThinkPad R400;
    • Lenovo ThinkPad T400 / T400S / T420 / T420S / T430 / T440 / T480 / T480S.
    • Lenovo ThinkPad T500 / T530 / T580;
    • Lenovo ThinkPad W530 / W541;
    • Lenovo ThinkPad R500;
    • HP EliteBook 2560p / 2570p / 2170p / 8470p / Folio 9470m;
    • HP EliteBook 820 G2;
    • HP Compaq Elite 8300 CMT;
    • HP EliteBook 8460p;
    • HP EliteBook 8560w;
    • Dell Latitute E6400 / E6430;
    • Dell Latitude E5420 / E5520 / E5530 / E6520 / E6530 / E6420 / E6220 / E6320 / E6330 / E6230 / E4300 / E7240;
    • Apple MacBook1 и MacBook2;
    • ASUS Chromebook Flip C101 (ARM);
    • Samsung Chromebook Plus (ARM), Lumpy и Stumpy (x86);
    • Purism Librem 13/14/15/Mini;
    • Более 200 моделей Google Chromebook.
  • Игровые приставки:
    • Sony PlayStation 1.

  1. Главная ссылка к новости
  2. OpenNews: Выпуск Coreboot 26.09, открытой альтернативы проприетарным прошивкам
  3. OpenNews: Истекает время жизни сертификата, которым заверен загрузчик для UEFI Secure Boot в дистрибутивах Linux
  4. OpenNews: Выпуск загрузочных прошивок Libreboot 26.01 и Canoeboot 26.01
  5. OpenNews: Проект U-Boot перешёл под крыло организации Software Freedom Conservancy
Обсуждение (75 +19) | Тип: Программы |


·16.10 Началось тестирование 64-разрядной версии клиента Steam для Linux (34 +47)
  Компания Valve опубликовала бета-версию обновлённого клиента сервиса доставки игр Steam для Linux. Выпуск примечателен формированием 64-разрядных сборок и переходом к выполнению клиента Steam внутри контейнера со Steam Runtime. Изменение существенно упрощает организацию работы Steam в дистрибутивах Linuх. До сих пор клиент Steam распространялся только в 32-разрядных сборках, что мешало дистрибутивам полностью прекратить поддержку 32-разрядных CPU и вынуждало специально для Steam поставлять необходимые 32-разрядные зависимости или упаковывать Steam в самодостаточные пакеты в форматах snap и flatpak.

В новой версии также предложен новый интерфейс для отслеживания и управления достижениями при прохождении игр. Окно с настройками уведомлений адаптировано для работы на экранах любого размера. Улучшена работа с библиотекой в offline-режиме. В Remote Play реализованы настройки для масштабирования вывода с учётом разных соотношений сторон экрана на локальной и удалённой системах.

  1. Главная ссылка к новости
  2. OpenNews: В GNOME Flatpak Runtime прекращена поддержка 32-разрядных приложений
  3. OpenNews: В Fedora намерены прекратить поддержку 32-разрядной архитектуры x86
  4. OpenNews: В KDE реализована отрисовка теней окон на стороне сервера для приложений, подобных Steam и Discord
  5. OpenNews: Предварительный выпуск дистрибутива для игровых консолей SteamOS 3.9.0
  6. OpenNews: Доступен Bazzite Deck 44, дистрибутив для игровых консолей
Обсуждение (34 +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 года.

  1. Главная ссылка к новости
  2. OpenNews: Релиз KDE Plasma 6.8, в котором оставлен только сеанс на базе Wayland
  3. OpenNews: Бета-выпуск MiDesktop, форка KDE 1 для современных систем
  4. OpenNews: Выпуск десктоп-окружения Trinity 14.1.6, продолжающего развитие KDE 3.5
  5. OpenNews: Представлен порт Qt 1 для современных систем
  6. OpenNews: Проект KDE отметил своё двадцатилетие повторным выпуском KDE 1
Обсуждение (82 +24) | Тип: К сведению |


·16.10 Доступен неофициальный порт игры Космические рейнджеры для Linux (111 +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. В ближайшем будущем планируется портировать и его.

Дополнение: сторонним автором на Github опубликована кроссплатформенная версия MatrixGame, работающая на Windows и Linux. Для работы с графикой используется фреймворк bgfx, обеспечивающий трансляцию Direct3D вызовов в Vulkan, а для интеграции с системой и управления вводом\выводом используется SDL 2.0.

  1. Главная ссылка к новости
  2. OpenNews: Valve опубликовала инструментарий Lepton для запуска Android-игр в Linux
  3. OpenNews: Сервис доставки игр GOG разрабатывает Linux-версию GOG Galaxy
  4. OpenNews: Опубликован исходный код игры Unturned
  5. OpenNews: Quake портирован для запуска внутри игрового мира Roblox
  6. OpenNews: Linux запущен на игровой приставке Atari Jaguar
Обсуждение (111 +30) ↻ | Автор: Аноним | Тип: Программы |


·15.10 Линус Торвальдс раскритиковал предвзятое отношение к AI-инструментам (306 +15)
  Линус Торвальдс принял участие в дискуссии по поводу отмены тега "Assisted-by", которым предписано помечать изменения, подготовленные с использованием AI-ассистентов. Участники конференции Maintainers Summit договорились удалить из правил оформления патчей требование по использованию данного тега, но при обсуждении патча, вносящего изменение в документацию, разработчик Лоран Пиншар (Laurent Pinchart) выступил против удаления.

Лоран аргументировал свою позицию тем, что даже если невозможно принудить людей всегда соблюдать правило о декларировании AI, так как часть разработчиков всё равно будет хитрить, сообщество всё равно должно формально зафиксировать свои ожидания и чётко обозначить, что допустимо, а что нет. Подобная попытка регулировать процесс разработки через ограничения на инструменты и апелляция к "установлению ожиданий" вызвала бурный ответ Торвальдса.

По мнению Линуса, к "ожиданиям" это не имеет никакого отношения, а вызвано личными заскоками. Линус не признаёт концепцию "не используй AI для таких-то задач", которая сродни рекомендации не использовать компиляторы при подготовке кода, в контексте того, что если разработчик не разбирается в том как компьютер обрабатывает машинный код, то предложенное изменение не заслуживает внимания, а разработчик не компетентен, если не может писать код на языке ассемблера. Доводя ситуацию до абсурда также можно потребовать не использовать текстовые редакторы при написании пояснений к коммитам, чтобы допускать только разработчиков, способных в один заход грамотно набирать текст без инструментов, позволяющих исправлять допущенные при вводе ошибки.

Линус против введения любых запретов на использование инструментов для упрощения работы и ожидает от людей, что они прикладывают максимум усилий и понимают, что делают. Но это понимание имеет мало общего с тем, какими инструментами они пользуются. По опыту Линуса, люди, которых он уважает и считает умными, не склонны сторониться новых и интересных инструментов.

  1. Главная ссылка к новости
  2. OpenNews: Проект GCC запретил приём значимых изменений, сгенерированных при помощи AI
  3. OpenNews: LLVM ввёл правила применения AI-инструментов. Curl и Node.js ограничат выплаты за уязвимости из-за AI
  4. OpenNews: В Fedora утверждены правила использования AI-инструментов при разработке
  5. OpenNews: Линус Торвальдс поддержал право использовать AI-инструменты при разработке ядра
  6. OpenNews: Линус Торвальдс экспериментирует с генерацией изменений к ядру через AI
Обсуждение (306 +15) | Автор: Artem S. Tashkinov | Тип: Тема для размышления |


·15.10 Выпуск системы тестирования памяти Memtest86+ 9.0 (23 +33)
  Доступен выпуск программы для тестирования оперативной памяти Memtest86+ 9.0. Программа не привязана к операционным системам и может запускаться напрямую из прошивки BIOS/UEFI или из загрузчика для проведения полной проверки оперативной памяти. В случае выявления проблем построенная в Memtest86+ карта сбойных участков памяти может использоваться в ядре Linux для исключения проблемных областей при помощи опции memmap. Код проекта распространяется под лицензией GPLv2.

Основные новшества:

  • Добавлена поддержка архитектуры AArch64 (ARM64). Работа протестирована на платах Raspberry Pi 4/5 и Snapdragon X.
  • Реализована функция сохранения отчёта на USB-накопителе, отформатированном с ФС FAT32.
  • Переработан набор тестов, в который добавлены оптимизации для сокращения времени выявления первого сбоя.
  • Добавлены тесты, в которых используются 128- и 256-разрядные векторные инструкции SIMD (SSE2/AVX2/NEON/LASX).
  • Добавлен новый стресс-тест шины, необходимый для памяти DDR5.
  • Добавлен опциональный тест для проверки подверженности памяти атаке RowHammer (искажение содержимого отдельных битов памяти DRAM путём цикличного чтения данных из соседних ячеек памяти).
  • Добавлен тест для определения повреждения данных SPD (Serial Presence Detect).
  • Расширена выводимая информация о памяти.
  • Реализовано определение более 100 новых наименований DRAM-памяти.
  • Добавлена поддержка платформы Intel Wildcat Lake.
  • Обеспечено заверение собственной цифровой подписью для загрузки в режиме Secure Boot (в будущем ожидается заверение подписью Microsoft).

  1. Главная ссылка к новости
  2. OpenNews: Выпуск системы тестирования памяти Memtest86+ 8.10
  3. OpenNews: Выпуск системы тестирования памяти Memtest86+ 8.0
  4. OpenNews: GPUHammer - вариант атаки Rowhammer на память GPU
  5. OpenNews: Phoenix - атака на чипы DDR5, приводящая к искажению содержимого памяти
  6. OpenNews: Атаки GDDRHammer и GeForge, искажающие память GPU для доступа ко всей памяти CPU
Обсуждение (23 +33) | Тип: Программы |


Следующая страница (раньше) >>



XSQUARE
Inferno Solutions
Hosting by Hoster.ru
Хоcтинг: