#offgrid ну что, оно живое. проблемы возникают, но чинятся в рамках его самого. и работает на довольно убогих каналах, черти где. в принципе, уже оправдывает название. git с ним работает. пилим подписки и acl-ы
#offgrid пилим систему прав/подписок/криптоподписок. в offgrid-git + еще отдельная система прав
кстати, понял, что не знаю, как коротко охарактеризовать offgrid. Постблокчейновый торрент с паб/сабом? Распределенный CAS с подписками? новый фидонет?
С этой вот сложностью такая двоякая ситуация. Есть вот сервант (servant). Довольно сложный для первого раза или как отвыкнешь. Думаешь такой - возьму-ка я scotty что бы микровебню написать. Но тут есть реальный риск, что через какое-то время будешь плюясь перетаскивать все обратно на сервант. Тоже самое как документами/презентациями - латех подзабыл, дай-ка быстро нашлёпаю в Google Draw. Через несколько часов обнаруживаешь себя гуглящим настройки beamer и вспоминающим tikz. ПОТОМУ ЧТО В Draw не добавить в нужном месте коннектор к фигуре и стрелку к ней под неотвратительным углом не подвести или еще что.
#offgrid работы по ACL пока задерживаются из-за работ по стабилизации. тем временем подпилил еще немного offgrid-git, ускорил вычисление зависимостей и сделал локальные ACL (пока что не публикуются в топик, думаю, как сделать лучше)
Оказалось, что offgrid-git вполне нормально работает с git-bug, bug tracker, который свою базу держит в формате репозиториев гита.
Сам git-bug устроен довольно спорно - по сути, на каждый bug он делает git reference, то есть файл, то есть мутабельный ключ.
Так-то может и норм, но если у вас миллион багов, то в каталоге .git/refs/bugs/ будет миллион файлов.
Плюсом git bug является то, что он жив - последние коммиты 4 дня назад.
Еще минус - там всё время надо отдельно делать git bug pull.
Если бы баги могли жить просто в топиках офгрида, то они бы и подъезжали бы сами.
Теперь вот непростая ситуация - простой багтрекер был в планах, git bug работает не совсем так, как хотелось бы. Но зато уже есть и работает.
Не, ну так-то надо брать, хотя бы для себя. Это же лучше, чем ничего, а мы баги сейчас в канале в телеграме трекаем.
Сам git-bug устроен довольно спорно - по сути, на каждый bug он делает git reference, то есть файл, то есть мутабельный ключ.
Так-то может и норм, но если у вас миллион багов, то в каталоге .git/refs/bugs/ будет миллион файлов.
Плюсом git bug является то, что он жив - последние коммиты 4 дня назад.
Еще минус - там всё время надо отдельно делать git bug pull.
Если бы баги могли жить просто в топиках офгрида, то они бы и подъезжали бы сами.
Теперь вот непростая ситуация - простой багтрекер был в планах, git bug работает не совсем так, как хотелось бы. Но зато уже есть и работает.
Не, ну так-то надо брать, хотя бы для себя. Это же лучше, чем ничего, а мы баги сейчас в канале в телеграме трекаем.
Как они (git-bug) могли бы сделать лучше.
Один ref = один "канал", туда постятся "коммиты", "коммиты" представляют собой просто команды, изменяющие state: создать баг, выставить поле X бага в значение Y. Тогда история бранча = лог изменений.
Сам стейт может быть, кстати, "деревом" багов, один баг = один файл, раз уж гит поддерживает деревья.
История сканится, текущий стейт держится в sqlite, если его грохнуть - то всегда можно пересоздать из лога, ничего страшного, по сути это просто кэш.
С точки зрения UX пользователя ничего бы не поменялось: "не засоряет репозиторий" в еще большей степени, чем текущий дизайн.
Как мы помним, ранние альтернативные подходы к багтрекерам внутри гит заключались в том, что там прямо создавались файлы, которые жили на отдельном бранче и раздражали.
Здесь же (в git-bug) вся мета хранится в формате базы git и пользователю не докучает, ну кроме того, что плодятся ref-ы.
Можно было лучше, в общем. Но лучше, чем было до того (и умерло, пока все такие системы помирают, хотя тикеты ведь логично держать вместе с кодом)
Один ref = один "канал", туда постятся "коммиты", "коммиты" представляют собой просто команды, изменяющие state: создать баг, выставить поле X бага в значение Y. Тогда история бранча = лог изменений.
Сам стейт может быть, кстати, "деревом" багов, один баг = один файл, раз уж гит поддерживает деревья.
История сканится, текущий стейт держится в sqlite, если его грохнуть - то всегда можно пересоздать из лога, ничего страшного, по сути это просто кэш.
С точки зрения UX пользователя ничего бы не поменялось: "не засоряет репозиторий" в еще большей степени, чем текущий дизайн.
Как мы помним, ранние альтернативные подходы к багтрекерам внутри гит заключались в том, что там прямо создавались файлы, которые жили на отдельном бранче и раздражали.
Здесь же (в git-bug) вся мета хранится в формате базы git и пользователю не докучает, ну кроме того, что плодятся ref-ы.
Можно было лучше, в общем. Но лучше, чем было до того (и умерло, пока все такие системы помирают, хотя тикеты ведь логично держать вместе с кодом)
pull-request (он же патч) может быть сделан как git bundle, при этом всю необходимую информацию можно поместить в него же, в отдельную ссылку git, которую можно добавить в этот bundle. таким образом, pull request становится самодостаточным объектом, который имеет смысл даже отдельно от offgrid, а будучи добавленный в offgrid он получает уникальный хэш, на который можно ссылаться и по которому его можно вытащить. Тогда это будет работать как с офгридом, так и без него. Как по мне это win. #offgrid #offgridgit
#offgrid Допустим, pull request это просто сообщение, в котором указано, где майнтейнеру взять изменения, которые смержить к себе. интересно,
как определять, что PR действительно смержен. Наличие коммита(ов) из PR на мастере(мастере?) ? Нет, ведь мейнтейнер мог сделать merge —squash —no-commit и взять всё одним коммитом. Наличием tree объекта на мастере (мастере?) идентичного тому tree, для которого делался PR? Ближе. Но на предыдущем шаге майнтенер мог добавить каких-то своих файлов, но делают так редко. Ок, допустим, наличие на мастере (мастере?) tree объекта, в который входят все блобы из tree объекта коммита PR. Хотя он майнтейнер в процессе мержа мог файлы не менять, а перетасовать их по каталогам, но обычно так не делают. Ну допустим, с некоторыми натяжками можно. Теперь про мастер. Всё еще смешнее. Название бранча в гите - это просто название файла в .git/refs/heads. Оно может совершенно произвольно меняться и это никак не трекается в самом гите. Но трекается в offgrid-git в силу его природы.
Таким образом, критерием приёмки PR можно считать тот факт, что в топике (репозитории), куда направлялся данный PR, существует commit, которому предшествует commit на который делался PR, и существует бранч, имя которого совпадает с тем, который указан в PR (допустим, master) и который существовал в какой-то момент после создания PR (это значит. что существует reference, name = master и в зависимостях того reference есть коммит, на который делался PR). Если всё это выполняется, можно сказать, что PR смержен. Наверное.
как определять, что PR действительно смержен. Наличие коммита(ов) из PR на мастере(мастере?) ? Нет, ведь мейнтейнер мог сделать merge —squash —no-commit и взять всё одним коммитом. Наличием tree объекта на мастере (мастере?) идентичного тому tree, для которого делался PR? Ближе. Но на предыдущем шаге майнтенер мог добавить каких-то своих файлов, но делают так редко. Ок, допустим, наличие на мастере (мастере?) tree объекта, в который входят все блобы из tree объекта коммита PR. Хотя он майнтейнер в процессе мержа мог файлы не менять, а перетасовать их по каталогам, но обычно так не делают. Ну допустим, с некоторыми натяжками можно. Теперь про мастер. Всё еще смешнее. Название бранча в гите - это просто название файла в .git/refs/heads. Оно может совершенно произвольно меняться и это никак не трекается в самом гите. Но трекается в offgrid-git в силу его природы.
Таким образом, критерием приёмки PR можно считать тот факт, что в топике (репозитории), куда направлялся данный PR, существует commit, которому предшествует commit на который делался PR, и существует бранч, имя которого совпадает с тем, который указан в PR (допустим, master) и который существовал в какой-то момент после создания PR (это значит. что существует reference, name = master и в зависимостях того reference есть коммит, на который делался PR). Если всё это выполняется, можно сказать, что PR смержен. Наверное.
Пришла в голову мысль, что если скрипты создания базы развернуть в поток операций создания колонок ( ALTER TABLE X ADD COLUMN ... ); - то каждую такую операцию легко сделать идемпотентной, а процедуру миграции базы - тривиальной и вообще она типа становится CRDT но это не точно
Что-то я застрял с sql-ным dsl-е. Первоначальная идея была сделать маленький слой над sqlite-simple, что бы не писать руками бесконечные примитивные - запросы - сделать простой DSL для генерации.
DSL сделать на уровне типов, что бы интерпретаторы писать тайпклассами - ну, примерно, как в серванте. До определенной стадии получилось, особенно нравится то, что не нужно, как в persistent описывать "таблицы" - а только те поля, которые используешь завернуть в newtype и задать для них колонку таблицы через тайпкласс.
Для простых запросов работает отлично. Для постгреса этого и хватает - любой сложный запрос это, считай, view - pg отлично работает с view + это даёт еще дополнительных плюшек.
Для sqlite лучше бы уметь делать вложенные запросы - и как-то это надо уже композить на уровне типов. В sql-ных запросах полно опциональных вещей, и как вот их подпихнуть в ту конструкцию, что тут на картинке (в коменте, в пост не влезло)?
Оно мало того, что позволяет разные запросы разбирать разными тайпклассами, так оно еще и типизирует и колонки запроса, и возвращаемое значение. Бойлерплейта для простых запросов получается мало и вообще прослойка над raw sql получается очень тонкая.
Но не понимаю, как хорошо сделать этот DSL расширяемым. Добавить туда всякие там limit, order, group by и так далее.
К моноидальным и монадическим DSL здесь не хочется скатываться, получится очень шумно + некорректно. Но как сделать нормально не пойму.
Очень не хочется тащить в проект persistent, слишком много там всего ненужного делается. beam вообще шляпа какая-то. #haskell #sql #edsl
DSL сделать на уровне типов, что бы интерпретаторы писать тайпклассами - ну, примерно, как в серванте. До определенной стадии получилось, особенно нравится то, что не нужно, как в persistent описывать "таблицы" - а только те поля, которые используешь завернуть в newtype и задать для них колонку таблицы через тайпкласс.
Для простых запросов работает отлично. Для постгреса этого и хватает - любой сложный запрос это, считай, view - pg отлично работает с view + это даёт еще дополнительных плюшек.
Для sqlite лучше бы уметь делать вложенные запросы - и как-то это надо уже композить на уровне типов. В sql-ных запросах полно опциональных вещей, и как вот их подпихнуть в ту конструкцию, что тут на картинке (в коменте, в пост не влезло)?
Оно мало того, что позволяет разные запросы разбирать разными тайпклассами, так оно еще и типизирует и колонки запроса, и возвращаемое значение. Бойлерплейта для простых запросов получается мало и вообще прослойка над raw sql получается очень тонкая.
Но не понимаю, как хорошо сделать этот DSL расширяемым. Добавить туда всякие там limit, order, group by и так далее.
К моноидальным и монадическим DSL здесь не хочется скатываться, получится очень шумно + некорректно. Но как сделать нормально не пойму.
Очень не хочется тащить в проект persistent, слишком много там всего ненужного делается. beam вообще шляпа какая-то. #haskell #sql #edsl
При сдаче проекта неожиданно отлично работает скринкаст, который ходит и демонстрирует все фичи, особенно, если около каждой фичи в списке указать её таймкод в скринкасте.
Во первых - его никто не смотрит! Но он есть и внушает уверенность. Во вторых - по хорошему, его бы генерить автоматически каким-нибудь селениумом.
Тесты такие все равно нужны, а тут только запуск скринкаста приделать. По скрипту на фичу, а потом в один видос слить. Не, но то, что их не смотрят это прям лол. Софт принимать это вам не языком в зуме чесать.
Во первых - его никто не смотрит! Но он есть и внушает уверенность. Во вторых - по хорошему, его бы генерить автоматически каким-нибудь селениумом.
Тесты такие все равно нужны, а тут только запуск скринкаста приделать. По скрипту на фичу, а потом в один видос слить. Не, но то, что их не смотрят это прям лол. Софт принимать это вам не языком в зуме чесать.
Каждый раз, когда начинаешь что-то делать, задаёшься вопросом, а как там будут виндовые пользователи. Реально, как про лиц с ограниченными возможностями ради повышения инклюзивности. Под линуксом-то, понятно, всё будет работать и всё есть. На маке тоже как-нибудь завёдется. А что делать виндовым пользователям? Надо, что бы и у них как-то работало. Давайте добавим ручки в протокол, что бы могли ремотный хост использовать в качестве костыля
Offgrid жив, просто все занимает больше времени, чем хочется. Писать новости сломанной рукой непросто. Ищем финансирование потихоньку
#offgrid На этой неделе начнём тестировать криптоподписку: ограничение на чтение/запись при помощи криптографических механизмов. Обратная совместимость поломана, всё внешнее поломано, но после фиксации изменений можно будет чинить и потом делать, например, приватные репозитории offgrid-git или же чатики, а то до этого момента всё было только открытое. Довольно сложная история оказалась, неудивительно, что мало кто это реализует
купил неттопчик для работы и для будущей ноды офгрида, что бы не шумел. завис на выборе файловой системы. точнее, даже так - хочу сделать типовой конфиг для рабочей машики, что бы потом быстро раскатывать. завис на вопросах: zfs или btrfs ? хочется постепенно настроить инкрементальные бэкапы чего нужно, а что не нужно - не бэкапить. шифрование чего нужно - а что не нужно не шифровать. т.к. будет много компилировать - весь хомяк или весь диск шифровать не хочется. если я правильно понимаю, то на блочном уровне zfs сможет шифровать отдельные под-тома, а btrfs - только работать поверх шифрованного устройства. следовательно, бэкапы btrfs-ных томов будут не зашифрованы. с другой стороны, zfs любит память и по бенчмаркам - от двух до трёх раз тормознее. что же взять?
UPD. еще у меня то, что мне важно живет в syncthing и в git, а что там не живёт - то мне и не нужно. таким образом, инкрементальные бэкапы на уровне томов мне особо-то и не нужны были. система же под nixos и так особо не ломается, а если ломалась - то 1) собственными моими усилиями 2) легко чинилось при помощи текстового редактора. т.е time machie-то мне особо и ни к чему
UPD2. если бы не шифрование, то и вопросов бы никаких не было - взял бы btrfs
UPD3. а если бы не сведения, что zfs тормознее и память любит - взял бы просто zfs
UPD. еще у меня то, что мне важно живет в syncthing и в git, а что там не живёт - то мне и не нужно. таким образом, инкрементальные бэкапы на уровне томов мне особо-то и не нужны были. система же под nixos и так особо не ломается, а если ломалась - то 1) собственными моими усилиями 2) легко чинилось при помощи текстового редактора. т.е time machie-то мне особо и ни к чему
UPD2. если бы не шифрование, то и вопросов бы никаких не было - взял бы btrfs
UPD3. а если бы не сведения, что zfs тормознее и память любит - взял бы просто zfs
запилил повторяемый конфиг системы на nix flakes для нового десктопчика, xmonad + polybar + никсифицированный nvim c плагинами. Говорят, красота спасёт мир, на самом деле, она его сожжёт дотла. Если даже не вспоминать троянскую войну, то что бы добиться красивой панельки, которая в mate дичайше глючила c xmonad - портились иконки - пришлось эту панель из mate выкинуть нафиг и вкрутить polybar. Только на то, что бы заставить телеграм отображать приемлемую иконку для темного трея - ушло часа полтора с strace. Знаю теперь много про то, как работает иксовый десктоп, кто на ком стоял и через что сообщениями обменивается. Лучше бы не знал. Зато прикрутил к xmonad-у haskell-language-server и подружил это всё с home-manager+flakes, теперь хоть жить можно. Сука ладно, а в троянской войне вообще люди погибли и одна из возможных причин катастрофы бронзового века. Так что два дня гребли с конфигами это фигня. Зато по nix level up, начинаю его понимать, через три года использования.