Hacker News Digest

Доля Linux-геймеров на Steam наконец преодолела психологически важный порог в 3%, достигнув 3.05% по данным опроса за октябрь 2025 года. Этот рост на 0.41% стал возможен благодаря устойчивому тренду и окончанию поддержки Windows 10, что побудило больше пользователей попробовать Linux. Windows по-прежнему доминирует с долей 94.84%, а macOS занимает 2.11%.

Несмотря на скромные на первый взгляд проценты, это уже миллионы пользователей. По последним официальным данным Valve за 2022 год, месячная активная аудитория Steam составляла около 120 миллионов, что означает более 4 миллионов Linux-геймеров. С учетом роста платформы и популярности Steam Deck, продающегося миллионами копиями, реальное число вероятно еще выше. Среди дистрибутивов лидирует SteamOS Holo с 27.18%, за которым следуют Arch Linux (10.32%) и Linux Mint (6.65%).

• Пользователи обсуждают переход с Windows на Linux для игр, отмечая, что большинство игр теперь работает через Proton, и что Steam Deck способствует этому.
• Некоторые упоминают, что единственное, что остаётся в Windows, — это играть в игры с античитом, так как Easy Anti-Cheat и подобные системы не работают под Linux.
• Участники также обсуждают, что, несмотря на то, что Linux-совместимость значительно улучшилась, всё ещё есть проблемы с драйверами, особенно с NVIDIA.
• Некоторые отмечают, что, несмотря на то, что Linux-совместимость значительно улучшилась, всё ещё есть проблемы с драйверами, особенно с NVIDIA.
• Также упоминается, что, хотя большинство игр теперь работает на Linux, всё ещё есть проблемы с некоторыми играми, которые не работают или имеют проблемы.

AWS опубликовал отчет о недавнем сбое, связанном с race condition в системе управления DNS. Автор статьи воспроизвел упрощенную версию проблемы с помощью верификатора моделей Spin и языка Promela. В системе участвуют DNS Planner (создает планы) и три независимых DNS Enactor (применяют планы в разных зонах доступности). Race condition возникает, когда один Enactor применяет новый план и начинает очистку старых, в то время как другой, отставший, все еще обрабатывает более старый план. Когда первый Enactor завершает очистку, он удаляет этот "старый" план, который на самом деле еще активен, что приводит к исчезновению DNS-записей.

Используя Spin, автор смоделировал Planner и два параллельных Enactor. Каждый Enactor проверяет свежесть плана перед применением и отслеживает высший примененный план. Во время очистки он удаляет только значительно более старые версии, но если удаляемый план совпадает с текущим активным, это сбрасывает флаг dns_valid в false. Spin систематически проверял все возможные состояния системы и обнаружил последовательность действий, приводящую к race condition, подтвердив уязвимость.

• Пользователи обсуждают, что формальные методы (TLA+, Alloy и т.д.) могли бы предотвратить инцидент, если бы инвариант «не удалять активный план» был бы формализован и проверялся непрерывно.
• Обсуждается, что реальные системы часто отклоняются от «чистой» модели из-за компромиссов с производительностью и стоимостью хранения логов и т.д.
• Участники спора сходятся в том, что даже если бы формальные методы были бы применены, они бы не предотвратили бы ошибку, если бы не было процесса, который бы гарантировал, что модель и код синхронизированы.
• Некоторые комментаторы подчеркивают, что даже самые продвинутые инструменты не могут предотвратить ошибки, если нет культуры их использования и процессов, которые бы обеспечивали бы, что модель всегда актуальна.
• В конце концов, большинство соглашается, что самым важным является не наличие формальных методов, а культура их использования и процессов, которые бы гарантировали бы, что модель всегда отражает код.

Законодательство, изначально созданное для борьбы с киберпреступностью, во многих странах используется для подавления журналистики. В Нигерии репортер Дэниел Оджуку был арестован вооруженной полицией и четыре дня содержался в заключении без предъявления обвинений, пока ему не вменили нарушение киберпреступного закона за статью о коррупции в администрации президента. Статья 24 нигерийского Закона о киберпреступности, запрещающая публикацию "грубо оскорбительной" или "непристойной" информации, неоднократно применялась против журналистов - в 2019 году под нее попал Агба Джалинго за публикации о коррупции губернатора (позже оправданный).

Хотя в 2024 году статью 24 изменили, новый закон все еще криминализирует "умышленное распространение ложной информации", которая может "нарушить общественный порядок" или "угрожать жизни", наказуемое тюремным сроком до трех лет. По словам представителя "Репортеров без границ", власти намеренно заглушают расследования о коррупции. Нигерия не единственная страна - в соседнем Нигере после переворота 2023 года восстановили тюремные сроки за "клевету" и "оскорбления" в интернете.

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

