Hacker News Digest

Larian Studios выпустила нативную версию Baldur's Gate 3 для Steam Deck, которая работает без слоя совместимости Proton. Это снижает нагрузку на процессор и потребление памяти, улучшая производительность. Игроки могут проверить установку через настройки Steam, выбрав инструмент совместимости с Linux Runtime.

Сохранения в нативной версии хранятся в папке /home/deck/.local/share/Larian Studios/, а не в compatdata. Steam Cloud автоматически синхронизирует последние сейвы, но старые можно перенести вручную через режим рабочего стола. Larian подчёркивает, что поддержка Linux ограничена только Steam Deck.

• Обсуждается выпуск нативной версии Baldur's Gate 3 для Steam Deck, отмечаются усилия Larian и улучшение производительности (~10% FPS в Act 3) по сравнению с версией на Proton.
• Поднимаются вопросы о термине "нативная" версия: означает ли она Linux-бинарник, оптимизацию под железо Steam Deck или просто правильную конфигурацию, а также о возможности её запуска на других Linux-дистрибутивах.
• Участники делятся личным опытом игры на Steam Deck: одни хвалят работу через Proton, другие сталкивались с проблемами производительности и теперь рады нативному релизу.
• Критикуется позиция Larian о непредоставлении поддержки для платформы Linux в целом, при этом выпуске сборки под конкретное устройство (Steam Deck) на Arch Linux.
• Затрагиваются смежные темы: проблемы с производительностью старого железа, сравнение с другими играми, баги в процессе обновления через Steam на Linux.

Разработан модуль Meshtastic 64, превращающий Commodore 64 в узел децентрализованной mesh-сети для текстовой связи. Устройство подключается через User Port и использует плату Heltec LoRa V3 с OLED-экраном, который виден через прозрачное окно картриджа. Для упрощения связи вместо сложных protobuf-команд применён текстовый режим.

Программа для отправки и приёма сообщений написана на BASIC для сохранения ретро-стиля и удобства разработки. Плата спроектирована с учётом размещения аккумулятора и доступного USB-C порта, хотя в первой версии допущена ошибка зеркальной разводки контактов. Проект демонстрирует, как винтажный компьютер может участвовать в современных peer-to-peer сетях.

• Высказана озабоченность отсутствием серьёзных попыток защитить содержимое сообщений на прикладном уровне в Meshtastic.
• Отмечены проблемы с маршрутизацией и доставкой сообщений, а также отсутствие функционала безопасной буферизации (store & forward).
• Упомянуты альтернативные проекты (Reticulum, MeshCore, CellSol) и проведены сравнения с APRS.
• Сообщество критикуется за большее увлечение обсуждением оборудования, чем практическим использованием сети.
• Разработчики проекта обвиняются в токсичности и имитации бизнеса под видом open-source.

Python сохраняет лидерство благодаря своей универсальности в машинном обучении и веб-разработке, а JavaScript остаётся незаменимым для фронтенда. Rust продолжает расти из-за акцента на безопасность и производительность, особенно в системном программировании. Go набирает популярность в облачных сервисах и микросервисной архитектуре благодаря простоте и эффективной параллельной обработке.

Стоит отметить рост TypeScript как более строгой альтернативы JavaScript, а также стабильное присутствие Java в корпоративных приложениях. Интерес к Julia увеличивается в научных вычислениях, а Kotlin укрепляет позиции в мобильной разработке под Android. Практический вывод: выбор языка всё больше зависит от конкретной области, а не только от общей популярности.

• Сомнения в методологии рейтинга языков программирования IEEE из-за использования ненадёжных источников (поисковые запросы, устаревающий StackOverflow), что может искажать реальную картину.
• Удивление высокой позицией Java (2-е место), объясняемой её доминированием в enterprise-секторе (финансы, страхование, здравоохранение) и миграцией legacy-систем с COBOL.
• Обсуждение искусственного завышения позиции Python из-за его популярности у новичков, в академических статьях и как основного языка вывода для LLM.
• Предложение объединить рейтинги близких языков (JavaScript/TypeScript, Java/Kotlin, C/C++) для более точного отражения популярности экосистем.
• Размышления о влиянии AI-ассистентов на будущее языков: возможная стагнация из-за зависимости LLM от популярных языков или, наоборот, упрощение изучения нишевых.

