Hacker News Digest

Автор изначально не интересовался 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 фиксированный размер стека может ограничить количество одновременно работающих сопрограмм.

Инженеры Nanit сэкономили $500,000 в год, создав собственную систему хранения N3 на Rust вместо использования AWS S3 для обработки видео. При тысячах загрузок в секунду, плата за запросы PutObject в S3 становилась основной статьей расходов, а минимальный период хранения в 24 часа правил out стоимость обработки, занимавшей всего 2 секунды.

N3 работает как in-memory landing zone, используя S3 только как буфер перегрузки. В исходной архитектуре камеры загружали видео чанками напрямую в S3 через presigned URL, после чего Lambda отправлял ключи в SQS FIFO очередь для обработки. Подход сохранил надёжность и строгую последовательность данных, но исключил плату за запросы на основном пути и сократил затраты на хранение.

• Стоимость S3 для короткоживущих файлов оказалась настолько высокой, что компания вместо него реализовала собственное in-memory хранилище, что позволило сэкономить $500k, но оставляет вопрос о том, что будет, если этот кэш упадёт.
• Обсуждение вылилось в критику концепции "serverless" архитектуры, где-то между линиями прочиталось, что сама архитектура была проблемой, а не решением.
• Участники обсуждения также подняли вопросы о приватности: камера в детской комнате передаёт аудио/видео в облако без шифрования, и кто-то может прослушивать ваш дом.
• Несколько комментаторов отметили, что вместо того, чтобы писать собственные сервисы, компании могли бы использовать существующие open-source решения, такие как MinIO или SeaweedFS, но при этом они также отметили, что даже эти решения не предоставляют той же степени удобства, что и делает S3.

Смартфоны специально созданы для манипуляции нашими эмоциями и запуска рефлексов, что делает нас зависимыми. Приложения используют психологические триггеры, такие как уведомления, лайки и бесконечная прокрутка, чтобы удерживать наше внимание. Эти механизмы активируют дофаминовую систему мозга, создавая циклы вознаграждения, от которых трудно отказаться. Исследования показывают, что средний человек проверяет свой телефон более 150 раз в день, а некоторые пользователи проводят до 5 часов ежедневно в социальных сетях.

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

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

В статье предлагается первое конкретное определение AGI, соответствующее когнитической универсальности и компетентности хорошо образованного взрослого человека. Авторы основали свою методологию на теории Кэттелла-Хорна-Карролла, наиболее эмпирически проверенной модели человеческого познания, разбив общую интеллект на десять когнитивных доменов, включая рассуждение, память и восприятие. Применение этого подхода показало "зубчатый" когнитивный профиль современных моделей, где текущие ИИ-системы, несмотря на proficiency в знаниемких областях, имеют критические недостатки в базовом когнитивном аппарате, особенно в долговременном хранении памяти.

Представленные AGI-оценки количественно определяют как прогресс, так и оставшийся разрыв до достижения AGI: GPT-4 получил 27%, а GPT-5 - 58%. Эта метрика предлагает объективный способ измерения развития систем ИИ и выявления их сильных и слабых сторон, что может направить будущие исследования в области создания более сбалансированных и универсальных искусственных интеллектов.

• Обсуждение в основном вращается вокруг того, что такое AGI и как его измерять, при этом критикуя предложенное в статье определение как "сопоставимость с взрослым человеком" как слишком узкое и не учитывающее другие формы интеллекта.
• Участники спора подчеркивают, что AGI не может быть измерено только через тесты на "когнитивные способности", поскольку эти тесты не охватывают такие аспекты как эмоциональный интеллект, физическое взаимодействие с миром и социальные навыки.
• Также поднимается вопрос о том, что если AGI определяется как "способность к обучению", то LLM уже достигли этого, но при этом они не обладают другими важными чертами интеллекта, такими как самостоятельность, мотивация и физическое взаимодействие с миром.
• Наконец, критикуется сама статья за то, что она не предлагает конкретного определения AGI, вместо этого полагаясь на устаревшую теорию CHC, которая сама по себе неполна и не охватывает такие важные аспекты интеллекта как мотивация и саморегуляция.

Отношение 987654321/123456789 удивительно близко к 8 (8.0000000729), но это не случайность. Автор исследовал, является ли это свойство специфичным для десятичной системы, и обнаружил, что в других системах счисления наблюдается схожая закономерность. В шестнадцатеричной системе 0xFEDCBA987654321/0x123456789ABCDEF ≈ 14, а в общем виде для основания b отношение числа из цифр в порядке убывания к числу из цифр в порядке возрастания всегда близко к b-2.

