Какой UI сделать в linux liveced для гражданских? У нас сейчас GNOME3, мне хочется вырвать себе глаза, когда я его вижу. Не помню, как выглядит мак, но кажется не совсем так. Какие есть еще опции? Задачи - кликнуть на три иконки и поработать с парой приложений, после чего бросить флешку в шреддер

Работа над offgrid продолжается, отладка и всё очень wip. Главное, не сдуться, тем более, что CAS часть уже работает, т.е недостающий кусок - это eventually consistent синхронизация топиков. Всё получается сложнее, чем казалось сверху.
Оставлю тут только IT-шное, всякое прочее пойдёт в t.me/voidlizardonlineblog

А вы знаете, что если вы решите сделать свой, простите, токен, например, в сети эфира и, например, продавать его за другие строчки из какой-нибудь другой распределенной недо-бд - вас, в зависимости от юрисдикции, будут неистово штрафовать и может быть, даже посадят? а что бы иметь возможность писать определенные циферки в чью-то какую-то опенсорсную поделку - надо, значить, обложиться бумажками от государства какого-то, а не то плохо будет? Просто поразительно. Особенно то, что те, кто эти законы принимает - даже не вполне понимает, что это всё такое и как оно работает. Но одно он понимает точно: люди это планктон, а куда планктон - туда надо и им. И регулировать, регулировать.

могу гарантировать, что в бложике будет гораздо больше фана, чем в айтишном журнале. ойти наше изрядно закисло с одной стороны, с другой стороны не более, чем один из инструментов дискурс-монгеров.

Микро-отчёт по поездке за картой армянского банка на мотоцикле - в блоге про жизнь: https://t.me/voidlizardonlineblog

Проект offgrid жив, ноды стартуют, синхронизируют контент и топики. Первый шоукейс будет - обмен файлами, soon. Следующими, предполагается, будет простой распределенный чат и всё-таки обмен git bundle-ми, пока что число cli и в виде расширения git, которое, слава авторам гит, написать достаточно легко. Идёт тяжело, потому, что распределенщина это всегда тяжело

Кто-нибудь понимает, как в принципе можно сделать распределенные видеоконференции?

Что же, стало понятно, что p2p видеоконференция - крайне плохой шоукейс для offgrid, хоть и был бы эффектный, а так же выявлены основные проблемы видеоконференций вообще, понятно, что тема затратная, хоть и нужная.

Большое спасибо участникам и призываю обойтись без оскорблений, честное слово, ничего не было сказано такого ни одной стороной, что бы стоило к ним переходить.

Тем временем уже offgrid умеет в файлы и скоро можно будет переходить к плагину для git, концепцию попробую описать. Думаю, что ядро offgrid мы откроем, как только станет возможным хостить разработку его на нём же.

Что можно сказать про "распределённый git".
Основное, что про него говорят --- что "git и так
распределённый".

Но его врожденной распределенности хватает
примерно на команду из двух человек, если больше -
все ставят сервер или подписываются на гитхаб или
его жалкое подобие и очень быстро делают его
централизованным опять.

Что не так с гитхабом в сложившейся обстановке?
Тема отдельная, сейчас не хочется на этом
останавливаться.

В частности, берёт деньги условный гитхаб в том
числе за место на накопителях, а вот этого добра у
команды, которая совместно работает и так в
избытке. Всё есть у всех, данные хранятся с
избыточностью и никакие централизованные ресурсы
не нужны.

Что хочется (в распределённом сеттинге):

1. Все работы хранятся с избыточностью, можно не
переживать, что работа пропадёт из-за отказа
какого-то из узлов. Т.е что-то поделал,
закоммитил, правки уехали куда-то в "облако"
(двойные кавычки), и никуда оттуда не денутся.

2. PR, как на гитхабе. Ну, тут просто. PR это патч
+ описание + дискуссия + правила приёмки (не
так-то просто в распределённом сеттинге)

3. Поддержание неких одинаковых бранчей у всех
участников.

Тут поясню. Сделать распределенную систему, где
все изменения расходятся по всем узлам, но при
этом каждый бранч уникален, т.е сколько
участников, столько и бранчей (некоторые будут
идентичны) - не выглядит сложным, и годный подход
для старта, это уже что-то. Можно договориться,
кто будет майнтейнером и с кого будет браться
релиз.

Можно ли лучше? Да. Если мы примем предположение,
что "релизные" бранчи должны гарантированно
собираться автоматически при помощи merge и/или
rebase, принятые в них патчи одобряются неким
голосованием (approve) от остальных участников,
включая их порядок.

Сделать участником голосования можно и CI c
тестами, и какие-то голоса сделать обязательными.

То мы получим, с одной стороны, уже существующую
систему gerrit, которая примерно так и работает
(но централизованно). Gerrit не особо удобен по
сравнению с гитхабом, но внезапно, в
распределенном сеттинге его подход начинает иметь
большой смысл.

