Разработчик, не нашедший «идеальный» шрифт для терминала и Neovim, спроектировал собственный с нуля на Python. Nordwand Mono — компактный моноширинный неогротеск, переносящий элементы классического «Univers» Адриана Фрутигера в пропорции «JetBrains Mono». Название отсылает к Швейцарии и её типографике, а также к суровой атмосфере северных стен Альп. Среди источников вдохновения также указаны «SF Pro» и «SF Mono» от Apple, «Alpes Mono» от Sharp Type и «Ubuntu Mono» от Dalton Maag.

Шрифт предлагает альтернативные начертания отдельных символов, переключаемые через теги OpenType, и всего две минимальные лигатуры — для «->» и «=>»; полный набор лигатур автор обещает, возможно, добавить позже, но сам пользоваться ими не собирается. Поскольку каждый глиф рисуется Python-классом с внедряемым контекстом отрисовки, можно менять метрики — например, высоту строчных или прописных знаков — через файл конфигурации: отдельные глифы просматриваются командой python -m visualize, а полный шрифт собирается командой python -m generate_font в папку ./custom-fonts. Автор предупреждает: при изменении метрик вид шрифта не гарантирован, а некоторые глифы потребуют ручной правки.

В репозитории есть образцы символов, начертаний и примеры кода на Python, C++ и Haskell, а также альтернативный кириллический алфавит.

Обсуждение дополняет статью практическими отзывами. Пользователи rootlocus, delta_p_delta_x и pookieinc считают Nordwand Mono почти идентичным JetBrains Mono или Berkeley Mono, отмечая различия лишь в отдельных знаках ($ и &). @fercircularbuf указывает на схожесть круглых и квадратных скобок, что затрудняет чтение кода. @bronlund ценит наличие минимального набора лигатур (→ и ⇒), так как остальные обычно отключают для разгрузки визуального потока. @JoshTriplett отмечает комфортный межсимвольный интервал, схожий с DejaVu Mono, в отличие от многих современных узких шрифтов. @abainbridge добавляет, что на мониторах с 100 DPI предпочитает bitmap-шрифты с ручным антиалиасингом для более резкой картинки и компактности текста.

Бенчмарк StarSkirmish v0.2 проверяет, насколько сильного бота для StarCraft: Brood War напишет языковая модель за один час — на C++ и за протоссов. Затем бот играет против ботов других моделей и против написанных людьми. Оценка — средняя доля побед по пяти запускам, от 0 до 100.

Лидирует GPT-6 Astra, за ним GPT-6.1 Sol; Gemini 4 Argon, Claude Opus 5.5 и Claude Fable 5.1 практически вровень (37–39). Лучшее соотношение цены и качества у GPT-6.1 Sol — единственной модели в привлекательном квадранте, чуть дороже десятой доли цены лидера.

Насыщения не видно: против сильнейших человеческих ботов Stardust, PurpleWave и BananaBrain лучшая модель выигрывает лишь 7% игр. Сильнее всего счёт предсказывает объём практики против семи сильнейших ботов ростера: GPT-6 Astra, GPT-6.1 Sol и Gemini 4 Argon начинают играть с ними рано, ещё проигрывая. Fable 5.1 — исключение: 37 очков, тренируясь почти только на слабых. Разброс между запусками велик у Gemini 4 Argon (18 очков против 9 и 8 у конкурентов). Бенчмарк больше не коррелирует с Artificial Analysis Intelligence Index (ρ 0,26) и отошёл от Terminal-Bench 4.0, но по-прежнему связан с Vals IOI и WeirdML.

Обсуждение дополняет статью скепсисом относительно чистоты бенчмарка из-за возможного запоминания кода ботов из обучающей выборки и подчеркивает критическую роль «обвязки» (harness) в производительности моделей. Пользователи @gritzko и @donutdonot полагают, что бенчмарк проверяет скорее способность к воспроизведению кода из обучающей выборки (recall), так как в сети много реализаций ботов для StarCraft, в то время как @gritzko отмечает, что в играх с меньшим количеством открытого кода LLM демонстрируют иные аспекты рассуждений. По опыту @djoldman, выбор интерфейса взаимодействия (harness), доступные инструменты (например, веб-поиск) и уровни «мышления» (thinking levels) оказывают огромное влияние на итоговый результат одной и той же модели. В то время как бенчмарк ставит GPT-6 Astra на первое место, @t1amat по своему опыту при создании ботов для ModernUO обнаружил, что Claude Opus 5.5 значительно лучше справляется с пониманием и построением системы, чем модели GPT-6. По мнению @GodelNumbering, результаты StarSkirmish v0.2 точно коррелируют с рейтингами GoBench (бенчмарк по игре Го), что указывает на общую иерархию способностей моделей в сложных стратегических задачах. Для более объективной оценки @BeaverGoose предлагает протестировать LLM-ботов против Pluto — нейросетевого бота, способного побеждать лучших игроков в Brood War. Пользователи @iugtmkbdfil834 и @carychang отмечают, что текущий метод оценки не разделяет навыки генерации кода, логический анализ, знание платформы C++ и умение разрабатывать тактики.

Проект PS5LM запускает llama.cpp прямо на взломанной консоли PS5: языковая модель работает на GPU консоли через бэкенд Vulkan на чипе RDNA 2, получая 11,4 ГБ общей памяти под модель и контекст. Консоль превращается в приватный сервер моделей для всей домашней сети — без ПК, облака и аккаунтов. Она отвечает на OpenAI-совместимый эндпоинт /v1/chat/completions, на Anthropic-совместимый /v1/messages (с ним работает Claude Code) и на /v1/systemone для «решающих» моделей вроде d1, Clef и OpenJev, выдающих типизированные решения с калиброванными вероятностями за доли секунды.

Интерфейс выведен на телевизор: каждый запрос стримится как чат с указанием устройства и текста ответа, кнопка «квадрат» запускает демо, «треугольник» открывает клавиатуру — всё управляется с дивана. Отдельная страница следит за температурой, энергопотреблением и загрузкой GPU и CPU за последние две минуты или час. Планировщик сам подбирает для каждого GGUF-файла максимальный контекст и лучший кэш под свободную память, а список Suggested содержит модели, измеренные на консоли. Поддерживаются все архитектуры и квантования, известные llama.cpp. Проект распространяется под GPL-3.0, не содержит файлов SDK Sony, ключей, прошивок и весов моделей и не связан с Sony Interactive Entertainment.

Запуск llama.cpp на взломанной PS5 технически возможен, но модель Qwen 3.8 27B в 2‐битной квантизации работает медленно и хуже, чем современные сервисы. Хостинг проекта на GitHub повышает риск DMCA, поэтому рекомендуется дублировать репозиторий. Для практических задач лучше использовать более мощные GPU или хотя бы 4‐битную квантизацию. Спор: Rabbit504030201 считает, что проект не должен размещаться на GitHub из‐за риска DMCA от Sony; dewey и другие указывают, что GitHub обеспечивает видимость и возможность зеркалирования; minimaxir предупреждает, что даже кастомный домен не спасёт от takedown. Несколько комментаторов согласны, что взломанная PS5 может стать недорогим вычислительным узлом — цена в $650 сопоставима с бюджетными видеокартами, но её аппаратные возможности уступают специализированным GPU. Модель Qwen 3.8 27B в 2‐битной квантизации на PS5 работает значительно медленнее и менее качественно, чем Claude или Opus 5.5: токен‐пропускная способность низкая, ответы требуют десятки тысяч токенов. Совет: Для улучшения качества вывода рекомендуется использовать 4‐битную квантизацию вместо 2‐битной — она ближе к полной точности и даёт более приемлемую производительность. PS5 подходит для длительных задач с низкой требовательностью к интеллекту: мониторинг серверных ошибок, просмотр видеонаблюдения, управление поливом растений. Спор: shiftpgdn предлагает использовать дешёвые платы BC250 за $150‐200; haunter возражает, что за такие деньги выгоднее купить RTX 3060 — получив более надёжную и гибкую платформу. Совет: Чтобы снизить риск удаления проекта, следует зеркалировать репозиторий не только на GitHub, но и на альтернативных хостингах или собственных доменах, как советует dewey.

Игры PlayStation 2 запускаются прямо в браузере благодаря статической рекомпиляции: машинный код Emotion Engine заранее переводится в C++ и компилируется в WebAssembly, поэтому главный процессор никогда не интерпретируется. Остальная консоль — её операционная система и аппаратура — эмулируется средой выполнения, которая рисует через WebGPU. Первой игрой стала Gran Turismo 4, одна из самых требовательных на системе: она опирается на оба векторных блока, на точное поведение чисел с плавающей точкой в повторах и лицензионных тестах и на графические трюки с чтением отрисованных изображений как палитр. Игра проходит от загрузки через вступительный ролик, меню и гонки, со музыкой и звуками, и сохраняется на карту памяти, хранимую в браузере. Гонка идёт на полной скорости — 50 кадров в секунду для европейской версии — в Chrome на встроенной графике ноутбука при вдвое большем разрешении, чем у PS2.

