На днях вышла новая версия аудио-кодека Opus 1.2. И на странице релиза упомянуто, что они провели дополнительное тестирование безопасности, в т.ч. с использованием "фаззинга". При этом существенных уязвимостей обнаружено не было. https://jmvalin.ca/opus/opus-1.2/
Я бы ещё добавил, что при ручном создании ~/.ssh/authorized_keys и папке, и файлу нужно обязательно правильно выставить права доступа.
700 для .ssh и 600 для authorized_keys
В противном случае сервер будет считать их скомпрометированными и не позволит использовать ключ для доступа.
А если по существу, у Log Navigator есть одно главное преимущество: аггрегация нескольких логов.
Например, с нескольких машин в кластере.
И при этом он ещё умеет тот самый "логротейт" распаковывать автоматически.
А как бы вы назвали поиск, который по запросу "don't ask base method" возвращает первыми записи, вроде "Gerrit support" и "Bad Gateway when using internal web server"?
Единственный способ добиться каких-то вменяемых результатов — это ограничивать выдачу различными фильтрами (Subsystem:..., by: me, etc.)
Из-за этой проблемы полнотекстовый поиск, по сути, бесполезен.
Я не могу нормально проверить, сообщили ли уже о каком-то дефекте, т.к. найденная запись даже со 100% попаданием во все ключевые слова может запросто оказаться на третьей странице результатов поиска.
Меня при пользовании двумя мониторами напрягало, когда курсор мыши "терялся". И стандартное решение — подёргать мышкой — не помогало его заметить. Потому что он, конечно же, был на другом экране.
А также нарушение "бесконечности размера" элементов на смежной границе обоих экранов.
Есть вот такой упрощённый способ набора формул, если не нужна полная мощь LaTeX: http://asciimath.org/
Работает через MathJax. Реализовать генерацию SVG на сервере для мобильных браузеров, наверное, будет сложнее.
Недавно прочитал статью The Day I Parsed A Monster. Статья об одной из трудностей, с которой столкнулись разработчики X-Ray при проверке .NET Core runtime.
Сама статья несколько раздута (а уж "решение" и вовсе не интересно — замена полноценного парсера десятком микро-грамматик для распознавания структурных единиц: условий, циклов и пр.). Но несколько моментов мне всё же показались интересными:
1) В ходе работы над X-Ray была найдена синтаксическая ошибка в gc.cpp. Я вижу, вы проверяли проекты .NET Core в декабре 2015. Но не смог найти, была ли в ваших отчётах эта ошибка? (я, правда, не очень силён в "топонимике" .NET Core: runtime — это то же самое, что CoreCLR? и если нет, не хотите ли проверить .NET Core runtime?)
2) Автор статьи сокрушается о "неподъёмной" сложности gc.cpp с его 37 тысячами строк кода. Как обстоят дела у PVS-Studio с обработкой файлов таких размеров?
3) Также интересной мне показалась идея отслеживать изменения в коде по логам системы контроля версий с тем, чтобы давать больший приоритет определённым участкам. Правда, это более актуально для анализа сложности, чем для поиска ошибок. Но, быть может, и вам будет интересно реализовать что-то подобное. Скажем, для запуска наиболее ресурсоёмких проверок (в первую очередь) на новых участках кода.
4) А ещё понравилась их диаграмма. Если сделать такую с диагностиками, можно будет одним взглядом оценить, насколько плохи дела в том или ином модуле.
5) Не думали ли вы сделать SaaS версию PVS-Sudio? Чтобы можно было указать ей URL открытого проекта на GitHub или BitBucket и (через какое-то время) получить отчёт.
Кстати, что касается stash, в Mercurial версии 2.8 и выше поставляется ShelveExtension. Как я понимаю, это тот самый stash и есть.
Для git add -i тоже есть аналог и без TortoiseHg. Раньше это было реализовано в RecordExtension. А сейчас уже есть "из коробки": hg commit --interactive
А про "легче переходить", скорее всего, обычно имеется в виду более согласованный синтаксис команд в Mercurial, в отличие от "полной анархии" в командах Git (см. мой комментарий ниже). Вряд ли на этапе перехода всплывают концептуальные нюансы использования веток.
Вот вам парочка идей в тему статьи.
Проект OpenVPN недавно прошёл целых два аудита кода. Однако, энтузиасты всё ещё находят уязвимости:
https://guidovranken.wordpress.com/2017/06/21/the-openvpn-post-audit-bug-bonanza/
На днях вышла новая версия аудио-кодека Opus 1.2. И на странице релиза упомянуто, что они провели дополнительное тестирование безопасности, в т.ч. с использованием "фаззинга". При этом существенных уязвимостей обнаружено не было.
https://jmvalin.ca/opus/opus-1.2/
Я бы ещё добавил, что при ручном создании ~/.ssh/authorized_keys и папке, и файлу нужно обязательно правильно выставить права доступа.
700 для .ssh и 600 для authorized_keys
В противном случае сервер будет считать их скомпрометированными и не позволит использовать ключ для доступа.
Рут, как таковой, не нужен. Но нужен разлоченный бутлоадер (от которого до рута уже один простой шаг).
А ещё есть zstd, который в 4 раза быстрее zlib при той же степени сжатия.
Вчера на Reddit про него прочитал :-)
А если по существу, у Log Navigator есть одно главное преимущество: аггрегация нескольких логов.
Например, с нескольких машин в кластере.
И при этом он ещё умеет тот самый "логротейт" распаковывать автоматически.
А как бы вы назвали поиск, который по запросу "don't ask base method" возвращает первыми записи, вроде "Gerrit support" и "Bad Gateway when using internal web server"?
Единственный способ добиться каких-то вменяемых результатов — это ограничивать выдачу различными фильтрами (Subsystem:..., by: me, etc.)
Скажите, а когда планируется исправить ситуацию с сортировкой результатов поиска?
https://youtrack.jetbrains.com/issue/JT-2392
Из-за этой проблемы полнотекстовый поиск, по сути, бесполезен.
Я не могу нормально проверить, сообщили ли уже о каком-то дефекте, т.к. найденная запись даже со 100% попаданием во все ключевые слова может запросто оказаться на третьей странице результатов поиска.
И чем он мне поможет, когда я смотрю на один экран, а курсор на другом?
Меня при пользовании двумя мониторами напрягало, когда курсор мыши "терялся". И стандартное решение — подёргать мышкой — не помогало его заметить. Потому что он, конечно же, был на другом экране.
А также нарушение "бесконечности размера" элементов на смежной границе обоих экранов.
В итоге нашёл вот такую штуку: http://dualmonitortool.sourceforge.net/dmt_cursor.html Пробую.
Вот моя подборка ссылок:
https://mynoise.net/
https://www.noisli.com/
https://noonpacific.com/
Первые две — "генераторы" (а-ля "звуки леса" или "напевы тибетских монахов").
Третья — раз в неделю обновляющийся "mix tape".
Есть вот такой упрощённый способ набора формул, если не нужна полная мощь LaTeX: http://asciimath.org/
Работает через MathJax. Реализовать генерацию SVG на сервере для мобильных браузеров, наверное, будет сложнее.
В контексте Version Control Systems > Diff & Merge — нет, насколько я могу судить.
Я настроил себе хоткеи:
Next Difference = Alt+Down
Previous Difference = Alt+Up
Accept Left Side = Alt+Right
Accept Right Side = Alt+Left
Простите за занудство, но не используют в русском оборот "размер проблемы". Точнее, используют, но с совсем другим смыслом.
В случае, если интересует только thread dump, можно воспользоваться вот этим скриптом на Python:
https://github.com/gidouin/hprof-tools
Ещё один оффтоп :-)
Недавно прочитал статью The Day I Parsed A Monster. Статья об одной из трудностей, с которой столкнулись разработчики X-Ray при проверке .NET Core runtime.
Сама статья несколько раздута (а уж "решение" и вовсе не интересно — замена полноценного парсера десятком микро-грамматик для распознавания структурных единиц: условий, циклов и пр.). Но несколько моментов мне всё же показались интересными:
1) В ходе работы над X-Ray была найдена синтаксическая ошибка в
gc.cpp
. Я вижу, вы проверяли проекты .NET Core в декабре 2015. Но не смог найти, была ли в ваших отчётах эта ошибка? (я, правда, не очень силён в "топонимике" .NET Core: runtime — это то же самое, что CoreCLR? и если нет, не хотите ли проверить .NET Core runtime?)2) Автор статьи сокрушается о "неподъёмной" сложности
gc.cpp
с его 37 тысячами строк кода. Как обстоят дела у PVS-Studio с обработкой файлов таких размеров?3) Также интересной мне показалась идея отслеживать изменения в коде по логам системы контроля версий с тем, чтобы давать больший приоритет определённым участкам. Правда, это более актуально для анализа сложности, чем для поиска ошибок. Но, быть может, и вам будет интересно реализовать что-то подобное. Скажем, для запуска наиболее ресурсоёмких проверок (в первую очередь) на новых участках кода.
4) А ещё понравилась их диаграмма. Если сделать такую с диагностиками, можно будет одним взглядом оценить, насколько плохи дела в том или ином модуле.
5) Не думали ли вы сделать SaaS версию PVS-Sudio? Чтобы можно было указать ей URL открытого проекта на GitHub или BitBucket и (через какое-то время) получить отчёт.
Чтобы получить кавычку "как часть строки", нужно заменить её на "слэш-кавычку". Т.е. должно быть двойное экранирование:
Replace("'", "\\'")
Алиасы для Git, кстати, можно задавать в настройках самого Git.
Некоторые интересные идеи есть, например, вот в этой статье — Human Git Aliases
P.S. Ваш алиас 'gbd' весьма опасен. Захотите вы запустить отладчик, а вместо этого нечаянно удалите ветку (да ещё и с -D)
Да, "сумбурная" пунктуация местами весьма напрягает.
Спасибо за подробный ответ.
Кстати, что касается stash, в Mercurial версии 2.8 и выше поставляется ShelveExtension. Как я понимаю, это тот самый stash и есть.
Для
git add -i
тоже есть аналог и без TortoiseHg. Раньше это было реализовано в RecordExtension. А сейчас уже есть "из коробки":hg commit --interactive
А про "легче переходить", скорее всего, обычно имеется в виду более согласованный синтаксис команд в Mercurial, в отличие от "полной анархии" в командах Git (см. мой комментарий ниже). Вряд ли на этапе перехода всплывают концептуальные нюансы использования веток.