Hacker News Digest

Десятилетиями криптографическое сообщество гадало, откуда взялись «зерна» (seed) для стандартных эллиптических кривых NIST, опубликованных в 2000 году в составе стандарта цифровой подписи FIPS 186-2. Эти параметры передала АНБ без каких-либо объяснений, что порождало подозрения в намеренных закладках. Ходила легенда, будто сотрудник АНБ Джерри Солинас сгенерировал зерна хешем шуточной фразы вроде «Дайте Бобу и Джерри прибавку». Проверка этой версии ни к чему не привела, а сам Солинас умер в 2023 году, оставив вопрос открытым.

В октябре 2026 года сотрудник Anthropic задал внутренней исследовательской модели вопрос о происхождении зерен — и меньше чем за полчаса Claude разгадал загадку для кривых P-192, P-224, P-256, P-384 и P-521. Никакого хеша не было: зерна оказались выводом генератора случайных чисел lrand48 из стандартной библиотеки C, инициализированного меткой времени Unix. Алгоритм брал по 20 байт за итерацию; для P-256 понадобилось 1842 итерации. Например, для prime192v1 подошла метка времени 20000.

Это не взлом и не ослабление кривых — наоборот, находка усиливает уверенность, что их выбирали без закладок.

Обсуждение подтверждает, что параметры кривых NIST получены из lrand48, инициализированного Unix‐временем, как показал Claude. Однако отсутствует окончательное объяснение некоторых seed‐ов, что вызывает скепсис относительно достоверности вывода и поднимает вопросы о практических последствиях. Некоторые пользователи (например, greatgib) сомневаются в доказательстве, указывая, что совпадение с lrand48 может быть случайным и не исключает наличия бэкдоров. teddyh предполагает, что необъяснимый seed B‐163 возник из‐за опечатки при публикации, поэтому поиск по правильному числу пока безуспешен. slowin предупреждает, что использование LLM для таких исследований создаёт асимметрию: провайдеры моделей получают информацию, недоступную обычным исследователям. sweis и tptacek отмечают, что раскрытие метода разрушает годы конспирологических теорий о преднамеренных уязвимостях в кривых NIST. nickysielicki утверждает, что Anthropic тайно стремится подорвать криптографию, но это личное мнение без доказательств. cowlby заметил, что первая цифра каждого seed никогда не превышает 7, что согласуется с 31‐битным выводом lrand48, где старший бит всегда 0. cloudfudge предлагает генерировать константы кривых из текущего времени при старте программы для упрощения управления параметрами. adastra22 считает, что такой способ генерации указывает на потенциальную уязвимость, сравнивая её с гипотетическим скрытым бэкдором. EGreg считает, что сообщества Bitcoin и Ethereum могут безопасно включать поддержку P‐256, так как доказано отсутствие преднамеренных уязвимостей в seed‐ах.

В 2026 году автор запустил коммерческий веб-сервис — marketyour.games — полностью на C через CGI, без фреймворков, контейнеров или отдельного сервера баз данных. Стек: OpenBSD, httpd, SQLite и статически скомпилированный бинарник. Все активы встроены в исполняемый файл, запросы обрабатываются через fork-процессы, а обновление — заменой одного файла без простоя. Использованы только три библиотеки: libcurl, libsodium и libcjson (включён как один файл), SQLite — в виде амальгамации. Система работает без JavaScript, поддерживает Stripe, Postmark и пользовательские аккаунты, при этом полностью изолирована через pledge, unveil и chroot.

Преимущества — полная прозрачность: нет слоёв абстракции, отладка — как у обычной программы через gdb, HTTP-логика проста и неизменна с 2004 года. SQLite устраняет необходимость в управлении сервером БД. Недостаток — отсутствие базовых утилит: автор сам написал cgi.h для обработки кук, параметров и валидации, но хотел бы стандартных библиотек в стиле stb. CGI не устарел — современные ядра эффективно оптимизируют fork, а FastCGI остаётся простым шагом вперёд. Стек оказался проще, надёжнее и легче в поддержке, чем любые современные решения.

Чистый C‐CGI‐подход прост, но в реальных проектах требует дополнительных мер: наблюдаемости (метрики, логирование, алертинг отсутствуют), конкурентного доступа к SQLite (каждый запрос открывает отдельный процесс, риск блокировок при записи), безопасности (уязвимости, риск RCE — нужна проверка кода и дополнительная защита) и удобства деплоя. Альтернативы: Go‐бинар без CGO (всё в одном файле, удобен для контейнеров), Rust‐фреймворки (Tokio, Actix — безопасность и производительность без проблем с памятью), FastCGI на C (стабильно работает, например, на FreeBSD с PostgreSQL). Простота архитектуры выигрывает в небольших проектах, но минимализм требует компромиссов. BusyBox содержит CGI‐bin — позволяет быстро развернуть веб‐интерфейс без отдельных серверов. Nginx не поддерживает CGI из коробки — нужен сторонний модуль или Lighttpd. Исторически в 1990‐х CGI‐скрипты писали на Perl, а не на C. Для безопасности C‐кода полезны инструменты вроде Fil‐C (проверка памяти). Отсутствие примеров кода в статье усложняет понимание — полезно добавить демонстрации запросов и ответов. Критика простоты C‐подхода в обсуждении почти отсутствует — возможно, недостаточно обсуждены потенциальные проблемы. Bash‐скрипты показывают минималистичный веб‐сервер, но не подходят для продакшна.

Я — низкоуровневый программист, чья идентичность строилась на глубоком понимании деталей: архитектуры процессоров, работы памяти, машинного кода и тонкостей языков вроде C или Rust. Я не просто писал код — я исследовал, как работает машина, считая такты, пишая OS-игрушки и отлаживая вручную. Для меня программирование было актом познания, а не создания утилит. Но индустрия сместилась в сторону абстракций, архитектурного мышления и «vibecoding», где ценят умение оперировать высокоуровневыми концепциями, а не знание того, что происходит под капотом. Возможности применить мои сильные стороны исчезают: компании предпочитают нанимать тех, кто работает с фреймворками, а не с ассемблером или кэш-линиями. Рост LLM усугубил кризис — теперь даже оптимизация кода и объяснение сложных концепций автоматизируются, делая мою экспертизу избыточной. Я физически не могу работать с большими кодовыми базами или архитектурой, поскольку мне нужно держать всё в голове, а LLMs, которые я пробовал, быстро превосходят моё понимание проекта, лишая меня смысла и контроля. Это привело к экзистенциальному кризису: я чувствую себя вытесненным, невостребованным, а моя страсть к низкоуровневому программированию — всё больше превращается в неприбыльное хобби, вытесняемое энтузиастами, ищущими признания, а не глубины. Я больше не вижу места для себя в индустрии.

Потеря глубокого понимания деталей в программировании вызывает эмоциональный кризис у низкоуровневых разработчиков, но выявляет ниши, где этот навык остаётся критически важным — кибербезопасность и оптимизация производительности, где LLM пока не могут заменить человеческое понимание архитектуры. Многие испытывают горе не из-за потери продуктивности, а из-за смерти идентичности, построенной на глубоком понимании машинных деталей — это не адаптация, а прощание с ушедшей эпохой. LLM не способны автоматически находить горячие участки кода или оптимизировать низкоуровневый код без чёткого понимания архитектуры и целей — они беспомощны без человеческого контекста. Работы в кибербезопасности — исследование уязвимостей, реверс-инжиниринг, анализ инцидентов — остаются областями, где детали определяют успех, и LLM не могут полностью заменить экспертов. Современные системы стали слишком сложны для удержания в голове — это не новость, но LLM усугубляют проблему, убирая стимул к глубокому пониманию, заменяя его поверхностным доверием к автоматизированным решениям. Спор: LLM генерируют ужасно неоптимизированный низкоуровневый код — например, снижение first paint с 4500ms до 1000ms в Claude, как заявлено, невозможно без ручной оптимизации, и это не достижение LLM. Спор: Один разработчик утверждает, что его коллега, почти не использующий LLM, остаётся самым ценным членом команды — он лучше всех понимает код, отвечает на вопросы и ловит баги в ревью, что опровергает тезис о неизбежной замене людей. Совет: Специализируйтесь на тех частях системы, где агентные потоки слишком рискованны — там, где ошибка может стоить миллионы, а не просто замедлить API — именно там глубокое понимание остаётся незаменимым. Совет: Используйте LLM как новый 'процессор' для логики — сосредоточьтесь на создании языков и систем для их контроля, что возвращает интерес к фундаментальным принципам информатики, а не к написанию кода. Совет: Ищите ниши, где ручная работа ценится — например, создание 'hand-made' ПО, где пользователи готовы платить за безупречный опыт, а не за быструю, но шаблонную автоматизацию. Совет: Переключитесь с написания кода на управление и поддержку — как один инженер, перешедший в менеджмент, заметил: люди, выполняющие агентную работу, требуют больше эмоциональной поддержки, и это новая возможность. Инженеры, которым важно понимание, а не построение, чувствуют себя потерянными — но это не слабость, а естественная реакция на уничтожение той культуры, где глубина ценилась выше скорости. Исторически, как и при промышленной революции, автоматизация уничтожает ремесло, но не устраняет потребность в мастерстве — она просто смещает его в более узкие, менее массовые ниши. Понимание компиляторов, кэширования CPU, TCP-стеков и пайплайнов остаётся ценным — даже если вы не пишете ассемблер, это знание позволяет находить скрытые узкие места, которые LLM не видят. Совет: Примите, что вы больше не сможете держать в голове всю систему — но это не значит, что вы перестали быть инженером; это значит, что ваша роль теперь — быть тем, кто понимает, что нельзя доверять автоматизации. LLM — это машина для интерполяции, а не для творчества; они не способны на открытия, как специальная теория относительности, если их обучали на данных до 1904 года — они не понимают, а пересобирают.

