Hacker News Digest

• За 3 месяца мы масштабировали «мышление» Qwen3-4B: выше качество и глубина рассуждений. Представляем Qwen3-4B-Thinking-2507:

  • Существенно лучше на задачах логики, математики, науки, кода и академических бенчмарках.
  • Улучшены общие навыки: следование инструкциям, инструменты, генерация текста, согласование с предпочтениями.
  • Расширено понимание длинного контекста: 256K.
  • Версия с увеличенной длиной «мышления» — рекомендуем для сложных задач.

• Обзор модели:

  • Тип: Causal LM; Этапы: пре-/посттренировка.
  • Параметры: 4.0B (без эмбеддингов 3.6B); Слоёв: 36; GQA: 32 Q / 8 KV.
  • Контекст: 262 144 токенов.
  • Поддерживается только режим «thinking»; enable_thinking=True не нужен. Шаблон чата добавляет <think> автоматически; нормален вывод, содержащий только </think>.
  • Подробности: блог, GitHub, документация.

• Производительность (избранное):

  • Знания: MMLU-Pro 74.0; MMLU-Redux 86.1; GPQA 65.8.
  • Рассуждения: AIME25 81.3; HMMT25 55.5; LiveBench 71.8.
  • Код: LiveCodeBench v6 55.2; CFEval 1852; OJBench 17.9.
  • Алайнмент: IFEval 87.4; Arena-Hard v2 34.9; WritingBench 83.3.
  • Агенты: BFCL-v3 71.2; TAU1/2 — лучшие в ряде доменов.
  • Мультиязычность: MultiIF 77.3; PolyMATH 46.2.
  • Примечания: выигрыш на Arena — GPT-4.1; для сложных задач — вывод до 81 920 токенов, иначе 32 768.

• Быстрый старт:

  • Нужен свежий transformers (иначе KeyError: 'qwen3').
  • Пример кода: загрузить AutoTokenizer/AutoModelForCausalLM, применить chat template, сгенерировать до 32 768 новых токенов, выделить «thinking»-часть до токена </think> (ID 151668) и основное содержимое.
  • Для продакшна: sglang>=0.4.6.post1 или vllm>=0.8.5; можно поднять OpenAI-совместимый сервис.

• Обсуждают малый открытый модель Qwen3-4B (в т.ч. «Thinking/Instr»), её доступность в LM Studio и на Hugging Face, возможность запуска на ПК, Mac (mlx 4–8 бит) и даже на слабом железе; полный контекст 262k токенов может требовать десятки ГБ RAM.
• По отзывам: модель быстрая, компактная и по многим бенчмаркам заметно улучшена; в ряде метрик приближается к старой 30B MoE-версии при ~7,5× меньшем размере, но новая 30B-A3B всё же сильнее.
• Практический опыт: хороша в анализе задач, но встречаются галлюцинации в предложениях/советах.
• Идёт сравнение с Gemma 3n: на общих тестах (напр. AIME, LiveCodeBench) Qwen3-4B-Thinking показывает значительно более высокие результаты.
• Обсуждают надёжность метрик: многие бенчмарки оцениваются GPT‑4.1; возникают вопросы о возможной адаптации моделей под «угодные» ответы и нехватке ручного аудита.
• Для «народных» оценок советуют LM Arena, Artificial Analysis, OpenRouter stats и r/LocalLlama, но подчёркивают ограниченную надёжность толпы.
• Вопросы пользователей: как соотносится контекст и RAM; варианты для iPhone/Apple Silicon; ссылки на готовые gguf и mlx-сборки предоставлены.

Представьте, вы пишете проект и вам нужна библиотека — назовем ее libpupa.

Вы находите текущую версию 1.2.3 и добавляете в зависимости: "libpupa": "1.2.3" Автор libpupa 1.2.3 в свою очередь зависел от liblupa версии 0.7.8 и записал это: "liblupa": "0.7.8" То есть libpupa 1.2.3 навсегда зависит от liblupa 0.7.8. Алгоритм разрешения зависимостей простой и детерминированный: берем версии верхнего уровня, затем версии их зависимостей, и так далее. Достаточно указать только верхние уровни — транзитивные получатся одинаковыми всегда. Зачем отдельный lockfile?

