Hacker News Digest

Tongyi DeepResearch — первый полностью открытый веб-агент, демонстрирующий производительность на уровне DeepAI OpenAI. Модель достигает передовых результатов: 32.9 на тесте академического рассуждения Humanity's Last Exam, 43.4 на BrowseComp и 46.7 на BrowseComp-ZH в сложных задачах поиска информации, а также 75 на пользовательском бенчмарке xbench-DeepSearch, превосходя все существующие проприетарные и открытые агенты глубоких исследований. Авторы делятся полной методологией создания таких агентов, включая инновационное решение для синтеза данных на всем конвейере обучения.

В основе обучения лежит Agentic Continual Pre-training (CPT) с использованием системы AgentFounder для масштабного синтеза данных. Разработчики создают цикл данных, перегруппируя различные источники в привязанную к сущностям открытую мировую память знаний. Для сложных вопросов с высокой неопределенностью они синтезируют веб-данные через высокосвязанный граф знаний с помощью случайных обходов. Модель демонстрирует мощные возможности в режиме ReAct без инженерии промптов, а продвинутый Heavy Mode раскрывает верхний предел ее потенциала сложного рассуждения и планирования.

• Обсуждение в основном вращается вокруг трёх тем: «Deep Research» как продукт vs. обычный поиск, практичность мелких моделей, и то, что большие модели всё ещё уступают специализированным инструментам в конкретных задачах.
• Участники обмениваются опытом, что мелкие модели (Qwen 3 4B и т.п.) уже способны обеспечить приемлемое качество при минимальных затратах, особенно если квантовать и/или запустить их на Apple Silicon.
• Обсуждается, что влияние этих моделей на рынок: будут ли они заменять крупные модели в нишевых задачах или же будут использованы как основа для дальнейшей настройки.
• Также поднимается вопрос о том, что, возможно, в будущем мы увидим взрыв специализированных моделей, обученных под конкретные задачи, и что это может быть следующим шагом после исчерпания выгод от предобучения.

HyperRogue is specifically hyperbolic (and very cool! See also RogueVis), but of course there are a number of non-Euclidean roguelikes. One of my favourites is Smart Kobold [1], which really amazed me at the time, particularly as it was made in just 7 days for the 7DRL! It's so c

Interesting, a few questions: 1. How hard/easy is it to make responses dynamic, i.e. to use something from the request data like query/path param or a body to execute function instead of hardcoding the response 2. What's the main motivation for creating this tool? I feel like eve

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

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

• Обсуждение охватывает вопросы: стоит ли хранить состояние в URL, какие ограничения накладывает это, какие есть альтернативы и какие есть подводные камни (отсутствие семантики, безопасность, длинные URL-ы и т.д.).
• Участники обмениваются опытом, что иногда приводит к тому, что URL становится слишком длинным, что это может вызвать проблемы.
• Обсуждается, что такое состояние должно быть сериализуемо так, чтобы его можно было закодировать в URL, и что такое состояние должно быть сериализуемо так, чтобы его можно было сохранить в URL.
• Разговор затрагивает, что такое состояние должно быть сериализуемо так, чтобы его можно было сохранить в URL.
• Участники обсуждают, что такое состояние должно быть сериализуемо так, чтобы его можно было сохранить в URL.

В FreeBSD находят способ вернуть радость в самохостинг: автор перешёл с Linux, устав от сложностей, и нашёл в BSD простоту, стабильность и отличную документацию.

Ключевые моменты:

• Использует BastilleBSD для контейнеров и vm-bhyve для виртуалок, несмотря на начальную путаницу.
• Ценит долгосрочную совместимость: решения десятилетней давности работают и сегодня.
• Сообщество оказалось невероятно поддерживающим, помогая на каждом шагу.

Автор подчёркивает: важна не идеальная настройка, а сам процесс обучения и радость от экспериментов. Результат — возвращение к хобби-программированию с тем же азартом, что и в юности.

