Hacker News Digest

Линус Торвальдс выпустил ядро 7.3, не став затягивать с релизом: по его словам, на этой неделе он «каким-то чудом» не потерял счёт дням. Выпуск стал рекордным по всем показателям — 18 765 несливаемых коммитов от 3 021 разработчика, из которых 807 участвовали в разработке ядра впервые. Сразу после релиза открывается окно слияния для 7.4, но Торвальдс предупредил, что из-за ежегодного семейного отпуска будет заниматься слияниями не с утра, а после обеда, проводя большую часть дня на лодке под водой, так что его график какое-то время будет необычным.

Среди значимых изменений — расширения «binfmt_misc», работа по групповому планированию для повышения производительности на больших системах, новая файловая система «failfs», проваливающая все операции, системный вызов fchroot(), глобальные данные per-CPU для программ BPF, завершение функции подпланировщика «sched_ext», отслеживание рабочего набора для виртуальных машин, поддержка альтернативных потоков данных в файловой системе ntfs3 и длинный список улучшений SMB-сервера. Подробности собраны в обзорах окна слияния LWN и на странице KernelNewbies, посвящённой 7.3.

Релиз 7.3 включает ksmbd с поддержкой Time Machine, реализованную обратным инжинирингом и остающуюся проблемной при работе с клиентами Apple из-за ограничений и несовместимости. Добавлен failfs — псевдо-файловая система, где любой путь не существует, обеспечивающая строгую изоляцию процессов через ограничение доступа только к заранее открытым дескрипторам. Улучшена поддержка Apple‐silicon, хотя мнения разделились: некоторые считают темпы быстрыми, другие — лишь стабильными из-за отсутствия GPU и Thunderbolt. Появился первый драйвер Wi‐Fi HaLow (s1g/900 MHz), требующий обновлений hostapd и wpa_supplicant для полноценной работы. Политика ядра допускает использование ИИ при написании патчей при условии раскрытия его применения и оставляет ответственность за качество за человеком. Релиз стал рекордным: 18 765 неконтрольных коммитов от 3 021 разработчика, включая 807 новых участников. Исправлено рекордное количество CVE‐уязвимостей, подчёркивая усиление безопасности. Обсуждается рост количества Rust‐патчей в ядре.

Пользователь купил точку доступа TP-Link EAP770 с Wi-Fi 7 в августе 2023 года, ещё до финализации стандарта, и столкнулся с повреждением данных при длительных загрузках по Wi-Fi: файлы больше нескольких гибибайт обрывались с ошибками MAC и TLS, хотя Wireshark не показывал ни плохих контрольных сумм, ни ретрансмиссий. Переход на Tailscale с WireGuard маскировал проблему, так как потеря пакета внутри туннеля вызывала повторную передачу. TP-Link отказался выпускать прошивки: устройство версии v1 объявили снятым с поддержки, а последняя прошивка осталась от июня 2023 года. Исправление оказалось тривиальным — записать два нуля в sysfs, но оболочка TP-Link не позволяла этого сделать, поэтому автор написал эксплойт ядра для собственной точки доступа.

Отдельно выяснилось, что ежедневные обрывы Wi-Fi около 11:00 — другой баг, связанный с картой Qualcomm WCN785x в ноутбуке Framework 16: каждые несколько часов она переставала передавать данные на 1–4 минуты, накапливая тысячи кадров в очереди драйвера ath12k, а затем разом отправляла весь накопленный запас. Сигнал при этом был отличным (-31…-42 dBm), ошибок приёма не было, а логика отправки кадров полностью скрыта в закрытой прошивке amss.bin. Автор переключил 5 ГГц с Wi-Fi 7 на Wi-Fi 6 и оставил наблюдение на сутки, чтобы понять, связан ли баг со стандартом.