Но люди изобрели lockfile из‑за диапазонов версий. Диапазоны делают сборку зависимой от времени: сегодня вы получите liblupa 0.7.8, через 10 минут — 0.7.9. Это определяется не при публикации, а при сборке: вы можете подтянуть версию, которой не существовало на момент выпуска libpupa 1.2.3. Откуда автор libpupa знает, что будущая 0.7.9 не сломает его код? Семантическое версионирование — это лишь намек, не гарантия.

И смешно то, что эти диапазоны все равно «замораживают» в lockfile, и вы не получаете предполагаемой пользы. «Перегенерируй lockfile и обновись» — это ничем не отличается от обновления верхнеуровневых зависимостей. «Lockfile решает конфликты версий?» — нет: библиотека либо работает с новой версией, либо нет; запись «0.7.*» не помогает — все равно нужно выбрать рабочую версию.

«Но раз lockfile существует, значит, нужен!» — не обязательно. Пример: Maven. Экосистема Java 20 лет обходится без lockfile, при этом тянет сотни библиотек — и все детерминировано.

Вывод: lockfile усложняет без достаточных причин. Менеджеры зависимостей могут работать без него.

UPD: В Maven при конфликте транзитивных зависимостей выбирается версия, ближайшая к корню. Это детерминированно и позволяет переопределять версии. Если вышла d 2.1 с патчами безопасности, добавьте ее в корень — она и будет выбрана, не дожидаясь обновлений у всех. Если автоматически брать самую большую версию, вы потеряете возможность переопределения.

• Обсуждение крутится вокруг необходимости lock-файлов и версионирования: одни считают, что фиксированные версии и детерминированные алгоритмы достаточно, другие настаивают, что lock-файлы критичны для воспроизводимости и безопасности.
• Приводят примеры из экосистем Maven/Java, Go (MVS), Cargo/Rust, .NET, Scala: у каждого свои компромиссы; даже при детерминированном резолве сеть/репозитории делают сборки недетерминированными без lock-файлов и хэшей.
• Аргументы за версии-диапазоны: автоматическое получение патчей безопасности без вмешательства авторов верхнеуровневых библиотек; но это ломается при конфликтующих транзитивных зависимостях и несовместимых API/ABI.
• Много комментариев о том, что lock-файлы особенно нужны приложениям (прод, стейджинг, аудит), а для библиотек — меньше, но всё равно полезны из-за пересборок и целостности (хэши артефактов).
• Подчёркивают проблемы разных языков: в компилируемых — типы из разных версий несовместимы; в JS Node могут сосуществовать несколько версий, но это не решает безопасность/детерминизм.
• Некоторые отмечают, что главная путаница — не в lock-файлах, а в культуре семвера, централизованных репозиториях и UX инструментов; предлагают BOM/snapshot-подходы и периодические обновления с тестами/реновейтом.
• Отдельная ветка критикует дизайн сайта с анимированными иконками, мешающими чтению.

Введение

Я часто использую отладчик, но привык и к выводной отладке, особенно в юнит-тестах. Хотелось улучшить её и чаще подключать отладчик.

Улучшение выводной отладки

Главная проблема — «шум»: в цикле интересна одна итерация, а печатается всё. Или удобнее читать форматированную структуру, но приходится раскидывать print’ы по коду. В Zig тесты используют error’ы, значит можно печатать только при падении теста через errdefer:

