купил неттопчик для работы и для будущей ноды офгрида, что бы не шумел. завис на выборе файловой системы. точнее, даже так - хочу сделать типовой конфиг для рабочей машики, что бы потом быстро раскатывать. завис на вопросах: zfs или btrfs ? хочется постепенно настроить инкрементальные бэкапы чего нужно, а что не нужно - не бэкапить. шифрование чего нужно - а что не нужно не шифровать. т.к. будет много компилировать - весь хомяк или весь диск шифровать не хочется. если я правильно понимаю, то на блочном уровне zfs сможет шифровать отдельные под-тома, а btrfs - только работать поверх шифрованного устройства. следовательно, бэкапы btrfs-ных томов будут не зашифрованы. с другой стороны, 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, начинаю его понимать, через три года использования.

#offgrid кажется, у нас подъехала более-менее стабильная версия ноды с шифрованием и можно начинать туда перекладывать исходники. При этом так же кажется, что для того, что бы это начало кого-то впечатлять, надо приделать какой-никакой gui и выложить с публичной нодой в большом интернете (и посмотреть, загнётся или нет). С другой стороны, очевидно, что без специальной обёртки для хайлоада загнётся - вся суть распределенности в том, что бы нагрузка распределялась по группам, а не все бежали в одну ноду.
С другой стороны - без публичной ноды на первом этапе - никто ничего не заметит. Вот, есть sourcehut, куда народ с гитхаба побежал. Так вот там самый-самый базовый ui на коленке - и ничего - они уже за это берут плату это раз, и оно удостоилось отдельного протокола в nix - это два.

#haskell смотрите, что нашел: json-stream, аппликативный парсер для json. в частности, позволяет избавиться от aeson-овых
портянок описания всех структур данных, из которых нам нужны пара полей, допустим. Например:

-- q - огромная вложенная портянка json-овых объектов с кучей полей
-- описывать такое на aeson, все (ненужные) промежуточные типы,
-- инстансы, маппинг полей - просто вскрыться.
-- тут же такое:
q = ...
fixed = realToFrac <$> number
pquo  = "quote" .: "USD" .: "price" .: number
parseByteString (  "data" .: "BTC" .: arrayOf ( (,) <$> "symbol" .: string <*> pquo  )   ) 

[("BTC",16825.237237370766)]

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

#offgrid #offgridgit починили offgrid-git для работы с ... multipart сообщениями. шифрованные топики пока не пробовали.

upstream: offgrid://6d8DHjfiCKAmEGyBG7CD5AkPz8y1kBmL485PKa6Azey7

надеюсь, ломающих изменений больше не будет

Лемма: несмотря на наличие лёгких потоков, в программе должно быть O(1) потоков, иначе вам жопа (_|_) TBD: нужно математическую нотацию для "вам жопа"

Следствие: компиляторы нужно объединить с пруф-оф-ворк блокчейнами, и на каждый forkIO в программе требовать доказательство работы, например, на велотренажёре. Без этого программа не должна компилироваться

Из nix мы знаем, на что похожи dsl на чистом функциональном языке без монад. на говно. а еще мы узнаем, что синтаксис важен. и лучше отсутствие синтаксиса в виде скобок, чем неудачный синтаксис.

два страха - что дисковые операции дырку в ssd сделают, и что хэши по кругу пойдут. не могу я поверить, что можно спокойно генерить 256-битные хэши и их еще много останется

Посоветуйте, что взять для стриминга? мне надо такое - что бы жило на O(1) по памяти точно и было с минимальными зависимостями и не пыталось свою вселенную построить, как кондуиты. взял было list-t - он протёк, на больших файлах крашится. Тупой пример, чего мне надо - который не падает: https://gist.github.com/voidlizard/46d1bac04f67ed0fd92560817b349b9e - хаскель курильщика, но работает за O(1) по памяти

#haskell читал из файла чанки / защитил докторскую

издохло мгновенно. быстрее, чем всё до того. вот так стриминг! #haskell #streaming #специальнаяолимпиада

Вообще я не планировал специальную олимпиаду, я чем-то другим хотел сегодня заниматься. Но по итогам хочу сказать, что рассчёт хэшей файла ~10G на streamly - взрывается. на list-t - взрывается. на unsafeMMapFile - хочет взорваться не но успевает, дорабатывает. на streaming - не взрывается. https://github.com/voidlizard/streaming-wtf/blob/master/MerkleStreaming.hs - работает ~ O(1). ну конечно не O(1) , но пропорционально количеству хэшей * размер хэша, фигня, типа мегабайт на 10 гигабайт. я вообще не этим собирался заниматься. очент досадно за list-t - прикольный и сука бесполезный в итоге

Нездоровая активность в плане кода в выходные объясняется просто — со сломанной рукой не так много развлечений доступно. Если не бухать, то мало что остаётся — например вот в стриминг на хаскелле поиграться

ListT починен, интересно, примут ли патч:

diff --git a/library/ListT.hs b/library/ListT.hs
index 4361a4a..70c3673 100644
--- a/library/ListT.hs
+++ b/library/ListT.hs
@@ -407,7 +407,7 @@ splitAt =
 -- |
 -- Prepend an element.
 cons :: Monad m => a -> ListT m a -> ListT m a
-cons h t =
+cons !h t =
   ListT $ return (Just (h, t))

Схоластика: когда средневековые учоные обсуждают и пытатся рационализировать потребление памяти хаскельной программой

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

Странное вот дело - казалось бы, нет ничего проще UDP. Но даже из протокола на две команды - получается конструкция на тысячи строк кода, это вспоминаю DNS прокси роутерную. Удивительное дело вообще. После дней пяти мучений с модельным сервером — решил посмотреть, что там как у людей, может хорошо уже сделали. Увиденое заставило всплакнуть - видно, что те же самые проблемы были, и судя по прибитым местами IO и ByteStrings - просто сдались в какой-то момент. А всего-то хочется написать обобщенный воркер с поддержкой сессий, а что бы конкретные типы пакетов и сессий определялись его клиентами. Типа, на случай, если протокол состоит из какого-то небольшого числа подпрототоколов со своими workflow. Если всё это загнать в один тип пакетов, например — то очень быстро становится невозможно отлаживать, т.к. каждый конкретный FSM обрастает каким-то дополнительными типами и таймаутами. Кстати, частое явление в этом нашем х-ле — то ли тупо запихнуть всё в один тип, то ли устроить содомию с тайпклассами и обёртками на экзистенциальных типах. Как говорится, есть два стула.

Твоё лицо, когда не любишь сервант, но пишешь какое-то его подобие для UDP

Пока так:
https://gist.github.com/voidlizard/2e27a831bcc295f3c5320802aef42c9b