Задача в принципе решена, но уже понятно, что хорошего решения тут нет. Штош, остаётся сделать приемлемое. Будет хотя бы быстро работать. Написать PDF проще, чем написать код, вернее, не так жалко его выкинуть или переписать потом. А глупость, изложенная на бумаге почти сразу же видна, в отличие глупости в голове, которую бросаешься реализовывать. Прямо понравилось мне сначала написать документ. Буду практиковать.

Бесплатная раздача идей: нейросеть/нейросети, которые будут вместо тебя участвовать в совещаниях по зуму. Потом еще устраиваешься с этими нейросетями сразу в несколько мест менеджером и профит. Задавать вопросы "какой статус? за сколько сделаете? почему так долго?" чат гпт может уже сегодня, осталось анимировать картинку и голос синтезировать. Вроде бы всё по отдельности уже есть. Еще приделать ручки, что бы тикетами манипулировать, причем там можно даже без особого интеллекта, чисто рандомно. Ну хорошо, с интеллектом будет менее палевно. Не шучу, кстати. Всегда говорил, что значительня часть менеджмента может быть заменена скриптами, но никогда не думал, что нейросети и скрипты сделают ненужными.
Продукт практически идеальный: за то, что будет приносить деньги, люди будут платить. Конечно, кончится всё тем, что это сделают B2B сервисом и всех менеджеров нахрен поувольняют. Аналогичный продукт, который будет лепить отмазки тоже будет востребован. Chat GPT — король отмазок

#offgrid #hbs2 работы ведутся, просто очередное выгорание. обычный режим - полгода работы овертайм, полгода в режиме овоща. удачно, когда овощной режим совпадает с летом. тестим tcp pex тем временем, вроде бы работает. надо бы сделать усилие и побороть эту циклотомию, конечно. с другой стороны, очень полезно выгрузить код из кэша в мозгу, потом когда заходишь —- видишь код совсем другими глазами, можно найти и убрать косяки. пока что думаю над вопросом, нельзя ли сделать обратную совместимость с текущим устройством репозитория, что бы не ломать ссылки. и кажется, что можно, но ценой дублирования данных. вечный трейдоф скорость/память

#hbs2 #offgrid

 ... -> Protocol Encryption -> Fast Large Git Repos -> Git Repo Encryption -> MVP

(1) в работе, (2) в работе

git абсолютно бесконечен. если хорошо поискать, то найдется команда, которая заменит всю твою сложносоставную конструкцию. Например, получить транзитивное замыкание (все объекты) бранча в хронологическом порядке:

git rev-list --objects --no-object-names <rev>

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

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

В своё время язык SQL делался, что бы простые люди могли общаться напрямую с машиной, в обход программистов. Простым людям не зашло. А вот чату гпт заходит отлично.

#hbs2 работа ведётся. новый подход к формату репозитория точно всё ускорил. статус нового репо: в принципе работает, но отладка. темп медленный из-за внезапного наступления лета, слишком много соблазнов + настал момент, когда за моё хобби мне теперь еще и платить готовы, очень необычные ощущения, к тому же там нет ощущения задолбанности. но неважно, всё равно доделаю. пока что статус такой же, какой и был
#hbs2 #offgrid

 ... -> Protocol Encryption -> Fast Large Git Repos -> Git Repo Encryption -> MVP

(1) в работе, (2) в работе

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

Хочу предложить новую дисциплину для специальных олимпиад: кто сделал самую большую задачу при помощи чат гпт. В ней подразделы: самая большая задача с одной формулировки. самая большая задача с ограниченным количеством понуканий (уточнений, включая указания на ошибки). Для меня это пока что: скрипт конверсии дампа БД из pg в sqlite.