God of War II заработала на тех же скриптах без кода под конкретную игру, но вскрыла два бага, которых Gran Turismo 4 не вызывала: один в рекомпиляторе, другой в таймингах векторного блока, плюс нехватку частей процессора ввода-вывода. Теперь она идёт от меню через катсцены в бой и держит 60 кадров в секунду в тяжёлых схватках при родном разрешении PS2, а при удвоенном — от 48 до 60, упираясь во встроенную графику. Данные игр не входят в репозиторий: вы приносите образ своего диска, а скрипты превращают его в веб-страницу на вашей машине. Диск читается через HTTP-запросы диапазона, поэтому сначала скачивается только исполняемый файл. Карту памяти можно выгрузить в формате .ps2, совместимом с PCSX2, и перенести между браузерами. Страница требует изоляции источников из-за SharedArrayBuffer, а сгенерированный код принадлежит правообладателям игр — публиковать его нельзя.

Обсуждение вызывает скепсис относительно термина «рекомпиляция», так как проект фактически остается эмулятором с вшитым образом, а не полноценной статической рекомпиляцией. Пользователи @vrighter и @anonymous908213 отмечают, что лишь часть кода переведена в функции, а автор позиционирует проект как «без эмулятора», что противоречит реальности. Сообщество признаёт, что современные LLM ускорили декомпиляцию и рекомпиляцию игр, но это вызывает опасения по качеству и достоверности заявлений. @aceazzameen выражает обеспокоенность скрытым вредоносным ПО, на что @johnfn отвечает, что WebAssembly является одной из самых безопасных сред исполнения. По опыту @kodablah, аналогичный ARM-to-WASM подход для PS Vita работает эффективно в Chrome на флагманских Android-устройствах. Пользователь @Hyperlisk разрабатывает схожий инструмент с фокусом на точность, используя рекомпиляцию в Golang для поддержки SIMD.

Автор провёл три месяца, используя ИИ-агентов для декомпиляции популярного шутера от первого лица, стремясь не к прототипу, а к точному, стабильному и полнофункциональному воссозданию игры на C++. Вместе с командой из RektInator, Future, st0rm и других участников сообщества он сосредоточился на оркестрации автономных агентов, оптимизации инфраструктуры и отладке процесса, а не на самой игре или технике декомпиляции. Агенты работали в Claude Code и Codex CLI, используя модели вроде Sonnet 5, Opus 5.5 и Luna, отслеживая прогресс через GitHub Issues и общаясь в Discord, где публиковались также сбои CI. Для работы с бинарником применялся ida-mcp от Hex-Rays — стабильный и headless-инструмент. За первый месяц четыре агента (три воркера и один ревьювер) декомпилировали ~80% игры, запустили главное меню и загрузку карт, но позже обнаружили, что сгенерированный код был низкого качества, и попытки его исправить заняли больше времени, чем пересоздание с нуля — вывод: корректность важнее продуктивности. Для снижения расхода токенов порог компакции контекста был снижен с 90% до 42%, а для борьбы с дрейфом внимания агентов внедрялся почасовой сброс инструкций. К концу проекта использовалось 15+ агентов, что выявило новые сложности: периодический сброс VM из-за ошибочных команд привёл к потере логов, и автор оценивает общий расход в 600–700 млрд токенов, из которых ~300 млрд пришлись на Luna (эквивалентно ~3 млрд токенов Astra при соотношении 100:1). Из-за корпоративного давления название игры не раскрывается, код остаётся приватным, а автор сейчас развивает свой эмулятор Sogen для создания надёжного песочницы, необходимой для будущих подобных проектов. Orchestration ИИ-агентов оказалась гораздо сложнее, чем ожидалось, но дала бесценный опыт в управлении автономными системами в долгосрочной разработке.

Тред дополняет статью практическими возражениями против цели байт-идентичности: указывает на избыточные затраты, альтернативные подходы к функциональной эквивалентности и роль качества модели, а также подчеркивает, что даже полная покрытость тестами не гарантирует идентичного поведения в сложных системах с глобальным состоянием. Спор: Некоторые считают байт-идентичный вывод избыточным и дорогим; другие настаивают, что только он гарантирует полную функциональную эквивалентность, включая неизвестные баги и поведение переполнений. Спор: Критики метода проверки последовательностей чтения/записи в RAM отмечают, что он не улавливает различия в поведении FPU, регистров или размещения переменных на стеке, при этом сохраняя семантическую эквивалентность. Совет: Опыт @aetherspawn показывает, что замена Sonnet на более мощную модель (Sol 6.1) снизила затраты с $1000 до $50 и ускорила завершение задачи с недели до двух дней. Совет: По опыту @momo5502, использование дешёвых моделей (Luna) при строгом харнессе позволяет эффективно обрабатывать сотни миллиардов токенов, что эквивалентно десяткам миллиардов токенов дорогих моделей. Спор: Участники отмечают, что даже с десятками тысяч тестов, покрывающих все ветки, невозможно гарантировать идентичное поведение из-за зависимости от глобального состояния и внешних данных, характерных для игр. Совет: Опыт @ChoosesBarbecue подтверждает, что глубокое знание игры (10 лет моддинга и эксплуатации) критически важно для успешной декомпиляции, иначе даже ИИ не справится с контекстом. Спор: Некоторые считают, что агентные системы не способны принимать архитектурные решения, требующие человеческого вкуса, что делает их непригодными для сложных систем без ручной настройки. Совет: Участник @edg5000 предлагает упростить процесс: вместо оркестрации агентов использовать один агент, что даёт лучший контроль над выводом, несмотря на большее время выполнения. Совет: Участник @tasubotadas отмечает, что даже без цели байт-идентичности процесс декомпиляции остаётся токен-интенсивным, особенно для редких игр с нестандартной архитектурой. Спор: Вопрос о легальности: участники спорят, каким образом использование ИИ для декомпиляции отличается от ручного — и нарушает ли это TOS, если модель не получает явных указаний на игру. Совет: Участник @stevefan1999 указывает, что динамические диспетчеры (vtable, fat pointers) и различия в выравнивании компилятора значительно усложняют декомпиляцию, даже для опытных разработчиков. Совет: Участник @Neywiny поднимает вопрос о влиянии LTO: если код скомпилирован с объединением единиц компиляции, декомпиляция становится практически невозможной из-за потери структуры. Совет: Участник @Fizz43 предупреждает, что утверждения об '80% совпадении' от ИИ — бессмысленны, так как не имеют смысла в контексте бинарной эквивалентности. Совет: Участник @Uptrenda отмечает, что ИИ-модели могут отказываться участвовать в декомпиляции, если им известны TOS, что ставит под сомнение возможность использования закрытых моделей без обфускации входных данных. Все согласны, что декомпиляция игр с помощью ИИ — это не просто техническая задача, а сложный инженерный процесс, требующий глубокого понимания как архитектуры, так и юридических рисков.

Проект psp-web-recomp позволяет запускать игры для PSP в браузере без эмулятора, используя статическую рекомпиляцию машинного кода MIPS в C++, который затем компилируется в WebAssembly. Игра взаимодействует с высокоуровневой эмуляцией ядра PSP (HLE), реализованной в C++, которая обеспечивает работу потоков, файловой системы (с потоковой загрузкой данных диска через HTTP Range-запросы), контроллера, аудио и сохранений. Графический чип GE эмулируется на CPU, где обрабатываются дисплей-листы, а результаты рендеринга передаются в WebGL2 через OffscreenCanvas в отдельном рабочем потоке, что позволяет достичь 60 FPS даже при увеличенном разрешении (до четырёх раз нативного 480×272). Звук, включая музыку и речь, декодируется через портированный ATRAC3/ATRAC3+ декодер из PPSSPP. Для работы требуется кросс-ориентированная изоляция (COOP и COEP), обеспечиваемая локальным сервером с нужными заголовками. Пользователь предоставляет собственный образ диска игры, после чего скрипты генерируют локальную веб-страницу. На данный момент успешно запущены God of War: Chains of Olympus и God of War: Ghost of Sparta, работающие на ноутбуках и смартфонах с сенсорным управлением, хотя видеовставки пока пропускаются. Весь код проекта распространяется под MIT-лицензией, за исключением сторонних компонентов с их собственными лицензиями. Важно: полученный WebAssembly и C++ считаются производными от оригинальной игры и должны храниться только локально.

