Псто про ментальную модель гита собрал, конечно, лулзовых коментов, но если у человека нет "ментальной модели" то откуда он тогда вообще знает, как работать с системой контроля версий? Конечно же, она есть. Вопрос, какая.

Учитывая, что некоторые вещи в git и придумали, во всяком случае, до него они не были широко известны, т.е понятия такого до git не было.

Конечно же, модель есть. Просто у одних это интуиция, выработанная пробами и ошибками, после обрывочных рассказов тех, кто читал про git flow, а у других это статья (вроде Торвальдса, но не уверен) + выступление Торвальдса, где он разносит svn и рассказывает про git. В принципе этого достаточно, что бы понимать, что ты делаешь, когда что-то делаешь в гите. В первом случае же просто зажмуриваешься и давишь на кнопки.

Но git это прост пачка утилит для работы с базой в специфическом формате, например, можно работать, как описано в git flow, а можно, как в gerrit, и кстати, в gerrit есть резонные причины делать именно так ( repeat (commit —amend) && push) , но можно и сяк ( merge —squash —no-commit && push ) и у того или иного способа есть свои последствия. Не говоря о же о том, что там есть еще и что до git не было известно (cherry-pick, read-tree и еще миллион всего). А можно патчи слать имейлом или телегой. А можно бандлы.

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

Мутабельные ссылки в распределенном окружении без механизмов согласования (их можно было бы хотя бы версионировать!)

Что я хочу сказать? Вот ты делаешь что-то гитом (это ответ на вопрос "как". гитом), а откуда ты знаешь, чего ты хочешь добиться и что это делается именно так? Первый вопрос совершенно точно из ментальной модели "распределенный контроль версий и что нам от него надо".

К вопросу о ментальных моделях. Если слово не нравится, предложите как-то другое. Есть вот такая вещь, как syncthing. Хорошая штука, именно она вдохновила делать hbs2, потому, что в целом оно работает и у меня есть расшаренный на все девайсы набор данных (файлы, фотки), но (skipped), но сделать на ней то, что мне надо - нельзя, и модель у неё странная. То есть там есть сущность "устройство". Потом "устройство" "предлагает" "папку" (folder) c квази-уникальным id. Потом ты вручную прописываешь, в какой каталог на диске смотрит эта "папка", и если несколько "папок" смотрят в один каталог, syncthing с переменным успехом пытается мержить редактируемые одновременно каталоги. Даже с одним писателем (мной), это время от времени вызывает конфликты, как оно мержит — непонятно, т.е даже невозможно под него подстроиться. С git это не будет работать, если будет несколько писателей, хотя казалось бы, в git каждый объект уникален. Каждый, да не каждый, есть ссылки (которые просто файлы!) на объекты, и еще пачка неверсионируемого контента. Нельзя каталог с гитом безопасно синхронизировать файловыми операциями. Это правда, косяк скорее гита, можно было более нормально сделать (как у нас в hbs2 бгг. ведь это гит на с стероидах (CAS на самом деле) с разными протоколами репликации). Это я просто обновлял мобилу взамен сгнившей и пытался передать с неё файл приватных ключей на новую мобилу, не через телеграм и не будучи уверен, что файл зашифрован, это ж андроид, gui, в нем непонятно ничего, что происходит. Минут через двадцать плюнул и экспортировал с ноута, убедившись, что зашифровано.

Возвращаясь с syncthing — видно, что модель кривая и в ней много лишнего. Мы хотим: иметь общий (виртуальный) каталог на кучу устройств, данные должны быть гарантированно зашифрованы, и доступ на чтение-запись только ограниченному кругу лиц (ключей, на самом деле). Сущности - каталог, ключ, круг ключей. Устройство - не сущность. Какая мне разница, что устройство afd6fcc5-1f28-43e9-a767-0170dc5b597d XPEH-C-BYGRA предлагает мне папку XXX ? Что мне делать с этой информацией? Даже если мне ip скажут (таже моя мобила, но через мобильную сеть).

Если подразумевается одновременное редактирование — то должен быть какой-то ясный алгоритм мержа. Ну и так-то всё.

git имеет такую великую вещь, как remote protocol helper, то есть можно делать push/fetch куда угодно, хоть в гугл диск, хоть в чат в телеграме, хоть в эхоконференцию в FIDO, лишь бы транслировалось в его понятия, которых у него совсем немного - получить объекты да установить ссылки. ссылки не версионируются (хаха!) поэтому внешнее хранилище должно это делать само, т.е должен быть некий алгоритм для ссылок (у нас в hbs2-git это выбор самой длинной цепочки из множества операций установки ссылки, что иногда приводит к лулзам)