Математически это выражается формулой: num(b)/denom(b) = b - 2 + (b-1)/denom(b), где num(b) и denom(b) — числа, составленные из цифр в порядке убывания и возрастания соответственно. Проверка для оснований до 1000 подтверждает это соотношение. Более точная аппроксимация, предложенная в комментариях, выглядит как (b-2) + (b-1)^3 / b^b, что объясняет, почему в шестнадцатеричной системе результат настолько близок к целому числу 14.

• Обсуждение охватывает широкий спектр тем — от детских наблюдений за калькулятором до сложных числовых совпадений в разных системах счисления, включая влияние ошибок округления и точность вычислений.
• Участники делятся личными историями о том, как в детстве они замечали закономерности в работе калькулятора, что подчеркивает универсальность и влияние этих наблюдений.
• Обсуждается взаимосвязь между доказательством и компьютерной проверкой, где скрипт или код может служить иллюстрацией, но не может полностью заменить полноценное математическое доказательство.
• Рассматриваются различные числовые совпадения, такие как 987654321/123456789 8, и их обобщения в других системах счисления и обратные варианты.
• Поднимается вопрос о том, как эти совпадения влияют на разработку программного обеспечения и как они могут быть использованы для обучения и визуализации.

Автор столкнулся с проблемой агрессивных ботов, собирающих данные для обучения LLM, которые составили 99% трафика на его сервере. В отличие от поисковых роботов, эти боты игнорируют robots.txt, постоянно меняют IP-адреса и отправляют множество запросов в секунду. Попытки блокировать их через IP-списки, ограничения по скорости или защитные стены (CAPTCHA, paywall) оказались неэффективными, так как боты просто находили обходные пути, а защитные меры мешали обычным пользователям.

Самым эффективным решением оказалось создание динамического генератора бессмысленного контента — "Markov babbler", который потребляет всего около 60 микросекунд процессорного времени на запрос и использует 1.2 МБ памяти. Этот подход не требует поддержки черных списков и позволяет эффективно "кормить" ботов, не тратя ресурсы на передачу реальных данных. Автор подчеркивает, что его контент лицензирован CC BY-NC-SA 4.0, но явно не разрешен для использования в обучении ML/LLM.

• Основной метод борьбы с AI-скраперами — генерация бессмысленного контента через Markov-цепи или gzip-бомбы, чтобы увеличить затраты скраперов на обработку данных.
• Этические риски: загрязнение обучающих данных LLM может привести к непредсказуемым последствиям и нарушению доверия к системам ИИ.
• Технические альтернативы: использование Basic Auth с публичными учётными данными или редирект на специализированные сервисы вроде "Markov Babbler".
• Проблема масштабирования: массовое применение методов защиты может привести к блокировке легитимного трафика и снижению репутации сайта.
• Эффективность сомнительна: современные LLM могут детектировать мусорный контент, а скраперы легко обходят простые защиты (например, через браузерные прокси).

Любой сервер с SSH-доступом может стать Git-сервером. Достаточно клонировать репозиторий через git clone ssh://username@hostname/path/to/repo, а для отправки изменений добавить на сервере git config receive.denyCurrentBranch updateInstead. Этот подход идеален для синхронизации кода между устройствами или работы с файлами на сервере без задержек.

Для публикации кода через веб нужно указать веб-серверу путь к Git-репозиторию и выполнить git update-server-info. Чтобы это происходило автоматически, можно настроить хук post-update, который будет запускать эту команду после каждого обновления. Хуки также могут использоваться для запуска статических генераторов сайтов — автор блога успешно применяет этот метод для своего сайта, получая преимущества локальной работы и автоматического развёртывания.

Такой подход обеспечивает встроенное резервное копирование: при поломке сервера данные останутся на ноутбуке, и наоборот. Git-трекинг версий предотвращает случайные удаления и упрощает отладку ошибок.

• Обсуждение охватило широкий спектр тем: от фундаментальных концепций (bare-репозитории, push-в-в-ssh, хуки) до практических аспектов (самостоятельный хостинг, CI/CD, бэкапы).
• Участники подчеркнули, что Git изначально задумывался как распределённая система без необходимости в централизованном хостинге, и что это встроено в его архитектуру.
• Были упомянуты различные инструменты и практики, такие как git init --bare, git daemon, git-shell, хуки и т.д., как часть более широкого обсуждения о том, как Git может быть использован для хостинга репозиториев.
• Обсуждались также более широкие темы, такие как философия open-source, централизация против децентрализации, и как GitHub/GitLab и подобные платформы влияют на разработку ПО и сообщество.