test { errdefer std.debug.print("{f}", .{ast}); // ... }

Так контекст появляется только при ошибке, без засорения лога.

Запуск тестов в отладчике

Просто запустить seergdb или gdb -tui неудобно: тестовые бинарники лежат в zig-cache. Трюк из ziggит: build.zig может запускать команды и передавать путь артефакта:

// seergdb — GUI фронтенд для gdb const debugger = b.addSystemCommand(&.{ "seergdb", "--run", "--" }); debugger.addArtifactArg(exe_unit_tests);

const debug_step = b.step("debug", "Run unit tests under debugger"); debug_step.dependOn(&debugger.step);

Это запускает правильный бинарник. Но отладчик сработает лишь на брейкпоинте или панике, тогда как раннер тестов «проглатывает» ошибки.

Комбинация трюков

Добавим @breakpoint через errdefer:

test { errdefer @breakpoint(); }

Так мы попадаем в точку ошибки, видим контекст и вывод std.testing.expect*. Минус: при zig build test отчёт показывает падение всего шага тестов, а не отдельных кейсов. Нужна возможность включать брейкпоинты выборочно.

Условная компиляция

Через build options пробрасываем флаг, решающий, вызывать ли @breakpoint в тестах.

Минимальный скрипт сборки, запускающий тесты, дополняем опциями:

const std = @import("std");

pub fn build(b: *std.Build) void { const target = b.standardTargetOptions(.{}); const optimize = b.standardOptimizeOption(.{});

const lib = b.addModule("zig-test-patterns", .{
    .root_source_file = b.path("src/root.zig"),
    .target = target,
    .optimize = optimize,
});

const options = b.addOptions();
options.addOption(bool, "debugger", false);
lib.addImport("config", options.createModule());

const mod_tests = b.addTest(.{ .root_module = lib });
const run_mod_tests = b.addRunArtifact(mod_tests);

const test_step = b.step("test", "Run tests");
test_step.dependOn(&run_mod_tests.step);

}

В коде тестов:

const std = @import("std"); const config = @import("config");

test "errdefer @breakpoint()" { errdefer if (config.debugger) @breakpoint(); return error.FixMe; }

test "no breakpoint" { return error.FixMe; }

zig build test — без брейкпоинтов. Но менять значение флага так — значит пересобирать build.zig. Добавим опцию прямо в систему сборки:

var options = b.addOptions(); const use_debugger = b.option( bool, "debugger", "Enables code intended to only run under a debugger", ) orelse false; options.addOption(bool, "debugger", use_debugger);

Теперь можно переключать поведением командой:

zig build -Ddebugger test

И, при желании, привязать шаг запуска отладчика к этому флагу.

• Участники хвалят согласованность базовых конструкций Zig: минимализм синтаксиса и мощь comptime позволяют элегантные решения без излишней сложности.
• Особый интерес вызвал errdefer: многие отмечают, что это упрощает тесты и отладку; звучит мнение, что такую возможность «стоит иметь каждому языку».
• Обсуждают практики отладки: полезны советы по интеграции дебаггера в build.zig, что избавляет от ручного поиска исполняемого файла в кэше.
• Поднимается вопрос об ошибках без полезной нагрузки в Zig: при парсинге (например, JSON) типовые ошибки вроде UnexpectedToken недостаточно информативны; интересуются паттернами передачи дополнительного контекста.
• Есть замечание о смешении стилей именования (camelCase в stdlib vs snake_case у автора), что может сбивать с толку.
• Отмечают эстетику сайта и блога: шрифты (Berkeley Mono), цветовую схему и ретро-оформление — «как в старых DOS-играх».
• Проводится параллель с D: аналогичная идея реализована через scope(failure), что подчеркивает общность концепции.

Если хотите решить сложную задачу, полезно разложить ее на части и идти от простого к сложному. Но сортировка частей тоже стоит времени: можно потратить его больше на упорядочивание, чем на решение.

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

Команда исследователей предложила новый алгоритм, который обходится без сортировки и работает быстрее всех «сортирующих» методов, преодолев сорокалетний барьер. Роберт Тарьян назвал результат поразительным.

Графы описывают вершины и ребра с весами (длина, время и т.п.). Задача: по данному источнику найти кратчайшие пути до всех вершин. Алгоритм Дейкстры (1956) идет «волной» наружу: зная оптимальные пути к ближайшим, находит пути к дальним. Но конечный результат — упорядоченный набор кратчайших расстояний, и потому скорость ограничена сортировкой. В 1984 году Тарьян с соавтором улучшили Дейкстру до этого предела: чтобы ускориться дальше, нужно избегать сортировки.

В конце 1990-х — начале 2000-х Торуп и другие обошли барьер для частных случаев, вводя ограничения на веса. Обобщить техники на произвольные веса не удавалось, и прогресс застопорился. Ран Дуань не согласился с пессимизмом и стремился сломать барьер для всех графов — и прошлой осенью добился цели.

Идея Дуани (созревшая к 2021 году): вместо того чтобы на каждом шаге сканировать всю «границу» уже исследованной области, как делает Дейкстра (что со временем замедляет ход), группировать соседние граничные вершины в кластеры и рассматривать по одному представителю из каждого. Это уменьшает число кандидатов и может вести не к ближайшей вершине — значит, зависимость от сортировки исчезает. Главная трудность — доказать, что кластеризация действительно ускоряет процесс на каждом шаге и в сумме.

За следующий год Дуань проработал идею и к осени 2022-го был уверен, что технические барьеры преодолимы.

• Обсуждение вокруг нового алгоритма SSSP с детерминированной сложностью O(m log^(2/3) n), который улучшает Дейкстру на разреженных графах; ссылку дали на arXiv: 2504.17033.
• Участники отмечают, что выигрыш зависит от структуры графа: для дорожных сетей обычно m ≈ c·n (c ~ 4–6 для ориентированных), что даёт O(n log^(2/3) n); для очень плотных графов (m ~ n^2) преимущество может исчезать.
• Возникают вопросы о сравнении логарифмических степеней, применимости к задачам вроде TSP с почти полными графами, и сохранении гарантии глобального минимума как у Дейкстры.
• Некоторые считают алгоритм сложнее Дейкстры, но отмечают теоретическую значимость прорыва и отсутствие «фancy math», что делает результат удивительным.
• Обсуждают возможные гибриды с рандомизацией и практическое влияние на реальные графы (улицы, геймдев).
• Есть скепсис о «позднем открытии» и комментарии про то, что практики могли бы дойти до подобных идей, но не оформляют их академически.
• Вспоминают вклад классиков (Тарjan и др.) и проводят аналогию с TimSort: практичная оптимизация поверх классики.

Я обожаю dotfiles.

“Dotfiles” — это конфигурационные файлы для программ и ОС, часто начинаются с точки: .bashrc, .tmux.conf, .zshrc. Когда софт не поддерживает настройку файлами, грустно: сложнее синхронизировать конфиги между устройствами и при настройке новых машин.

Я люблю делиться: пишу блог, веду цифровой сад заметок и выкладываю почти весь код на GitHub. И обожаю читать чужие dotfiles, учиться у них.

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

У меня есть классный репозиторий с кучей всего: конфиг zsh и алиасы, tmux, neovim и vscode, Python startup-скрипт. Храню список пакетов Homebrew — ставлю на новый компьютер одной командой. Там же — CSS-правила для Stylus, чтобы везде получать нужный вид.

Для управления использую GNU Stow: структура папок позволяет командой stow [folder] раскидать симлинки по нужным местам, и изменения синхронизируются на всех машинах. Это очень удобно.

В сумме там 19 конфигов плюс весь мой neovim с плагинами. Но пока я «берегу их как тайну», пока не почувствую готовность делиться.

Если откликнулось — напишите на juhamattisantala at gmail dot com. В 2025 хочу больше глубоких разговоров с людьми со всего мира — буду рад вашему письму.

• Участники разделились: одни считают дотфайлы слишком личными/уязвимыми для публикации, другие — ценным источником обмена знаниями и вдохновения.
• Главные опасения: утечки секретов и контекста (хосты, пути, IP, корпоративные детали), риски социнженерии и отпечатков, а также стыд/страх оценки «неидеальной» личной конфигурации.
• Распространенная практика — разделение на слои: публичные «универсальные» настройки, приватные оверрайды и секреты; отдельные репозитории, шифрование (age/gpg, sops), менеджеры вроде chezmoi, myba, Polykey.
• Советы по безопасности: не хранить секреты в .bashrc и подобных, исключать их через .gitignore, использовать шифрование и хранилища (1Password ссылки, отдельные файлы, приватные репо).
• Польза публикации: обучение через чужие конфиги (vim/zsh/emacs/nvim), улучшения качества жизни через алиасы/маппинги, возможность быстро делиться и переустанавливать окружение.
• Практические подходы: файл-локальные приватные настройки, employer-специфические include-файлы, документирование и чистка перед открытием, минимизация зависимостей от нестандартного софта.
• Итоговый консенсус: «делиться избирательно» — держать публичным обобщаемое и полезное, а чувствительное и слишком личное — приватным или зашифрованным.

OK, so every agentic prompt injection concern and/or data access concern basically immediately becomes worst case scenario with this, right? There is now some sort of "official AI tool" that you as a Federal employee can use, and thus like any official tool, you assume it's prope

• Обсуждение о том, что один из корпоративных Salesforce-инстансов Google был скомпрометирован через вишинг-атаки (UNC6040), с кратковременной утечкой контактных данных и заметок по малому и среднему бизнесу; официальный тон смягчает масштаб, что вызывает скепсис.
• Комментаторы сомневаются в формулировках “лишь базовые и публичные данные”, предполагая, что ценность для злоумышленников была реальной (возможны вторичные схемы, например мошенничество с биллингом).
• Многих удивляет, что Google использует Salesforce; объяснения: историческое наследие, быстрые поглощения, а также предпочтения команд продаж и маркетинга к индустриальным стандартам вместо внутренних инструментов.
• Приводятся истории о неудачных внутренних CRM у Google: баги, нехватка функций, нежелание инженеров поддерживать; продажи и PM часто продавливают Jira/Salesforce ради скорости найма и онбординга.
• Отмечается культурный сдвиг: замена внутренних решений “джанковыми” шаблонными процессами Salesforce; внутренние инструменты больше для инжиниринга.
• Уточнения: у Google десятки тысяч сотрудников в продажах/маркетинге; часть саппорт-систем GCP ранее зависела от Salesforce; выбор строить/покупать/партнериться по CRM оценивался и часто оказывался экономически нецелесообразным для собственной разработки.
• Общий вывод: инцидент — результат классической социальной инженерии, а не технического взлома; реакция компании стремится минимизировать восприятие ущерба, вызывая дискуссии о прозрачности и рисках использования сторонних SaaS.

If you're looking for a fantastic dev-focused linux distro, I can't say enough good things about Bluefin Linuxhttps://projectbluefin.io/ I really appreciate that he included a video with great narration. So much better than the animated gifs that provide too little context and go

Claude Code IDE для Emacs

Обзор

• Интеграция с Claude Code CLI через MCP создает двусторонний мост между Claude и Emacs.
• Claude получает доступ к возможностям Emacs: LSP, проекты, Elisp-функции, что делает его «понимающим Emacs» помощником в вашем рабочем процессе.

Возможности

• Автоопределение проекта и управление сессиями
• Терминал с цветом (vterm/eat)
• Реализация MCP для IDE-интеграции
• Инструменты для файлов, состояния редактора и рабочего пространства
• Расширяемый сервер MCP для Emacs-команд (xref, tree-sitter, project и др.)
• Диагностики Flycheck/Flymake
• Расширенный дифф с ediff
• Поддержка tab-bar и отслеживание выделений/буферов

Интеграция инструментов Emacs

• LSP через xref (eglot, lsp-mode) для навигации по коду
• Tree-sitter для анализа AST
• Imenu для структуры символов
• Project для операций на уровне проекта
• Любую команду/функцию Emacs можно выставить как MCP-инструмент: поиск и рефакторинг по проекту, доступ к режимам, выполнение кастомного Elisp.

Скриншоты

• Осведомленность об активном файле — знает, какой файл открыт
• Контекст выделения — работает с выделенным текстом
• Продвинутый дифф с диагностикой — ediff и доступ к ошибкам/предупреждениям
• Автоматические упоминания текста — вставка ссылок на выделение в диалог
• Восстановление сессии — продолжение разговоров с флагом –resume

Установка Предварительные требования

• Emacs 28.1 или новее

• AI-инструменты вроде Claude Code упрощают жизнь нишевым редакторам: вместо тяжёлых IDE-фич они получают «умных» ассистентов почти без кода.
• Emacs и Vim выигрывают благодаря открытости: можно быстро обернуть Claude в elisp или lua и настроить под себя.
• Уже есть несколько готовых обёрток (claude-code.el, eca, claudemacs и др.), но пока нет явного лидера.
• Пользователи жалуются на сложность конфигурации, проблемы безопасности (чувствительные файлы) и привязку к одному провайдеру.
• Мечтают о локальных моделях, Org-mode-интеграции и едином протоколе для всех агентов.

This pops up every few years, and I bet once it gets in it never goes away. It seems asymmetric that one side only has to win once to win permanently while the other side has to win constantly. Is there any mechanism to stop this in the EU and make this kind of legislation explic