Несмотря на то, что основной проект несколько потерял темп по разным обстоятельствам, промежуточные результаты таки есть. Во первых, это всё таки юзабельный работающий прототип распределенного git, который используется внутри команды и действительно работает. Во вторых, это, наконец, распределенный трекер fixme, который живёт внутри репозитория и использует здравые предположения — т.е использует git правильным образом, не абьюзя его. Так же исследованы свойства CAS и более менее понятно, как строить приложения на основе иммутабельных массивов данных. Не в последнюю очередь это и suckless-conf, который, наконец-то, является sexp-ами при этом может имитировать простой плоский конфиг, когда не нужна сильная вложенность. Параллельно он может парсить тексты/протоколы/данные, похожие на секспы. Ну и сам hbs2 является неким фреймворком для построения распределенных приложений, который требует, на мой взгляд, минимум от пользователей и содержит минимум инфраструктуры. В нём есть средства для построения FSM протоколов и описания их свойств, есть PEX (пока не стопроцентно проработанный), есть автоматический поиск пиров в L2 сегментах, есть dns бутстрап, есть ручки для криптографии. Есть куки, сессионные данные с автоматической подчисткой, есть pub/sub для коммуникации разных частей приложения на основе эвентов. Есть заделы для протыкания NAT, т.е оно их в целом протыкает кроме тяжелых случаев (когда нужен релей), при этом даже без использования STUN. Мессаджинг обёрнут в тайпклассы, т.е можно хоть UDP в TCP заворачивать, хоть всё гнать через HTTPS / вебсокеты или вообще любую проксю, типа shadowsocks. TCP есть, значит, через SOCKS работать будет, хоть через tor proxy гоняйте. Мессаджинги могут вкладываться, т.е можно сделать мультиплексирование/демультиплексирование и разные надстройки, например прозрачное шифрование.

Т.е на этом всём можно брать и запиливать, при этом фокусируясь на логике, и всё это без адового когнитивного оверхеда - посмотрите на cloud haskell / дистрибьютед всякое там. Сериализация настраивается через тайпклассы - хотите, текстовые протоколы пилите, хотите CBOR (надо хотеть CBOR). Да, много есть сырого, но постепенно всё лишнее отсечём. Гонять сериализованный код по сети и исполнять, ловя адовые проблемы — очень хрупко и нафиг не надо. EDSL вокруг FSM для протоколов - норм тема. PEX, SOCKS и нат и правильное построение каналов для работы дают возможность в серверлесс / распределенном окружении. Да, пока непонятно, как вообще снюхивать пиры без точек рандеву, но я не уверен, что это в принципе-то возможно. Всё вместе это ложится на некое глобальное вИдение распределенных приложений, в т.ч. нагруженность: асинхронность, fsm, pull/poll, транзакционность, отсутствие сессий с токенами, вместо этого криптографическая авторизация каждой операции + представление любых данных merkle деревьями и p2p их распространение. Короче, пока что есть много кубиков, следующий этап - брать кубики и рисовать между ними стрелочки. Так победим. Пример распределенного приложения, через реальный TCP (но без пекса) https://gist.github.com/voidlizard/2deb91c346ce69b74818a42f58ced593

Зачем это всё вообще. Ну потому, что традиционные протоколы слабоваты в ситуации, когда с одной стороны чебурнет, с другой стороны меты и алфабеты. С одной стороны недостаточны, с другой стороны избыточны. Зачем миллион протоколов для обмена сообщениями? Чем сообщение в телеге отличается от имейла? Чем короткое сообщение отличается от длинного? Ну и прочие вопросы. А ведь нам просто надо обменяться данными no matter what, и узнать, что эти данные есть no matter what, узнать у кого забрать, ну и узнать, что это действительно его данные, и всё так, что бы товарищ майор, чебурашка, корпорации зла и бандиты максимально не знали, что внутри. Ну то есть набор кейсов он ограничен, понятен, и понятно, что можно проще, чем есть сейчас. Зачем нам платить за чужие мощности, когда у нас полно своих? Зачем нам, как команде, платить за чужой сторейдж, когда у нас своего минимум столько, сколько в команде участников? Зачем нам DNS, когда есть криптографические идентификаторы?

UPD. "Protocol Encryption" подъехало. Ну вот, а вы говорите, что ничего не делается. Делается всё, прост не так быстро, как хотелось бы.

