Hacker News Digest

• Проекты охватывают от автомасштабирования кластера до генератора историй, демонстрации важности локального хранения данных и даже до создания языка программирования.
• Среди прочего: само-обучающийся инструмент для веб-API, инструмент для визуализации данных, инструмент для создания цветовых палитр, инструмент для создания и ведения списков задач, инструмент для создания и ведения списков задач, инструмент для создания и ведения списков задач, инструмент для создания и ведения списков задач.
• Проекты варьируются от OSS до коммерческих, от хобби до полностью само-финансируемых, и от индивидуальных до коллективных.
• Некоторые проекты уже имеют пользователей, другие находятся в стадии альфа или бета-тестирования.

В индустрии безопасности наблюдается растущая проблема: ИИ-системы массово генерируют ложные сообщения об уязвимостях, которые затем отправляются настоящим экспертам на проверку.

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

Результат? По данным Дэниела Стернхауса (maintainer curl), до 20% всех сообщений об уязвимостях — это ложные срабатывания ИИ, в то время как реальные уязвимости составляют лишь около 5%. Это означает, что на каждую реальную проблему приходится четыре ложных, а на их проверку уходят часы работы экспертов-добровольцев.

Ситуация усугубляется тем, что проверка каждого такого отчёта требует совместных усилий нескольких человек. Например, один человек пытается воспроизвести проблему по шагам из отчёта (но шаги могут вести к несуществующим функциям). Другой — анализирует исходный код, чтобы понять, есть ли там такая уязвимость. Третий — проверяет гипотезы коллег. В итоге, одна ложная тревога съедает несколько человек-часов.

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

• Тема: «богатство, созданное на неоплаченном труде» — и LLM-технологии усугубляют проблему, а не GPL/AGPL-лицензии, как будто бы это имело значение.
• Проблема «hallucination» в LLM — это не просто баг, а фундаментальная проблема, и неясно, можно ли ее решить без радикального изменения архитектуры.
• Вопрос о том, что open-source сообщество может быть «обязано» Google, если бы они использовали GPL-библиотеки, остается открытым.
• И, возможно, что-то вроде «поддержки» open-source сообщества со стороны крупных технологических компаний может быть не столько «добровольной» инициативой, сколько необходимостью.

В предоставленном тексте отсутствует содержимое самого issue #21647 "Docker release?" в репозитории minio/minio. Видна только навигационная структура GitHub без основного текста обсуждения. Для создания точного пересказа необходимо содержимое самого issue, включая описание проблемы, комментарии и любые детали, связанные с выпуском Docker-образа MinIO.

• MinIO прекращает публикацию готовых Docker-образов, что вызвало волну обсуждений о «rug pull» и ожиданиях от OSS-проектов.
• Участники обсуждают, что компания имеет право прекратить предоставлять бесплатные образы, но отсутствие предупреждения и альтернативы вызывает раздражение.
• Появились альтернативы в виде Garage и SeaweedFS, но у них есть свои ограничения.
• Некоторые участники подчеркивают, что OSS-проекты не обязаны предоставлять бинарники, но при этом они также напоминают, что и сообщество не обязано использовать именно этот проект, если он становится менее удобным.

• curl: 180 тыс. строк, 1,4 тыс. авторов, 20–25 активных в месяц, один зарплатный разработчик — сам Стенберг.
• Используют 47 брендов авто; спонсоров — 0.
• Компании требуют поддержку, аудиты, соответствие CRA, шлют угрозы «I will slaughter you».
• LLM-боты сыплют ложными баг-репортами, ИИ-скраперы ддосят сайт: 99,99 % трафика — боты.
• Поддержка = одному человеку: безопасность, документация, инфраструктура, иногда фичи.
• Письмо 11-летнего ребёнка — единственное тёплое «спасибо».

• Компании хотят платить за OSS, но бюрократия, налоги и отсутствие «адреса» делают это почти невозможным.
• Поток фейковых «AI-уязвимостей» превратился в охоту за CVE ради резюме и баг-баунти, отнимая время у maintainer’ов.
• curl получил 200 тыс. € от немецкого Sovereign Tech Agency — редкий пример гос-финансирования.
• Утопичная идея «AGPL-шантажа» и GoFundMe мгновенно оборачивается форком и потерей сообщества.
• Нет единого «клоут-индекса» библиотек: кто действительно критичен — видно только изнутри.

Как RubyGems.org защищает инфраструктуру сообщества

