AlpineBSD: ОС на ядре NetBSD, где любой код от ИИ считается «скомпрометированным»

Споры о том, пускать ли ИИ-сгенерированный код в open source, перешли от дискуссий в рассылках к целым операционным системам. Проект AlpineBSD, анонсированный Дрю ДеВо (известным как sircmpwn), делает отказ от генеративного ИИ не пожеланием, а базовым принципом.

Что внутри

AlpineBSD собирают из знакомых деталей. Ядро, стандартная библиотека libc и низкоуровневые утилиты вроде mount приходят из NetBSD. Поверх них работает пользовательское окружение, вдохновлённое Alpine Linux: базовый набор утилит на BusyBox, пакетный менеджер apk, система инициализации s6. Приложения по возможности берутся из репозиториев Alpine.

Готовых установочных образов пока нет, но систему можно поставить вручную. Код и репозиторий портов размещены на Sourcehut.

Такая комбинация не случайна. Инструментарий Alpine легко переносится: apk уже используют Chimera Linux, где нет компонентов GNU, но много от FreeBSD, и Adélie Linux. AlpineBSD пробует тот же приём на ядре из мира BSD.

Что значит «скомпрометировано»

Главная формулировка проекта: любое ПО, будь то исходники, документация или бинарные файлы, которое хотя бы частично содержит результат работы генеративной модели, считается скомпрометированным. Порога «допустимой доли» нет. Достаточно, чтобы фрагмент написал LLM.

Это продолжение линии NetBSD. Ещё в 2024 году проект прописал в правилах внесения изменений, что код, созданный большой языковой моделью, считается скомпрометированным. По сути, AlpineBSD наследует политику апстрима и распространяет её на весь дистрибутив.

Обратите внимание на контекст. В июле Линус Торвальдс заявил, что Linux не относится к проектам, выступающим против ИИ. После этого, по данным источника, NetBSD столкнулся с заметным ростом интереса и объёма пожертвований. То есть позиция «без ИИ» стала для части сообщества самостоятельной ценностью, которую готовы поддерживать деньгами.

Для справки: недавно вышла NetBSD 11.1. Проект поддерживает 15 семейств CPU, 8 первичных портов (amd64, i386, evbarm, evbmips, evbppc, hpcarm, sparc64 и xen) и 49 вторичных, включая alpha, hppa, m68k, sh3, sparc и vax.

Ограничения и практический вывод

Главный вопрос: как это проверять. В анонсе нет описания механизма, которым проект будет отличать человеческий код от сгенерированного. Скорее всего, это будет опираться на добросовестность авторов и на происхождение зависимостей. Пакеты из Alpine берутся «по возможности», а значит, граница чистоты в реальности будет размытой: никто не гарантирует, что в апстримных программах нет вставок от ассистентов.

Плюс проект совсем молодой: без образов, без стабильного релиза, с ручной установкой. Использовать его в продакшене рано.

Что это значит на практике:

• Если вы поддерживаете open source, стоит заранее определить политику по ИИ-коду. Требования к контрибьюторам уже становятся предметом выбора пользователей и спонсоров.
• Если вы продаёте продукт на основе открытых компонентов, проверьте лицензионные и репутационные риски: часть сообщества считает ИИ-код проблемой.
• Если вы строите инструменты для кодинга с ИИ, учитывайте, что в некоторых экосистемах ваши результаты просто не примут. Маркировка происхождения кода может стать полезной функцией.

AlpineBSD вряд ли станет массовой ОС. Но как сигнал он важен: «без ИИ» превращается в отдельную нишу с собственной аудиторией, и отношение к сгенерированному коду всё чаще определяет, куда сообщество несёт внимание и деньги.