Обсуждение дополняет статью свидетельствами о системном низком качестве ПО TP-Link, техническими деталями проблем с когерентностью кэша в SoC и советами по выбору альтернатив вроде OpenWRT. Аппаратная разгрузка (hardware offload) часто становится источником трудноуловимых багов в сетевых картах, включая дорогое корпоративное оборудование. Совет: При выборе роутера рекомендуется проверять совместимость с OpenWRT, чтобы избежать зависимости от низкокачественного или заброшенного вендорского ПО. Доверие только к контрольным суммам TCP опасно, так как ошибки когерентности кэша или отсутствие ECC RAM в буферах NIC могут привести к незаметному повреждению данных. ZFS send/recv не полагается на TCP checksums, так как использует собственные сквозные (end-to-end) контрольные суммы для обнаружения повреждений при передаче. Спор: Пользователи спорят о поддержке GL.Inet: @commandersaki хвалит их за глубокую помощь в диагностике, в то время как @Oxodao считает предоставление доступа к роутеру поддержке недопустимым. По опыту @reflexe, проблемы с повреждением данных часто связаны с тем, что когерентность кэша плохо специфицирована на уровне SoC/платформы, что приводит к разным результатам на разных чипах с одним и тем же ядром ARM. В потребительской электронике драйверы часто представляют собой «винегрет» из скриптов, что заставляет разработчиков переписывать их с нуля по даташитам или через реверс-инжиниринг. Пользователи сообщают о проблемах с поддержкой TP-Link, включая отсутствие прошивок для старых ревизий (v1) и быстрый вывод устройств из эксплуатации (EOL).

WSL 3.x с ядром Linux 6.18 привёл к заметным улучшениям в низкоуровневых операциях по сравнению с WSL 2.x на ядре 6.6. Наибольший прирост наблюдается в памяти: пропускная способность memcpy выросла на 61,35 % — с 7,84 ГБ/с до 12,64 ГБ/с благодаря более крупному размеру страниц при репортинге памяти, что снижает накладные расходы гипервизора. Планировщик и межпроцессное взаимодействие также ускорились: latency контекстного переключения упал на 11,25 %, а производительность в тестах sched/pipe и sched/messaging выросла на 12,68 % и снизилась на 10,06 % соответственно. Базовые системные вызовы вроде getppid() стали быстрее на ~4 %, но здесь ограничения архитектуры процессора оставляют мало места для оптимизаций.

В реальной нагрузке — сборке GoReleaser — общее время уменьшилось на 3,91 % (с 191,27 с до 183,80 с), причём основной выигрыш пришёлся на снижение времени, проведённого в ядре: sys‑time упал на 15,98 % (с 57,39 с до 48,22 с) благодаря меньшим издержкам при открытии файлов, mmap и futex. Однако так как компиляция Go на 80 % зависит от пользовательских вычислений, а vCPU ограничены двумя ядрами на 2,10 ГГц, общий приростwall‑clock времени остался скромным. Вывод: WSL 3.x выигрывает в задачах с высокой интенсивностью IPC и работы с памятью (БД, микросервисы), тогда для вычислительно ограниченных сборок улучшение будет ощущаться преимущественно в снижении нагрузки на ядро, а не в ускорении самого билда.

WSL3 улучшает производительность, но не решает фундаментальные проблемы Windows как ОС. Основная проблема — медленный доступ к файлам через /mnt/c из-за 9P-файловой системы, а не виртуализация. Улучшения в WSL3 (например, +61% пропускной способности memcpy) значимы для разработчиков, но не меняют восприятия WSL как второсортной среды по сравнению с нативным Linux. Многие пользователи, перешедшие на Linux, не планируют возвращаться к Windows из-за нестабильности, принудительных обновлений и ограничений в управлении системой. AI (например, Claude) стал ключевым фактором, позволяющим новичкам преодолевать сложности Linux и ускоряя переход от WSL к нативной системе. WSL3 — это не архитектурный прорыв, а обновление WSL2 до версии 3.0 без изменения гипервизора или фундаментальной модели. Оно не решает проблему отсутствия полноценной интеграции с Windows и считается 'leaky abstraction' с ненужными слоями. Споры о стабильности Windows 11: некоторые называют её надёжной, другие — нестабильной, особенно на ноутбуках Lenovo Legion 5 с проблемами Wi-Fi. Одни видят в WSL незаменимый инструмент для корпоративных пользователей, другие — неудовлетворительное решение, не компенсирующее неудобства Windows. Советы: хранить рабочие файлы внутри WSL-файловой системы, а не в /mnt/c; полностью отказаться от Windows в пользу Linux с AI-помощью; переход на Linux с AI становится решаемым за час вместо дней. WSL стал 'вратами' для многих, кто впоследствии перешёл на нативный Linux и не возвращался. WSL2 и WSL3 не решают проблему производительности при работе с большими файлами — это остаётся ограничением. Воссоздать 'полированный' интерфейс Windows на Linux сложно, и даже dual-boot может быть технически сложной задачей.

