Тем временем на гитхабе шлют спасибы за патч в USB стек STM32, который я пытался донести до производителя и через их форум, и через поддержку. 11 лет прошло, видимо, так и не починили.

#hbs2 #status Заминка в разработке и отсутствие новостей объясняется ангиной. Ехать пять часов по холоду после дайвинга видимо так себе была идея, странно, раньше прокатывало, но без дайвинга. В любом случае, сейчас пилится TCP PEX. Коротко говоря - TCP себя оправдал, но гемор с ним велик, как и предполагалось. Сейчас протоколы ходят по TCP те же самые, что и по UDP, что субэффективно. И тут непонятно, пока, как поступить лучше. Текущая структура данных для hbs2-git начинает всё тормозить на большом количестве объектов, а структура была такая выбрана, что бы бы каждый гитовый объект в мире соответствовал одному единственному меркл-дереву в системе и кроме того, все зависимости скачивались бы рекурсивно бесплатно (без дополнительных усилий, чисто за счёт самой структуры данных). Не проканало, а было довольно круто - на любую версию любого гитового объекта в мире можно было сослаться по blake256-хэшу. В принципе, на этом еще полностью крест не поставлен. Теперь пытаюсь придумать другой подход, но который бы не приводил к дублированию данных. В принципе-то придумал - append-only-log без повторений. Что бы он был без повторений, он должен быть индексирован. Отсюда возникает вопрос, где держать индекс, или не держать, а строить его каждый раз. Другой вопрос - сейчас сделано так, что любая транза полностью самодостаточна и строит репозиторий, можно пропустить любое количество транз до и после, неважно - мы всегда имеем весь полностью репо, но это, конечно же, приводит к оверхеду в виде кучи мелких зловредных кусков данных, которые всё и портят. Еще минус append-only-лога в том, что для своей передачи он будет требовать отдельного merkle-разбиения и вот эта вся надструктура - нужна только для передачи, а потом она сохранится в хранилище, хотя особо уже не нужна, т.е лишний оверхед по данным опять. И еще его минус - сейчас объекты дублируются 1) в сторейдже hbs2 и 2) репозитории гита, а будут еще и в append-only-логе, т.е аж в трёх местах. Неизящно. Можно лог каждый раз грохать и пересоздавать - до сотен мегабайт/гигабайта это будет работать сравнительно быстро. С другой стороны что я парюсь - кого вообще волнует лишний гиг на диске. С третьей стороны, еще не исследовал, как ведёт себя git если ему доступен только fast-import/fast-export, возможно, ответ в этом - надо не какой-то свой append-only-log делать, а тупо дампить репо каждый раз в fast-import/fast-export формате. TL;DR — проблема ясна, а решений может быть примерно пять-шесть и неизвестно, какое лучше. TL;DR (2) - залип на придумывании нового формата hbs2-git.

Итоги предварительных изысканий: если писать все гитовые объекты в лог, одна секция = один объект с гитовым хэшем и размером, то: 1) лог пишется быстро 2) индексируется на проекте размером (упакованного) репо 12M быстро (= мгновенно, но это линейный проход файла - O(n) от числа объектов и ~ n * log n на индексацию), если вести один и тот же лог с момента начала репо - то у файла есть устойчивая стабильная часть, которая никогда не будет передаваться повторно. Однако, если в какой-то момент этот файл дропнуть и пересоздать из гита, и порядок объектов изменится - то в разбиении этого файла не будет вообще ничего общего с предыдущими файлами. Что наводит нас на следующую мысль: Алиса пилила пилила проект, инкрементально добавляя в лог. Потом Боб форкнул проект и накатил сверху патч, и отправил Алисе = опубликовал merkle tree своего лога. Получилось следующее:

AAAAAAAAAA|BBBBB

Где BBBBB - разбиение объектов из гита Боба. Алиса приняла патч Боба, и получилось у неё следующее:

AAAAAAAAAA|YYYYYYYY|

и Боб, несмотря на то, что у него все эти патчи есть, выкачивает upstream Алисы, т.к. из-за другого порядка, других смещений и т.п - разбиение upstream уже не

AAAAAAAAAA|BBBBB

, а

AAAAAAAAAA|YYYYYYYY|

- кусок же BBBBB - живет в форке Боба и никому, кроме него, не нужен. Т.е YYYYYYYY и BBBBB - это в принципе одни и те же объекты, но по-разному разбитые и это дублирование информации как раз.

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

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

Кажется, что если всё-таки разбивать изменения на 256K куски и писать в лог (т.е сейчас лог произвольный, в его просто пишутся объекты гита с префиксами - а надо будет сначала объекты представить merkle-деревьями [или одним деревом], а затем записать в лог, используя стандартный размер блока — то эти самые блоки будут одни и те же, даже если и порядок их будет разный — что сводит ненужные хвосты "BBBBB" к почти нулю).