• Участники обсуждают преимущества и недостатки BSD-систем, включая OpenBSD, FreeBSD и производные от них, так как OPNsense и TrueNAS, в контексте самостоятельного хостинга и само-обеспечения.
• Обсуждается, что BSD-системы предлагают высокую стабильность, безопасность и простоту конфигурации, но при этом страдают от недостатка поддержки драйверов и некоторых современных технологий, таких как Docker и systemd.
• Участники делятся личным опытом, включая использование FreeBSD в качестве настольной системы и OpenBSD в качестве маршрутизатора, а также обсуждают, что такие системы могут быть использованы в качестве серверов для различных сервисов, включая Jellyfin и n8n.
• Обсуждается, что BSD-системы могут быть менее удобны для пользователей, которые привыкли к GNU-утилитам и systemd, и что это может быть препятствием для некоторых пользователей.
• Участники также обсуждают, что BSD-системы могут быть менее удобны для разработчиков, так как они могут не поддерживать такие технологии, как CUDA и Docker, что может быть важно для некоторых разработчиков.
• В конце обсуждение переходит к тому, что, несмотря на все вышеупомянутое, BSD-системы все еще имеют свою нишу и что они могут быть полезны для определенных пользователей, особенно для тех, кто ценит стабильность и безопасность.

Helion — это высокоуровневый язык для создания производительных и переносимых ML-ядер, разработанный командой PyTorch в Meta. Он разрешает конфликт между производительностью и удобством, компилируя Python-встроенный DSL в автоматически настраиваемый код Triton. Helion создает новый уровень абстракции, сочетающий простоту PyTorch с производительностью низкоуровневых языков, автоматизируя рутинные задачи вроде индексации тензоров и управления памятью. Это позволяет разработчикам сосредоточиться на алгоритмической логике, а не на аппаратно-специфичных деталях.

Текущие языки вынуждают выбирать между контролем и производительностью: CUDA дает максимум контроля, но требует значительных усилий; Triton — шаг вперед, но все еще требует ручной настройки; PyTorch прост, но ограничен в детальном контроле. Программная модель Helion, описываемая как "PyTorch с тайлами", минимизирует шаблонный код и использует знания разработчиков в PyTorch. Типичное ядро Helion состоит из двух взаимодополняющих частей, что упрощает создание правильных и эффективных ядер.

• Helion позиционируется как более высокоуровневая альтернатива Triton, упрощая написание кода за счет автоматического автотюнинга, в отличие от других DSL (Gluon, CuTe), которые предлагают больше контроля на низком уровне.
• Основные проблемы включают длительный автотюнинг (до 10+ минут), отсутствие полноценной поддержки Python-отладки (автодополнение, точки останова) и сложность выбора между множеством технологий (Triton, Gluon, JAX Pallas и др.).
• Несмотря на рост высокоуровневых фреймворков, низкоуровневые оптимизации остаются критичными для новых архитектур моделей (например, FlashAttention, MXFP4) и аппаратных платформ (NVIDIA, AMD).
• Споры о релевантности CUDA: мнения расходятся от его "устаревания" до сохранения доминирующей роли в экосистеме на годы вперед из-за зрелости инструментов и сообщества.
• Пользователи отмечают, что Helion может расширить круг разработчиков, способных писать эффективные ядра, но сомневаются в его преимуществах перед Triton/Gluon без явного выигрыша в производительности или простоте.

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

Карпати утверждает, что понимание обратного распространения ошибки (backprop) критически важно, несмотря на автоматизацию в фреймворках вроде TensorFlow. Он называет backprop "утечкой абстракции" — опасно верить, что просто соединяя слои, можно "магически" обучить сеть. Студенты курса CS231n жаловались на ручную реализацию backprop в numpy, но Карпати настаивает: без понимания математики невозможно диагностировать проблемы обучения.

Яркий пример — сигмоидные функции. При плохой инициализации весов сигмоиды "насыщаются" (выходы близки к 0 или 1), делая локальный градиент z*(1-z) равным нулю. Это полностью останавливает обучение. Даже при нормальных условиях градиент сигмоиды не превышает 0.25 (при z=0.5), что означает его 4-кратное ослабление при каждом проходе. Для сетей с сигмоидами нижние слои учатся значительно медленнее верхних.