Debian выпустил обновление ядра Linux (DSA-6528-1) для стабильного релиза trixie, устраняющее более 100 уязвимостей, включая критические проблемы, ведущие к повышению привилегий, отказу в обслуживанию и утечкам информации. Исправления включены в версию ядра 6.12.111-1, и пользователям настоятельно рекомендуется обновить пакеты linux как можно скорее. Среди уязвимостей — CVE-2024-52560, CVE-2025-21817 и множество других, охватывающих подсистемы сетевого стека, файловой системы, управления памятью и драйверов устройств.

Обновление доступно через стандартные репозитории Debian Security. Подробная информация о статусе безопасности пакета linux доступна на странице трекера безопасности Debian. Применение обновления требует перезагрузки системы для активации нового ядра. Администраторы должны проверить совместимость с собственными модулями и конфигурациями перед обновлением в продакшене. Дополнительные рекомендации по применению обновлений и часто задаваемые вопросы доступны на официальной странице Debian Security.

Массовое присвоение CVE любому исправлению делает метрику «количество CVE» бесполезной для оценки реальной угрозы, так как приводит к росту числа записей и игнорированию их специалистами по безопасности. ИИ ускоряет обнаружение уязвимостей, но может вводить новые ошибки с аналогичной частотой. Пользователи часто откладывают обновления, а дистрибутивы медленно выпускают патчи, увеличивая риск эксплуатации. CVSS‐оценки, присвоенные CVE за исправления, часто не отражают реальную опасность: даже низкосерьёзные баги получают высокие баллы, а некоторые патчи в стабильных ветках получают оценки до 9.8. В 2026 году число присвоенных CVE превысило 100 000, но это не означает, что все они представляют реальную угрозу. Микрокернелы могут сократить поверхность уязвимостей, но их внедрение и поддержка остаются сложными. Открытый исходный код повышает обнаружение багов, но одновременно увеличивает риск эксплойтов при отсутствии контроля процесса. Рекомендуется использовать унифицированную схему версионирования A.B.C, где C — патчи безопасности, B — новые функции, A — системные изменения. Для повышения безопасности можно рассмотреть переход на Coreboot и EFI‐шимы, которые уменьшают привилегии загрузчика. Формально верифицированные микрокернелы, такие как seL4, представляют перспективу для обеспечения строгой изоляции.

Эксплойт Relapse-Exploit позволяет выполнить произвольный код на консолях PlayStation 5 с прошивками от 7.00 до 13.60 включительно. Для использования достаточно изменить Primary DNS в настройках сети на 45.56.67.85 и открыть веб-страницу эксплойта через браузер PS5 либо запустить локальный сервер с serve.py. После успешной эксплуатации загружаемый ELF-пайлоад становится доступным через порт 9021, а исходные бинарники сохраняются в директории payloads/.

Эксплойт состоит из двух этапов: браузерный использует утечки информации в JSC и несоответствие в пуле объектов structured clone для повреждения typed array, что приводит к выполнению кода в рендерере; ядерный этап сочетает утечку адреса с гонкой условий типа use-after-free в aio_multi_wait для достижения чтения и записи в ядре. Из-за возможной нестабильности Webkit может потребоваться несколько попыток перезагрузки страницы, а ядерный эксплойт иногда приводит к панике системы — в таких случаях рекомендуется перезагрузить консоль перед повторной попыткой. Проект создан для образовательных и исследовательских целей, его использование на чужих устройствах или для обхода защиты запрещено. Среди авторов: ntfargo, ufm42, Sonic_Iso, Jordy, Dr. Yenyen, TheFlow и другие.

Эксплойт позволяет выполнить произвольный код на PS5, но полноценный Linux пока невозможен без доступа к гипервизору. Уязвимость исправлена в прошивке 14.0, поэтому новые консоли защищены. Эксплойт работает на уровне ядра, но запуск Linux требует гипервизорного доступа, которого пока нет. Sony продаёт консоли в убыток и зарабатывает на играх, поэтому не заинтересована в открытии системы для пользовательского ПО. Уязвимость, вероятно, связана с JavaScriptCore в WebKit; Sony может отключить JIT в прошивке 14.0, чтобы снизить риск атак. Обсуждаются применения: медиа‐ПК, запуск Steam‐игр через проекты типа AnyPS5, но есть ограничения по контроллеру и стоимости. Память и хранилище ограничены 128 ГБ, что делает консоль неудобной для современных игр объёмом 50‐100 ГБ. Для использования рекомендуется запускать ELF‐payload через порт 9021 с локальным сервером serve.py, как в оригинальном гиде. Некоторые считают, что Linux на PS5 станет возможным благодаря усилиям сообщества и аналогам вроде Apple Game Porting Toolkit. Есть споры о конкуренции с Apple TV: один считает его способным запускать 4K‐игры, другой указывает на малый объём хранилища и отсутствие контроллеров. Для экспериментов советуют изучить проект ProsperoEden — порт Switch‐эмулятора на PS5, позволяющий запускать некоторые игры без полного доступа к системе.