Из хороших новостей, если мы приняли, что стейт гита — это один растущий лог, можно его версионировать и в будущем менять формат, мало на что повлияет, меньше допущений делается. Жалко сразу такая мысль в голову не пришла — текущий формат репозиториев привёл к размножению мелких объектов и так оставлять нельзя, т.е будет хардфорк с изменением ссылок на репозитории, т.к hbs2 будет рекурсивно качать все содержимое лога ссылок (reflog) и будет засорять пользователю эфир, пока все не скачает. Сейчас эта канитель на десятки минут при выкачивании нового репо.

UPD. Всё еще хуже, кажется, если Боб форкнул репо Алисы в момент

AAAAAA|

, то хвост этого файла не сойдется с Алисой уже никогда => у всех форков хвосты будут разные => огромное дублирование информации, если только не выкидывать форки и не начинать новые после того, как их изменения приняты. Но повлиять на это никак нельзя - пользователи ж могут творить, что хотят. Короче, явно нужно что-то разбивать на merkle деревья и уже эти меркл деревья писать в лог, либо же придумать стабильный формат, который будет одинаковый у всех для одинакового набора объектов. Собственно, кажется, что merkle-разбиение это и есть этот стабильный формат. Другое, что в голову приходит —- это сортировка секций файла каждый раз при push. Тогда идентичные объекты будут идти в логе одинаково, и в случае одинакового набора объектов файл сойдется рано или поздно. Но кажется, что гигабайтные репозитории сортировать каждый раз будет накладно. Можно писать в базу, базу дампить и разбивать, но это довольно всё медленно выходит даже на текущий момент

UPD2. С другой стороны, если писать объекты выровненными на границу 256K блока, то опять появляются стабильные куски, отличающиеся только порядком следования блоков. Как проверить: пишем лог гита, выравнивая каждый объект на границу 256K (плохо для мелких объектов, которых в гите много!). Инкрементально добавляем новые объекты, каждый выравниваем на границу 256K. Дампим merkle разбиение. Грохаем лог. Пересоздаём лог. Ожидание: значительное пересечение по хэшам merkle-разбиения (без выравнивания: вообще ничего общего).

UPD3. Поскольку merkle-разбиение мы можем делать на блоки любых размеров, можно, например, выравнивать на границу 4K. Это даст какие-то смутные бенефиты при чтении-записи на диск возможно. Но станет больше блоков/больше хэшей, возрастёт нагрузка на CPU и возможно всё на сколько-то замедлится

UPD4. Если для текущего репозитория писать объекты, выравнивая по границе 256K, то оверхед будет 2G. Если выравнивать по 4K - то оверхед будет 13M, при том, что весь упакованный репозиторий 13M и есть. Если выравнивать на 1K, то особо оверхеда нет. Но теперь хэшей/секций становится в 256 раз больше, не придём ли мы к той же проблеме кучи мелких объектов

Короче, ноука это когда у тебя не 2 стула. А 256K стульев и надо найти наиболее оптимальный стул по N параметрам. В итоге всё равно редуцируется до двух стульев - объем vs cpu time

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

Алиса оказалась той еще сучкой, прошлое решение - не решение. Походу, хорошего решения здесь вообще нет. Предосылка 1. "лог" объектов гита должен генерироваться только из репо, и репо + голова (push-объекты) и должно быть стейтом. 2. Лог стейта должен формироваться у всех участников одинаково, независимо от того, каким путём они эти объекты получили, хоть rsync-ом. 3. Лог должен писаться инкрементально. Решение: берём все коммиты, сортируем в топологическом порядке, одинаковые топологически сортируем по хэшам. Для каждого коммита берём его объекты, сортируем по хэшам. Для каждого коммита пишем объекты, пишем коммит. "Старые" объекты будут ближе к началу, новые - в конце лога. В этом случае, для одинаковых репозиториев лог будет одинаковый. Если Боб имеет привычку грохать временные бранчи, а мастеру делать git reset —hard на апстрим, как я, то его репо будет приходить в соответствие репо Алисы, и при последующих FETCH он будет выкачивать только новую часть. Мусор будет образовываться, тем не менее. Но кажется, ничего лучше тут не придумать, если не понижать гранулярность. Сейчас гранулярность = весь репо. Пишем объекты упорядоченно по сути по времени создания, и надеемся на лучшее. Можно еще попытаться вести логи для бранчей по отдельности, тогда при прибивании временного бранча возможно, мусор будет зачищен, надо подумать

