Hacker News Digest

За двадцать лет автор провёл цифровую археологию, чтобы возродить классическую Unix-игру Conquer 1987 года. Изначально опубликованная в USENET как "conquest – middle earth multi-player game", эта многопользовательская стратегия в мире Средиземья повлияла на множество последующих игр. В 2006 году автор начал поиск создателей Эдварда Барлоу и Адама Брайанта, чтобы relicensировать код под GPL. Как отметил Барлоу: "copyleft didnt exist when i wrote it and it was all for fun so...".

Поиск авторов напоминал детективную работу - адреса электронной почты 80-х были недоступны, приходилось следовать цифровым следам. После пятилетнего ожидания в 2011 году Брайант сам нашёл статью автора и разрешил распространение кода под GPL. В 2025 году выяснилось, что Брайант создал полную переработку - Conquer Version 5 с расширенными возможностями, которую также согласовал лицензировать под GPL. В истории игры также участвовал MaF, создавший утилиты PostScript для генерации печатных карт.

• Участники обсуждают исторические текстовые игры (Conquer, Trek, Netrek, Empire) и их сохранение для будущих поколений.
• Поднимаются вопросы лицензирования и переноса старого кода на современные платформы, включая использование веб-интерфейсов (ttyd) и репозиториев (bsdgames).
• Автор статьи (vejeta) активно участвует, объясняет сложности сохранения Conquer и делится опытом поиска и реставрации кода.
• Участники делятся воспоминаниями о старых играх и системах (SunOS, IBM minicomputers, PLATO), а также предлагают идеи для музеев и возрождения "Play-by-Mail" игр с использованием ИИ.

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

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

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

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

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

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

В Ubuntu 25.10 обнаружен баг в Rust-версии команды date из пакета uutils, нарушающий автоматические обновления системы. Проблема затронула облачные развертывания, контейнеры, десктоп и серверные версии. Системы с rust-coreutils версии 0.2.2-0ubuntu2 или ранее подвержены уязвимости, исправленной в версии 0.2.2-0ubuntu2.1. Интересно, что баг не влияет на ручные обновления через apt.

Ubuntu реализует проект "окисления" дистрибутива, переходя на uutils и sudo-rs для версии 25.10, чтобы оценить пригодность Rust-утилит для долгосрочного выпуска в апреле. Этот переход вызвал дискуссию: одни считают, что замена проверенных десятилетиями C-утилит неизбежно приведет к краткосрочным проблемам, другие поддерживают инициативу как необходимую. Также поднимаются вопросы лицензирования MIT вместо GPL и управления проектом uutils.

• Обсуждение вокруг замены GNU coreutils на Rust-версию свелось к тому, что проблема лицензии (GPLv3 vs MIT), а не безопасность, и что в конце концов, как и следовало ожидать, никакой "серьёзной" уязвимости там не было.
• Участники обсуждения отмечают, что даже если бы это была уязвимость, то это была бы не более чем типичная для мейнтейнеров Ubuntu ошибка пакетов, которые не были бы исправлены в нужное время.
• Сообщество высказывает опасения по поводу переписывания критически важных утилит, которые были проверены временем, на новом и потенциально менее стабильном языке программирования.
• Некоторые комментаторы подчеркивают, что обсуждение не касается безопасности, а вопрос лицензии и что это не более чем естественное течение времени и что в конце концов, как и следовало ожидать, никакой "серьёзной" уязвимости там не было.

Steinberg выпустил VST SDK 3.8.0 с важными изменениями, включая переход на открытый исходный код под лицензией MIT. Основные обновления включают поддержку MIDI 2.0 с новыми интерфейсами IMidiLearn2 и IMidiMapping2, которые заменяют предыдущие версии, а также добавление отсутствующего перечисления ControllerNumbers для MIDI 1.0. Появилась предварительная поддержка Wayland в Linux с интерфейсами IWaylandHost и IWaylandFrame.