Игра, превышающая доступный объём видеопамяти, не обречена на крах — главное ограничение — производительность, а не стабильность. При нехватке VRAM данные выгружаются в системную оперативку, а доступ к ней через PCIe‑4.0x16 (≈ 32 ГБ/с) ограничивает пропускную способность до ~1 ГБ за кадр, что делает невозможным удержание 30 fps, если требуется больше.

Ключевой нюанс — не все обращения одинаковы: небольшие буферы команд и часто используемые данные могут оставаться в CPU‑памяти без катастрофических потерь, особенно если они умеют кэшироваться. Поэтому оптимизация доступа и более тесное взаимодействие драйвера с приложением позволяют смягчить удар по FPS, делая «переполнение» VRAM менее болезненным.

Обсуждение смещает фокус с производительности на стабильность при нехватке RAM/VRAM. Пользователи отмечают критические различия в работе драйверов NVIDIA и AMD под Wayland: старые NVIDIA (750 Ti) вызывают краши композиторов при исчерпании VRAM, тогда как AMD (RX 480) бесшовно выгружает в системную память. Проблемы с утечками и стабильностью под Wayland/Vulkan сохраняются и на новых NVIDIA (2080). Для предотвращения зависаний рекомендуют systemd-oomd или Magic SysRq 'f'. Спор о том, какая ОС лучше справляется с нехваткой памяти: @krisknez утверждает, что Windows не фризит, но @alightsoul и @qwertox опровергают — Windows также зависает при активном swap или ресурсоёмких браузерах (Chromium); @adrian_b считает, что отказ от swap в Linux решает проблему. Поведение macOS неоднозначно: @inventor7777 отмечает сохранение отзывчивости (Ctrl+C работает) на M4 Max даже с артефактами, @LoganDark — сильную деградацию и необходимость перезагрузки после загрузки LLM. Улучшения Linux 7.3 менее значимы для LLM inference, чем для игр — в играх паттерны использования VRAM менее предсказуемы и требуют сложного управления памятью. Рекомендация: выделять 32 ГБ swap на быстрых SSD для комфортной работы с ВМ и тяжёлыми процессами. В Ubuntu 24 OOM-killer по умолчанию часто убивает Firefox, даже если память потребляют другие процессы — вызывает раздражение.

Уязвимость GhostLock (CVE‑2026‑43499) позволяет любому локальному пользователю без привилегий получить контроль над ядром Linux, который живёт в каждом из основных дистрибутивов более 15 лет. По данным исследователей, эксплуатация стабильна в 97 % случаев и уже привела к выплате $92 337 в рамках kernelCTF. Уязвимость появилась в версии 2.6.39 при упрощении PI‑алгоритма rtmutex и оставалась непатченной до версии 7.1; её активация требует лишь включения CONFIG_FUTEX_PI, без необходимости привилегий или специальных настроек. Через простую последовательность системных вызовов можно вытащить указатель на стек ядра, записать его в произвольный адрес и захватить таблицу функций, что в итоге даёт полное повышение прав и побег из контейнеров.

Техническая основа – ошибка в функции remove_waiter() в kernel/locking/rtmutex.c, где при ошибке прокси‑переадресации стека задачи очищается не тот указатель. Это приводит к использованию после освобождения (UAF) стека, который можно инициировать через системный вызов FUTEX_WAIT_REQUEUE_PI. В результате получаем dangling‑pointer к стеку, возможность записать произвольный адрес и перехватить управление, что в конечном итоге приводит к повышению до root. Эта уязвимость позволяет получить контроль над ядром без специальных прав, что делает её критически важной для всех дистрибутивов.

