Haskell-ный petrovich здесь:

git clone hbs23://DnzR3EgPTmQ9Gkmjr1t5umiNDVqC67bR4BzKcnYDaTsC petrovich-hs

в прошлый раз дал ссылку на зашифрованный репо, не склонится. Эта открытая.

Использование примерно так:

ghci> let name  = fromJust $ parseName "Иванова Татьяна Генриховна"
...

ghci> detectGender name
Just F

-- ruleGen from here:

--data Rule =
--  Rule {
-- ...
--   , ruleNom        :: Nom
--   , ruleGen        :: Gen
--   , ruleDat        :: Dat
--   , ruleAcc        :: Acc
--   , ruleIns        :: Ins
--   , rulePre        :: Pre
--  }

ghci> inclineName ruleGen Nothing name
...

гендер детектит... как-то само или можно явно указать. Попробую добавить скелет странички проекта, вопрос что там должно быть (последние N коммитов? ссылка на архив?).

Думаю для минимально скелета сойдет README.md + ссылка на репо.

как-то так:

https://hbs2.net/ref/2ryFDHtC6yDk6XQNidVaayy6NUUUMb4RV7aG61Cp2ue5

(define site:ref  :2ryFDHtC6yDk6XQNidVaayy6NUUUMb4RV7aG61Cp2ue5)

(define (from:markdown:file f)
    (call:proc:raw pandoc -s -t :markdown -t :html f)
)

(define (as-html n) [kw :file-name n :mime-type "text/html; charset=utf-8"])