Выпуск Zig 0.17.0 стал результатом пяти месяцев работы 206 участников и 925 коммитов. Ключевое улучшение — переработка системы сборки с внедрением Build Server Protocol, что упрощает интеграцию с IDE и ускоряет разработку. ELF-линкер значительно улучшен, что делает инкрементальную компиляцию надёжной для всех пользователей на x86_64-linux. Обновлён уровень поддержки платформ: добавлен Tier 1 для Windows на ARM64, расширена поддержка Linux на RISC-V и улучшена работа на macOS. В языке удалён синтаксис умножения массивов, добавлены функции @bitCast с улучшенной безопасностью, @divCeil для точного округления вверх, @backingInt и @fromBackingInt для работы с перечислимыми типами, а также @SpirvType для Vulkan-разработки. Грамматика языка теперь формально специфицирована и протестирована фаззингом, что повышает надёжность парсинга. Перевод C-кода вынесен во внешний пакет, упрощая основной инструментарий. Zig остаётся ориентированным на создание надёжного, производительного и переиспользуемого кода, а развитие финансируется через Zig Software Foundation. Поддержка проекта через пожертвования помогает ускорить путь к версии 1.0.

Zig 0.17.0 — значительный шаг вперёд в интеграции с IDE и стабильности сборки благодаря Build Server Protocol и улучшенному ELF-линкеру, подтверждённому практическим опытом. Однако остаются споры: жёсткая политика против ИИ в репозитории критикуется за баны за личные проекты, хотя команда утверждает, что блокировки касаются только официальных пространств и могут быть ошибочными. Нестабильность сборок из-за изменений в build.zig между версиями признаётся, но некоторые считают её неизлемой ценой быстрого развития. Zig называют наиболее продуманным языком для человека по сравнению с C, Go и Haskell, несмотря на малую экосистему. Поддержка целевых платформ остаётся сильной стороной, сравнимой с C, особенно для SPIR-V и WebGPU. Векторизация циклов по-прежнему отключена из-за сложностей с LLVM, что разочаровывает разработчиков численных задач. Поддержка io_uring отсутствует в 0.17.0 — команда отказалась от реализации на последнем этапе, вызывая недовольство у тех, кто нуждается в асинхронном вводе-выводе. Несмотря на официальную политику против ИИ, Zig привлекателен для LLM-ассистированных задач из-за хорошей поддаче генерации и анализу кода. Пользователи советуют избегать слишком новых релизов в продакшене из-за риска поломки build.zig, рекомендуя фиксировать зависимости или использовать стабильные версии. Баны за ИИ часто ошибочны — рекомендуется обращаться в команду по email. Сообщество видит Zig как «живой» язык с быстрыми изменениями и энтузиазмом, похожим на ранние Node.js или ES6, привлекающим тех, кто готов к нестабильности. Сомнения в достижении 1.0 до 2028 года coexist с надеждой, что стабилизация IR и работа над проверкой жизненного цикла памяти могут ускорить релиз.

DwarfStar 4 (ds4) — это узкоспециализированный C-движок для локального запуска frontier-моделей: DeepSeek V4/V4.1 Flash, GLM 5.x и Qwen3.8 Flash Next. Он работает на высокопамятных Mac (Metal), CUDA и ROCm-устройствах, используя асимметричную 2-битную квантилизацию routed экспертов, сохраняя точность критических путей. Это позволяет размещать 284-миллиардные параметровые модели на машинах с 128 ГБ ОЗУ, где KV-кэш сохраняется на SSD по хешу промпта, ускоряя перезапуски без полного префилла.

Движок предоставляет три интерфейса: интерактивный CLI (./ds4), локальный HTTP-сервер с OpenAI/Anthropic-совместимыми API (./ds4-server) и нативный агент для постоянных кодинг-сессий (./ds4-agent), все разделяющие одно состояние модели и кэш. На M5 Max с 128 ГБ при контексте 65K токенов достигается 398.5 токенов/с на префилле и 27.6 на генерации; на DGX Spark аналогичной конфигурации — 823.0 и 13.8 соответственно. Установка: клонировать репо, скачать веса через download_model.sh ds4f-q2, собрать под бекенд (например, make cuda-spark) и запустить. Лицензия MIT.

ds4 эффективно запускает крупные MoE-модели на Apple Silicon с 128 ГБ RAM, обеспечивая высокую скорость генерации и поддержку длинных контекстов (до 1 млн токенов, ~22 токенов/сек на Qwen 3.8 Flash Next на M5 Max). Требует дорогостоящего оборудования, ограничивая доступность. ds4 отличается минимальными зависимостями, ориентацией на frontier-модели и асимметричной 2-битной квантизацией экспертов, позволяя размещать модели до 284 млрд параметров на потребительском железе. Поддерживает Metal (Apple Silicon) и CUDA/ROCm (другие платформы), фокусируясь на реальных сценариях использования на высокопроизводительном оборудовании, а не на универсальности. Разработчики расширяют ds4: добавлена поддержка Qwen3.8 и Vision, реализованы FFI-биндинги для Go (ds4go), улучшена интеграция с Hugging Face через TUI. SSD-стриминг позволяет запускать крупные модели (например, полные GLM 5.x) на системах с менее чем 96 ГБ RAM, расширяя применимость за пределы флагманских Mac. Пользователь @simoiacos разработал собственный инференс-движок для Intel Xe-LP (без XMX) на 32 ГБ ноутбуках, поддерживающий квантизированный Gemma-4, с планами расширения поддержки MoE-моделей. Пользователь @liuliu рекомендует Local Code (TestFlight) как альтернативу для 64 ГБ M5-Pro, поддерживающую DeepSeek 4.1 Flash и Qwen 3.8 27B с SSD-стримингом и кастомными квантами. Некоторые пользователи сомневаются в уникальности ds4 по сравнению с llama.cpp или ollama, которые также поддерживают длинные контексты и квантизацию. Комментатор @doctorpangloss утверждает, что квантизированный чекпоинт DeepSeek V4 низкого качества, что ставит под сомнение точность результатов несмотря на высокую скорость. Использование C вместо Rust обусловлено стремлением к минимальным зависимостям и максимальной портируемости (как в Redis), обеспечивая лёгкую интеграцию через FFI. Пользователь @neomantra создал ds4go — Go-биндинги и TUI-инструменты для загрузки моделей с Hugging Face, упрощая использование ds4 для не-C-разработчиков. Цена MacBook Pro M5 Max с 128 ГБ RAM (~7800 €) делает ds4 доступным лишь для узкого круга пользователей, ограничивая массовое распространение несмотря на технические достижения.

Tcl/Tk 9.1.0 — это текущая версия разработки, нацеленная на стабильный релиз в сентябре 2026 года. Она расширяет возможности Tcl и Tk, добавляя новые команды и C-подпрограммы. В Tcl появились команды unicode для нормализации Юникода, timer с монотонным таймером микросекундного разрешения и lfilter для фильтрации списков. Улучшена работа с переменными через interp set, расширены опции subst и switch, а в expr теперь доступны многие функции из C99-математики. Для C-API добавлены новые функции: Tcl_IsEmpty, Tcl_GetEncodingNameForUser, Tcl_AttemptCreateHashEntry, а также улучшенные функции работы со списками (Tcl_ListObjRange, Tcl_ListObjRepeat, Tcl_ListObjReverse) и время с использованием long long. На macOS реализована нечувствительность к регистру в путях файловой системы, на Windows переработан поиск через auto_execok и exec, а также улучшен поиск библиотек скриптов и кодировок. Внутреннее представление списков оптимизировано для больших данных, добавлена поддержка 64-битных размеров.