Если у вас в хаскелле большой мутабельный стейт. По которому вы делаете различные выборки, соединяете одно с другим, ищете и т.п.
То может быть, лучше сразу положите его в sqlite/memory . Всё, кроме рекурсивных алгоритмов по такому стейту - выглядит, как пародия на SQL. Может, лучше по умолчанию пихать стейт в sqlite, а уж какие-то аспекты оттуда выносить, если надо?

плохие новости: я сломал ссылку 2YNGdnDBnciF1Kgmx1EZTjKUp1h5pvYAjrHoApbArpeX

можете её удалять.


хорошие новости: push/fetch/clone работает для нового формата репо
он намного проще и быстрее, и подъедет в мастер soon. поддержка старого формата будет прекращена (не стоит того, что бы морочиться с совместимостью).
время скачивания нового крупного репозитория уменьшилось с десятков минут до секунд.

Спасибо цирку с педальными конями, произошедшему вчера, у меня вчера (и видимо, сегодня) — рабочий день вместо прыжков. Штош. Продолжаю тестить новый формат репо для hbs2-git. Оно работает, разлетается по нодам быстро. В целях рефлексии и выработки привычки, а так же закрепления навыков рисования диаграмм в tikz — напишу сейчас документ, как оно устроено. Удивительным образом документы помогают выявлять всякого рода особенности. Послушав комментатора из предыдущего поста, решил в качестве стресс-теста импортировать репозиторий nixpkgs в hbs2-git, что бы посмотреть, что произойдет. Происходит следующее:

1) клонирование самим git происходит очень долго

2) репозиторий после клонирования весит ~ 3.5G - напоминаю, что объект в гите пакуются.

3) при экспорте в hbs2-git происходит запись лога. В логе каждая секция (соответствующая гитовому объекту или
же операции) имеет префикс, там, в числе прочего, указывается хэш. Размер этого префикса - фиксированный, и вроде бы, ерунда —- но внезапно,
на БОЛЬШОМ количестве объектов эта ерунда начинает что-то стоить

4) каждая запись упакована gzip с опциями паковать как можно быстрее

5) пишет оно объекты в этот лог помедленнее, чем, скажем, это делает команда

git fast-export --all | bzip2 > dump

однако же, не в разы медленнее. заметим, что hbs2-git каждый объект читает пока что при помощи git cat-file

6) сама операция получения списка объектов

git rev-list --objects --date-order --reverse ...

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

7) на размере лога в районе 7 гигабайт (вместо 4) я что-то взгрустнул и прервал. мне не очень хочется видеть в стейте у себя такое, особенно,
пока не сделана сборка мусора. Ну и упаковка заведомо неоптимальная, так как пакуем маленькими секциями, вместо того, что бы запаковать
всё —- понятно, что размер будет больше, чем 3-4G, плюс заметен оверхед на заголовки.

8) hbs2-git работал примерно с O(1) памяти, т.е отожрал довольно большой сет, но он не рос от числа объектов. попыток взорваться не было.
то ли я успешно объезжаю грабли, то ли хаскель стал прямо таки продакшн-реди, раньше типичное поведение было, когда вместо маленьких
данных подсунешь большие —- сразу же взрыв. 10 гигабайтные файлы я успешно в hbs2 пропихивал, ничего не присходило. т.е кажется, что
hbs2-git способен работать на больших репо, но грустно, что такой долгий первоначальный экспорт. ну и эффектное заявление сделать не
получилось. пока надо подумать, что делать с этим.

В дополнение к предыдущему посту. Пытливый читатель сразу же спросит: а почему бы не использовать просто fast-export для каждой операции push и не морочить голову себе и окружающим? Отвечаем. 1) В какой-то момент может потребоваться индексированный репо (например, что бы объекты по http отдавать) 2) поскольку в hbs2-git стейт представлен, как объединение логов, каждый из которых соответствует одной команде push (т.е разница с предыдущим состоянием ветки) - мне, что бы вычислить последовательность этих логов, нужно знать, какие там есть коммиты. высота лога = высота его максимального коммита, таким образом, логи и приезжающие в них операции естественным образом упорядочиваются, что очень полезно при упорядочивании операций 3) наличие исходного хэша вместе с самим объектом позволяет нам обнаруживать ошибки, если что. так-то мы битый объект засунем в гит, проблемы не заметим, а репо поломается, и в какой момент мы это обнаружим — вопрос

