Кто-то на 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 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)