Кто-то на GitHub Actions сделал автоматизацию, которая собирает FFmpeg для сотни платформ: https://github.com/BtbN/FFmpeg-Builds
В процессе сборки она скачивает FFmpeg и все его зависимости, включая GNU gmp. Исходники берёт самые свежие, и у GNU gmp они лежат в Mercurial.
Сервера у GNU gmp не держат такую огромную нагрузку (отдать несколько гигабайт за несколько часов), и источник нагрузки начали банить: https://gmplib.org/list-archives/gmp-devel/2023-June/006164.html
Злого умысла у FFmpeg-Builds нет.
Предположим, что некто решает задачу автоматического анализа бинарников, например с целью выявления нарушений GPL. Он строит pipeline, на вход которому дают исполняемый файл, а на следующем этапе происходит поиск исходников, периодически приводящий к скачиванию их с серверов GNU. Будет ли подобный бан на стороне серверов GNU нарушением GPL (ведь лицензия требует предоставить исходники пользователю программы)?
Перемещено crypt из feedback
Возможность зеркалирования ничего не означает, это можно делать и с централизованными системами.
Децентрализованность это когда каждый клиент является одновременно и сервером.
Мне как-то тогда сложно представить как потом собирать изменения для релиза в случае, когда репозиторий клонировался древовидным образом
Но тем не менее гит по факту централизован.
В общем случае да, наверно все-таки соглашусь, потому что чаще всего есть один сервер, куда попадают изменения от всей команды разработчиков
Даже если серверов много то они всё равно не объединены в систему и не ищутся друг через друга стандартным для git способом(такого стандарта просто нет).
(нет аналога торрентовкского DHT)
Ну и опять таки, репозитарий в git адресуется не по ключу или названию и владельцу, а по доменному имени в интернете или ip адресу.
Я думаю что с этим можно что-то придумать, если интересно то можно обсудить.
Но ведь так и есть. “Отправить pull-request” в своём оригинальном значении означает “написать письмо с просьбой сделать pull со своего хоста”, а не “запросить в централизованной системе слияние двух веток”.
Для git сервер часто запускается по требованию клиента, используя sshd в качестве безопасного транспорта и механизма запуска.
Смотри, вот у тебя пустая домашняя папка и ты набираешь команду
git search tag=kernel,linux,sources,srcОн после её выполнения предложит сам по себе загрузится с kernel.org или github.com?
Будет ли в этом списке куча исходников с кастомными патчами?
Ничего такого он тебе не предложит, он напишет что такой команды нет и искать эти репозитарии ты будешь в браузере.
Теперь второй вопрос: положим мы живём в одном многоквартирном доме и находимся в подсетке одного провайдера и я набрал на своём компе команду
git clone kernel.org/linuxчем скачал к себе исходники ядра после чего разлогинился из компьютера.Потом ты выполнил уже на своём компьютере ту же команду
git clone kernel.org/linuxВопрос: откуда git будет качать исходники: с моего компа, неведомого Васи Пуркина или именно с kernel.org?
Подозреваю что именно с kernel.org, про частичные копии репозитария на моём компьютере или компьютере Васи Пупкина git на твоём компе ничего не знает и что важно даже не попытается узнать, у него просто нет для этого средств и механик.
То есть то что ты пишешь про написание письма может и создаёт ПРЕДПОСЫЛКИ для децентрализации, но по факту всё будет завязано на конкретный домен и если этот домен заблокируют спецслужбы то ты не получишь копии репозитария не смотря на то что она есть рядом с тобой на моём компьютере, у тебя просто не будет средств о этом узнать если только я не напишу о этом в интернете, например в виде поста в соцсети.
git сам мой репозитарий не найдёт и к тебе не скачает.
Пойдём дальше, kernel.org по прежнему заблокирован, а ты внёс в свои версии исходника правку и набрал условный git pull.
Вопрос: когда твои изменения попадут на сервер kernel.org?
При гормальной децентрализации они сначала попадут в копию репозитария у Джона Пупкина в США и уже оттуда через некоторое время фоновой синхронизации придут на kernel.org
И всё это без каких либо твоих тело движений как нормальная работа децентрализованного клиента.
Но что же будет по факту?
По факту ты будешь сидеть и ждать когда с kernel,org снимут блокировку, при том что компьютер Джона Пупкина заблокирован не будет.
И вот после всех этих "не" ты будешь говорит о том, что git хоть капельку децентрлизован?
Если он децентрализован то он всё это должен уметь по дефолту без настроек, патчей и всяких костылей.
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.
Стоп, не надо меня учить git, я им какое-то время пользовался и если надо то всё вспомню или прочитаю.
Мои примеры надо понимать схематически и давать на них такие же схематические ответы, избегая детализации чтобы концентрироватся на сути, а не на частностях.
И если kernel.org в этот транспорт не умеет то что будет?
Как бы они не были равноправны, всё равно все пулреквесты будут мержится не в распределённой сети, а на одном конкретном хосте с конкретным адресом и не важно, будет это реальный ip или будет адрес в одном из многочисленных анонимезаторов.
Как я понимаю git это мета-команда которая потом передаёт управление в какой либо специализированный блок как это сейчас делается в командах
ip,aptилиbtrfsи я не вижу ничего плохого в том если она подряд обратится к нескольким блокам, в конце концов в интеграции блоков и есть её назначение.То есть ты предлагаешь сделать отдельную команду
distributed_search_clientработу которой ты понял неправильно так как иначе вместо ошибочного| head -n1использовал бы конвеер из кучиgrep, в частности|grep kernel.orgи наверное gawk на случай если попадётся адрес видаdiadia_kiev.com/kernel.org/linuxкоторый вне сомненья будет удовлетворять твоему наивному запросу потому какkernel.orgто в нём есть…Это во первых, а во вторых как твоя утилита
distributed_search_clientобработает запрос видаgit search tag=kernel,linux,sources,src branch=brainfuck type=commit autor='Free Jone' include_txt='func brainfuck.extfs(devname) date_dia='2002.06.24.12:32-2016.12.xx.24:00'Теперь понимаешь всю нелепость твоего предложения делать отдельную утилиту
distributed_search_clientособенно если искомый коммит есть удалён из kernel.org и остался только в личном экземпляре исходников Free Jone?Ты не понял ход моей мысли, я смотрю на это не как на отдельный функционал, а как на одно из возможных применений единой очень гибкой системы.
То же самое, если попытаться связаться с тобой по телефону, если телефона у тебя никогда не было. Я про то, что git - это штука, которая синхронизирует объекты и ветки на двух машинах, если они уже смогли как-то связаться друг с другом, и git не очень интересно, как именно они это сделали.
Так же и ты можешь прочитать моё сообщение, даже если linuxtalks.co перестанет существовать. Возможно, я найду какой-то другой способ связаться с тобой, например напишу email или ещё как-то. От этого твоя способность понимать текст никак не поменяется.
Проблема не в том, из одного блока состоит программа или из разных. systemd ведь тоже не из одного бинаря состоит. Проблема начинается, когда авторы комплекта программ пытаются навязать одновременно и mechanism, и policy, лишая пользователя гибкости.
То есть если сделать git search, который делает всё, что ты предлагаешь, то придётся повторить всю эту работу для остальных задач, где полезен распределённый поиск - сделать ещё и youtube-dl search, wget --search, apt search и так далее.
Вместо этого лучше взять отдельно транспорт, отдельно систему разрешения имён, отдельно сервер метаданных, отдельно индексатор. Тогда можно будет простым скриптом в git hook вытащить информацию об объектах/ветках/коммитах и передать её в программу, накапливающую локальные метаданные. Другая программа сможет рассказать моим соседям (по DHT или ещё как-нибудь) про всё, чем я готов поделиться. И уже поверх этих компонентов можно делать глобальный поиск.
Если так происходит всегда то это опять таки свидетельствует о том что гит либо не децентрализован, либо это очень плохая децентрализация.
Не всё ли равно децтрализованной системе по какому транспорту общаются отдельные ноды, это влияет только на одно - по кому именно маршруту будет доставлено отправленное сообщение.
Вообще это твоё пояснение натолкнуло на мысль что гит децентрализован также как мессенжер у которого есть просмотрщик чатов, но нет сетевой части для обмена сообщениями, вместо этого создаётся текстовый файл, а пользователь уже сам как-нибудь разыщет адресата и доставит файл.
Это выглядит может и идейно правильно, но при отсутсвии прямой свзи с получателем сообщения выглядит довольно комично.
Может гит всёж научится в сортировку и автопересылку писем?
@kmeaw так что скажешь о двух предыдущих постах?
Увы, не знаю, что такое sendxml/sendjson.
Большая часть этих идей существует с времён FidoNet, когда мейлер, тоссер, редактор - отдельные программы. Сортировка и автопересылка писем там есть.
Если рассматривать классический email поверх SMTP, то есть git-send-email, а большинство MTA поддерживают .forward, откуда можно вызвать скрипт для разбора таких писем и применению патчей (git-am) из них в remote-ветки. Получателем таких писем может быть mailing list, рассылающий широковещательно письма, как это часто происходит в крупных opensource-проектах (например в ядре Linux).
Отсутствие прямой связи сейчас может и выглядит комично, но offline-протоколы всё ещё востребованы. До сих пор на Земле есть места, где связь очень так себе или появляется не всегда, а с расширением на космические масштабы проблема связи вообще становится неизбежной. Тот же TCP с дефолтными таймаутами и congestion control до Марса просто сломается.
Из интересных распределённых систем хранения (и поиска) стоит отметить IPFS, Tahoe-LAFS, YaCy. Я не знаю, как (и вообще ли) сделана в них защита от плохих участников - что случится, если кто-то будет отвечать медленно и/или неправильно.
Другая проблема в отсутствии общепринятого протокола для обмена статически типизированных данных между программами - большинство утилит командной строки в unix-пободных системах потребляют и порождают plain text, что не всегда удобно для сложных композиций. Некоторые умеют JSON, но нигде не описывают схему. Некоторые - XML. В корпорациях и модных cloud-native программах любят Protobuf (и gRPC). Для чтения людьми хороши recfiles - если бы мне нужно было выбрать формат описания артефактов для большой сети друзей, я бы начал именно с него.
Ещё интересный вопрос - что делать, если индексы очень большие, и вынуждают поисковую систему не скачивать сам индекс, а распределять пользовательские запросы на все системы, где потенциально могут быть искомые данные - насколько богатые запросы стоит разрешать? В мире веба похожую задачу решает GraphQL - он позволяет запрашивать, изменять или подписываться на изменения коллекций данных на удалённой машине и поддерживает фильтрацию и по вложенным полям, что обычно транслируется в запросы к локальной реляционной или объектной базе.
Ты довольно уникальный человек который начал просекать идею сервиса sendxml(ну или sendjson)