Hacker News Digest

• Два варианта у OEM: продавать стек Nvidia (рост выручки, снижение маржи) или остаться без AI-заказов, довольствуясь лишь периодическими продажами серверов Intel/AMD.
• Dell выбрал первый путь и стал ключевым поставщиком крупнейших AI-кластеров (xAI, CoreWeave), используя «покупай американское» и собственный масштаб.

• Пользователи обсуждают, что Dell выигрывает на всплеске спроса на AI-серверы, несмотря на более высокую цену и «энтерпрайз-поддержку».
• Ключевые причины выбора Dell: быстрая поставка, надёжные цепочки поставок, гарантия, удобный iDRAC и «не мой кошелёк — моя голова».
• Некоторые считают, что это очередной пузырь: «графокард-максимизаторы» поглощают ресурсы, а в будущем рынок окажется завален дешёвыми бывшими AI-серверами.
• Участники спорят, когда лопнет пузырь: прогнозы варьируются от «в любой момент» до «держится до 2026 года и дальше».
• Есть надежда, что после взрыва спроса появится дешёвая «железка» для домашних лаб и конкуренция для AWS.

Ты должен почувствовать это

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

Люди испытывают чувства при каждом взаимодействии: радость, раздражение, уверенность. Это чувство — часть работы. Оно должно быть в требованиях.

Когда ты чувствуешь — знаешь: функция заставляет улыбнуться, будто всегда была здесь. Хочется использовать снова и рассказать другим.

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

Ты должен почувствовать это.

• Всё сводится к чувствам: даже «рациональные» решения в итоге определяются «вайбом».
• Корпоративная машина чувств не имеет, поэтому продукты без души побеждают по метрикам, но не вызывают восторга.
• «Тест выходного дня»: если хочется ковыряться в проекте в свободное время — значит, он «чувствуется» правильно.
• Некоторые считают, что чувства можно (и нужно) анализировать, другие — что это неизмеримая эволюционная сверхспособность.
• Маленькие команды могут позволить себе «неправильные» продукты, которые не проходят корпоративные чек-листы, но вызывают любовь пользователей.

• Condor Computing, дочка Andes Technology, показала на Hot Chips 2025 ядро Cuzco — высокопроизводительное 8-ширинное RISC-V с 256-записным ROB, 2–2,5 ГГц на TSMC 5 нм и 10-цикл. штрафом за промах предсказания.
• Ядро конкурирует с SiFive P870 и Veyron V1, превосходя уже реализованные C910 и P550.
• Особенность: «временное» статическое планирование в backend для экономии энергии без изменений ISA и без требований к компилятору.
• Cuzco модульное: строится из «execution slices», конфигурируются L2 TLB, шины, L2/L3, размеры внутренних структур. До 8 ядер в кластере, связь через CHI; можно масштабировать множеством кластеров.
• Frontend: TAGE-SC-L для условных переходов, BTB 16 К-entry, RAS 64-entry, μop-кэш 3 K-entry/96 KB, 32 B/цикл выдача.
• Fetch/decode: 32-байт/цикл, 4×simple + 1×complex декодер, поддержка RVC, μop fusion.
• Rename/dispatch: 8 μop/цикл, 256 phys-регистров int/fp, 96-entry scheduler, 32-entry store queue.
• ALU: 4 int + 2 branch + 2 fp/simd + 2 load + 1 store, 2-cycle FMA, 256-бит SIMD, crypto-расширения.
• L1: 64 KB I + 64 KB D, 4-cycle load-to-use; L2 512 KB–2 MB; L3 2–8 MB.
• Потоковая модель: 1 thread/core, но можно SMT в будущем.
• Потребление: ~0,5 Вт/ГГц (Typical), 2,5 мм² на 5 нм без L2/L3.

• Новое ядро Andes (Condor) делает ставку на энергоэффективность: жертвует 5–7 % «сырой» производительности ради десятков процентов экономии энергии.
• Вместо классического Tomasulo в бэкэнде статическое расписание формируется во фронтенде; при промахе L1 результаты помечаются как «ядовитые» и переигрываются, заполняя пустые слоты конвейера.
• Критики сомневаются в эффективности без аппаратного учёта зависимостей по памяти и переменной латентности операций; автор отвечает, что всё покрывается предикцией + replay.
• Появление битовых инструкций RVA23 признано полезным и для HPC-кода, и для встраиваемых задач.
• Сообщество радуется, что RISC-V добрался до высокопроизводительных реализаций, несмотря на патентные барьеры доминирующих игроков.

AI-модели нуждаются в виртуальной машине

