Несмотря на децентрализованный характер Git, для первичного получения исходных текстов требуется сервер, занимающийся отдачей кода. Например, блокирование доступа или сбой в работе GitHub перекроет возможность загрузить код и вынудит искать зеркала, несмотря на то, что данный код может присутствовать в локальных git-репозиториях сотен и тысяч разработчиков. Крис Болл (Chris Ball), долгое время занимавший пост главного инженера проекта One Laptop Per Child, предложил (http://blog.printf.net/articles/2015/05/29/announcing-gittor... использовать технологии BitTorrent для решения данной проблемы. Кроме общей концепции Крис подготовил и опубликовал (https://github.com/cjb/gittorrent) под лицензией MIT прототип дополнения для git с реализаций транспорта, загружающего данные через BitTorrent, а также специальный демон, отдающий содержимое локального git-репозитория через BitTorrent.Идея проекта достаточно проста - по аналогии, как BitTorrent позволяет сформировать распределённую сеть для хранения файлов, GitTorrent даёт возможность сформировать распределённую сеть для Git-репозиториев, отключение отдельных участников в которой не скажется на доступности данных, за счёт наличия в отдаче реплицированных копий. Для определения отдающих искомый репозиторий узлов и узла для отправки коммитов применяется DHT (https://ru.wikipedia.org/wiki/%D0%A0%D0%... (распределённая хеш-таблица). Организованное при помощи DHT хранилище в формате ключ/значение используется как система для определения профиля пользователя и информации о том, какие у него имеются репозитории и свежие git-хэши изменений.
Начальное согласование соединения производится при помощи специального расширения BitTorrent. При обращении узлу, на котором установлено данное расширение, создаётся специальный архив, включающие запрошенные git-объекты. На основании SHA1-хэша данного архива начинается его загрузка с использованием обычного BitTorrent и задействованием распараллеливания по сидам, которые имеют в раздаче аналогичный набор git-объектов. После загрузки и распаковки архива производится проверка подлинности git-объектов через верификацию цепочки коммитов в репозитории.
При необходимости загрузки репозитория, вместо прямого обращения к GitHub по SSH пользователь может выполнить "git clone gittorrent://github.com/someuser/somerepo" и загрузить репозиторий от участвующих в его раздаче узлов при помощи BitTorrent. В случае использования имени хоста вместо SHA1 хэша репозитория (github.com/someuser/somerepo) будет отправлен запрос к github.com и получен хэш последней коммит в репозитории. После этого через распределённую хэш-таблицу будут выявлены узлы, которые содержат данный коммит. Затем, соединившись с одним из таких узлов и запросив у него список необходимых файлов, будет сформирован архив с нужными коммитами и передан его хэш, на основании которого начнётся загрузка при помощи штатного BitTorrent.Стадию обращения к GitHub для получения данных о коммитах можно исключить, указав при обращении SHA1-хэш репозитория. Так как метод использования хэшей не слишком удобен, предусмотрена возможность регистрации читаемых имён, используя методы (http://en.wikipedia.org/wiki/Block_chain_(transaction_databa... применяемые для регистрации имён пользователей в Bitcoin. Для прямой отдачи своего репозитория через BitTorrent достаточно запустить gittorrentd. Возможно совершение не только операций fetch и clone, но и внесение изменений через операцию push. Синхронизиация полученных коммитов между участвующими в раздаче узлами производится через отправку архивов с необходимыми git-объектами при помощи специального расширения протокола BitTorrent.
URL: http://blog.printf.net/articles/2015/05/29/announcing-gittor.../
Новость: https://www.opennet.ru/opennews/art.shtml?num=42333
Какой-то геморой и костыль. Проще держать зеркало своего основного репозитория и не строить велосипеды из скотча.
> Какой-то геморой и костыль.+1
> +1На третий день Зоркий Глаз заметил что для установки этой штуки сватается какой-то npm и node.js, которые тоже надо где-то взять, и которые тоже можно заблокировать. Wait, oh shi-
А зеркало чужого тоже будете держать, даже не зная, что он вам понадобится? Тут, как я понимаю, идея в том, что те, кому не жалко - открывают доступ к своим клонам, при этом их имена/адреса клиенту знать не надо. В результате когда очередной идиот заблокирует гитхаб вы сможете получить доступ к тем проектам, которые склонировал кто-то, кто не поленился запустить этот сервис.
> когда очередной идиот заблокирует гитхабЗеркало (как и основной репозитарий) можно сделать доступным не только в инете, но и по другим протоколам.
> Зеркало (как и основной репозитарий) можно сделать доступным не только в инете, но и по другим протоколам.кто бы сомневался: RFC1149
> кто бы сомневался: RFC1149Слишком устарело -- хороший "карриер" не то что флешку, болванку со всем проектом утянет.
Можно. Осталось только понять, как те, кто хочет склонировать основной репозиторий, узнают о существовании зеркала. А здесь - вполне удобный механизм.
> Осталось только понять, как те, кто хочет склонировать
> основной репозиторий, узнают о существовании зеркала.Кому действительно нужно — узнают.
И тебя заблокируют лет на 20!
Без права переписки! xD
Я не имею дурной привычки жить в России
> А зеркало чужого тоже будете держать, даже не зная, что он вам понадобится?Вот в чем я совершенно точно уверен - так это в том что я не побегу ставить node.js и какие-то подвыперды скрипткидизов через их левый самопальный эрзац пакетного менеджера. Сделали бы это мелким и ненапряжным - им бы пользовались. А вкрячивать node.js и кучу требухи к оному в систему ради этой буиты будут только полные психи.
Да не бегите, кто ж заставляет. Другие найдутся. Кстати, интерпретатор перла или питона тоже ради скрипта не поставите? И ладно - они и так обычно в системе есть. И нода так же - часто появляется ради совсем других задач - либо по прямому назначению на машине разработчика, либо как хост для штук вроде Emscripten, либо именно как интерпретатор локального JS, на котором хотя бы быстрые скрипты получаются. Опять же, если V7 зачем-то стал, то нода поверх него - невелик оверкилл.
> Другие найдутся.Ога, будет как в i2p. Когда придется двое суток ффтыкатЪ пока единственный пир на тощем ADSL сможет вам таки налить что-то. При этом блокировать ничего не придется: при такой реализации оно просто не взлетит "само по себе".
> Кстати, интерпретатор перла или питона тоже ради скрипта не поставите?
Ну у меня есть какие-то максимально обкоцаные варианты, и не более того. И то - только потому что perl-ом немного пользуется пакетный манагер, а питоном - гимп. Они обрубленые до невозможности и я труба шатал чтобы какой-то скриптовый крап самовольничал у меня в системе что-то там вкрячивая мне в обход системного пакетного манагера через свои эрзацы. Да и не получится это - выход в сеть весьма фундаментально побустан и пакетному манагеру - дорожка прорублена. А эрзацы могут идти получать заслуженный "RST" от фаера, если хотят.
> получаются. Опять же, если V7 зачем-то стал, то нода поверх него - невелик оверкилл.
"А если вот так посмотреть, то вовсе даже и не кривой".
При том 95% которые с виндами - вообще на известно чем вертели и питона и перла и тем более ноду.
> Ну у меня есть какие-то максимально обкоцаные варианты, и не более того.Скорее, просто нормальные варианты, без дополнительных "прибамбасов" и библиотек.
> и я труба
> шатал чтобы какой-то скриптовый крап самовольничал у меня в системеНе запускать от рута -- не вариант, не?
Вообще-то, если "скриптовой крап" начинает что-то там пытаться установить без всяких " setup.py build install", то в 99% всех случаев -- это действительно крэп и его можно смело удалять.> там вкрячивая мне в обход системного пакетного манагера
Удобнейший, на самом деле, механизм.
Хотя бы "ман virtualenv" почитайте, прежде чем писать о абсолютной ненужности.> через свои эрзацы.
Это не эрзатцы, а отличная возможность (для разработчика, естественно) сделать полностью изолированною среду (и не одну), со своими, независимыми версиями либ.
При этом, авторам достаточно мелких либ не нужно заниматься опакечиванием под все дистрибутивы, вам (т.е. разработчику) не нужно ждать новой версии либы в репе (или пинать мейнтенеров или корячиться со сборкой и установкой), мейнтейнерам вашего дистрибутива -- поддерживать десяток разных версий и т.д. Да и "система не засирается"(с). Короче, одни плюсы.Но да, хороший инструмент можно использовать несколько изваратно -- т.е. запускать от рута и "какать" в систему.
Ну ведь и молотком можно шурупы забивать или соседу голову проломить.> При том 95% которые с виндами - вообще на известно чем вертели
> и питона и перла и тем более ноду.И гит в придачу )
> и питонаБез которого, скорее всего, вообще никаких торрентов бы не было.
Ибо в далеком 2000-мохнатом году протокол был одной из полусотни сферических п2п-придумок для "конеобразных сетей" (в смысле требований и допущений модели).
Т.е. то, что оно "взлетит" не знал никто и прототип ваялся как раз на "ужасном пистоне", на скорую руку. Тем поучительнее было, всего пару лет спустя, читать высказывания типа "Аффторы -- неосиляторы! Могли бы сразу на Си сделать!!!" =)
Учитывая, что 95% которые с виндами (из разработчиков) - веберы, то нода у них окажется с много большими шансами, чем что-либо другое.Но я самого стона не понимаю. Задача для интерпретатора в самый раз - ничего сверхсложного, никаких тяжелых вычислений, и вообще запросы приходят раз в год по обещанию. Зачем здесь что-то большее, чем скрипт?
Не мешайте чуваку демонстрировать свое ЧСВ.
> Зачем здесь что-то большее, чем скрипт?согласен, незачем. но оно тянет за собой идиотскую ноду.
Это недо допилить, добавить туда распределенную сборку проектов на разрешивших это узлах и будет то, что я пару лет назад на форуме описывал. Но он сделал, а я так, мечты мечтал :)
Какую сборку, куда, зачем? Это VCS, а не CI.
Э-э-э, а как пушить коммиты-то?Торрент протокол подразумевает, что качаемые порнофиль... то есть файлы не изменяются во времени. А в нормальном репозитории постоянно происходят изменения. Как по хэшу определять, чья версия репы самая свежая? Как сиды будут узнавать, что появился ещё один коммит? Как определять, куда пушить?
P.S.: Мама, это я дурак или идея битгита такая?
Пример из оригинала статьи:git clone gittorrent://81e24205d4bac8496d3e13282c90ead5045f09ea/recursers
Здесь 81e24205d4bac8496d3e13282c90ead5045f09ea - хеш публичного ключа владельца репозитория, а recursers - имя репозитория. Софтина ищет по этому ключу самого владельца, и спрашивает у него, что новенького в репозитории. Я, правда, не уверен, что представленная реализация умеет кешировать эту информацию на других узлах на случай отсутствия владельца в онлайне (не вникал в код, а в описании информация отсутствует), но технически и это реализуемо.
Даже если никак - это всё равно интересная возможость
Это ты дурак. Синкаются object-файлы. Они не меняются.
> Это ты дурак. Синкаются object-файлы. Они не меняются.Понятно. Спасибо.
Версионный срез не меняется
One Git Per Child
One GitHub Per Child
Бред какой-то, седня точно не первое апреля?
Интересная идея.
В любом случае хуже от этого не будет.
Единственный минус это актуализация содержимого репозитария.
Но он также существует на тех же фтп зеркалах.
Это лучше, чем отсутствие доступа к основному хранилищу репозитариев.
Слабость Git на базовом уровне в том, что он не только сложный в применении, но и не поддерживает докачку файлов с сервера при обрыве соединения. Далее идёт костылинг, чтобы хоть как-то обойти эти слабости и несовершенства.
> Слабость Git на базовом уровне в том, что он не только сложный
> в применении, но и не поддерживает докачку файлов с сервера при
> обрыве соединения. Далее идёт костылинг, чтобы хоть как-то обойти эти слабости
> и несовершенства.Тем не менее ртуть все сильнее разлагается и пахнет.
> Слабость Git на базовом уровне в том, что он не только сложный в примененииiZen ниасилил
И часто у тебя связь рвется?
Не, этот аргумент не катит. Неосиляторство — это, конечно, глупость, но считать само собой разумеющейся бесперебойную связь — глупость даже бо́льшая.
Ты понимаешь о каком объеме трафика идет речь, чтобы заморачиваться на докачку?
> Ты понимаешь о каком объеме трафика идет речь, чтобы заморачиваться на докачку?Примерно 5 ГБ занимает скачанный на ZFS с включенным сжатием LZ4 объём локального репозитория Netbeans в hg.
OpenJDK и Mozilla не тестировал. Есть ещё OpenOffice, но он по большому счёту не нужен.Что, разработчикам этих продуктов совсем-совсем неинтересно знать, что у них недокачалось или оборвалось, раз они не используют Git? Может у них каналы слабые и часто рвётся телефонная связь? Вряд ли. Так почему же они не используют везде распиаренный Git?! Это же модно, молодёжно, привлекательно! Молодняк ушёл Git осваивать, а старики на hg сидят, но почему?
> Примерно 5 ГБ занимает скачанный на ZFS с включенным сжатием LZ4 объём
> локального репозитория Netbeans в hg.
REPO SIZE REPO SIZE
613M .git 2,7G .hgЗря ты, зефирушка, взялся размерами меряться. https://xrunhprof.wordpress.com/2011/04/11/mercurial-vs-git-.../
Также ткнись носом -- там и по времени в 2.5-6 раз разница. И не в пользу ртути.
И таки да, там оно не на "zfs с lz4" (ты у нас один такой), иначе бы разница была в десятки раз.
>>чтобы заморачиваться на докачку?
> Примерно 5 ГБ занимает скачанныйИ кстати, Великий Космос внял твоим мольбам о докачке: теперь для тебя есть git поверх торрента же.
++А ртутные всё ещё тормозят без торрента?! В 2015-ом??? Ниаписуема.
> Не, этот аргумент не катит. Неосиляторство — это, конечно, глупость, но считать
> само собой разумеющейся бесперебойную связь — глупость даже бо́льшая.Скачать большой проект 1 раз в жизни можно и на нормальном канале. А докачивать дельту потом можно хоть на GPRS, дельта ж мелкая. Вот никто и не парится особо. Для разработчиковских юзкейсов все нормальненько. А если кто путает vcs и файлокачалку - при чем тут git?
И скачать может быть проблематично (вопрос - где именно вас застала нужда что-то сделать с кодом, или понадобилось именно тогда, когда есть проблемы с VPN к серверу с репой), и дельта бывает большая, если активно разрабатываемую репу обновляешь раз в три месяца, так как чаще не нужна... Если проект занимает мегабайт 300 то размеры репы в несколько гиг - ни разу не экзотика, особенно когда там есть хоть какие-то бинари, вроде графики. Другое дело, что есть какие-то практические проблемы с реализацией - я не смотрел, как именно pull сделан, но как минимум добавить при выставленном флажке в конфиге генерацию и сохранение бандла могли бы. То есть полный pull превратился бы в скачивание (возможно с докачкой) бандла + апдейт до текущего состояния.
Качать первый раз через rsync?
тарбол с добавленым .git
бинари. в гит. этот «проект» надо закопать вместе с разработчиками, неоперабельно.p.s. имел в виду «часто меняющиеся бинари», натюрлих.
Что-нибудь вроде специфических шкур под заказчика - ещё и как ложится в репу - куда ж ещё, если может оказаться нужной сборка версии полугодовой давности с багфиксом. А так - скормил системе сборки имя ветки - и готово. И шкурки, понятно, имеют свойство меняться вместе с веяниями моды, изменениями фирменного стиля и т.д. Да и вообще - через пару-тройку лет даже "редко меняющиеся" отрастают так, что весело становится.
> И скачать может быть проблематичноНу, понимаешь, качать какой-нить линуксный кернель целиком по GPRS - займет уйму времени, даже если там докачка будет. За это время можно будет сто раз доехать до места с приличным интернетом или попросить кого-нибудь прислать болванку с снапшотом, чем пытаться там что-то докачивать через такую пипетку. А вот потом - дельту на два мега можно уже и между делом докачать не особо напрягаясь.
> (вопрос - где именно вас застала нужда что-то сделать с кодом,
Внезапно, у гита очень мелкие дельты. Так что если ты проект не в первый раз видишь - никаких проблем. А выкачивать полинтернета на посмотреть на гпрс который еле ловит - по любому очень галимое начинанеи.
> с VPN к серверу с репой), и дельта бывает большая,
Ну не знаю, я Linux Kernel синкал несколько раз по GPRS ради лулзов - нормально было. Не, если у тебя бешеные дизайнеры льют гигазы файлов... то ты за ними по любому не успеешь :)
> хоть какие-то бинари, вроде графики. Другое дело, что есть какие-то практические
> проблемы с реализацией - я не смотрел, как именно pull сделан,Из очевидного: дельта считается под конкретного клиента и его текущее состояние дел, и серверу совсем не в кассу при отвале клиента помнить все состояние и эту дельту. Это наверное можно как-то заворкэраундить, но видимо не сильно злободневно для именно прогрмамистов, а не местных, которым извольте гиг отгрузить чтобы они могли посмотреть и в трэш отправить или там попользоваться серваком VCS как файлокачалкой. Это вообще не разработчики, отдачи с них буй, а ресурсы на их обслуживание транжирятся мама не горюй.
> сохранение бандла могли бы. То есть полный pull превратился бы в
> скачивание (возможно с докачкой) бандла + апдейт до текущего состояния.Технически это можно наверное как-то вкостылить даже. Если кому сильно надо. Ну там написать какой-то довесок генерящий бандл, а потом качать его. Но он будет трескать место на серваке. На каждого отвалившегося клиента. А учитывая что речь про проекты "300 мегабайтов и дельта в гигазы" - на серваке просто вскоре закончится место. По факту лишний головняк админам с простым и очевидным DoS: фигачим серверу пачку запросов и все время отваливаемся. Смотрим как сервер будет раскладывать гигазы по бандлам и насколько его хватит.
Да хрен с ней, с дельтой. Хотя бы для полного clone сделали костыль - решилось бы 99% проблем.А всё остальное - чаще не GPRS, а просто падает раз в N минут при не слишком высокой скорости (когда репа качается, скажем, минут 15). С VPN на хреноватых каналах такое - сплошь и рядом. Обычная корпоративная проектная репа и обычный же корпоративный VPN. И не с одним заказчиком я такое видел, тормозной отваливающийся VPN - скорее норма. Да, я понимаю, что каналы должны быть хорошими, VPN - правильно настроенным и т.д. Но вот реальность такая - попадал не раз.
А трескать место на сервере надо один раз. По принципу "раз в сутки генерим бандл и сутки его держим". Бандл - тупо архив репы, для всех клиентов одинаковый. Что даёт возможность забрать львиную долю объектов, остальное дотянется обычным образом. В сущности, проблема с этим ровно одна - хотелось бы, чтобы это было внутри гита, чтобы автоматом работало с дефолтным гитом на сервере и клиенте. накостылить-то - не проблема, cron + tar на сервере, wget + git clone --reference на клиенте - и всех делов. Только задолбаешься админов уговаривать этот кроновский таск добавлять да веб-доступ к файлику давать.
у iZen хобби позориться?
> у iZen хобби позориться?Ну да. Если не веришь - посмотри в его профайл и загугли. А что еще ожидать от "типа, фирбздшника" который на работе восьмерку использует? ;)
> Ну да. Если не веришь - посмотри в его профайл и загугли.
> А что еще ожидать от "типа, фирбздшника" который на работе восьмерку
> использует? ;)ИМХА, он уже много лет оччень неплохо так троллит и ловит лулзы с очередных д'Артаньянов ;)
Изя, залогинься)
> ИМХА, он уже много лет оччень неплохо так троллит и ловит лулзы
> с очередных д'Артаньянов ;)увы, нет, не тролль он. а просто дурак.
> троллитВы сделали несколько ошибок в слове "тормозит".
Очень круто!
Как уже достало неосиляторство. Всё уже давно есть: http://j16sdiz.github.io/egit-freenet/ При этом freenet приспособлен для гита замечательно, поскольку позволяет распространять связки ключ-блокданных, а приспосабливание торрента для этого - костыль, который обречён на провал, поскольку торрент нужен для выкачки целых архивов, а не одиночных файлов. Даже emule был бы лучше.
> Как уже достало неосиляторство. Всё уже давно есть: http://j16sdiz.github.io/egit-freenet/Ты бы сам осилил осведомиться как о freenet, так и о сабже как следует. Они вообще ничем не похожи. О каком "всё уже давно есть" может идти речь?
Давно есть безопасная распределённая сеть с key-value базой данных. Давно уже пытаются через неё наладить работу распределённых систем контроля версий.Но это же не популярно! Хоть технология старше некоторых посетителей этого сайта. Надо на модном и молодёжном битторенте запилить вообще всё, что требует p2p. Видимо потому что более стрёмного и небезопасного протокола найти не смогли. А так бы на нём делали.
Имела жаба гадюку^W пито^W... жабу-скрипта, во.В смысле, вы серьезно полагаете что этими выcepами на яве и node.js будет пользоваться толпа народа? Среди програмеров мало желающих вфигачить себе 100 мегов рантайма ради одной мелкой финтифлюшки.
А вы посмотрите сколько jvm проектов на том же github. Думается мне, кто сам пишет на яве, не будет столь лицемерным, чтобы не пользоваться ею для синхронизации гита.
> А вы посмотрите сколько jvm проектов на том же github. Думается мне,
> кто сам пишет на яве, не будет столь лицемерным, чтобы не
> пользоваться ею для синхронизации гита.отличный ответ! действительно, какая разница: javascript или java?
Он фринет имел в виду
> Он фринет имел в видуСостояние фринета как бы намекает, насколько оно всем надо. В результате все используют мелкий и ненапряжный tor, хоть у него и есть ряд бестолковостей в дизайне. Зато это мелкая программа не требующая для себя 100 мегов рантайма и не орудующая в системе через левые эрзацы пакетного менеджера.
Если вы разрабатываете не на ноутбуке то 100 метров рантайма для программера - вообще не объём. Вопрос только чтобы не мешало текущей деятельности - но нода, вроде, довольно умеренна в этом плане, в отличие от JVM.
> Если вы разрабатываете не на ноутбуке то 100 метров рантайма для программера
> - вообще не объём.Вот только если на каждое крапваре вгружать по 100 метров дребедени, которая еще к тому же в лучших виндовых традициях что-то побочно докачивает и гадит во все закоулки, система вскоре станет малоотличимой по свойствам от винды у завирусованых хомяков - все время будут отовсюду какие-то ошметки торчать, все будет тормозить и глючить, а расчистить это можно будет только полным "форматцэ", потому что гуано оптом впихнуто мимо пакетного манагера.
Я сам ни разу не фанат всего, что идёт мимо пакетного менеджера. Но вот самих рантаймов - число весьма ограниченное. Что там - перл, питон (2.7 по факту хватает), джава, нода. Ну руби ещё. не велика проблема хоть все поставить - по нынешним временам - в плане дискового пространства это абсолютные копейки.
> Давно есть безопасная распределённая сеть с key-value базой данных. Давно уже пытаются
> через неё наладить работу распределённых систем контроля версий.
> Но это же не популярно! Хоть технология старше некоторых посетителей этого сайта.
> Надо на модном и молодёжном битторенте запилить вообще всё, что требует
> p2p. Видимо потому что более стрёмного и небезопасного протокола найти не
> смогли. А так бы на нём делали.А подробности можно?
> А подробности можно?зачем тебе подробности от профана? по его тексту видно, что он вообще ничего не понимает в том, о чём пытается Вещать.
> А подробности можно?Зачем вам всякие невзлетевшие сферические кони, которые только "теоретически в 100500 раз лучше всяких поделок студентов!"?
Когда была мода на п2п, их там дюжинами "клепали" -- и большая часть этих придумок так и осталось на бумаге (т.к. только там и работало).А торренту уже более 10 лет. И назвать его "модно-молодежной недоподелкой" может разве что очередной диванный эксперт.
> Давно есть такой гордый птиц -- ежик. Давно уже пытаются
> его научить летать и заодно наладить доставку почты.
> Но это же не популярно! Хоть технология правильного пинка и старше некоторых посетителей этого сайта.
> Надо обязательно брать этих модных и молодёжных голубей, вообще для всего, что требует полета.fixed
Теперь патенты не страшны - даже если технология запатентована, опенсорсный проект можно развивать, никто не сможет закрыть
> Теперь патенты не страшны - даже если технология запатентована, опенсорсный проект можно
> развивать, никто не сможет закрытьТолько штатовские и еще некоторые разработчики для себя им пользоваться не смогут и поэтому разрабатвыать ты будешь "тихо, сам с собою, правою рукою" (с) Ларри Мак Лаффер.
Кроме пиндосов и так никто не боится, такой бред как патенты на ПО существует только в самой свободно1 стране