А как чисто технически СРКНы собираются мониторить "экстремисткие запросы" в гугл или duckduckgo ? TLS-то вроде еще работает, а логи гугл им не выдаёт. История браузера? Но кто в здравом уме будет такое делать не в incognito режиме? Он конечно так себе инкогнито, но историю точно не хранит. Опять же, LLM-ы охотно общаются на любые темы экстремисткие темы, это ж не про секс.

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

Desperation Driven Development всегда работает. Единственная проблема, что отчаяние должно быть неподдельным. Т.е заранее (что бы сэкономить время) не получится.

Ну и день. Когда тесты проваливаются, и ты патчишь код, но ничего не помогает, потому что ошибки в тестах. Ладно, эта пилорама — график пропускной способности NCQ2 от числа потоков.

Красным пунктиром — baseline, то есть просто берёт N блоков и пишем в файл через appendFile.

Это с пересчётом хэшей. Учитывая то, что лог реально пишется в один поток в один момент времени — и всё остальное это мои ухищрения с fsynс и батчингом.

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

"Говорящая собака" пошло из интервью, кажись, с Марковым (?), который сравнил LLM с собакой, которая притаскивает хозяину всякие ништяки и ждёт, пока хозяин похвалит. LLM перебирает реплики, пока мясного не устроит результат и он не отвяжется

Хотел сделать бенчмарков относительно rocksdb, но по славной традиции ни один никсовый флейк не собирается, а в никсовом пакете нет db_bench. Я уже и забыл, что основной причиной не использовать rocksdb было то, что какой-то с ним вечно гемор. Софт на плюсах -> скорее всего не соберётся. ни сам, ни то, что с ним линкуется. Закон!

Сделал тест напротив rocksb, пока результаты приблизительные, т.к. в rocksdb черт ногу сломит, но вроде бы я попытался записать 100K значений размером 96K (среднее 64..256), потом для них lookup на холодную. ncq2: median 0.171 0.171 секунд на 100K чтений.

rocksdb: readrandom : 7.041 micros/op 142013 ops/sec 0.704 seconds 100000 operations; 8 - 0.704

тестовая обвязка для rocksdb http://hbs2.net/tree/En5Fy2s3RKJcc924wseYtwQ88M3sBLnz4UmHKx4Zz1Tj

заметим, что в тесте скорости ncq2 считает хэши, чего rocksdb не делает - и скорость в районе 900Mb/s,

ну... хрен знает. но вроде бы перспективно.

UPD: rocksdb - 1.4Gb/s, если ncq2 отключить генерацию рандомных строк и подсчёт хэшей - то 1.9 .. 2.2 Gb/s. Не, ну это норм, получается

JHC ожил. Какой-то чувак его форкнул и что-то туда поддерживает. Это я реддит почитал от прокрастинации. Ничего себе! Вообще нам бы не помешал еще один компилятор хаскелла. Даже у плюсов больше одного компилятора есть. Но так-то смотришь на список расширений языка в проекте и понимаешь, что безнадёжно

Интересно, если какие-то общепринятые/готовые/достаточно хорошие эвристики для сборки мусора в lsm-подобных иммутабельных файлах? Т.е с одной стороны их лучше держать размером поменьше. т.к. любая трансформация -> полное переписывание. С другой стороны их лучше бы держать размером побольше => т.к. меньше файлов -- быстрее лукап, а лукап тут O(n) от количества файлов. С третьей стороны, а что если файлы будут ОГРОМНЫЕ? С четвёртой тут можно эвристики придумывать бесконечно, надо с чем-то достаточно хорошим закрыть этот вопрос и дальше двигаться

Я был внутри двух мощных волн хайпа - SDN и БЧ. Если взять соотношение сигнал/шум оттуда и применить для анализа заявлений в рамках текущего хайпа - можно почти на все наплевать и игнорировать. Т.е делить надо где-то на два-три порядка, а настоящее начнется, когда волна схлынет. Если, конечно, подход применим. Помню, какой-то тётке в Стэнфорде дали (или заявили, что дали) 30 миллионов на БЧ, который решает все проблемы БЧ - когда надо быстрый, когда надо медленный. Где ее стартап? Где-где. Именно там, да.