Современные приложения с ИИ включают модель в «обвязку», которая обеспечивает вызов инструментов, поиск контекста, безопасность и прочие сервисы. Первые чат-боты были простым REPL-циклом: запрос → модель → ответ. С появлением протоколов вроде MCP логика управления стала сложнее и требует свойств ОС: изоляции, расширяемости, переносимости, контроля доступа к файлам и инструментам.
Мы предлагаем рассматривать этот слой как виртуальную машину для ИИ-моделей (MVM), где одна из «инструкций» — вызов LLM. Это развязывает разработку моделей от кода интеграции и даёт «write once, run anywhere» аналогично JVM.

Зачем MVM

• Безопасность и приватность «из коробки», а не как дополнение.
• Повторное использование: любая модель подключается к экосистеме инструментов и политик безопасности.
• Переносимость: модель и политики можно поставлять и запускать в разных средах.

Пример работы

1. Пользователь: «Забронируй рейс».
2. MVM передаёт запрос модели.
3. Модель: «вызови booking-tool».
4. MVM проверяет, разрешён ли этот инструмент, и только потом вызывает его.
   Такой контроль есть в любом коммерческом ИИ-продукте; MVM выносит его в стандартизированную платформу.

Инструкции MVM

• загрузка/выгрузка модели и инструментов;
• вызов модели с контекстом;
• парсинг её ответа;
• вызов разрешённых инструментов;
• работа с памятью, историей, вводом пользователя;
• стандартные управляющие конструкции (if, seq, loop).

• Критики считают, что статья расплывчата: «VM для ИИ» сводится к обычной песочнице/контейнеру, а не к полноценной машине.
• Основная проблема — не инструменты, а разрешения: нужно точно ограничить, какие действия и данные доступны агенту, иначе он может, например, купить билет с 37-часовой пересадкой ради 3 $.
• Многие предлагают использовать уже существующие механизмы: Docker, отдельный пользователь, контейнеры, WebAssembly или capability-модель вроде Fuchsia.
• Часть комментаторов указывает, что продвинутые модели (ChatGPT Code Interpreter, OpenHands) уже работают в изолированных средах, но этого всё равно недостаточно.
• Итог: вместо новой «ОС для ИИ» нужно чёткое управление правами и данными; VM лишь метафора для этой задачи.

• bcachefs переведён в статус externally maintained — Линус отметил, что новые изменения в mainline маловероятны, но немедленного удаления файловой системы из ядра не планируется.
• Суть конфликта: не лицензия и не технические проблемы, а личные разногласия Линуса и других разработчиков с автором bcachefs Кентом Оверстритом.
• Возможные сценарии
  • Найти нового мейнтейнера, который будет выступать посредником между Кентом и ядром.
  • Риск: такой человек может выгореть, повторив конфликт «по доверенности».
  • Альтернатива — форк ядра без участия Кента, но Линусу это, судя по всему, неинтересно.
• Позиция Кента: он не хочет перекладывать ответственность на коллег-разработчиков, чтобы не потерять ещё одного инженера, и настаивает на контроле качества релизов, так как сам обрабатывает большинство баг-репортов.

• Btrfs по-прежнему не догнал ZFS по надёжности и функционалу, а уход Josef Bacik из Meta усиливает тревогу за его будущее.
• bcachefs остаётся в ядре, но из-за конфликта Kent Overstreet с процессом слияния патчей его обновления теперь могут идти вне основного дерева (DKMS/сторонние репозитории).
• Участники обсуждают высокий «bus-factor» bcachefs (разработка почти одним человеком) и сравнивают ситуацию с ZFS, который стабильно работает на FreeBSD и некоторых Linux-дистрибутивах.
• Некоторые пользователи рассматривают переход на FreeBSD или возврат к проверенным схемам LVM+XFS из-за нестабильности btrfs и проблем bcachefs.

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

• Следи за «весом» кода: одна функция = одна идея, короткие имена, избегай вложенностей.
• Удаляй дубли: повторы усложняют чтение и тестирование.
• Используй типы и имена как документацию: ясные сигнатуры снижают необходимость комментариев.
• Ограничь контекст: меньше глобальных переменных, чёткие границы модулей.
• Автоматизируй рутину: линтеры, форматтеры и тесты экономят мозговые ресурсы.

Правила применимы к любому языку и масштабу проекта.

• Участники сходятся во мнении, что «простота» кода измеряется не строками, а когнитивной нагрузкой при его изменении (Ousterhout: complexity = cognitive load × frequency of change).
• Часто «сложный» код — результат привычки или неопытности; опытные разработчики умеют сжимать идеи до минимально необходимого набора понятий.
• Помогают: ранние возвраты, выразительные имена переменных, тесты, чёткие границы компонентов и повторяющиеся стандарты проекта.
• Противоречие: «куча if-ов» кажётся простой, но скрывает дублирование; избыточные абстракции тоже усложняют отладку.
• Ключевой совет — писать код как текст для людей, а не для машины, и сознательно тратить время на упрощение, даже если это не приносит немедленной карьерной выгоды.