В Tk 9.1.0 акцент сделан на доступность: добавлена поддержка экранных читалок и начальная поддержка двунаправленного текста и RTL-языков. Появился новый виджет ttk::toggleswitch и команда tk attribtable. Команда send улучшена на macOS (Aqua), обработаны отрицательные расстояния экрана, расширены состояния в ttk::treeview и ttk::notebook. Улучшена работа с текстом на канвасе (Tk_CanvasTextInfo), добавлена возможность поворота текста в метках, ограничены размеры диалогов шириной экрана, улучшены цвета выделения в списках, а поддержка внешнего вида Windows XP удалена.

Tcl/Tk остаётся жизнеспособным в нишевых областях: VLSI CAD, сетевое оборудование, встроенные системы — благодаря стабильности, простоте GUI и уникальной архитектуре субинтерпретаторов. Tk — самый простой способ создать GUI на Unix/X11, превосходя XView и поздние альтернативы. Tcl как язык расширения был одним из первых, внедривших встраивание интерпретатора в C/C++-приложения, конкурируя с Lisp, Python и кастомными решениями. Он активно используется в CAD-инструментах для VLSI и электроники, где долгожительство обусловлено консерватизмом отрасли и надёжностью. Cisco применяет Tcl в IOS для скриптов и управления, подтверждая устойчивость в сетевом оборудовании. SQLite изначально разрабатывался как расширение Tcl, его дизайн (типизация, форматирование) вдохновлён Tcl, хотя сейчас работает автономно. Tcl поддерживает изолированные субинтерпретаторы с полной инкапсуляцией состояния, позволяя безопасно выполнять недоверенный код без GIL и сериализации — функция, превосходящая Python-подобные решения. Tcl/Tk-интерфейсы для логов показали лучшую производительность по сравнению с C# Forms, избегая утечек памяти и высокой загрузки CPU при обработке тысяч строк. AOLServer и TiK (AIM-клиент) использовали Tcl в 1990–2000-х, демонстрируя применимость в высоконагруженных сетевых приложениях. Спор: некоторые считают Tcl непригодным для веба из-за 'stringly typed' природы (словарь — список, список — строка), делая корректную сериализацию в JSON невозможной. Спор: одни называют Tcl 'опасной игрой' из-за upvar/uplevel, другие — 'идеальным для игры', подчёркивая гибкость и удовольствие от использования. Совет: Tcl/Tk остаётся хорошим выбором для маленьких утилит, особенно с SQLite, где синтаксис и типизация идеально дополняют друг друга. Tcl/Tk не поддерживает Wayland напрямую — работает только через XWayland, ограничивая применение на современных Linux-дистрибутивах. Несмотря на отсутствие новых книг и популярности, Tcl не умирает — он живёт в промышленных системах, где стабильность важнее трендов. Современные ИИ-модели способны генерировать рабочие Tcl/Tk-приложения с тестами, подтверждая предсказуемость языка для автоматизации. Linux-дистрибутивы, включая Arch, всё ещё поставляют Tcl 8.6, несмотря на выход 9.0 два года назад, указывая на медленное внедрение новых версий.

Переписав JSONPath из Rust в Zig, я оценил простоту и скорость Zig, но столкнулся с рядом непривычных моментов. IDE-поддержка оказалась слабой: только подсветка и базовое автодополнение, что заставило вернуться к работе через терминал. Однако система сборки build.zig оказалась удобной и гибкой — позволяла легко запускать тесты, отладку и проверку соответствия стандарту. Это даже вдохновило на переход на минималистичный стек: Helix + Alacritty + Zellij.

Структура проекта в Zig поощряет плоскую иерархию файлов — в отличие от Rust, где дробление на модули привычно, здесь вложенные папки создают трения при импорте без явной выгоды. Оказалось проще держать связанный код в одном файле и navigировать по разделам. При реализации столкнулся с нюансами управления памятью: в Zig нужно явно дублировать строки перед добавлением в вектор и использовать errdefer для очистки при неудаче — в Rust такая ситуация невозможна благодаря семантике move. Экосистема пока молода: отсутствуют зрелые библиотеки (например, regex без Unicode-свойств), а стандартная библиотека меняет API между версиями. Несмотря на это, Zig оставил впечатление современного, быстрого и перспективного языка — потенциального преемника C, который стоит развивать дальше.

Zig — молодой язык с потенциалом как преемник C, но его слабая IDE-поддержка, отсутствие автоматических деструкторов и фокус на аллокаторах вызывают сомнения в пригодности для продакшена. Rust уже обеспечивает безопасность памяти без GC и считается зрелым выбором для коммерческих проектов. Спор: Zig не требует мутаций из-за аллокаторов — иммутабельность возможна при явной передаче аллокатора. Мутация — выбор программиста, не требование языка. Спор: Отсутствие автоматических деструкторов в Zig критикуют как 'dead-end', но Rust также использует мутации под капотом, скрывая их за иммутабельным интерфейсом. Согласны: Rust — единственный язык, сочетающий высокую производительность, нулевой runtime-overhead и безопасность памяти без GC, незаменимый для продакшена. Совет: В Zig arena-аллокация с defer arena.deinit() упрощает управление памятью в циклах. Спор: IDE-поддержка Zig (ZLS) нестабильна несмотря на LSP — реальная проблема для разработчиков, привыкших к полноценным IDE. Спор: Для архивного порта K&R C C23 предпочтительнее Zig из-за минимальных изменений и стабильности; Zig слишком нестабилен для таких целей. Совет: LLM эффективен для перевода кода между языками, если поведение можно автоматически проверить — снижает риски. Согласны: Современные C-преемники (Zig, Odin, Jai) страдают от одержимости аллокаторами — полезно в нишевых сценариях, но не масштабируется на общие задачи. Спор: Цепочки итераторов в Rust критикуют как 'gaslighting', но защищают как нулевую стоимость абстракций — читаемость зависит от привычки. Согласны: Zig быстр и современен, но незрел из-за незавершённого синтаксиса, слабой инструментальной поддержки и отсутствия стандартов — в отличие от зрелого Rust. Совет: В Helix отсутствует сворачивание кода — затрудняет навигацию по большим файлам Zig, важно при выборе редактора. Согласны: Rust решает управление памятью на этапе компиляции без GC — несмотря на долгую компиляцию, надёжен для командной разработки. Совет: В Zig запуск конкретных тестов через build.zig проще, чем рутинные подходы в других языках — фильтрация по имени экономит время. Спор: Аналогия с выбором блюда в ресторане ошибочна, если есть инструменты (переводчик); в незнании выбор должен быть консервативным.

DuckDB v2.0, codenamed «Cyanoptera», выходит этим осенью и представляет набор кардинальных изменений: серверный режим через расширение quack и оператор CONNECT, новый SQL‑парсер, переработанную СУБД‑структуру, асинхронный ввод‑вывод и тип VARIANT. Серверный режим позволяет любой процессу DuckDB обслуживать базы данных по сети, а клиентские запросы можно отправлять напрямую на удалённый PostgreSQL или MySQL без копирования данных. Кроме того, в v2.0 введены триггеры, более строгая типизация и поддержка транзакций в многопользовательском режиме, что делает DuckDB конкурентоспособным для аналитических и даже транзакционных нагрузок.

Ключевые нововведения: серверный режим (quack + CONNECT), новый тип VARIANT для гибкого хранения схем, асинхронный I/O ускоряющий запросы, новая хранилище‑формат с улучшенной компрессией, а также новый C‑API и небольшие, но важные ломающие изменения (переход на lambda‑синтаксис). В статье также упоминается создание DuckDB Foundation Advisory Board, который будет влиять на дальнейшее развитие проекта. Эти изменения формируют фундамент для «года DuckDB как сервера» и открывают путь к масштабным распределённым решениям.

DuckDB v2.0 трансформируется из локального аналитического процессора в основу облачной аналитической инфраструктуры, что подтверждено использованием в продакшене: многотенантные системы с данными 5–150 ГБ на тенанта, обработка миллионов Parquet-файлов, замена серверных решений. Он превосходит PostgreSQL и MariaDB в OLAP-задачах благодаря колоночному хранению и встроенному процессу, но уступает в многопользовательской конкурентности без Quack. Поддерживает обработку данных, превышающих ОЗУ, на потребительском оборудовании, снижая требования к инфраструктуре. Асинхронный ввод-вывод в v2.0 критически важен для масштабной работы с Parquet и обеспечивает значительный прирост производительности. WASM-сборка весит ~10 МБ, пригодна для браузера; расширения не увеличивают размер бинарников существенно. Заменяет сложные ETL-пайплайны, позволяя объединять запросы к CSV, Parquet и базам данных в одном SQL-интерфейсе. Стандартная практика — анализ лог-файлов (например, Nginx access.log) на диске. Рекомендации: - Использовать Arc для ускорения сканирования через pruning при работе с Parquet. - Для расширений применять официальный шаблон extension-template. - Ручная настройка memory_limit необходима для предотвращения убийства OOM-killerом. - При аналитике в браузере кастомизировать Emscripten-сборку — она оптимизирована, но требует настройки. - Документировать новый PEG-парсер — его детали критичны для совместимости. Quack (серверный режим) и CONNECT к PostgreSQL делают DuckDB гибридным инструментом, интегрируемым с OLTP-системами. Споры: - Некоторые считают DuckDB неподходящим для распределённой обработки против AWS Athena с Trino, но Quack и DuckLake меняют эту динамику. - Одни выражают разочарование, что DuckDB не переписан на Zig, другие не видят в этом проблемы.

GitHub-проект h3.c реализует нативную инференс-систему для модели MiniMax H3 на Apple Silicon, используя Metal для максимальной производительности на M3 Max и M5 Max. Система работает по принципу вертикальных слоёв: сначала загрузка метаданных, затем оптимизация вычислений — от кодирования промптов до генерации видео и аудио с условием по первому и последнему кадру. Поддерживается интерактивный режим, где промпты, условия и модели остаются в памяти между запросами, что ускоряет повторные генерации. Можно задавать опорные изображения через !ref-image, управлять последовательностью ссылок и сохранять результаты в MP4 без перезагрузки модели.

Оптимизации включают специализированные Metal-ядрa: для внимания — компиляция матриц 7168×5376 в статические тензоры, что даёт прирост до 0.8% скорости; для FC1 и FC2 — целочисленные (int8) масштабы с точной квантизацией, сохраняющие байт-идентичность вывода. При длине последовательности ≤2048 строк применяются оптимизированные 128-потоковые редукции, уменьшающие чтения памяти. Для экономии памяти слои модели загружаются по частям — трансформер, кодировщик и декодеры не живут одновременно в Unified Memory. Команда --profile показывает временные метрики, а --show отображает промежуточные кадры в терминале (Kitty, iTerm2). Использование --layers 45 и --reuse 2 снижает время генерации на 30–40% без потери качества.

Пользователи делятся опытом использования модели MiniMax H3 на устройствах Apple с M5 Pro, M5 Max и Mac Studio: модель эффективна при достаточном объёме памяти, но требует значительных ресурсов и долго генерирует видео. Спорят о необходимости 64 ГБ против 128 ГБ ОЗУ для комфортной работы. Рекомендуют оптимизировать работу через ComfyUI и аналогичные инструменты. Модель подходит для генерации видео и изображений, но неэффективна на устройствах с ограниченной памятью.

Интерактивный эксплорер исходного кода Linux kernel позволяет просматривать дерево файлов и структуры данных, открывать исходники для изучения. Гид начинается с первой главы "Understanding Linux Kernel Before Code": ядро — не процесс, а всегда присутствующая система, мост между аппаратным и ПО; оно обслуживает пользовательские процессы через системные вызовы, прерывания и планировщик; организована в слои — виртуальные, отображенные, изолированные и контролируемые.

Рекомендуемые файлы для изучения: init/main.c, kernel/fork.c, include/linux/sched.h, arch/x86/kernel/entry_64.S. Тест знаний проверяет: разницу kernel и процесса (kernel — не процесс, а сама система), способы обслуживания (оркестрация syscalls, interrupts, scheduling), характеристики слоев (virtual, mapped, isolated, controlled). Гид включает 9 глав — от системных основ до scheduling, I/O и virtualization, с веткой @master.

• Пользователи хвалят интерактивный гид по исходникам Linux kernel как удобную "карту" для новичков, сравнивая с Талмудом и инструментами вроде Elixir Bootlin.
• Отмечены баги: ошибки загрузки файлов (entry_64.S), GitHub API rate limits, проблемы с сертификатом .dev, мобильной версией и позиционированием в файлах.
• Сравнения с Elixir (лучше поиск, теги, мобильность); пожелания AI-объяснений, графов зависимостей, локального деплоя и версий для CPython/Emacs/Vim.
• Критика: отсутствие поиска/редактирования/grep, слабые квизы (возможно AI-generated), ожидания большего от "AI-эры".

Perl не мёртв, его популярность находится на уровне периода dotcom пузыря, согласно отчёту CPAN 2023. Новичков среди пользователей Perl становится всё меньше с 2011 года, хотя общее использование языка остаётся стабильным. Raku (бывший Perl 6) не стал причиной упадка, так как Perl продолжал расти даже во время разработки Raku.

Основные гипотезы упадка Perl связаны с изменением поколений программистов и развитием инструментов разработки. Программисты, выросшие на Unix-системах, естественно воспринимали Perl как продолжение shell, C, awk и sed. Новое поколение, воспитанное на Microsoft, Visual Basic и Java, предпочло Python. Кроме того, появление мощных менеджеров пакетов сделало доступными множество альтернатив, в то время как раньше Perl был одним из немногих доступных инструментов.

• Perl умер не из-за Raku, а из-за отсутствия единого пути развития, отсутствия стандарта кодстайла и культуры «один-разовых» скриптов.
• Python и PHP выиграли, потому что они были «дружелюбнее» для новичков и имели лучшую документацию.
• CPAN стал менее удобным, чем PyPI и npm, что сделало Perl менее привлекательным.
• Отсутствие единого фреймворка для веб-разработки и отсутствие стандарта ООП в Perl 5.
• Не было единого сообщества, которое могло бы продвигать Perl, в то время как Python и JavaScript имели Google и Facebook.

Автор создал заголовочный файл safe_c.h (600 строк), добавляющий в C современные средства безопасности из C++ и Rust, сохраняя при этом производительность и простоту языка. Этот файл используется для создания высокопроизводительного grep-клона cgrep, демонстрируя, как можно обуздать "опасные возможности" C. safe_c.h предоставляет семантику RAII через атрибуты [[cleanup]] с обратной совместимостью для старых компиляторов, а также умные указатели UniquePtr и SharedPtr для автоматического управления памятью.

Заголовочный файл включает макросы LIKELY/UNLIKELY для оптимизации ветвления и гарантирует очистку ресурсов даже при раннем возврате или goto. UniquePtr автоматически освобождает память при выходе из области видимости, устраняя утечки, а SharedPtr реализует автоматический подсчёт ссылок. Автор утверждает, что с помощью таких инструментов C остаётся языком свободы и гибкости, позволяющим писать безопасный код без потери производительности.

• Обсуждение показало, что безопасность в C требует компромисов: либо платить за счёт производительности (POSIX-мьютексы), либо отказаться от переносимости кода.
• Участники спорят, стоит ли вообще пытаться эмулировать современные примитивы безопасности в C, или лучше просто использовать C++ там, где это возможно.
• Поднимается вопрос, что макросы и обёртки в C ведут к созданию "мини-языка" внутри проекта, что затрудняет понимание кода для новых участников команды.
• Обсуждается, что C++ уже реализовал всё, что пытаются эмулировать в C, и что это не избежно ведёт к "переизобретению велосипеда".
• Участники обсуждают, что встроенные в компилятор возможности C++ вроде std::unique_ptr и std::shared_ptr не только более безопасны, но и более производительны, чем попытки их эмулировать в C.

Zig - это не просто замена C или C++, а совершенно новый подход к программированию, который удивил автора с 45-летним опытом. Самые впечатляющие особенности языка - встроенная возможность компилировать C-код и кросс-компиляция "из коробки", что уже оказывает значительное влияние на индустрию.

Установка компилятора Zig проста и доступна для различных платформ и архитектур на официальном сайте. Автор подчеркивает, что эти функции сами по себе уникальны, но сосредоточен на том, как программировать на Zig и почему стоит выбрать его вместо других языков.

• Статья преувеличивает инновативность Zig, не подкрепляя заявления о "революционности" реальными уникальными фичами.
• Пользователи отмечают практические преимущества: простота установки (через PyPI), кросс-компиляция, явный синтаксис и компиляция C-кода.
• Критика включает отсутствие безопасности памяти, спорные решения (политика идентификаторов, отсутствие данных в ошибках) и сравнение с Rust/Ada как более зрелых альтернатив.
• Отдельные хвалят метапрограммирование (comptime), простоту навигации по коду и удобство для низкоуровневого программирования.
• Обсуждение подчеркивает субъективность восприятия: для одних Zig "меняет подход к программированию", для других — лишь "улучшенный C" без уникального позиционирования.

Filip Pizlo выпустил проект Fil-C, добавляющий проверку безопасности памяти в clang и включающий параллельный сборщик мусора. Инструмент демонстрирует высокую совместимость с существующим кодом, позволяя с минимальными исправлениями собирать полный Linux userspace. По измерениям, производительность составляет 1-4x (и более широкий диапазон по другим тестам), что для многих рабочих нагрузок является приемлемым. Проект основан на долгой линии исследований в области безопасности памяти, включая работы самого автора в Apple, где некоторые предыдущие итерации уже используются в производстве.

Несмотря на преимущества, Fil-C имеет ограничения: он динамически, а не статически предотвращает ошибки, программы все еще могут аварийно завершаться, есть накладные расходы на память (3-6x), и он не решает проблему гонок данных. Автор отмечает интересную возможность применения - проверки границ Fil-C могут сделать указательный код на C безопаснее, чем небезопасный Rust, и предлагает идею адаптации для компиляции небезопасных блоков Rust с дополнительными проверками.

• Почти все программы имеют пути, которые могут привести к краху, но это не означает, что они будут достаточно часто встречаться, чтобы быть проблемой.
• Fil-C обеспечивает безопасность памяти, но требует сборщика мусора и может быть медленнее, чем Rust.
• Стоит ли переписывать код на Rust, если Fil-C может обеспечить безопасность памяти без переписывания.
• Стоит ли переписывать код на Rust, если Fil-C может обеспечить безопасность памяти без переписывания.

К сожалению, я не вижу полного текста статьи для создания пересказа. В предоставленном фрагменте только заголовок "Rob Ricci: 'While cleaning a storage room, our staff found th…'" и ссылка на discuss.systems, но отсутствует основное содержание.

Для создания точного и ёмкого пересказа (~170 слов в двух абзацах) мне нужен полный текст статьи. Пожалуйста, предоставьте содержимое статьи, и я с удовольствием подготовлю для вас качественный пересказ в соответствии с вашими требованиями.

• Восстановление ленты Unix V4 (1973 г.) — первой версии, написанной на C, — может дать нам единственный сохранившийся образец кода той эпохи.
• Проект, в котором участвуют исследователи из университета Юты, подразумевает извлечение битовой копии с ленты и последующее распространение ее через GitHub под лицензией BSD-2-Clause.
• Поскольку лента хранилась в сухом климате, шансы на то, что данные уцелели, высоки; однако никто не может гарантировать, что 50-летняя лента 9-дорожечной записи не содержит ошибок.
• Даже если в итоге окажется, что часть данных утрачена, сообщество может в конце концов получить хоть какие-то фрагменты кода на C, что само по себе уже является сенсацией.
• Вопрос о том, какие именно части кода первоначально были потеряны, остается открытым — возможно, они были утеряны еще в 1970-х.

Автор изучает необычный стиль написания кода Артура Уитни, создателя языков программирования A, K, Q и высокопроизводительных баз данных kdb и Shakti, используемых в финансовой индустрии. Основное внимание уделено компактному интерпретатору языка K размером всего около 50 строк на C, который демонстрирует уникальный подход Уитни к программированию. Код насыщен макросами и использует необычные синтаксические конструкции C, что делает его трудным для понимания, но потенциально эффективным для быстрого восприятия всей логики целиком.

Автор мотивирован изучению этого стиля кода по нескольким причинам: желание писать более компактный код, возможность более быстрого понимания сложных систем при концентрации всей логики в одном месте, а также то, что чтение кода стало важнее его написания в его работе. Интересно, что Уитни использует тип char * как для строк, так и для целых чисел, что является одним из его необычных подходов. Несмотря на первоначальную сложность, автор смог разобраться в большинстве частей кода к концу изучения.

• Код стиля Артура Уитни (Arthur Whitney) — это микро-DSL на препроцессоре C, который вдохновлялся APL; читать его лучше всего, если вы знакомы с APL, иначе он может казаться нечитаемым.
• Подход «сначала напиши, потом сделай это читаемым» противоположен современному подходу «сначала сделай это читаемым, потом напиши код».
• Сторонники и противники такого стиля спорят о том, является ли это «искусством» или «самообфускацией»; в то время как другие считают, что это просто вопрос привычки и что читаемость может быть улучшена с помощью современных инструментов.
• Некоторые комментаторы отмечают, что стиль кода Уитни может быть трудным для чтения, но он также может быть более выразительным и эффективным для тех, кто привык к APL.
• В конце концов, обсуждение пришло к выводу, что важно не только то, как стиль кода влияет на читаемость и поддерживаемость, но и то, как команда работает вместе, чтобы поддерживать и развивать код в течение длительного времени.

Автор рассказывает о своем пути к любви к Erlang, начавшегося с непонимания базовых концепций программирования в восемь лет, когда столкнулся с выражением "X = X + 1" в BASIC, показавшимся ему математической ложью. В университете он столкнулся с такими же трудностями при изучении C, но продолжил учиться через практику и эксперименты. Переломный момент наступил, когда партнер по бриджу спросил, как суммировать числа от 1 до 10 без циклов, что привело его к открытию рекурсии в Prolog — математически чистого подхода, где описывалось "что" является, а не "как" вычислять.

Знакомство с Erlang произошло случайно на турнире по бриджу от шведского игрока, который описал его как функциональный язык для распределенных, отказоустойчивых систем. Автор был поражен возможностью простого обмена сообщениями между разными узлами без сложных протоколов, демонстрируя пример ping-pong на Erlang. Этот язык, сочетающий функциональность, распределенность и отказоустойчивость, стал тем, что он искал с детства — способом программирования, где математика говорит правду.

• @az09mugen отмечает полезность функции > cd .. в конце статьи за простоту и мобильную доступность.
• @az09mugen предполагает наличие пасхалки (easter egg) в этой функции.
• @Gleamball выражает благодарность за выступление и обмен информацией.

SQLite написан на C, а не на более современных языках, по нескольким ключевым причинам.

Производительность и контроль: C позволяет разработчикам писать код, который выполняется максимально близко к аппаратному уровню, что критично для низкоуровневых библиотек, таких как SQLite. Хотя некоторые языки могут заявлять о схожей производительности, C остается эталоном. Кроме того, его "портабельность" (работа практически на любой платформе) делает его универсальным.

Совместимость и стабильность: Библиотеки на C могут использоваться практически из любого другого языка программирования, что делает SQLite доступным для разработчиков на разных платформах и в разных экосистемах. C также является зрелым и стабильным языком, что минимизирует риски, связанные с изменчивостью более молодых языков.

Минимальные зависимости: В отличие от многих современных языков, которые требуют объемные среды выполнения, код на C имеет минимальные зависимости. Это делает развертывание легким и надежным, что критично для встраиваемых систем, где SQLite часто используется.

Хотя существуют аргументы в пользу использования объектно-ориентированных или "безопасных" языков (таких как Rust), эти варианты были либо недоступны, либо незрелы, когда начиналась разработка SQLite. Более того, переход на новый язык потребовал бы значительных усилий без гарантии улучшений, особенно учитывая, что SQLite уже хорошо отлажен и оптимизирован в своей текущей реализации на C.

• Обсуждение вращается вокруг того, стоит ли переписывать SQLite на другие языки, но аргументы сводятся к тому, что существующий код уже безупречен, а переписывание может внести новые баги и даже замедлить работу.
• Подчеркивается, что SQLite — это не только код, но и 100% покрытие тестами и 25 лет отладки, что делает язык менее важным, чем для других проектов.
• Участники обсуждения отмечают, что языки вроде Rust всё ещё молоды и меняются, а также не предоставляют преимуществ в контексте уже готового кода.
• Поднимается вопрос о том, что важнее — язык или разработчики, и подчеркивается, что последние могут писать на любом языке, если бы это действительно было нужно.

Переменные окружения — это наследие прошлого: они устроены как плоский глобальный словарь строк без пространств имён или типов, и передаются от родительского процесса к дочернему.

В Linux они передаются через execve как массив строк вида KEY=VALUE. Внутри процесса они хранятся в стеке или куче, а программы используют разные структуры данных для их представления: Bash использует хешмапы, Python — словари, а C — массив environ.

Важно помнить, что изменения в дочернем процессе не влияют на родительский, и не все инструменты наследуют окружение. Например, login задаёт свежее окружение.

Из-за отсутствия пространств имён или типов легко допустить ошибку, например, перезаписать критичную переменную PATH. Хотя они удобны для конфигурации, их следует использовать с осторожностью.

• Обсуждение охватило широкий спектр тем: от безопасности переменных окружения до передачи секретов, влияния на разные системы и стандарты, и даже до влияния на разработку программного обеспечения.
• Участники обсуждали, что переменные окружения небезопасны для передачи секретов, так как любой процесс может прочитать их.
• Были упомянуты альтернативы, такие как systemd-creds, которые могут быть использованы для передачи секретов безопасно.
• Также обсуждались проблемы с конфигурацией и стандартами, такие как использование переменных окружения для конфигурации вместо файлов конфигурации.
• Участники также обсуждали влияние переменных окружения на разработку программного обеспечения, включая влияние на разработку в Windows и Unix системах.

MAML — это минималистичный формат для данных, который сохраняет читаемость для человека и при этом остаётся простым для машинной обработки. Он сочетает лучшее из JSON, дополняя его комментариями, многострочными строками и необязательными запятыми и кавычками.

MAML уже реализован в нескольких языках, включая JavaScript, Python, Rust, C и PHP. Эти реализации находятся на разных стадиях разработки: от готовых к использованию до находящихся в активной разработке.

Проект полностью открыт, с кодом на GitHub, и распространяется по лицензии MIT, что позволяет свободно использовать, модифицировать и распространять его.

• Обсуждение вновь подтвердило, что вместо улучшения JSON/YAML/TOML появляется всё больше новых конфиг-языков, но никто не решает их проблемы с синтаксисом, датами, комментариями и т.д.
• Участники обсуждения отмечают, что большинство этих новых языков не решают фундаментальные проблемы, такие как отсутствие типов данных, дат и комментариев в JSON.
• Некоторые комментаторы подчеркивают, что вместо того, чтобы изобретать новые языки, лучше бы улучшить существующие инструменты, такие как JSON5 или TOML.
• Другие участники поднимают вопрос, что если бы разработчики потратили усилия на улучшение существующих инструментов, вместо создания новых, это было бы более продуктивно.

Разработчик выложил на Hacker News фреймворк на C, и я, как исследователь безопасности, сразу заметил три классические ошибки: не проверяемый Content-Length, переполнение при копировании тела запроса и переполнение при записи ответа. Пример кода показывает, как непроверенное поле Content-Length используется как размер для malloc и memcpy, что может привести к утечке памяти или чтению за пределы буфера. Подобные проблемы встречаются везде, где C-фреймворки принимают ввод из сети или файловой системы.

• Обсуждение крутится вокруг того, что «хороший код на C» должен минимизировать выделение памяти и избегать atoi() и strdup() без проверки ошибок, что приводит к уязвимостям.
• Участники спорят о том, насколько критичны эти проблемы в контексте обучения и использования ИИ-помощи, и о том, что новички в C могут не осознавать эти ловушки.
• Обсуждается влияние ИИ на качество кода и безопасность, а также то, что влияние ИИ на обучение языкам может маскировать проблемы, которые иначе были бы очевидны.
• Участники также обсуждают, что влияние ИИ на обучение языкам и на то, что это может привести к проблемам, если человек не понимает, что делает ИИ, и что это может быть опасно.
• В обсуждении также поднимается вопрос о том, что ИИ может быть использован для аудита кода и нахождения проблем, и о том, что это может быть использовано для улучшения качества кода.

Краткий пересказ:
lavandula — это минималистичный веб-фреймворк на C, который обещает «скорость C и удобство Python». Проект с открытым исходным кодом, лицензия MIT. Сейчас он находится в стадии альфа-тестирования: базовый роутинг, middleware, JSON-ответы и простой шаблонизатор уже работают. Пример «Hello, world» компилируется в 12 КБ статического бинарника, а полноценный REST API сервис — меньше 100 КБ.

Планы: добавить встроенный ORM, WebSocket и SSE, а также CLI-генератор проектов. Поддержка Windows пока нестабильна, но Linux и macOS уже можно использовать. Сообщество приветствует вклад: обсуждение ведётся в Discussions, а примеры кода и бенчмарки публикуются в репозитории.

• Проект получил похвалу за чистоту и современный стиль кода, но также вызвал споры о практичности и безопасности C-фреймворков.
• Участники обсуждали, насколько целесообразно писать веб-приложения на C, и поднимались вопросы о безопасности и удобстве использования.
• Некоторые отметили, что проект может быть полезен для обучения и как отправная точка для других языков или фреймворков.
• Были также упоминания о том, что проект может быть развит с добавлением функций вроде шаблонизатора или поддержки HTTPS.
• Некоторые комментарии подчеркнули важность тестов и обработки ошибок в коде, а также отметили, что проект может быть использован как основа для других языков или фреймворков.

DARPA запускает программу TRACTOR для автоматизированного перевода уязвимого наследуемого кода на C в безопасный язык Rust. Проблема памяти — наиболее распространённый тип уязвимостей, возникающих из-за прямого управления памятью в C и неопределённого поведения. Несмотря на осознание проблемы, масштабный ручной переписывание кода был невозможен из-за огромного объёма legacy-систем, включая критическую инфраструктуру и оборонные проекты.

Программа использует прорывы в машинном обучении, включая большие языковые модели, для автоматизации перевода с сохранением идиоматичности и качества Rust-кода. TRACTOR будет сочетать статический и динамический анализ с ИИ, проводя публичные соревнования для тестирования решений. Цель — устранить целый класс уязвимостей безопасности, переложив ответственность с программиста на язык, который принудительно обеспечивает корректность работы с памятью.

• Критика синтаксиса Rust и его неидиоматичности для некоторых задач по сравнению с TypeScript, C#, Go или Python, при признании превосходства его инструментов (Cargo, система сборки).
• Обсуждение возможности создания безопасной реализации C (как Fil-C) и аргументы, что проблема не в языке, а в выборе реализации, жертвующей безопасностью ради производительности.
• Сомнения в эффективности автоматической трансляции C/C++ в Rust и риске получения "C с акцентом Rust" вместо идиоматического и безопасного кода.
• Дебаты о применимости Rust в оборонной сфере и его сравнение с другими языками (Zig, Go) по простоте сборки, зависимостям и размеру стандартной библиотеки.
• Споры о философии дизайна Rust: фокус на композиции вместо наследования, сложности borrow checker и несовместимости некоторых идиом C++ с моделью безопасности Rust.

Zig предлагает более простой подход к созданию CLI-инструментов по сравнению с Rust, особенно когда речь идёт о работе с памятью. В Rust строгий borrow checker предотвращает ошибки на этапе компиляции, но часто вынуждает переписывать код под его требования, усложняя разработку. Например, при попытке добавить новую запись в список, одновременно удерживая ссылки на существующие, компилятор Rust блокирует действие из-за конфликта владения и заимствования.

В Zig же разработчик напрямую управляет памятью через аллокаторы, используя указатели и мутацию без сложных правил времён жизни. Это требует дисциплины, но даёт больше гибкости и скорости написания кода. Для CLI-инструментов, где производительность и простота часто важнее абсолютной безопасности памяти, Zig оказывается практичнее. Безопасность — это не только отсутствие ошибок памяти, но и читаемость, скорость разработки и соответствие задаче.

• Обсуждение затрагивает проблемы безопасности в C, связанные с ручным управлением памятью, и ироничные комментарии по этому поводу.
• Пользователи делятся мнениями о современных языках (Nim, Odin, V, D, Zig), отмечая их преимущества, такие как интероперабельность с C и гибкость в управлении памятью.
• Уточняется функциональность Zig: он не компилируется в C, но имеет инструмент для трансляции C-кода в Zig, при этом компилируясь напрямую в машинный код.
• В обсуждении присутствует юмористический тон относительно утверждения, что разработчики не являются идиотами.

Миниатюрная библиотека sj.h для парсинга JSON весит всего 500 строк кода и использует единственный заголовочный файл. Она спроектирована для минимализма и эффективности, поддерживая базовые операции: разбор строк, чисел, булевых значений, массивов и объектов.

Библиотека не требует динамического выделения памяти, что делает её идеальной для встраиваемых систем и сред с ограниченными ресурсами. Её API интуитивен — всего несколько функций для доступа к данным, что снижает порог входа. Практический плюс: легко интегрируется в существующие C-проекты без зависимостей.

• Обсуждаются достоинства библиотеки автора: однофайловые решения на ANSI C/Lua с фокусом на простоту, удобный интерфейс и хорошую документацию.
• Отмечаются потенциальные проблемы безопасности и корректности: отсутствие проверок на переполнение целых чисел, возможное неопределённое поведение, слабая валидация JSON.
• Поднимается вопрос о целесообразности использования: обсуждаются нишевые применения (например, embedded), недостатки для продакшена и альтернативные библиотеки.
• Упоминается необходимость тестирования на соответствие стандарту (конформность) и handling edge cases.
• Обсуждается философия подобных минималистичных библиотек: свобода от избыточной сложности ценой отказа от безопасности и обработки всех крайних случаев.

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

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

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

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

Я провёл расчёты и получил примерно 2,5 года работы до переполнения. Чтобы проверить это на практике, я запустил DOOM на КПК с питанием от самодельного ИБП на 18650, подключённого к роутеру. Система работала всё это время, и я почти забыл о ней.

Сегодня игра наконец crashed — всего через несколько часов после отметки в 2,5 года. Переменная переполнилась, что подтвердило теорию.

• В игре Crash Bandicoot 3 используется 32-битный счётчик времени, который переполняется через ~2.26 года, вызывая сбои.
• Аналогичная проблема переполнения счётчика обсуждается в контексте DOOM, Windows NT и других систем.
• Переполнение знакового целого в C является неопределённым поведением, что может приводить к краху программы.
• Упоминаются другие примеры из игр (Final Fantasy 9) и систем, где переполнение таймеров вызывает проблемы.
• Обсуждаются технические детали, такие как использование signed vs unsigned integer для счётчиков.
• Пользователи шутят о грядущих проблемах в 2038 году из-за переполнения времени Unix.
• Высказывается уважение к стабильности и инженерному качеству кода старых игр, несмотря на подобные баги.

Как я вживил LLM в Animal Crossing без единой правки кода

Проблема
GameCube-версия Animal Crossing 2001 года повторяет те же фразы 23 года. Консоль оффлайн, 24 МБ ОЗУ, нет TCP/IP.

Решение

1. Декомпиляция: сообщество выложило исходники на C, нашёл mMsg_ChangeMsgData.
2. «Почтовый ящик» в ОЗУ: выделил кусок RAM (0x81298360) для обмена строками.
3. Сканер памяти: замораживал эмулятор, искал адреса активного текста и имени собеседника.
4. Мост: Python-скрипт читает имя персонажа, шлёт запрос к LLM, пишет ответ прямо в буфер диалога.
5. Никаких патчей картриджа: всё через Dolphin + чтение/запись процесса.

Итог
В villagers теперь живой чат, а консоль по-прежнему думает, что 2001 год.

• Мод перехватывает диалог Animal Crossing на GameCube через shared-memory «почтовый ящик» и подменяет строки ответами LLM.
• Игра приостанавливается на секунды, пока внешний Python-скрипт запрашивает ответ у модели и кладёт его обратно в память.
• Первые сгенерированные реплики villagers’ов — «свергнуть Тома Нука», что вызвало веселье и обсуждение капиталистической сатиры.
• Участники видят в моде будущее игр: бесконечные, контекстуальные реплики вместо заезженных фраз, но сомневаются в производительности и сюжетной последовательности.
• Проект напомнил о старых попытках встроить ИИ в NPC (Quake 3, Skyrim, Modbox) и вызвал желание повторить для Switch-версий, хотя DRM усложняет декомпиляцию.

running-qix-malware
Репозиторий демонстрирует работу вируса QIX (1989) в эмуляторе DOS.

• Собранный DOS-бинарь запускается в браузере через эмулятор.
• Исходники на ассемблере и C, скрипты сборки.
• Инфицирует .COM-файлы, показывает бегущую линию.
• Безопасен: эмуляция изолирует вредоносный код.

• Участники вспомнили про инцидент Jia Tan и пожаловались, что npm до сих пор не автоматически блокирует публикации с обфусцированным кодом и шестнадцатеричными именами.
• Предложены меры: предпубликационный сканер с «задержкой на проверку», 2FA-апрув каждого релиза, опциональный «verified»-бейдж и поддержка Yubikey.
• Сомнения в пользе LavaMoat: не спасает от DLL в lifecycle-скриптах, не работает с Webpack HMR, а изоляция может быть дорогой.
• Обсуждали lock-файлы: хэши в package-lock защищают от перезаписи версии, но теги git всё ещё можно подменить; иммутабельность npm-тарболлов считается основной защитой.
• Namespaces (@scope) в npm есть с 2016 г., но «красивые» безскоповые имена всё ещё популярны, поэтому переход идёт медленно.

• Увлечение — восстановление данных с кассет 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 не сломала систему.

Fil-C — это C/C++-совместимый язык с безопасной памятью и современным инструментарием. Его сердце — FUGC, параллельный, конкурентный, точный, неперемещающий сборщик мусора.

Ключевые черты FUGC

• Параллельность: маркировка и очистка выполняются на всех ядрах.
• Конкурентность: потоки-мутаторы не останавливаются; блокировки только на медленных путях аллокации.
• On-the-fly: нет глобальной паузы; «мягкие рукопожатия» просят потоки асинхронно сканировать стек.
• Grey-stack: повторное сканирование стеков до фикс-поинта; барьер только при записи, быстрая сходимость.
• Dijkstra-barrier: при записи указателя объект помечается CAS-relaxed.
• Точность: LLVM-плагин FilPizlonator точно знает, где все указатели.
• Неперемещаемость: объекты не двигаются; освобождённые блоки «перенаправляются» через InvisiCap.

Safepoint-механизм

• Компилятор вставляет pollcheck: быстрая проверка или колбэк для GC.
• «Мягкое рукопожатие» запускает колбэк на всех потоках.
• Состояния enter/exit позволяют блокироваться в syscall без pollcheck’ов; GC сам выполняет колбэк для «exited» потоков.
• Safepoint защищает от гонок: загруженный указатель будет жив до следующего safepoint’а.

По желанию можно включить полный stop-the-world (FUGC_STW=1) для fork(2) или отладки.

• Fil-C — это С-компилятор с точным параллельным GC (FUGC) и capability-указателями, позволяющий запускать «как есть» CPython, SQLite, OpenSSH и др., теряя в худшем случае 4× производительности.
• Вместо ручного free и UB-оптимизаций LLVM код живёт под барьером Дейкстры и soft-handshake safepoint’ами; указатели превращаются в «InvisiCap» (base+offset), теряющие силу при приведении к integer.
• Проект исследовательский, но уже промышленно полезен: нет сборок под 32-бит, Windows и embedded без MMU, нет пока поколенческого GC и ARM/RISC-V.
• Споры: «lock-and-key» предсказуемее RAM, но требует атомиков; GC = «мусор потом» vs compile-time проверки; можно ли дождаться AI-стат-анализа вместо Rust-переписей.

Magic Lantern 2025: Midsummer Edition
21 июня 2025

Возвращение официальных сборок

• Регулярные релизы для всех камер
• Проверенные билды на сайте, а не в форуме
• Баги исправляются
• Поддержка новых моделей расширяется

Что изменилось
После ухода a1ex в 2020 остались фрагментарные доки и нерабочая система сборки. Несколько волонтёров восстановили проект:

• обновили сайт и репозиторий;
• перешли на Git, современные ОС и инструменты;
• код стал чище, быстрее, компактнее;
• добавлена поддержка Digic 6/7.

Новая команда
g3gg0, kitor, names_are_hard, WalterSchulz.
Lead-dev: names_are_hard.

Новые камеры

• 200D / Kiss X9 / Rebel SL2
• 6D Mark II
• 750D / Rebel T6i / Kiss X8i
• 7D Mark II

Хотите помочь? Нужны разработчики C.

• Magic Lantern возвращается: это бесплатная надстройка, расширяющая возможности старых и новых Canon-ов за счёт реверса прошивки.
• Проект перешёл на Git, современный тулинг и чистую сборку без варнингов, что упрощает вход новым разработчикам.
• Нужен C и желание покопаться в «железе»; камеры стоимостью <$100 подходят, сообщество приглашает помогать.
• Пользователи вспоминают RAW-видео, таймлапсы, HDR-скрипты и другие «фичи», которых нет в штатной прошивке.
• Нет поддержки новых Sony/Nikon/Fujifilm, но многие мечтают о таких же проектах для других марок.

Я написал What the Fork — кроссплатформенный визуализатор сборки C/C++ (и не только).
Запуск: wtf make, wtf cargo build, wtf gradle build, wtf -x для Xcode и т.д.

Инструмент показывает все процессы, включая скрытые вызовы ld, и ищет типичные проблемы:

• отсутствие -j у make,
• однопоточная компиляция,
• повторяющиеся cmake/make-шаги,
• непараллельные CI-сборки.

Как работает
Сборка = дерево команд. Чтобы увидеть всё, ловим системные вызовы fork/exec/exit:

• macOS — Endpoint Security API,
• Linux — ptrace,
• Windows — Event Tracing (самое мерзкое API).

Что уже нашли

• cargo собирал зависимость одним потоком вместо 10× ускорения.
• ninja при сборке LLVM держит 12 задач на 10 ядрах — почти идеал.
• CMake 85 раз подряд вызывает xcode-select, sw_vers, cmake/make → clang, не используя параллелизм.

Инструмент открыт для тестов — попробуйте на своём проекте.

• Пользователи восторженно реагируют на новый визуализатор сборки, особенно те, кто застрял на CMake/GCC/Make без clang/ninja и не может понять, почему сборка тормозит.
• Просят сразу показать GIF-демонстрацию под заголовком статьи и спрашивают, будет ли macOS-версия и открытый код.
• Некоторые делятся опытом: strace/dtruss, ninjatracing, vcperf, cargo --timings, Instruments и другие инструменты уже решали похожие задачи.
• Предложения расширить функциональность: добавить flame-графы процессов, поддержку fork(), интеграцию с Bazel Build Event Protocol, оценку «осталось времени» по историческим данным.
• Отдельные комментарии касаются маркетинга (сменить название), сравнения с VS/Xcode, а также шуток про TEEP/OEE завода и «LLVM, завари кофе».

Репозиторий FFmpeg

• 120 755 коммитов, 38 веток, 408 тегов, размер 271 МиБ
• Языки: C 90 %, Assembly 8 %, Makefile 1 %, остальное <1 %

Ветка master

• Последний коммит: a2cfaf1 — avformat/mov: передавать индекс потока в sanity_checks для HEIF
• CI: все проверки успешны (linux-amd64, linux-aarch64, Windows, lint)

Ссылки

• ZIP | TAR.GZ | BUNDLE

Последние изменения

• libavformat: передача индекса потока в sanity_checks для HEIF (James Almer)
• libavcodec: очистка pu_info в rv60dec
• fftools/ffmpeg_mux_init: 64-битные вычисления score
• libswscale: выравнивание на 8 строк для planarCopyWrapper
• doc/examples: замена sleep на av_usleep
• presets: удалены устаревшие пресеты iPod

• FFmpeg ушёл с GitHub на самостоятельный Forgejo, отказавшись от рассылок и ускорив навигацию по файлам.
• Пользователи жалуются на защиту Anubis с «аниме-девочкой»: ошибки «Invalid Response», пропадающий CSS, проблемы на Android.
• Критика мотива «не Microsoft» и вопросы: почему именно Forgejo, а не GitLab/Gitea.
• Сторонники отмечают суверенитет и удобство, противники — нестабильность и «нелепый» брендинг.

Modos Paper Monitor — открытый e-paper монитор 75 Гц и dev-kit.
Собрано $61 611 из $110 000, 37 дней до конца кампании.

В комплекте

• Плата на FPGA (Caster, 60 Гц, открытая прошивка).
• 6" и 13" монохромные панели; контроллер подходит и к другим экранам 6–13,3".
• HDMI/USB, Linux/macOS/Windows.
• Корпус-чертежи и ПО на GitHub.

Почему это важно

• Закрытые драйверы и высокие цены тормозят e-paper.
• Мы даём инженерам и энтузиастам свободу экспериментировать и формировать стандарты (Discord, Mastodon, Matrix, Bluesky).

Возможности

• Низкая задержка: независимые области обновления, отмена прежних пикселей.
• Гибкие режимы: бинарный для скорости + гибридный серый для деталей.
• C API: полный контроль режимов и обновлений.

Цены

$199–$599, 6 вариантов комплектации.

GitHub-список совместимых экранов

• Проект Glider — полностью открытый: исходники, Verilog, документация и файлы платы на GitHub/GitLab.
• NLnet и ЕС профинансировали разработку; обсуждаются условия грантов и гражданство авторов.
• Контроллер на низкобюджетном FPGA выдаёт HDMI/USB-C, но пока не предлагает LVDS/eDP для моддинга ноутбуков.
• Демо показывает высокую скорость обновления при заметном «ghosting»; блики — особенность дешёвой панели, не самой платы.
• Участники хотят 21–24″ монохромный 30 Гц дисплей дешевле $500, сенсорный слой и драйверы X11/Wayland.
• Упомянуты альтернативы: Inkplate, TRMNL, Boox, а также DIY-кибердеки и ноутбуки ThinkPad T480 с e-ink.

Добро пожаловать на LWN.net

Этот материал для подписчиков стал доступен благодаря читателю LWN. Тысячи подписчиков зависят от LWN как от источника новостей о Linux и свободном ПО. Если статья вам понравилась, пожалуйста, рассмотрите возможность оформления подписки. Спасибо за визит!

Антонио Куни, давний инженер по производительности Python и разработчик PyPy, на EuroPython 2025 в Праге представил доклад «Мифы и сказки про производительность Python». По его мнению, привычная «мудрость» о скорости Python часто вводит в заблуждение. На примерах он показал реальные узкие места и пришел к выводу: в конечном счете предел оптимизаций упирается в управление памятью. Он начал ранний проект SPy, который, возможно, приведет к сверхбыстрому Python.

Он попросил зал поднять руки, кто считает «Python медленным или недостаточно быстрым» — рук было много (в отличие от PyCon Italy). Годы работы с производительностью и общение с разработчиками породили набор мифов, которые он хочет развеять.

Мифы

Миф: «Python не медленный». Да, часто «достаточно быстрый», особенно как «склеечный» язык в эпоху «важен только GPU». Но это верно лишь для части задач. Есть множество программ, где скорость Python критична — отсюда постоянные усилия по оптимизации интерпретатора и перенос горячих участков в Cython, Numba и т.п.

В слайдах он показал множества: «программы, где Python достаточно быстр» — подмножество «всех Python-программ», а снаружи — «все возможные программы». В идеале Python должен подходить для всех; пока что задачи, требующие максимума от процессора, не могут быть на Python. Он хочет расширять «внутренние круги».

Королларий «это всего лишь клей»: «просто перепишите горячее в C/C++» (сегодня — в Rust). Прием рабочий, но быстро упирается в стену: принцип Парето подсказывает оптимизировать 20% кода, где 80% времени, но затем срабатывает закон Амдаля — ускорив горячую часть, вы упираетесь в остальной код, который начинает доминировать во времени выполнения.

Еще миф: «Python медленный, потому что интерпретируемый». Интерпретация — лишь малая часть. Даже выражение p.x * 2 в C/C++/Rust — это загрузка, умножение, сохранение. В Python же нужно определить тип p, вызвать getattribute(), распаковать p.x и 2, выполнить операцию с учетом перегрузок и протоколов, упаковать результат, выделить память и т.д. Это диктуют семантика и динамичность языка, не способ исполнения.

Статические типы

С распространением тайпингов слышно: «теперь компиляторы могут пропускать лишнее и считать напрямую». Пример:

def add(x: int, y: int) -> int:
    return x + y

print(add(2, 3))

Но аннотации не применяются во время выполнения, и можно вызвать:

print(add('hello ', 'world'))  # type: ignore

Чекер доволен, но семантика сложения уже другая. Аннотации бесполезны для оптимизации и скорости, если их не гарантирует рантайм. Более того, в Python легально перегружать операции, меняя поведение в рантайме, что разрушает предпосылки для агрессивных оптимизаций.

• Обсуждение сосредоточено на мифах о скорости Python: динамичность языка, непредсказуемость типов и плохая кэш-локальность мешают компиляторам и JIT достигать производительности системных языков без компромиссов по совместимости и простоте.
• Многие отмечают, что JIT и спекулятивное выполнение помогают на «хэппи-пате», но становятся хрупкими: небольшие изменения кода могут срывать оптимизации и резко просаживать скорость.
• Популярные пути ускорения — PyPy, Numba, Pythran, mypyc, а также перенос «горячих» участков в C/C++/Rust или использование DSL/субсетов (SPy); однако граница вызовов и динамика Python часто «съедают» выгоды.
• Отмечают альтернативы и эволюцию: Mojo как супермножество Python с статикой и компиляцией, возможное сосуществование компиляторов рядом с CPython вместо «Python 4».
• Критики указывают, что популярность Python не доказывает его производительность; многие реальные «тормоза» — это не CPU, а I/O и сеть, где помогают async и масштабирование.
• Скептики считают, что «быстрым» Python не станет без отказа от ключевых динамических свойств (примерно как в JS — оптимизации на общий случай, но с ограничениями); часть участников предлагает оставлять Python для скриптинга и клеевого кода.
• Вопросы многопоточности, старта интерпретатора и GIL остаются проблемными; параллельно обсуждают идеи «final»-квалификаторов, иммутабельности и GPU/параллельных подходов, но признают их практические ограничения.