• Обсуждение вращается вокруг статьи Карпати "Yes, you should understand backprop" и его тезиса о том, что понимание backprop важно, даже если вы никогда не будете писать его вручную.
• Участники спора сомневаются в ценности этого подхода, указывая на то, что современные фреймворки и высокоуровневые абстракции делают знание деталей неактуальным.
• Некоторые участники подчеркивают, что даже если вы не будете реализовывать backprop вручную, понимание принципов работы оптимизаторов и функций активации важно для отладки и проектирования моделей.
• Обсуждение также затрагивает вопрос о том, насколько важно понимать детали, когда вы пользуетесь высокоуровневыми инструментами, и какие уровни абстракции считаются приемлемыми.
• В конце концов, спор сводится к тому, что хотя фундаментальное понимание важно, но не стоит забывать, что большинство практических задач будут решаться с помощью высокоуровневых инструментов и фреймворков.

Этот пост рассказывает о веб-сайте Tyco's Pages, который содержит множество статей на различные темы. Сайт структурирован по разделам, включая критику капитализма, описание альтернативных систем, демократии и даже тем вроде кошек и инопланетян. Особо выделена страница про микросхему LM8560, представленная как "вечный чип из 1980-х". Хотя сайт позиционируется как ресурс против капитализма, он также охватывает случайные темы вроде чипов, что может указывать на сатиру или эклектичный подход к контенту. В целом, сайт служит примером того, как интернет-ресурсы могут совмещать серьёзную критику и случайные детали, призывая к глубокому анализу привычных концепций.

• Воспоминания о 1970-х: от красных светодиодов до 555-таймеров и ранних цифровых часов, которые были не более чем счетчиками, а не микроконтроллерами.
• Самодельные проекты, которые не выглядят как самодельные, и почему мы до сих пор используем 555 таймеры.
• Почему часы на светодиодах до сих пор выглядят как взрывчатые устройства, и как мы можем сделать их более безопасными.
• Как мы пришли к тому, что мы не можем больше купить нормальные светодиодные часы, и почему мы до сих пор используем 555 таймеры.

В последние годы скраперы, используемые компаниями для обучения LLM, стали более агрессивными, игнорируя robots.txt и маскируясь под обычных пользователей. Это привело к росту популярности Anubis — решения на основе proof-of-work, требующего от посетителей решения криптографической задачи перед доступом к сайту. Однако автор утверждает, что Anubis неэффективен против LLM-скраперов, так как те просто не выполняют JavaScript, а вычислительные затраты для обхода всех установок Anubис составляют примерно $0.00.

В качестве альтернативы предлагается простой 12-строчный Caddyfile, который устанавливает cookie через JavaScript, эффективно блокируя ботов без 10-секундной задержки для посетителей. Оба решения являются временными, так как боты могут научиться их обходить — Huawei уже умеет решать задачи Anubis. Автор подчеркивает, что если единственная проблема — ClaudeBot, лучше использовать менее раздражающие решения, а Cloudflare остается наиболее надежным, хоть и монопольным, способом защиты от ботов.

• Обсуждение в основном вращается вокруг того, что Anubis и подобные системы защиты от скрапинга, по сути, не решают проблему, а лишь создают неудобства для пользователей и разработчиков, и что это больше похоже на "security theater", чем на реальную защиту.
• Участники обсуждения подчеркивают, что LLM и скраперы уже давно научились обходить такие системы, и что единственный эффект — это лишнее время загрузки для обычных пользователей.
• Также поднимается вопрос о том, что вместо того, чтобы развивать "arms race" вокруг защиты от скрапинга, было бы лучше сосредоточиться на создании устойчивых и этичных решений, которые бы не требовали таких мер.
• Некоторые участники также отмечают, что вместо того, чтобы полагаться на подобные системы, разработчики могли бы использовать более прогрессивные подходы, такие как rate limiting, требование авторизации для доступа к API и другие методы, которые не требуют от пользователей выполнения сложных вычислений.
• В конце концов, обсуждение смещается к тому, что вместо того, чтобы продолжать "гонку вооружений", было бы более продуктивно сосредоточиться на создании более этичных и устойчивых решений, которые не требуют таких мер.