• Китайская группа Salt Typhoon взломала почти всех американцев, заявил заместитель директора ФБР по киберпреступлениям Брайан Ворондран.
• Хакеры продержались в сетях операторов связи США до 9 месяцев, перехватывая звонки, SMS и данные.
• Взлом затронул миллионы абонентов Verizon, AT&T, T-Mobile и Lumen, включая правительственные линии.
• Потери трудно оценить: злоумышленники могли читать SMS-коды, перенаправлять звонки и собирать метаданные.
• Секретные данные могли быть скомпрометированы, но точный масштаб расследуют.
• Китай отрицает причастность, называя обвинения «политически мотивированными».

• Атака Salt Typhoon стала возможной благодаря обязательным «законным» закладкам (CALEA) в телеком-оборудовании, которые теперь использует Китай для массовой слежки.
• Участники напоминают, что ещё NSA перехватывала трафик Google (Room 641A), поэтому удивляться «нарушению норм» странно.
• Инцидент всё ещё активен: данные продолжают утекать, а «пост-мортум» ещё не начался.
• Критика властей США: вместо защиты они продолжают расширять слежку и сокращают CISA.
• Вывод: любые обязательные backdoors делают уязвимыми не только «плохих парней», но и всех остальных.

Agent Client Protocol (ACP) — единый стандарт связи между редакторами кода и агентами-разработчиками на базе ИИ.
Протокол в разработке, но уже позволяет строить полезные интеграции.

Зачем ACP?

• Редакторы и агенты сейчас жёстко связаны: каждая пара требует собственной интеграции.
• Это → лишние затраты, ограниченная совместимость и привязка к конкретным интерфейсам.
  ACP, как LSP для языковых серверов, развязывает стороны: агент, реализовав ACP, работает во всех совместимых редакторах, а редактор, поддерживающий ACP, получает доступ ко всей экосистеме агентов.

Как устроено

• Агент запускается как подпроцесс редактора.
• Обмен — JSON-RPC через stdio.
• Используются типы MCP, дополнены собственными (например, для диффов).
• Текст для пользователя — Markdown, без необходимости HTML.

Поддержка

Редакторы:

• Zed
• neovim (через плагин CodeCompanion)

Агенты:

• Gemini
• Скоро — ещё.

• Предложен новый протокол (ACP) для связи агентов-ИИ с IDE/редакторами, плюс библиотеки на Node, Python, Rust и сайт.
• Название ACP вызывает путаницу с уже существующим agentcommunicationprotocol.dev и IBM/Google A2A.
• Некоторые считают, что достаточно расширить LSP или MCP, другие предлагают «Neovim внутри Claude Code», а не наоборот.
• Уже есть первые реализации для Claude Code и Zed, но остаются проблемы с поиском несохранённых файлов и UI-дифами.
• Обсуждают риск фрагментации стандартов и желание, чтобы любой редактор мог подключиться без переписывания под каждого агента.

• Пользователи жалуются на взрыв цен на мелкооптовые и хоббийные платы из-за отмены de minimis: заказать у JLCPCB стало невыгодно, а альтернатив почти нет.
• Многие считают шаг «экологическим выигрышем» (меньше мусора с Shein/Temu), но это игнорирует рост посредников и логистики, которые могут увеличить углеродный след.
• Критика, что США ввели правило, не создав инфраструктуры для сбора пошлин: теперь налог должен удерживать сам иностранный продавец, а не пограничник.
• Хоббисты и мелкие мастерские теряют доступ к дешёвым компонентам из Китая (их никто не выпускает в США), цены через посредников вырастают в 3-4 раза.
• Некоторые предлагают оставить de minimis для «дружественных» стран, но опасаются, что товар просто пойдёт через третьи страны.

Nokia Sans — шрифт, которым пользовались почти все телефоны Nokia с 2002 по 2013, — оказался отличным выбором для интерфейса. Автор статьи, ностальгируя, скачал варианты Nokia Sans и установил их в KDE. Оказалось, что Nokia Sans Wide читается прекрасно на высоких DPI и придаёт интерфейсу характер без излишеств, вытеснив у автора привычный Inter.

Создатель шрифта Эрик Шпикерманн ещё в 2011-м спорил с Nokia, утверждая, что Wide-вариант вполне подходит для UI, но компания предпочла «безликий» Nokia Pure. Автор признаёт: всё субъективно, на Windows/macOS или низких DPI результат может отличаться, а правовой статус скачанных файлов неясен.

• Nokia Sans (и её Wide-вариант) вызывает ностальгию, но как UI-шрифт годится только на HiDPI-дисплеях и имеет лишь один начертание.
• В США Nokia была главным телефоном 1995-2005, несмотря на позднее отступление из-за конфликта с операторами.
• Шрифт напоминает Fira Sans и Meta — все они вышли из-под пера Эрика Шпикермана.
• На сайте мелкие скриншоты и блокировка зума мешают оценить детали; лицензия для коммерческого использования неясна.