Короче, сборка мусора. Придется всё переделывать. В новой модели: индекс (n) -> (k) данные т.е файл индекса индексирует множество данных. Связь не по соответствию индекса файлу, как в гите, а в каждой записи индекса - ссылка на ключ файла. Ключ - 32 битное целое, монотонный счётчик. Файлы данных мержатся редко и до определенного размера, индексы — (неограниченно? до какого-то лимита?). Данные не трогаем. Индексы мержим. Время доступа остаётся близким к O(1), мерж индекса - O(m+n), память O(1). Индекс где-то на два порядка меньше данных, 48 байт на запись. при населённости около 0.6 — 16Gb индекс может адресовать ~ 48 терабайт данных
Алгоритм мержа индекса: I, J ∣ T(I) > T(J) ⟹ K = I ∪ (J ∖ I), T(K) = T(I)
I,J - подряд идущие по таймстемпу файлы, K - новый файл. В стейте заменяем I, J на K, потом отложенно "актуализируем" стейт, т.е удаляем всё, что не в нём, если
refcount = 0.

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

Удаление мусора: из индекса удаляются дублирующие (по ключу) данные. Если затираются томбом — ну, значит, остаётся томб.

Для любого томба — его можно удалить отдельным проходом, если больше нигде нет на него ссылок.

Сборка мусора для файлов данных: удаляем блоки, если их нет в индексе или они томбы.

Целостность обеспечивается стейтом. Т.е пишем файлы, добавляем в состояние. Источник правды — файл(ы) стейта, дамп стейта = коммит транзакции. Лишнее (отсутствующее в текущем стейте) удаляем отложенно и когда оно точно не используется.

Из плюсов — файлы индекса маленькие, их быстро мержить. Файлы данных можно мержить, можно нет, на скорости чтения особо сказываться не должно.

Такие дела

Что-то в нашем этом хаскелле не хватает гарантий хвостовой рекурсии. Я бы написал что-то такое tailrec (what ...) и что бы компилятор если не может гарантировать, что хвостовое — шоб ошибку генерил. А то палево прямо. Интересно, можно такое сделать? Это мне как в сишке не хватало гарантий экстента.

По мере надобности подпиливаю bf6 (aka suckless-script), добавил по мелочи file:size, median, avg. Теперь например посчитать медианный размер файла в каталоге:

bf6 median [map file:size [dir:list:files .]]

Пошёл посмотреть чо как поживают Nim, Zig и D, выяснил, что существует язык Odin. Получается так, что теперь отдельно язык Жопа Одина, отдельно Один. Одни тесты в язык встраивают — т.е получается, что в языке нет более общих конструкций, на которых можно было бы выразить тест, например (функция с аннотацией). Причем, конечно же, весь этот лес adhoc конструкций еще и более всрат, чем то, что тут уже с 59-го года есть. Ну, как обычно. Я бы выпускникам факультетов компьютер сайнсов дарил бы книжку, что бы хоть одну книжку прочитали. В идеале бы две, конечно

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

      put "#define DEFSTACK(n, t, l) t n[(l)], *n##top = n"
      put "#define RESET(a)   (a##top) = a"
      put "#define PTOP(a)    (a##top)"
      put "#define TOP(a)     (*(a##top))"
      put "#define POP(a)     (*(a##top)--)"
      put "#define PUSH(a,v) (*(++(a##top)) = v)"
      put "#define NEXT(x)    continue"
      put "#define JUMP(x, b, o)  ((x) = (b) + (o)); continue"
      put "#define SKIP(x, n)  (x += n)"
      put "#define PC(x, b) ((unsigned int)(x - b))"

ну умножить где-то еще в десять раз. но типа того, не больше. конечно, пока что заруливает sectorlisp , https://github.com/jart/sectorlisp/blob/main/sectorlisp.S который делает lisp в 512 байт машинных кодов, что наводит на мысль, что форт здесь лишнее звено и скорее уж форт писать на лиспе, чем наоборот.

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

Шутка про сделать простой сторейдж на хаскелле используя только простые иммутабельные дисковые структуры несколько затянулась, конечно. Но тем не менее — подход рабочий. 850 - 880 mb/s при записи (с индексацией и fsync), 820K лукапов в секунду по 32-байтовому ключу при 1 индексе (скорость заметно падает с ростом числа сегментов, так что надо мержить), фоновой сборкой мусора и компакцией. Сегодня допилил тесты на устойчивость к kill -9, всё работает как должно — теряется только в пределах fsyncBytes данных и ничего не корраптится. Несколько Пару тысяч тестов сегодня прогнал. Начал чистить код и готовить к внедрению в hbs2-peer. Теперь уже после 10-го числа только.

