git-хостинги: туда, сюда и обратно - ч.2
В качестве одной из альтернатив Github представлялся протокол децентрализованной разработки Radicle, за развитием которого я следил с 2018 года.
В презентации проекта обосновывается мотивация основателей и одновременно даётся ответ на вопрос "А чем вам Github не угодил?". Если коротко, то по следующим ключевым причинам: 1) open source - это общественное благо, к которому имеют доступ все без исключения люди; 2) общественное благо не может хоститься на проприетарной платформе, потому что это противоречит п.1; 3) Github принадлежит одной единственной всем известной мегакорпорации, которая располагает всеми инструментами, чтобы ограничивать доступ к этим общественным благам; 4) корпорация работает в конкретной юрисдикции и подчиняется всем её требованиям, что налагает дополнительные риски. Также там содержится объяснение по какой причине федеративные self-hosted решения не взлетают и не могут быть полноценной альтернативой.
Но вернёмся к Radicle. Это решение надстраивает над git транспортные механики обмена патчами на базе протокола Gossip, что делает возможным синхронизацию без центрального сервера - каждый клонирующий становился не просто бэкапом, а полноценным seed-узлом (как в bittorrent), участвующим в обмене обновлениями репозитория. Пользователи идентифицируются ed25519-публичным ключём - никаких email-ов и доменов.
Ребята в своё время подсуетились, сделав DAO и выпустив токен, благодаря чему до сих пор бойко поддерживают проект. В конце 2024 года наконец релизнули сильно отрефакторенную версию 1.0 и мы с командой выступили бета-тестерами первой версии Radicle, планируя перевести со временем туда всю разработку. Мы развернули свои seed-ноды (веб-интерфейс можно посмотреть на git.robossembler.org) и начали пробовать в тесном контакте с командой разработчиков в их Zulipchat. Миграция сводилась к установке ноды и добавлению нового remote к текущему локальному репозиторию. Однако, довольно быстро стало понятно, что переход будет сложноват с точки зрения UX. Помимо особых механизмов авторизации, в Radicle весьма оригинальная схема внесения изменений. Там нет merge и pull request'ов, изменения в репозитории вносятся через патчи (по сути это возврат к старому-доброму обмену патчами только без email - см. collaboration in a radicle way) и требуют от пользователя относительно глубокого знания cli-интерфейса git. У нас довольно много "железных" проектов, которые в принципе довольно туго натягиваются на git, так, в добавок ко всему, инженеры-конструктора, привыкшие к Windows и встроенным в CAD инструментам версионирования (они называются PDM), обычно пользуются графическими фронтенд-приложениями и не суются в командную строку. Дополнительно осложняет перенос проектов отсутствие на текущий момент поддержки LFS для больших бинарных файлов (в CAD и CG домене актуально).
В общем, Radicle оказался для нас слишком радикальным и мы вернулись на какое-то время обратно на Gitlab в поисках другого решения, оставив Radicle роль бета-сервиса для публичных зеркал в децентрализованном мире.
#radicle #p2p #github
В качестве одной из альтернатив Github представлялся протокол децентрализованной разработки Radicle, за развитием которого я следил с 2018 года.
В презентации проекта обосновывается мотивация основателей и одновременно даётся ответ на вопрос "А чем вам Github не угодил?". Если коротко, то по следующим ключевым причинам: 1) open source - это общественное благо, к которому имеют доступ все без исключения люди; 2) общественное благо не может хоститься на проприетарной платформе, потому что это противоречит п.1; 3) Github принадлежит одной единственной всем известной мегакорпорации, которая располагает всеми инструментами, чтобы ограничивать доступ к этим общественным благам; 4) корпорация работает в конкретной юрисдикции и подчиняется всем её требованиям, что налагает дополнительные риски. Также там содержится объяснение по какой причине федеративные self-hosted решения не взлетают и не могут быть полноценной альтернативой.
Но вернёмся к Radicle. Это решение надстраивает над git транспортные механики обмена патчами на базе протокола Gossip, что делает возможным синхронизацию без центрального сервера - каждый клонирующий становился не просто бэкапом, а полноценным seed-узлом (как в bittorrent), участвующим в обмене обновлениями репозитория. Пользователи идентифицируются ed25519-публичным ключём - никаких email-ов и доменов.
Ребята в своё время подсуетились, сделав DAO и выпустив токен, благодаря чему до сих пор бойко поддерживают проект. В конце 2024 года наконец релизнули сильно отрефакторенную версию 1.0 и мы с командой выступили бета-тестерами первой версии Radicle, планируя перевести со временем туда всю разработку. Мы развернули свои seed-ноды (веб-интерфейс можно посмотреть на git.robossembler.org) и начали пробовать в тесном контакте с командой разработчиков в их Zulipchat. Миграция сводилась к установке ноды и добавлению нового remote к текущему локальному репозиторию. Однако, довольно быстро стало понятно, что переход будет сложноват с точки зрения UX. Помимо особых механизмов авторизации, в Radicle весьма оригинальная схема внесения изменений. Там нет merge и pull request'ов, изменения в репозитории вносятся через патчи (по сути это возврат к старому-доброму обмену патчами только без email - см. collaboration in a radicle way) и требуют от пользователя относительно глубокого знания cli-интерфейса git. У нас довольно много "железных" проектов, которые в принципе довольно туго натягиваются на git, так, в добавок ко всему, инженеры-конструктора, привыкшие к Windows и встроенным в CAD инструментам версионирования (они называются PDM), обычно пользуются графическими фронтенд-приложениями и не суются в командную строку. Дополнительно осложняет перенос проектов отсутствие на текущий момент поддержки LFS для больших бинарных файлов (в CAD и CG домене актуально).
В общем, Radicle оказался для нас слишком радикальным и мы вернулись на какое-то время обратно на Gitlab в поисках другого решения, оставив Radicle роль бета-сервиса для публичных зеркал в децентрализованном мире.
#radicle #p2p #github
👍10