Суммарно: "распределенный git" можно собрать из
механизма распространения топиков + блобов (CAS)
(уже есть) + плагин к git, который будет уметь
ходить в ноду и забирать свои топики и
соответствующие блобы (надо писать).

В первом приближении --- хотя бы создавать
уникальные бранчи для всех участников, так, что бы
все изменения были у всех, ручная обработка
релизных бранчей.

Во втором приближении --- автоматически собираемые
бранчи, с приёмкой патчей с голосованием (как в
gerrit).

Уже видно, что если голосование не будет делаться
консенсусом, а будет требовать всего-лишь
несколько голосов --- то могут возникать ситуации
split brain. Но мы исходим из того, что каждый
узел/разработчик заинтересован в том, что бы его
топики были синхронизированы с мейнстримом,
соответственно, просто надо дать ему механизмы для
того, что бы узнать, какое состояние топиков
является мейнстримом, залить эти топики себе и
сделать их "мейнстримом" у себя, а потом свои
изменения накатить поверх этих топиков. Как и
везде, надо не только придерживаться линии партии,
но и активно выяснять, что же является сейчас этой
самой линией партии, что бы не попасть в неловкую
ситуацию. В данном случае, это приемлемо,
особенно, если автоматизируемо.


Решается это примерно топиком анонсов, в который
каждый узел пишет "я такой-то, бранчи у меня
такие-то, история бранча такая-то, хэш такой-то".

Пока так.

А, ну да. Что бы всё это вообще работало с нулевой
настройкой, придётся сделать уже механизмы peer
exchange и бутстрапа, а так же криптографическая
подписка/отписка. Так, что бы peer exchange
работал для всех, а вот топики были изолированы
между группами, которые с ними работают.

Вероятно, эта самая подписка будет сделана
попозже, первое время подойдет только для хостинга
опенсорса.

#offgrid В процессе: автоматическая синхронизация топиков, acl что бы хоть как-то ограничить распространение топиков —- понятно, что это не криптография, но по крайней мере нода не будет раздавать всё, что имеет всем подряд, и зачатки peer exchange. последний делается через те же самые "топики", просто топик определенного формата + есть идеи, как его формировать автоматически. Это делается сейчас для того, что бы можно было где-то размещать релейные ноды, что бы запущенные в рандомных местах ноды могли найти друг друга и синхронизироваться. Ну то есть ты поднял ноду, твой знакомый поднял ноду, хоба, друг друга нашли через релей и можете файлы синхронизировать.

В своё время наблюдал за реакцией на научную публикацию, в которой было моё имя. Цитирования и т.д. Тогда в первый раз возникла мысль о распространении идей - от первого мира ко второму, далее к третьему. Т.е одно и тоже можно продать сначала в первом мире, потом во втором, потом в третьем. Наверное, и капитализация на каждом переходе падает на порядок, но всё равно неплохо получается. Ну и истории есть - сначала в США, потом через пару-тройку лет в РФ, потом лет через десять — во Вьетнаме. Ну и в Африке в целом движуха началась сравнительно недавно. Интереснее, что же из себя представляют на самом деле эти миры (коммуникационные кластеры?), казалось бы, идеи должны распространяться не обращая внимания на границы, а вот нет.

Ну и еще интересно, что то, что не полетело в одном месте, вполне может полететь в другом в силу другого бэкграунда. Т.е. в более диком месте могут выжить более прогрессивные технологии, а на старых местах не очень, там и без них всё нормально

При отладке многопоточных серверов логи становятся малополезны. Надо заводить метрики/счётчики и выводить снапшоты состояния системы. По метрикам можно и графики строить, бывает. Полезнее бывает пялиться в график, чем в бесконечную портянку лога. Отладка же распределенных систем это вообще дичь. Хотя сейчас переполнение нашли методом пристального вглядывания в логи и хаскельный код. В течение часов в трёх в сумме. Могло быть и хуже #offgrid

#offgrid ну что же, чихает, пердит, но едет. приступаю к прикручиванию git, что бы хоть как-то можно было уже совместно разрабатывать offgrid на нём самом

И никсовые артефакты в него же запихать для сборки

#offgrid #offgrid-git предварительный дизайн:

один git remote соответствует одному топику offgrid. поддержка acl в offgrid достаточная для того, что бы можно было создать топик, куда постить сможет только owner, остальные посты будут отбрасываться нодой.

пишется git protocol helper, который умеет работать с нодой оффгрид.

поработал-поработал, закоммитил, сказал git push. твои изменения уехали всем, кто слушает этот топик. писать в него можешь (пока) ты один.

есть топик-upstream - сейчас его будет руками собирать майнтенер и постить. откуда он узнает. ну пока что у него будет костыль, который по всем топикам покажет новые бранчи/коммиты, потом будет сделан топик, в который будут подъезжать аналоги github pr. они и мержиться смогут автоматом или там голосованием. но для начала просто ручками поребейзит, в первом приближении хватит

