Тем временем,

[dmz@expert:~/w/hbs2]$ hbs2-peer fetch -p HRDcFo2PwTQkEmPPECbZivdUf788s3GumhhqtgErHhfc && hbs2 cat HRDcFo2PwTQkEmPPECbZivdUf788s3GumhhqtgErHhfc
NCQ3-PREVED-20250822

посмотрим, где теперь прострелит.

Как вот так получается, что Snapgradon/ARM - по сути телефонный SoC, андроид — это линукс, а линукс на ноутах со Snapdragon практически не работает. Или винда или макбук. Винда нот ан опшн, а mac — зловещая долина. Там буквально ВСЁ по мелочам сделано так, что вызывает вопросы — в порядке авторы или нет. Незакрывающиеся терминалы, недонастроенный баш, хоткеи которые почти — но не совсем, т.е типа надо палец на одну кнопку сдвинуть и это почти невозможно. Мышиного копирования по умолчанию нет. Понятно, что всё можно настроить, но там надо настроить буквально прямо всё. А если комп поменяется — получится его раскатать, как из flake.nix что бы все эти настройки обратно заехали? Вопрос.

fish признается bf6-совместимым и вообще годнотой. картинка в коментах

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

У нас есть — концепт мессенджера, веб. E2E P2P вся фигня. Вроде работает, но подозреваю много проблем из-за несвоевременного вкорячивания UI.

Что бы работало нормально без локальной ноды — надо бы научиться делать cbor пакеты на клиенте и шифровать.

Можно сделать чисто консольный прототип. Если нашлось что-то, от чего было бы легко взять фронтенд и туда подсунуть hbs2 в качестве бэкенда — было бы отлично, но я ничего такого не нашёл.

Можно сделать local-first juick — т.е по сути мессадж борду по модели твиттера ( у каждого свой канал; каждый пишет к себе; те кто подписался — становятся новыми точками раздачи). Можно допустим шарить подписки, кроме того —- можно натренировать какую-то микросетку, что бы работала, как система рекомендаций.

Подмывает сделать vcs чисто поржать — по модели "все есть меркл дерево" и посмотреть, что получится. По сути она делается добавлением "манифестов" / "чекпойнтов" в hbs2-sync но надо подумать. Нафига её делать... Ну, получу time machine для проекта, который хотел + у меня есть кейс публикации подпроектов из монорепы; можно на уровне дизайна сделать "подпроект" и манипуляцию ими.

Морду для гита мне делать не хочется. Очень много UI, очень мало профита. По сути можно синкать через hbs2-git локальный git bare repo и натравить на него любую вебморду гита. Т.е основной вектор усилий будет смещен в сторону UI и веба, кажется, это просто трата времени. По факту лично мне вебморда для гита особо не нужна. Я даже lazygit ленюсь использовать. При таких вводных вряд ли получится хорошо.

Возможно продуктивнее просто взять движок hbs2.net - статический генератор с бэкендом в CAS — немного допилить + прикрутить шаблоны и выложить как средство для публикации своих проектов + сделать какой-то каталог.

Весь hbs2.net это просто небольшая обвязка на bf6 вокруг hbs2-cli — интерпретатора для вызова функций hbs2. ну там сохранить блок/дерево/ссылку и тп.

hbs2-sync + fuse вроде тоже пилится и синхронизирован со сторейджем. Будем мержить всё вместе. Для больших каталогов (файлопомоек) без нового сторейджа оно сдохнет, а с ним нет.

Мне хочется для поржать сделать vcs, но со сторейджем я тоже думал что приключение на пару недель, чо там - в файл пишешь, из файла читаешь, LSM, всё просто.

Кажется, что ввиду общего вот этого фона правильнее двигаться в сторону борды + чуть позже к ней прикрутить приватные сообщения + сделать некий аналог KeyBase возможно.

Есть мысли?

Уверен, что протоколом mailbox никто кроме меня не пользовался, но если что —- миграция на новый сторейдж его поломала. То есть не его, а состояние сообщений (импортировано/нет).

Как раз за счёт того, что не сохранял исходные хэши посоленных хэшей ссылок.

Починябельно; из хороших новостей — оно в целом работает.

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

hbs2 dev-0.25.3 доступен для скачивания/установки/тестирования.

https://hbs2.net/ref/4X65y4YvUjRL2gtA9Ec3YDDP4bnxjTGhfjpoah96t3z1/get

статус — тест. может, "бета". поменялся внутренний сторейдж, теперь на NCQ3. поменялся тулчейн — hbs2 теперь скриптовая обёртка над hbs2-cli, могли отъехать маны или что-то недообернулось. надо будет смотреть. буду довыкладывать.

Миграция вроде работает. На Mac OS X вроде работает. Пойду смигрирую маковую ноду, кстати.

Перед миграцией рекомендую бэкап, но оно и само не будет удалять старую бд, только переименует.

Тестировал миграцию на 50Gb снапшоте, отработало за O(1) по памяти (это же Haskell, так что это важно).

Про сторейдж написал тут:
https://hbs2.net/ref/4X65y4YvUjRL2gtA9Ec3YDDP4bnxjTGhfjpoah96t3z1/ncq3

TL;DR - раньше CAS был, как у старого гита — один объект один файл. Что было не так уж плохо, т.к объекты у нас довольно большие.

Потом стал NCQv1 — слегка похоже на git packs (один файл данных — один индекс. структура, впрочем, другая - что данных, что индекса). Чем был плох — подозрение, что заклинит на очень больших объемах + плохо переживал выключения питания и kill -9.

Сейчас CAS — дисковые хэштаблицы (lookup O(1)) в качестве индексов + append only журналы для хранения данных. журналы и индексы мержатся, мусор собирается при мерже. Журналы данных — 512M ... 8G + delta (чот типа 9.3 получается). На что влияет: если сделать верхний край больше — очень хреново переписываются на слабых компах. Если сделать их меньше — то могут поджирать лимиты числа запамленных файлов и подтормаживать при поиске.

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

C этим сторейджем можно уже ехать дальше, например делать большие распределенные файловые хранилища и т.п.

Btw, у нас в IT почти все ружья стреляют. Вот например есть такой nix и есть такой git. И nix любит лазить в гит, а еще ссылаться на код по гитовой "ссылке" — так вот поскольку ссылки в гите являются симулякром, то ситуации, когда на одном хосте ссылка смотрит на одно, а на другом хосте — на другое —- или у nix вообще в рамках одного хоста мозги вышибает из-за хэшей, как раз.

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

Делаем тарболл, кладём в hbs2, потом собираем и прочее вот так:

nix build localhost:5000/tree/Aog9nHUMSLFgVaCBWqLjWDU4FZ6x2KibPo9XADM3QaNW

С тех пор, как перешел на такую схему — стало ноль проблем с nix. TL;DR — помог отказ от гита.

казалось бы, что может быть вообще проще, чем скачать файл и записать его на диск. отсюда даже пошла поговорка — как два пальц байта переслать. По UDP, сука. Основная проблема даже не в том, что сеть плохая — сеть как раз хорошая. Пакеты приезжают. Просто туда, где их уже никто не ждёт