Ну если всё до сих пор хорошо — то хорошо.
Если что — о проблемах можно писать. Эффективнее будет в issues на github — я их лучше получаю, чем уведомления отсюда.
Кстати сейчас от такого mitm и https не спасёт, без дополнительных средств вроде привязки к сертификату в заголовке и/или мониторинга в реальном времени выпущенных сертификатов.
точно так же можно подменить DNS-ответы для сервера lets encrypt, получить их сертификат.
Потом уже атаковать DNS-сервер провайдера/клиента чтобы встроится посередине с сертификатом Let's encrypt. Тогда и клиент увидит валидный сертификат и браузер паниковать не будет и трафик будет прослушан.
Мне кажется потери гитлаб неприятны, но врядли для кого то критичны.
и даже если бы коммиты за сутки потеряли — тоже неприятно, но в большинстве случаев не критично, т.к. они есть у разработчиков на локальных машинах.
кроме того надо делать скидку на то что gitlab.com полностью бесплатный сервис, фактически просто публичная демка enterprise решения, а пользователи с т.з. бизнеса там нужны для рекламы и для массового тестирования этого платного продукта.
и с этим учетом 6 часов данных не очень большая потеря.
к тому же это потеря из за ошибок админа, а не бага в продукте, так что врядли это повлияет на отношение к гитлаб как к системе.
В смысле чтобы я на тестовой виртуалке сделал ту же конфигурацию что у вас, запустил расширение и гарантировано получил сломанную таблицу (ну или с большой долей вероятности).
От fdisk тут зависимости нет — с таблицей разделов я работаю напрямую на диске.
Ошибки про loop-девайсы это номально, они ни на что не влияют. Ошибки в первом выводе это про то что ядро не смогло распознать увеличение нижележащего раздела без ребута и не получается PV сразу расширить, т.е. тоже ничего страшного.
рекламировать основной, а там когда есть проблемы делать рассылку, что тормоза связаны с ограничениями телеграм. Можно оставаться тут с тормозами или регнуться в таком-то боте где места есть и всё быстро.
база к телеграму отношения не имеет — бот это самостоятельная программа, которая рассылает/принимает сообщения через апи, т.е. база, файлы и всё остальное — это на откуп разработчика.
1. По практике — насколько можно пользоваться EAP версиями в работе — т.е. будет ли это вылет каждые полчаса или это косметические неудобства и сильно ли на данном этапе отличается от плагина (т.е. уже есть то что на сайте описано или это еще планы)?
2. Будет ли развиваться плагин или работа над ним останавливается и дальше всё вливается только в новую IDE?
Я на всякий случай себе анализаторы и инструкцию скачал и сохранил. Вдруг завтра (или когда еще анализатор потребуется) точка зрения у разработчика будет другое и доступного варианта лицензирования не будет вообще. Тогда можно будет сохранённой версией воспользоваться.
Системы патчей сейчас вполне умеют применять патчи в примерно похожие файлы — т.е. сдвиг на несколько строк для них не проблема — равно как и для человека: при разборе ошибки обычно есть не только номер строки, но и какой-то контекст по которому ± 3 строки вполне ищутся. Собственно так же как при изменении самого файла при штатном редактировании — потом всплывает баг и номера строк вполне могли немного уехать.
Информация собранная людьми становится незначительно менее качественной — строки всё равно плывут и вроде никто не следит за тем чтобы после коммита сохранялись номера строк.
Я не исключаю вероятности что в большом проекте при огромном числе изменений (даже таком синтаксически нейтральном) может быть какая-то непредвиденность, однако я бы тут оценивал не возможные проблемы из-за коммита
трех бесполезных строк в кучу файлов
а возможные проблемы vs выгода от получения инструмента с ценником если не изменяет память — несколько тысяч долларов.
т.е. если инструмент не нужен — то и возможные проблемы от коммита не нужны
если нужен — то соответственно сравнивать степень риска/пользы с выгодой от инструмента, а не с бесполезными изменениями в файлах.
Отличный вариант.
Мне особенно понравился критерий бесплатности: по сути клиент сам решает будет ли он пользоваться платной версией или бесплатной.
Большие организации скорее всего действительно купят, т.к. они явно не индивидуальный проект и тут может сработает бюрократия, может внутренний имидж + нужна поддержка и т.п.
В конце концов большие предприятия и redhat покупают просто из-за поддержки, даже без доп. условий хотя есть бесплатный centos/oracle — точно такие же но без поддержки.
А те, кто будут пользоваться бесплатной версией скорее всё равно всё равно бы никогда анализатора не купили.
Скачал для интереса исходники с
svn://svn.reactos.org/reactos/trunk/reactos
файлов там 19 тыс (50 тыс. это видимо посчитались служебные файлы внутри .svn), а *.c* — файлов 7063 — примерно 1.1Мб изменений.
У вас используется SVN, он хранит и пересылает только изменения (подозреваю что в сжатом виде).
Комментарий
// This is an open source non-commercial project. Dear PVS-Studio, please check it.
// PVS-Studio Static Code Analyzer for C, C++ and C#: http://www.viva64.com
занимает 160 байт. Для 50000 файлов получается около 8Мб несжатых изменений. Даже без учета сжатия для EDGE и тарифов порядка $1/мб трафик вполне подъемный.
добавка — теперь в один сертификат можно записать домен и его поддомены. По умолчанию сертификат выписывается сразу для поддомена www, т.е. для domain.com и www.domain.com в одном сертификате.
Ну если всё до сих пор хорошо — то хорошо.
Если что — о проблемах можно писать. Эффективнее будет в issues на github — я их лучше получаю, чем уведомления отсюда.
Странные у вас контакты какие-то.
точно так же можно подменить DNS-ответы для сервера lets encrypt, получить их сертификат.
Потом уже атаковать DNS-сервер провайдера/клиента чтобы встроится посередине с сертификатом Let's encrypt. Тогда и клиент увидит валидный сертификат и браузер паниковать не будет и трафик будет прослушан.
Мне кажется потери гитлаб неприятны, но врядли для кого то критичны.
и даже если бы коммиты за сутки потеряли — тоже неприятно, но в большинстве случаев не критично, т.к. они есть у разработчиков на локальных машинах.
кроме того надо делать скидку на то что gitlab.com полностью бесплатный сервис, фактически просто публичная демка enterprise решения, а пользователи с т.з. бизнеса там нужны для рекламы и для массового тестирования этого платного продукта.
и с этим учетом 6 часов данных не очень большая потеря.
к тому же это потеря из за ошибок админа, а не бага в продукте, так что врядли это повлияет на отношение к гитлаб как к системе.
А это можно как-то воспроизвести?
В смысле чтобы я на тестовой виртуалке сделал ту же конфигурацию что у вас, запустил расширение и гарантировано получил сломанную таблицу (ну или с большой долей вероятности).
От fdisk тут зависимости нет — с таблицей разделов я работаю напрямую на диске.
Ошибки про loop-девайсы это номально, они ни на что не влияют. Ошибки в первом выводе это про то что ядро не смогло распознать увеличение нижележащего раздела без ребута и не получается PV сразу расширить, т.е. тоже ничего страшного.
1. По практике — насколько можно пользоваться EAP версиями в работе — т.е. будет ли это вылет каждые полчаса или это косметические неудобства и сильно ли на данном этапе отличается от плагина (т.е. уже есть то что на сайте описано или это еще планы)?
2. Будет ли развиваться плагин или работа над ним останавливается и дальше всё вливается только в новую IDE?
Я на всякий случай себе анализаторы и инструкцию скачал и сохранил. Вдруг завтра (или когда еще анализатор потребуется) точка зрения у разработчика будет другое и доступного варианта лицензирования не будет вообще. Тогда можно будет сохранённой версией воспользоваться.
Информация собранная людьми становится незначительно менее качественной — строки всё равно плывут и вроде никто не следит за тем чтобы после коммита сохранялись номера строк.
Я не исключаю вероятности что в большом проекте при огромном числе изменений (даже таком синтаксически нейтральном) может быть какая-то непредвиденность, однако я бы тут оценивал не возможные проблемы из-за коммита
а возможные проблемы vs выгода от получения инструмента с ценником если не изменяет память — несколько тысяч долларов.
т.е. если инструмент не нужен — то и возможные проблемы от коммита не нужны
если нужен — то соответственно сравнивать степень риска/пользы с выгодой от инструмента, а не с бесполезными изменениями в файлах.
Мне особенно понравился критерий бесплатности: по сути клиент сам решает будет ли он пользоваться платной версией или бесплатной.
Большие организации скорее всего действительно купят, т.к. они явно не индивидуальный проект и тут может сработает бюрократия, может внутренний имидж + нужна поддержка и т.п.
В конце концов большие предприятия и redhat покупают просто из-за поддержки, даже без доп. условий хотя есть бесплатный centos/oracle — точно такие же но без поддержки.
А те, кто будут пользоваться бесплатной версией скорее всё равно всё равно бы никогда анализатора не купили.
svn://svn.reactos.org/reactos/trunk/reactos
файлов там 19 тыс (50 тыс. это видимо посчитались служебные файлы внутри .svn), а *.c* — файлов 7063 — примерно 1.1Мб изменений.
Так что мне кажется это не так страшно.
Комментарий
// This is an open source non-commercial project. Dear PVS-Studio, please check it.
// PVS-Studio Static Code Analyzer for C, C++ and C#: http://www.viva64.com
занимает 160 байт. Для 50000 файлов получается около 8Мб несжатых изменений. Даже без учета сжатия для EDGE и тарифов порядка $1/мб трафик вполне подъемный.