Спросил вопрос про NixOS в русскоязычном чате NixOS.Был накормлен вторичным продуктом. Вспомнил историю успеха получения поддержки в этом чате (равную нулю), и выпилился оттуда. Спросил свой вопрос у ChatGPT. Чувствую, скоро мы все пойдем на мороз

@blaze к твоей реплике про переизобретение QUIC. сейчас в протоколе есть: подпротоколы (различные отдельные FSM), которые работают не мешая друг другу. То есть, если один поток ждёт 4 пакета, то вклинившийся туда пакет от другого подпротокола никак не помешает. Другие FSM занимаются своими делами: пингуют, передают PEX и так далее. В протоколе нет: ACK. Точнее, они есть или нет для подпротоколов. В каких-то (передача данных) - терять ничего нельзя. там есть ACK. В каких-то всё равно, там нет. Вся эта пачка протоколов работает на одном сокете/порту. Чего нет пока - шифрования. С одной стороны шифруются сами данные, с другой стороны просто временно открутили, ничего не мешает вкрутить обратно. Что есть еще: самодеятельный протокол CC, высосанный из пальца из общих соображений, но похожий на какие-то другие известные протоколы. Кажется, до переизобретения QUIC осталось вернуть на место шифрование и вкрутить нормальный CC. Однако, всё это намного меньше, чем QUIC, так как тут не пытались изображать потоки. Протокол ориентирован на датаграммы, просто по несчастью какие-то из них такие большие, что не лезут в один пакет

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

1) повесить inotify на гит, и на изменение репозитория его автоматом забрасывать в offgrid/hbs2 и делать анонс
2) сделать commit hook, который будет коммит забрасывать в offgrid/hbs2 и делать анонс

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

#fixme теперь вместо

fixme set workflow backlog XXXX

можно определить макро в конфиге и писать

fixme backlog XXXX

Есть ощущение, что для пущей крутизны файлы надо уже класть в hbs2, и приделать к нему http, который бы их отдавал по хэшу. тем более, что для этого уже все внутренние ручки есть. nginx только настроить с кэшированием

надо в проект CoC запилить. думаю, такой: НОРМАЛЬНО ДЕЛАЙ - НОРМАЛЬНО БУДЕТ.

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

Признавайтесь, кто в нашему кластеру прицепился? Хотя б порт назад откройте, что бы пинговать можно было. Чувствую, пока мутабельные ссылки подъезжают, надо сделать перерыв в реализации гита и запилить NAT-PMP

Так или иначе, но похоже, что полноценно работающий "распределенный" гит до конца этой недели заработает (со ссылками. без ссылок он и так как-то работает). Интересно, что же желать дальше — ликвидировать технический долг? прикручивать криптографию везде, где откручено? Запилить пару шоукейсов (распределенный чат ? шаринг файлов / каталогов ?) Написать какую-то статью/пост о том, как это всё работает (спойлер: наиболее простым и очевидным способом из возможных) Прикрутить другие типы ссылок, а не только линейные с одним писателем ?

Когда работал в Keenetic, смотрел, как делается "операционная система" изнутри - т.е интегрированная куча софта на базе какого-то другого софта + сколько-то своего софта + клей. Всегда было какое-то зудящее чувство, что вот, хорошо бы всё это запилить на каком-то нормальном языке. Там еще и сетевые абстракции свои были, и всё это на подможестве плюсов - плюсы без самого вкусного, т.к. шаблоны раздували код, который не лез на маленькую внутреннюю флешку. Плюс там еще контуженное телекомовское сообщество породило стандарты типа TR-069, короче ехал SOAP через SOAP, можете в UPnP полюбоваться. Короче, впилили эрланг, эрланг в роутер влез (но больше ничего не влезло), но переписать огромную кодовую базу и передизайнить огромную модель на другом языке - с какого-то момента задача неподъемная. Так вот. Тогда в то время возникала какая-то идея, что надо всё потребное, например, для ноута - согнать в какой-то демон на приличном языке, и таскать с собой, время от времени портируя на новые модели железа. Идея умерла, т.к. дело это огромное, но почти бессмысленное. Но в итоге-то, оказалось, что на базе nix + помойка из всего — по факту вполне подъемно для одного. Ведь по сути ты делаешь свою ОС, где всё, как тебе нравится, она может деплоится на разные хосты, а системно-зависимые куски можно как-то абстрагировать. И на это не надо тратить весь остаток жизни. Да, в итоге адовая смесь из nix, haskell, bash, evlish, конфигов и бог знает чего еще. Но оно в целом работает, хоть всё и стрёмно изнутри (и в идеальном мире было бы написано на каком-то нормальном языке), но вроде довольно надёжно и работает. Самый треш, конечно, это когда ты никсом генеришь хакельный код (а не наоборот, как должно было бы быть в нормальном мире).

