и то, тут хватит "одного MCP что бы править всеми"
более в тему было бы зарезервировать конкретный порт под агентов, как сайты на 80/443, так точка входя для агентов будет на 81/444 например, а для такого отдельный DNS не нужен
у меня есть домашний сервер нормальный и удаленный VPS для глобалки
я syncthing лет 6 использую для фонового бекапирования и знаком со всеми приколами и особенностями
для заметок реально удобно гит, потому что единая история. История у syncthing не такая удобная и там нельзя играть с ветвлением как с гитом если надо восстановить только один старый файл из истории
Я бы сказал что вы слишком серьезно воспринимаете жизнь, но странно такое писать про человека которому комментарии ИИ пишет
В целом сложилось такое впечатление что я вам своими комментариями непоправимую ментальную травму нанес, что очень странно слышать от настолько старого аккаунта (хотя аккаунтами как и кармой свободно торгуют, причем недорого)
Если вы так плохо воспринимаете критику (а ее и не было как таковой), то не публикуйтесь, что бы поберечь свое ментальное здоровье.
Так все последовательно и ничго удивительного. Сначала был Evernote платный, но он не сильно развивался, старики любили но молодежь нет. Затем как ответ появился Notion тоже закрытый платный, но уже дым погуще. А потом бахнула пандемия и был создан Обсдиан под тезисом local-first.
К этому давно шло плюс он очень вовремя появился. Он относительно кривой (веб-движок для отрисовки всего одновременно упрощает создание и делает больно при пользовании) но своей простотой он сразу захватил многих, ведь в пандемию со скуки тысячи программистов легко создавали свои плагины, что бы "расширить функционал" пошло-поехало.
Если бы не экосистема плагинов то обсидиан никому нафиг не нужен был потому как есть редакторы получше. А плагины появились благодаря людям которым было скучно)))
юзайте проверенное решение с гитхабом и прочими гит-площадками. Отслеживаемость по коммитам, стабильность, работает везде на любых клиентах (для андроида я юзаю GitSync хотя у знакомого все в рамках плагинов на обсидиан работает)
Единое что - название файлов не все виды символов допустимы. Точнее с дескстопа все будет работать, но с телефона поймаете ошибку если есть неприемлемые для гита (url) символы в названии файла
Вообще syncthing хорош как фоновый бекапер в формате master-slave и то с оговорками (большие данные, например гит-репу на сотню гигов он очень долго синхронизирует, а потом стабильно шакалит). master-master используйте на свой страх и риск, потому как даже включенная история не поможет если у syncthing разойдется синхронизация и начнутся шакалы. Максимум master-master с промежуточным slave который всегда в сети, а мастера выходят по очереди, без возможности одновременной работы.
Это не значит что syncthing плох, я сам его использую много лет, особенно хорош с электронной книгой, никаких проводов, сам по серверу обновляется. Просто именно для обсидиана и активных заметок на разных устройствах syncthing плох.
Не планировал как то оскорблять или навешивать ярлыки, просто написал как думаю
а теперь по пунктам:
я не владею растом, пробовал много раз, но мне сложного и не очевидного синтаксиса и в Си хватает, потому мог что-то просто криво понять
TLS это не просто транспорт, как и protobuf это не просто gRPC. Если вам нужно безопасно хранить логи клиента то храните, в чистом виде что получили то и храните. При этом куча фишек сразу идет в комплекте причем не только критографических.
За хранение:
Статья написана про протокол, в репе сказано за протокол. Я пытался понять зачем хранение в транспортном протоколе. Обычно если делают модуль то разделяют зоны ответственности, то есть транспорт отдельно, хранение отдельно. Вместе это уже какая-то тулза что состоит из отдельных модулей.
По хранению рекомендую посмотреть на как сделано cockroachdb/pebble дам довольно просто и очевидно, потому как ваше простое хранение по фиксированному массиву спорное решение для вашей же задачи когда надо прокидывать и читать странные логи. Во-первых хранение не массивами, а фиксированными чанками,что бы оно ровно в памяти лежало и проще читалось на произвольные размеры. Во-вторых как раз лучше разорвать шифрование транспорта и шифрование хранилища, для того что бы расшифрованное нарезать по чанкам, а чанки жать и уже результат шифровать. Даже если все in-memory то оперативка не бесконечная, а зашифрованное не сожмется так как расшифрованное особенно если это логи которые можно сжать и в х20 если повторов много.
По кривому шифрованию как минимум у вас в отрытых данных длинна и как убить комп подменив всего пару байт в потоке я писал выше. Было бы у вас еще по хешу проверка целостности, а не CRC32 то можно было бы "помолившись забить" но так вектор атаки настолько очевиден, что подсознательно кажется что это приманка (например 16 байт с зашифрованного блока это скрытая хеш-сумма всего пейлоада, что бы детектить мамкиных хакеров еше на этапе анализа инфраструктуры)
За интеграции я потому и написал за подключаемые библиотеки. Вы со своей стороны собрали бинарь, а дальше как с ним будут работать не ваши половые трудности. Если простыми словами, то dll/so это "стариковский WASM для десктопов". Потому как CLI это не сильно безопасно и вообще не кроссплатформенно. Я вот например свои пет-проекты если делаю как "универсальный" CLI то собираю 38 бинарей (linux/amd64, linux/arm64, linux/arm/v7, linux/arm/v6, linux/386, linux/mips, linux/mipsle, linux/mips64, linux/mips64le, linux/ppc64, linux/ppc64le, linux/riscv64, linux/s390x, windows/amd64, windows/arm64, windows/arm/v7, windows/386, macos/amd64, macos/arm64, freebsd/amd64, freebsd/arm64, freebsd/arm/v6, freebsd/arm/v7, freebsd/386, openbsd/amd64, openbsd/arm64, openbsd/arm/v6, openbsd/arm/v7, openbsd/386, netbsd/amd64, netbsd/arm64, netbsd/arm/v6, netbsd/arm/v7, netbsd/386, android/amd64, android/arm64, android/arm/v7, android/386) и это самые популярные и беспроблемные (то есть собирается прямо в actions github) потому как предусмотреть все нереально, а ковыряться со сборкой до бума с ИИ редко бы кто стал.
А за логи я вам писал в другом вашем посте развернуто. Как лучше хранить и агрегировать. По поводу "небезопасных данных" - если сами разрабы, кто писали логи, такие "индусы" то просто сделайте тонкий клиент-обфускатор что будет работать в потоке и все. Все равно нежные данные должны как то помечатся - задетектили, обрезали середину, добавили звездочек и вот уже открыто переданный пароль нечитаем для стороннего чтения. Потому как шифрование это полумеры и вы этим лечите чужие ошибки своими костылями. Но вообще за такое безопасники беседуют без смазки со всеми причастными вплоть до увольнений.
рекомендую написать самому. Точнее навайбить как сейчас говорят. Нормальные готовые только по подписке за 20-40$ в месяц
Вам хватит веб-сайта под PWA. Если захочется централизации то простенький хостинг что бы он был мастером для синхронизации. Но хотинг не обязателен все может работать локально.
Кодовый агент по подписке вам сделает четко то что нужно. Причем сейчас html5 и PWA поддерживают и работу с камерой, и виброотклик, и пуш-оповешения. А котовые агенты отлично умеют сами запускать браузер и смотреть что получилось.
То есть вы можете подробно расписать план что нужно, как делать и как проверять и на выходе получите примерно что нужно. Отладка и подгонка будет, но для личного приложения вам это вообще не проблема.
Единое что - сразу заложить железобетонную структуру хранения поддержкой импорта/экспорта. Рекомендую прописывать структуры в protobuf и экспорт делать сжимая тело в gzip программно (не в архив паковать, а именно байты тела жать). Получится и строгость и гарантированная целостность (не забываем добавлять хеш проверки целостности) и удобный формат который ни с чем не перепутается (нет проблем с импортом "похожего" и база поползла)
я за RFID думал сразу уже промышленное решение со складским стационарным ридером за 600$ который спокойно комнату покроет по площади считывания, что бы уже не переделывать по 10 раз
остановило именно "закручивание гаек в семье" что бы это заработало нормально, ведь человеческий факто никуда не девается. на работе можно и простыми 2Д кодами решить с UID и ячеечным хранением потому как можно прописать четкий регламент и требовать что бы его придерживались, а вот дома так нельзя иначе какой это дом
Войну с "складывать в одном месте" я выиграл. Проблема в том "как" складывать. И вторая проблема что не всегда относится на место, особенно если по сумкам кидают "срочно срочно на работе выпью" и забывают.
Я сразу вижу две проблемы - отсутствие актуализации (потратили и не отметили что потратили) и порядок хранения (кинули как попало или греблись в поисках без заморочек)
Думал за RFID что могут работать с метками-соседями (и заодно можно будет найти заныканое по сумкам) но проблема опять в маркировке - по одной пластинке маркировать дичь, а коробками и пакетами не всегда обратно складывают и опять неопределенность
С одной стороны строить гулаг дома, а с другой стороны если хочется тотального контроля над живым существом то лучше купить хомяка и его мучить.
Была мысль вообще радикально поступить - система хранения что выдает и контролирует что выдает, не пластинками, а таблетками и тд. А для баночек и мазей уже можно RFID с оповещениями "вы не вернули на место" но это тоже как то антиутопией отдает)
Не слушайте этих извращенцев с консольными полурешениями, где для работы с логом тебе надо кодить прямо в консоли на баше. Ваша ситуация классика, я бы даже сказал легко-средний уровень. Средний уровень это десятки и сотни гигов логов одним файлом. А кошмарный уровень выражается в терабайтах, что раскиданы по куче разным S3 по папкам и архивам.
Во-первых нужно нормально формировать логи. Прозвучит странно, но 80% работы с разбором логов начинается с формализации логера и встраивания нормального настроенного четко под вас логера с строгими правилами как и где логируется, с какими уровнями и метками.
Во вторых уровни логирования. Для рантайм вывода хватит и ERR-уровня или даже вообще выключить (но лучше что бы было, логов много не бывает). Для потокового пишущего логера достаточно INF-уровня. А если нужно и можно (ресурсы) то фоново пишутся в файлы по DBG-уровню причем сразу уже с архивацией, ротацией по размеру и очисткой по переполнению и дате.
Кажется что 2 и 3 это одно и тоже, но это не так. Существует огромное количество нормальных агрегаторов логов, которые созданы что бы с минимумом оверхеда хранить и индексировать логи. Лично я в работе использую Loki в связке с метриками, но никто не запрещает использовать что-то другое. Самое главное в таком подходе что логи будут лететь сразу на агрегатор в базу, а не в какой-то текстовый файл с которого потом парсить (хотя Loki может и так, причем в рантайме). Особенно такой подход оцените при множестве источников логов (микросервисы или распределенная архитектура) и/или когда нужно проанализировать данные за огромный период (месяцы и года) и/или огромный массив (миллиарды точек и терабайты логов) Тонкость в том что на агрегатор летит именно по INF. Не прям все, особенно если логи нормально описаны, но все же достуточно что бы отслеживать и детектить проблемы. А если же реально возник форсмажор то всегда есть дебаг-логи которые хранятся на месте всего за месяц или неделю, но которые максимально полные. Одна консольная команда (или прямо в каком-то интерфейсе) и мы загружаем эти логи в наш агрегатор что бы с ними работать как привыкли.
Всегда когда возникает какая-то проблема, особенно если эта проблема частая, стоит погуглить как с ней воюют другие (и проблема ли это вообще - "верх запаян, дна нет"). Возможно уже давно есть решение этих проблем. Решение которое проверенно временем и уже предвосхищает не только данную проблему но и те что возникнут потом в будущем.
протобаф это много что. gRPC это просто вишенка на торте. В первую очередь это стандартизированный и главное вылизанный формат бинарного обмена данными. Ваш пример с 0 некорректен ведь если нужно строго то можно прямо указать что бы генерировались все значения даже отсутствующее рамках языка, нужно определять пустоту - ссылка или массив из простого.
Из прото-схем потом можно и в json и в какой угодно другой формат без головняка, для проприоретаршины же нужно писать и поддерживать специальные методы под это
Вылизаность стандарта - как много всего в этом термине. Простое склеивание бинарных данных чревато множеством интересных вещей, особенно если данные являются разным типом. С протобафами же не переживаешь ни за разрядность, ни за правильный порядок, ни за миграцию схем, и прочее прочее.
"распознание в замусоренных потоках" очень странное требование, но окей, с прото можно так же, причем сам прото имеет механизм oneof что бы удобно прямо в рамках протобафа определять подходящий обьект если получаешь на чтение просто какой-то обьект. А если без oneof то тогда только руками проверять, но отделить прото-обьект в производном потоке можно без проблем потому как у протобафа тоже есть стандартная сигнатура)
Префильтрация это немного другая задача. Я не знаю может ли протобаф сам что-то с этим делать потому что мне никогда не нужно было, но эта задача решается так же как и с любым другим способом разметки данных и фильтрации в потоке: определяем начало нужной сигнатуры >> ищем совпадение >> помечаем сигнатуру как игнорируемую если совпадения нет (или наоборот)
Даже сам создатель протобафа согласен что он не является святым граалем (и пилит свои "улучшенные костыли" которые до сих пор даже из альфы не вышли) но стандартизация на то и существует что б упрощать жизнь как себе, так и тем кто будет после тебя. Протобаф не только проверен и вылизан максимально, но еше имеет и огромную кучу вещей построенных вокруг него, начиная от не-гугловских генераторов/сигнализаторов (по разнообразным причинам) и заканчивая либами и поддержкой сторонними приложениями.
Из интереса закопался в исходный код (интересен сам алгоритм) и по состоянию на последний коммит f4228c5 вот список вопросов/фактов
не совсем понятно почему не запаковалось это все в динамические библиотеки (dll/so) раз уж начали делать интеграции, вместо этого неочевидный cli который еше может дрейфовать если продукт будет развиваться
не совсем понял за фишку с "смешанным потоком", я думал там что-то по типу "размазывания шума" что бы сами данные не были видны (очень актуально сейчас), но там классическая классика с сигнатурой+crc
так же вообще не понял за механику хранилища, я думал то такой странный кольцевой буфер для асинхронных ридеров, даже неронку зарядил на анализ, но оказалось что это просто хранилище? Зачем вшитое хранилище в потоковый криптопротокол? И я не увидел никаких ограничений на память при запуске (как параметр) то есть вполне можно убивать удаленные машины просто забив память отсылая пустые данные этим протоколом
подозрительно встречающиеся unsafe, для такой задачи (учитывая что никакой магии с байтами я не заметил) это очень похоже на костыли которые воткнули "чтоб работало" что в разрезе криптопротокола интересно смотрится, особенно если добиться колизии адресов при перезапуске тулзы(где в основном unsafe и юзается)
уязвимость прямо из учебника - берется len из полученного пакета и по этому len сразу резервируется память. Как минимум крашнуть тулзу можно и вызвать потери пакетов, как макс память выделится на всю оперативку и комп зависнет (никаких ограничений в рамках самой тулзы на лимиты памяти нет, напомню)
таки я был не прав и сделано нормально с симетричным на тело и асиметричным на обмен, но как же оно сделано! Ротация ключей сделана на лимите. Я искал другие механизмы начиная от принудительного рукопожатия по требованию и заканчивая сбросом лимита по условиям (размер, частота битости, иное) но такого нет, строго лимит и все.
в продолжение вышеперечисленного - шифрование ничего не гарантирует и ни от чего не защищает. Я выше писал что распознание по сигнатуре+CRC и это не опечатка - используется не префикс и даже не правило чтоб не палится с префиксом, а тупо тело. Незашифрованное хочу заметить тело (перепроверил нейросетью, метаданные гарантировано не шифруются)
Резюмируя - как учебный проект на поиграться очень топово и разнопланово. Все мы таким занимались когда-то в своей жизни если программирование действительно интересно. Но как реально используемый проект/алгоритм под вопросом потому что я даже не могу придумать где такое можно было бы использовать что бы оно было прямо таки преимуществом и/или в тему.
Как ученическая работа на поковырять и посмотреть ваш проект хорош. Даже векторы затронули, что не каждый из тех кто играется с созданием своей криптографии делает.
Но вот как "боевое использование" какие преимущества от такой проприоретаршины? На глаз Я бы не сказал что она будет быстрее классики, я бы даже сказал что наоборот если я правильно понял и вы все end-to-end в RSA пакуете. За безопасность тоже под вопросом, хотя тут я не специалист может и не прав. У меня сразу вопрос почему производная от SHA256 а не тот же BLAKE3?
а вообще джуны сейчас маскируются под мидлов (что не так уж и сложно, ведь прохождение собеседований это совершенно другая дисциплина) потому прям реальных джунов которые говорят что они джуны мало (потому как они понимают всю тленность бытия еше в первый месяц поиска работы) уже неоднократно с таким сталкивался в наеме за последние два года
локальное или корпоративное - да
и то, тут хватит "одного MCP что бы править всеми"
более в тему было бы зарезервировать конкретный порт под агентов, как сайты на 80/443, так точка входя для агентов будет на 81/444 например, а для такого отдельный DNS не нужен
надо настройки корвырять. Причем расширенные. Отключить что бы не пыталось искать за пределами NAT как минимум
у меня есть домашний сервер нормальный и удаленный VPS для глобалки
я syncthing лет 6 использую для фонового бекапирования и знаком со всеми приколами и особенностями
для заметок реально удобно гит, потому что единая история. История у syncthing не такая удобная и там нельзя играть с ветвлением как с гитом если надо восстановить только один старый файл из истории
Я бы сказал что вы слишком серьезно воспринимаете жизнь, но странно такое писать про человека которому комментарии ИИ пишет
В целом сложилось такое впечатление что я вам своими комментариями непоправимую ментальную травму нанес, что очень странно слышать от настолько старого аккаунта (хотя аккаунтами как и кармой свободно торгуют, причем недорого)
Если вы так плохо воспринимаете критику (а ее и не было как таковой), то не публикуйтесь, что бы поберечь свое ментальное здоровье.
Удачи!
Так все последовательно и ничго удивительного. Сначала был Evernote платный, но он не сильно развивался, старики любили но молодежь нет. Затем как ответ появился Notion тоже закрытый платный, но уже дым погуще. А потом бахнула пандемия и был создан Обсдиан под тезисом local-first.
К этому давно шло плюс он очень вовремя появился. Он относительно кривой (веб-движок для отрисовки всего одновременно упрощает создание и делает больно при пользовании) но своей простотой он сразу захватил многих, ведь в пандемию со скуки тысячи программистов легко создавали свои плагины, что бы "расширить функционал" пошло-поехало.
Если бы не экосистема плагинов то обсидиан никому нафиг не нужен был потому как есть редакторы получше. А плагины появились благодаря людям которым было скучно)))
потому что обсидиан это открытый бесплатный наследник Evernote который гораздо старше.
Абсолютно не рекомендую syncthing для обсидиана!
юзайте проверенное решение с гитхабом и прочими гит-площадками. Отслеживаемость по коммитам, стабильность, работает везде на любых клиентах (для андроида я юзаю GitSync хотя у знакомого все в рамках плагинов на обсидиан работает)
Единое что - название файлов не все виды символов допустимы. Точнее с дескстопа все будет работать, но с телефона поймаете ошибку если есть неприемлемые для гита (url) символы в названии файла
Вообще syncthing хорош как фоновый бекапер в формате master-slave и то с оговорками (большие данные, например гит-репу на сотню гигов он очень долго синхронизирует, а потом стабильно шакалит). master-master используйте на свой страх и риск, потому как даже включенная история не поможет если у syncthing разойдется синхронизация и начнутся шакалы. Максимум master-master с промежуточным slave который всегда в сети, а мастера выходят по очереди, без возможности одновременной работы.
Это не значит что syncthing плох, я сам его использую много лет, особенно хорош с электронной книгой, никаких проводов, сам по серверу обновляется. Просто именно для обсидиана и активных заметок на разных устройствах syncthing плох.
да нет, это выглядит как заинтересовала статья пошел читать другие
на дату я потом уже посмотрел))
иногда утка это просто утка
Не планировал как то оскорблять или навешивать ярлыки, просто написал как думаю
а теперь по пунктам:
я не владею растом, пробовал много раз, но мне сложного и не очевидного синтаксиса и в Си хватает, потому мог что-то просто криво понять
TLS это не просто транспорт, как и protobuf это не просто gRPC. Если вам нужно безопасно хранить логи клиента то храните, в чистом виде что получили то и храните. При этом куча фишек сразу идет в комплекте причем не только критографических.
За хранение:
Статья написана про протокол, в репе сказано за протокол. Я пытался понять зачем хранение в транспортном протоколе. Обычно если делают модуль то разделяют зоны ответственности, то есть транспорт отдельно, хранение отдельно. Вместе это уже какая-то тулза что состоит из отдельных модулей.
По хранению рекомендую посмотреть на как сделано cockroachdb/pebble дам довольно просто и очевидно, потому как ваше простое хранение по фиксированному массиву спорное решение для вашей же задачи когда надо прокидывать и читать странные логи.
Во-первых хранение не массивами, а фиксированными чанками,что бы оно ровно в памяти лежало и проще читалось на произвольные размеры.
Во-вторых как раз лучше разорвать шифрование транспорта и шифрование хранилища, для того что бы расшифрованное нарезать по чанкам, а чанки жать и уже результат шифровать. Даже если все in-memory то оперативка не бесконечная, а зашифрованное не сожмется так как расшифрованное особенно если это логи которые можно сжать и в х20 если повторов много.
По кривому шифрованию как минимум у вас в отрытых данных длинна и как убить комп подменив всего пару байт в потоке я писал выше. Было бы у вас еще по хешу проверка целостности, а не CRC32 то можно было бы "помолившись забить" но так вектор атаки настолько очевиден, что подсознательно кажется что это приманка (например 16 байт с зашифрованного блока это скрытая хеш-сумма всего пейлоада, что бы детектить мамкиных хакеров еше на этапе анализа инфраструктуры)
За интеграции я потому и написал за подключаемые библиотеки. Вы со своей стороны собрали бинарь, а дальше как с ним будут работать не ваши половые трудности. Если простыми словами, то dll/so это "стариковский WASM для десктопов". Потому как CLI это не сильно безопасно и вообще не кроссплатформенно. Я вот например свои пет-проекты если делаю как "универсальный" CLI то собираю 38 бинарей (linux/amd64, linux/arm64, linux/arm/v7, linux/arm/v6, linux/386, linux/mips, linux/mipsle, linux/mips64, linux/mips64le, linux/ppc64, linux/ppc64le, linux/riscv64, linux/s390x, windows/amd64, windows/arm64, windows/arm/v7, windows/386, macos/amd64, macos/arm64, freebsd/amd64, freebsd/arm64, freebsd/arm/v6, freebsd/arm/v7, freebsd/386, openbsd/amd64, openbsd/arm64, openbsd/arm/v6, openbsd/arm/v7, openbsd/386, netbsd/amd64, netbsd/arm64, netbsd/arm/v6, netbsd/arm/v7, netbsd/386, android/amd64, android/arm64, android/arm/v7, android/386) и это самые популярные и беспроблемные (то есть собирается прямо в actions github) потому как предусмотреть все нереально, а ковыряться со сборкой до бума с ИИ редко бы кто стал.
А за логи я вам писал в другом вашем посте развернуто. Как лучше хранить и агрегировать. По поводу "небезопасных данных" - если сами разрабы, кто писали логи, такие "индусы" то просто сделайте тонкий клиент-обфускатор что будет работать в потоке и все. Все равно нежные данные должны как то помечатся - задетектили, обрезали середину, добавили звездочек и вот уже открыто переданный пароль нечитаем для стороннего чтения. Потому как шифрование это полумеры и вы этим лечите чужие ошибки своими костылями. Но вообще за такое безопасники беседуют без смазки со всеми причастными вплоть до увольнений.
а они починили свои "улучшения" которые уже который месяц тянутся из-за чего модели антропика в целом стали тупее?
Особенно баг с забыванием контекста даже на милипиздрических задачах бесит. И это именно общий тюн их настроек, а не какая-то конкретная модель
спасибо!
убедился в глубине всратости и сохранил на случай
возврата саске в конохуважных переговороврекомендую написать самому. Точнее навайбить как сейчас говорят. Нормальные готовые только по подписке за 20-40$ в месяц
Вам хватит веб-сайта под PWA. Если захочется централизации то простенький хостинг что бы он был мастером для синхронизации. Но хотинг не обязателен все может работать локально.
Кодовый агент по подписке вам сделает четко то что нужно. Причем сейчас html5 и PWA поддерживают и работу с камерой, и виброотклик, и пуш-оповешения. А котовые агенты отлично умеют сами запускать браузер и смотреть что получилось.
То есть вы можете подробно расписать план что нужно, как делать и как проверять и на выходе получите примерно что нужно. Отладка и подгонка будет, но для личного приложения вам это вообще не проблема.
Единое что - сразу заложить железобетонную структуру хранения поддержкой импорта/экспорта. Рекомендую прописывать структуры в protobuf и экспорт делать сжимая тело в gzip программно (не в архив паковать, а именно байты тела жать). Получится и строгость и гарантированная целостность (не забываем добавлять хеш проверки целостности) и удобный формат который ни с чем не перепутается (нет проблем с импортом "похожего" и база поползла)
я за RFID думал сразу уже промышленное решение со складским стационарным ридером за 600$ который спокойно комнату покроет по площади считывания, что бы уже не переделывать по 10 раз
остановило именно "закручивание гаек в семье" что бы это заработало нормально, ведь человеческий факто никуда не девается.
на работе можно и простыми 2Д кодами решить с UID и ячеечным хранением потому как можно прописать четкий регламент и требовать что бы его придерживались, а вот дома так нельзя иначе какой это дом
Войну с "складывать в одном месте" я выиграл. Проблема в том "как" складывать. И вторая проблема что не всегда относится на место, особенно если по сумкам кидают "срочно срочно на работе выпью" и забывают.
Я сразу вижу две проблемы - отсутствие актуализации (потратили и не отметили что потратили) и порядок хранения (кинули как попало или греблись в поисках без заморочек)
Думал за RFID что могут работать с метками-соседями (и заодно можно будет найти заныканое по сумкам) но проблема опять в маркировке - по одной пластинке маркировать дичь, а коробками и пакетами не всегда обратно складывают и опять неопределенность
С одной стороны строить гулаг дома, а с другой стороны если хочется тотального контроля над живым существом то лучше купить хомяка и его мучить.
Была мысль вообще радикально поступить - система хранения что выдает и контролирует что выдает, не пластинками, а таблетками и тд. А для баночек и мазей уже можно RFID с оповещениями "вы не вернули на место" но это тоже как то антиутопией отдает)
Не слушайте этих извращенцев с консольными полурешениями, где для работы с логом тебе надо кодить прямо в консоли на баше. Ваша ситуация классика, я бы даже сказал легко-средний уровень. Средний уровень это десятки и сотни гигов логов одним файлом. А кошмарный уровень выражается в терабайтах, что раскиданы по куче разным S3 по папкам и архивам.
Во-первых нужно нормально формировать логи. Прозвучит странно, но 80% работы с разбором логов начинается с формализации логера и встраивания нормального настроенного четко под вас логера с строгими правилами как и где логируется, с какими уровнями и метками.
Во вторых уровни логирования. Для рантайм вывода хватит и ERR-уровня или даже вообще выключить (но лучше что бы было, логов много не бывает). Для потокового пишущего логера достаточно INF-уровня. А если нужно и можно (ресурсы) то фоново пишутся в файлы по DBG-уровню причем сразу уже с архивацией, ротацией по размеру и очисткой по переполнению и дате.
Кажется что 2 и 3 это одно и тоже, но это не так. Существует огромное количество нормальных агрегаторов логов, которые созданы что бы с минимумом оверхеда хранить и индексировать логи. Лично я в работе использую Loki в связке с метриками, но никто не запрещает использовать что-то другое. Самое главное в таком подходе что логи будут лететь сразу на агрегатор в базу, а не в какой-то текстовый файл с которого потом парсить (хотя Loki может и так, причем в рантайме). Особенно такой подход оцените при множестве источников логов (микросервисы или распределенная архитектура) и/или когда нужно проанализировать данные за огромный период (месяцы и года) и/или огромный массив (миллиарды точек и терабайты логов)
Тонкость в том что на агрегатор летит именно по INF. Не прям все, особенно если логи нормально описаны, но все же достуточно что бы отслеживать и детектить проблемы. А если же реально возник форсмажор то всегда есть дебаг-логи которые хранятся на месте всего за месяц или неделю, но которые максимально полные. Одна консольная команда (или прямо в каком-то интерфейсе) и мы загружаем эти логи в наш агрегатор что бы с ними работать как привыкли.
Всегда когда возникает какая-то проблема, особенно если эта проблема частая, стоит погуглить как с ней воюют другие (и проблема ли это вообще - "верх запаян, дна нет"). Возможно уже давно есть решение этих проблем. Решение которое проверенно временем и уже предвосхищает не только данную проблему но и те что возникнут потом в будущем.
протобаф это много что. gRPC это просто вишенка на торте. В первую очередь это стандартизированный и главное вылизанный формат бинарного обмена данными. Ваш пример с 0 некорректен ведь если нужно строго то можно прямо указать что бы генерировались все значения даже отсутствующее рамках языка, нужно определять пустоту - ссылка или массив из простого.
Из прото-схем потом можно и в json и в какой угодно другой формат без головняка, для проприоретаршины же нужно писать и поддерживать специальные методы под это
Вылизаность стандарта - как много всего в этом термине. Простое склеивание бинарных данных чревато множеством интересных вещей, особенно если данные являются разным типом. С протобафами же не переживаешь ни за разрядность, ни за правильный порядок, ни за миграцию схем, и прочее прочее.
"распознание в замусоренных потоках" очень странное требование, но окей, с прото можно так же, причем сам прото имеет механизм oneof что бы удобно прямо в рамках протобафа определять подходящий обьект если получаешь на чтение просто какой-то обьект. А если без oneof то тогда только руками проверять, но отделить прото-обьект в производном потоке можно без проблем потому как у протобафа тоже есть стандартная сигнатура)
Префильтрация это немного другая задача. Я не знаю может ли протобаф сам что-то с этим делать потому что мне никогда не нужно было, но эта задача решается так же как и с любым другим способом разметки данных и фильтрации в потоке: определяем начало нужной сигнатуры >> ищем совпадение >> помечаем сигнатуру как игнорируемую если совпадения нет (или наоборот)
Даже сам создатель протобафа согласен что он не является святым граалем (и пилит свои "улучшенные костыли" которые до сих пор даже из альфы не вышли) но стандартизация на то и существует что б упрощать жизнь как себе, так и тем кто будет после тебя. Протобаф не только проверен и вылизан максимально, но еше имеет и огромную кучу вещей построенных вокруг него, начиная от не-гугловских генераторов/сигнализаторов (по разнообразным причинам) и заканчивая либами и поддержкой сторонними приложениями.
Из интереса закопался в исходный код (интересен сам алгоритм) и по состоянию на последний коммит f4228c5 вот список вопросов/фактов
не совсем понятно почему не запаковалось это все в динамические библиотеки (dll/so) раз уж начали делать интеграции, вместо этого неочевидный cli который еше может дрейфовать если продукт будет развиваться
не совсем понял за фишку с "смешанным потоком", я думал там что-то по типу "размазывания шума" что бы сами данные не были видны (очень актуально сейчас), но там классическая классика с сигнатурой+crc
так же вообще не понял за механику хранилища, я думал то такой странный кольцевой буфер для асинхронных ридеров, даже неронку зарядил на анализ, но оказалось что это просто хранилище? Зачем вшитое хранилище в потоковый криптопротокол? И я не увидел никаких ограничений на память при запуске (как параметр) то есть вполне можно убивать удаленные машины просто забив память отсылая пустые данные этим протоколом
подозрительно встречающиеся unsafe, для такой задачи (учитывая что никакой магии с байтами я не заметил) это очень похоже на костыли которые воткнули "чтоб работало" что в разрезе криптопротокола интересно смотрится, особенно если добиться колизии адресов при перезапуске тулзы(где в основном unsafe и юзается)
уязвимость прямо из учебника - берется len из полученного пакета и по этому len сразу резервируется память. Как минимум крашнуть тулзу можно и вызвать потери пакетов, как макс память выделится на всю оперативку и комп зависнет (никаких ограничений в рамках самой тулзы на лимиты памяти нет, напомню)
таки я был не прав и сделано нормально с симетричным на тело и асиметричным на обмен, но как же оно сделано! Ротация ключей сделана на лимите. Я искал другие механизмы начиная от принудительного рукопожатия по требованию и заканчивая сбросом лимита по условиям (размер, частота битости, иное) но такого нет, строго лимит и все.
в продолжение вышеперечисленного - шифрование ничего не гарантирует и ни от чего не защищает. Я выше писал что распознание по сигнатуре+CRC и это не опечатка - используется не префикс и даже не правило чтоб не палится с префиксом, а тупо тело. Незашифрованное хочу заметить тело (перепроверил нейросетью, метаданные гарантировано не шифруются)
Резюмируя - как учебный проект на поиграться очень топово и разнопланово. Все мы таким занимались когда-то в своей жизни если программирование действительно интересно.
Но как реально используемый проект/алгоритм под вопросом потому что я даже не могу придумать где такое можно было бы использовать что бы оно было прямо таки преимуществом и/или в тему.
TLS - просто существует
Как ученическая работа на поковырять и посмотреть ваш проект хорош. Даже векторы затронули, что не каждый из тех кто играется с созданием своей криптографии делает.
Но вот как "боевое использование" какие преимущества от такой проприоретаршины? На глаз Я бы не сказал что она будет быстрее классики, я бы даже сказал что наоборот если я правильно понял и вы все end-to-end в RSA пакуете. За безопасность тоже под вопросом, хотя тут я не специалист может и не прав.
У меня сразу вопрос почему производная от SHA256 а не тот же BLAKE3?
зашел за картинкой в превьюхе, а ее тут нет(
а вообще джуны сейчас маскируются под мидлов (что не так уж и сложно, ведь прохождение собеседований это совершенно другая дисциплина) потому прям реальных джунов которые говорят что они джуны мало (потому как они понимают всю тленность бытия еше в первый месяц поиска работы)
уже неоднократно с таким сталкивался в наеме за последние два года
WhyDNS - строго для страниц-пояснений что бы люди и агенты могли удобно искать о чем вообще этот ресурс