Ну что, неделя в горах с парапланами без связи - done, впечатления в соседнем офтопиковом канале. Кстати, hbs2 хорошо себя чувствует в ситуациях с плохой связью и возможный кейс — обмен данными и сервисы в присутствии локальной сети и отсутствии связи с большим интернетом. Минимум в одном таком месте я бываю регулярно и P2P сервисы типа того же инстаграмма (шарить фоточки и видео среди своих с отложенной репликацией в глобальные сервисы) — зашли бы отлично, если бы можно было бы объяснить ЦА что это такое. Лучше бы, конечно, никаких глобальных сервисов бы не было вовсе, но тут увы, даже СРКН не справился.

Судя по увеличению количества новостей про те или иные mesh решения — это заметный тренд, ввиду всякого разного, например, повсеместной чебурнетизации. Удивительно (нет), но отличники в говноедстве снова британцы, а вовсе не всякие сатрапии со своими СРКНЫ-ами. Сатрапии, как всегда, перенимают передовой западный опыт и находятся в роли догоняющих.

Очередному бедолаге удалили все данные за двадцать лет из AWS, потому что уборщица (девопс) выдернула провод шваброй (тестировала какой-то скрипт в проде), конечно же репликация этих данных была с N=1, и за деньги пользователя согласно EULA провадер сервиса должен пользователю просто его не бить ногами. Теперь будет судиться, суд конечно же постановит вернуть все биты в исходное состояние .

Так что мы продолжаем.

Как так вышло, что вопрос о том, что нужны протоколы для IM, а не какая-то конкретная реализация — вообще пропал из повестки? Почему-то как само собой разумеющееся, что государственный, прости г-пди, мессенджер — это какой-то конкретный сервис. А не набор протоколов + федерация операторов.

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

Как раз государство на волне всего этого могло бы продавить протокол и "операторов", сорма туда понатыкать, пакетов яровой и что угодно, но хотя бы клиенты были бы разные и глядишь, был бы один нормальный.

Вместо этого какая-то неприкрытая содомия, хотя содомия у нас запрещена, вроде.
Еще какой-то мессенджер появился, мало одного всратого поделия, теперь их два.

Ничего в этом невозможного нет. SMS-то ходят между операторами. Смогли еще в 90х,

email ходит, смогли в 80х.

Тут всё в разы проще.

У меня особенно бомбит от того, что в этой сфере (IM) нет и не будет / не предвидится правильных вещей. Правильная вещь, например — это адресация по криптоключу.

В 2025 и дальше ни с опсосами, ни с доменами дел лучше не иметь.

Нам показали в 2009, что так можно и это мало того, что отлично — так еще снимает просто огромную кучу головняка. Это тупо удобнее и проще.

Проблемы роутинга многократно решены, просто надо сделать, как уже много кто делал.

Вопрос распространения большого/нетекстового контента / ссылок — решается CAS и хэш-ссылками.

"как это будет масштабироваться на охулиард миллионов пользователей" — такая проблема есть только у централизованных сервисов, у которых бизнес — торговля пользователями. Остальным не надо охулиард миллионов, а только свою адресную книгу. Опять же — email работал и всё еще работает. Торренты работают. Блокчейны работают. Почему вместо псевдоденежных переводов нельзя слать сообщение "привет,как дела" ?

Но вместо того, что бы сделать правильно — и просто -- PEX/GOSSIP/NAT traversal/криптоадреса — мы имеем два трека —- государственные и централизованные говномессенджеры с проприетарными протоколами и нечто малоюзабельное, но судя по фичам действительно ориентированное на организацию беспорядков или торговлю наркотиками, т.к. для остального можно было бы попроще и подружелюбнее сделать.

Блокчкейнов как чаек на помойке, криптокошелёк в каждом двадцатом телефоне точно, а сделать на той же по сути платформе мессенджер — ну за вычетом всего ненужного будет даже меньше — никто не сделал. Как так-то. Надо тупо просто специфицировать форматы данных и алгоритмы шифрования/подписи. Всё.

Интересно, не лежит ли причина отсутствия спецификаций протоколов мессенджеров в том, что в любом их них не может не быть E2E шифрование.

Простое E2E без PFS/PD сделать очень просто — и если алгоритм шифрования не скомпрометирован, то даже самый простой chachapoly сделает массовую прослушку бесполезной. Я не очень понимаю, как прослушивают HTTPS (видимо, никак) — но в случае форума можно прийти к владельцу/хостеру форума и бить его гаечным ключом, пока от отдаст дамп базы. Если форум иностранный — то можно его запретить.

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

На всякий случай скажу — прямо сейчас есть децентрализованный багтрекер fixme-new, который просто синхронизирует sqlite базу тикетов через CRDT примитивы (refchan ) и GOSSIP. C ACL и шифрованием. Чем это отличается от доски сообщений, кроме немножечко вёрстки — не вполне понятно.