Пользоваться корпоративными продуктами, аналоги которых есть в естественном виде в природе, стыдновато потому, что товаром там является не их сервис, а вы. Т.е они берут ваши деньги, а продают вас. Т.е это стыдно вообще с любой стороны, даже проститутки в менее унизительном положении находятся. Ну а если их EULA запостить в Chat GPT и попросить сделать выжимку, то единственным смыслом там останется ПНАХ. Да, от этого невозможно избавиться совсем, но не значит, что нельзя к этому стремиться. Это не бинарное состояние, это измеримый KPI. Количество позора можно снижать год за годом.

В suckless-conf (конфиги на sexp) добавились FromJSON/ToJSON , теперь можно сериализовывать/десериализовывать объекты в sexp-ы и работать с этим конфигом традиционным унылым хаскельным путём. Пользуясь случаем хочу в очередной раз заявить, что sexp-ы сила, json-могила. В json - убогая семантика встроенных когда-то в ecmascript структур данных, а в sexp - вся мощь любых dsl.

hbs2://JAuk1UJzZfbDGKVazSQU5yYQ3NGfk4gVeZzBCduf5TgQ

https://github.com/voidlizard/suckless-conf

Сегодня будет коммит в hbs2-git, который в общем-то не ломает совместимость, но меняет способ вычисления значения ссылок (бранчей), и после него те, кто на новой версии и на старой версии могут видеть разное значение бранча. На текущей "стабильной" версии некорректно работали push —force и удаление бранча. На новой будут, но только для новых пушей, т.е если у вас удалённый бранч не хотел удаляться - то надо будет его удалить еще раз.

Другими словами, надо будет обновиться на master, хотя master ветка, вроде как, не стабильная сейчас. Я думал, что следующим большим релизом будет шифрование резиториев / приватные репозитории, но вот нет. Но зато у нас есть каналы с множеством писателей и возможностью их удалять/добавлять (refchan), и демо онлайн BFT консенсуса поверх hbs2, который, вроде как, работает.

Как работает hbs2-git раньше и сейчас. hbs2-git пишет в "reflog". "Reflog" это некая мутабельная ссылка, в которую может писать только владелец приватного ключа, который и определяет рефлог, т.е приватный ключ это он и есть. В рефлог пишутся "транзакции", каждая может быть чем угодно, порядок не гарантируется, кроме лексикографического, это append-only growing set. Что внутри транзакций знают только писатели-читатели. Например, там могут быть объекты git. Но не по одному: hbs2-git для каждого push формирует лог в виде файла, куда пишет все новые объекты. Формат лога имеет определенную структуру и последовательность в надежде, что он будет хотя бы частично повторно использован. В любом случае, в каждый журнал операции push пишутся только те объекты, которых еще нет в стейте, где стейт - это объединение всех предыдущих журналов. Помимо самих объектов git, с которыми git знает что делать и порядок их (коммитов) - это DAG и управляетс самим git, есть еще "ссылки", они же бранчи, они же теги. Ссылка в git это текстовый файл, в котором лежит хэш коммита. Таким образом, ссылка указывает на голову цепочки. Это буквально неверсионируемый текстовый файл и нам надо обеспечить консенсус относительно него, т.е ввести порядок операций модификации, что не так-то просто. Как нам определить порядок операций? Можно ввести отдельный CRDT счётчик, хоть там есть нюансы. Ну а можно взять естественный. Раньше это была максимальная глубина DAG git для этого журнала, но поскольку в git как угодно можно (и часто нужно) редактировать историю —- это так себе ориентир. Но вот поскольку журнал транзакций рефлога только растёт, можно в момент git push вычислять этот самый счётчик, который суть число транзакций в журнале. У нас один писатель. Если некто на разных хостах запушит операции с одинаковым rank - то возможна неоднозначность. Однако же, поскольку у нас он является единственным владельцем канала, то таким образом он будет византийствовать только в отношении себя самого. Ну и пожалуйста, ССЗБ.

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

Тем временем, "распределенный" git aka hbs2-git эксплутируется уже полгода и скорее, работает.

https://www.youtube.com/watch?v=esMjP-7jlRE

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

Статья того же Клеппмана, тож проезжается по облачным сервисам.

Local-First Software: You Own Your Data, in spite of the Cloud
Martin Kleppmann, University of Cambridge, Cambridge, United Kingdom

UK под санкциями?

Меня, правда, удивляет столько внимания вокруг совместного редактирования документов прямо в реальном времени в wysiwyg. Это же дичь и неудобно, кроме того, часто может бесить. Кто-то реально так делает - в четыре руки документ пишет? так-то git+latex и ок. жалко, что нет попроще формата, чем latex. adoc/markdown/rst - ну такое себе, rst еще и мержить плохо, конечно.

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