Статическая рекомпиляция PSP‐игр в WebAssembly воспринимается как прорыв в сохранении игрового наследия, особенно когда оригинальные разработчики не поддерживают проекты. Однако она вызывает споры: некоторые считают, что это стимулирует разрозненные «vibe‐coded» порты вместо совместной работы над единым decomp‐проектом, ослабляя качество и сотрудничество в открытом сообществе. Есть опасения, что такой подход может нарушать законы об интеллектуальной собственности, и крупные компании могут добиваться ужесточения законодательства. Участники отмечают, что AOT‐компиляция и статическая рекомпиляция технически воспроизводят поведение железа, но не считаются традиционной эмуляцией. Автор проекта подтверждает, что порты работают в браузере с приемлемой скоростью даже на старом железе, демонстрируя более 1 000 MIPS в Firefox. Для легального использования необходимо иметь собственный образ PSP‐диска, так как репозиторий не содержит игровых ресурсов. Другие разработчики уже применяют аналогичные методы, например порт Super Smash Bros. Melee для браузера, показывая масштабируемость подхода. Также упоминается, что AI использовался для взлома DRM‐систем, что может привести к судебным искам против разработчиков подобных инструментов.

Whistle — это открытая модель распознавания речи размером 16,9 МБ, которая работает на CPU без зависимостей и использует тот же C++ движок, что и модель Needle. Она транскрибирует аудио до 30 секунд на семи языках: английском, немецком, французском, испанском, итальянском, нидерландском и польском, определяя язык автоматически, если он не задан явно. Первый токен появляется за 11 мс, а вся обработка происходит локально на устройстве — аудио никогда не покидает его. Помимо транскрипции, Whistle выдаёт временные метки для каждого слова с вероятностью и генерирует речевые эмбеддинги — по одному вектору на каждые 80 мс аудио, полученные из выхода энкодера.

Архитектура Whistle делит обработку на энкодер и декодер. Аудио преобразуется в 80-полосные лог-мел спектрограммы с окном 25 мс и шагом 10 мс, затем проходит через свёрточный стебель, уменьшающий длину с 3000 до 375 кадров (по одному на 80 мс). Энкодер состоит из восьми блоков Simple Attention, общих с Needle, использующих mHC residual lanes и Monarch Hadamard MLP вместо стандартного FFN. Декодер содержит восемь Laddered Simple Attention блоков с гейтированным кросс-вниманием к энкодеру, где ключи и значения проецируются один раз при загрузке аудио и переиспользуются для всех лучей. Декодирование выполняется beam search с шириной 5, длинормализованным лог-вероятностным скором и смещением по ключевым словам через Aho-Corasick автомат. Модель поддерживает вывод текста, языка, латентности первого токена и скорости декодирования, а также расширенные опции вроде принудительного указания языка или подсказки ключевых слов. Установка возможна через pip, а готовые бинарники доступны для 17 платформ, включая мобильные устройства, микроконтроллеры и браузер через WASI. Вес модели и исходный код размещены на Hugging Face и GitHub.

Whistle — компактная модель для локальной работы на CPU без зависимостей с низкой задержкой (первый токен за 11 мс), подходящая для встраиваемых устройств и веб-приложений. Основные характеристики и ограничения: * **Точность:** В режиме свободного распознавания точность низкая (70/170 против 168/170 у Qwen). Однако при использовании как детектора шаблонов (обучение сети на сгенерированных фразах) точность возрастает до 164/170. * **Языки и акценты:** Хорошо работает с английским языком и различными акцентами (индийским, хорватским, испанским), превосходя стандартные системы и встроенное распознавание iOS, особенно в технических терминах (ASP.NET, .NET 10.0). Плохо работает с испанским, не поддерживает норвежский, японский и другие языки. * **Технические недостатки:** Отсутствует поддержка потоковой транскрипции в реальном времени. Ограничение длины аудио — до 30 секунд; при обработке длинных файлов модель может зацикливаться на одной фразе (например, «Thank you.»). * **Специфика:** Не подходит для распознавания речи людей с речевыми нарушениями. Альтернативы: * ZWhispr: для локальных систем с 8 ГБ GPU, обеспечивает высокую точность за счет трех SOTA моделей. * Yapsnap: бесплатный вариант для CPU без GPU с поддержкой 10 языков, потоковым режимом, диаризацией и временными метками.

mold 3.0.0 — это первый релиз линкера, переписанного с C++ на Rust, и он позиционируется как drop-in-замена версии 2.42.1. Переписанная версия сохраняет те же параметры командной строки, поддерживает те же архитектуры и выдаёт идентичный вывод, за исключением исправленных ошибок. Производительность линкования осталась на уровне предыдущей версии, а совместимость проверена запуском тестов на всех целевых платформах, сравнением вывода на реальных нагрузках и сборкой всех пакетов Gentoo — регрессий не обнаружено.

Переход на Rust повысил безопасность: теперь при повреждённых входных файлах mold не падает с segmentation fault, а останавливается с паникой благодаря bounds-checked чтению памяти. Изменена система сборки — вместо CMake используется Cargo, требуется Rust 1.95+ и C-компилятор. Сборка выполняется через cargo build --release, установка — ./install-mold.sh с поддержкой PREFIX и DESTDIR. Убрана зависимость от oneTBB, оставлено статическое связывание mimalloc, а системный аллокатор можно включить через --features system-allocator. Тестовый запуск теперь осуществляется через cargo test, а зависимости для тестов устанавливаются скриптом install-test-deps.sh. Среди исправлений — устранение крахов при работе с version script, при совпадении входного и выходного файла, при использовании --gc-sections с --init/--fini, при обработке общих символов разного размера, а также улучшена работа ICF и обработки версионных ссылок в共享 библиотеках. Исправлены архитектурно-специфические ошибки для SH4 и SPARC64. Проект продолжает получать поддержку от спонсоров, включая Cybozu, SAP, Mercedes-Benz и других.

Переход mold на Rust вызывает споры из-за проблем бутстрапа: Rust-инструменты недоступны на ранних этапах сборки дистрибутива, что делает использование mold невозможным без поддержки C-версии mold2 как отдельного форка. Автор mold @rui314 признаёт проблему, но предлагает использовать mold 2.x для бутстрапа, а затем переходить на mold 3 после сборки Rust — как практичный компромисс. Пользователь @lrvick настаивает на необходимости сохранения C-версии для ранних этапов. Советы по решению: - @danudey и @karavelov предлагают использовать LLD для бутстрапа и линковки Rust, так как LLVM уже требуется для сборки Rust, что устраняет дополнительные зависимости. - @Orphis и @rui314 отмечают, что воспроизводимые и герметичные сборки с кэшированием бинарников позволяют использовать последнюю версию mold для сборки следующих версий Rust, минимизируя пересборки. - @mohamedkoubaa предлагает рассмотреть Eurydice как альтернативу для управления цепочками сборки, без уточнения деталей. - @nicce предлагает добавить #[no_mangle] и поддержку extern C в mold 3.0 для ABI-совместимости, но не связывает это с бутстрапом. - @avadodin предлагает использовать сэкономленное время на переписывании mold для создания chibirustc — упрощённого компилятора Rust для быстрой локальной сборки, чтобы решить проблему бутстрапа. Дополнительно: - @rui314 утверждает, что переписывание mold на Rust ускорено AI, называя AI-assisted coding крупнейшим прорывом в производительности за свою карьеру. - @tialaramex опровергает утверждение о транспиляции кода, отмечая, что для транспиляции нужен исходный код на другом языке, чего в случае mold нет. - @sillysaurusx подчёркивает, что Wild — другой быстрый линкер, но ориентирован на инкрементальную линковку, тогда как mold фокусируется на скорости полной линковки. - @BoingBoomTschak отмечает, что Cargo.lock mold содержит ~600 строк против ~2200 у Wild, что снижает поверхность атаки, несмотря на общую зависимость от крейтов в Rust. Все факты и оговорки сохранены, повторы и канцелярит удалены, мысли объединены. Ничего не добавлено. Текст на русском, латиница только в именах и терминах.

Книга «Competitive Programmer’s Handbook» Антти Лааксонена — это практическое руководство по алгоритмам и структурам данных, ориентированное на подготовку к программным соревнованиям. Оно охватывает основные темы: сложность алгоритмов, сортировку, поиск, динамические массивы, множества, словари, итераторы, полный перебор, жадные алгоритмы и динамическое программирование. Особое внимание уделяется реализации на C++ и эффективному написанию кода под ограничениями времени и памяти.

В разделе о сложности алгоритмов объясняются правила оценки времени работы, классы сложности (O, Ω, Θ) и методы оценки эффективности. Приводятся примеры, такие как максимальная сумма подмассива (алгоритм Кадане), демонстрирующие линейные решения. В части про сортировку рассматриваются теоретические основы, реализация в C++ через std::sort и применение бинарного поиска. Описываются структуры данных: векторы, множества (set, multiset), словари (map, multimap), их итераторы и практическое использование.