Теперь самое гнусное решение: 1) выравниваем все объекты до некоей границы (64K / 256K ) . 2) считаем хэши от дополненных объектов 3) в сторейдж пишем в сжатом виде (оверхед по данным около нуля) 4) передаём блоки в сжатом виде, в BlockInfo говорим, что блок сжат - при пересчёте хэша распаковываем. Оверхед по данным при хранении устраняется, при пересылке - устраняется, ну и вообще принуждает сжимать данные, что невредно. Возникает оверхед при пересчёте хэшей, но насколько но значителен? А мерзкое решение потому, что это куча мелких изменений в разных местах протокола.

Задача в принципе решена, но уже понятно, что хорошего решения тут нет. Штош, остаётся сделать приемлемое. Будет хотя бы быстро работать. Написать PDF проще, чем написать код, вернее, не так жалко его выкинуть или переписать потом. А глупость, изложенная на бумаге почти сразу же видна, в отличие глупости в голове, которую бросаешься реализовывать. Прямо понравилось мне сначала написать документ. Буду практиковать.

Бесплатная раздача идей: нейросеть/нейросети, которые будут вместо тебя участвовать в совещаниях по зуму. Потом еще устраиваешься с этими нейросетями сразу в несколько мест менеджером и профит. Задавать вопросы "какой статус? за сколько сделаете? почему так долго?" чат гпт может уже сегодня, осталось анимировать картинку и голос синтезировать. Вроде бы всё по отдельности уже есть. Еще приделать ручки, что бы тикетами манипулировать, причем там можно даже без особого интеллекта, чисто рандомно. Ну хорошо, с интеллектом будет менее палевно. Не шучу, кстати. Всегда говорил, что значительня часть менеджмента может быть заменена скриптами, но никогда не думал, что нейросети и скрипты сделают ненужными.
Продукт практически идеальный: за то, что будет приносить деньги, люди будут платить. Конечно, кончится всё тем, что это сделают B2B сервисом и всех менеджеров нахрен поувольняют. Аналогичный продукт, который будет лепить отмазки тоже будет востребован. Chat GPT — король отмазок

#offgrid #hbs2 работы ведутся, просто очередное выгорание. обычный режим - полгода работы овертайм, полгода в режиме овоща. удачно, когда овощной режим совпадает с летом. тестим tcp pex тем временем, вроде бы работает. надо бы сделать усилие и побороть эту циклотомию, конечно. с другой стороны, очень полезно выгрузить код из кэша в мозгу, потом когда заходишь —- видишь код совсем другими глазами, можно найти и убрать косяки. пока что думаю над вопросом, нельзя ли сделать обратную совместимость с текущим устройством репозитория, что бы не ломать ссылки. и кажется, что можно, но ценой дублирования данных. вечный трейдоф скорость/память

#hbs2 #offgrid

 ... -> Protocol Encryption -> Fast Large Git Repos -> Git Repo Encryption -> MVP

(1) в работе, (2) в работе

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

git rev-list --objects --no-object-names <rev>

Радует, что несмотря на нанесение сокрушительного удара по оптимизму стартаперов и инвесторов, этот самый оптимизм выжил. Просто к пачке прочих допущений добавились новые — война когда-нибудь закончится, и можно будет выходить на рынки САСШ и Канады, и Европы, лол. Или что к моменту, когда война закончится, будет само понятие рынков САСШ будет существовать. Учитывая матожидание успеха всей этой движухи, эти все риски добавляют... Ну, пару процентов вероятности провала. Так что всё ок, улыбаемся и машем! Рулетка крутится. Кто-то неизбежно выиграет.

Когда началось, я написал последний твит, типа, доброе утро Иран. ХЗ кто что понял, мне всё время кажется, что все разделяют мой контекст, что очевидно не так. Занятно, что сейчас Иран как пример изолированной страны, где, тем не менее, чот даже осталась какая-то биржа, и там, на удивление, не всё так однозначно — скорее, положительный пример. Отрицательный это скорее... Сомали?

В своё время язык SQL делался, что бы простые люди могли общаться напрямую с машиной, в обход программистов. Простым людям не зашло. А вот чату гпт заходит отлично.

#hbs2 работа ведётся. новый подход к формату репозитория точно всё ускорил. статус нового репо: в принципе работает, но отладка. темп медленный из-за внезапного наступления лета, слишком много соблазнов + настал момент, когда за моё хобби мне теперь еще и платить готовы, очень необычные ощущения, к тому же там нет ощущения задолбанности. но неважно, всё равно доделаю. пока что статус такой же, какой и был
#hbs2 #offgrid

 ... -> Protocol Encryption -> Fast Large Git Repos -> Git Repo Encryption -> MVP

(1) в работе, (2) в работе

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