• Обсуждается уязвимость, позволяющая получить root через JavaScript в Firefox на Android, используя Chromium‑based браузер без JS.
• Уязвимость связана с устаревшими функциями ядра (GhostLock) и может привести к привилегированному доступу к системным ресурсам.
• Участники делятся мнениями о влиянии уязвимости на безопасность Android, необходимости обновлений и роли OpenBSD, SELinux и виртуализации.
• Есть споры о том, насколько такие эксплойты делают инфосекурность менее надёжной и требуют ли новых подходов к защите.

Процесс загрузки Linux начинается с нажатия кнопки питания, после чего процессор переходит в реальный режим (real mode) и выполняет инструкцию по адресу сброса 0xFFFFFFF0. Это приводит к запуску микропрограммы на материнской плате (BIOS или UEFI), которая выполняет самотестирование (POST) и ищет загрузочное устройство. При обнаружении загрузочного сектора (маркеры 0x55 и 0xAA), BIOS копирует его в память по адресу 0x7C00, после чего управление передается загрузчику GRUB. GRUB считывает свою конфигурацию, загружает ядро Linux в память и передает управление программе настройки, которая создает предсказуемую рабочую среду: выравнивает сегментные регистры, создает стек, очищает область BSS и запрашивает информацию о доступной памяти у микропрограммы. В конце концов, вызывается первая функция C с именем main, что标志着 переход к следующей фазе загрузки.

• Обсуждение показало, что статья о процессе загрузки Linux охватывает только самые базовые концепции, что вызвало критику за упрощение и упущение важных деталей, таких как взаимодействие с UEFI, инициализация видео и роль загрузчика.
• Участники подчеркнули, что статья не соответствует уровню подготовки аудитории Hacker News, и что она не раскрывает важные темы, такие как влияние UEFI на процесс загрузки.
• Также было отмечено, что статья не затрагивает такие важные темы, как влияние UEFI на процесс загрузки и не упоминает о таких важных компонентах, как initrd и драйверы.
• Некоторые комментаторы выразили сожаление по поводу того, что статья не затрагивает такие темы, как влияние systemd на процесс загрузки и не упоминает о таких важных компонентах, как initrd и драйверы.
• Также было отмечено, что статья не упоминает о таких важных компонентах, как initrd и драйверы, и не раскрывает влияние systemd на процесс загрузки.

Rust продолжает развиваться, и новые языковые функции, такие как проекции полей, инициализация на месте и произвольные типы self, становятся важными для разработки ядра Linux. Эти функции упрощают работу с указателями, позволяют избежать двойной инициализации и делают код более выразительным. Рядом с этими изменениями, Rust for Linux активно работает над стабилизацией существующих функций и разработкой новых, чтобы код ядра был не только безопасным, но и элегантным. Разработчики подчеркивают, что сообщество, включая участников Rust for Linux, играет ключевую роль в определении приоритетов разработки языка.

• Обсуждение охватывает вопросы от безопасного доступа к полям структур до сложных вопросов владения памятью в Rust, а также влияние этих обсуждений на разработку ядра Linux и взаимодействие с другими языками программирования.
• Участники обсуждали, что сложность Rust может быть препятствием для новых разработчиков, но также отметили, что сложность C++ может быть еще более запутанной.
• Обсуждались вопросы о том, как влияет на разработку ядра Linux внедрение Rust, и были высказаны мнения, что это может быть экспериментом, который следует проводить в другом месте.
• Также обсуждались вопросы о том, какие функции Rust могут быть полезны для разработки ядра Linux и какие функции Rust могут быть полезны для разработки ядра Linux.
• В конце обсуждение перешло к вопросу о том, какие функции Rust могут быть полезны для разработки ядра Linux и какие функции Rust могут быть полезны для разработки ядра Linux.

• Увлечение — восстановление данных с кассет QIC-80 90-х гг.
• Драйвер ftape (Linux 2.4) последний раз собирался ~2000 г.; с тех пор приходится держать CentOS 3.5.
• Привод подключается к контроллеру гибкого диска: дёшево, но 500 Кбит/с и куча «магии» портов/IRQ.
• Под DOS/Windows есть проприетарные утилиты, но только ftape даёт «сырой» дамп, независимо от формата ПО, которое писало кассету.

Цель: переписать драйвер под современное ядро без боли.
Инструмент — Claude Code (Claude 3.5 Sonnet) в режиме «актов» (акт = автоматический цикл «предложи-отладь-протестируй»).

