Hacker News Digest

Основатель Pebble Эрик Мигицовский и сообщество Rebble ведут спор о будущем умных часов Pebble. Мигицовский основал Core Devices в 2025 году для возрождения бренда, в то время как Rebble, некоммерческая организация с 2017 года, поддерживает сообщество после закрытия Pebble. Конфликт возник из-за соглашения о платежах $0.20 в месяц на пользователя и спора о правах на данные магазина приложений Pebble (13 000 приложений 2012-2016 годов). Rebble утверждает, что полностью владеет этими данными и хочет создать "закрытый сад", в то время как Мигицовский настаивает на открытости экосистемы.

Rebble обвиняет Мигицовского в "краже" их работы для коммерческих часов, но он отрицает эти обвинения, подчеркивая, что все вклады в PebbleOS были полностью открытыми. В ноябре 2025 года Core Devices отгрузила 5 000 часов Pebble 2 Duos и работает над Pebble Time 2. Мигицовский отмечает, что они перешли на собственный репозиторий из-за долгих проверок PR в репозитории Rebble.

• Rebble опасается вытеснения из экосистемы после предоставления Core доступа к данным магазина приложений, требуя гарантий против создания "враждебного" закрытого сервиса.
• Core Devices (Эрик) стремится использовать инфраструктуру Rebble для возрождения часов, но Rebble видит в этом попытку "ренты" вместо сотрудничества, обвиняя Core в недобросовестных действиях (включая "скрапинг" данных).
• Сообщество разделено: часть пользователей поддерживает Rebble за сохранение открытости, другая — Core за возрождение часов, предлагая технические решения (переход на GPL/AGPL) или альтернативные устройства (BangleJS).
• Проблемы прозрачности: использование Discord вместо публичных каналов усложняет отслеживание решений, а публикация переписки без согласия участников вызывает вопросы о доверии.
• Обе стороны зависят друг от друга (Core — от инфраструктуры Rebble, Rebble — от новых часов), но не осознают этого, ведя к "избегаемому проигрышу" для пользователей.

Команда Rebble обвиняет Core Devices в нарушении соглашения и попытке присвоить их работу. После банкротства Pebble Technology Corporation девять лет назад Rebble и сообщество приложили огромные усилия, чтобы сохранить экосистему часов, потратив сотни тысяч долларов на хостинг и поддержку. Интересно, что текущий магазин приложений Pebble от Core на самом деле работает на инфраструктуре Rebble, а данные в нём на 100% принадлежат Rebble. Как отмечает команда: "Данные за магазином приложений Pebble на 100% от Rebble".

Core требует неограниченного доступа к архивам данных, чтобы делать с ними что угодно, включая создание закрытого магазина приложений. Несмотря на устные обещания, Эрик отказывается закреплять это в письменном соглашении и даже нарушил предыдущее договорённость, скопировав магазин приложений Rebble. Команда подчёркивает: "Мы бы предпочли сотрудничать с ними для создания чего-то великого вместе, но мы достигли тупика".

• Rebble обвиняет Core Devices в попытке получить полный доступ к их базе данных без компенсации, угрожая существованию сообщества.
• Многие пользователи угрожают отменить предзаказы часов Core из-за недоверия и поддержки Rebble.
• Обсуждаются лицензионные вопросы (Apache/AGPL) и этика использования открытого кода и данных.
• Предлагаются альтернативы: партнерство с другими производителями или создание собственных часов сообществом.
• Подчеркивается историческое недоверие к Pebble после продажи компании Fitbit.

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

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

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

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

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

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

Я ухожу с поста сопровождающего libxml2, поэтому проект временно остаётся без поддержки.

До конца 2025 года я буду исправлять регрессии в релизе 2.15.

Спасибо за вашу тяжёлую работу!

Спасибо за долгое сопровождение libxml2!

Я изучаю код libxml2 и libxslt. У меня есть время на поддержку, но нужно разобраться с последними изменениями, например, с управлением буферами ввода-вывода. Как лучше связаться для вопросов?

Спасибо за поддержку ключевых библиотек интернета, используемых в миллионах продуктов по всему миру. Удачи!

От лица миллионов пользователей благодарю за вашу работу!

• Основной сопровождающий libxml2, Nick Wellnhofer, уходит после десяти лет неоплачиваемой работы и форкает проект под лицензией AGPL.
• Сообщество обсуждает кризис поддержки критически важной инфраструктуры из-за проблем с финансированием open-source.
• Поднимается вопрос о чрезмерной сложности XML и необходимости больших библиотек вроде libxml2; предлагаются более минималистичные альтернативы (например, TinyXML2, libexpat).
• Упоминается спорная политика безопасности libxml2 «без эмбарго», что вызывает обеспокоенность по поводу будущих уязвимостей.
• Обсуждается бизнес-модель продажи исключений из GPL для коммерческого использования как потенциальное решение для поддержки.
• Отмечается упадок XSLT из-за проблем с libxml2 и планы по удалению его поддержки из браузеров.
• Высказывается мнение, что сложные стандарты вроде XML с большими RFC являются неустойчивыми и что при выборе технологий следует учитывать простоту поддержки.

Open SWE — первый open-source агент для асинхронной разработки в облаке.
Подключается к вашим репозиториям GitHub, берёт задачи из issue и самостоятельно исследует код, пишет, тестирует, исправляет ошибки и открывает pull-request.

Как попробовать

1. Перейдите на swe.langchain.com.
2. Авторизуйтесь в GitHub и выберите репозитории.
3. Добавьте ключ Anthropic в настройках.
4. Создайте задачу и наблюдайте.

Особенности

• Человек в цикле: агент показывает план, вы можете править, удалять или дополнять его без перезапуска.
• Обратная связь на ходу: во время выполнения можно отправить новое сообщение — агент учтёт его без сбоя.
• GitHub-нативность: задача = issue, результат = PR. Достаточно добавить метку open-swe-auto, чтобы агент начал работу.
• Безопасность: каждая задача запускается в изолированном контейнере Daytona.
• Облако: параллельные задачи, никакой нагрузки на ваш ПК.
• Планирование и ревью: отдельные агенты Planner и Reviewer минимизируют поломки CI.

• Часть сообщества мечтает о полностью локальных, прозрачных агентах без облачных «чёрных ящиков» и навязанных UI.
• Другие уверены, что будущее за долгоживущими, асинхронными, облачными агентами, которые уже почти умещаются в памяти пары вкладок Chrome.
• Утилита вызывает подозрения: AGPL-код Daytona не раскрывает control-plane, а README сразу предлагает регистрацию в сервисе.
• Пользователи жалуются на невосстановимые ошибки и просят переноса контекста между сессиями.
• Скептики напоминают: VRAM всё ещё редкость, а «облачная» модель потребления данных не способствует технологической независимости.