Попробовал сделать

git fast-export --all | bzip2 > dump

для репо nixpkgs. Поначалу работало бодро, но чем дальше за три гигабайта, тем больше начинало грустнеть, а с какого-то момента (10Gb) я и вовсе дропнул этот процесс. fast-export точно не панацея, и всех проблем больших репо не решит. отложу.

Написал мурзилку про hbs2-git. Буду рад комментариям и вопросам, обновлю документ тогда

Прислали статью, как владельцев IPFS шлюзов атакуют через их провайдеров, жалуясь на размещение некоего "контента", якобы защищенного правом. Короче, пишут анонимки, а хостеры сносят, не разбираясь, само собой. Доносы, причем, в части случаев ложные, не будем говорить, что сам "закон" сомнительный.

Собственно, это же и hbs2 ждёт, т.к. я вот публикую документики в чате пока по той причине, что не дошли еще руки сделать те самые "шлюзы", что бы по ссылке были доступны данные тем людям, которые пока не хотят ничего ставить себе. Плюс в PDF я правлю опечатки, значит, надо не просто документ по ссылке на контент отдавать, а отдавать ссылку на мутабельный документ, т.е рефлог, где из транзакций будет выводиться последняя версия. Ну, собственно, тот же самый кейс что и в исходной ссылке.

Как бороться с беспределом пока непонятно — понятно, что даже если DNS будет резолвиться во множество IP - множество всё равно 1) очень ограниченное 2) будут атаковать через регистратора доменного имени. Т.е лучший вариант, что бы имя было гарантированно в мире не существующее и резолвящееся на локалхост или на ближайшую ноду. Что бы сделать последнее, нужен какой-то специфический DNS резолвер, который, опять же, человек должен будет поставить. Короче, пока непонятно, как с этим быть.

С другой стороны, может оставить "обычных людей" в покое? Захотят - подсуетятся, не захотят - ну, значит им не надо. У меня был кейс, я "обычных людей" научил забирать парашютное видео через торренты.

Потому что маразм с "закачали в облако - заплатили за облако - скачали из облака" ну реально достал. При том еще, что часть интересантов тусуется в рамках одного L2 сегмента, т.е на одном вайфае! Видео такого много, объемы большие, но при этом оно одноразовое. Когда все, кто хотел скачать - скачали, можно сносить (из облака. на диске-то пусть живёт, пока место есть). Т.е типично с облаком ты очень быстро начнёшь платить за место (видео много!), и должен будешь заниматься менеджментом (все скачали? я сношу!). Т.е неудобно и провоцирует на лишние ненужные расходы, как и гитхаб. Заметим, что создаётся искусственная потребность, за счёт подавления альтернативных технологий (торрент с DHT просто перестали работать в какой-то момент, а ведь работающие торренты были бы идеальным решением данной задачи).

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

Похоже на группу в телеге, но там сделано максимально неэргономично. 1. по умолчанию видео жмётся 2. нет такого, что бы сбросил пачку видосов и пошёл по своим делам, а дальше оно само всем доставится, был бы девайс онлайн.

https://torrentfreak.com/publishers-carpet-bomb-ipfs-gateway-operators-with-dmca-notices-230625/

по поводу того, как сделать стабильные веб-ссылки: видимо, только так: "лёгкая версия" ноды hbs2 компилируется в js/webasm и работает в браузере, отдаётся или с локалхоста или вообще лежит статическим html-ем на диске, а ссылка выглядит, как hbs2.html?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX ну и исходя из того, что dns бутстрап с одной точкой в какой-то момент подавят, надо поднимать точек входа для него много, сидов для PEX тоже делать много, и запоминать их в локалсторейже! Т.е нода всё-таки должна быть с мутабельным стейтом, т.е хотя бы запоминать пиров, с которыми работала последний раз, и при рестарте начинать бутстрап и с них тоже