Forwarded from Лентач
В Европе готовят законопроект об обязательной проверке переписки в мессенджерах, включая защищённые чаты.
Инициативу уже поддержали 15 из 27 стран ЕС — всё ради «борьбы с детской порнографией».
Окончательное решение планируют принять 14 октября
А что ещё случилось?
Инициативу уже поддержали 15 из 27 стран ЕС — всё ради «борьбы с детской порнографией».
Окончательное решение планируют принять 14 октября
А что ещё случилось?
Смотрю этот ваш jj и как-то много всё равно там возни. Куча непривычных команд с кракозябрами.
Кмк, система контроля версий должна вообще состоять из двух, что ли частей 1) то, что локально (история изменений) 2) то, что публикуем — и что будет растить глобальный стейт, приводя к 130+ гигабайтам репо линукса.
Я теперь делая каждый коммит гита угрызаюсь, что оно будет потом вечно засорять эфир — т.е привязка кейса "бэкап" к кейсу "публикация изменений" она какая-то неправильная. наверняка в командах с монорепами бьют по рукам за коммиты с целью просто бэкепа текущей работы, да и никто так не делает.
т.е vcs должна работать так — просто как-то (inotify? таймер) + по явной команде сохраняет изменения. что нужно трекать решает настройка - никаких git add, stage и всей этой хни.
периодически можно сказать команду типа бранч/тег/mark/pin — что бы текущее место в DAG как-то пометить.
что куда публиковать — ну опять же, есть наверное бэкап на случай (кот обоссал ноутбук) — и публикация чего-то куда-то.
в общем-то, путём добавлений тегов/марок и манифестов делается из hbs2-sync.
что хочется — так это дешевого и легкого (бесплатного) перемещения по локальной истории, ну и прозрачной работы — просто редактируешь, а vcs сам собой обеспечивается, без каких либо команд вообще
Кмк, система контроля версий должна вообще состоять из двух, что ли частей 1) то, что локально (история изменений) 2) то, что публикуем — и что будет растить глобальный стейт, приводя к 130+ гигабайтам репо линукса.
Я теперь делая каждый коммит гита угрызаюсь, что оно будет потом вечно засорять эфир — т.е привязка кейса "бэкап" к кейсу "публикация изменений" она какая-то неправильная. наверняка в командах с монорепами бьют по рукам за коммиты с целью просто бэкепа текущей работы, да и никто так не делает.
т.е vcs должна работать так — просто как-то (inotify? таймер) + по явной команде сохраняет изменения. что нужно трекать решает настройка - никаких git add, stage и всей этой хни.
периодически можно сказать команду типа бранч/тег/mark/pin — что бы текущее место в DAG как-то пометить.
что куда публиковать — ну опять же, есть наверное бэкап на случай (кот обоссал ноутбук) — и публикация чего-то куда-то.
в общем-то, путём добавлений тегов/марок и манифестов делается из hbs2-sync.
что хочется — так это дешевого и легкого (бесплатного) перемещения по локальной истории, ну и прозрачной работы — просто редактируешь, а vcs сам собой обеспечивается, без каких либо команд вообще
Я, бывало, прыгал BASE c 72-метровой ЛЭП (и ломал руку), так вот ощущения когда там наверху перелезаешь ограждение и стараешься раньше времени не упасть вниз — сопоставимы с запуском hbs2-peer с новым сторейджем с только что написанной процедурой миграции. У меня ж тестовый стенд он же продакшн, как-то неудобно hbs2-peer в нескольких инстансах держать
Если жизнь посылает тебе лимон — сделай из него регрессионный тест. Д. Карнеги
У nix - и много чего еще — discource. У radicle и мнго чего еще — zulip. У fossil scm и sqlite — конечно же свой форум, уважаю чувака, он же всё это еще и на сях пилит. Фоссил-то на сях. Я к тому, что никто ж не делает коммьюнити в вацапах или facetime, это дичь. То, что мы это делаем это в телеге — нехорошо. Я к тому, что надо бы напилить что-то типа juick только распределенное.
Тем временем,
посмотрим, где теперь прострелит.
[dmz@expert:~/w/hbs2]$ hbs2-peer fetch -p HRDcFo2PwTQkEmPPECbZivdUf788s3GumhhqtgErHhfc && hbs2 cat HRDcFo2PwTQkEmPPECbZivdUf788s3GumhhqtgErHhfc
NCQ3-PREVED-20250822
посмотрим, где теперь прострелит.
Как вот так получается, что Snapgradon/ARM - по сути телефонный SoC, андроид — это линукс, а линукс на ноутах со Snapdragon практически не работает. Или винда или макбук. Винда нот ан опшн, а mac — зловещая долина. Там буквально ВСЁ по мелочам сделано так, что вызывает вопросы — в порядке авторы или нет. Незакрывающиеся терминалы, недонастроенный баш, хоткеи которые почти — но не совсем, т.е типа надо палец на одну кнопку сдвинуть и это почти невозможно. Мышиного копирования по умолчанию нет. Понятно, что всё можно настроить, но там надо настроить буквально прямо всё. А если комп поменяется — получится его раскатать, как из flake.nix что бы все эти настройки обратно заехали? Вопрос.
Опупея с новым сторейджем для CAS движется к концу. Даже на маке заработало. и тут удачно и погода не очень и лето заканчивается, так что можно что-то прикольное сделать.
У нас есть — концепт мессенджера, веб. E2E P2P вся фигня. Вроде работает, но подозреваю много проблем из-за несвоевременного вкорячивания UI.
Что бы работало нормально без локальной ноды — надо бы научиться делать cbor пакеты на клиенте и шифровать.
Можно сделать чисто консольный прототип. Если нашлось что-то, от чего было бы легко взять фронтенд и туда подсунуть hbs2 в качестве бэкенда — было бы отлично, но я ничего такого не нашёл.
Можно сделать local-first juick — т.е по сути мессадж борду по модели твиттера ( у каждого свой канал; каждый пишет к себе; те кто подписался — становятся новыми точками раздачи). Можно допустим шарить подписки, кроме того —- можно натренировать какую-то микросетку, что бы работала, как система рекомендаций.
Подмывает сделать vcs чисто поржать — по модели "все есть меркл дерево" и посмотреть, что получится. По сути она делается добавлением "манифестов" / "чекпойнтов" в hbs2-sync но надо подумать. Нафига её делать... Ну, получу time machine для проекта, который хотел + у меня есть кейс публикации подпроектов из монорепы; можно на уровне дизайна сделать "подпроект" и манипуляцию ими.
Морду для гита мне делать не хочется. Очень много UI, очень мало профита. По сути можно синкать через hbs2-git локальный git bare repo и натравить на него любую вебморду гита. Т.е основной вектор усилий будет смещен в сторону UI и веба, кажется, это просто трата времени. По факту лично мне вебморда для гита особо не нужна. Я даже lazygit ленюсь использовать. При таких вводных вряд ли получится хорошо.
Возможно продуктивнее просто взять движок hbs2.net - статический генератор с бэкендом в CAS — немного допилить + прикрутить шаблоны и выложить как средство для публикации своих проектов + сделать какой-то каталог.
Весь hbs2.net это просто небольшая обвязка на bf6 вокруг hbs2-cli — интерпретатора для вызова функций hbs2. ну там сохранить блок/дерево/ссылку и тп.
hbs2-sync + fuse вроде тоже пилится и синхронизирован со сторейджем. Будем мержить всё вместе. Для больших каталогов (файлопомоек) без нового сторейджа оно сдохнет, а с ним нет.
Мне хочется для поржать сделать vcs, но со сторейджем я тоже думал что приключение на пару недель, чо там - в файл пишешь, из файла читаешь, LSM, всё просто.
Кажется, что ввиду общего вот этого фона правильнее двигаться в сторону борды + чуть позже к ней прикрутить приватные сообщения + сделать некий аналог KeyBase возможно.
Есть мысли?
У нас есть — концепт мессенджера, веб. E2E P2P вся фигня. Вроде работает, но подозреваю много проблем из-за несвоевременного вкорячивания UI.
Что бы работало нормально без локальной ноды — надо бы научиться делать cbor пакеты на клиенте и шифровать.
Можно сделать чисто консольный прототип. Если нашлось что-то, от чего было бы легко взять фронтенд и туда подсунуть hbs2 в качестве бэкенда — было бы отлично, но я ничего такого не нашёл.
Можно сделать local-first juick — т.е по сути мессадж борду по модели твиттера ( у каждого свой канал; каждый пишет к себе; те кто подписался — становятся новыми точками раздачи). Можно допустим шарить подписки, кроме того —- можно натренировать какую-то микросетку, что бы работала, как система рекомендаций.
Подмывает сделать vcs чисто поржать — по модели "все есть меркл дерево" и посмотреть, что получится. По сути она делается добавлением "манифестов" / "чекпойнтов" в hbs2-sync но надо подумать. Нафига её делать... Ну, получу time machine для проекта, который хотел + у меня есть кейс публикации подпроектов из монорепы; можно на уровне дизайна сделать "подпроект" и манипуляцию ими.
Морду для гита мне делать не хочется. Очень много UI, очень мало профита. По сути можно синкать через hbs2-git локальный git bare repo и натравить на него любую вебморду гита. Т.е основной вектор усилий будет смещен в сторону UI и веба, кажется, это просто трата времени. По факту лично мне вебморда для гита особо не нужна. Я даже lazygit ленюсь использовать. При таких вводных вряд ли получится хорошо.
Возможно продуктивнее просто взять движок hbs2.net - статический генератор с бэкендом в CAS — немного допилить + прикрутить шаблоны и выложить как средство для публикации своих проектов + сделать какой-то каталог.
Весь hbs2.net это просто небольшая обвязка на bf6 вокруг hbs2-cli — интерпретатора для вызова функций hbs2. ну там сохранить блок/дерево/ссылку и тп.
hbs2-sync + fuse вроде тоже пилится и синхронизирован со сторейджем. Будем мержить всё вместе. Для больших каталогов (файлопомоек) без нового сторейджа оно сдохнет, а с ним нет.
Мне хочется для поржать сделать vcs, но со сторейджем я тоже думал что приключение на пару недель, чо там - в файл пишешь, из файла читаешь, LSM, всё просто.
Кажется, что ввиду общего вот этого фона правильнее двигаться в сторону борды + чуть позже к ней прикрутить приватные сообщения + сделать некий аналог KeyBase возможно.
Есть мысли?
Уверен, что протоколом mailbox никто кроме меня не пользовался, но если что —- миграция на новый сторейдж его поломала. То есть не его, а состояние сообщений (импортировано/нет).
Как раз за счёт того, что не сохранял исходные хэши посоленных хэшей ссылок.
Починябельно; из хороших новостей — оно в целом работает.
Как раз за счёт того, что не сохранял исходные хэши посоленных хэшей ссылок.
Починябельно; из хороших новостей — оно в целом работает.
Похоже, что с вайбкодингом какая история — у нас есть множество людей, которые уверены, что они очень умные и знают, что делать, просто языков программирования не знают. В отличие от тупых программистов, которые очень тупые, но языки программирования знают. В общем-то это прямое следствие того, что в социуме почти все — самые умные. (sic).Ну уж точно умнее, чем эти. Навеяно тем, что говорящая собака прямо со звериным упорством предлагает писать код, как будто бы именно это какая-то проблема и её решение очень ценно. Между тем всё дело в требованиях, и кажется, что инжиниринг требований (обнаружение зависимостей, конфликты) — таки может быть произведен говорящими собаками в силу того, что они внимательные и (пока) не подвержены скуке и похуизму. Ведь зачем мясному аккуратно и добросовестно работать с требованиями — когда точных критериев успеха нет, проверить почти невозможно (самая близкая аналогия — состязание в суде) — соответственно, факап с требованиями может или не выясниться никогда или "ну не шмогла"
hbs2 dev-0.25.3 доступен для скачивания/установки/тестирования.
https://hbs2.net/ref/4X65y4YvUjRL2gtA9Ec3YDDP4bnxjTGhfjpoah96t3z1/get
статус — тест. может, "бета". поменялся внутренний сторейдж, теперь на NCQ3. поменялся тулчейн — hbs2 теперь скриптовая обёртка над hbs2-cli, могли отъехать маны или что-то недообернулось. надо будет смотреть. буду довыкладывать.
Миграция вроде работает. На Mac OS X вроде работает. Пойду смигрирую маковую ноду, кстати.
Перед миграцией рекомендую бэкап, но оно и само не будет удалять старую бд, только переименует.
Тестировал миграцию на 50Gb снапшоте, отработало за O(1) по памяти (это же Haskell, так что это важно).
Про сторейдж написал тут:
https://hbs2.net/ref/4X65y4YvUjRL2gtA9Ec3YDDP4bnxjTGhfjpoah96t3z1/ncq3
TL;DR - раньше CAS был, как у старого гита — один объект один файл. Что было не так уж плохо, т.к объекты у нас довольно большие.
Потом стал NCQv1 — слегка похоже на git packs (один файл данных — один индекс. структура, впрочем, другая - что данных, что индекса). Чем был плох — подозрение, что заклинит на очень больших объемах + плохо переживал выключения питания и
Сейчас CAS — дисковые хэштаблицы (lookup O(1)) в качестве индексов + append only журналы для хранения данных. журналы и индексы мержатся, мусор собирается при мерже. Журналы данных — 512M ... 8G + delta (чот типа 9.3 получается). На что влияет: если сделать верхний край больше — очень хреново переписываются на слабых компах. Если сделать их меньше — то могут поджирать лимиты числа запамленных файлов и подтормаживать при поиске.
+ появилась значительная тестовая обвязка и особенно тесты выносливости, имитирующие реальную нагрузку + многократные открытия/закрытия сторейджа или отключение питания / kill -9.
C этим сторейджем можно уже ехать дальше, например делать большие распределенные файловые хранилища и т.п.
https://hbs2.net/ref/4X65y4YvUjRL2gtA9Ec3YDDP4bnxjTGhfjpoah96t3z1/get
статус — тест. может, "бета". поменялся внутренний сторейдж, теперь на NCQ3. поменялся тулчейн — hbs2 теперь скриптовая обёртка над hbs2-cli, могли отъехать маны или что-то недообернулось. надо будет смотреть. буду довыкладывать.
Миграция вроде работает. На Mac OS X вроде работает. Пойду смигрирую маковую ноду, кстати.
Перед миграцией рекомендую бэкап, но оно и само не будет удалять старую бд, только переименует.
Тестировал миграцию на 50Gb снапшоте, отработало за O(1) по памяти (это же Haskell, так что это важно).
Про сторейдж написал тут:
https://hbs2.net/ref/4X65y4YvUjRL2gtA9Ec3YDDP4bnxjTGhfjpoah96t3z1/ncq3
TL;DR - раньше CAS был, как у старого гита — один объект один файл. Что было не так уж плохо, т.к объекты у нас довольно большие.
Потом стал NCQv1 — слегка похоже на git packs (один файл данных — один индекс. структура, впрочем, другая - что данных, что индекса). Чем был плох — подозрение, что заклинит на очень больших объемах + плохо переживал выключения питания и
kill -9.Сейчас CAS — дисковые хэштаблицы (lookup O(1)) в качестве индексов + append only журналы для хранения данных. журналы и индексы мержатся, мусор собирается при мерже. Журналы данных — 512M ... 8G + delta (чот типа 9.3 получается). На что влияет: если сделать верхний край больше — очень хреново переписываются на слабых компах. Если сделать их меньше — то могут поджирать лимиты числа запамленных файлов и подтормаживать при поиске.
+ появилась значительная тестовая обвязка и особенно тесты выносливости, имитирующие реальную нагрузку + многократные открытия/закрытия сторейджа или отключение питания / kill -9.
C этим сторейджем можно уже ехать дальше, например делать большие распределенные файловые хранилища и т.п.
voidlizard.online pinned «hbs2 dev-0.25.3 доступен для скачивания/установки/тестирования. https://hbs2.net/ref/4X65y4YvUjRL2gtA9Ec3YDDP4bnxjTGhfjpoah96t3z1/get статус — тест. может, "бета". поменялся внутренний сторейдж, теперь на NCQ3. поменялся тулчейн — hbs2 теперь скриптовая…»
Btw, у нас в IT почти все ружья стреляют. Вот например есть такой nix и есть такой git. И nix любит лазить в гит, а еще ссылаться на код по гитовой "ссылке" — так вот поскольку ссылки в гите являются симулякром, то ситуации, когда на одном хосте ссылка смотрит на одно, а на другом хосте — на другое —- или у nix вообще в рамках одного хоста мозги вышибает из-за хэшей, как раз.
В общем, весь этот кошмар закончился, когда вместо ссылок на гит стал скармливать никсу просто тарболл исходников. кстати, тарболл делает сам гит при помощи
Делаем тарболл, кладём в hbs2, потом собираем и прочее вот так:
С тех пор, как перешел на такую схему — стало ноль проблем с nix. TL;DR — помог отказ от гита.
В общем, весь этот кошмар закончился, когда вместо ссылок на гит стал скармливать никсу просто тарболл исходников. кстати, тарболл делает сам гит при помощи
git archive.Делаем тарболл, кладём в hbs2, потом собираем и прочее вот так:
nix build localhost:5000/tree/Aog9nHUMSLFgVaCBWqLjWDU4FZ6x2KibPo9XADM3QaNW
С тех пор, как перешел на такую схему — стало ноль проблем с nix. TL;DR — помог отказ от гита.
казалось бы, что может быть вообще проще, чем скачать файл и записать его на диск. отсюда даже пошла поговорка — как два пальц байта переслать. По UDP, сука. Основная проблема даже не в том, что сеть плохая — сеть как раз хорошая. Пакеты приезжают. Просто туда, где их уже никто не ждёт