• Bluetooth-устройства не реализуют LESC, что делает их уязвимыми к MITM-атакам и снижает безопасность всей экосистемы.
• Apple и другие производители не реализуют OOB-паринг, что делает невозможным защиту от MITM-атак.
• Существует необходимость в современной замене Bluetooth, которая была бы безопасной и не имела бы проблем с подключением.
• Side-channel атаки, включая извлечение AES ключа из 90,000 трассировок, демонстрируют, что уязвимости существуют повсюду.
• Необходимо развивать и внедрять более безопасные протоколы и практики, такие как LESC и OOB-паринг, и развивать культуру безопасной разработки для предотвращения уязвимостей в будущем.

В работе с monorepo, где ежедневно делаются сотни коммитов, тесты внезапно начали проваливаться. Проблема была в изменении конфигурационного файла, который ссылался на неверный аккаунт, но найти виновника среди множества коммитов вручную было невозможно. Тогда коллега применил git bisect - инструмент, использующий бинарный поиск для локализации проблемного коммита. Это позволило точно определить, где именно был внесен сбойный код, после чего откат этого коммита восстановил работоспособность системы.

В статье приведен наглядный пример репозитория с функцией сложения, где намеренно введена ошибка - преобразование аргументов в строки. Запуск git bisect start, указание "плохого" и "хорошего" коммитов, затем git bisect run ./test_script.sh автоматически проверяет промежуточные версии. Инструмент последовательно тестирует коммиты, сокращая количество проверок вдвое на каждом шаге, и точно находит первый сбойный коммит, где функция add начала возвращать строку вместо числа.

• git bisect is a powerful tool for pinpointing the exact commit that introduced a bug, especially in large or poorly tested codebases.
• Its real value is in narrowing the search space when you lack the tests or architecture to reason about the code, not in replacing proper testing or code review.
• The discussion exposed a cultural divide: some developers see bisect as a last-ditch rescue tool for when tests or architecture have already failed, while others argue that if you need it, your process has already failed.
• Several commenters pointed out that if you have to reach for bisect, you probably lack tests, logging, or a clear commit history, and the real fix is to improve those, not to rely on bisection.
• The thread also surfaced the point that bisection is only useful if you can reliably detect the bug in every commit; if the bug is non-deterministic or only shows up in production, the tool becomes much less useful.

Generally the problem with carpark solar is the mounting solutions are low volume niche products that cost way more than traditional ground mounts. My biggest hope is that this policy creates a marketplace with actual competition that comes up with more cost efficient mounting so

Автор объясняет, что Isabelle сознательно отказалась от объектов доказательств, которые являются неотъемлемой частью обычных теорий типов. Это сделано потому, что объекты доказательств не нужны и занимают много места. Вместо этого Isabelle использует архитектуру LCF, где проверка типов осуществляется в языке реализации, а не в логике, что гарантирует легитимность шагов доказательства. Robin Milner имел это фундаментальное понимание 50 лет назад.

Лоуренс Полсон рассказывает о своем опыте работы с AUTOMATH и Martin-Löf type theory. Первоначально Isabelle была реализацией Martin-Löf type theory, которая до сих пор включена в дистрибутив как Isabelle/CTT. Однако автор переключился на более общий подход, вдохновленный AUTOMATH - "большим рестораном, который обслуживает любую кухню". В итоге Isabelle/HOL стала доминирующей, хотя де Брёйн не одобрял растущую мощь теорий типов и презирал теорию множеств.

• Обсуждение показало, что вопрос не в «плохих» зависимых типах, а в том, что они не нужны для большинства задач и не оправдывают свою сложность.
• Участники обсуждали, что отсутствие зависимых типов не мешает Isabelle/HOL доказать критически важные части математики, и что вместо этого важнее автоматизация и библиотеки.
• Сообщество отметило, что даже в языках без зависимых типов можно выразить «матрица 10×5 из float32», если размеры известны на этапе компиляции, и что это покрывает большинство практических случаев.
• Несколько участников поделились личным опытом, что попытка использовать зависимые типы в продакшене привела к тому, что команды отказались их использовать из-за кривой кривой обучения и отсутствия инструментальной поддержки.
• В итоге автор статьи подытожил, что выбор между зависимыми типами и другими системами типов часто сводится к личным предпочтениям и доступным инструментам, а не к объективным преимуществам.

Проект Open Space разрабатывает открытые аппаратные и программные решения для связи с отражением сигналов от Луны (Earth-Moon-Earth, EME), делая космическую связь доступной для радиолюбителей. Их основное предложение — программно-определяемая фазированная антенная решётка, работающая в C-диапазоне (4.9–6.0 Гц). Проект предлагает три уровня оборудования: Quad — 4-антенный SDR-модуль ($49-99), Mini — компактная фазированная решётка из 18 модулей (72 антенны, $899-$1,499) и Moon — высокоапертурная решётка из 60 модулей (240 антенн, $2,499-$4,999), специально созданная для экспериментов с EME. Ожидается поставка оборудования в марте 2026 года.