Ход работы

1. Запустил claude в каталоге исходников ftape-4.04 (1999 г.).
2. Первый акт: «сделай модуль для ядра 6.10». Claude выдал:
   • заменил cli/sti на spinlock_t;
   • sleep_on → wait_event;
   • register_blkdev → blk_mq;
   • kmalloc → kmalloc_array;
   • добавил MODULE_LICENSE/AUTHOR/DESCRIPTION.
     Собралось с десятком предупреждений.
3. Акт 2: «убери варнинги». Убрал устаревшие ioctl, обернул printk в pr_*, добавил fallthrough;.
4. Акт 3: «проверь на x86_64». Исправил long ↔ int в структурах, выровнял u8/u16 через __packed.
5. Акт 4: «протестируй на железе». Создал QEMU-образ с контроллером FDC, подключил образ кассеты.
   • первый insmod — kernel oops; Claude добавил BUG_ON(!request_region) и проверку IRQ.
   • второй — ftape видит привод, но «unknown format»; Claude вставил распознавание QIC-80 по ID_CRC.
   • третий — успешный дамп 120 Мб за 40 мин.
6. Акт 5: «очисти и оформи». Удалил весь #ifdef LINUX_2_0, добавил README.md, Kconfig, Makefile для in-tree сборки.

Результат

• 2 500 строк C → 1 100; 45 файлов → 12; минус 4 архаичных под-драйвера.
• Собирается как out-of-tree (6.6–6.12) и как in-tree (патч 30 Кб).
• Скорость 470 Кбит/с — предел FDC, но стабильно.
• Поддержаны только QIC-80; QIC-40/3010/3020 выкинуты (никто не просил).

Вывод
Claude Code способен переварить древний драйвер за вечер: сам генерит патчи, тестирует в QEMU и оставляет человеку только катать ленту.

• Claude Code и другие LLM-инструменты превращаются в «силовой множитель» для разработчиков: ускоряют работу в знакомых фреймворках и позволяют быстро осваивать новые.
• Главное — самому понимать, что делаешь: чёткие промты, ключевые слова предметной области и умение сверять результат критически снижают количество багов.
• Примеры успеха: порт драйвера ftape с Linux 2.4 на 6.8, апгрейд Pydantic V1→V2, inline-ASM под Apple, модернизация 15-летнего PHP-кода — всё за часы вместо недель.
• Самые ценные фичи: долгие процессы в терминале, автоматическая проверка своего кода, быстрое написание тестов и бенчмарков «на заказ».
• Безопасность: при работе с sudo-операциями или ядром итерации лучше вести вручную, чтобы LLM не сломала систему.

32-битные системы устарели, но ядро всё ещё их поддерживает из-за старого «железа» и ПО.
Arnd Bergmann: новые продукты уже 20 лет выходят на 64-битных платформах; встраиваемые устройства постепенно переходят с armv7 (32-бит) на armv8 (64-бит).

• Arm: 90 % встраиваемых систем; лишь три старые архитектуры до-armv7 ещё можно купить, но ядро держит десяток выведенных из производства. Поддержку можно выбрасывать «по половинам», когда исчезнут пользователи.
• Другие 32-битные архитектуры (arc, microblaze, nios2, openrisc, rv32, sparc/leon, xtensa) вытесняются RISC-V.
• nommu (armv7-m, m68k, superh, xtensa) никто не выпускает, их держат лишь ради существующих систем.

Для несовместимых 32-битных приложений — запуск 32-битного userspace на 64-битном ядре: экономит память, не требует 32-битного ядра.

Боль разработчиков:

• Высокая память (highmem) усложняет mm-подсистему; нужна, когда физической памяти > ~800 МБ.
• Ядро пока держит 32-битные машины до 16 ГБ, но таких почти нет; 4 ГБ встречаются (Chromebook), 2 ГБ — чаще, но «глупо»: память дороже CPU.

• Участники обеспокоены удалением поддержки nommu/32-бит: это уменьшает свободу, лишает возможности запускать Linux на старом или простом железе и делает ядро похожим на «дорожную карту» Apple/Windows.
• Некоторые предлагают форк «Linux Legacy» или переход на NetBSD/OpenBSD, которые по-прежнему поддерживают старые архитектуры.
• Для встраиваемых устройств без MMU считают более подходящими Zephyr, NuttX или Contiki, а не полноценный Linux.
• Поддержка big-endian почти мертва, но сохранится, пока IBM вкладывается в s390x.
• Старые ядра и LTS-дистрибутивы ещё десятилетие обеспечат безопасность и работу выброшенного железа.

