Вопрос, который меня мучает постоянно, когда приходится работать с большими числами - почему в стандартной библиотеке есть bigmath, но нет встроенного типа float128. В большинстве других языков он есть, а в go не хотят его вводить.
Весь проект не загружаем, 1М токенов (лимит джемини) много, но не для всего проекта. Можно подкинуть ему весь код через MCP сервер. Что то такое хотим сделать, но даже без всего кода результат очень и очень годный.
Мы реализовал у себя ревью бота на базе gemini 3 flash. Важный момент - помимо ПРа кормим ему ещё и кучу смежного контекста - саму задачу, смежные задачи, смежные ПРы, полные версии изменненных файлов, комменты к ПРу людей и тд. Так же нужно это все правильно разместить и снабдить правильными дескрипшенами, что бы модель чётко понимала что это за данные в контексте, насколько они достоверно и как их использовать.
Результат работы бота превосходит все ожидания. Мало того, что он достаточно умен, что бы находить обычные проблемы в коде - ошибки логики, проблемы производительности, архитектурный проблемы, так он ещё и указывает на несоответствие задачи и реализации. Не совместимости с другими изменениями ( например ПРы в 2 проекта с реализацией Апи и Апи клиентом. И имя параметра или поля отличается в них).
Точность комментов порядка 70-80%. Ещё 10-15% это в целом релевантные, но не важные комменты. Например придерается к лишним аллокациям или не очень оптимальному алгоритму в не горячем месте, где производительность совсем не важна. Совсем неверные комменты достаточно редкие, но тут вероятно очень зависит от качества модели. Есть еще gemeni 3 pro. И она вероятно даст результат ещё лучше но она в 5 раз дороже flash. Решили пока её не юзать. Оплата за токены копеечная, у нас выходит около $200 в мес на средних размеров компанию.
Так же очень решает качество системного промпт - у нас он порядка страницы а4. В нем подробно описано как боту проводить ревью, взаимодействовать с людьми и ещё куча всего.
Многие проблемы, которые находит бот люди вероятно бы не нашли глазами и оно уехало бы в прод. Но что важнее бот решает 90% типовых проблем и люди при ревью не проверяют наличие опечаток и типовых ошибок, вроде инверсий в булевой логике, а могут сосредоточиться на общей архитектуре и бизнес задаче. Так же выросло качество кода, который уходит на тестирование -> меньше доработок, быстрее процесс доставки до прода.
В планах добавить в контекст ещё и документацию по общей архитектуре продукта, архитектуре конкретного компонента, код стайлы и соглашения о типовых подходах и тд. В целом хорошая документация должна дать ревью боту следующий качественный скачек и лучше понимать что происходит в продукте, как эти измения будут влиять на другие компоненты и тд.
Ковырялся я недавно frr и с одной стороны крутая штука, а с другой есть много вопросов.
Мне необходимо было рулить frr программно, через какой то API. Нашёл в офф документации инфу о Northwood API через grpc. Выглядит отлично и даже сгенерировался клиент под GO. Но в процессе тыканья выяснил, что в АПИ методов раз два и обчелся и большая часть функционала не покрыта апи. +не получилось собрать yang модели(не особо пытался, т.к. OSPF все равно не покрыт ими)
Ок, решил работать через CLI. В офф доке есть инфа о transactional API для CLI, пробую его использовать и оно не работает (по крайне мере для ospf).
В общем чувства смешанные. Документация поверхностная, многие фичи не допилены.
Может это я что-то не понял и юзаю его неправильно?
Если кто поделится опытом как лучше работать с ним программно, то буду очень благодарен.
Возможно из-за веса, там каждые сотни грамм на счету, а манипулятор, которым можно оттолкнуться (достаточно длинный и сильный) видимо весит слишком много.
Есть сервисы, которые не умеют или не могут в LE, например потому что требуют wildcard сертификат, а его без доступа к DNS не получить.
Есть куча железок, куда сертификат надо заливать руками и никакого нормального API у них.
Есть внутреннии ресурсы, к которым нет доступа снаружи и нет доступа к DNS (или неподдерживаемый провайдер DNS) и на них нельзя автоматически выписывать сертификаты.
Наконец нет нормального софта по управлению и распространению сертификатов. Пока бложик на 1 компе все ок, а вот когда серверов десятки-тысячи приходится костылить свои решения, что бы выписывать на 1 сервере и распространять на другие.
И не понятно ради чего это делать - сертификаты воруют не так уж и часто и даже в случае кражи всегда есть возможность отозвать сертификат. Мошенники обычно не подделывают оригинальный сайт, т.к. помимо сертификата надо еще как то зароутить трафик на свой сервер вместо атакуемого, а регистрируют похожий домен и спокойно выписывают на него легитимный сертификат, причет обычно как раз LE.
Сейчас 2023, некоторые ноуты/материнки уже и не умеют грузится в легаси режиме.
Так что лучший сейчас подход - незашифрованный /boot, но подписанный инитрамфс + ядро Secure Boot + хранение части ключа в TPM. Ядро с инитрамфс пакуется в единое efi приложение и подписывается.
Это сделает невозможным скрытую модификацию бут раздела и сброс настроек UEFI для отключения secure boot.
Чтобы расположить пул на определенных ODS есть более простое решение — device classes (доступно если мне не изменяет память с 13 версии ceph). При создании OSD можно задать ему класс. По умолчанию у ceph 3 класса — hdd, ssd и nvme. Мы можем добавить OSD со своим классом, например hdd-slow или ssd-metapool. После этого мы создаем crush rule: ceph osd crush rule create-replicated replicated_hdd-slow default host hdd-slow
После этого создаем пул и назначаем ему crush_rule «replicated_hdd-slow». Все, пул будет располагаться только на OSD с указанным классом.
А планируются ли хоть что то из дорогих не игровых моделей на AMD? Сейчас на AMD в основном бюджетные игровые ноуты, а хочется что то типа XPS 15 — небольшой, с хорошим дисплеем, мощным процом и 16-32 RAM.
ИМХО, но если необходима многозадачность, то лучше взять нормальный язык программирования и написать логику на нем. В баше это реализовано ужасно и любой скрипт на 200+ строк и многопоточностью будет нечитаемой кучей кода. (Это не относится к xargs -P или parallel). Контроль кодов выхода, синхронизация потоков, доступ к общим данным. Конечно все это можно заколхозить на баше, но как сисадмин, я надеюсь, что мне не достанется такой подарок на поддержку.
Если в туннеле планируется движение не личных авто, а «общественных», то какой тогда смысл от машин в тоннеле? Просто потому что это тесла?
Небольшие электропоезда на 2-3 вагона перевезут намного больше пассажиров и сделают это быстро, безопаснее и с большим комфортом.
На крайний случай автобусы (можно тоже электрические).
Водород считается практически идеальным топливом, поскольку при сгорании он не выделяет вредных парниковых газов типа CO2 — только водяной пар.
Это относится только к сгоранию чистой пары кислород-водород. При горении водорода в воздухе все не так однозначно, т.к. образуются оксиды азота и другие соединения. И их образуется тем больше, чем больше температура горения, а у водородных ДВС она выше, чем у бензиновых.
Не зависит от дискового бэкенда. Диск может быть в LVM/ZFS/QCOW/NFS и тд.
Можно вместе со снапшотом делать дамп памяти. Актуально например для серверов БД (чтобы не повреждать ее).
В вашем случае добавляется еще и возможная неконсистентность XFS при снапшоте, а значит и QCOW образов на ней. В общем что-то вы конечно восстановите, но если приложению в госте критична консистентность данных, то можно напороться. В остальном ваш способ вполне подходит для резервного бэкапа.
Насчет надежности не скажу, у нас этот способ работает на паре машин, проблем не было. Но тут конечно стоит более масштабно протестировать.
А вы уверены, что lvcreate -s надежный?) Вы же сами написали про повреждение меты LVM.
Уверены, что у вас данные всех томов правильные и в какие то случайные сектора не записалась каша (например данные снапшотов)?
Спасибо, интересная ссылка.
Но я говорил о external snapshot, он не использует возможности QCOW, все операции со снапшотом делаются QEMU, можно снапшотить даже raw диски.
Почему не используете понятно.)
Не раскрыта тема того, что случилось с LVM VG. Почему оказалась повреждена мета?
Второй вопрос — почему вы не делаете снапшоты средствами QEMU (external snapshot)?
Вопрос, который меня мучает постоянно, когда приходится работать с большими числами - почему в стандартной библиотеке есть bigmath, но нет встроенного типа float128. В большинстве других языков он есть, а в go не хотят его вводить.
Весь проект не загружаем, 1М токенов (лимит джемини) много, но не для всего проекта. Можно подкинуть ему весь код через MCP сервер. Что то такое хотим сделать, но даже без всего кода результат очень и очень годный.
Мы реализовал у себя ревью бота на базе gemini 3 flash. Важный момент - помимо ПРа кормим ему ещё и кучу смежного контекста - саму задачу, смежные задачи, смежные ПРы, полные версии изменненных файлов, комменты к ПРу людей и тд. Так же нужно это все правильно разместить и снабдить правильными дескрипшенами, что бы модель чётко понимала что это за данные в контексте, насколько они достоверно и как их использовать.
Результат работы бота превосходит все ожидания. Мало того, что он достаточно умен, что бы находить обычные проблемы в коде - ошибки логики, проблемы производительности, архитектурный проблемы, так он ещё и указывает на несоответствие задачи и реализации. Не совместимости с другими изменениями ( например ПРы в 2 проекта с реализацией Апи и Апи клиентом. И имя параметра или поля отличается в них).
Точность комментов порядка 70-80%. Ещё 10-15% это в целом релевантные, но не важные комменты. Например придерается к лишним аллокациям или не очень оптимальному алгоритму в не горячем месте, где производительность совсем не важна. Совсем неверные комменты достаточно редкие, но тут вероятно очень зависит от качества модели. Есть еще gemeni 3 pro. И она вероятно даст результат ещё лучше но она в 5 раз дороже flash. Решили пока её не юзать. Оплата за токены копеечная, у нас выходит около $200 в мес на средних размеров компанию.
Так же очень решает качество системного промпт - у нас он порядка страницы а4. В нем подробно описано как боту проводить ревью, взаимодействовать с людьми и ещё куча всего.
Многие проблемы, которые находит бот люди вероятно бы не нашли глазами и оно уехало бы в прод. Но что важнее бот решает 90% типовых проблем и люди при ревью не проверяют наличие опечаток и типовых ошибок, вроде инверсий в булевой логике, а могут сосредоточиться на общей архитектуре и бизнес задаче. Так же выросло качество кода, который уходит на тестирование -> меньше доработок, быстрее процесс доставки до прода.
В планах добавить в контекст ещё и документацию по общей архитектуре продукта, архитектуре конкретного компонента, код стайлы и соглашения о типовых подходах и тд. В целом хорошая документация должна дать ревью боту следующий качественный скачек и лучше понимать что происходит в продукте, как эти измения будут влиять на другие компоненты и тд.
А почему не стали использовать VictoriaMetrics?
У неё потребление памяти намного ниже и разные полезные фичи есть.
Интересная статья, спасибо.
А что насчёт совместимости? Если клиент поддерживает только tls 1.1 то вы его реджектить или устанавливаете коннект без ktls?
RSA сертификаты как опцию поддерживаете, если клиент не умеет в ECDSA?
Ковырялся я недавно frr и с одной стороны крутая штука, а с другой есть много вопросов.
Мне необходимо было рулить frr программно, через какой то API. Нашёл в офф документации инфу о Northwood API через grpc. Выглядит отлично и даже сгенерировался клиент под GO. Но в процессе тыканья выяснил, что в АПИ методов раз два и обчелся и большая часть функционала не покрыта апи. +не получилось собрать yang модели(не особо пытался, т.к. OSPF все равно не покрыт ими)
Ок, решил работать через CLI. В офф доке есть инфа о transactional API для CLI, пробую его использовать и оно не работает (по крайне мере для ospf).
В общем чувства смешанные. Документация поверхностная, многие фичи не допилены.
Может это я что-то не понял и юзаю его неправильно?
Если кто поделится опытом как лучше работать с ним программно, то буду очень благодарен.
Переносили кластер, около 30 тб на ноду, нод много. Миграция в рамках одного региона, между ДЦ 10 Гбит и небольшой пинг.
Делали это стандартной репликацией КХ. ЗК выдали побольше ресурсов и все было ок.
Возможно из-за веса, там каждые сотни грамм на счету, а манипулятор, которым можно оттолкнуться (достаточно длинный и сильный) видимо весит слишком много.
Ужасное изменение.
Есть сервисы, которые не умеют или не могут в LE, например потому что требуют wildcard сертификат, а его без доступа к DNS не получить.
Есть куча железок, куда сертификат надо заливать руками и никакого нормального API у них.
Есть внутреннии ресурсы, к которым нет доступа снаружи и нет доступа к DNS (или неподдерживаемый провайдер DNS) и на них нельзя автоматически выписывать сертификаты.
Наконец нет нормального софта по управлению и распространению сертификатов. Пока бложик на 1 компе все ок, а вот когда серверов десятки-тысячи приходится костылить свои решения, что бы выписывать на 1 сервере и распространять на другие.
И не понятно ради чего это делать - сертификаты воруют не так уж и часто и даже в случае кражи всегда есть возможность отозвать сертификат. Мошенники обычно не подделывают оригинальный сайт, т.к. помимо сертификата надо еще как то зароутить трафик на свой сервер вместо атакуемого, а регистрируют похожий домен и спокойно выписывают на него легитимный сертификат, причет обычно как раз LE.
Конечно можно)
В любой UEFI за редким исключением, типа surface можно добавить свои ключи и Secure Boot прекрасно работает
Сейчас 2023, некоторые ноуты/материнки уже и не умеют грузится в легаси режиме.
Так что лучший сейчас подход - незашифрованный /boot, но подписанный инитрамфс + ядро Secure Boot + хранение части ключа в TPM. Ядро с инитрамфс пакуется в единое efi приложение и подписывается.
Это сделает невозможным скрытую модификацию бут раздела и сброс настроек UEFI для отключения secure boot.
ceph osd crush rule create-replicated replicated_hdd-slow default host hdd-slowПосле этого создаем пул и назначаем ему crush_rule «replicated_hdd-slow». Все, пул будет располагаться только на OSD с указанным классом.
Небольшие электропоезда на 2-3 вагона перевезут намного больше пассажиров и сделают это быстро, безопаснее и с большим комфортом.
На крайний случай автобусы (можно тоже электрические).
Это относится только к сгоранию чистой пары кислород-водород. При горении водорода в воздухе все не так однозначно, т.к. образуются оксиды азота и другие соединения. И их образуется тем больше, чем больше температура горения, а у водородных ДВС она выше, чем у бензиновых.
В вашем случае добавляется еще и возможная неконсистентность XFS при снапшоте, а значит и QCOW образов на ней. В общем что-то вы конечно восстановите, но если приложению в госте критична консистентность данных, то можно напороться. В остальном ваш способ вполне подходит для резервного бэкапа.
Насчет надежности не скажу, у нас этот способ работает на паре машин, проблем не было. Но тут конечно стоит более масштабно протестировать.
А вы уверены, что lvcreate -s надежный?) Вы же сами написали про повреждение меты LVM.
Уверены, что у вас данные всех томов правильные и в какие то случайные сектора не записалась каша (например данные снапшотов)?
Но я говорил о external snapshot, он не использует возможности QCOW, все операции со снапшотом делаются QEMU, можно снапшотить даже raw диски.
Почему не используете понятно.)
Второй вопрос — почему вы не делаете снапшоты средствами QEMU (external snapshot)?