Хочу предложить новую дисциплину для специальных олимпиад: кто сделал самую большую задачу при помощи чат гпт. В ней подразделы: самая большая задача с одной формулировки. самая большая задача с ограниченным количеством понуканий (уточнений, включая указания на ошибки). Для меня это пока что: скрипт конверсии дампа БД из pg в sqlite.

Несмотря на то, что основной проект несколько потерял темп по разным обстоятельствам, промежуточные результаты таки есть. Во первых, это всё таки юзабельный работающий прототип распределенного git, который используется внутри команды и действительно работает. Во вторых, это, наконец, распределенный трекер fixme, который живёт внутри репозитория и использует здравые предположения — т.е использует git правильным образом, не абьюзя его. Так же исследованы свойства CAS и более менее понятно, как строить приложения на основе иммутабельных массивов данных. Не в последнюю очередь это и suckless-conf, который, наконец-то, является sexp-ами при этом может имитировать простой плоский конфиг, когда не нужна сильная вложенность. Параллельно он может парсить тексты/протоколы/данные, похожие на секспы. Ну и сам hbs2 является неким фреймворком для построения распределенных приложений, который требует, на мой взгляд, минимум от пользователей и содержит минимум инфраструктуры. В нём есть средства для построения FSM протоколов и описания их свойств, есть PEX (пока не стопроцентно проработанный), есть автоматический поиск пиров в L2 сегментах, есть dns бутстрап, есть ручки для криптографии. Есть куки, сессионные данные с автоматической подчисткой, есть pub/sub для коммуникации разных частей приложения на основе эвентов. Есть заделы для протыкания NAT, т.е оно их в целом протыкает кроме тяжелых случаев (когда нужен релей), при этом даже без использования STUN. Мессаджинг обёрнут в тайпклассы, т.е можно хоть UDP в TCP заворачивать, хоть всё гнать через HTTPS / вебсокеты или вообще любую проксю, типа shadowsocks. TCP есть, значит, через SOCKS работать будет, хоть через tor proxy гоняйте. Мессаджинги могут вкладываться, т.е можно сделать мультиплексирование/демультиплексирование и разные надстройки, например прозрачное шифрование.

Т.е на этом всём можно брать и запиливать, при этом фокусируясь на логике, и всё это без адового когнитивного оверхеда - посмотрите на cloud haskell / дистрибьютед всякое там. Сериализация настраивается через тайпклассы - хотите, текстовые протоколы пилите, хотите CBOR (надо хотеть CBOR). Да, много есть сырого, но постепенно всё лишнее отсечём. Гонять сериализованный код по сети и исполнять, ловя адовые проблемы — очень хрупко и нафиг не надо. EDSL вокруг FSM для протоколов - норм тема. PEX, SOCKS и нат и правильное построение каналов для работы дают возможность в серверлесс / распределенном окружении. Да, пока непонятно, как вообще снюхивать пиры без точек рандеву, но я не уверен, что это в принципе-то возможно. Всё вместе это ложится на некое глобальное вИдение распределенных приложений, в т.ч. нагруженность: асинхронность, fsm, pull/poll, транзакционность, отсутствие сессий с токенами, вместо этого криптографическая авторизация каждой операции + представление любых данных merkle деревьями и p2p их распространение. Короче, пока что есть много кубиков, следующий этап - брать кубики и рисовать между ними стрелочки. Так победим. Пример распределенного приложения, через реальный TCP (но без пекса) https://gist.github.com/voidlizard/2deb91c346ce69b74818a42f58ced593

Зачем это всё вообще. Ну потому, что традиционные протоколы слабоваты в ситуации, когда с одной стороны чебурнет, с другой стороны меты и алфабеты. С одной стороны недостаточны, с другой стороны избыточны. Зачем миллион протоколов для обмена сообщениями? Чем сообщение в телеге отличается от имейла? Чем короткое сообщение отличается от длинного? Ну и прочие вопросы. А ведь нам просто надо обменяться данными no matter what, и узнать, что эти данные есть no matter what, узнать у кого забрать, ну и узнать, что это действительно его данные, и всё так, что бы товарищ майор, чебурашка, корпорации зла и бандиты максимально не знали, что внутри. Ну то есть набор кейсов он ограничен, понятен, и понятно, что можно проще, чем есть сейчас. Зачем нам платить за чужие мощности, когда у нас полно своих? Зачем нам, как команде, платить за чужой сторейдж, когда у нас своего минимум столько, сколько в команде участников? Зачем нам DNS, когда есть криптографические идентификаторы?

UPD. "Protocol Encryption" подъехало. Ну вот, а вы говорите, что ничего не делается. Делается всё, прост не так быстро, как хотелось бы.