Исправление kmeaw, (текущая версия) :
git децентрализован в том смысле, что он может функционировать в сети равноправных участников. Ему всё равно, как работает DNS-резолвер и IP-маршрутизация в твоей системе. Можешь даже свой транспорт положить в /usr/libexec/git-core/git-remote-* или сделать git clone fd::7,8/astral:linux, предварительно подключив файловые дескрипторы 7 и 8 к астральному транспорту - лишь бы с другой стороны был запущен git upload-pack linux.
Участники полностью равноправны - любой может запускать как fetch (pull), так и push.
Команды git search в системе, которая следует парадигме «выполняй одну задачу и делай это хорошо» быть не должно. Вместо неё стоит реализовать git clone $(distributed_search_client -format uri -tag kernel,linux,sources,src | head -n1).
git clone kernel.org:linux в текущей реализации - это краткая форма git clone ssh://kernel.org/linux, а git clone kernel.org/linux означает «сделай клон из локальной директории ./kernel.org/linux». В первом случае можно обеспечить себе желаемый уровень децентрализации с помощью ProxyCommand %h %p в ~/.ssh/config - можно вынести в отдельную программу любую, даже самую наркоманскую логику для установки связи через децентрализованный астрал с хостом %h.
Писать письма не обязательно через SMTP с резолвом доменов через MX-записи централизованной системы доменных имён с корнями *.root-servers.net - любой элемент этой цепочки можно заменить, если хочется избежать блокировки. Или сразу все, используя системы типа store-and-forward, например NNCP - тогда будет не важно, через какой канал пришёл пакет, главное, чтобы у него была правильная подпись, которой ты доверяешь. NNCP может работать даже поверх флоппинета или флешки, замурованной в общедоступной стене - наличие возможности для работы интерактивного протокола необязательно.
Если он децентрализован то он всё это должен уметь по дефолту без настроек, патчей и всяких костылей.
Если запихать все эти возможности в сам git, то это и будет огромным костылём. Такие задачи должны решаться на уровне дистрибутива, который соберёт вместе все компоненты, обеспечивающие согласованную работу децентрализованной системы.
Наиболее важные, на мой взгляд, свойства unix-подобных систем (из списка The Art of Unix Programming, Eric Steven Raymond):
Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Composition: Design programs to be connected to other programs.
Rule of Separation: Separate policy from mechanism; separate interfaces from engines.
Исправление kmeaw, :
git децентрализован в том смысле, что он может функционировать в сети равноправных участников. Ему всё равно, как работает DNS-резолвер и IP-маршрутизация в твоей системе. Можешь даже свой транспорт положить в /usr/libexec/git-core/git-remote-* или сделать git clone fd::7,8/astral:linux, предварительно подключив файловые дескрипторы 7 и 8 к астральному транспорту - лишь бы с другой стороны был запущен git upload-pack linux.
Участники полностью равноправны - любой может запускать как fetch (pull), так и push.
Команды git search в системе, которая следует парадигме «выполняй одну задачу и делай это хорошо» быть не должно. Вместо неё стоит реализовать git clone $(distributed_search_client -format uri -tag kernel,linux,sources,src | head -n1).
git clone kernel.org:linux в текущей реализации - это краткая форма git clone ssh://kernel.org/linux, а git clone kernel.org/linux означает «сделай клон из локальной директории ./kernel.org/linux». В первом случае можно обеспечить себе желаемый уровень децентрализации с помощью ProxyCommand %h %p в ~/.ssh/config - можно вынести в отдельную программу любую, даже самую наркоманскую логику для установки связи через децентрализованный астрал с хостом %h.
Писать письма не обязательно через SMTP с резолвом доменов через MX-записи централизованной системы доменных имён с корнями *.root-servers.net - любой элемент этой цепочки можно заменить, если хочется избежать блокировки. Или сразу все, используя системы типа store-and-forward, например NNCP - тогда будет не важно, через какой канал пришёл пакет, главное, чтобы у него была правильная подпись, которой ты доверяешь. NNCP может работать даже поверх флоппинета или флешки, замурованной в общедоступной стене - наличие возможности для работы интерактивного протокола необязательно.
Исходная версия kmeaw, :
git децентрализован в том смысле, что он может функционировать в сети равноправных участников. Ему всё равно, как работает DNS-резолвер и IP-маршрутизация в твоей системе. Можешь даже свой транспорт положить в /usr/libexec/git-core/git-remote-* или сделать git clone fd::7,8/astral:linux, предварительно подключив файловые дескрипторы 7 и 8 к астральному транспорту - лишь бы с другой стороны был запущен git upload-pack linux.
Участники полностью равноправны - любой может запускать как fetch (pull), так и push.
Команды git search в системе, которая следует парадигме «выполняй одну задачу и делай это хорошо» быть не должно. Вместо неё стоит реализовать git clone $(distributed_search_client -format uri -tag kernel,linux,sources,src | head -n1).
git clone kernel.org:linux в текущей реализации - это краткая форма git clone ssh://kernel.org/linux, git clone kernel.org/linux - сделай клон из локальной директории kernel.org/linux. В первом случае можно обеспечить себе желаемый уровень децентрализации с помощью ProxyCommand %h %p в ~/.ssh/config - можно вынести в отдельную программу любую, даже самую наркоманскую логику для установки связи через децентрализованный астрал с хостом %h.
Писать письма не обязательно через SMTP с резолвом доменов через MX-записи централизованной системы доменных имён с корнями *.root-servers.net - любой элемент этой цепочки можно заменить, если хочется избежать блокировки. Или сразу все, используя системы типа store-and-forward, например NNCP - тогда будет не важно, через какой канал пришёл пакет, главное, чтобы у него была правильная подпись, которой ты доверяешь. NNCP может работать даже поверх флоппинета или флешки, замурованной в общедоступной стене - наличие возможности для работы интерактивного протокола необязательно.