RubyGems.org применяет многослойную защиту:

1. Автоматика – каждый gem сканируется статическими и динамическими анализаторами (инструменты Mend.io, созданные мейнтейнером Maciej Mensfeld).
2. Оценка риска – высоко-рисковые пакеты переходят на ручную проверку.
3. Ретро-скан – старые версии перепроверяются при улучшении детекторов.
4. Внешние источники – данные от партнёров и других реестров.
   Таким образом 70–80 % вредоносных пакетов ловят до публикации.

Что происходит после флага
Инженер безопасности подтверждает вредоносность (≈ 5 % оказываются ложными срабатываниями), затем gem удаляется, действия логируются, а похожие имена блокируются.

Инцидент Socket.dev

• 20 июля 2025 – система отметила подозрительные гемы, подтверждена кража учётных данных.
• 23–28 июля – удалены почти все пакеты и аккаунты.
• 7 августа – после публикации Socket.dev удалили ещё 16 связанных гемов.
  Всего убрали все пакеты злоумышленника; популярные библиотеки не пострадали.

Сообщество
Сообщайте о проблемах: security@rubygems.org или Slack Bundler. Команда быстро реагирует и благодарит за помощь.

Реальность безопасности цепочки поставок
В среднем еженедельно удаляется один вредоносный или спам-пакет. Работа ресурсоёмка и держится на спонсорах (Mend.io, Alpha-Omega) и волонтёрах. Поддержите RubyGems через RubyGems Supporter Program.

Инцидент показал: системы сработали, угроза была локализована. Безопасность OSS – общее дело.

• Один из мейнтейнеров gem-ов сознательно обходит MFA-ограничения RubyGems, чтобы казаться «ненадёжным» и избежать ответственности.
• Участники хвалят Ruby/Rails как «скучный», но надёжный и продуктивный инструмент, противоположный эншиттификации.
• Критикуют отсутствие обязательной подписи гемов и вспоминают, что старая система подписей так и не прижилась из-за нехватки инфраструктуры.
• Мейнтейнер unicorn считается эксцентричным: отказывается от JavaScript и GitHub, а в README сам проект называют «нанёсшим вред экосистеме».
• Сообщество обсуждает, что отсутствие коммерческого давления помогает Rails оставаться стабильным и «не-эншиттифицированным».

С днём 100000-летия, Debian!

Сегодня проекту исполняется 100 000 лет — в двоичной системе, или 0x20 (32) в шестнадцатеричной. С момента основания 16 августа 1993 года Debian вырос из небольшого начинания в один из крупнейших дистрибутивов свободного ПО, охватывающий всё — от встраиваемых устройств до кластеров.

Благодарим всех участников и пользователей за вклад и поддержку. Особая признательность командам FTPMaster, Release, Installer, Images, Press, разработчикам, документаторам, переводчикам и всем, кто помог сделать свежий релиз Trixie возможным. Отдельное спасибо Ансгару за решение проблем с подписью кода.

Празднуем сегодня и продолжаем готовить ещё более мощный Forky.

• Участники поздравляют Debian с «100000-м» (бинарным) днём рождения и вспоминают Иэна Мёрдока.
• Debian хвалят за верность идеалам OSS, надёжность «на века» и удобство для headless-систем.
• Идут шутки о «100000nd birthday» и лингвистике: «th» допустимо, поскольку в бинарной записи последняя цифра 0.
• Кто-то планирует отметить своё 1 000 000-летие, а другой уже выбрал песню на будущий «бинарный» юбилей.

• Пользователи жалуются, что при росте контекста модель «убивается» скоростью обработки, хотя генерация токенов быстрая.
• Вопросы безопасности: guard-rails вшиты, но есть форки «abliterated» и джейлбрейки, хотя они делают модель глупее.
• Дискуссия о цене: 64–128 ГБ ОЗУ и RTX 3060 называют как «дешёвое» железо (< $1000), но для многих всё ещё дорого.
• На 64 ГБ Mac и 16 ГБ MacBook Air удаётся запускать 20B и 4B квантованные модели, но function calling в llama.cpp пока сломан.
• Появился патч, который должен починить llama.cpp; оптимизация экспертных слоёв через regex работает и на других MoE-моделях.

• Сгенерированное ИИ изображение, где ИИ руками «отвергает» меня. Очень мета.