Почему античиты не работают в Linux

Доля геймеров на Linux растёт благодаря Steam Deck и надоедливым «фичам» Windows. Однако почти все сетевые хиты с античитом не запускаются или не подключаются к серверам: PUBG, Call of Duty, Rust, R6 Siege, EA FC 24, Destiny 2, Valorant, League of Legends и даже FACEIT/ESEA для CS2.

Как работают читы и античиты

Чит либо внешний процесс, читающий/писующий память игры, либо внедрённая DLL. ОС не даёт процессам трогать чужую память благодаря виртуальному адресному пространству: каждая программа «думает», что владеет всей ОЗУ, а процессор и ядро переводят виртуальные адреса в реальные.

Античиты борются с этим двумя путями:

1. Пользовательский режим – сканируют память, читают файлы, ловят подозрительные потоки. Легко обойти, если у чита есть root-доступ.
2. Ядро (kernel) – драйвер внутри ядра Windows имеет полный доступ к железу и памяти, может скрывать свои структуры и блокировать вмешательство. Vanguard, EAC, BattlEye и пр. работают именно так.

Почему это невозможно в Linux

• Linux — открытая система. Любой может собрать своё ядро, поставить патч, изменить ABI.
• Античиту нужен стабильный, неизменяемый и закрытый интерфейс ядра. В Linux этого нет: модуль, собранный под 6.9, не загрузится под 6.10, а пользователь может вообще отключить модульные загрузки.
• Даже если разработчик выпустит проприетарный модуль, сообщество его не примет: безопасность, GPL-лицензия, репутационные риски.
• Попытки «запечатать» Linux (secure boot + immutable образ) противоречат свободе системы и всё равно не гарантируют, что пользователь не пересоберёт ядро без проверок.

Что можно сделать

1. Играть в поддерживаемые игры: Apex, Fortnite, CS2, Elden Ring и др. уже работают через Proton.
2. Двойная загрузка или VFIO-виртуалка – запуск Windows в виртуальной машине с проброской GPU (сложно, но работает).
3. Облачный гейминг – GeForce NOW, Xbox Cloud и т.д.
4. Ждать – пока разработчики не придумают античит, который не требует закрытого ядра (маловероятно).

Вывод: пока Linux остаётся открытой системой, современные kernel-level античиты там жить не смогут.

• Критики считают, что анти-чит на уровне ядра — это по сути rootkit, который подрывает безопасность и конфиденциальность.
• Многие предлагают альтернативы: доверительные сообщества, выделенные игровые машины, серверные проверки или облачные платформы.
• Подчеркивается, что Linux по дизайну даёт пользователю полный контроль, что делает невозможным эффективный, но инвазивный анти-чит.
• Некоторые игроки готовы пожертвовать безопасностью ради «честной» игры, но большинство участников обсуждения считают такой обмен неприемлемым.

AnduinOS — лёгкий, приватный, бесплатный дистрибутив на базе Ubuntu.
ISO 2 ГБ, GNOME-оболочка, Flatpak-приложения, никакого слежения.
Совместим с пакетами Ubuntu, подходит для работы, игр, сервера и обучения.

Версии

• LTS 1.1 (Noble Numbat) — до апреля 2029, GNOME 46, ядро 6.11, стабильность.
• Standard 1.3 (Plucky Puffin) — до января 2026, GNOME 48, ядро 6.14, новейшие функции.

Ссылки

• Скачать | Документация | Исходники | Поддержать

«Переход с Windows прошёл безболезненно, система лёгкая и красивая» — пользователи.

• Многие спутали название «AnduinOS» с «ArduinoOS».
• Это одиночный проект китайского инженера Microsoft: ремикс Ubuntu с GNOME, стилизованным под Windows 11.
• Критика: «distro-дистро-дистро» не заслуживает звания OS, не ясен уникальный посыл по сравнению с Mint/Ubuntu.
• Плюсы: простая установка Flatpak, может помочь консервативным пользователям перейти с Windows.
• Минусы: нет ARM-сборки, в скриншотах замечен сомнительный WPS Office, отсутствует описание отличий от Ubuntu.