сегодня отбываю на рекорд россии, но как только с него вернусь, буду с головой погружаться в гит, а пока просто почитаю и подумаю, что тоже полезно.

как делать более-менее понятно, вот этот проект git@github.com:vlastavesely/git-remote-example.git более-менее внёс ясность. но еще много белых пятен, конечно. порядок действий такой:

1) сначала простой протокол без upload-pack 2) сначала команда list 3) потом команда push 4) потом команда fetch.

Работает это всё примерно так: гит это CAS, где каждому объекту соответствует хэш. но поскольку некоторые объекты должны быть изменяемые, есть ссылки. ссылка эт просто текстовый файл в каталоге .git/refs, в каждом таком файле записан хэш объекта, который ему соответствует. т.е изменение объекта - это изменение ссылки на объект, т.е изменение контента этого файла. git-remote-protocol это бинарник из путей, который гит зовёт, когда хочет поговорить по какому-то протоколу. работает через пайпы, там текстовый протокол согласования фич. дальше работа ведётся либо по текстовому протоколу, либо через более умный бинарный протокол (пока неважно).

По текстовому протоколу:

При push сначала делается list, который должен "пушеру" отдать список объектов, которые есть на той стороне. Потом пушащий решает, что на самом деле надо запушить и отдаёт список того, что он хочет запушить той стороне, в виде

(HASH REF-NAME \n)+ \n

, и как-то, в зависимости от протокола, пропихивает сами объекты с данными кодами в тот репозиторий из этого.


При fetch - получаем список объектов на той стороне и решаем, какие нам нужны.

NB: так как мы получаем список пар (хэш, символ) мы знаем, какие ссылки изменились (куда теперь указывают бранчи и теги).

Как это всё ложится на offgrid.

Есть топики. Каждый топик отражает стейт репозитория (remote). Каждый пост в топик может или отражать стейт целиком (список пар хэш/имя), или же его инкрементально обновлять. Видимо, надо поддержать и то, и то.

Пуш делается так: 1) кладём в offgrid сами объекты 2) обновляем стейт. В стейте так же храним соответствие хэшей sha1 нашим хэшам (offgrid-hash).

Фетч делается так: 1) обходим топик, собираем стейт (либо же делаем это в фоне и сохраняем последний стейт в кэше и получаем за O(1) ) 2) сообщаем список объектов 3) отдаём этой стороне объекты, которые она попросит, используя таблицу соответствия sha1 <-> offgrid-hash

Вроде бы и всё, после этого минимума offgrid-git должен завестись и позволить его разрабатывать на нём самом.

Как гит мог бы быть лучше. Могло бы быть понятие стейта и каждый push его бы модифицировал, и каждый стейт сам бы имел свой хэш. Тогда можно было бы легко делать diff между тем состоянием и этим и получать список изменившихся объектов, например. Сейчас приходится туда-сюда гонять списки ссылок, а список ссылок это и есть стейт, но в явном виде его нет. Но вот это понятие вошло в обиход после распространения блокчейнов. С другой стороны, в гите есть "локальное" и "удалённое", причем индивидуальное для каждого репозитория. В целом это вносит много мороки, но мало что даёт. Гит мог бы быть сразу таким, как мы делаем offgrid, но тогда бы он не был бы self-hosted через пару дней (как гласит легенда). А в лучшем случае, месяца через четыре. Или же offgrid мог бы быть новым dvcs, т.к. в нём всё для этого есть, но тогда его будет ждать судьба fossil, т.е быть не нужным никому, кроме авторов. Но спасибо авторам git за его модульность и адаптируемость.

Просто еще раз: репозиторий в гите является составным мутабельным объектом, который можно менять неатомарно и которому нельзя сделать rollback

История с торнадо кэш еще раз подтверждает, что власти охренели решительно везде, централизованные сервисы - говно по определению, это помимо того, что не нужны. Прямо доза рвать и метать с утра. Надо опять навалиться на оффгрид-гит, а то я что-то приуныл. Там какие-то мистические ошибки выдаёт гит при работе с ним по протоколу, надо видимо будет сначала побороть брезгливость и поотлаживать имеющиеся питоновые прототипы. Ну или на расте помакетировать. Потому, что ошибки крайне подозрительные и наводят на мысль о хаскельном IO.

Hate driven development

#offgrid ну что, в шаге от того, что бы offgrid-git стал self-hosted. push делается, объекты (сами) расползаются по нодам, и структура данных позволяет восстановить репо. остаётся сделать fetch и можно пушить/фетчить объекты из "p2p облака" оно же личинка "гипертекстового векторого фидонета на блокчейне" (бинго!)

#offgrid ссылка на репо offgrid-git (идут тяжелые работы!) 3CAaSFxhHVQZjeM2wEq1NXRQkZgK9Mccust8qzv6X1pC