В октябре 2024 Anthropic представила «Claude Computer Use», позволяющую ИИ управлять компьютером, копировать данные из браузера в таблицы и т.п. Я поддерживаю библиотеку для управления компьютером и этой весной решил разобраться, как они это делают. К моему удивлению, Anthropic использует мою библиотеку enigo.

Проверить использование enigo в Claude Desktop для macOS можно так:

• 7z x Claude.dmg
• perl -nle 'print $& while /.{0,67}enigo.{0,30}/g' Claude/Claude.app/Contents/Resources/app.asar.unpacked/node_modules/claude-native/claude-native-binding.node Вывод содержит путь к enigo-0.2.1/src/macos/macos_impl.rs

На Windows:

• 7z x Claude-Setup-x64.exe
• 7z x AnthropicClaude-0.11.6-full.nupkg
• perl -nle 'print $& while /.{0,75}enigo.{0,26}/g' Claude-Setup-x64/AnthropicClaude-0.11.6-full/lib/net45/resources/app.asar.unpacked/node_modules/claude-native/claude-native-binding.node Вывод указывает на enigo-0.2.1/src/win/win_impl.rs

Я горжусь, что enigo дорос до продакшена у компании с огромным бюджетом. Эмуляция ввода сложна из‑за слабой документации и платформенных особенностей. На мой взгляд, enigo — отличный выбор: работает на Windows, macOS, *BSD и Linux (Wayland, X11, libei) без root; написан на Rust (безопасность памяти, высокая скорость); самый популярный на crates.io (~300k загрузок, 1200+ звёзд). И всё же тревожно, что мой хобби‑проект установлен на тысячах устройств.

Сколько я на этом заработал? Нисколько: enigo под MIT‑лицензией — можно бесплатно использовать. Взамен — звёзды на GitHub и счётчик загрузок.

Интересно, что Claude Desktop — Electron‑приложение, но есть только для macOS и Windows. Сообщество запустило его на Linux, заменив вызовы enigo заглушками, хотя enigo кроссплатформенна — любопытный выбор.

Через знакомых я узнал об открытой роли в команде, делавшей секретную, ещё не выпущенную функцию Claude Desktop с enigo. Подал заявку, ждал. В итоге пришло письмо: команда не успевает рассматривать дополнительные заявки.

Я бы с радостью поработал в Anthropic: сделать аналог Computer Use, довести Claude Desktop до Linux, вложить свой опыт в эмуляцию ввода и полноценно отполировать enigo, чтобы Anthropic концентрировалась на моделях, а не на капризах ввода.

В целом я счастлив, что enigo в Claude Desktop, и всем об этом рассказываю. Забавно думать, что я метафорически дал Claude руки и ноги — и получить отказ. Письмо написал человек или сам Claude? По крайней мере, теперь я, наверное, в безопасности…

• Обсуждение вокруг автора OSS-библиотеки enigo, которую, по словам поста, использует Claude Desktop; при попытке податься в Anthropic он получил авто‑отказ без рассмотрения, что вызвало резонанс.
• Многие считают, что заявку, вероятно, даже не читали из‑за перегруженных или автоматизированных HR/ATS‑процессов; советуют искать тёплый интро к менеджеру, а не подаваться «в общий ящик».
• Поднята тема лицензий: permissive (MIT) позволяет корпорациям брать код без вклада; участники предлагают рассмотреть MPL/EUPL, Fair Source или даже целевые ограничения, хотя применимость и исполнение спорны.
• Несколько комментаторов призывают Anthropic хотя бы поблагодарить автора, дать консультационный контракт или символическую компенсацию; другие напоминают, что компания волна отбирать кого хочет.
• Обсуждаются возможные факторы отказа: геолокация (США vs Европа), визы, несоответствие профиля «AI‑инженеру», парадоксы найма и предпочтение «низкопрофильных» кандидатов.
• Приводятся похожие кейсы из индустрии: от игнора мейнтейнеров до неудачных интервью у компаний, зависящих от их софта.
• Общий вывод: современный тех‑набор страдает от автоматизации и перегрузки; для кандидатов критичны нетворкинг, прямой контакт с нанимающим менеджером и стратегия видимости, а для OSS — осознанный выбор лицензии.

Discussed here: https://news.ycombinator.com/item?id=44800746 I wrote a detailed breakdown of the models and why this release is a big deal — especially for devs who want to run or fine-tune LLMs locally: https://medium.com/@miguel.paracuellos.inf/openai-just-went-...Curious how