Кстати, прo elvish. Нужен был язык для шельного скриптования получше, чем баш, по по факту elvish им не является, более того, в каких-то моментах он до смешного убог и проигрывает даже bash.

Пока неохотно, но коммиты расползаются по нодам. Бесплатно получаем зачаток чата, чем gossip не чат. по сути чем сплетни отличаются от трёпа? Учитывая, что распределенный сторейдж идёт в комплекте, можно уже запиливать еще один распределенный мессенджер. И везде сплошное UDP!

code review с fixme:
делай раз:

cat .fixme/config
...
fixme-prefix     REVIEW:    review
...

делай два

cat .fixme/config
...
[ fixme-report review json
  (render builtin:microstache report-wip.tpl)
  (post builtin:columns | 10 10 8 12 _)
  (query tag:REVIEW:)
]
...

делай три

  -- REVIEW: no-time-to-die
    просто удаляй пира из вайтлиста,
    если он в блэклисте

  unless (Set.disjoint blkeys wlkeys) do
    die "whitelist and blacklist intersect"

делай четыре:

[dmz@expert:~/w/hbs2]$ fixme report review
Da2nChoaL9 []         REVIEW:               no-time-to-die

et voila:

Со ссылками не очень прикольная ситуация. Ссылка - это некая глобальная идентифицированная мутабельная переменная в распределенной системе, состояние которой определяется неким консенсусом. Ну, например, простой тип консенсуса - когда писатель только один и у ссылки есть версия. Тогда все участники сети просто сохраняют последнюю известную им версию ссылки и её же отдают, когда их попросят. Это один самый частный случай. В идеале, поскольку система просто представляет собой сетевой уровень, хочется, что бы состояние ссылки и тип консенсуса определялся внешним приложением. Для этого состояние ссылки надо просто пропихивать туда (во внешнее приложение), как есть. Если мы просто в онлайне просто слушаем и пересылаем эти самые ссылки, вернее, транзации об изменении их состояния - то всё просто работает — ссылку получили, пруфы (подпись, например) проверили, если ок - переслали. Вопрос, что делать если pull модель - т.е кто-то к нам приходит и говорит - дай лог для ссылки. Во первых, если ссылка нам не принадлежит - мы лог не можем подписать той же подписью — можем только переслать его как есть, т.е лог будет не содержимого транзакций, а самих (подписанных) транзакций. Неудобно, но, допустим, ок. Во вторых - лог может быть дюже здоровенный, а как-то фильтровать мы его не можем, мы же не знаем, что там внутри в транзах. Допустим, сделать запрос "дай N последних транз" - а что такое "последних" ? Последних принятных в хронологическом порядке? Последних N принятых в хронологическом порядке, упорядоченных по хэшам? Понятно, что можно сделать как-то. Но хочется сделать как-то логично и минимально, что бы несколько каких-то рандомных частных случаев на уровень протокола

Конкретно для гита с одним писателем - стейт это просто транзация с максимальным номером и ссылкой на merkle дерево состояния (head репозитория [состояние всех бранчей + транзитивное замыкание коммитов]). Вопрос в том, что для разных приложений понимание стейта может быть разным, вопрос какие примитивы должны быть в самой системе

Короче, для гита и случая, когда нода hbs2 в онлайне - всё работает с довольно общим механизмом. Теперь надо решить для случая, когда нода была в офлайне / стартует в начальный момент времени и ничего не знает про ссылку. Самое простое - попросить соседей переслать то, что у них есть. Конкретно это означает, что 1) рассылаем всем нодам запрос "проиграй свой лог транзакций 2) они плюют в ответ все транзы, которые у них есть - если есть сто, то сто. Если тысяча, то тысячу (UDP пакетов), если сто тысяч - то сто тысяч. Ну чот такое себе. Что же делать

Как работает git clone hbs2://...

#hbs2 @offgrid Удалось, кстати, это всё запустить на raspberri pi, что странно для хаскеля с TemplateHaskell. Видимо ноука шагнула за пять лет далеко вперёд. Неожиданно