Раздел о полном переборе включает генерацию подмножеств, перестановок и использование backtracking с эвристиками обрезки поиска. Метод «встреча посередине» представлен как способ снизить экспоненциальную сложность до приемлемой для задач с n ≈ 40. Жадные алгоритмы иллюстрируются на примерах монетной задачи, планирования задач и минимизации сумм, с акцентом на условия, при которых жадность оптимальна. Динамическое программирование раскрывается через классические задачи: монеты, наибольшая возрастающая подпоследовательность, пути в сетке и рюкзак, с акцентом на определение состояний и переходов. В приложении даны ссылки на ключевые исследования и ресурсы, включая работы по алгоритмам Прима, Шарара и Тарьяна, а также полезные платформы вроде USACO и Szkopuł.

Обсуждение подчеркивает, что книга развивает алгоритмическое мышление как «умственную гимнастику», а не как прямой путь к успеху на собеседованиях. Она ценна как справочник по алгоритмам и структурам данных, полезный для понимания CS-основ, включая трейды производительности и паттерны памяти, и помогает преодолеть пробелы в образовании, особенно у тех, кто пришёл из смежных областей. Практика competitive programming улучшает навыки написания кода с меньшим количеством багов, ускоряет реализацию решений и воспринимается как способ «детоксикации» от чрезмерного использования LLM, возвращая глубокое мышление и ощущение личного достижения. Книга Лааксонена считается более глубокой и менее ориентированной на собеседования, чем LeetCode, что привлекает тех, кто ищет истинное понимание, а не подготовку к тестам. Опытные участники советуют не воспринимать её как руководство для собеседований, а как инструмент для долгосрочного роста. Она остаётся актуальной спустя 6 лет после публикации, поскольку фундаментальные алгоритмы и структуры данных не изменились. Задачи с CSES.fi, сопровождающие книгу, структурированы и включают проверку решений, что делает их ценным ресурсом для практики. Книга помогает выявлять «gotchas» в программировании — вопросы памяти, сложности и оптимизации — применимые независимо от языка. Несмотря на рост AI, многие считают, что изучение алгоритмов важно для формирования мощного способа мышления, даже если код пишут модели. Споры: некоторые считают LeetCode нерелевантным фильтром для найма, так как реальная работа редко требует задач в стиле соревнований; другие утверждают, что AI делает ручное кодирование устаревшим, но опыт критически важен для эффективного управления LLM в разработке. Книга более сухая и лаконичная, чем современные учебники, но это её сила — ориентирована на быстрое применение, а не на чтение для удовольствия. Некоторые рекомендуют альтернативы, например «Algorithmic Thinking» Зингаро, как более доступные для новичков, сохраняя плотность материала.

EDG, тридцатилетний фронтенд C++ компилятора, стал открытым исходным кодом 30 сентября 2026 года, перейдя под опеку некоммерческой организации The C++ Alliance. Двигатель и стандарты остались прежними — изменилась только модель stewardship: теперь код доступен на GitHub, финансируется через налогово-вычитаемые пожертвования, а разработка ведётся командой Альянса и сообщества. Continuity — ключевой принцип: это не поворот, а передача заботы тем, кто уже обеспечивал качество EDG десятилетиями.

