А ведь хорошо учёным, наверное: если вовлёкся в дискуссию с чувачком, который в теме знает только то, что только что загуглил — то в какой-то момент просто просишь выложить индекс Хирша на стол и линейкой меряете. Самое интересное, что технически у меня возможно и есть этот самый индекс Хирша - стою соавтром нескольких бумаг, и там в сетях мне долгое время шли уведомления, что их кто-то где-то цитирует. Правда, чувствую, короткий индекс Хирша. Но может быть, больше нуля всё равно. Оставаться в академии, что бы иметь козырь для срачей в телеге — хм, заманчиво!
Собрался в Бишкек, а в Бишкеке блэкауты. Зачем лучший интернет-банк в СНГ, если у него отключили электричество?
Импорт openwrt из git в pijul идёт шесть часов, волнуюсь (git -> git - примерно одна минута)
Почему вот нет lsm-подобной файловой системы? Максимально иммутабельной, что бы каждое изменение просто меняло бы указатель на стейт, а физически бы переписывало блоки только если закончилось место ну или достигнут некий трешхолд. Окей, кажется невозможно инкрементально обновлять индексы в таком виде. Но ведь есть append-only btree — почему-то очень непопулярный. Короче, можно ж было бы встроить time machine в файловую систему почти бесплатно, кажется, что она там нужна.
(Это я случайно снёс .git в проекте)
(Это я случайно снёс .git в проекте)
Для нашей специальной олимпиады — вот параметры проектов. Глубина важна, т.к для каждого измененного объекта — меняются все деревья, куда он входит. Количество каталогов важно, т.к. влияет на обход в ширину.
Как мы видим, nixpkgs не сильно-то страшнее linux, примерно одного порядка явление.
Всё это, конечно, немонорепы. Монорепа — это когда тащится транзитивно весь мир, например если контора делает прошивки для роутеров на основе nix и linux — то туда приедет и nixpkgs и linux и чёрт в ступе (вместе со всей историей, которая может и не нужна)
Как мы видим, nixpkgs не сильно-то страшнее linux, примерно одного порядка явление.
Всё это, конечно, немонорепы. Монорепа — это когда тащится транзитивно весь мир, например если контора делает прошивки для роутеров на основе nix и linux — то туда приедет и nixpkgs и linux и чёрт в ступе (вместе со всей историей, которая может и не нужна)
Довольно занятно, что наличие распределенного гита приводит к тому, что в реальной распределенной разработке git как-то особо не нужен. То есть предпочитаемый способ получения изменений — получение оформленного патча как отдельного артефакта; сам "канал" с проектом как-то не особо нужен. Похоже (точно я не знаю) что в таком стиле работает и сам linux - только не через hbs2 артефакты передаются, а через почту + обвязку в b4. В таком стиле в git не хватает сохранения авторства патчей - т.е вот мержишь ты его — если сразу не заскочил — то приходится руками что-то покурочить, а это меняет хэши. А от удаления авторства страдает социальный аспект этой всей движухи.
Кажется, что для "работы с патчами" нужна алгебра патчей, но чот реальные реализации этой самой алгебры выглядят как-то неутешительно/неубедительно.
Кажется, что для "работы с патчами" нужна алгебра патчей, но чот реальные реализации этой самой алгебры выглядят как-то неутешительно/неубедительно.
Forwarded from ᛒ ᛖ ᚱ ᚲ ᚢ ᛊ ᛞ ᛖ ᚲ ᛖ ᚱ
мы видели великое переселение openwrt, импорт успешно закончился сообщением Error: No such file or directory (os error 2) после всасывания ВСЕХ 64571 коммитов за (2025-06-22-10:18 — 2025-06-19-08:22 то есть 3 дня 1 час и 56 минут) со средней скоростью 14,5 коммитов в минуту.
Разбор полётов по текущему NCQ (lsm подобное хранилище с быстрой записью и дисковой хэштаблицей в качестве индекса).
Как обычно — переусложнил из-за непроверенных предпосылок, а проверить их трудно, пока не сделал.
Итого: писать в N потоков может быть до какого-то момента быстрее. Многопоточная запись на диск оправдана. Текущий дизайн этого не позволит.
Файлы, которые пишутся — должны быть как можно более self-contained, не должно быть между ними связи. Взаимосвязи усложняюти логику, добавляют краевых случаев и приводят к ошибкам, даже если кажется, что их нет.
Решение с current.data + current.size исходило из того, что писать лучше в один поток + не стоит создавать мелких файлов, лучше делать из покрупнее, а merge сразу не было (а в итоге он есть всё равно и его наличие делает current.data ненужным)
Решение трекать состояния (в памяти, записан в файл, fsync-нут) с заменой ASAP записанной строки на смещение в файле — нну, в принципе смысл есть однако получилось слишком сложно; думаю надо просто индексировать ASAP и заменять только проиндексированное.
Тут, получается, что минимальный размер сегмента до записи = столько, сколько мы можем себе позволить держать в RAM.
Вообще говоря, имело смысл, но вот что в итоге будет по футпринту если упростить и если не упрощать — надо смотреть. Но похоже, можно просто делать сегменты достаточно маленькими (64...256 мегабайт) и лучше почаще мержить.
Все файловые операции должны быть операциями над каталогом хранилища и ничего не удалять сами и не требовать стейта: merge/index/compact — только создают новые файлы, а что делать со старыми решает верхний уровень (swap+rm или rm — в зависимости от того, мы онлайн или оффлайн).
Вместо файла current.size пишем заголовки транзакций = fsync. Да, write amplification будет — но их можно удалять при compact/merge, имеет значение только последний заголовок; в случае, если его не нашли — можно сканировать файл хоть с начала хоть с конца в поисках последнего корректного заголовка.
Все структуры будут сведены к memtable
в общем, за счёт этого всего ожидаю уменьшения кодовой базы строк на 500 и NCQ2 сравняется с SimpleStorage.
Как всегда, сначала приходит в голову более сложное решение, за исключением memtable. Думал, что сделаю попроще, без fanout этого вот. В итоге попроще тут — гарантированно затыкается — а переделать сложно; Надо как-то запомнить это и больше никогда так не делать; когда много потоков пишут —
Как обычно — переусложнил из-за непроверенных предпосылок, а проверить их трудно, пока не сделал.
Итого: писать в N потоков может быть до какого-то момента быстрее. Многопоточная запись на диск оправдана. Текущий дизайн этого не позволит.
Файлы, которые пишутся — должны быть как можно более self-contained, не должно быть между ними связи. Взаимосвязи усложняюти логику, добавляют краевых случаев и приводят к ошибкам, даже если кажется, что их нет.
Решение с current.data + current.size исходило из того, что писать лучше в один поток + не стоит создавать мелких файлов, лучше делать из покрупнее, а merge сразу не было (а в итоге он есть всё равно и его наличие делает current.data ненужным)
Решение трекать состояния (в памяти, записан в файл, fsync-нут) с заменой ASAP записанной строки на смещение в файле — нну, в принципе смысл есть однако получилось слишком сложно; думаю надо просто индексировать ASAP и заменять только проиндексированное.
Тут, получается, что минимальный размер сегмента до записи = столько, сколько мы можем себе позволить держать в RAM.
Вообще говоря, имело смысл, но вот что в итоге будет по футпринту если упростить и если не упрощать — надо смотреть. Но похоже, можно просто делать сегменты достаточно маленькими (64...256 мегабайт) и лучше почаще мержить.
Все файловые операции должны быть операциями над каталогом хранилища и ничего не удалять сами и не требовать стейта: merge/index/compact — только создают новые файлы, а что делать со старыми решает верхний уровень (swap+rm или rm — в зависимости от того, мы онлайн или оффлайн).
Вместо файла current.size пишем заголовки транзакций = fsync. Да, write amplification будет — но их можно удалять при compact/merge, имеет значение только последний заголовок; в случае, если его не нашли — можно сканировать файл хоть с начала хоть с конца в поисках последнего корректного заголовка.
Все структуры будут сведены к memtable
Vector (TVar HashMap ...) - хорошо масштабируется по потокам (вернее сказать, просто TVar HashMap не масштабируется)writeQueue и trackedFiles :: TVar (HashSet FileKey)в общем, за счёт этого всего ожидаю уменьшения кодовой базы строк на 500 и NCQ2 сравняется с SimpleStorage.
Как всегда, сначала приходит в голову более сложное решение, за исключением memtable. Думал, что сделаю попроще, без fanout этого вот. В итоге попроще тут — гарантированно затыкается — а переделать сложно; Надо как-то запомнить это и больше никогда так не делать; когда много потоков пишут —
TVar HashMap considered harmful.почти (или не почти?) любая структура данных изоморфна списку с тегами; т.е примерно suckless минус сахар
... ну только выкинуть ненужное.
К чему это я? А ну вот — я теперь понимаю, почему solana появился бинарный формат borsсh вместо cbor. Потому что комитет, которому нужно оправдывать свое существование по типу данных "borsch" невозможен. Что бы еще больше подстраховаться, можно назвать как-то еще более антикомитетно, например — jopa или похуже.
Я просто в соседнем чате прочитал про перипетии вокруг CBOR и кажется, надо начинать бояться.
data Syntax c
= List (Context c) [Syntax c]
| Symbol (Context c) Id
| Literal (Context c) Literal
| OpaqueValue Opaque
deriving stock (Generic,Typeable)
... ну только выкинуть ненужное.
К чему это я? А ну вот — я теперь понимаю, почему solana появился бинарный формат borsсh вместо cbor. Потому что комитет, которому нужно оправдывать свое существование по типу данных "borsch" невозможен. Что бы еще больше подстраховаться, можно назвать как-то еще более антикомитетно, например — jopa или похуже.
Я просто в соседнем чате прочитал про перипетии вокруг CBOR и кажется, надо начинать бояться.
Ноут догнивает — к чести марки, корпус держится на последних болтах, а электронной части хоть бы хны. Надеялся, что он доживёт до пришествия ноутов на ARM (мак не предлагать, не заходит), но видимо нет, Linux на ARM ноутах еще не заводится нормально. Думаю, не сделать ли мобильный сетап на безумной платформе типа
GPD Win Max 2 — а несовместимый с жизнью экранчик компенсировать AR очками, встречал описания подобного. Из опасений — на линуксе тоже не заведется. По начинке более чем достойно, кроме прямого применения (читать, немного писать в поездках) — просмотр видео 4K с гоупрох и таскать в мотоцикле (отсюда требования к минимальным размерам). Вроде в стимдеке примерно такая же платформа и всё работает. Обидно будет, если уже через год появятся ARM
GPD Win Max 2 — а несовместимый с жизнью экранчик компенсировать AR очками, встречал описания подобного. Из опасений — на линуксе тоже не заведется. По начинке более чем достойно, кроме прямого применения (читать, немного писать в поездках) — просмотр видео 4K с гоупрох и таскать в мотоцикле (отсюда требования к минимальным размерам). Вроде в стимдеке примерно такая же платформа и всё работает. Обидно будет, если уже через год появятся ARM
Еще интересное. Конструкция
TVar (Seq HashRef) ведёт себя не хуже TQueue/TBQueue очереди, однако позволяет естественно читать пачками с одного или другого конца, что удобно и позволяет простым образом чуток балансировать нагрузку CPU vs IO.#haskell а, ну и fdWrite из System.Posix.IO.ByteString работает процентов на 15 быстрее, чем из Data.ByteString.hPutStr
аналог тайммашины для проекта нужен прямо сейчас. может, для nvim что-то такое есть — что бы были снапшоты с таймстемпами и можно было между ними быстро переключаться
Пока в соседнем чате идут споры (ну как — споры, просто появляются люди, которые абсолютно всё уже знают заранее, куда другим идти и что там делать и как) — и планируется построение глобальной распределенной системы в которой всё будет хорошо — корпорации и AI будут унижены и вообще общее благолепие — примерно скажу, как я всё это вижу.
А вижу я это как на этапе 0 — просто соглашение о структурах данных, и не так важно, как эти именно структуры доедут до конечного потребителя.
Идея, в общем, не нова — есть тот же nostr, на него любопытно посмотреть в плане того, во что можно превратить изначально вроде бы разумную идею.
В web в своё время появились гиперссылки — но по факту, ссылка же ничего физически не адресует и нет никакой гарантии, что для разных пользователей одна и та же ссылка будет указывать на одно и то же (что?). Сейчас ни домены, ни ip адреса, ни строчки после имени домена в URL (да и до него тоже) не имеют никакого смысла.
Сейчас — это когда мы вступаем в эпоху глобального мультичебурнета.
Хэш ссылка — напротив, адресует нечто конкретное, но тоже вопрос — а что именно?
Ну и нет какого-то всеобщего способа хэширования. Последняя проблема выглядит решаемой.
Но если мы сможем хотя бы договориться о ссылках и форматах — то при наличии некоей системы, которая по хэш-ссылке сможет отдать её содержимое — уже можно строить самые занятные системы.
Система это, в общем-то некий глобальный CAS и основное, что он должен уметь делать — это отдавать контент по хэш-ссылке.
Второе, что он должен уметь делать — это поддерживать мутабельные переменные, и эта самая мутабельность в распределенных системах — целая отдельная большая тема.
Углубляться дальше пока незачем, т.е на фазе 0 — нужно хотя бы согласовать виды хэш-ссылок и подумать, как будут добавляться новые алгоритмы хэширования. Что-то мне подсказывает, что даже здесь нас ожидают проблемы, достаточно посмотреть на git, например.
А вижу я это как на этапе 0 — просто соглашение о структурах данных, и не так важно, как эти именно структуры доедут до конечного потребителя.
Идея, в общем, не нова — есть тот же nostr, на него любопытно посмотреть в плане того, во что можно превратить изначально вроде бы разумную идею.
В web в своё время появились гиперссылки — но по факту, ссылка же ничего физически не адресует и нет никакой гарантии, что для разных пользователей одна и та же ссылка будет указывать на одно и то же (что?). Сейчас ни домены, ни ip адреса, ни строчки после имени домена в URL (да и до него тоже) не имеют никакого смысла.
Сейчас — это когда мы вступаем в эпоху глобального мультичебурнета.
Хэш ссылка — напротив, адресует нечто конкретное, но тоже вопрос — а что именно?
Ну и нет какого-то всеобщего способа хэширования. Последняя проблема выглядит решаемой.
Но если мы сможем хотя бы договориться о ссылках и форматах — то при наличии некоей системы, которая по хэш-ссылке сможет отдать её содержимое — уже можно строить самые занятные системы.
Система это, в общем-то некий глобальный CAS и основное, что он должен уметь делать — это отдавать контент по хэш-ссылке.
Второе, что он должен уметь делать — это поддерживать мутабельные переменные, и эта самая мутабельность в распределенных системах — целая отдельная большая тема.
Углубляться дальше пока незачем, т.е на фазе 0 — нужно хотя бы согласовать виды хэш-ссылок и подумать, как будут добавляться новые алгоритмы хэширования. Что-то мне подсказывает, что даже здесь нас ожидают проблемы, достаточно посмотреть на git, например.
Неловкий момент, когда высосал из пальца фильтр тупо на TVar + unboxed vector и он работает примерно так (первый тест — библиотечный блум фильтр bloomfilter)
Но потом говорящие собаки говорят, что ты высосал из пальца то, что уже используется в
- RocksDB (filter block)
- Parquet
- LSM-based системах
и вообще Твой подход — это blocked Bloom filter + multi-bit hashing
См. статью: "Blocked Bloom Filters"
ну... пусть будет тогда, что ли. Так-то мне всего лишь надо было что бы фильтр в STM работал
Но потом говорящие собаки говорят, что ты высосал из пальца то, что уже используется в
- RocksDB (filter block)
- Parquet
- LSM-based системах
и вообще Твой подход — это blocked Bloom filter + multi-bit hashing
См. статью: "Blocked Bloom Filters"
ну... пусть будет тогда, что ли. Так-то мне всего лишь надо было что бы фильтр в STM работал
Еще к фильтрам. Как и было изначально, .cq индексы сами по себе фильтры. Надо просто снижать их количество при помощи merge и/или делать поиск по ним параллельным, что и попробую сейчас запилить. Фильтры это хорошо, но с ними очень много проблем - и с масштабированием, и отсутствием готовых, и непонятно что с инкрементальностью. Иерархический блум например по сложности как весь ncq, + были придумки насчёт инкрементального куку-индекса, но он по сложности тоже больше самого ncq. Ладно...
Вот еще загадка века — зачем нужен PAXOS если есть PBFT. Гугл говорит нам, что
https://ieeexplore.ieee.org/document/9975938
Самое интересное в этом то, что PBFT это типа 2001-ый год, что ли. 1999!!
И он простой как тапок, там 20kloc это потому, что на C++, на х-ле сам алгоритм (минус gossip минус сеть минус сторейдж, чисто FSM) — строк триста. И главное его умом понять можно, а не как PAXOS.
Т.е оно проще даже Raft, кажется. Если же к согласуемому стейту применимы некоторыe принципы CRDT — то становится еще проще.
Finally, based on the evaluation results, it was found that the PBFT algorithm has a speed five times faster than Raft and six times faster than Paxos to reach consensus. So we consider the PBFT algorithm to have the best speed and scalability.
https://ieeexplore.ieee.org/document/9975938
Самое интересное в этом то, что PBFT это типа 2001-ый год, что ли. 1999!!
И он простой как тапок, там 20kloc это потому, что на C++, на х-ле сам алгоритм (минус gossip минус сеть минус сторейдж, чисто FSM) — строк триста. И главное его умом понять можно, а не как PAXOS.
Т.е оно проще даже Raft, кажется. Если же к согласуемому стейту применимы некоторыe принципы CRDT — то становится еще проще.
А как чисто технически СРКНы собираются мониторить "экстремисткие запросы" в гугл или duckduckgo ? TLS-то вроде еще работает, а логи гугл им не выдаёт. История браузера? Но кто в здравом уме будет такое делать не в incognito режиме? Он конечно так себе инкогнито, но историю точно не хранит. Опять же, LLM-ы охотно общаются на любые темы экстремисткие темы, это ж не про секс.