(define README
  (begin
    (local readme (from:markdown:file ../README.md))
    ; (local html (skel '[] readme "petrovich"))
    (local meta [kw :file-name :index.html :mime-type "text/html; charset=utf-8"])
    (hbs2:tree:metadata:string meta readme)
  )

)

(define (publish)
  (hbs2:lwwref:update site:ref README))

 hbs2-cli import ./page.ss and publish

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

Продолжаем сторейдж. Кажется, в текущем дизайне я лоханулся, хорошо, что он никуда еще не успел пойти (...)

Сторейдж в целом готов. Осталось сделать компакцию, которая получается очень простая: берём два самых старых файла в A и B в порядке обратном таймстемпам, пишем все записи которые не томбы из A в C, потом все записи, которых не было в A и которые не томбы из B в C. Индексируем C. Атомарно удаляем A и B из списка tracked files, C добавляем. Таймстемп C <- таймстемп A.

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

А теперь — зачем это всё было. Вот сравнение трех сторейджей:

новый (ncq), sqlite-mock (просто пишем блоки в таблицу, ключ = 32 байта), старый (git-like loose). пишем дерево Меркла для 2.5G файла, 32 байта ключ, 256K - значение.

Интересно, что sqlite проиграл не только NCQStorage, но и SimpleStorage.

Запись в sqlite асинхронная, с таймслотами по 1 секунде, т.е батчами. Сильно его не ускорить.

Теперь у нас есть ответ на вопрос — можно ли из говна и палок на хаскелле сделать приемлемое хранилище и что получится. Ну вот примерно что.

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

Товарищ в соседнем чате делает статически слинкованный дистрибутив stal/ix и призывает им пользоваться. Но какую пользовательскую проблему решает статическая линковка? Эстетика — да, допустим. Но для десктопа оно еще не готово, нужен проприетарный софт, который тащит всякое динамически слинкованное. А для серверных контейнеров у меня colmena + nix которые в общем дают способ описать сервер. и я бы хотел язык получше, чем nix. но важна ли мне статическая линковка? честно говоря эстетика серверных контейнеров меня как-то крайне мало волнует, а so-хелла в никсе нет, ценой токсичности пакетного менеджера. Но опять же, на неё для серверных контейнеров мне всё равно...

Зачем в туннелях типа hysteria2 подключение сертификатов от "авторити" типа lets encrypt? Что бы они ... что? А то — что? Какой-то абсурд.

shadowsocks-то всё. причем хитро — curl всякий через него работает, а браузеры — обламываются. причем почему-то не с любых ip. с некоторых еще работает.

Думаю над миграцией со старого сторейджа (simple) на новый (ncq). ncq - от n-way cuckoo hash, это lsm сегменты + ncq индексы + один "текущий" индекс, т.к. часто hbs2-peer ничего не пишет или пишет очень мало, мне не захотелось плодить много мелких сегментов. короче что-то среднее между bitcask (не знаю что это, нейросети рассказали) и обычными LSM БД.

Варианты — миграция при старте (пир не запустится, пока не смигрирует), прозрачный сторейдж (постепенно в фоновом режиме мигрирует сам), полностью ручная миграция + ручное переключение сторейджа.

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

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

В общем, пока думаю. Работает всё вроде ок. Единственное что, текущий алгоритм мержа тяготеет к сливанию всего в один большой fossil- файл, который чем дальше тем дольше будет мержиться. Если он подойдет к терабайту — станет совсем грустно.

Надо будет как-то придумать, что бы fossil сегменты не росли больше некоего верхнего предела, но тогда мерж (удаление удалённых и томбов и старых версий) — перестаёт быть простым. Пожалуй, это следует решить ASAP. Правда не знаю как пока что.

Новости сторейджа — сделал linear scan compaсtion (не знаю это существующий термин или нет). Суть такова, что идем от более новых записей к более старым, если томб или ref - то запоминаем и последний и на дальнейшем пути выпиливаем всё с таким же ключом, но более старым таймстемпом. Из минусов — не делаем дедуп как таковой, но при нормальной работе никаких дупов быть и не должно, dup = какая-то ошибка. Может работать инкрементально — т.е задавать глубину скана и количество томбов, дальше которого не ходить.

Работает, естественно, инкрементально, онлайн, без остановки сторейджа. По поводу масштабируемости решил, что будем задавать параметр N - число сегментов, это и будет константа при хэштаблице, Соответственно мы будем фиксировать число сегментов, а размер сегментов не будем. Ну будут большие и будут большие, что поделать. Пока соотношение индексов к данным — типа 900 килобайт на гигабайт, но там без фанатизма — скорость размещения ценится выше, чем населенность.

При миграции большого хранилища NCQ нажрался памяти и издох несколько раз. Сколько-то блоков потерялись по дороге из-за этого, но когда пир поднялся - засинкались из сети. Ну, проблему нашёл, вставлю контроль очереди и блокировки при переполнении. Так то почти норм

У Mac OS X всё не как у людей, конечно же. Впрочем, с минимальными патчами новый сторейдж завёлся.

А вот миграция не дорабатывает и как вы думаете почему? А потому, что case insensitive filesystem.

Я еще задавался вопросом — почему же оно работает. А работало оно потому, что крайне редко или никогда получаются хэши, отличающиеся только регистром.

А вот при миграции блоков оно и выстрелило, часть не смогло смигрировать.

Хорошая новость в том, что новому сторейджу регистр названия файлов не важен. Т.е по факту на Mac OS X можно работать только с NCQ, нет пути назад.

Интересно, почему работал git? А потому, очевидно, что что там base16 кодировка хэшей.

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

Ведь в принципе, кому в голову могло прийти делать case insensitive файловую систему и самое главное — зачем?

Только MS и Apple, только кажется, что у MS это давно в прошлом.

Что происходит с системой, если заменить сторейдж на более быстрый (по всем тестам)? Правильно, производительность падает. Пока непонятно, дело в сторейдже или недавних изменениях в TCP, остановивших жор памяти. Так что никакой микропенсии, опять обложиться тестами. Знал бы кто, какой же геморрой профилировать p2p систему. Разработка тестового сетапа для неё это сам по себе процесс сопоставимый с разработкой системы. Короче, 0.25.2 пока не рекомендую, недельку полечу нервы и навалюсь на профилирование. Заработает, куда денется.

Tуннель через ssh не работает больше. При том, что сам ssh работает. Как будто бы форсят переключение на hysteria. Hysteria работает хорошо. Пока не очень понимаю, как это возможно, но факт, уже несколько дней продолжается.

На всякий случай вновь прибывшим сообщаю, что многие недостатки гита, озвученные в треде откуда вы прибыли — решены в hbs2-git. И версионируемость ссылок, и их крипто-пруфы, и хранение прочих объектов (issues), и p2p репликация, и наличие репозитория как сущности с криптоподтверждением владения.

По поводу gitless подхода. Допустим, мы сделаем дамп каталога, где наапротив каждого имени файла будет его хэш, запишем так же ссылку на предыдущий такой файл, сам по себе файл тоже где-то сохраним и будем ссылаться на него по хэшу, а если он большой — то относительно него можем писать только файлы, в которых есть некие изменения - добавлено/удалено. Можно ли поверх такого построить систему управления исходниками и какого размера проекты она потянет? Нужны ли нам коммиты или просто аннотацию писать в тот же файл ( напомню, что коммит в гите — это текст + ссылка на парента (или двух, если это мерж + ссылка на tree - которое — просто дерево проекта ). Структура данных максимально простая — текстовый манифест. Насколько хорошо это будет работать ? А хрен его знает. Но проще не придумать, кажется.

По итогам ненужной дискуссии (надо как-то научиться избегать) решил померять скорость импорта гита vs fossil (который бд объектов держит в sqlite). Мне это интересно потому, что я как раз отказываюсь везде от sqlite в пользу lsm-подобных дисковых структур. На linux стало понятно, что fossil не закончит примерно никогда, посмотрим на openwrt - пожатый git 740mb.

Думаю, он там еще и не пакует, посмотрим на размер БД потом. Ну, гит справился за 1m12

time git --git-dir ../openwrt/.git fast-export --all   --reencode=no --signed-tags=strip | git fast-import
real  1m12.285s

fossil:

time git --git-dir ../openwrt/.git fast-export --all   --reencode=no --signed-tags=strip  | fossil import --git  ./trunk
34 минуты

Неожиданное: в fossil есть дельта и итоговый размер репо в два раза меньше гита.

А ведь хорошо учёным, наверное: если вовлёкся в дискуссию с чувачком, который в теме знает только то, что только что загуглил — то в какой-то момент просто просишь выложить индекс Хирша на стол и линейкой меряете. Самое интересное, что технически у меня возможно и есть этот самый индекс Хирша - стою соавтром нескольких бумаг, и там в сетях мне долгое время шли уведомления, что их кто-то где-то цитирует. Правда, чувствую, короткий индекс Хирша. Но может быть, больше нуля всё равно. Оставаться в академии, что бы иметь козырь для срачей в телеге — хм, заманчиво!