Решил всё-таки потыкать в задачу "приватных репозиториев". Самый лобовой подход - использование группового ключа - т.е шифруем некий ключ публичными ключами пользователей, и им шифруем наши данные. Компрометация ключа пользователя, таким образом, даёт возможность прочитать всё, что мы таким образом разделим, до момента, пока мы не исключим скомпрометированный ключ из группового ключа. Кажется, такая схема не обеспечивает полный PFS, но так же кажется, что его тут лучше и не сделать. Или есть какая-то более лучшая схема? В целом, это не лучше и не хуже традиционного подхода с репозиториями. Любой пользователь может украсть и раздать все данные, до того момента, пока у него был доступ. Или можно лучше? Сильно упарываться даже смысла нет - если данные в итоге в открытом виде улягутся в репозиторий git в виде объектов, можно невозбранно покрасть его и это, в целом, не обойти

Я не настоящий криптограф, однако жизнь заставляет. Скажите, вот есть у нас некий сравнительно большой файл, который разбивается на блоки, и есть желание его шифровать, например, симметричным ключом алгоримом из libsodium. Надо генерить нонс для каждого блока или можно сгенерить его для всего файла целиком? Что такое вообще "повторное использование нонса" ? Что считается повтором? Ежели шифр потоковый — то говорить про блоки не приходится ведь? Если нонс может быть просто целым числом - порядковым номером блока - то ведь тогда можно просто один нонс на весь файл сгенерить? Или нет? Или что?

Какой же геморрой эта ваша криптография.