Ключевые характеристики включают полную дуплексную работу, пропускную способность 40 МГц на антенну, мощность передачи 1 Вт на антенну и коэффициент шума приёмника ~1.2 дБ. Решётки обеспечивают низкую задержку лучеобразования (<1 мс) и когерентное распределение времени. Для эксплуатации требуется любительская радиолицензия уровня Technician+. Проект не только упрощает сложную ранее задачу EME-связи, но и открывает возможности для радиоастрономии, сканирования неба и атмосферных исследований.

• Проект использует "Quad" SDR (4Tx×4Rx) для отражения сигналов от Луны (EME), совместимый с Raspberry Pi, первые поставки ожидаемы в конце года.
• Технические параметры: мощность 1W на антенну, усиление ~39.3 dBi, суммарная EIRP ~63.1 dBW, потери в канале ~283 dB.
• Споры о реалистичности: одни считают проект из-за огромных потерь и сложности неосуществимым, другие приводят расчеты, показывающие возможность приема при правильной модуляции и кодировании.
• Альтернативы: для глобальной связи можно использовать более простую HF-ионосферную связь, а EME рассматривается как уникальный, но сложный подход.
• Особенности связи: задержка ~2 секунды из-за расстояния до Луны, битрейт зависит от модуляции (теоретически до 250 Mbps для наземных линий, но для EME требует особой схемы).

Представлено руководство "Writing FreeDOS Programs in C" от Джима Холла, которое учит создавать программы для FreeDOS на языке C. Книга состоит из 9 частей, охватывающих основы программирования, синтаксис C, управление потоком, функции, массивы, работу с файлами и консольное программирование, завершаясь созданием пошаговой игры.

Проект изначально стартовал как видеосериал на YouTube с поддержкой через Patreon, где спонсоры получали ранний доступ к материалам и эксклюзивные ресурсы. После завершения видео серии руководство было отредактировано в книгу через издателя Lulu. Книга опубликована под лицензией CC BY 4.0 и скоро будет перемещена в обновленную Wiki FreeDOS.

• Обсуждение охватывает вопросы от выбора компилятора до лицензий, где упоминается как компиляторы с открытым исходным кодом, так и старые компиляторы вроде Turbo C, и при этом подчеркивается, что важно, чтобы компилятор мог породить код, который будет работать в DOS или FreeDOS без необходимости кросс-компиляции.
• Участники обсуждают, что важно иметь компилятор, который может породить код, который будет работать в DOS или FreeDOS, и что это может быть важно для сохранения старого кода, который может быть важен для поддержания старого оборудования.
• Также обсуждается, что FreeDOS может быть полезен для обновления BIOS и для запуска старого кода, который может быть важен для поддержания старого оборудования.
• Участники также обсуждают, что важно иметь компилятор, который может породить код, который будет работать в DOS или FreeDOS, и что это может быть важно для сохранения старого кода, который может быть важен для поддержания старого оборудования.
• Также упоминается, что FreeDOS может быть полезен для обновления BIOS и для запуска старого кода, который может быть важен для поддержания старого оборудования.

Выпущены исправления для трех критических уязвимостей в X.Org X server и Xwayland. Обновления xorg-server-21.1.19 и xwayland-24.1.9 исправляют проблемы, существовавшие в предыдущих версиях. Все три уязвимости (CVE-2025-62229, CVE-2025-62230 и CVE-2025-62231) были обнаружены Jan-Niklas Sohn при сотрудничестве с Trend Micro Zero Day Initiative.

Первая уязвимость связана с use-after-free при создании XPresentNotify структур, вторая - с некорректным удалением Xkb клиентских ресурсов, а третья - с переполнением значения в XkbSetCompatMap(). Две из этих проблем существуют с версии X11R6, что подчеркивает их серьезность. Все исправления уже доступны в репозиториях, и пользователям рекомендуется немедленно обновить системы для предотвращения потенциальных атак.

• В обсуждении поднимается вопрос о том, что X11/X.Org уязвим к трем недавно обнаруженным уязвимостям, и что это может быть последней каплей, которая убедит окончательно перейти на Wayland.
• Участники обсуждают, что X11 не имеет никаких механизмов безопасности, и что это не может быть исправлено без полной переработки.
• Некоторые участники высказывают мнение, что X11 устарел и что усилия по его поддержке были бы лучше направлены на другие проекты.
• Также обсуждается, что X11 не может быть защищен от вредоносного клиента, и что это не может быть исправлено без полной переработки.