VSTGUI обновлен до версии 4.15.0 с новым API Task Concurrency для выполнения задач в фоновых потоках, поддержкой пользовательских макетов вида, включая GridLayouter, аналогичный CSS Grid, и скриптингом для UIDescription. Также добавлен новый текстовый редактор и предварительная поддержка Wayland. В SDK исправлены ошибки в cmake, helper classes и VST3PluginTestHost, а документация адаптирована под новую модель лицензирования.

• Steinberg/Yamaha открыли исходники VST3 SDK под GPL-3, что стало возможным благодаря давлению со стороны CLAP и сообщества.
• Это снимает юридические барьеры для распространения VST3-плагинов в свободных программах и делает возможным включение SDK в дистрибутивы Linux.
• Одновременно, Steinberg открыла исходники примеров и утилит, что упрощает разработку плагинов и хостов.
• Несмотря на то, что VST3 всё ещё более сложен в реализации, чем CLAP, сообщество продолжит использовать VST3 из-за его широкой поддержки.
• Сообщество приветствует этот шаг как победу свободного программного обеспечения в аудио-индустрии.

Ричард Столлман выступает против превращения GCC бэкенда в библиотеку, аргументируя это защитой свободного программного обеспечения. Он предупреждает, что компании неизменно стремятся сделать ПО несвободным, и некоторые создали бы несвободные дополнения к GCC, если бы им это позволили. Именно требование GPL заставило авторы фронтендов для C++ и Objective-C сделать их свободными, так как они не могли использовать их иначе. Столлман подчеркивает: "Все, что упрощает использование GCC бэкендов без фронтендов, ставит под угрозу наше влияние на то, чтобы новые фронтенды оставались свободными".

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

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

EUPL — это публичная лицензия Европейского Союза, созданная для распространения ПО, разработанного европейскими институтами. Она обеспечивает юридическую точность в терминах европейского права, включая чёткие формулировки об ограничении ответственности и гарантий, что отличает её от многих лицензий, ориентированных на законодательство США. Важной особенностью является доступность на всех официальных языках ЕС, что обеспечивает равную юридическую силу в разных юрисдикциях.

Лицензия имеет сильный copyleft, предотвращающий присвоение улучшенных версий ПО третьими сторонами. EUPL совместима с другими популярными лицензиями, такими как GPL, через специальное положение о совместимости, позволяющее комбинировать код под разными лицензиями. Хотя изначально предназначена для госсектора, она может использоваться любым правообладателем ПО.

• EUPL моделируется после GPLv3, закрывает SaaS-лазейку, но исключает положения о тивоизации и DRM, а также явно определяет юрисдикцию ЕС.
• Лицензия фокусируется на юридической интероперабельности в ЕС, имеет список совместимых лицензий, но её совместимость с GPL вызывает споры о потенциальном релизайсинге.
• EUPL мало распространена, воспринимается как политический/правовой компромисс, а не идеологическое заявление, и её практическая полезность ставится под сомнение.
• Некоторые участники обсуждают выбор между EUPL и AGPLv3, отмечая модификации EUPL и её применимость вне ЕС.
• Поднимаются вопросы о лицензиях с ограничительными клаузами (например, против оружия или ископаемого топлива), но отмечается их непопулярность из-за неоднозначности.

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

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

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

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

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

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

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

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

GrapheneOS получает предварительный доступ к бюллетеням безопасности Android и уже готовит обновления.

• Google на 3–4 месяца блокирует публикацию исходников патчей безопасности, чтобы OEM-ы успели обновить свои устройства, но при этом злоумышленники получают «белый свет» на использование уязвимостей.
• GrapheneOS видит патчи, но не может включать их в открытые сборки, пока не истечёт эмбарго, что ставит пользователей в уязвимое положение.
• Предложенный выход — выпускать временно бинарные обновления (opt-in), чтобы сообщество могло запрашивать GPL-исходники и реверс-инжирить исправления.
• Участники считают, что OEM-ы легко могли бы тестировать патчи в CI за дни, но экономия и нежелание тратиться на безопасность тормозят процесс.
• Некоторые подозревают, что затягивание обновлений выгодно не только OEM, но и госструктурам, которым даётся «окно» для эксплойтов.