Работа структурирована по трём трекам в одном репозитории: вклад сообщества (pull request'ы), текущая поддержка от разработчиков Альянса и коллективно финансируемые крупные фичи. Все изменения попадают в основную ветку одновременно — никакого раннего доступа. Процессом руководит Fiscal Sponsorship Committee под председательством Джона Спицера, включающий волонтёров из пользователей EDG. Присоединиться можно через код, обсуждения в Slack или влияние на состав комитета и приоритеты развития. EDG теперь открыт для всех, но остаётся тем же надёжным инструментом, которым пользовалась индустрия тридцать лет.

EDG‐frontend сохраняет ключевые преимущества: совместимость с GCC, Clang и MSVC, эмуляцию их багов и историческую роль в C++. Он был единственной реализацией, поддерживавшей export‐templates (C++98), и участвовал в прототипировании статической рефлексии для C++26. Бывшие пользователи отмечали высокую надёжность — почти не встречали собственных багов компилятора. Компания EDG закрывается, поэтому открытие кода — временное решение для перехода клиентов на Clang (как отметили @jcranmer и @jabl). Лицензия: Apache‐2.0 с исключением LLVM, позволяющая свободное использование даже с GPL‐v2 (@throwaway2037). Код написан на C без стандартной библиотеки C++ и компилируется очень быстро (@dgrunwald, @rurban). Благодаря эмуляции других компиляторов, он может служить базой для трансляции C++ в другие языки (например, Free Pascal), хотя требует доработки. EDG использовался в крупных продуктах: Intellisense Visual C++, компиляторы SGI IRIX, Borland, SN Systems для PlayStation. Открытый репозиторий содержит необычную реализацию Unicode‐FSM — потенциально полезный материал для исследований оптимизации обработки Unicode.

OpenDLSS-NR — это Vulkan-реализация нейросети DLSS 5 Neural Rendering от NVIDIA, бит-в-бит идентичная оригиналу. Она воспроизводит ту же архитектуру: U-Net из 71 блока Swin/Vit-трансформеров с глобальным ViT внизу, работающий в FP8 (E4M3) с FP16 накоплением, используя 141 МБ весов. Это генеративная нейросетевая отрисовка (Neural Rendering), которая не увеличивает разрешение, а улучшает уже отрисованный кадр: добавляет детали из шума, корректирует тон, структуру и кожу под стилем, принимая на вход текущий кадр (LDR-прокси), три канала гауссовского шума, репроецированный предыдущий вывод и пять скалярных условий, выдавая RGB-резидуал и логит временного смешивания. Все промежуточные результаты на 75 границах блоков совпадают с оригиналом байт в байт.

Есть независимый порт в браузере через WebGPU (ports/browser-webgpu/), который воспроизводит те же байты без tensor-ядер и FP8 — чисто на шейдерах. Для запуска нужны собственные веса в указанной структуре каталога. Сборка выполняется через PowerShell-скрипты: установка инструментов, сборка шейдеров и PTX, сборка демо на базе Filament. Демонстрация позволяет выбирать сцены из build\scenes и управлять через view.json. Производительность на RTX 4070 SUPER: от 2.8 мс при 768×768 до 29.3 мс при 3840×2160 (241 диспатч на кадр). Доступны переменные окружения для тонкой настройки: маска цепочки экспертов (DLSS5VK_CHAIN_MASK), порог отложенного слияния GEMM (DLSS5VK_DEFER_MAX), валидация и отладка. Проект лицензирован под MIT, не связан с NVIDIA и не предоставляет веса — пользователь отвечает за их законное получение и использование. Полная документация по сети, нумерации, исполнению и кадровому буферу находится в папке docs/.

OpenDLSS-NR воспроизводит архитектуру DLSS 5 бит-в-бит, но её практическая применимость ограничена высокой вычислительной нагрузкой — даже на флагманских GPU. Производительность сопоставима с оригиналом: на RTX 5060 в 1080p — 9.9 мс, на RTX 5090 в 2160p — 8.2 мс, что делает её непригодной для игр при 60+ FPS без топового железа. DLSS 2 и новее используют универсальную модель, персонализация достигается через настройки интенсивности и маскирование объектов на этапе инференса. Веса модели не включены в репозиторий, вероятно, из-за юридических рисков, несмотря на то, что по закону США они не подлежат авторскому праву как результаты работы нейросети. Документация содержит фактические ошибки, например, ложные утверждения о git-игнорировании файлов, которые на самом деле присутствуют в репозитории. Для практического использования требуется доступ к весам, извлечённым из последней версии DLSS 5 в игре NBA — без них проект неполноценен. Реализация использует одностадийную диффузионную модель в пиксельном пространстве — техническое достижение, несмотря на низкую производительность. Она больше похожа на технический демо-проект, чем на рабочее решение для игр — официально доступна только в одной игре. Архитектура включает 71 блок Swin/ViT-трансформеров, работает в FP8 (E4M3) с FP16 накоплением, соответствует описанию оригинальной модели NVIDIA. Временной путь использует репроецированный предыдущий кадр и логиты смешивания для стабильности — критично для устранения артефактов в динамических сценах. Оригинальный DLSS 5 использует дополнительные данные от движка (LOD, UV-карты), но OpenDLSS-NR, вероятно, обходит это, чтобы работать с существующими хуками без изменений рендерера. DLSS 1 использовал персонализированные модели на игру; с DLSS 2 NVIDIA перешла на универсальные — подтверждено техническими отчётами. Споры: некоторые считают, что LLM могли сгенерировать код и документацию, снижая доверие; другие утверждают, что если код работает — это не важно, кто его написал. Также обсуждается, использует ли сеть z-буфер: объясняют, что глубина уже закодирована в RGB-каналах, а добавление z-буфера увеличивает пропускную способность без значимой выгоды. NVIDIA не поддерживает открытые реализации CUDA; несмотря на позиционирование как сторонник open source, её интересы ограничены областями, где она сохраняет контроль. Создание OpenDLSS-NR требует глубокого понимания нейросетевых архитектур и может быть выполнено с помощью современных LLM, что снижает барьер для реверс-инжиниринга закрытых систем.

GPT–6 Astra самостоятельно взломала немецкое армейское шифрование Enigma сообщение MVUEH от 10 июля 1941 года, которое оставалось неразгаданным с 2005 года. Сообщение, длиной 82 буквы, было зашифровано с использованием уникального ключа: порядок роторов 253 (в отличие от 512 у других сообщений того дня), отличающиеся соединения штекерной панели и положения кольц. Расшифрованный текст почти идентичен тексту сообщения SIPVX (Nr. 173), отличаясь лишь из-за ошибки при шифровании слова «Bitte» (получилось «Btte») и повторения подписи «Waschbusch» в SIPVX. Ключевым фактором стало обнаружение оборота левого ротора на 72-й букве — редкое явление, усложняющее криптоанализ, а также ошибки в транскрипции шифротекста из исходного документа.

Для взлома GPT–6 Astra использовала клич «ROSENOW ROSENOW» (повторяющееся название места), разработала собственные эмуляторы Enigma на Python и C++, а также реализовала алгоритм типа Bombe для перебора ключей. Помимо криптоанализа, ИИ проявила навыки архивного исследователя: в её логах обнаружены ссылки на конкретные фонды Bundesarchiv (RS 3–3/20a и RS 3–3/63b), связанные с коллекцией радиосообщений подразделения Nachschubführer SS-Totenkopf, что указывает на самостоятельный поиск и анализ первоисточников. Хотя доступ к этим файлам на сайте Crypto Cellar Research отсутствует, точность ссылок и глубина проработки свидетельствуют о высоком уровне автономной работы. Как отметил автор, достижение, которое заняло бы у человека недели или месяцы, было выполнено за два дня.

Обсуждение подчеркивает, что успех Astra связан не с автономным мышлением, а с использованием существующих симуляторов Enigma, человеческим вовлечением и ошибками в исходных данных, что ставит под сомнение преувеличенные заявления о самостоятельном взломе. Tantalor указывает, что разработка Python/C++ симулятора Enigma — не новация, а широко доступный код, и вопрос о реальном вкладе Astra остается открытым. Nexawave-ai и partiallypro задают вопрос о применимости метода к нерасшифрованным шифрам Зодиака, ставя под сомнение уникальность достижения и указывая на потенциальную универсальность подхода. 125ah утверждает, что Astra не изобрела новый метод, а использовала открытые исходники симуляторов Enigma и Bombes, обученные на больших данных, делая успех результатом финансовой мощи, а не интеллекта модели. Trixn86 критикует отсутствие прозрачности: без публикации промптов, промежуточных шагов и истории взаимодействия утверждение о взломе выглядит необоснованным, возможно, основанным на простом запуске готовых инструментов. Ck2 предлагает проверить, сможет ли ИИ, обученный только до 1903 года, прийти к E=mc2, чтобы отличить истинное творчество от статистического подбора — ставя под сомнение способность LLM к оригинальному научному открытию. Threethirtytwo отвергает достижение как «стохастическое пародирование», утверждая, что модель воспроизводит шаблоны из обучающих данных, а не решает задачу с пониманием. Jtrn и podgorniy подтверждают, что ключ к успеху — человеческий вклад: исследователь Leffer определил редкую особенность ключа (переворот левого ротора на 72-й букве), что позволило Astra сузить пространство поиска. Mmsc и podgorniy приводят точный расшифрованный текст и объясняют типичные ошибки операторов (BTTE→BITTE, WASCHBBSCH→WASCHBUSCH, X как разделитель), подтверждая реалистичность результата и контекстную осведомленность модели. Podgorniy демонстрирует воспроизводимость: Gemini 3.8 Flash расшифровал сообщение за 45 минут без ручной настройки, указывая, что задача доступна современным LLM при правильном промпте. Ricksunny интересуется, как Astra проверяла, что текст — немецкий, поскольку стандартные методы криптоанализа неочевидны для неспециалистов — ключевой элемент для оценки надежности. Sophira задает вопрос: возможно ли, что ключ неверен, но результат выглядит правдоподобно — поднимая проблему ложных срабатываний при использовании LLM для криптоанализа без строгой верификации. BubbleRings выражает тревогу по поводу упоминания «частной коллекции» в статье, предполагая, что Astra могла получить доступ к неопубликованным данным, что ставит под сомнение этичность и прозрачность метода.

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

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

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

onboardapi — это библиотека и middleware для надёжного обмена данными между сенсорными системами и программными компонентами. Она основана на стандарте DDS (Data Distribution Service) от OMG и использует ddkit SDK, обеспечивая низкую задержку и высокую надёжность в сложных аппаратно-программных средах. Благодаря DDS XTypes и XCDR2 кодированию библиотека сохраняет обратную совместимость, позволяя разным версиям ПО взаимодействовать даже при эволюции данных модели.

API написан на C++, но поддерживает мультиязычную интеграцию через обёртки для Java, C#/.NET и Python. Документация включает концепции клиент-сервисной архитектуры, примеры реализации на всех поддерживаемых языках, инструкции по конфигурации, описание интерфейсов и модели данных, а также журнал изменений. Лицензирование разделено: описания интерфейсов распространяются под EPL v2.0, а runtime-библиотеки — под проприetary EULA-RME-SDK-1.0 от Rheinmetall. Это делает onboardapi подходящим для промышленных и defence-приложений, где критичны совместимость, производительность и долгосрочная поддержка.

DDS считается тяжёлым для встраиваемых систем, но существуют лёгкие реализации с пулами памяти и альтернативные протоколы (Zenoh, UDP). Публикация только документации, а не кода, упрощает экспортный контроль (ITAR) и является типичным подходом в оборонных проектах. Есть разногласия: одни утверждают, что Rheinmetall открыла исходники, другие указывают, что на GitHub доступны только документы — код не опубликован. Качество кода вызывает вопросы: в примерах использован std::endl, что снижает производительность; рекомендуется заменить на '\n'. Библиотека соотносится с существующими военными стандартами (TMS, DIS, HLA, OMS, GVA) и ROS 2 — подобные решения давно применяются в обороне. Безопасность не должна зависеть от скрытности кода; открытая спецификация позволяет большему числу специалистов проверять её на уязвимости. Открытые протоколы для военной техники (например, MAVLink) существуют более десяти лет, поэтому новизны решения сомнительна.

Lore — это новый открытый контроль версий, созданный Epic Games для масштабных игровых и развлекательных проектов, где код сочетается с большими бинарными артефактами. Он хранит данные по контент‑хешу в Merkle‑дереве, формируя неизменяемую цепочку ревизий, что обеспечивает проверку целостности и повторное использование кода. Файлы разбиваются на переиспользуемые куски, а рабочие пространства могут подгружать данные только по требованию, делая систему лёгкой в начале и готовой к росту без дублирования.

Запуск занимает минуты в локальном режиме, а затем система масштабируется за счёт кэшируемого центрального сервиса и сжатой передачи данных. Свободные ветки позволяют быстро создавать, управлять и синхронизировать их, а CLI даёт полный доступ к всем функциям. Поддерживаются SDK на C/C++, C#, Rust, Go, Python и JavaScript, а лицензия MIT делает проект полностью открытым. Epic позиционирует Lore как основу для совместного развития открытого экосистемного контроля версий, приглашая разработчиков присоединиться к сообществу через GitHub и Discord. История репозитория проверяется криптографически, а лёгкие ветки ускоряют переключение без дублирования данных. Система обеспечивает сжатие и дедупликацию, экономя место даже при частых изменениях больших файлов.

• Lore — новый VCS от Epic, ориентированный на игровую разработку и работу с большими бинарными артефактами, позиционируется как конкурент Perforce.
• Использует Rust, открытый исходный код, предлагает «полную» API и интеграцию с Unreal Engine, но пока документация написана LLM‑ом и содержит стилистические несоответствия.
• Планируется поддержка локального/отдельного режима без сервера, но текущая реализация требует удалённого хранилища и GUI‑клиента пока не реализован.
• Обсуждаются вопросы масштабируемости, локального использования для личных проектов и потенциального применения в ML/AI‑проектах, а также сравнение с существующими решениями вроде PlasticSCM и XetHub.

Новый алгоритм преобразования дней с эпохи 1970-01-01 в дату (год, месяц, день) для 64-бит UNIX-времени работает на 30–40% быстрее предыдущего лидера (Neri-Schneider 2021) и в 2.4 раза быстрее Boost (2012). Он охватывает ±1.89 трлн лет, использует всего 4 умножения (вместо 7+), и оптимизирован для x64/ARM. Бенчмарки на Intel x64 и Apple M4 Pro: ~27 циклов (4M + 15B) против 40 и 51 у предшественников.

Ключевые идеи: подсчёт лет назад (rev = D_SHIFT - days) убирает промежуточные шаги; пропуск day-of-year с year-modulus-bitshift (yrs % 4 * 512 + shift - ypt) вместо деления; Julian Map (cen = (rev * C1) >> 64; jul = rev + cen - cen/4) ускоряет правила високосных 100/400 лет, экономя 2 умножения. Псевдокод: корректировка эпохи, 4 красных умножения (C1/C2/C3/782432), зелёные "бесплатные" на x64 (shift/LEA), выход day/month/year с bump для янв/фев. Код на C++ — open source (BSL-1.0).

• Новый алгоритм конвертации дат в григорианский календарь даёт 30–40% прирост скорости за счёт обратного подсчёта лет и снижения умножений (4 вместо 7+).
• Сравнения с ClickHouse (таблицы поиска), Windows-эпохой (1601) и Unix-временем (без учёта високосных секунд); упоминания исторических календарей с 1 марта как началом года.
• Обсуждение оптимизаций (128-битные числа, constexpr, asm), долгосрочной точности (±1,89 трлн лет) и влияния приливного трения на будущие расчёты.
• Похвалы за подробный write-up, literate programming и open-source C++ код; предложения для наносекунд и микроконтроллеров.

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

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

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

Knokke представляет собой новый высокоскоростной сканер 35 мм пленки, который позиционируется как "новая эра сканирования". Устройство предлагает впечатляющие характеристики: разрешение 4064 DPI, динамический диапазон 120 дБ и глубину цвета 48 бит, при этом способно отсканировать всю катушку всего за несколько минут. Сканирование происходит с помощью кастомной оптики и современного сенсора, что обеспечивает высочайшее качество при доступной цене.

Сканер работает на собственном программном обеспечении Korova — легком приложении на C++, нативном для Linux, macOS и Windows. Это позволяет отказаться от устаревших ПК и использовать современный plug-and-workflow. Каждому кадру можно задать индивидуальные настройки, которые повторяются при последующих сканированиях для консистентных результатов. Цена запуска составит €999, включая и сканер, и программное обеспечение.

• Стоимость сканера Knokke составляет €999, что вызывает сравнение с ценой на подержанные DSLR-установки и вызывает обсуждение ценообразования.
• Отсутствие примеров сканов и отсутствие ИК-сенсора для удаления пыли и царапин вызывает критику.
• Обсуждается, что цена может быть оправдана для энтузиастов, которые ценят дизайн и удобство использования.
• Некоторые участники обсуждения выражают сожаление, что сканер не поддерживает 120 формат, а также отсутствие автоподатчика.
• Участники также обсуждают, что стоимость может быть оправдана для тех, кто ищет высокое качество сканирования и готов заплатить за него.

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

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

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

В 2025 году SIMD в Rust продолжает развиваться, предлагая значительный прирост производительности до 64x для операций с u8 на современных процессорах. Основная проблема - фрагментация наборов инструкций: ARM использует обязательный NEON (128 бит), WebAssembly - 128-bit packed SIMD, а x86 имеет сложную иерархию от SSE2 до AVX-512 (512 бит). Для x86 разработчики выбирают между указанием target-cpu (например, x86-64-v3) и использованием function multiversioning для поддержки различных процессоров.

В Rust существует четыре подхода к SIMD: автоматическая векторизация (самый простой), продвинутые итераторы, портируемые абстракции и сырые интринсики. В то время как ARM стандартизировал NEON, а WebAssembly требует компиляции двух бинарных файлов, x86 остается самой сложной платформой из-за множества расширений и необходимости обеспечения обратной совместимости.

• Обсуждение показало, что Rust пока не может предложить стабильный и удобный способ работы с SIMD, в отличие от C# и C++.
• Основная причина — std::simd всё ещё в nightly, а стабильная альтернатива отсутствует.
• Участники также отметили, что даже в ночной ветке API нестабилен и может измениться, что делает его использование в production-окружениях проблематичным.
• Некоторые участники выразили обеспокоенность тем, что отсутствие стабильной SIMD-поддержки может отпугнуть потенциальных пользователей Rust, особенно в областях, где эффективное использование SIMD критично.
• В то же время, другие участники подчеркнули, что Rust всё ещё молодой язык и что сообщество может в конце концов решить эту проблему, как это было с другими функциями в прошлом.

Автор изначально не интересовался Zig, считая его нишевым языком для аудиопрограмм, но решил переписать индекс AcoustID на Zig как возможность изучить новый язык. Результат превзошёл ожидания — новая версия оказалась быстрее и масштабируемее, чем предыдущая на C++. Однако при добавлении серверного интерфейса возникли сложности с сетевыми возможностями Zig, что привело автора к созданию библиотеки Zio — асинхронной I/O и библиотеки для конкурентности в стиле Go.

Zio реализует стековые корутины с фиксированным размером стека, поддерживает асинхронную сетевую и файловую I/O, примитивы синхронизации и каналы в стиле Go. Главная особенность — контекстный переключение практически бесплатен, сравним с вызовом функции. В однопоточном режиме Zio обгоняет все протестированные фреймворки, включая Go и Rust Tokio. Интересно, что благодаря стандартным интерфейсам reader/writer, внешние библиотеки могут использоваться без модификаций, даже не зная, что работают внутри Zio.

• Обсуждение показало, что Zig не имеет встроенной поддержки async/await, а вместо этого используется библиотечный код, что вызывает вопросы о том, как это скажется на производительности и удобстве использования.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.
• Участники обсуждения также отметили, что в отличии от Go, где стек горутин растет по мере необходимости, в Zig фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.

Статья представляет собой воображаемый список курсов компьютерных наук, которых не существует, но должны. Автор предлагает такие курсы, как "Отказ от объектно-ориентированного программирования", где студенты изучат переменные вне иерархии объектов и "функции", а также "Классические исследования программного обеспечения", посвященные исторически значимым продуктам вроде VisiCalc и Zork. Особый интерес представляет курс "Написание быстрого кода на медленных языках", где учат писать на Python, который по производительности может превзойти C++, и "Пользовательский опыт командной строки", анализирующий принципы UX для консольных программ.

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

• Обсуждение показало, что академическая программа CS часто не охватывает такие темы, как история ПО, философия вычислений, практика командной работы и даже базовые навыки работы в консоли.
• Участники подчеркнули, что курсы вроде "Unlearning OOP" и "Classical Software Studies" должны быть обязательной частью образования, но их нет.
• Обсуждение подняло вопрос о том, что не хватает курсов по фундаментальным навыкам, таким как CI/CD, системное администрирование и работа с консолью.
• Было отмечено, что студенты часто не получают практических навыков, необходимых для работы в отрасли, и что курсы по таким темам как "как писать быстрый код на медленных языках" или "как не страдать от внутренних конфликтов в команде" отсутствуют.
• В конце концов, обсуждение подтолкнуло к тому, что вместо того, чтобы учить студентов тому, как создавать и поддерживать сложные системы, которые уже работают, они вместо этого вынуждены изучать фреймворки, которые могут исчезнуть через 5 лет.

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

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

Проект Gamedev Guide обновил раздел о современных инструментах Linux для разработчиков. Основное внимание уделено оптимизации рабочего процесса: авторы рекомендуют использовать Docker для изоляции окружений, что ускоряет сборку и тестирование. Особо отмечена интеграция с Windows Subsystem for Linux (WSL2) для кросс-платформенной разработки, а также инструменты вроде Ninja для ускоренной компиляции C++ проектов. В статье приводятся примеры настройки CI/CD пайплайнов под Linux, что особенно полезно для крупных команд. Авторы подчеркивают, что современный Linux уже не уступает в инструментах для разработки под Windows, а в чём-то даже превосходит.

• Обсуждение в основном вращается вокруг того, что «современные» инструменты не всегда объективно лучше, а скорее улучшают UX и визуально оформляют вывод, и что важнее уметь пользоваться базовыми утилитами, чем полагаться на специфические инструменты, которые могут не оказаться в других окружениях.
• Участники обсуждают, что важно знать и уметь использовать базовые инструменты, такие как find, grep, sed, awk, vi, ed, less, tail, head, tar, ls, cat, dd, top, ps, kill, df, du, free, uptime, w, who, last, ls, df, mount, umount, fdisk, lsblk, blkid, lsusb, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsomod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsmod, lsomod, lsmod, lsmod, lsmod, lsmod, lsomod, lsmod, lsmod, lsmod, lsmod, lsomod, lsmod, lsmod, lsomod, lsmod, lsmod, lsomod, lsmod, lsomod, lsmod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, lsomod, `

KDE Connect — это проект, обеспечивающий интеграцию между настольными компьютерами KDE и мобильными устройствами. Позволяет передавать файлы, SMS, уведомления и управлять устройствами через безопасное соединение. Поддерживается на Linux, Windows, Android, iOS и macOS, что делает его универсальным решением для кроссплатформенной интеграции.

Проект включает в себя как C++ приложение для десктопа, так и мобильные приложения. Для разработки доступны исходные коды, а также инструменты для создания плазмоидов и мобильных QML-приложений. Поддерживается выпуск через различные магазины приложений, включая Google Play, Apple App Store, Windows Store и F-Droid.

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

• KDE Connect и его аналоги (GSConnect, GSConnect) обеспечивают бесшовную связь между устройствами, но сталкиваются с проблемами, такими как несовместимость с различными сетевыми конфигурациями и отсутствие официальной поддержки для iOS.
• Пользователи отмечают, что KDE Connect может быть установлен на различных ОС, включая Linux, Windows и Android, но не на iOS.
• Некоторые пользователи сообщают о проблемах с обнаружением устройств в сети, что может быть связано с настройками фаервола или маршрутизатора.
• Обсуждается, что KDE Connect может быть использован для передачи файлов, управления мультимедиа и других функций, но иногда эти функции могут не работать из-за проблем с подключением.
• Пользователи также обсуждают, что KDE Connect может быть использован для обмена буфером обмена между устройствами, но иногда это может не работать из-за проблем с подключением.

VALORANT изначально требовал серверы с частотой 128 тиков для минимизации преимущества атакующего и обеспечения честного геймплея, где защитники успевают реагировать. Это означало обработку кадра каждые 7,8125 мс, но изначально сервер тратил 50 мс на кадр, что делало задачу масштабирования неподъёмной из-за высоких затрат на CPU.

Команда разбила проблему на категории: репликация, сеть, анимация, движение и другие, внедрив систему ValSubsystemTelemetry для точного измерения времени выполнения кода. Используя внутреннюю аналитическую платформу Riot, инженеры визуализировали данные и последовательно оптимизировали код, железо и настройки ОС, достигнув цели в 2,34 мс на кадр и обеспечив бесплатные 128-тиковые серверы для всех игроков.

• Обсуждается высокая частота обновления (128 тиков/секунда) серверов Valorant в сравнении с другими играми (Factorio 60, Minecraft 20, CS:GO 64, Fortnite 30).
• Поднимается вопрос архитектурных решений и оптимизаций для достижения низкой задержки (<35 мс), включая выбор процессоров Intel Xeon и отключение анимации в фазе покупки.
• Критикуется система "sub-tick" в CS2 как менее эффективная по сравнению с классическим высоким тикрейтом, а также современный matchmaking, не учитывающий пинг.
• Упоминается, что для некоторых жанров (например, Runescape) достаточно низкого тикрейта (0.6 в секунду), и это определяет геймплей.
• Обсуждаются технические сложности реализации высокопроизводительных серверов на языках с GC (Erlang, Elixir) и предпочтение C++ для симуляции игры.

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

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

• OpenZL использует SDDL для описания структуры данных, что позволяет применять специализированные методы сжатия, значительно улучшая компрессию по сравнению с общими алгоритмами (zstd, xz).
• Инструмент эффективен для структурированных и колоночных форматов (Parquet, CSV), но требует описания формата данных через SDDL, C++ или Python код.
• Поддерживает сжатие без потерь, гарантирует точное восстановление данных, планирует добавление потоковой обработки и работы с чанками.
• Вызывает интерес для сжатия геномных данных, JSON (после преобразования), логов и других структурных форматов, но не оптимален для случайных текстовых файлов.
• Реализация включает открытый код (BSD-3-Clause), документацию и white paper; активно развивается, включая будущую поддержку языковых привязок (Python, .NET).

Современный Fortran может быть предпочтительнее Python для обучения основам численной линейной алгебры из-за строгой типизации и явного управления памятью, что помогает студентам лучше понять внутреннюю работу алгоритмов. В Python студенты часто полагаются на готовые функции вроде np.linalg.solve, что скрывает детали реализации и приводит к ошибкам, связанным с динамической типизацией и неправильной индексацией массивов. Например, путаница между списками и массивами NumPy или неявное приведение типов могут затруднить отладку.

Fortran, напротив, требует чёткого объявления переменных и размеров массивов, что снижает риски ошибок и заставляет студентов продумывать структуру данных. Это особенно важно для таких задач, как метод Гаусса-Зейделя или метод наименьших квадратов, где понимание циклов и операций с матрицами критично. Хотя Python с его экосистемой удобен для сложных проектов, Fortran обеспечивает более прозрачный переход от математических формул к коду, укрепляя фундаментальные навыки.

• Обсуждается выбор языка для преподавания численных методов и линейной алгебры (Python, Fortran, Julia, C++ и др.), где Fortran хвалят за производительность и удобство для математики, а Python — за распространённость и простоту.
• Критикуется чрезмерно объектно-ориентированный подход в C++ для научных вычислений, а также сложности и "бородатость" некоторых языков (например, Fortran) для новичков.
• Поднимается вопрос о важности баланса между теоретической "чистотой" языка и его практической полезностью для будущей работы студентов.
• Отмечаются преимущества Julia и MATLAB/Octave для обучения благодаря близости их синтаксиса к математической нотации и удобным инструментам.
• Упоминаются проблемы с ошибками в Python (например, типизация и сообщения об ошибках), а также сложности отладки в сравнении с другими языками.

Cloudflare объявляет о спонсорской поддержке двух независимых open-source проектов — браузера Ladybird и дистрибутива Omarchy на базе Arch Linux для разработчиков. Это часть стратегии по укреплению открытого интернета через разнообразие инструментов. Ladybird — амбициозная попытка создать браузер с нуля, включая собственные движки рендеринга (LibWeb) и JavaScript (LibJS), что контрастирует с доминированием Chromium, используемого 65% пользователей. Такой подход стимулирует инновации в безопасности и производительности, а также выявляет недочёты в веб-стандартах.

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

• Обсуждение спонсорства Cloudflare проектов Ladybird и Omarchy с акцентом на возможные скрытые мотивы компании, включая движение к вебу только для одобренных браузеров.
• Скептицизм относительно практической ценности Omarchy как ещё одного дистрибутива Linux и его сравнение с другими установщиками и системами, такими как Nix или Alpine.
• Вопросы о целесообразности создания нового браузерного движка (Ladybird) на C++ вместо более безопасных языков и сомнения в его способности конкурировать с существующими гигантами.
• Обсуждение личности DHH (создателя Omarchy) и его спорных высказываний, а также того, должно ли это влиять на поддержку его проектов.
• Поднята тема стратегического интереса Cloudflare к децентрализации веба и уменьшения зависимости от Google, аналогичного стратегии Valve с Proton.

В защиту C++

Почему C++ остаётся мощным и актуальным языком программирования в современном технологическом ландшафте.

Репутация C++

C++ часто критикуют за сложность, крутую кривую обучения и способность позволить разработчикам не просто выстрелить себе в ногу, но и оторвать всю ногу. Но выдерживают ли эти критики проверку?

В этом посте я постараюсь разобрать некоторые распространённые критические замечания и представить сбалансированный взгляд на сильные и слабые стороны языка.

C++ «сложен»

C++ действительно сложный язык с огромным набором возможностей. Для любой задачи есть дюжина способов её решения, каждый со своими компромиссами. Но нужно ли глубокое понимание языка, чтобы выбрать правильный подход?

Не совсем. Преждевременная оптимизация — корень всех зол. В C++ можно писать прекрасный код, не беспокоясь о сложных функциях языка. Можно создавать простой, читаемый и поддерживаемый код без шаблонов, перегрузки операторов и других продвинутых возможностей.

Не стоит зацикливаться на «лучшем» подходе — лучше сосредоточьтесь на написании понятного кода. Если он читаем, всё будет в порядке.

C++ «устарел»

C++ очень стар — он вышел в 1985 году. Но означает ли это, что он устарел?

Ни в коем случае. C++ активно развивается уже более 40 лет. Последняя версия стандарта, C++20, добавила множество новых функций, а C++23 расширил возможности стандартной библиотеки, концепций, диапазонов и сопрограмм, делая язык более мощным и выразительным.

C++ остаётся одним из самых widely используемых языков с огромной экосистемой библиотек и инструментов. Он применяется в играх, высокопроизводительных вычислениях и embedded-системах. Многие популярные приложения написаны на C++.

Язык не устарел — чтобы утверждать обратное, придётся сильно извратить определение «устаревшего».

C++ «небезопасен»

А вот и главный аргумент. Да, я сравню с Rust, поскольку его часто называют «безопасным» языком, который должен заменить C++.

Переписывание кодовых баз C++ на Rust всегда даёт более безопасные результаты.

Многие компании сообщают об улучшении безопасности и уменьшении количества ошибок после перехода на Rust.

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

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

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

• C++ и C полагаются на навыки и дисциплину разработчиков вместо автоматических проверок безопасности, что часто приводит к уязвимостям в больших проектах.
• Сложность C++ считается чрезмерной и архаичной, многие функции языка (шаблоны, перегрузка операторов) сложны для понимания и неизбежны в реальных проектах.
• Безопасность памяти в C++ проблематична даже для опытных разработчиков, в отличие от языков с автоматической проверкой, таких как Rust.
• Идиоматичный C++ сильно отличается от C, и попытки писать на C++ «как на C» противоречат современным практикам и стандартам.
• Переписывание кода с C++ на Rust часто повышает безопасность и удобство сопровождения, но обратный процесс сложнее и рискованнее.
• C++ останется важным языком из-за его распространённости в legacy-системах и критичных к производительности областях.
• Инструменты и экосистема C++ (пакетные менеджеры, форматтеры) часто считаются устаревшими по сравнению с современными языками.

Safe C++ больше не развивается.
Год назад появился черновик, обещавший «ржавую» безопасность без ломки старого кода: память, типы, потоки — всё через явный safe-контекст. Комитету идея не зашла: модель Rust назвали чуждой, голоса отдали Profiles — набору ограничений на уже существующий C++, которые на этапе компиляции блокируют UAF, data-race, deadlock, утечки.

Profiles не добавляют синтаксиса, только запрещают опасные паттерны; включаются опцией, обратно совместимы. Safe C++ требовал новых квалификаторов и заимствовал проверки времени жизни — слишком радикально.

Автор Safe C++, Шон Бакстер, признал:

Дальнейшая работа бесполезна; все силы — в Profiles.

Вывод: Profiles слабее, но реалистичнее; ждём их в C++26.

• Комитет C++ фактически отверг Safe C++ и ограничился «Profiles» — набором флагов, запрещающих часть небезопасных конструкций.
• Участники сходятся: главная проблема не техническая, а культурная — сообщество не хочет ограничений, считая «если код работает — значит, он безопасен».
• Profiles критикуют за примитивность: они не решают temporal safety, не выражают лифтаймы и не требуют изменения синтаксиса, поэтому дают лишь иллюзию защиты.
• Большинство считает, что без полного отказа от C-подобного подмножества и без внедрения lifetimes C++ никогда не станет «безопасным»; проще перейти на Rust.
• Практический вывод: крупные проекты продолжат игнорировать Profiles, а новые кодовые базы будут выбирать Rust либо двухъязычный подход «C++26 + внешние анализаторы».

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-переписей.

Краткий обзор проблемы C++ модулей

1. Главное требование
   Если модули не ускоряют сборку минимум в 5 раз (желательно 10×) на реальных проектах, их нужно удалить из стандарта. Все остальные плюсы не стоят вложенных ресурсов.

2. Что обещали vs. что получили

   • Изначально: «уберём O(N²) из-за заголовков, компиляция станет мгновенной».
   • Сейчас: упор сместился на «изоляцию сборки» (макросы, пространства имён). Это полезно, но редко встречается и не решает главную боль — медленную сборку каждый день.

3. Почему всё так плохо

   • Модули приняли в C++20, несмотря на предупреждения о невозможности реализации.
   • Реализация заняла >5 лет и всё ещё не готова.
   • Стандарт не описывает, как именно компилятор и сборочная система должны взаимодействовать: имена файлов, каталоги, зависимости — всё на совести разработчиков.
   • Компиляторные команды отказываются «превращаться в систему сборки» и блокируют любые предложения.

4. Итог
   Проект превратился в «интеграционный ад». Пока нет массовых 5-10-кратных ускорений, дальнейшие инвестиции — просто затягивание «затратной ямы».

• Участники сетуют: вместо простого «import = include без утечек контекста» получили громоздкий механизм, который мало кто использует.
• Старые пре-компил-хедеры 90-х и сторонние решения вроде zapcc уже давали 5× ускорение, но были проигнорированы стандартом.
• Модули обещали избавить от forward-declaration и макро-ifdef, но на практике вызывают лавину пересборок и несовместимы с большим объёмом существующего кода.
• Многие считают, что модули заточены под «большой тех» с кэшированными билдами, а малый бизнес и хобби-проекты «попали в пролёт».
• Итоговое настроение: «убейте модули, C++ всё сломали», «мир ушёл в Rust», но «на C++ всё ещё держится пол-мира, так что просто так не выкинешь».

grok-code-fast-1 — новая модель xAI для агентного кодинга: быстрая, дешевая, заточена под ежедневную работу.

• Скорость: архитектура с нуля, оптимизация инференса, кеш >90 %. Десятки вызовов инструментов до того, как вы прочтёте первую строку мыслей.
• Цена: 0,20 $/1 M входных, 1,50 $/1 M выходных, 0,02 $/1 M кешированных токенов.
• Языки: TypeScript, Python, Java, Rust, C++, Go.
• Инструменты: grep, терминал, редактирование файлов — «родная» работа в IDE.
• Партнёры: временно бесплатно в Cursor, GitHub Copilot, Cline, Roo Code, Kilo Code, opencode, Windsurf.

Производительность

• 190 токенов/сек, SWE-Bench-Verified 70,8 %.
• Оценки реальными разработчиками: быстро и надёжно для рутинных задач.

• Кто-то хвалит grok-code-fast-1 за скорость и качество, сравнивая с gpt-5-mini, другие считают «быстро, но тупо».
• Основная критика: упор на скорость вместо качества, неточные или вредные изменения кода, сомнительные внутренние бенчмарки.
• Несколько человек жалуются, что модель случайно удаляет код и скрывает кнопки «стоп».
• Подняты этические и экологические вопросы: нелегальные газовые турбины и «обученный нацистский бот».
• Часть пользователей просто рада быстрой бесплатной модели в Cursor/VS Code для простых задач.

Без futex всё тленно

Книга The Art of Multiprocessor Programming (2-е изд., 2021) считается канонической, но она обходит стороной futex — ключевой примитив современной многопоточности. Это упущение делает пособие бесполезным для практиков.

Futex ≠ mutex
Название происходит от «fast userspace mutex», но futex — это не мьютекс, а основа для всех высокоэффективных примитивов синхронизации. До него всё строилось на громоздких System V IPC, которые не масштабировались: при 1000 потоков futex в 2002-м оказался в 20–120 раз быстрее sysv-блокировок. Windows и macOS добавили аналоги только в 2012 и 2016 гг.

Суть futex
Он разделяет блокировку и ожидание/пробуждение:

• В user-space проверяем состояние; если свободно — захватываем без системного вызова.
• При конфликте вызываем futex_wait(addr, expected), засыпаем в ядре на конкретном адресе.
• Пробуждение — futex_wake(addr, n), где n обычно 1 или «все».

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

Такой подход убирает лишние системные вызовы и позволяет строить быстрые мьютексы, rw-lock’и, семафоры и пр. без поллинга и экспоненциальных бэкоффов.

Итог
Любая современная библиотека (pthreads, C++ std::mutex, Rust std::sync) опирается на futex. Учебник, игнорирующий этот примитив, не готовит к реальной разработке.

• Futex — это быстрый примитив синхронизации, который экономит системные вызовы при отсутствии конфликтов и не требует выделения ядром объектов.
• В отличие от Benaphore и старых SysV-механизмов, futex не требует предварительной инициализации в ядре и исчезает, когда нет ожидающих.
• Обсуждение подчёркивает, что современные учебники по многопроцессорному программированию обязаны упоминать futex, но «The Art of Multiprocessor Programming» этому не уделяет внимания.
• Улучшения futex2 (Linux ≥5.16) добавили NUMA-поддержку и аналог Windows WaitForMultipleObjects, а io_uring теперь умеет работать с futex.
• Для надёжности при падении потока существуют robust-locks и списки futex, которые ядро автоматически разблокирует.

Я написал 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, завари кофе».