-
Рекурсивная правда Редакция газеты "Рекурсивная правда" в изгнании https://voidlizard.online/ Жизнь, спорт, разное - здесь: t.me/voidlizardonlineblog
git абсолютно бесконечен. если хорошо поискать, то найдется команда, которая заменит всю твою сложносоставную конструкцию. Например, получить транзитивное замыкание (все объекты) бранча в хронологическом порядке:
git rev-list --objects --no-object-names <rev>Читать полностью…
#offgrid #hbs2 работы ведутся, просто очередное выгорание. обычный режим - полгода работы овертайм, полгода в режиме овоща. удачно, когда овощной режим совпадает с летом. тестим tcp pex тем временем, вроде бы работает. надо бы сделать усилие и побороть эту циклотомию, конечно. с другой стороны, очень полезно выгрузить код из кэша в мозгу, потом когда заходишь —- видишь код совсем другими глазами, можно найти и убрать косяки. пока что думаю над вопросом, нельзя ли сделать обратную совместимость с текущим устройством репозитория, что бы не ломать ссылки. и кажется, что можно, но ценой дублирования данных. вечный трейдоф скорость/память
Читать полностью…
Задача в принципе решена, но уже понятно, что хорошего решения тут нет. Штош, остаётся сделать приемлемое. Будет хотя бы быстро работать. Написать PDF проще, чем написать код, вернее, не так жалко его выкинуть или переписать потом. А глупость, изложенная на бумаге почти сразу же видна, в отличие глупости в голове, которую бросаешься реализовывать. Прямо понравилось мне сначала написать документ. Буду практиковать.
Читать полностью…
Алиса оказалась той еще сучкой, прошлое решение - не решение. Походу, хорошего решения здесь вообще нет. Предосылка 1. "лог" объектов гита должен генерироваться только из репо, и репо + голова (push-объекты) и должно быть стейтом. 2. Лог стейта должен формироваться у всех участников одинаково, независимо от того, каким путём они эти объекты получили, хоть rsync-ом. 3. Лог должен писаться инкрементально. Решение: берём все коммиты, сортируем в топологическом порядке, одинаковые топологически сортируем по хэшам. Для каждого коммита берём его объекты, сортируем по хэшам. Для каждого коммита пишем объекты, пишем коммит. "Старые" объекты будут ближе к началу, новые - в конце лога. В этом случае, для одинаковых репозиториев лог будет одинаковый. Если Боб имеет привычку грохать временные бранчи, а мастеру делать git reset —hard на апстрим, как я, то его репо будет приходить в соответствие репо Алисы, и при последующих FETCH он будет выкачивать только новую часть. Мусор будет образовываться, тем не менее. Но кажется, ничего лучше тут не придумать, если не понижать гранулярность. Сейчас гранулярность = весь репо. Пишем объекты упорядоченно по сути по времени создания, и надеемся на лучшее. Можно еще попытаться вести логи для бранчей по отдельности, тогда при прибивании временного бранча возможно, мусор будет зачищен, надо подумать
Читать полностью…
Короче, ноука это когда у тебя не 2 стула. А 256K стульев и надо найти наиболее оптимальный стул по N параметрам. В итоге всё равно редуцируется до двух стульев - объем vs cpu time
Читать полностью…
Итоги предварительных изысканий: если писать все гитовые объекты в лог, одна секция = один объект с гитовым хэшем и размером, то: 1) лог пишется быстро 2) индексируется на проекте размером (упакованного) репо 12M быстро (= мгновенно, но это линейный проход файла - O(n) от числа объектов и ~ n * log n на индексацию), если вести один и тот же лог с момента начала репо - то у файла есть устойчивая стабильная часть, которая никогда не будет передаваться повторно. Однако, если в какой-то момент этот файл дропнуть и пересоздать из гита, и порядок объектов изменится - то в разбиении этого файла не будет вообще ничего общего с предыдущими файлами. Что наводит нас на следующую мысль: Алиса пилила пилила проект, инкрементально добавляя в лог. Потом Боб форкнул проект и накатил сверху патч, и отправил Алисе = опубликовал merkle tree своего лога. Получилось следующее:
AAAAAAAAAA|BBBBBГде BBBBB - разбиение объектов из гита Боба. Алиса приняла патч Боба, и получилось у неё следующее:
AAAAAAAAAA|YYYYYYYY|и Боб, несмотря на то, что у него все эти патчи есть, выкачивает upstream Алисы, т.к. из-за другого порядка, других смещений и т.п - разбиение upstream уже не
AAAAAAAAAA|BBBBB, а
AAAAAAAAAA|YYYYYYYY|- кусок же BBBBB - живет в форке Боба и никому, кроме него, не нужен. Т.е YYYYYYYY и BBBBB - это в принципе одни и те же объекты, но по-разному разбитые и это дублирование информации как раз.
AAAAAA|, то хвост этого файла не сойдется с Алисой уже никогда => у всех форков хвосты будут разные => огромное дублирование информации, если только не выкидывать форки и не начинать новые после того, как их изменения приняты. Но повлиять на это никак нельзя - пользователи ж могут творить, что хотят. Короче, явно нужно что-то разбивать на merkle деревья и уже эти меркл деревья писать в лог, либо же придумать стабильный формат, который будет одинаковый у всех для одинакового набора объектов. Собственно, кажется, что merkle-разбиение это и есть этот стабильный формат. Другое, что в голову приходит —- это сортировка секций файла каждый раз при push. Тогда идентичные объекты будут идти в логе одинаково, и в случае одинакового набора объектов файл сойдется рано или поздно. Но кажется, что гигабайтные репозитории сортировать каждый раз будет накладно. Можно писать в базу, базу дампить и разбивать, но это довольно всё медленно выходит даже на текущий момент Читать полностью…
Тем временем на гитхабе шлют спасибы за патч в USB стек STM32, который я пытался донести до производителя и через их форум, и через поддержку. 11 лет прошло, видимо, так и не починили.
Читать полностью…
И прогрессивный налог на энергопотребление введут в рамках зелёной повестки. Кстати, тоже странно, что еще нет — решает вопросы государств с криптой. Правда, люди оказались такими, что им любой PoS заходит да хоть вебмани, там что там особо толку не будет. Но вот биток-то можно прижать
Читать полностью…
А ведь мошенники уже, наверное, ставят на поток обучение нейронок, которые будут разводить людей на деньги. В массовых масштабах. Потому, что развод людей на деньги по скрипту - это идеальная задача для таких нейронок, и с автоматизацией её можно прям массово запускать. Приделать ручки для звонков/чатов и т.п. Прямо завод по производству денег и прямая монетизация этих нейронок. Инвест-план простой и прямой, как палка. Опять же, спасибо виталику, продавшему свой планктон американским регуляторам, GPU для майнинга больше не нужны, а вот для обучения нейронок - могут и пригодиться. Как всегда, до меня доходит, как до жирафа, кто надо уже полтора года назад, поди, всё поняли
Читать полностью…
в гите есть фича fast-import/fast-export - это дамп в текстовом формате всего репо. если репо испортировать/экспортировать через это, то будет быстро с одной стороны, но не будет дедупликации
Читать полностью…
Вчера катнул tcp в "прод". Ради понта даже сделал обратную совместимость по протоколам, чисто, что бы отработать концепт. Как и предполагалось, cborg/serialise ADT-шные конструкторы скорее всего добавляет, как кортежи, где числом - номер конструктора. Таким образом, в ADT-шные типы можно в конец добавлять конструкторы, и более старые версии не сломаются. PEX для TCP получается более хитрый, надо сначала выяснить, что пир в принципе поддерживает TCP, потом попытаться открыть к нему клиентское соединение, в случае успеха - добавлять в PEX, которым делиться с миром. В процессе. На следующей неделе доделаю. Походу мучений с TCP - как всегда, всё упёрлось в off-by-one ошибку где-то в глубинах - перепилил и UDP, теперь таймауты не хардкоды, а пропорциональны измеряемому RTT + если один поток скачивания заткнулся в таймауте - другой не ждёт и стартует раньше. Качать начало люто, что через Австралию, что напрямую. UDP ведёт себя как ему положено - на хорошей связи уделывает TCP, на плохой - начинает мигать битрейтом - т.е ждать каких-то потерянных пакетов до таймаута. В любом случае, в итоге увидел цифры доселе невиданные - до 80 мегабайт в секунду, и наконец-то стало упираться в CPU, вероятно, пересчёт хэшей, как положено. В целом, доволен. Так победим
Читать полностью…
Что-то от TCP мгновенного счасться не произошло. Когда работает UDP - он работает чуть лучше даже с самодельным congestion control, а когда не работает UDP - то и TCP тоже почему-то не работает. Что-то я надеялся, что подменю транспорт и сразу в дамки, но нет. Предвижу пару недель увлекательной отладки.
Читать полностью…
Думаю, что немногие заказные проекты, что остались - перетащим в hbs2 тоже в течение месяца. Хрен с ним, что нет шифрования, хотя по факту оно есть, надо только прикрутить и дисциплину ключей продумать. Если не класть туда секреты, то и шифровать особо незачем, всё одно в Роспатент поедет.
К fixme вполне можно прикрутить фронт, а к всему вместе - (статическую?) вебморду для гражданских. И принципиально сделать её стейтлесс - т.е вся авторизация только приватным ключом на клиенте, каждая транза на апдейт им подписывается, то, что зашифровано - им расшифровывается. думаю, в течение нескольких месяцев такое можно.
Получится своего рода продукт - среда разработки для команды + фронт для гражданских (заказчиков), без какого-либо стейта на сервере, расшифровка блоков перед отображением в js на клиенте. Вполне себе конь-цепт
Над какими-то вещами редко задумываешься. Или там абстрактно знаешь, но не прочувствовал.
Например, почему вайфай шляпа:
[notice] peer 5.227.202.xxx:7351 burst: 2 burst-max: errors: 0 down: 0 rtt: 210.00msЧитать полностью…
[notice] peer 95.216.187.xxx:7351 burst: 2 burst-max: errors: 0 down: 0 rtt: 19.00ms -- провод, Хельсинки
[notice] peer 213.141.129.xxx:7352 burst: 2 burst-max: errors: 0 down: 0 rtt: 9.00ms -- где-то в Москве, провод
[notice] peer 192.168.1.49:7353 burst: 2 burst-max: errors: 0 down: 0 rtt: 111.00ms -- вайфай, три метра от роутера
Квикфикс бага hbs2-git:
commit 343bfd607017f11ea48a752e19b7c0f51bc9c237 (HEAD -> master, hbs2/master)
Author: Dmitry Zuikov <dzuikov@gmail.com>
Date: Sun Apr 2 09:50:02 2023 +0300
hbs2-git db bugfix
#hbs2 #offgrid
... -> Protocol Encryption -> Fast Large Git Repos -> Git Repo Encryption -> MVP(1) в работе, (2) в работе Читать полностью…
Бесплатная раздача идей: нейросеть/нейросети, которые будут вместо тебя участвовать в совещаниях по зуму. Потом еще устраиваешься с этими нейросетями сразу в несколько мест менеджером и профит. Задавать вопросы "какой статус? за сколько сделаете? почему так долго?" чат гпт может уже сегодня, осталось анимировать картинку и голос синтезировать. Вроде бы всё по отдельности уже есть. Еще приделать ручки, что бы тикетами манипулировать, причем там можно даже без особого интеллекта, чисто рандомно. Ну хорошо, с интеллектом будет менее палевно. Не шучу, кстати. Всегда говорил, что значительня часть менеджмента может быть заменена скриптами, но никогда не думал, что нейросети и скрипты сделают ненужными.
Продукт практически идеальный: за то, что будет приносить деньги, люди будут платить. Конечно, кончится всё тем, что это сделают B2B сервисом и всех менеджеров нахрен поувольняют. Аналогичный продукт, который будет лепить отмазки тоже будет востребован. Chat GPT — король отмазок
Теперь самое гнусное решение: 1) выравниваем все объекты до некоей границы (64K / 256K ) . 2) считаем хэши от дополненных объектов 3) в сторейдж пишем в сжатом виде (оверхед по данным около нуля) 4) передаём блоки в сжатом виде, в BlockInfo говорим, что блок сжат - при пересчёте хэша распаковываем. Оверхед по данным при хранении устраняется, при пересылке - устраняется, ну и вообще принуждает сжимать данные, что невредно. Возникает оверхед при пересчёте хэшей, но насколько но значителен? А мерзкое решение потому, что это куча мелких изменений в разных местах протокола.
Читать полностью…
Немножко описал проблему формата hbs2-git репозитория и проблему дизайна стейта в целом. Пока не решил, хотя пока не начал писать документ, казалось, что решил. В документе есть немного про устройство системы и форматы данных, думаю, что это личинка будущего описания системы. В PDF, так как картинки
Читать полностью…
UPD2. С другой стороны, если писать объекты выровненными на границу 256K блока, то опять появляются стабильные куски, отличающиеся только порядком следования блоков. Как проверить: пишем лог гита, выравнивая каждый объект на границу 256K (плохо для мелких объектов, которых в гите много!). Инкрементально добавляем новые объекты, каждый выравниваем на границу 256K. Дампим merkle разбиение. Грохаем лог. Пересоздаём лог. Ожидание: значительное пересечение по хэшам merkle-разбиения (без выравнивания: вообще ничего общего).
UPD3. Поскольку merkle-разбиение мы можем делать на блоки любых размеров, можно, например, выравнивать на границу 4K. Это даст какие-то смутные бенефиты при чтении-записи на диск возможно. Но станет больше блоков/больше хэшей, возрастёт нагрузка на CPU и возможно всё на сколько-то замедлится
UPD4. Если для текущего репозитория писать объекты, выравнивая по границе 256K, то оверхед будет 2G. Если выравнивать по 4K - то оверхед будет 13M, при том, что весь упакованный репозиторий 13M и есть. Если выравнивать на 1K, то особо оверхеда нет. Но теперь хэшей/секций становится в 256 раз больше, не придём ли мы к той же проблеме кучи мелких объектов
#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.
Читать полностью…
А у вас нет ощущения, что поисковики последние годы деградируют? Ну то есть тупо стали хуже искать. То, что раньше находилось - сейчас не находится. Или же это тупо деградирует сам веб - контент переезжает в те ресурсы, которые не индексируются, причем не всё, а только "актуальное", а ресурсы где раньше было - просто тихо дохнут. Нет ли такого?
Читать полностью…
Сейчас государства опять встрепенутся, и поймут, что они нужны не только детей от педофилов защищать, а еще и распространение технологий контролировать. Данные по нейросетям к хренам закроют, GPU будут регистрировать, как оружие. И всё ради общественного блага.
Читать полностью…
В общем, есть два стула. Скорость или дедупликация. Надо выбрать.
Читать полностью…
Большое количество мелких файлов - реально, источник проблем. Хотелось каждому блобу в гите сопоставить объект в системе и на метаинформацию тоже файл. Но что-то их становится овердофига, и они медленно качаются, как бы быстро не пытался. Ну и вообще видно, что это будуший источник проблем. Надо что-то переосмысливать, пока оно несильно распространилось
Читать полностью…
А подскажите кто-нибудь хостинг с локациями в ЮВА / Австралии? И желательно, что бы криптой можно было платить или еще как-то нормально, евпочя.
Читать полностью…
#haskell А не может внезапно выясниться, что
TVar [x]- работает не хуже STM-ной очереди, при этом можно с ней хоть рингбуфер делать, хоть что. Или не выяснится ли там, что STM-ные очереди - это TVar + очереди Окасаки? неохота смотреть, кто-то разбирался? Читать полностью…
Гримасы распределённых систем: постишь транзакцию через свою ноду. Забываешь её сохранить. Твой кластер синхронизируется и ты получаешь транзу от других, стейт сходится, не замечаешь разницы. Другая сторонняя нода постит ссылку со своим ключом, транза не сохраняется, связь с той нодой пропадает, на собственную рассылку она не подписана. В итоге на ноде - источнике транзакций, ключ подписи которых есть только у неё — имеет меньше транзакций, чем все остальные ноды. А ты смотришь на это всё и сходишь с ума
Читать полностью…
Экспортируем репо побольше. Работает медленновато, но это надо один раз. Можно ускорить
Читать полностью…
Каким-то образом magic-wormhole унижает и scp тоже. То есть он не просто копирует между двумя хостами через свой релей, но каким-то образом делает это лучше, чем просто копирование файла с хоста на хост. Достойный соперник, одним словом
Читать полностью…