Главная бейсбольная лига официально одобрила внедрение системы автоматических судей (роботов-арбитров) с 2026 года. Решение предполагает использование технологии в рамках системы вызовов: команды смогут оспаривать решения живых арбитров по страйкам и болам, а итоговое слово будет за электронной системой. Это не полный переход на роботов — традиционные судьи останутся на поле, но ключевые спорные моменты будут разрешаться алгоритмами.

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

• Внедрение системы автоматического определения страйк-зоны (ABS) и системы обжалования судейских решений воспринято неоднозначно: одни видят в этом долгожданное исправление очевидных ошибок, другие — потерю «человеческого элемента» и духа игры.
• Ключевым катализатором изменений называют распространение спортивных ставок, которые требуют максимальной точности и беспристрастности в принятии решений, особенно для ставок на отдельные питчи.
• Многие пользователи проводят параллели с успешным опытом внедрения аналогичных технологических систем в других видах спорта, таких как крикет (DRS) и теннис (Hawk-Eye).
• Предлагаемая система с ограниченным количеством вызовов (2 за игру) рассматривается как компромисс, позволяющий сохранить некоторые традиционные элементы (например, фрейминг) и драматизм, но при этом исправлять грубые ошибки.
• Обсуждается потенциальное влияние системы на динамику игры: сокращение количества конфликтов и удалений, изменение роли судьи и возможный переход к полностью автоматизированному calling в будущем.

В Нью-Йорке Секретная служба провела рейд против крупной сети SIM-ферм, используемых для массовой рассылки спама и мошеннических звонков. Обнаружено необычное оборудование — так называемые SIM-банки, устройства, вмещающие сотни SIM-карт, организованные в симметричные стойки с антеннами. Это позволяло операторам управлять тысячами номеров одновременно, обходя ограничения мобильных операторов.

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

• Обсуждение касается обнаруженных в Нью-Йорке устройств для массовой рассылки спама (SIM-банков или "модемных пулов"), которые используют сотни SIM-карт для обхода защиты.
• Участники предполагают, что основное применение таких устройств — мошенничество и спам, а не государственный шпионаж, как первоначально могло показаться.
• Поднимаются вопросы о том, почему операторы связи не могут обнаружить такую активность, и высказываются предположения, что MVNO (виртуальные операторы) могут не иметь стимулов или инструментов для этого.
• Отмечается, что подобное оборудование легко доступно на площадках вроде Alibaba и изначально использовалось для серых схем VoIP-звонков и спама в SMS.
• Обсуждаются технические аспекты, такие как возможность работы множества радиомодулей без помех и использование eSIM для снижения трудозатрат на управление SIM-картами.

В Rust есть встроенная атомарная операция fetch_max, которая отсутствует в Java и C++. Она позволяет безопасно обновлять максимальное значение в многопоточной среде без явного написания цикла CAS. Исследование показало, что fetch_max генерируется макросом atomic_int! в стандартной библиотеке Rust, который создаёт методы для атомарных типов.

На уровне компиляции LLVM эта операция превращается в цикл сравнения и обмена, скрытый от программиста. Это демонстрирует, как Rust абстрагирует сложные низкоуровневые детали, предоставляя удобные и безопасные примитивы для конкурентного программирования.

• Автор обнаружил, что Rust имеет встроенную атомарную операцию fetch_max, которой нет в Java и C++ (хотя она планируется в C++26).
• Обсуждение затронуло технические детали реализации атомарных операций (например, на ARM и x86), их производительность при высоком уровне конкуренции и возможность компилятором оптимизировать циклы CAS в нативные инструкции.
• Участники отметили, что подобные низкоуровневые операции существуют и в других средах, таких как GPU (HLSL/GLSL/CUDA) и RISC-V.
• Многие выразили признательность автору за познавательную статью, углубившую их понимание модели памяти и атомарных операций.
• Несколько человек поинтересовались, был ли нанят кандидат, упомянутый в исходной статье, на что автор ответил, что тот не подошел по культуре.