Памятник в Баркинге напоминает о трагедии асбестового прошлого Великобритании. В 2022 году здесь открыли мемориал "В память о тех, кто потерял жизнь из-за воздействия асбеста". Причина проста: Баркинг имеет одну из самых высоких в стране смертностей от асбестозависимых заболеваний. Корень зла — огромная фабрика Cape Asbestos, работавшая с 1913 по 1968 год. Рабочие, не имея средств защиты, перерабатывали асбест, не зная его смертельной опасности. Их дети играли в пыли, отравленной волокнами, а локальная мезотелиома получила прозвище "Баркингский кашель". Запрет асbesta вступил в силу лишь в 1985 году.

Наследие фабрики все еще ощущается. Закрытый завод снесли, но на его месте построили непривлекательный жилой комплекс Харц Лейн. Две башни этого комплекса сейчас планируют снести из-за пожарной опасности, но работы осложняются загрязнением почвы асбестом. Земля под жильем может остаться "ядерным" временем. Мемориал, установленный в сквере у Town Hall, призывает "Помнить мертвых и бороться за живущих", напоминая о непреложной связи прошлой безответственности и современных проблем.

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

Advent of Code 2025 — это календарь программистических головоломок на каждый день декабря, доступных для решения на любом языке программирования. Созданный Эриком Вастлом, этот проект подходит для любого уровня подготовки — от новичков до опытных разработчиков. Участники используют его для подготовки к собеседованиям, обучения в компаниях, университетских курсов или просто для практики. Не требуется глубоких знаний компьютерных наук — достаточно базовых навыков программирования и решения задач. Все задачи можно решить на десятилетнем оборудовании за не более 15 секунд.

Проект поддерживается через AoC++ и социальные сети. Если вы застряли, автор советует проверять решения на примерах, создавать тестовые случаи и обращаться за помощью в subreddit. В разделе FAQ освещены вопросы аутентификации через OAuth, сложности задач (которые обычно возрастают со временем), разблокировки задач в полночь по EST, а также возможность участия в соревнованиях через приватные рейтинги.

• Сокращение до 12 дней вместо 25 вызвало бурную дискуссию: часть сообщества считает, что это разрушает саму суть "Advent of Code", в то время как другие отмечают, что это снизит нагрузку на автора и позволит ему продолжать проект.
• Пользователи отмечают, что сокращение до 12 дней делает невозможным привычное соревнование за лидербордом, и что это может оттолкнуть некоторых участников.
• Некоторые участники выразили обеспокоенность тем, что сокращение может повлиять на качество головоломок, так как автор будет иметь меньше времени на их разработку.
• Некоторые участники предложили альтернативы, такие как выпуск головоломки каждые два дня вместо ежедневного выпуска, что позволило бы сохранить привычный формат мероприятия.
• Участники также обсудили, что сокращение до 12 дней может повлиять на их собственные планы на декабрь, и что они могут не успеть решить головоломки до Рождества, что для них является важным элементом мотивации.

Это репозиторий Apple с названием "pico-banana-400k", но предоставленный контент содержит только навигационную часть страницы GitHub без информации о самом проекте. В тексте отсутствует описание содержимого репозитория, его цели или функциональности.

Из доступных данных известно только, что проект принадлежит Apple (из имени пользователя "apple"), но без доступа к содержимому репозитория невозможно предоставить детали о его назначении, коде или связанных технологиях. Для получения полезной информации потребуется прямой доступ к файлам и документации внутри репозитория.

• Nano-Banana-400K — это набор из ~400K примеров редактирования изображений, созданный с помощью Gemini-1.5-Pro, который используется для обучения и оценки моделей редактирования изображений.
• Лицензия CC-BY-NC-ND запрещает коммерческое использование и создание производных работ, что ставит под сомнение полезность набора для исследователей и разработчиков.
• Набор включает в себя изображения, которые могут быть использованы для обучения моделей, которые могут быть использованы для создания подобных изображений, что вызывает вопросы об этике и правовом статусе таких наборов данных.
• Несмотря на то, что набор был создан с помощью Gemini-1.5-Pro, Google не является партнером в этом проекте, и вопросы об использовании набора в коммерческих целях остаются открытыми.