А, всё правильно. Он в отдельной ветке SDF, плюс я не успел новый класс внутрь fontrender-а засунуть.
Резервный шрифт устанавливает операционная система. Надо либо делать свой движок рендеринга ttf, что довольно хлопотно, либо поискать как в ОС поменять резервный Arial на какой-то другой (в linux, например, за это fontconfig отвечает).
Не стоит также игнорировать экспорт кернинг-пар — в экзотических шрифтах отсутствие кернинга ой как заметно.
Минутку, в UBFG ведь есть встроенный Distance Field!
Да, есть. Но результат получается заметно хуже. Возможно в обновлениях авторы UBFG это поправят.
Странно. Раньше в алгоритме были ошибки и приближенное вычисление SDF, но в последнем коммите я пытался поправить SDF-генератор и вроде бы он не уступает по качеству BruteForce (см. тест, PSNR > 70 дБ).
Реализация PHP слишком хитрая — там читерство с потоками и она запутаннее, чем js. Найдётся умелец, который перепаяет js на потоки и расстановка сил снова изменится. А вообще в тесте соревнуются в скорости pcre-движков, только и всего, и учитывая что многие используют libpcre — разница Python, PHP и C++ должна быть минимальна. Аналогично, там есть тест с числом пи, где по сути сравнивают производительность очень оптимизированной библиотеки gmp саму с собой, которая написана, к слову, на Си и ассемблере.
Но делать такие далеко идущие выводы на основе самого сомнительного бенчмарка (там ключевое слово — game)...
Зато желающие могут поупражняться в сравнении разных реализаций регулярок — те же peg попробовать или генератор парсеров yacc, который оттранслирует все выражения в чистый сишный код и лишь компилятор ему судья.
Попробуйте ещё yad — это форк Zenity, но более продвинутый и устраняет многие недостатки Zenity. Но главное — можно делать практически произвольные формы.
Для проверки качества пароля используйте cracklib-check, она умеет сообщать вид «слабости» пароля, используется в стандартном PAM:
$ cracklib-check <<< 123
123: it is WAY too short
Для отправки уведомлений можно использовать notify-send, там багов таких нет.
Разработчики Transmission уже выпустили патч, удаляющий червяка. Ещё пару дней назад. Ну и регулярные бекапы + подписка на oss-security сделают вашу жизнь чуть более скучной:) Присоединяюсь к предыдущему вопросу о пути проникновения червя в подписанный инсталлятор на офф. сайт разработчика.
Выглядит очень интересно, хотя я и привык к shutil и простой обертке над subprocess, но никогда не писал на питоне то, для чего шелл подошёл бы лучше. Из статьи непонятно, умеет ли библиотека делать конвейер? Ведь шелл-простыни зачастую намного сложнее, что-то вроде такого:
while read a b c; do
grep $(sed s/1/2/ <<< $a) ... && some_command || error_handler
done <(find ... | grep ... | tr ... | sort -u)
В "нормальных" языках как раз часто не хватает главной фичи юникс-вея — конвейеров и всех тех непонятных штук, которые знакомы администраторам 50-го уровня:).
P. S. Интересно, кто-нибудь подсчитывал, сколько в приведённых трёх строчках шелла строк кода на Си (ну ладно, хотя бы на Питоне). Естественно, если делать по-честному, не прибегая к вызову system.
Пользуясь случаем, сообщу, что runexe по ссылке мертва, а ещё меня терзают смутные сомнения, что я смогу повторить запуск этих тестов, например, на power.
Я немного не об этом. Нельзя загрузить этот код, выполнить make и получить такую же табличку, верно? У меня есть возможность протестировать код на совершенно разных машинах, но нет времени его детально изучать. Но по крайней мере я выяснил, что ваш код считает время пустого цикла:) Быстрый взгляд показывает, что в программе не хватает интерфейса чтобы прогнать все тесты разом.
Именно поэтому код следует выложить на GitHub, так как его ещё дорабатывать и дорабатывать. Чтобы не считать время пустого цикла я использовал разворот цикла на 8, после чего время, затрачиваемое на перебор значений, стало ничтожно мало.
> гарантированно пройдя по всем значениям
А почему цикл от 0 до N не пройдёт гарантированно все значения?
> чтобы компилятор вообще не удалил цикл за ненадобностью
есть volatile.
Но хабр не для Pull Requesto-в. А про гитхаб уже сказали.
POPCNT не будет использоваться, если не указать флаг -msse4.2, что означает либо компиляцию под определённую платформу либо шаманство с weak-функциями и потеря производительности на вызове функции. Если это узкое место, то нужно отдельно компилячить кучу версий — одну для sse4.2, одну для sse4.1… и так до sse2 который гарантированно поддерживается для 64-разрядной архитектуры.
К сожалению представленные на ЯД исходники не позволяют мне проверить все варианты, так как я не понял, что с ними нужно делать. Могу сказать только, что на i5 __builtin_popcount выдаёт 0.1 сек для 100000000 итераций с типом int для sse4.2 и 0.3 сек без него. На Xeon паршивый результат даже с sse4.2 — 0.25, без sse — 2 секунды. На core i7 лучший результат — 0.08 сек. На power хоть и есть инструкция popcntw, но её результат тоже не впечатляет — 0.3 сек.
А учитывалось ли в Java-тестах то, что на Intel она использует JIT-компилятор, который по понятным причинам не поддерживает платформу Эльбрус? Тогда стократная разница — это нормальная разница интерпретатора и JIT. На эльбрусах Java будет не быстрее питона:)
Всё в порядке, уязвимость присутствует. Вообще баг не относится к какому-то конкретному браузеру — утекают изображения из офиса, просмотрщиков изображений и прочее, прочее.
Проверил на разных машинах. В драйвере 358 пофикшено, в 352 ещё не пофикшено (с помощью этой программы можно получить остаточные буферы памяти). В драйверах Intel и VESA проблемы нет.
Если я правильно понял, то эта оптимизация имеет отношение к блоку clearMemory, но не readpixels, к тому же автор оставил блок clearMemory опциональным. Мне же было интересно сохранить весь дамп VRAM для последующего изучения. Есть вероятность что драйвер «оптимизировал» также и чтение из только что аллоцированного пустого блока. Наверное, стоит попробовать рисовать небольшой прямоугольник поверх этого буфера, чтобы драйвер пометил его как «грязный». Попробую ещё потестить с разными драйверами.
Разве непривилегированное приложение может слить дамп ОЗУ на современных ОС? Тут же речь о том, что любой Вася может даже под другим юзером запустить эту программу и увидеть содержимое вкладок браузера другого пользователя или ещё чего интересное. Вот здесь более развёрнуто.
В современных операционных системах принято занулять память перед тем как отдать её приложению. Это это очень хорошо, так как при выполнении malloc «мусор» в буфере окажется мусором освобождённой памяти текущего приложения, а не какого-то другого. Зануление при освобождении, как правило, не происходит (в угоду производительности) и используется на параноидальных сборках ядра Linux с патчами PAX/Grsecurity.
Я на скорую руку переписал тест автора бага на Си: github.com/scriptum/vmem_test (go активно отказывался компилироваться). Проверил на двух драйверах под Linux: nouveau и nvidia 358.16. В драйвере nouveau эффект присутствует (да какой — данные сохраняются даже после перезагрузки), в случае же с последним актуальным проприетарным драйвером nvidia 358.16 — возвращается чёрный экран.
Достаточно обратиться к /dev/mem по известному из вывода утилиты «lspci» офсету.
Это очень плохая «фича». Я очень рад, что моя система запрещает обращаться к /dev/mem не только кому попало, но и руту. Так, на всякий случай.
Проблема в том, что непривилегированный процесс, используя штатные механизмы (в данном случае — запрос видеобуфера из памяти через OpenGL), может получить данные, которые ему не принадлежат.
А, всё правильно. Он в отдельной ветке SDF, плюс я не успел новый класс внутрь fontrender-а засунуть.
Резервный шрифт устанавливает операционная система. Надо либо делать свой движок рендеринга ttf, что довольно хлопотно, либо поискать как в ОС поменять резервный Arial на какой-то другой (в linux, например, за это fontconfig отвечает).
Не стоит также игнорировать экспорт кернинг-пар — в экзотических шрифтах отсутствие кернинга ой как заметно.
Странно. Раньше в алгоритме были ошибки и приближенное вычисление SDF, но в последнем коммите я пытался поправить SDF-генератор и вроде бы он не уступает по качеству BruteForce (см. тест, PSNR > 70 дБ).
Реализация PHP слишком хитрая — там читерство с потоками и она запутаннее, чем js. Найдётся умелец, который перепаяет js на потоки и расстановка сил снова изменится. А вообще в тесте соревнуются в скорости pcre-движков, только и всего, и учитывая что многие используют libpcre — разница Python, PHP и C++ должна быть минимальна. Аналогично, там есть тест с числом пи, где по сути сравнивают производительность очень оптимизированной библиотеки gmp саму с собой, которая написана, к слову, на Си и ассемблере.
Но делать такие далеко идущие выводы на основе самого сомнительного бенчмарка (там ключевое слово — game)...
Зато желающие могут поупражняться в сравнении разных реализаций регулярок — те же peg попробовать или генератор парсеров yacc, который оттранслирует все выражения в чистый сишный код и лишь компилятор ему судья.
Для проверки качества пароля используйте cracklib-check, она умеет сообщать вид «слабости» пароля, используется в стандартном PAM:
Для отправки уведомлений можно использовать notify-send, там багов таких нет.
В "нормальных" языках как раз часто не хватает главной фичи юникс-вея — конвейеров и всех тех непонятных штук, которые знакомы администраторам 50-го уровня:).
P. S. Интересно, кто-нибудь подсчитывал, сколько в приведённых трёх строчках шелла строк кода на Си (ну ладно, хотя бы на Питоне). Естественно, если делать по-честному, не прибегая к вызову system.
Именно поэтому код следует выложить на GitHub, так как его ещё дорабатывать и дорабатывать. Чтобы не считать время пустого цикла я использовал разворот цикла на 8, после чего время, затрачиваемое на перебор значений, стало ничтожно мало.
> гарантированно пройдя по всем значениям
А почему цикл от 0 до N не пройдёт гарантированно все значения?
> чтобы компилятор вообще не удалил цикл за ненадобностью
есть volatile.
Но хабр не для Pull Requesto-в. А про гитхаб уже сказали.
К сожалению представленные на ЯД исходники не позволяют мне проверить все варианты, так как я не понял, что с ними нужно делать. Могу сказать только, что на i5 __builtin_popcount выдаёт 0.1 сек для 100000000 итераций с типом int для sse4.2 и 0.3 сек без него. На Xeon паршивый результат даже с sse4.2 — 0.25, без sse — 2 секунды. На core i7 лучший результат — 0.08 сек. На power хоть и есть инструкция popcntw, но её результат тоже не впечатляет — 0.3 сек.
Я на скорую руку переписал тест автора бага на Си: github.com/scriptum/vmem_test (go активно отказывался компилироваться). Проверил на двух драйверах под Linux: nouveau и nvidia 358.16. В драйвере nouveau эффект присутствует (да какой — данные сохраняются даже после перезагрузки), в случае же с последним актуальным проприетарным драйвером nvidia 358.16 — возвращается чёрный экран.
Это очень плохая «фича». Я очень рад, что моя система запрещает обращаться к /dev/mem не только кому попало, но и руту. Так, на всякий случай.
Проблема в том, что непривилегированный процесс, используя штатные механизмы (в данном случае — запрос видеобуфера из памяти через OpenGL), может получить данные, которые ему не принадлежат.
Тогда if не нужен. Ну и пользователи не-bash, скорее всего, будут ругаться.
Или даже такие: