Hacker News Digest

Представлена реализация eForth на C/C++ с кроссплатформенной поддержкой. Проект работает на Linux, MacOS, Windows, ESP32 и даже в WebAssembly (WASM), что делает его универсальным решением для различных систем.

Код проекта размещен на GitHub в репозитории chochain/eforth. Реализация eForth на C/C++ позволяет использовать этот язык программирования в широком спектре устройств - от настольных компьютеров до встраиваемых систем вроде ESP32, а также в веб-среде через WASM.

• Forth ценен для образования как альтернативный подход к вычислениям наряду с Lisp, демонстрирующий разные способы выражения программной логики.
• Классические реализации Forth на ассемблере противоречат идее 100% C/C++ с кросс-платформенностью, но язык остается простым для реализации с нуля, особенно на стековых процессорах.
• Производительность Forth часто страдает из-за цепочек вызовов подпрограмм, но возможна оптимизация через инлайнинг, использование регистров и native-код для критичных участков.
• Forth сохраняет нишевое применение в embedded-системах благодаря компактности и гибкости от низкоуровневого до высокоуровневого программирования.
• Сообщества вокруг таких языков могут предлагу уникальные решения, но иногда склонны к догматизму и пренебрежению другими подходами.

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-х.

В статье разбираются рекурсивные макросы в C, которые автор называет самой неприятной частью языка, несмотря на его 60-летнюю историю успеха. Макросы критически важны для многих систем, так как позволяют абстрагировать сложность, добавлять проверки и обеспечивать безопасность, но их система имеет серьёзные ограничения. Основная проблема: макросы в C не поддерживают рекурсию, что, по мнению автора, могло быть как случайностью эволюции системы, так и сознательным решением для предотвращения бесконечных циклов компиляции.

Автор мотивирует необходимость рекурсивных макросов возможностью обрабатывать переменное количество аргументов, что особенно ценно для создания безопасных вариадических функций. Цель статьи — создать макрос, считающий количество аргументов, что позволит автоматически добавлять проверки и избегать ошибок, связанных с ручным подсчётом. Хотя система макросов кажется устаревшей, она остаётся единственным механизмом компиляции времени в C, делая изучение этих техник важным для разработчиков.

• Обсуждение охватывает историю и ограничения препроцессора C, включая его влияние на языки C и C++, а также затрагивает вопросы безопасности (DoS-риски) и читаемости кода.
• Участники обсуждают, что препроцессор не предназначен для сложной метапрограммирования, и что современные языки предлагают более безопасные и выразительные альтернативы.
• Также обсуждается, что хотя препроцессор и может быть использован для продвинутых задач метапрограммирования, он требует нестандартных и сложных приемов, что делает его использование непрактичным и потенциально опасным.
• Некоторые участники упоминают, что препроцессор может быть использован для создания сложных макросов, которые могут быть использованы для создания DSL или для экспериментов с синтаксисом языка, хотя это может быть опасным.
• В целом, обсуждение подчеркивает, что хотя препроцессор может быть использован для сложных задач, он не предназначен для этого и что современные языки предлагают более безопасные и выразительные средства для решения таких задач.

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

Разработчики позиционируют grayskull как альтернативу более тяжёлым решениям, подчёркивая её лёгкость и универсальность. Ключевое преимущество — отсутствие внешних зависимостей, что упрощает компиляцию и развертывание на различных платформах. Библиотека идеально подходит для проектов, где важна производительность и минимальный размер исполняемого кода.

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

За десять лет автор прошёл путь от веб-разработчика до специалиста по базам данных, присоединившись к EnterpriseDB, где работает над pglogical и Postgres Distributed. Его карьера началась в 2014 году с JavaScript и Python, затем он стал менеджером инженеров. Прорывным моментом стало 2020 год, когда проблемы с производительностью его сервиса заставили его изучить индексы и структуры данных. Он создал образовательные проекты, включая простую in-memory SQL базу данных, и построил сообщества вроде Software Internals Discord и /r/databasedevelopment.

После неудачной попытки запустить собственный стартап в 2021-2023 годах и работы в TigerBeetle автор искал позицию именно разработчика баз данных, а не DevOps-инженера для работы с базами. Несмотря на нетрадиционный путь (он бросил колледж) и сомнения работодателей, он получил три предложения на работу над расширениями Postgres на C и Rust. Выбрав EnterpriseDB, компанию с 20-летней историей и одним из крупнейших вкладчиков в развитие Postgres, он предпочёл стабильность ранним стартапам, в которых работал последние три года.

• Сообщество обсуждает, как трудно сменить специализацию, если ты уже «записан» в базе данных как специалист в области X, и как это влияет на найм и карьерные возможности.
• Участники делятся личным опытом: кто-то ушел в разработку на C/C++ и Rust, кто-то перешел в SRE или DevOps, кто-то пытается попасть в компиляторы.
• Обсуждается, что рекрутеры и системы найма не видят за пределами ключевых слов в резюме и не учитывают site-reliability, DevOps и прочие смежные навыки, что делает смену специализации еще более сложной.
• Участники делятся советами, как обойти эту систему: делать сайд-проекты, которые демонстрируют навыки в новой области, участвовать в open-source, писать блоги и статьи, и так далее.
• Также обсуждается, что важно не только выждать подходящий момент, но и быть готовым пойти на уменьшение зарплаты и не бояться начать с более низкой позиции, что может быть ключом к переходу в новую область.

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

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

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

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

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

• Python-оптимизация часто сводится к выносу «горячих» участков в C/NumPy, а не к микро-оптимизации кода.
• Сам факт, что в CPython «всё является объектом» влечёт за собой неизбежные накладные расходы, которые нельзя убрать без отказа от части философии языка.
• JIT (PyPy) и отсутствие GIL в будущем могут решить 90 % проблем производительности, но это не касается CPython.
• Сообщество в целом согласно с тем, что вместо попыток «оптимизировать» Python-стильный код, стоит либо полностью переписать узкие места на C/Rust, либо вовсе перейти на Julia/Go.

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

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

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

Статья представляет собой руководство по созданию минимальной библиотеки компьютерного зрения Grayskull, использующей только 8-битные изображения в градациях серого, обычный C и простые структуры данных. Автор демонстрирует базовые операции с пикселями: инвертирование, зеркалирование, копирование, обрезку и изменение размера. Особое внимание уделено двум методам масштабирования - ближайшего соседа (быстрый, но с блоками) и билинейной интерполяции (медленнее, но качественнее).

Библиотека реализует свёрточные фильтры для обработки изображений, где новое значение пикселя вычисляется как взвешенная сумма соседних пикселей с использованием ядра фильтра. Приведены примеры распространённых ядер: размытие по ящику (box blur), гауссово размытие, повышение резкости и тиснение (emboss). Статья подчёркивает, что изображение по сути является прямоугольником чисел, и даже с минимальными инструментами можно реализовать мощные алгоритмы компьютерного зрения.

• Обсуждение охватило от основ компьютерного зрения до практических примеров и ссылок на ресурсы, включая MIT-2024 книгу и репозиторий GitHub.
• Участники обменялись опытом в индустрии машинного зрения, обсуждая такие темы как цвет против grayscale, промышленные применения и библиотеки вроде Halcon и MVTec.
• Были упомянуты такие инструменты как customFilter и примеры кода, а также ссылки на полезные ресурсы.
• В комментариях также поднимались вопросы о балансе между стоимостью, скоростью и качеством изображения в промышленных системах.
• В целом, обсуждение было наполнено практическими советами и ссылками на открытые исходники и учебные материалы.

Fil-C - реализация C и C++ с безопасной памятью, позволяющая существующему коду работать безопасно без изменений. Несмотря на молодость проекта и одного активного разработчика, Fil-C уже компилирует весь безопасный пользовательский Linux. Это форк Clang с лицензией Apache v2.0, который изначально был медленным, но после оптимизации работает всего в несколько раз медленнее оригинала. Тест с Bash показал практически незаметную разницу в производительности.

Основная сложность проекта - обработка указателей. Текущая реализация "InvisiCaps" разделяет указатели на доверенную "capability" и недоверенную "address" части, позволяя им соответствовать естественному размеру архитектуры. Для поддержки безопасности Fil-C использует другую внутреннюю ABI, чем Clang, что требует полной перекомпиляции проекта. При выделении объекта в куче Fil-C добавляет два слова метаданных для проверки границ доступа и хранения дополнительной информации о указателях.

• Fil-C — это компилятор C → C, добавляющий проверки безопасности памяти, но при этом оставляющий программы полностью совместимыми с существующим кодом и не требующий изменений в исходном коде.
• Проект разрабатывается в рамках Nix, что позволяет легко собирать любые пакеты с Fil-C, а также предоставляет кэш сборок.
• Обсуждение выявило, что Fil-C в первую очередь ориентирован на безопасность, а не на производительность, и что он не решает проблему безопасности в полном объеме, но является важным шагом вперед.
• Некоторые участники обсуждения выразили обеспокоенность по поводу того, что Fil-C может быть непрактичен из-за производительности, но другие отметили, что для некоторых приложений безопасность важнее производительности.

Проект представляет собой набор реализаций бенчмарка "Are-we-fast-yet" на различных языках программирования, включая Oberon, C++, C, Pascal, Micron и Luon. Основная цель - сравнение производительности разных языков через единый тестовый набор. Реализации позволяют разработчикам оценить эффективность каждого языка в стандартных задачах и понять, как современные языки конкурируют с классическими.

Бенчмарк охватывает ключевые алгоритмические задачи, такие как сортировка, обработка строк и математические вычисления. Интересно, что даже в 2023 году некоторые классические языки, как C и Pascal, демонстрируют конкурентоспособную производительность, в то время как более современные языки предлагают разные компромиссы между скоростью и выразительностью кода. Проект предоставляет ценный ресурс для выбора языка программирования под конкретные требования производительности.

• Обсуждение в основном касается языков Oberon и их компиляторов, включая их производительность и репозиторий.
• Участники обсуждают, что репозиторий недавно добавил реализацию на C++, но она оказалась значительно медленнее.
• Также поднимается вопрос о названии Micron — участники считают его плохим выбором, так как может вводить в заблуждение.
• Появляется ссылка на недавно опубликованные результаты тестов производительности.
• Участник под ником «dead» отмечен как неактивный.

Проект MyraOS представляет собой операционную систему Unix-подобного типа для архитектуры x86, созданную с нуля без использования стороннего кода. Автор проекта Dvir Biton разработал ядро системы, файловую систему, драйверы и пользовательские утилиты самостоятельно, что делает его впечатляющим достижением в области разработки ОС.

Система поддерживает базовые функции Unix, включая многозадачность, управление памятью и взаимодействие с пользователем через командную строку. Проект открыт на GitHub и может быть использован для образовательных целей или как основа для дальнейших разработок. Код написан на ассемблере и C, что обеспечивает эффективную работу на аппаратном уровне.

• Проект получил много похвал за качество кода и полезность, но также вызвал критику за использование устаревших ресурсов и отсутствие современных инструментов.
• Участники обсуждали, что в 2025 году нужно обновить учебные материалы для новичков в разработке ОС, чтобы они не ориентировались на 32-битный x86 и устаревшие устройства.
• Предложения включали: предоставление ISO-образов для тестирования, создание обучающего видео, и сотрудничество с такими проектами как copy.sh.
• Также обсуждались проблемы, такие как управление памятью и отладка, и как они масштабируются в контексте разработки ОС.
• В конце обсуждение сошлось на то, что проект является вдохновляющим примером, но может быть улучшен с использованием современных практик и инструментов.

Автоматические инструменты перевода кода с C на Rust полезны, но создают небезопасный и неидиоматичный код. Авторы Jaemin Hong и Sukyoung Ryu исследуют эти проблемы и предлагают решения с использованием статического анализа. Основные трудности включают различия в управлении памятью, типах данных и моделировании ресурсов между двумя языками.

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

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

Wren — это маленький, быстрый, объектно-ориентированный скриптовый язык с поддержкой concurrency. Его реализация занимает менее 4000 строк кода, что позволяет изучить весь код за один день. Язык сочетает в себе идеи Smalltalk, Lua и Erlang, предлагая современный и понятный синтаксис. Wren использует быстрые однопроходный компилятор в байт-код и компактное представление объектов, что позволяет ему конкурировать с другими динамическими языками.

Особенностью Wren является акцент на классах как основной парадигме и встроенная поддержка легковесных волокон (fibers) для организации программы в набор взаимодействующих корутин. Язык создан для встраивания в приложения — он не имеет зависимостей, имеет небольшую стандартную библиотеку и простой C API. Wren компилируется как C99, C++98 или более новые версии, доступен для запуска в браузере и открыт на GitHub под руководством Боба Нистрома.

• Wren — язык, который сочетает в себе лаконичность Lua и объектно-ориентированный синтаксис, но при этом остаётся компактным и легко встраиваемым.
• Пользователи отмечают, что Wren легко встраивается в C/C++ проекты, но при этом не требует сложных зависимостей, что делает его привлекательным для встраиваемых скриптовых языков.
• Некоторые участники обсуждения упоминают, что Wren может быть использован как альтернатива Lua, особенно в контексте встраивания в игровые движки и другие приложения.
• Обсуждается также, что Wren имеет активное и дружелюбное сообщество, что способствует его развитию и поддержке.

В файле rlsw.h представлен упрощённый API SimpleWindow для raylib, созданный для быстрой разработки оконных приложений с минимальным кодом. Основная структура SimpleWindow инкапсулирует параметры окна (ширина, высота, заголовок), а SimpleWindowEvent обрабатывает базовые события (закрытие, перемещение, изменение размера). API содержит всего 12 функций, включая swCreateWindow для инициализации, swBeginDrawing/swEndDrawing для рендеринга, и swPollEvents для обработки ввода.

Ключевое преимущество — лаконичность: весь функционал сводится к нескольким вызовам, что идеально подходит для прототипов и небольших проектов. Поддерживаются все основные платформы (Windows, Linux, macOS), а зависимость сводится к одному заголовочному файлу без необходимости линковки. Разработчики отмечают, что это решение особенно полезно для образовательных целей или когда требуется минимальная сложность без избыточных возможностей полного raylib.

• Raylib теперь компилируется без внешних зависимостей, что делает его идеальным для встраиваемых систем и ретро-харда.
• Сообщество вспомнило, что ПО-рендеринг всегда был возможен, и теперь можно делать 2D/3D игры даже на 20-летнем железе.
• Появился спор о том, насколько полезен этот факт для разработки игр на микроконтроллерах и эмуляторах старого железа.
• Некоторые участники обсуждения отметили, что это также открывает путь к созданию игр для таких систем, как Nintendo 3DS и других портативных устройств.
• Были упомянуты проекты TinyGL и PortableGL как альтернативы, а также отмечено, что OpenGL 1.1-совместимое ПО-рендеринг всегда было возможно, но теперь это стало еще более доступным.

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

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

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

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

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

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

• Появление аппаратной поддержки тегирования памяти в x86-64 — это ответ на уже существующие технологии ARM64 (MTE) и Apple (MIE), а не новая идея.
• Технически это не более чем перенос существующих подходов на x86-64, но важно, что это может быть сделано опционально и не сломает существующий код.
• Поддержка тегирования памяти в x86-64 может быть реализована в виде набора инструкций, которые будут использоваться компилятором и стандартной библиотекой, чтобы обеспечить безопасность кода, написанного на C/C++.
• Это не решит проблему безопасности памяти в целом, но может помочь в обнаружении ошибок и предотвращении эксплойтов.

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

В 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 могут не осознавать эти ловушки.
• Обсуждается влияние ИИ на качество кода и безопасность, а также то, что влияние ИИ на обучение языкам может маскировать проблемы, которые иначе были бы очевидны.
• Участники также обсуждают, что влияние ИИ на обучение языкам и на то, что это может привести к проблемам, если человек не понимает, что делает ИИ, и что это может быть опасно.
• В обсуждении также поднимается вопрос о том, что ИИ может быть использован для аудита кода и нахождения проблем, и о том, что это может быть использовано для улучшения качества кода.

pgEdge выпустил open-source-утилиту spock — логическую репликацию PostgreSQL с поддержкой multi-master. Проект позиционируется как замена Bucardo и Slony, но с фокусом на высокую доступность и отказоустойчивость. Под капотом — использование логической репликации, что позволяет конфликтам разрешаться на уровне транзакции, а не на уровне отдельных запросов. Это делает spock пригодным для кластеров, где каждая нода может принимать запись.

Проект написан на C и Python, распространяется под лицензией PostgreSQL. Поддерживает PostgreSQL 12-16 и требует расширение pglogical.

• Разработчики подчеркнули, что multi-master репликация не обеспечивает такую же строгую согласованность, как PostgreSQL, и что это важно учитывать при выборе решения.
• Участники обсуждали, что при использовании multi-master репликации важно понимать, какие именно edge cases могут возникнуть и как они решаются.
• Были упомянуты такие решения, как CockroachDB и pgEdge, и обсуждались их плюсы и минусы по сравнению с другими решениями.
• Также обсуждались вопросы лицензии и лицензионной политики, а также то, какие именно ограничения могут быть связаны с использованием таких решений.
• В конце обсуждения было отмечено, что важно понимать, что multi-master репликация не решает всех проблем масштабирования и что важно тщательно оценивать, подходит ли она для конкретного use case.

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

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

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

Для высокой производительности B+Tree узлы должны размещаться в памяти как единый непрерывный блок, что улучшает локальность данных и повышает вероятность попадания в кэш процессора. В C++ это требует отказа от std::vector из-за дополнительной косвенности через отдельное выделение памяти, и вместо этого используется гибкий массив (flexible array member) — техника, унаследованная из C. Массив переменной длины объявляется как последний член структуры без указания размера, что позволяет динамически выделять память под весь узел и его записи единым блоком.

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

This pattern was officially standardized in C99,No it wasn't; the C99 flexible array uses [] not [1] or [0].When using the [1] hack, you cannot use the sizeof the structure to get the offset, because it includes the [1] array.When using C99, you also cannot use sizeof to get th

• Дискуссия разворачивается вокруг старых обвинений в адрес языка C и архитектуры x86, но участники быстро указывают, что стековые инструкции и концепция вызова функций существовали задолго до C и даже были запатентованы в 1957 году.
• Спор уходит в сторону от предмета: автор статьи не предлагает никакой альтернативы, кроме как упоминания о "сообщениях" без каких-либо деталей.
• Участники также отмечают, что статья игнорирует такие факторы как тепловой бюджет, параллелизм и стоимость транзисторов.
• В итоге обсуждение сводится к тому, что критика не предлагает никакой конструктивной альтернативы и что современные CPU не оптимизированы под конкретные задачи, но и под общий набор инструкций, что делает их универсальными.

Виртуальная машина для языка Scheme реализована на C с использованием кучи для хранения пар. Основана на модели из работы Дабвига «Three Implementation Models for Scheme», что делает её компактным учебным примером интерпретатора Lisp-подобных языков.

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

• Обсуждение производительности и особенностей различных реализаций Scheme, включая Chez Scheme, MIT Scheme и другие.
• Упоминание роли Кента Дибвига как создателя Chez Scheme и его влияния как преподавателя и исследователя.
• Вопросы о технических деталях и возможных ошибках в представленном коде, включая проблемы с указателями и порядком вычислений.
• Идеи о бутстраппинге компиляторов и интерпретаторов, включая использование LLM для генерации ассемблерного кода.
• Общие положительные отзывы о минималистичных и элегантных реализациях Scheme, таких как обсуждаемый код.

Выбор между Ada, SPARK и Rust вместо C/C++ зависит от целей проекта. C/C++ остаются стандартом для встраиваемых систем из-за привычной экосистемы и обученных кадров, но они несут риски для безопасности — десятилетия разработок не сделали их по-настоящему безопасными без значительных затрат.

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

• Участники обсуждают сравнительные преимущества систем типизации в Ada и Rust, включая возможность создания отдельных типов для единиц измерения (например, мили и километры) для предотвращения ошибок.
• Высказываются мнения о применимости языков (C++, Ada, Rust, SPARK, Zig, D) в высоконадёжных и критических системах, таких как аэрокосмическая отрасль, с акцентом на строгие процессы разработки и верификации, а не только на выбор языка.
• Поднимается тема, что безопасность кода зависит в большей степени от методологии разработки и тестирования (интеграционного, системного), чем от самого языка программирования.
• Обсуждается эргономика и удобство использования возможностей языков (например, newtype в Rust, контролируемые типы в Ada) для обеспечения типобезопасности и предотвращения ошибок на этапе компиляции.
• Некоторые участники выражают скептицизм по поводу необходимости замены C/C++, предлагая вместо этого лучше изучать и использовать существующие языки, совершенствуя навыки и процессы разработки.

Toybox — это минималистичная реализация стандартных утилит командной строки для Linux и Android, написанная на чистом C. Она создана как компактная и самодостаточная альтернатива BusyBox, с акцентом на простоту, корректность и соответствие стандартам POSIX. Проект включает основные инструменты вроде ls, cp, mv и многие другие, сохраняя при этом малый размер и избегая внешних зависимостей.

Разработка ведётся с упором на читаемость кода и портируемость, что делает Toybox полезной для встраиваемых систем, восстановительных сред и случаев, где важны предсказуемость и минимализм. Она часто используется в проектах типа Android Toybox, демонстрируя свою практическую ценность для современных ОС.

• Toybox — это альтернатива BusyBox с более разрешительной лицензией (0BSD/MIT-0), созданная для решения лицензионных проблем и использования в Android.
• Оба проекта предоставляют набор стандартных UNIX-утилит (ls, cp, mv и др.) в виде одного исполняемого файла, что экономит место на диске.
• Изначальная идея Toybox вызывала споры из-за отказа от copyleft, но была принята как компромисс для включения в ОС.
• Название Toybox, вероятно, отсылает к коллекции игрушек (аналогично BusyBox) и может быть связано с песней Soundgarden.
• Проект ценится за чистый код и пермиссивную лицензию, но пока не достиг полной функциональной parity с BusyBox.

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

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

• Проблемы совместимости кода для x86 и ARM архитектур, включая необходимость использования библиотеки SIMDe для эмуляции x86 intrinsics на ARM.
• Обсуждение особенностей и ограничений NEON (ARM SIMD) по сравнению с SSE (x86 SIMD), включая отсутствие инструкции movemask и предложенные альтернативы.
• Потенциальные применения алгоритма для эффективной битовой упаковки и распаковки данных в задачах, чувствительных к пропускной способности памяти (например, в data warehouses).
• Критика методологии бенчмарков и сравнений в исходном исследовании, анонс собственной работы по схожей тематике.
• Рекомендации к дополнительным материалам по теме: научная статья обобщающая алгоритмы и статья о симуляции bit packing на NEON.

Проект edge264 представляет собой простой декодер H.264, написанный на C. Он предназначен для образовательных целей и демонстрации базовых принципов работы с видеокодеком, избегая сложностей промышленных реализаций. Код легко читается и модифицируется, что делает его полезным для изучения алгоритмов сжатия видео.

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

• Отмечена сложность и значительный объем работы по созданию видеокодека, автору высказаны похвалы.
• Обсуждены технические детали реализации: доступ к макроблокам, использование переменной окружения VARIANTS для оптимизации под разные процессоры.
• Высказано сомнение в целесообразности поддержки Apple Silicon из-за наличия аппаратных декодеров и альтернатив в виде libavcodec.
• Поднят вопрос об архитектуре проекта: использование нескольких исполняемых файлов вместо multiversioning функций.
• Упомянута возможность сборки и работы кодеков на ARM64 Mac OS X, несмотря на заявленное отсутствие поддержки.

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 — это современный язык системного программирования, который предлагает альтернативу C и C++ с акцентом на безопасность, производительность и простоту. Он исключает неопределённое поведение благодаря строгой проверке типов и управлению памятью без сборщика мусора, что делает его особенно привлекательным для низкоуровневых задач. Zig также предоставляет мощные инструменты для метапрограммирования и кроссплатформенной компиляции.

Одной из ключевых особенностей Zig является его минималистичный дизайн и предсказуемость выполнения, что снижает сложность отладки и поддержки кода. Язык активно развивается и набирает популярность в сообществе за счёт своей прозрачности и эффективности. Практический вывод: Zig может стать отличным выбором для проектов, где критичны контроль над памятью и производительность.

• Критики выражают сомнения в целесообразности использования Zig для крупных проектов из-за отсутствия гарантий памяти, как в Rust или Swift, и нестабильности языка до версии 1.0.
• Сторонники Zig отмечают его сильные стороны: простоту, явный контроль над выделением памяти, отличную совместимость с C и возможность писать код без использования кучи.
• Обсуждаются практические примеры успешного использования Zig в реальных проектах (Tiger Beetle, Ghostty), несмотря на нестабильность.
• Поднимается вопрос о своевременности выхода книги по языку, который всё ещё активно меняется, что может быстро сделать издание устаревшим.
• Утверждается, что безопасность памяти — это спектр, а не бинарный выбор, и что простота Zig может снижать количество логических ошибок в целом.

Этот репозиторий содержит пошаговое руководство по созданию операционной системы с нуля на языке C и ассемблере. Он охватывает основы загрузки, управления памятью, прерываний и файловых систем, предлагая практический опыт низкоуровневого программирования.

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

• Создание ОС с нуля на базе устаревшего BIOS и x86 рассматривается как учебный, но непрактичный путь, погружающий в исторические детали архитектуры вместо современных концепций.
• Многие проекты ОС остаются незавершенными из-за сложности поддержки железа и драйверов, что является рутинной и нетривиальной задачей.
• В качестве более актуальных альтернатив предлагаются подходы с использованием микрокернелов, современных архитектур (RISC-V, ARM) или существующих педагогических ОС (xv6).
• Рекомендуется начинать с изучения авторитетных источников (например, wiki.osdev.org) и современных туториалов, избегая устаревших материалов с пробелами и ошибками.
• Разработка ОС углубляет понимание распределенных систем, планирования и кэширования, что полезно для инженеров, даже если они не планируют писать ядро.

Разработан экспериментальный компилятор Scheme в WebAssembly, который автор сам называет «очень плохим» и минималистичным. Он написан преимущественно на C (97.2%) и способен преобразовывать код Scheme в валидный WASM-модуль, который затем можно запускать через Wasmtime.

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

• Упомянуты проекты на WebAssembly: минимальный OOP рантайм, Forth, компилятор в твите и книга о WebAssembly.
• Обсуждается компилятор Scheme в WebAssembly (Guile Hoot), его особенности и поддержка WASM-GC.
• Затронуты технические вопросы: возможность использования как интерпретатора, поддержка tail call и call/cc.
• Отмечается важность самодостаточных инструментов и независимости от платформ.
• Поднята тема различий между Asm.js и WebAssembly в контексте исторического развития.

Оригинальная версия Prince of Persia была создана Джорданом Мечнером для Apple II за три года (1986–1989), но наиболее известной стала PC-версия 1990 года с улучшенной графикой и MIDI-музыкой, переоркестрованной его отцом. Именно она легла в основу большинства последующих портов благодаря превосходству языков C-семейства над устаревшим 6502.

Любопытны судьбы портов для Amiga и Macintosh: первый сделал легендарный Дэн Горлин идеально и в срок, а второй затянулся из-за постоянных адаптаций под новые модели Mac. Неофициальные порты для Commodore 64 и Plus/4 появились лишь десятилетия спустя, уже от фанатов.

• Книги Джордана Мекнера о создании игр "Karateka" и "Prince of Persia" высоко оцениваются как увлекательный личный дневник и взгляд на историю компьютерной революции.
• Обсуждается ценность свежего взгляда при тестировании и ревью кода (или любого творческого продукта), так как автор не замечает собственных допущений.
• Пользователи делятся ностальгическими воспоминаниями о своем первом опыте игры в Prince of Persia на различных платформах: DOS, Hercules, Siemens-телефоне, SNES и фанатском порте для Atari.
• Критикуется двухколоночная верстка статьи на сайте, предлагаются технические решения для улучшения читаемости (изменение CSS, режим чтения).
• Отмечаются технические детали портирования игры (поддержка Hercules, различия версий для разных платформ) и высокое качество арта и музыки в версии для SNES.

На RustConf 2025 обсуждалась совместимость Rust и C/C++, где Чендлер Каррут сравнил подходы Rust и экспериментального языка Carbon. Rust предлагает инструменты вроде bindgen и cxx для взаимодействия, но они слабо подходят для сложного legacy-кода C++ (brownfield), где тесные связи и большой API усложняют миграцию. Carbon же задуман как полностью совместимый с C++ язык, позволяющий постепенно переписывать проекты файл за файлом без смены компилятора, с акцентом на аннотации для безопасности памяти.

Каррут считает, что Rust не скоро решит проблему полной интероперабельности с C++, тогда как Carbon предлагает эволюционный путь, аналогичный переходу от JavaScript к TypeScript. Это даёт пространство для Carbon, особенно в крупных legacy-проектах, где полный переход на Rust непрактичен. Вывод: два языка могут сосуществовать, решая разные аспекты миграции к безопасным языкам.

• Обсуждается сложность и подходы к миграции с C/C++ на современные языки (Rust, Kotlin, Swift), включая инструменты для конвертации и постепенного перехода.
• Поднимаются вопросы о важности качественной интероперабельности между языками и недостатках C как языка-«клея» из-за отсутствия современных функций безопасности.
• Высказываются сомнения в универсальности Rust для полного переписывания из-за архитектурных несовпадений с идиоматическим C++.
• Отмечается, что такие проекты, как Carbon, нацелены на крупные кодобазы (вроде Google) и инкрементальный рефакторинг без полного переписывания.
• Упоминается, что принятие Rust в Linux пока ограничено (драйверы, отдельные подсистемы), а будущее Kotlin и Swift вне их экосистем (Android/Apple) остается под вопросом.

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

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

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

jacobly0 предлагает полностью переписать линкер Zig с нуля, создав Elf2 вместо текущей реализации. Основная цель — повысить производительность, уменьшить потребление памяти и улучшить поддержку различных форматов объектных файлов. Новая архитектура позволит эффективнее обрабатывать символы, секции и релокации, избегая проблем существующего кода.

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

• Участники высоко оценивают Zig как компилятор для C/C++ и инструмент кросс-компиляции за его простоту и самодостаточность.
• Отмечается мощная вертикально интегрированная система сборки Zig, включающая линкер и бэкенды генерации кода, что открывает возможности для оптимизаций.
• Обсуждаются ограничения использования линкера Zig (elf2) и самого компилятора вне экосистемы Zig, а также отсутствие неструктурированного goto.
• Некоторые пользователи выражают смешанные чувства: язык делает многое правильно, но отдельные изменения и особенности вызывают сомнения.
• Упоминается книга "Linkers and Loaders" и общее оживление в области разработки линкеров (ренессанс).

Миниатюрная библиотека 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.

Проект isingLenzMC реализует метод Монте-Карло для классической модели Изинга с использованием высокопроизводительной библиотеки на языке C. Основная цель — эффективное моделирование фазовых переходов в магнитных системах, где спины атомов могут находиться в двух состояниях. Алгоритм учитывает взаимодействие ближайших соседей через гамильтониан Ленз-Джонса, что позволяет точно описывать критические явления.

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

• Обсуждается внезапный интерес к старому репозиторию с методами статистической физики, возможно, связанный с новой статьей Google по квантовой эргодичности.
• Участники просят порекомендовать учебные материалы по методам Монте-Карло для начинающих и делятся ссылками на книги и лекции.
• Затрагивается вопрос о различии терминов "Statistical Physics" и "Statistical Mechanics" (признаны синонимами).
• Обсуждается роль экосистемы R для воспроизводимых исследований и её потенциальная конкуренция с Python в области научных вычислений.
• Высказывается мнение, что моделирование одномерной модели Изинга является базовым упражнением, но может быть полезно для понимания эргодичности.

Два с половиной года назад я начал свой самый длинный эксперимент с программным обеспечением в реальных условиях. Прочитав статью о работе движка 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.
• Высказывается уважение к стабильности и инженерному качеству кода старых игр, несмотря на подобные баги.

curl 8.16.0 внедрил pthread_cancel, чтобы прерывать зависший getaddrinfo, но уже в следующем релизе функцию убирают: отмена потока приводит к утечке памяти.

glibc сначала резолвит имя, выделяя память, затем читает /etc/gai.conf, где встречается fopen — точка отмены. Если поток прервать на этом шаге, выделенные адреса не освобождаются, и утечка повторяется при каждом новом вызове.

Поскольку других «опасных» точек может быть ещё больше, а библиотека не гарантирует чистоту ресурсов, pthread_cancel признан неприемлемым. Возвращаемся к старому выбору: либо ждать pthread_join, либо пускать потоки «в свободное плавание» и накапливать их.

Кто не хочет тормозов — подключает c-ares, но тот не покрывает всех возможностей glibc.

• Проблема: стандартный POSIX-вызов getaddrinfo блокирующий, не имеет таймаута и плохо сочетается с pthread_cancel, что приводит к утечкам/дедлокам.
• Исторически DNS-запросы запускали в отдельном потоке/процессе, но 30 лет спустя ситуация не улучшилась.
• Альтернативы есть: getaddrinfo_a, c-ares, systemd-resolved, io_uring, но они либо glibc-специфичны, либо нетривиальны в кросс-платформенной разработке.
• Разработчики предлагают:
  – отказаться от pthread_cancel и использовать пул воркер-потоков с флагом «самоубийства»;
  – вынести DNS из libc в системный сервис;
  – дождаться нового POSIX-стандарта асинхронного резолвера.

CLAVIER-36
Компактная 36-клавишная механическая клавиатура с RGB-подсветкой, hot-swap и USB-C.

• CLAVIER-36 — новая сеточная музыкальная среда от River, написанная на C с нуля; кажется техническим прорывом благодаря вычислению всей сетки на аудио-частоте.
• В отличие от ORCA, появилась «проводная» система и встроенные инструменты, что упрощает создание больших и безопасно рефакторимых патчей.
• Пока десктоп-only: на мобильных выводится лишь просьба уйти; требуется короткое демо-видео, чтобы новичок за 10 секунд понял, что это «клавишный» секвенсор.
• Проблемы со скоростью: 200 Мбит/с не спасают, WASM-файл грузится по 4 минуты; автор обещает CDN и чинит сервер.
• Порт на Steam и поддержка Steam Deck в планах; желающим стоит добавить игру в вишлист.

skiftOS
Включите JavaScript для работы приложения.

• За 6 лет автор SkiftOS написал микроядро, загрузчик, графическую оболочку, UI-фреймворк и даже движок браузера.
• Код на современном C++ (модули, async, co_await) и выглядит очень чисто; вдохновение Rust заметно.
• Система CPU-рендеринг, GPU — в планах; сеть пока только HTTP, без HTTPS.
• Безопасность: приложения не видят всю память и железо, драйверы в userspace, доступ по capability.
• Собрать можно под Linux/macOS (./skift.sh run --release <app>), но полный билд сейчас сломан.
• Автор признаёт: почти не было личной жизни, помощь была лишь с движком браузера.

Как я вживил 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 г., но «красивые» безскоповые имена всё ещё популярны, поэтому переход идёт медленно.

GTK1
Классическая библиотека GUI GTK1 для Windows, Linux, macOS.
Языки: C/C++.
108 коммитов, 1 ветка, 0 тегов.

• Кто-то всё ещё поддерживает GTK 1.2: CinePaint и Lazarus используют его как «стабильную» базу, но приходится собирать из исходников — ни одна современная дистра, кроме Slackware, не поставляет пакеты.
• Совместимости между GTK1 и GTK2/3/4 нет: API ломают регулярно, что участники называют «визитной карточкой GNOME».
• GTK1 ценят за лёгкость, быструю работу по удалённому X11 и простоту статической линковки; минусы — нет юникода, антиалиасинга, fontconfig, только X11 core-шрифты.
• GTK2 тоже считают «мертвым»: 30-40 DLL на Windows, медленный remote-X, а тяжёлый GTK3/4 воспринимают как «ад в корзине».
• Утилиты вроде Glade давно не обновлялись, примеры в доках течёт памятью, а «лёгкой» сборки GTK2 никто не делает.

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

SQLite начинался как TCL-расширение и до сих пор носит его отпечаток: гибкая типизация, синтаксис $var в SQL и единственный адаптер внутри ядра — tclsqlite.c. Сегодня ядро на чистом C и работает без TCL, но вся разработка и тестирование держится на нём: 90 % кода тестов на TCL, генерация сборок, документация и релизы полностью автоматизированы скриптами makefile.tcl.

• Команда SQLite общается в приватном чате на собственном Tcl/Tk-скрипте (~1000 строк), который работает и как клиент, и как сервер.
• С 2021 г. основное общение перешло в встроенный Fossil-чат: он E2E-шифрован и доступен из любого браузера.
• SQLite сохраняет Tcl-наследие: sqlite3_analyzer — это тоже Tcl-программа, упакованная в С-обёртку.
• Подстановка $uid в SQL безопасна: токен распознаётся парсером SQLite, а не «eval»-ится Tcl.
• Участники защищают выбор Tcl: он компактен, стабилен и удобно встраивается в С, что важнее модных языков.

Контракты для C  
C++ почти утвердила контракты (P2900); я попробовал адаптировать идеи для C.  
Пока это черновик, без реализации в компиляторах.

Главное:  
- `pre`/`post` — проверяемые условия на входе/выходе функции.  
- Не ломают ABI.  
- Компонуются и позволяют оптимизатору выкинуть лишние проверки.  
- Если условие — константа, оно как `static_assert`: ошибка компиляции.

Базовые примитивы  
```c
contract_assert(условие, "текст");   // всегда проверяется, при лжи — abort
contract_assume(условие, "текст");   // компилятор верит, иначе UB

Пример функции

// заголовок
void *my_malloc(size_t s) pre(s) post(r: r);

// реализация
inline void *my_malloc(size_t s) {
    contract_assert(s, "size != 0");
    defer { contract_assert(defer_return_value, "ok"); };
    return malloc(s);
}

defer выполняет post-проверку при любом выходе.
Инлайн даёт компилятору видеть контракт; внешняя декларация сохраняет привычное разделение .h/.c.

Польза: читаемость, статический анализ, оптимизация.

• Участники спорят, что считать «контрактом»: от assert до полноценных спецификаций, проверяемых компилятором.
• Проблема С/С++: нет единого стандарта, каждый реализует по-своему (Digital Mars — с 90-х, Frama-C, C23 unreachable()).
• Часть сообщества считает контракты костылем для слабой типизации: «если типы не выражают инварианты, добавь ещё один слой».
• Критика С23: макрос contract_assume вызывает UB через unreachable(), что делает поведение непредсказуемым и оптимизацию агрессивной.
• Альтернативы: переходить на Ada/SPARK, Rust, OCaml — там контракты либо встроены, либо доказываются статически.

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, но многие мечтают о таких же проектах для других марок.

• Пакеты: libxslt, linux-c7-libxslt, linux-rl9-libxslt (версии <2)
• Суть: проект без мейнтейнера, 3 неисправленные уязвимости
• CVE-2025-7424: путаница типов xmlNode.psvi
• CVE-2025-7425: use-after-free в xmlFreeID
• CVE-2025-????: четвёртая уязвимость (18.06.25) пока не раскрыта
• Статус: патчи от Apple и Google есть, но не применены из-за отсутствия мейнтейнера

• Пользователи обсуждают, что libxslt остаётся единственной C-реализацией XSLT 1.0, на которую завязаны браузеры, GNOME-стек и множество дистрибутивов.
• Google отказалась выплачивать bug-bounty за уязвимости, сообщённые контрибьютору libxslt, а новый мейнтейнер всё ещё проходит бюрократическую проверку в GNOME.
• Появились предложения вывести XSLT из браузеров и заменить его WASM-полифиллом или переложить поддержку на Linux Foundation.
• Участники отмечают, что XSLT 1.0 имеет много реализаций (Saxon, Xalan, MSXML), но именно libxslt используется в Chrome/Blink, что создаёт монокультуру.

Плюсы Nim 2

• Память: по умолчанию ORC/ARC (RAII, деструкторы, move/copy), а не трассирующий GC. Можно --mm:none или --mm:atomicArc.
• Компилируется в C/C++/Obj-C/JS; выбираем компилятор (gcc, nvcc, …).
• Лёгкая интеграция: {.importc.}, {.importcpp.}, {.importjs.}, {.compile.} для сторонних файлов.
• Метапрограммирование: макросы, static исполнение кода на этапе компиляции, генерация CUDA.
• Краткость: мало шаблонного кода (чат на 70 строк).
• Производительность ≈ C/C++/Rust; поддержка SIMD, CUDA.

Минусы и подводные камни

• Генерируемый C/C++ код нечитаем — не цель проекта.
• Нет атомарных счётчиков в ORC по умолчанию (требуется флаг).
• Некоторые старые статьи/комментарии описывают Nim 1.x (GC по умолчанию).
• Синтаксис чувствителен к отступам и регистру (но это субъективно).

Мини-пример: простой key/value формат

import std/[tables, strutils]

type Config = object
  host*: string
  port*: int

proc loadConfig(path: string, T: typedesc): T =
  let data = readFile(path).splitLines()
  var kv = initTable[string, string]()
  for line in data:
    let parts = line.split('=')
    if parts.len == 2:
      kv[parts[0].strip()] = parts[1].strip()

  result.host = kv.getOrDefault("host", "localhost")
  result.port = parseInt(kv.getOrDefault("port", "8080"))

let cfg = loadConfig("app.conf", Config)
echo cfg.host, ":", cfg.port

Файл app.conf:

host = 0.0.0.0
port = 9000

Всё компилируется в один бинарник без GC-задержек.

• Пользователи отмечают редкую, но полезную возможность Nim — определять собственные операторы.
• Хвалят макросы, интегрированные в систему типов и перегрузку, сравнивая язык с «статически типизированным Lisp».
• Критика: сложности с Windows (Nimble-зависимости тянут GCC, Defender блокирует бинарники) и неоднозначная «фантастическая» интеграция с C++.
• Обсуждают объём JS-артефактов: для мелких примеров — десятки килобайт, но без оптимизации могут быть мегабайты.
• Для WASM рекомендуют компилировать в C и прогонять через Emscripten, но стандартные JS-биндинги не работают.
• Вопросы IDE: есть nimsuggest и быстрая настройка для Neovim, но плагинов для JetBrains почти нет.

fluid-sims — коллекция симуляций жидкости от seanwevans.
Репозиторий публичный, доступен без авторизации.

• Пользователи восторженно отреагировали на стиль Jos Stem и 3D-демо.
• @clbrmbr попросил сделать GPU-анимацию всего одной строки.
• @petermcneeley поделился примером realtime-флюида на WebGPU.
• @glouwbug задался вопросом, хватит ли CPU для уравнения Бюргерса.
• @dahart считает, что при низком разрешении и Navier–Stokes спокойно укладывается в CPU.

• Почему Forth?
  20 лет назад прочёл про язык в книге по embedded, но не вник. В июне 2025-го захотелось просто писать код и наткнулся на статьи Dave Gauera — решил попробовать.

• Два уровня Forth
  User: просто пользуешься языком.
  Hacker: IF…THEN, BEGIN…UNTIL и прочие конструкции — обычные слова, которые можно переопределить; язык описывает сам себя.

• goforth (Go)
  «Чистый» интерпретатор: слово хранит исходный текст, который повторно интерпретируется. Для пользователя работает, но нельзя реализовать IF внутри Forth — всё контролирует Go.

• ctil (C)
  Классическая реализация: связанный словарь, токен-трединг, большая часть на Forth. Позволяет писать:

: variable create 1 cells allot ;

: if   ' 0branch , here 0 , ; immediate
: then here swap - swap ! ; immediate
: else ' branch , here 0 , swap dup here swap - swap ! ; immediate

Итого: два эксперимента, показывающие разницу между «просто работает» и «можно копнуть душу языка».

• Реализация Forth на Go оказалась «не по канонам»: стек и память описаны отдельными структурами, поэтому многие стандартные слова не работают.
• Кто-то показал элегантный вариант на C++ с continuation-passing style и musttail-атрибутом clang.
• Всплыли воспоминания о Forth-диалекте FCode в Open Firmware старых Mac, но выяснилось, что Intel-Mac’и использовали EFI, а не Open Firmware.
• Читатели посетовали на читаемость кода без комментариев о стеке и отметили, что «high-level» реализации могут потерять дух Forth.
• Автор ответил: первая версия на Go была экспериментом, а «правильная» реализация на C хранит код и данные вместе, как положено.

Разработка собственной ОС освобождает от ограничений коллективной работы и позволяет экспериментировать с необычными паттернами. Вдохновлённый статьёй LWN «Object-oriented design patterns in the kernel», я реализовал все сервисы ядра через «виртуальные таблицы» (vtables) — структуры с указателями на функции, обеспечивающие полиморфизм на чистом C.

Базовая идея

struct device_ops {
    void (*start)(void);
    void (*stop)(void);
};

struct device {
    const char *name;
    const struct device_ops *ops;
};

Разные устройства регистрируют свои реализации ops, а вызывающий код работает с единым интерфейсом. Таблицу можно менять на лету без изменения клиентов.

Применение в моей ОС

• Сервисы: сетевой менеджер, оконный сервер и др. описываются структурой

struct service_ops { void (*start)(void); void (*stop)(void); void (*restart)(void); };

Позволяет из терминала запускать/останавливать потоки без хардкода.

• Планировщик: интерфейс yield, block, add, next реализуется разными стратегиями (round-robin, SJF, FIFO). Политику можно заменить без пересборки ядра.
• Файлы: как в Unix, «всё есть файл». Сокеты, устройства и обычные файлы предоставляют одинаковые read/write, скрывая сложность реализации.

Модули ядра
Такой подход легко расширяется динамически загружаемыми модулями-драйверами, как в Linux.

• Обсуждение показывает, что в ядре Linux и других проектах на C давно применяют «объектно-ориентированные» приёмы через структуры с указателями на функции (таблицы виртуальных методов).
• Некоторые считают это удобным и экономным по памяти, другие — источником проблем с читаемостью, отладкой и оптимизацией.
• Упоминаются готовые микро-фреймворки (co2, carbon) и примеры из tmux, где такие паттерны уже используются.
• Спор идёт о необходимости явного параметра this: одни ценят прозрачность, другие — «сахар» неявного this в C++/Java.
• Вопрос «почему бы не перейти на C++/другой язык» сводится к контролю над памятью, отсутствию «магии» и возможности оставаться на C ради производительности и простоты.

fenster — сверхкомпактная кроссплатформенная GUI-библиотека.

• Особенности:

  • Окно, пиксельный буфер, ввод с клавиатуры/мыши.
  • Один .h файл, ~400 LOC, зависимости: X11 (Linux), Cocoa (macOS), Win32 (Windows).
  • Поддержка C/C++, Zig, Odin, Rust, Go, JS (WASM), C#, Swift, Pascal, Nim, Lua, Python, Ruby, OCaml, Fortran.

• Быстрый старт (C):

#define FENSTER_IMPL
#include "fenster.h"
int main() {
  struct fenster f = {.width = 320, .height = 240, .title = "demo"};
  uint32_t buf[320*240];
  for (fenster_open(&f); fenster_loop(&f) == 0; ) {
    // рисуем
    fenster_sync(&f, buf);
  }
  return 0;
}

• Сборка: cc demo.c -o demo (Linux: -lX11, macOS: -framework Cocoa, Windows: без флагов).

• API (C):

  • fenster_open, fenster_close, fenster_loop, fenster_sync.
  • Поля: width, height, title, keys[64], mouse.

• Лицензия: MIT.

• Fenster — это минимальная C-библиотека, создающая окно с пиксельным буфером, а не полноценный GUI с кнопками и меню.
• Участники отмечают отсутствие скриншотов и просят добавить их в README.
• Название «Fenster» переводится как «окно» на немецком, африкаанс, шведском и других языках.
• Некоторые считают polling-цикл ошибкой, другие считают его допустимым для такой простой задачи.
• В блог-посте нашли опечатку в sizeof и ограничение кода 8-битными цветами.
• Проект вызывает интерес для визуализации данных и как лёгкая альтернатива raylib.

SDS — библиотека динамических строк на C от автора Redis.
Предоставляет удобный API: создание, копирование, конкатенация, форматирование, сравнение, обрезку и пр.
Скрывает ручное управление памятью, хранит длину и оставшийся буфер в заголовке, что ускоряет операции и делает буфер-переполнение невозможным.
Совместима с обычными char* (нулём-терминатором), поэтому строки можно передавать в любые функции стандартной библиотеки.
Используется в Redis, хорошо протестирована, распространяется под BSD-лицензией.

• Пользователи обсуждают, почему в SDS предпочитают sdscat(s, "...") вместо stscat(&s, "..."): главное — производительность и простота.
• Некоторые удивлены, что sds — это char* без const, что может привести к ошибкам при передаче в libc-функции, не обновляющие метаданные.
• Автор antirez напоминает: актуальная версия SDS живёт внутри Redis, куда она мигрировала и развивалась дальше.
• Разгорелся спор «зачем вообще писать на C, если есть C++ и string_view»; ответы: embedded, совместимость, «не платишь за то, что не используешь», а также исторические причины (Redis начинался в 2009, string_view появился в C++17).
• Подчёркивают: C-код можно встраивать куда угодно, а C++ уже требует рантайма и ограничивает переносимость.

agent-c — сверхлёгкий AI-агент от bravenewxyz.
Проект открыт, код на GitHub.

• 4 КБ-агент на Си вызывает OpenRouter через curl и исполняет команды, что вызывает шутки о «русской рулетке» и безопасности.
• Критика: сжатие UPX, отсутствие проверок ошибок, жёстко заданные константы, popen вместо libcurl.
• Лицензии обсуждают от «Copy me» до CC0, BSD, Apache, GPL и WTFPL.
• Некоторые предлагают запускать под отдельным пользователем или в Docker, локально через Ollama/LM Studio.
• Промпт заставляет агента говорить как Наполеон Динамит («Gosh!», «Sweet!»).
• Сравнивают с Rust-версией «alors» и оффлайн-Python-примером на 44 строки.

DOSDevelResources — подборка инструментов и ссылок для разработки под DOS.

Содержание

• Языки

  • C/C++: Watcom, DJGPP, OpenWatcom, SmallerC, SubC
  • Pascal: Free Pascal, Turbo Pascal 5.5
  • BASIC: FreeBASIC, QB64, QuickBASIC 4.5
  • Сборка: NASM, FASM, WASM, TASM, MASM 6.11
  • Прочее: Rust (rustc-dos), Go (gccgo), Lua, Python 2.4

• Библиотеки и API

  • Allegro, SDL, Raylib, GRX, pdcurses, OpenGL (Mesa3D), VESA, SoundBlaster, TCP/IP (Watt-32, mTCP)

• Утилиты

  • Редакторы: RHIDE, FTE, SETEdit, TDE, Vim, Emacs
  • Отладчики: GDB, WD, TD, SoftICE
  • Упаковка: UPX, LZEXE, PKLite, Diet
  • Эмуляция: DOSBox, DOSBox-X, 86Box, PCem, Bochs
  • Разное: Git, Make, Doxygen, Valgrind-like (Dr. Memory)

• Документация

  • Ralf Brown’s Interrupt List, PCGPE, Intel/AMD manuals, OSDev Wiki

• Ссылки

  • FreeDOS, OSDev, Vogons, Scene.org

Как пользоваться

Клонируйте репозиторий:

git clone https://github.com/SuperIlu/DOSDevelResources.git

Все файлы/архивы лежат в каталогах по темам.

Лицензия

MIT.

• Участники вспомнили, что DOS-ретросцена жива: анонсирован 3-месячный DOSember game-jam.
• Перечислены доступные инструменты: HX DOS Extender, JWasm, Borland C++ 3.1, Free Pascal, DJGPP, GW-BASIC/PC-BASIC, а также MIT-лицензированный набор Microsoft 1988 года.
• Названы ключевые ресурсы: PC Games Programming Encyclopedia, эмулятор PCjs, книги «Black Book of Graphics Programming», «Programmer’s Guide to the EGA/VGA» и «PC-Intern».
• Отмечены удобные IDE: RHIDE и клон Turbo Vision от Free Pascal, а также ностальгия по быстрым Borland-IDE.
• Обсуждали, что современные ассемблеры (FASM/NASM) удобнее старых MASM/TASM, а DOS-цели можно собирать даже из Win32 PE.

tinylisp — лисп-интерпретатор всего на 99 строк C.
Включает 21 примитив, сборщик мусора и REPL.
Доступны варианты с оптимизацией хвостовой рекурсии для ускорения и экономии памяти.

• Участники обсуждают крошечную реализацию Lisp, которую, по словам одного комментатора, могли писать для карманного компьютера Casio AI-1000 1989 г.
• Код раскритикован за «ужасный» стиль на C: злоупотребление double, нарушения strict aliasing и эндиан-зависимость.
• Предложены альтернативы: 100-строчный Lisp на Python, tinylisp, lispy.py Питера Норвига.
• Найдена синтаксическая ошибка в tinylisp (лишняя скобка) и отмечено отсутствие TCO, из-за чего Y-комбинатор не работает без доработки.

Я написал 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.
• Сторонники отмечают суверенитет и удобство, противники — нестабильность и «нелепый» брендинг.

Показываю, как в C сделать обобщённый контейнер maybe, который безопасно возвращает результат, если он есть, и сообщает об ошибке, если её нет.

#define maybe(T) struct { bool ok; T value; }
#define maybe_just(T,x)  { .value = (x), .ok = true }
#define maybe_nothing(T) { .value = (T){}, .ok = false }

static maybe(int) divide(int a, int b) {
    return (b != 0) ? maybe_just(int, a / b) : maybe_nothing(int);
}

Вызов:

maybe(int) p = divide(6, d);
if (p.ok) printf("%d\n", p.value);
else       puts("division by zero");

Чтобы не забыть проверку, добавляем макрос maybe_value, который при ошибке возвращает нулевой указатель, ловим его санитайзером:

#define maybe_value(x) \
    (*({ auto _p = &(x); _p->ok ? &_p->value : (void*)0; }))

Но деление на ноль — не единственная проблема. При делении INT_MIN / -1 возникает переполнение. Исправляем:

maybe(int) safe_divide(int a, int b) {
    if (b == 0 || (b == -1 && a == INT_MIN))
        return maybe_nothing(int);
    return maybe_just(int, a / b);
}

Компилируем с -fsanitize=signed-integer-overflow,integer-divide-by-zero -fsanitize-trap=undefined -O2. В ассемблере не остаётся пути к ud2, то есть оптимизатор доказал: переполнения и деления на ноль нет.

Это не делает весь C «безопасным» (жизненный цикл указателей и арифметика не покрыты), но для ограниченных задач подход работает.

• Критика: реализация не заставляет проверять результат, теряя главное преимущество Maybe.
• Ассемблер: GCC выдаёт почти тот же код, что и для std::optional, но не возвращает результат в регистре.
• UB: «пустой» lvalue в случае ошибки вызывает неопределённое поведение; автор полагается на null-sanitizer.
• Эргономика: предлагают добавить and_then/or_else и сделать тип непрозрачным через макросы.
• Почему не другой язык: встраиваемые/фирменные проекты часто ограничены только C или ASM.

Как обогнать memcpy

Профилируя Shadesmar, увидел: при больших (>512 КБ) сообщениях 97 % времени уходит на memcpy между процессной и разделяемой памятью. Решил ускорить копирование.

---

Разбор memcpy

perf показал:
__memmove_avx_unaligned_erms — это memcpy через memmove, AVX, 32 байта за раз, поддержка не выровненных блоков и ERMS (железный цикл REP MOVSB).

• memmove выбран, т.к. допускает перекрытие.
• Для <4 КБ используется SSE2, иначе — REP MOVSB + AVX.
• Не-временные (NT) инструкции и prefetcht0 уменьшают кэш-промахи.

---

Способ 1: простой REP MOVSB

void _rep_movsb(void *d, const void *s, size_t n) {
  asm volatile("rep movsb"
               : "=D"(d), "=S"(s), "=c"(n)
               : "0"(d), "1"(s), "2"(n)
               : "memory");
}

Тот же цикл, что и в glibc, но без лишней логики.

• Часть выгоды даёт отказ от лишнего копирования: часто данные можно использовать на месте.
• Несколько участников отмечают, что без контроля кэшей и правильной сериализации бенчмарки теряют смысл.
• График в конце вызывает сомнения: скачки пропускной способности выглядят неправдоподобно.
• Для IPC обсуждают zero-copy через размещение данных сразу в shared memory (Iceoryx, Boost.Interprocess, DPDK).
• Большинство сходится к выводу: для обычных задач лучше довериться стандартному memcpy/std::memcpy, особенно в glibc.

Переписал Ghuloum-туториал на Python (~300 строк). Убрал читалку S-выражений и бинарный код — теперь текстовая ассемблерная печать.

Lambda-lifting требует:

• знать связанные переменные;
• собирать свободные переменные лямбд;
• накапливать создаваемые code-объекты.

Связывают let и lambda; для них обновляем окружение.

Lifter

class LambdaConverter:
    def __init__(self):
        self.labels = {}

    def convert(self, expr, bound, free):
        match expr:
            case int() | Char() | bool():
                return expr
            case str() if expr in bound or expr in BUILTINS:
                return expr
            case str():
                free.add(expr)
                return expr
            case ["if", t, c, a]:
                return ["if",
                        self.convert(t, bound, free),
                        self.convert(c, bound, free),
                        self.convert(a, bound, free)]

lift_lambdas запускает обход и возвращает (labels …).

Lambda

Лямбда:

• связывает параметры;
• выделяет код;
• захватывает внешнее окружение.

Пример:

(lambda () x)  ; x свободна

превращается в

(labels ((f0 (code () (x) x)))
  (closure f0 x))

Даже если x связан снаружи, внутри лямбды он считается свободным.

• Участники рекомендуют три современные книги по компиляторам, вдохновлённые статьёй Ghuloum: «Writing a C Compiler» (Sandler), «Essentials of Compilation» на Racket и Python (Siek).
• Обсуждали «lambda lifting»: преобразование, выносящее замыкания наверх, уменьшая их размер вплоть до полного исчезновения.
• Уточнили, что «lambda lifting» в статье связан с разделом 3.11 о сложных константах в Scheme.
• Разбирали, почему современный ИИ использует Python, а не Lisp: удобство как «клея» для C++/CUDA, упадок доли рынка Lisp и смена парадигмы ИИ.

bolt — компактный встраиваемый язык на C:

• высокая скорость, реал-тайм, статическая типизация
• целевые задачи: скрипты в играх, IoT, системы с ограниченными ресурсами

Основное

• репозиторий: Beariish/bolt
• лицензия: MIT
• компилятор ~150 КБ, зависимости отсутствуют

Возможности

• синтаксис C-подобный, сборка мусора без пауз
• FFI к C «из коробки»
• компиляция AOT/JIT, кроссплатформенность (x86, ARM, RISC-V)

Быстрый старт

git clone https://github.com/Beariish/bolt
cd bolt && make
./bolt examples/hello.bt

hello.bt

import std.io;

fn main() {
    io.println("Привет, bolt!");
}

• Пользователи одобрили идею быстрого статически типизированного скрипт-языка для встраивания, но сразу спутали «embedded» с «embedded-systems» и отметили отсутствие поддержки ARM/32-бит и отказ от целочисленных типов.
• Критика синтаксиса import a, b from module: неудобен для автокомплита и повышает риск конфликтов имён; автор готов добавить псевдонимы.
• Сомнения в заявленной скорости: несколько человек привели замеры, где Bolt проигрывает LuaJIT и даже обычной Lua 5.4.
• Подняты вопросы о полноте типовой системы (генерики, полиморфизм), отладке, LSP, сборке мусора и долгосрочной поддержке.
• Плюсы: понятный C/Python-подобный синтаксис, удобный Result-тип, потенциальная замена Lua в играх и редакторах.

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.

Моя предыдущая статья о обобщённых структурах данных в C готовила почву к теме: структура, которая заменяет динамические массивы, даёт стабильные указатели и хорошо работает с аренными аллокаторами. Её переоткрывали много раз под разными именами: “levelwise-allocated pile” (2001), в Zig — Segmented List, частично похожая на C++ std::deque. Мне нравится название Per Vognsen — Segment Array.

Скачать мой однофайловый заголовок segment_array.h можно, подписавшись на рассылку.

Идея проста: фиксированный массив указателей на сегменты; каждый следующий сегмент вдвое больше предыдущего; новые сегменты выделяются по мере необходимости. Поскольку элементы не двигаются, указатели на них стабильны, не остаются “дыры” в арене, а доступ по индексу — за O(1).

Реализация

Структура на C:

typedef struct { u32 count; int used_segments; u8 *segments[26]; } SegmentArrayInternal;

Почему всего 26 сегментов? Из 64 бит указателя обычно реально используются 48, так что 49 сегментов уже перекрывают адресное пространство (~256 ТиБ). Я предпочитаю индекс u32 (до ~4 млрд элементов) — это даёт 32 сегмента. Ещё убираем 6 маленьких (1..32), начинаем с 64, остаётся 26 сегментов — хватает для 4 294 967 232 элементов (чуть меньше UINT32_MAX). Фиксированный массив рядом со структурой снижает риск промаха кэша.

Размеры сегментов — степени двойки: проще математика и быстрые сдвиги для индексов.

#define SMALL_SEGMENTS_TO_SKIP 6

#define log2i(X) ((u32) (8*sizeof(unsigned long long)
- __builtin_clzll((X)) - 1))

u32 capacity_for_segment_count(int segment_count) { return ((1 << SMALL_SEGMENTS_TO_SKIP) << segment_count) - (1 << SMALL_SEGMENTS_TO_SKIP); }

void *_sa_get(SegmentArrayInternal sa, u32 index, size_t item_size) { int segment = log2i((index >> SMALL_SEGMENTS_TO_SKIP) + 1); u32 slot = index - capacity_for_segment_count(segment); return sa->segments[segment] + item_sizeslot; }

log2i использует __builtin_clzll (подсчёт ведущих нулей) для быстрого вычисления номера сегмента.

Clang оптимизирует _sa_get до ~10 инструкций x86-64 (-O3), так что узким местом будет память, а не вычисления индекса. При последовательной итерации можно обходить сегменты напрямую; в segment_array.h есть макрос.

Выделение нового элемента:

u32 slots_in_segment(int segment_index) { return (1 << SMALL_SEGMENTS_TO_SKIP) << segment_index; }

void *_sa_alloc(SegmentArrayInternal *sa, size_t item_size) { if (sa->count >= capacity_for_segment_count(sa->used_segments)) { size_t segment_size = item_size * slots_in_segment(sa->used_segments); sa->segments[sa->used_segments++] = malloc(segment_size); } sa->count++; return _sa_get(sa, sa->count-1, item_size); }

Замечание: можно сделать ёмкость строго степенью двойки, если первые два сегмента одинакового размера. Код станет менее изящным, но это спасает от ~50% потерь памяти при использовании как массива бакетов в хеш-таблице со степенью двойки.

Дженерики

Я применяю технику из прошлой статьи для типобезопасного хранения любого типа. Макрос связывает тип с общей структурой:

#define SegmentArray(type)
union {
SegmentArrayInternal internal;
type *payload;
}

Дальше макросы используют payload, чтобы передавать сведения о типе…

• Обсуждается структура «сегментированный массив» (экспоненциальные сегменты), её плюсы и минусы, и сравнение с существующими решениями: std::deque, ropes, Zig std.SegmentedList, rust-array-stump, plf::colony.
• Критика терминологии: это не «массив» в классическом смысле из‑за неконтигуозной памяти; многие API ожидают сплошной/страйдовый буфер и не подойдут.
• Производительность: при локальных L1-итерациях вычислительная часть индексации может быть ощутима; для больших объёмов память становится бутылочным горлышком. Предлагаются оптимизации итерации по сегментам и замечания про clz/bsr/lzcnt и опции компилятора.
• Виртуальная память как альтернатива: резервирование большого диапазона и по мере роста коммит страниц/guard pages; отмечены плюсы на Linux (MAP_POPULATE, mremap), но плохо для embedded/WASM.
• Сравнение с deque: фиксированные блоки vs экспоненциальные, поддержка prepend, рандом-доступ есть; реализация MSVC критикуется за малый размер блока, GNU/libc++ лучше.
• Недостатки сегментов: ухудшение предвыборки/кэш-локальности при линейной итерации, отсутствие стабильной непрерывности для API, сложность с хеш-таблицами при росте (rehash), потенциальный перерасход памяти при экспоненциальных размерах.
• Предложения: настраиваемый минимальный размер сегмента, функции «склейки» мелких сегментов, разбор условий, когда экспоненциальные сегменты оправданы, и замечания о чрезмерной макротрюковости в C/C23.

Добро пожаловать на 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/параллельных подходов, но признают их практические ограничения.

The reason you are not seeing crashes when allocating with Rust and freeing with C (or vice versa) is that by default Rust also uses the libc allocator.https://stdrs.dev/nightly/x86_64-unknown-linux-gnu/src/std/s... Lots of detail, little substance, and misleading section headers

This is epic: :)From : https://github.com/ioccc-src/winner/blob/master/2024/kurdyuk...This code draws the current moon phase to the console. So if you’re a lycanthrope, you can monitor the phase of the moon.#include <time.h> #include <stdio.h> a,b=44,x, y,z;main() {!a ?a=2551443,