Контекстная инженерия для AI-агентов — это ключевой подход, позволяющий быстро итеративно улучшать производительность без переобучения моделей. Опыт разработки Manus показал, что вместо обучения end-to-end модели эффективнее использовать способность современных LLM к обучению в контексте, что сокращает цикл улучшений с недель до часов и делает продукт независимым от прогресса базовых моделей.

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

• Предлагается использовать файловую систему как память для агентов через директорию .agent/ для хранения задач, планов и других данных.
• Проводятся параллели между лучшими практиками для AI-агентов и управления кодом: избегать раздувания, не удалять плохие коммиты, не рефакторить слишком часто.
• Отмечается разница в стимулах для кеширования: на фиксированных тарифах выгодно провайдеру, на поминутных — пользователю.
• Рекомендуется простота в инструментарии, согласующаяся с подходом OpenAI Codex, например, использование update_plan для отслеживания прогресса.

Qwen — это серия больших языковых моделей, разработанных Alibaba Group. Модели Qwen, включая версии для генерации текста, кода и мультимодальных задач, позиционируются как открытые и конкурентоспособные альтернативы другим известным ИИ, таким как GPT от OpenAI. Они поддерживают длинный контекст, мультиязычность и специализированные применения, например, для программирования или анализа данных.

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

• Пользователи высоко оценили производительность модели Qwen3-VL при обработке сложных изображений (например, низкокачественных счетов), отмечая её превосходство над другими решениями.
• Обсуждаются технические и экономические аспекты запуска больших моделей (235B параметров) локально, включая требования к оборудованию и стоимость вычислений.
• Модель позиционируется как конкурентоспособная с закрытыми SOTA-решениями (GPT-4, Omni) при значительном снижении стоимости использования.
• Критикуются отдельные недостатки, характерные и для других мультимодальных моделей: ошибки в анализе edge-кейсов (например, подсчет конечностей у животных).
• Отмечается активность и щедрость команды Qwen в публикации моделей с открытыми весами и их вклад в развитие open-source сообщества.

В 1983 году успешная британская компания Acorn Computers столкнулась с кризисом: рынок 8-битных компьютеров насыщался, а американские IBM PC и Apple Macintosh предлагали новую мощь. Разработчики BBC Micro Софи Уилсон и Стив Фёрбер искали 16-битный процессор для слота «Tube», но существующие варианты — Intel 80286, National Semiconductor 32016 и Motorola 68000 — их не устраивали из-за низкой эффективности использования памяти и сложности программирования.

Визит в National Semiconductor показал, что создание собственного чипа требует огромных ресурсов, но посещение скромного Western Design Center, где на Apple II проектировали 65C618, доказало: маленькая команда может сделать процессор. Это вдохновило Acorn на рискованный шаг — силами всего 10 инженеров они начали разработку архитектуры, которая позже стала ARM и изменила мир мобильных устройств.

• Представлены дополнительные материалы по истории ARM до 1997 года и интервью с первым CEO компании.
• Обсуждаются технические аспекты архитектуры: низкое энергопотребление как ключевое преимущество, использование микрокода и различия между RISC и CISC.
• Упоминается фильм "Micro Men" о британской компьютерной индустрии и эпохе Acorn.
• Отмечается современная бизнес-стратегия ARM как причина для критики.
• Предлагается передача исторического оборудования (чипы RISC OS 2) в музей вычислительной техники.

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

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

• Критика отсутствия чёткого определения понятия «вычисление» и спекулятивного характера аналогий между биологией и информатикой.
• Обсуждение возможности моделирования жизни как вычисления, но не отождествления этих процессов, с оговоркой о необходимости строгих определений.
• Упоминание альтернативных концепций, таких как прогностическая обработка, иерархия Хомского и принцип вычислительной эквивалентности Вольфрама.
• Скептицизм по поводу детерминизма жизни и редукционистского подхода, игнорирующего её сложность, стохастичность и emergent-свойства.
• Замечание о том, что подобные аналогии являются продуктом человеческого абстрактного мышления и не существуют в природе в явном виде.