Так же хочу заметить, что модный-молодежный просмотрщик изображений loupe на gtk4 стартует около двух секунд на компе c быстрым nvme и где вообще много всего (CPU, RAM). Двух секунд! Так держать! Сделаем из любого компа 286-ой. Хотя, кажется, там вьювер картинки стартовал быстрее. По крайней мере не помню у себя никакого дискомфорта на эту тему.
Итак, чего не хватает (сейчас, в числе прочего) hbs2 - это публикации страничек проектов из некоего дефолтного шаблона, который пользователи смогли бы патчить для себя. Ну, hbs2.net так собирается — практически исключительно при помощи hbs2-cli, которая предоставляет просто биндинги на функции работы с hbs2 + немного общих функций (строки, файлы, шаблонизация). Думаю, что этот шаблон будет генерировать просто hbs2-git если его попросить. Думаю там просто README + лог коммитов + снапшот исходников (daily? weekly?). Всякое типа лога fixme — прикрутить можно позже. Круто было бы интегрировать haddock, но на это меня точно не хватит сейчас, но если вдруг найдутся добровольцы, было бы здорово.
Как это будет: hbs2-git генерирует рыбу проекта куда-то в .hbs2-git3/website или типа того. или прямо сюда. или спросит куда. там - bf6 скрипт, который соберёт базовую страницу и сделает функции для публикации. как сейчас это выглядит:
hbs2-cli import ./root.ss and publish
после чего hbs2.net доступен по ссылке localhost:port/ref/4X65y4YvUjRL2gtA9Ec3YDDP4bnxjTGhfjpoah96t3z1
что бы это захостить в "clearnet" — нужно поднять hbs2-peer на хосте и настроить реверс прокси на этот URL.
Почему сейчас? Ну вот свои библиотеки таскаю туда-сюда, и единственный источник данных о них — каталоги на хостах. fuzzy-parse вот понадобился.
Как это будет: hbs2-git генерирует рыбу проекта куда-то в .hbs2-git3/website или типа того. или прямо сюда. или спросит куда. там - bf6 скрипт, который соберёт базовую страницу и сделает функции для публикации. как сейчас это выглядит:
hbs2-cli import ./root.ss and publish
после чего hbs2.net доступен по ссылке localhost:port/ref/4X65y4YvUjRL2gtA9Ec3YDDP4bnxjTGhfjpoah96t3z1
что бы это захостить в "clearnet" — нужно поднять hbs2-peer на хосте и настроить реверс прокси на этот URL.
Почему сейчас? Ну вот свои библиотеки таскаю туда-сюда, и единственный источник данных о них — каталоги на хостах. fuzzy-parse вот понадобился.
Решил донастроить suspend на новой рабочей станции. Вопреки ожиданиям — и драйвера nvidia и ядро работают хорошо. Но hyprland крашится после выхода из suspend. Крашится он тоже не просто так, а ему почему-то кажется, что hyprlock (локер экрана) - упал. Сука упал и упал — ну подними. Но нет. В общем, путём тыка выяснилось, что скорее всего имеет место банальная гонка — там какая-то сложная конструкция из dbus и всего прочего, скорее всего hyprand успевает подумать что "о — нужен hyprlock", потом комп засыпает раньше, чем последний успевает стартовать, потом при просыпании — хоба, нету hyprlock. Это, кстати, не первая гонка в hyprland — при смене обоев тоже всякий бред происходит. Думаю там банально в коде что-то в духе sleep(0.25) расставлено. Что бы писать на C++ надо быть очень умным, это вам не хаскель. Однако то, что люди пишут на C++ вовсе не означает автоматически, что они очень умные.
Haskell-ный petrovich здесь:
в прошлый раз дал ссылку на зашифрованный репо, не склонится. Эта открытая.
Использование примерно так:
гендер детектит... как-то само или можно явно указать. Попробую добавить скелет странички проекта, вопрос что там должно быть (последние N коммитов? ссылка на архив?).
Думаю для минимально скелета сойдет README.md + ссылка на репо.
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
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 секунде, т.е батчами. Сильно его не ускорить.
новый (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. Правда не знаю как пока что.
Варианты — миграция при старте (пир не запустится, пока не смигрирует), прозрачный сторейдж (постепенно в фоновом режиме мигрирует сам), полностью ручная миграция + ручное переключение сторейджа.
Последний вариант кажется самым бесполезным — никто не будет заниматься.
Но только в этом варианте явно появляется скрипт, который сможет откатить всё обратно и понятно кто и когда будет его запускать.
В общем, пока думаю. Работает всё вроде ок. Единственное что, текущий алгоритм мержа тяготеет к сливанию всего в один большой fossil- файл, который чем дальше тем дольше будет мержиться. Если он подойдет к терабайту — станет совсем грустно.
Надо будет как-то придумать, что бы fossil сегменты не росли больше некоего верхнего предела, но тогда мерж (удаление удалённых и томбов и старых версий) — перестаёт быть простым. Пожалуй, это следует решить ASAP. Правда не знаю как пока что.
Новости сторейджа — сделал linear scan compaсtion (не знаю это существующий термин или нет). Суть такова, что идем от более новых записей к более старым, если томб или ref - то запоминаем и последний и на дальнейшем пути выпиливаем всё с таким же ключом, но более старым таймстемпом. Из минусов — не делаем дедуп как таковой, но при нормальной работе никаких дупов быть и не должно, dup = какая-то ошибка. Может работать инкрементально — т.е задавать глубину скана и количество томбов, дальше которого не ходить.
Работает, естественно, инкрементально, онлайн, без остановки сторейджа. По поводу масштабируемости решил, что будем задавать параметр N - число сегментов, это и будет константа при хэштаблице, Соответственно мы будем фиксировать число сегментов, а размер сегментов не будем. Ну будут большие и будут большие, что поделать. Пока соотношение индексов к данным — типа 900 килобайт на гигабайт, но там без фанатизма — скорость размещения ценится выше, чем населенность.
Работает, естественно, инкрементально, онлайн, без остановки сторейджа. По поводу масштабируемости решил, что будем задавать параметр N - число сегментов, это и будет константа при хэштаблице, Соответственно мы будем фиксировать число сегментов, а размер сегментов не будем. Ну будут большие и будут большие, что поделать. Пока соотношение индексов к данным — типа 900 килобайт на гигабайт, но там без фанатизма — скорость размещения ценится выше, чем населенность.
При миграции большого хранилища NCQ нажрался памяти и издох несколько раз. Сколько-то блоков потерялись по дороге из-за этого, но когда пир поднялся - засинкались из сети. Ну, проблему нашёл, вставлю контроль очереди и блокировки при переполнении. Так то почти норм
У Mac OS X всё не как у людей, конечно же. Впрочем, с минимальными патчами новый сторейдж завёлся.
А вот миграция не дорабатывает и как вы думаете почему? А потому, что case insensitive filesystem.
Я еще задавался вопросом — почему же оно работает. А работало оно потому, что крайне редко или никогда получаются хэши, отличающиеся только регистром.
А вот при миграции блоков оно и выстрелило, часть не смогло смигрировать.
Хорошая новость в том, что новому сторейджу регистр названия файлов не важен. Т.е по факту на Mac OS X можно работать только с NCQ, нет пути назад.
Интересно, почему работал git? А потому, очевидно, что что там base16 кодировка хэшей.
Вот что бывает, когда привыкаешь к нормальной системе и не задумываешься, что где-то может быть иначе.
Ведь в принципе, кому в голову могло прийти делать case insensitive файловую систему и самое главное — зачем?
Только MS и Apple, только кажется, что у MS это давно в прошлом.
А вот миграция не дорабатывает и как вы думаете почему? А потому, что case insensitive filesystem.
Я еще задавался вопросом — почему же оно работает. А работало оно потому, что крайне редко или никогда получаются хэши, отличающиеся только регистром.
А вот при миграции блоков оно и выстрелило, часть не смогло смигрировать.
Хорошая новость в том, что новому сторейджу регистр названия файлов не важен. Т.е по факту на Mac OS X можно работать только с NCQ, нет пути назад.
Интересно, почему работал git? А потому, очевидно, что что там base16 кодировка хэшей.
Вот что бывает, когда привыкаешь к нормальной системе и не задумываешься, что где-то может быть иначе.
Ведь в принципе, кому в голову могло прийти делать case insensitive файловую систему и самое главное — зачем?
Только MS и Apple, только кажется, что у MS это давно в прошлом.
Что происходит с системой, если заменить сторейдж на более быстрый (по всем тестам)? Правильно, производительность падает. Пока непонятно, дело в сторейдже или недавних изменениях в TCP, остановивших жор памяти. Так что никакой микропенсии, опять обложиться тестами. Знал бы кто, какой же геморрой профилировать p2p систему. Разработка тестового сетапа для неё это сам по себе процесс сопоставимый с разработкой системы. Короче, 0.25.2 пока не рекомендую, недельку полечу нервы и навалюсь на профилирование. Заработает, куда денется.
Tуннель через ssh не работает больше. При том, что сам ssh работает. Как будто бы форсят переключение на hysteria. Hysteria работает хорошо. Пока не очень понимаю, как это возможно, но факт, уже несколько дней продолжается.