Hacker News Digest

Проект Gillou68310/DukeNukemZeroHour представляет собой полную декомпиляцию игры Duke Nukem: Zero Hour, выпущенной в 1999 году для Nintendo 64. Это техническое достижение позволяет изучать исходный код классического шутера, который ранее был недоступен для исследования. Декомпиляция открывает возможности для моддинга, анализа и сохранения наследия игровой индустрии.

Проект демонстрирует сложность работы с обратной инженерией старых игровых движков. Исходный код игры был восстановлен из исполняемого файла без доступа к оригинальным исходникам. Это важный вклад в сохранение истории видеоигр и позволяет новым поколениям разработчиков изучать архитектуру игр эпохи Nintendo 64.

• Duke Nukem: Zero Hour для N64 полностью декомпилирован на 100 %, но пока без человеческих имён переменных и функций.
• Сообщество спидранов и моддеров активно использует проект, а значит игра может быть портирована на ПК и модифицирована.
• Появились вопросы о правовом статусе: репозиторий не распространяет ROM-файл, но требует его наличия, и это может быть не вполне легально.
• Пользователи обсуждают, стоит ли LLM-ам помогать в автоматическом именовании переменных, или же это создаст риск ложных срабатываний и потери времени.

Похоже, вы предоставили только название "Detective Wiki", но не саму статью для пересказа. Для создания точного и ёмкого саммари в формате Markdown на русском языке мне нужен полный текст статьи с Hacker News.

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

• Пользователи отмечают, что игра «Where is X» нуждается в «естественном» завершении и награде за угаданное слово, а также в более коротком времени игры, чтобы она была похожа на Wordle.
• В игре «Where is X» повторяются одни и те же статьи, что вызывает усталость и снижает ценность контента.
• В «Where is X» не хватает визуального подтверждения правильного ответа, а также неясно, что именно считается победой.
• В «Where is X» не хватает визуального подтверждения правильного ответа, а также неясно, что именно считается победой.

Новый интерфейс std.Io.Reader в Zig может приводить к неопределённому поведению при использовании с буфером произвольного размера. Например, при передаче ридера из zstd-декомпрессора в функцию вывода с буфером 64 байта код либо аварийно завершается в режиме отладки, либо зацикливается в релизе. Проблема в том, что некоторые ридеры требуют конкретного размера буфера у писателя, но это требование не всегда очевидно или документировано.

Ситуация усугубляется тем, что сбой может зависеть от входных данных: с одними данными код работает, с другими — нет. Это создаёт риски для библиотек, где тип ридера неизвестен заранее, например, при обработке HTTP-заголовков. Автор спрашивает, не ошибся ли он, но если нет — это серьёзный изъян в дизайне API.

• Обсуждается потенциальная проблема безопасности или баг в Zig, но участники склоняются к тому, что это скорее единичная ошибка, а не системная уязвимость.
• Участники дискутируют о ценностном предложении языка Zig, описывая его как современную альтернативу C с лучшей эргономикой, компиляцией во время выполнения (comptime), явным управлением памятью и меньшим количеством неопределённого поведения.
• Критикуется реакция создателя Zig, Эндрю Келли, на конструктивную критику, которую некоторые участники сочли резкой и недружелюбной.
• Zig позиционируется как мощный инструмент для низкоуровневого программирования с ультранизкой задержкой (например, для HFT или игр), где безопасность не является приоритетом, в противовес Rust.
• В качестве альтернатив для модернизации C++ упоминаются другие языки, такие как Carbon.

• half/bfloat/float/double – 4 формата: 16, 16-Trunc, 32, 64 бит
• 0 – единственное число с экспонентой 0
• 2⁵²–1 – максимум значащих бит у double
• 1 – первое число после нуля
• 30 – смещение экспоненты float (127–97)
• (−1)²×2^(e–bias)×1.m – двоичная запись
• ×2× – десятичная мантисса
• Exact – точное десятичное значение
• Δnext / Δprev – шаг к соседнему числу

• Пользователи делятся лучшими визуальными объяснениями IEEE-754: ссылки на статьи Фабьена Санглара и Джулии Эванс.
• Обсуждают «красивую» печать float: нужно 9 значащих цифр для однозначности, но тогда 0.1 → 0.100000001; существуют быстрые алгоритмы Dragon4, Grisu3, Ryu.
• Интересный факт: сравнение float почти работает как сравнение signed-integer битов, если учесть знак и NaN.
• Проблема удаления от начала координат в играх: дальше → хуже точность; Kerbal и Minecraft иллюстрируют «Far Lands».
• Просят добавить fp8/fp4, жалуются на отсутствие денормалей, NaN, ∞ в визуализации.
• Кто-то считает IEEE-754 «дьяволом», предпочитает posits или рациональные числа (Raku/FatRat).