Починил схему шифрования согласно рекомендациям @rblaze, в итоге тормозит... ну посильнее, чем могло бы быть, но не критично. Пришлось делать временные файлы и вот это всё. Зато шифрование детерминированное (от ключа и контента), если пользователь не захотел иного. Интересное про хаскелл: siphash из memory очень быстрый. Прямо практически без разницы, читать файл по блокам, или читать файл по блокам и хэшировать. fnv1 значительно медленнее. murmur2 очень медленный (а я его брал, как быстрый хэш куда-то там в сетевую часть (выпилить!)). xxHash не собирается ну и пакеты с ним выглядят подозрительно - старые да маленькие. В итоге, для вычисления нонса блока - читаю файл по блокам, для каждого блока считаю siphash, потом сипхэши склеиваю и от этого считаю blake256, оказалось быстрее всего, незначительно медленнее, чем просто лишний раз прочитать файл по блокам и эти блоки посчитать. Нонсы блоков беру от номеров блоков + начальный нонс. Сессионный ключ вывожу из нонса файла (см. выше) и HKDF. Это используется для положения в сторейдж порезаннаго на блоки файла. Как если бы вы хотели раздать торрент ограниченной (групповым ключом шифрования) группе лиц. Написал мурзилку про ограничения такой схемы (https://github.com/voidlizard/hbs2/blob/master/docs/notes/group-key-update-note.txt) но внезапно понял, что это ограничение - вообще для любой информации, которая когда либо опубликована в интернете, т.е для обычного облака верна тоже. Коротко: что однажды в интернете опубликовано, разопубликовать уже нельзя. Таким образом, централизованная схема вообще ничем не лучше децентрализованной (to be continued...)

Сейчас вот думаю над тем, как это всё прикручивать к hbs2-git, дело в том, что функции шифрования/расшифрования хотят полноценный сторейдж, ну как полноценный. нет, не полноценный, там нужно всего пара функций оттуда. общая схема такова, что есть "сторейдж", который пока что встраивается, есть hbs2-peer, который занимается сетью (и сторейджем), и есть клиенты (hbs2-git). Сторейдж вроде как безопасен для конкурентной записи прямо на уровне FS, но это стрёмно. Так-то блоки пишутся один раз (свойство CAS), ссылки обновляются атомарно (rename), но всё равно -- стрёмно. Выбор - то ли клиенту (hbs2-git) ходить в пира по http - но там не все функции сторейджа доступны, а если делать все - то либо авторизация/аутентификация (стрёмно), либо просто стрёмно. Делать через TCP не хочется, т.к. стрёмные функции не хочется экспонировать наружу (стрёмно), остаётся только unix socket, и это уж очень интересная вещь оказалась: sockaddr там имя файла (которое не уникально), а на каждый connect делается новый сокет, и отсутствие уникального sockaddr ломает текущую абстракцию Messaging с одной стороны, а с другой стороны - делает возможной двунаправленную коммуникацию между "клиентом" и "сервером", т.е даже если у нас внешний "клиент" hbs2-peer-а является "сервером" (сервер - это тот, кто делает listen/accept или тот, кто предоставляет функции - при этом с точки зрения сети это может быть клиент (что бы юник-сокет менеджила та сторона, которой это надо)) - то любая сторона может быть инициатором коммуникации. И это свойство, блин, уже используется, даже не хочется его ломать. Так вот, что бы часть rpc hbs2-peer экспонировать через unix сокеты - надо или это свойство сломать, или как-то извернуться, или не делать через unix socket вообще. Короче, работа порождает работу, а думалось, что после детерминистичного группового шифрования я к это к гиту за день прикручу. Но нет.

Забавная история: этот вот "децентрализованный гит" я хотел очень давно (пять лет? десять лет?), и тогда (давно) меня останавливало то, что я не знал, как его сделать без "пира", т.е без какой-то штуки, которая реализует некое подобие консенсуса для согласованного обновления данных репозитория в итоге. Т.е чисто на уровне структуры данных. Напоминаю, у гита есть мутабельная часть, которая вызовет конфликты при синхронизации репо на уровне файловой системы. Этот самый пир/консенсус казался чем-то сложным (и так оно и есть!) и был стоп-фактором. Так вот, теперь я знаю, как сделать это чисто для гита: есть каталог - суть пачка файлов. Каждый файл уникален, его имя == его хэшу, а внутри - подписанная "операция". Операция - ну, какая-то операция над репозиторием, например, изменение ссылки, всё, кроме изменения ссылки - тривиально, а в операции изменения ссылки должно быть что-то, что позволит эти операции упорядочить. Собственно, всё. Эту пачку файлов - синхронизируйте хоть rsync-ом, хоть торрентом, хоть syncthing. Потом процесс (оффлайн) бежит по этим файлам, и выполняет операции в них согласно правилам (импорт объектов - тривиально, обновление ссылок - согласно правилам). Но rsync это гемор с адресацией пиров и доступами, а торрент - почти ок, но СРКН заставляет провайдеров давить DHT, а syncthing у нас так и не заработал, когда надо пошарить на разных людей (не знаю, почему!). Представьте, в гите сразу бы так сделали (ссылки - первосортные объекты, операции их изменения упорядочены, ключ подписи является идентификатором автора, сразу добавляются естественные ACL). Сервер/сетевая часть не нужна. Ладно, утреннюю раскачку закончил, пойду пилить.

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

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

До Накомото (неважно, он существовал или нет), может быть, и были мысли, что идентификатор == публичный ключ, а право — это факт владения приватным ключом, которое доказывается подписью. Но это не было мейнстримом, т.е вся идентификация в сети делается иначе миллионом способов. Какие имейлы, какие-то логины, какие-то пароли. Вся эта хрень не нужна вообще. Причем тут вообще имейл и аутентификация? Особенно сейчас. Выглядит просто как анекдот. В принципе, большая часть того, что у нас (в IT) есть — выглядит, как анекдот.

Т.е у Торвальдса в моменте было всё, что бы гит сделать нормально - как некий журнал операций (CRDT!) с аутентификацией криптоключами (и больше ничего не нужно) — но не было понимания, что 1) это нужно 2) это не так уж сложно. Т.е все кусочки по отдельности в моменте были: понятие о CAS, криптоподпись. Не было термина CRDT, но, например, git это растущее множество уникальных объектов (+ мутабельные ссылки, как бельмо в глазу). В итоге гит оброс всяким — миллионом протоколов (с аутентификацией/авторизацией), гитхабами, как точкой централизации "децентрализованной" системы. А если бы сделать по уму — то для синхронизации репо ничего бы, кроме rsync-а или торрента (2001-ый год, раньше гита!) и не понадобилось бы. Т.е 1) типичный кейс ширины лошадиной жопы 2) работа порождает (ненужную) работу.

Кстати, email/instant messaging туда же. Решается одна и та же задача, миллионами способов, а решение есть более простое, если правильно поставить задачу.

Тоже самое с ЯП. Казалось бы, можно было бы сразу отделить фронтенд - промежуточное представлени - бэкенд, понять, что типизация/синтаксис - это вкусовщина, зафиксировать промежуточное представление, как высокоуровный ассемблер (скобки!), сделать простейший транслятор из синтаксиса в скобки и далее в машинный код, промежуточное представление не трогать, фронтенды пусть запиливают, как хотят, кто хочет. По дороге понять, что скобки гораздо лучше, чем ущербный синтаксис Cи, лучше скобок только хаскель.

Но нет, зато имеем язык Си и всё, что из него последовало (лошадиная жопа!) - типичный сон разума. Вебасм (почему веб?) появился в 2015, когда уже не нужно.