Вышла (http://permalink.gmane.org/gmane.org.fsf.announce/2047) новая версия популярной утилиты для организации поиска данных в текстовых файлах - GNU Grep 2.15. В новой версии для значительного ускорения поиска при использовании опции "-P"  добавлена поддержка JIT-компилятора для perl-совместимых регулярных выражений (PCRE). JIT-компилятор включается автоматически, но требует сборки grep с библиотекой PCRE, поддерживающей данную возможность. Кроме того, в новой версии налажено корректное сопоставление многобайтовых символов пробела с масками "\s" и "\S" и устранена серия крахов, проявляющихся при работе с текстом и локалями в многобайтовых кодировках.

URL: http://permalink.gmane.org/gmane.org.fsf.announce/2047
Новость: http://www.opennet.me/opennews/art.shtml?num=38267

• Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,vitalif, 23:25 , 27-Окт-13
  • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Яйцассыром, 00:29 , 28-Окт-13
    • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,kurokaze, 12:13 , 28-Окт-13
      • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Яйцассыром, 12:51 , 28-Окт-13
        • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,kurokaze, 13:23 , 28-Окт-13
          • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Яйцассыром, 14:24 , 28-Окт-13
            • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 18:00 , 28-Окт-13
              • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Яйцассыром, 19:07 , 28-Окт-13
                • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 21:23 , 28-Окт-13
                • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 22:48 , 28-Окт-13
                  • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Яйцассыром, 00:45 , 29-Окт-13
                    • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 15:56 , 29-Окт-13
                    • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 19:19 , 29-Окт-13
  • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 23:02 , 28-Окт-13
• Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Xasd, 00:13 , 28-Окт-13
  • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Псевдоним, 01:38 , 28-Окт-13
    • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Xasd, 14:57 , 28-Окт-13
      • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,linux must __RIP__, 02:01 , 29-Окт-13
      • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Псевдоним, 13:43 , 29-Окт-13
        • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 16:18 , 29-Окт-13
  • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,pavlinux, 01:52 , 28-Окт-13
    • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Mr. Cake, 11:46 , 28-Окт-13
  • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Michael Shigorin, 02:47 , 28-Окт-13
    • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,AlexAT, 07:55 , 28-Окт-13
    • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,linux must __RIP__, 11:35 , 28-Окт-13
      • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 22:49 , 28-Окт-13
        • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,linux must __RIP__, 01:53 , 29-Окт-13
          • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 15:59 , 29-Окт-13
        • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Michael Shigorin, 14:04 , 29-Окт-13
    • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Xasd, 15:02 , 28-Окт-13
      • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 16:02 , 29-Окт-13
        • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Xasd, 00:54 , 03-Ноя-13
    • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,CSRedRat, 17:10 , 28-Окт-13
      • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 15:58 , 29-Окт-13
  • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 15:56 , 29-Окт-13
• Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,linux must __RIP__, 11:37 , 28-Окт-13
  • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Andrey Mitrofanov, 11:48 , 28-Окт-13
    • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,linux must __RIP__, 14:25 , 28-Окт-13
      • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Andrey Mitrofanov, 15:22 , 28-Окт-13
        • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,linux must __RIP__, 19:00 , 28-Окт-13
          • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 22:58 , 28-Окт-13
          • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Andrey Mitrofanov, 22:58 , 28-Окт-13
            • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,linux must __RIP__, 01:55 , 29-Окт-13
      • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 15:25 , 28-Окт-13
        • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,pavlinux, 16:54 , 28-Окт-13
          • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,linux must __RIP__, 19:02 , 28-Окт-13
            • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 22:56 , 28-Окт-13
              • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,linux must __RIP__, 01:56 , 29-Окт-13
          • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 16:04 , 29-Окт-13
    • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 18:03 , 28-Окт-13
      • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,linux must __RIP__, 19:04 , 28-Окт-13
        • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 16:05 , 29-Окт-13
          • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,linux must __RIP__, 18:24 , 29-Окт-13
      • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Andrey Mitrofanov, 23:01 , 28-Окт-13
        • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 23:03 , 28-Окт-13
  • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,kurokaze, 12:19 , 28-Окт-13
    • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,linux must __RIP__, 14:26 , 28-Окт-13
      • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,pavel_simple, 18:13 , 28-Окт-13
        • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,linux must __RIP__, 18:55 , 28-Окт-13
          • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,pavel_simple, 21:03 , 28-Окт-13
            • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Led, 00:35 , 29-Окт-13
            • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,linux must __RIP__, 01:58 , 29-Окт-13
              • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Andrey Mitrofanov, 07:54 , 29-Окт-13
                • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,linux must __RIP__, 11:51 , 29-Окт-13
            • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Michael Shigorin, 14:15 , 29-Окт-13
              • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,pavel_simple, 18:52 , 29-Окт-13
          • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Andrey Mitrofanov, 23:03 , 28-Окт-13
          • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 16:10 , 29-Окт-13
          • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 16:21 , 29-Окт-13
  • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 22:54 , 28-Окт-13
    • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,linux must __RIP__, 01:58 , 29-Окт-13
      • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 16:14 , 29-Окт-13
    • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 16:11 , 29-Окт-13
      • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Michael Shigorin, 19:38 , 29-Окт-13
• Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 12:15 , 28-Окт-13
  • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 22:59 , 28-Окт-13
  • Выпуск GNU grep 2.15 с поддержкой JIT-компиляции для PCRE-вы...,Аноним, 16:12 , 29-Окт-13

Ух ты. Я давно уже pcregrep юзаю, а они pcre оказывается в обычный запиливают O_o

есть еще oniguruma, которая быстрее, чем pcre
если уж нужна максимальная скорость лучше ее запилить

Regex: '.*fence.*'
[oniguruma] time:   220 ms (284 matches)
[ pcre-jit] time:   100 ms (284 matches)

что это за буквы и как они опровергают то, что oniguruma быстрее, чем pcre?

> что это за буквы

Это латинские символы и арабские цифры, странно что ты этого не знаешь

> и как они опровергают то, что oniguruma быстрее, чем pcre?

Первый же найденый бенчмарк как бы говорит нам о том, что ты лжешь

ясно, очередной тролляка.

а я тебе рассказываю не о бенчмарках, а о реальном программе, где юзаю около 30 намного более сложных регулярок(есть и относительно простые) и на каждом регэкспе oniguruma оказывалась лучшей. Кроме одного случая, где не требуется захват групп - там RE2 оказался быстрее всех.

Но я до сих пор держу движки boost, pcre, oniguruma, re2 и при добавлении нового выражения выбираю лучший, пока что oniguruma - 27, re2 - 1, pcre - 0, boost - 0

кстати вот нашел какой-то ьенчмарк там регэксп "a[^x]{20}b" - действительно pcre быстрее в 7 раз.

А вот для приведенного троллякой
".*fence.*":
re2 = 0.82s
boost = 3.22s
pcre = 2.37s
oniguruma = 2.30s

и для ".*(fence).*":
re2 = 24.11s
bost = 3.85s
pcre = 3.64s
oniguruma = 2.55s

Для тупых объясню еще один раз, последний:
>pcre = 3.64s
>oniguruma = 2.55s

а надо сравнивать с pcre-jit

тебе лишь бы ляпнуть? с чего ты решил, что я не использовал jit?

Потому что у тебя в посте про не го ни слова.

> тебе лишь бы ляпнуть? с чего ты решил, что я не использовал jit?

Потому что на приведенном регекспе (который .*fence.*) pcre-jit в ~2 раза быстрее, чем oniguruma.

ты это тестировал? на каких данных он быстрее?

> ты это тестировал? на каких данных он быстрее?

Ну вот вы например никакого JIT в вашем посте не упоминали, зато права качаете. Почему вы вашему оппоненту предъявляете, а себе то же самое - не хотите? Вам не кажется что это слегка двойные стандарты?

> ты это тестировал?

http://www.opennet.me/openforum/vsluhforumID3/92332.html#13

> Ух ты. Я давно уже pcregrep юзаю, а они pcre оказывается в обычный запиливают O_o

pcregrep - это особенность дебиановской сборки. Пакет grep - это обычный grep, но специально собранный без pcre.

а ведь на Windows_RT (и Apple_iOS) -- не поддерживается JIT?

Как напишешь транслятор, так и будет поддерживаться. Платформа здесь мало чем тебе помешать может.

> Платформа здесь мало чем тебе помешать может.

думаю проблема в специальном бите в оперативной памяти (Execute Disable Bit? или как там на ARM?) , который разрешает или запрещает выполнение машинных инструкций из области памяти.

разумеется виноват не сам бит -- а то как он испольуется в операционной системе :) ..

> Как напишешь транслятор, так и будет поддерживаться.

если только операционная система разрешит делать Memory Allocation с доступом на выполнение кода.

Linux -- разумеется разрешит! в Linux этот бит -- используется во благо :-)

>> Платформа здесь мало чем тебе помешать может.
> думаю проблема в специальном бите в оперативной памяти (Execute Disable Bit? или
> как там на ARM?) , который разрешает или запрещает выполнение машинных
> инструкций из области памяти.
> разумеется виноват не сам бит -- а то как он испольуется в
> операционной системе :) ..

я бы сказал то как написан компилятор. никто не мешает сделать трамлины не на стеке - но в тоже время они сделаны в gcc только там.

>> Как напишешь транслятор, так и будет поддерживаться.
> если только операционная система разрешит делать Memory Allocation с доступом на выполнение
> кода.
> Linux -- разумеется разрешит! в Linux этот бит -- используется во благо
> :-)

hint. трамплины в gcc - пока это будет существовать, на стек поставить NX бит нельзя.

> думаю проблема в специальном бите в оперативной памяти (Execute Disable Bit? или
> как там на ARM?) , который разрешает или запрещает выполнение машинных
> инструкций из области памяти.

Это вопрос одного вызова mprotect/VirtualProtect.

> Это вопрос одного вызова mprotect/VirtualProtect.

А кто сказал что вам собираются тебе позволять? Пометить область кода как readonly, а область данных как no execute - удачи в JIT.

> а ведь на Windows_RT (и Apple_iOS) -- не поддерживается JIT?

Java и .NET уже не работают на венде?

JVM на WinRT не заведётся, там нельзя самому вызывать VirtualProtect. Дотнетовский Reflection.Emit тоже порезали. Редиски, нехорошие люди.

> а ведь на Windows_RT (и Apple_iOS) -- не поддерживается JIT?

Дорогой, куда там так спешить?

Точнее - кому там спешить?

дорогой ты к себе не думал применять пункт правил о создании флуда?

> дорогой ты к себе не думал применять пункт правил о создании флуда?

Потому что к тебе его применять гораздо веселее. Ты так прикольно бугуртишь))

а как же не предвзятость модератора ?:)

> а как же не предвзятость модератора ?:)

Согласен, модераторы на этом ресурсе предвзятые. При непредвзятом рассмотрении твоей кандидатуры надо было стереть твои посты и забанить КЕМ. Вот это было бы по заслугам.

> Потому что к тебе его применять гораздо веселее.

Дело не в веселье, а в том, что мой ответ был техническим, но неуважаемый самозваный псевдооппонент оказался неспособен это уловить.

>> а ведь на Windows_RT (и Apple_iOS) -- не поддерживается JIT?
> Дорогой, куда там так спешить?

ды просто интересно.. не более того :-)

> ды просто интересно.. не более того :-)

Мне интереснее другое: ты и правда собираешься использовать GNU Grep на этом огороженном г@вне? А ты уверен что для начала владельцы платформы вообще позволят тебе такую блажь? И что ты там грепать собираешься? Там же огорожено все что только можно и нельзя. И JIT по той же самой причине зарублен - чтоб хомяк из своей лабораторной клетки ненароком не сбежал.

>> ды просто интересно.. не более того :-)
> Мне интереснее другое: ты и правда собираешься использовать GNU Grep на этом
> огороженном г@вне?

нет, не собираюсь :)

> А ты уверен что для начала владельцы платформы вообще
> позволят тебе такую блажь?

и мне это тоже интересно :-)

> И что ты там грепать собираешься?

хм... сказать трудно..

В iOS сознательно выпилено, недавно читал статью. Разобрались и нашли причины поступить по своему правильно. У Apple свой путь и это тоже хорошо, путей должно быть свободно много.

> путей должно быть свободно много.

Да, у Гитлера тоже свой путь был. Вот эппл чем-то таким напоминает - их путь тоже концлагерями попахивает, хоть и виртуальными.

> а ведь на Windows_RT (и Apple_iOS) -- не поддерживается JIT?

Тем хуже для WinRT и Apple iOS //ваш Капитан.

> устранена серия крахов, проявляющихся при работе с текстом и локалями в многобайтовых кодировках.

сколько из этих крахов можно использовать для атаки? берем подсовываем хлам в /var/log/messages и когда админ делает grep по логу... выполняем произвольный код..

Линуксоиды делают все что можно лишь бы прятать свои ошибки в безопастности...

> Линуксоиды делают все что можно лишь бы прятать свои ошибки в безопастности...

Ты бы пошёл, в новости об своей любовной freebsd, или кто там у тебя, поприбумывал заговоры. Ты же не объективен. Вот в новости про fbsd накакаешь -- поверю, всё взаправду.

на придумывал? да ну..

вот примерчик буквально недавний...

В Linux-утилите grep обнаружена опасная уязвимость (CVE-2012-5667), которая проявляется при обработке специально сформированного входного потока и может быть использована для инициирования отказа в обслуживании, а также, возможно, для выполнения произвольного кода. Подвержены выпуски утилиты grep до версии 2.11. В выпуске 2.11, вышедшем в начале марта 2012 года, эта уязвимость была исправлена, однако не было сделано никаких специальных анонсов о том, что ошибка имеет отношение к проблемам с безопасностью.

есть что сказать по теме? судя по новости в 2.15 еще одна тонна таких ошибок исправлена..

> на придумывал? да ну..

Докaжи, что ты
1. объективный, и гадшь во _все новости. Тебе же можно _верить_, да-а-а?
2. не тyпой, и понял, о чём я

Запости выжимку из (их! не перепутай) багтрекера в www.opennet.ru/opennews/art.shtml?num=38225

В своём обычном флyдo раcт ическом стиле, чтоб не меньше половины постов -- твои. И с теориями заговоров -- обязательно.

Ну?

>> на придумывал? да ну..
> Докaжи, что ты
> 1. объективный, и гадшь во _все новости. Тебе же можно _верить_, да-а-а?  
> 2. не тyпой, и понял, о чём я

тебе сколько лет что бы ловить на слабо? мне незачем самоутверждаться :) А ты боишся видимо расстаться с своим ореолом гуру? Ты не бойся никто твой уютный linux не обижает :) не стоит выпячивать свои комплексы наружу, как и некомпетентность.

> Запости выжимку из (их! не перепутай) багтрекера в www.opennet.ru/opennews/art.shtml?num=38225

зачем?  я такой мелочью не развлекаюсь. Вот ext4-devel более адекватно реагировал на тыканье в многолетние проблемы в linux-mm, и таки suse родил патчик.. А ты чего добился?

> В своём обычном флyдo раcт ическом стиле, чтоб не меньше половины постов
> -- твои. И с теориями заговоров -- обязательно.

да да :) а по теме сказать есть чего? считаешь что CVE-2012-5667 не применимо к этой новости?
Хочешь сказать что если grep падает в крэш от просмотра текста, то нельзя через syslog слить что-то такое что из-за чего grep упадет при обработке /var/log/messages? хочешь сказать что не одна из этих ошибок (исправленых в этом релизе) не может быть эксплуатирована как это было сделано в CVE-2012-5667 ?

ну так?

> тебе сколько лет что бы ловить на слабо? мне незачем самоутверждаться :)

Сказал человек, который уже не первый год самоутверждается, пытаясь гадить на других.
(Каковой способ самоутверждения люди обычно используют только при отсутствии альтернативных методов)

>> 2. не тyпой, и понял, о чём я
> тебе сколько лет что бы ловить на слабо? мне незачем самоутверждаться :)

п.2

> А ты боишся видимо расстаться с своим ореолом гуру? Ты не
> ну так?

Доказательство во весь рост по обоим пунктам. Засранец довольно неискренний, говорящий не то, что думает. Тупой - соскакиваюший без огонька, либо вообще не въехавший в вопрос.

Ну, давай, потряси ещё своими неискренники рев.шароварами с запахом рассказов о патчах Novel-а 1800-лохматого года. Ты же за Безопасность /bin/grep-а? По тебе _видно.

>>> 2. не тyпой, и понял, о чём я
>> тебе сколько лет что бы ловить на слабо? мне незачем самоутверждаться :)
> п.2
>> А ты боишся видимо расстаться с своим ореолом гуру? Ты не
>> ну так?
> Доказательство во весь рост по обоим пунктам. Засранец довольно неискренний, говорящий
> не то, что думает. Тупой - соскакиваюший без огонька, либо вообще
> не въехавший в вопрос.
> Ну, давай, потряси ещё своими неискренники рев.шароварами с запахом рассказов о патчах
> Novel-а 1800-лохматого года. Ты же за Безопасность /bin/grep-а? По тебе _видно.

спасибо посмешил. Так по теме сказать есть что? или переход на личности все что можешь предложить ?
а патчи - не 1800 года, а 3.10 или 3.11, не помню уж - да и не интересно было.

А тебе уважаемый кроме злости есть что сказать ?

A также возможно для вызова духа Наполеона и запуска ядерных ракет, да.

> A также возможно для вызова духа Наполеона и запуска ядерных ракет, да.

В ядре нет ракет!

>> A также возможно для вызова духа Наполеона и запуска ядерных ракет, да.
> В ядре нет ракет!

зато linux используют в том числе на кластерах которые производят расчеты по программе ядерного оружия США -> Sandia.gov с их кластером Cray XT. не помню какой именно там - года 4 назад был XT3 на catamount,  что сейчас стоит (в свете того что крей сказал что catamount больше нигде не используется) - не знаю.

> зато linux используют в том числе на кластерах которые производят расчеты по
> программе ядерного оружия США -> Sandia.gov с их кластером Cray XT.

... и расчеты эти сводятся исключительно к запуску grep из-под рута.

>> зато linux используют в том числе на кластерах которые производят расчеты по
>> программе ядерного оружия США -> Sandia.gov с их кластером Cray XT.
> ... и расчеты эти сводятся исключительно к запуску grep из-под рута.

grep из под рута там тоже используется :)

> В ядре нет ракет!

Безобразие! Ждем новую версию.

> про fbsd накакаешь -- поверю, всё взаправду.

Андгей ... а ви таки вправду не заметили что лет уж 5 как лапяатые рекомендуют срочно обновиться из за проблем безопасности ... не расскрывая суть проблемы? И чем они лучше любимого тут оракала? Изложите будьте любезны, мы Вас внимательно скушаем :)

>> про fbsd накакаешь -- поверю, всё взаправду.
> Андгей ... а ви таки вправду не заметили что лет уж 5
> как лапяатые рекомендуют срочно обновиться из за проблем безопасности ... не
> расскрывая суть проблемы? И чем они лучше любимого тут оракала? Изложите
> будьте любезны, мы Вас внимательно скушаем :)

не разрывай шаблон человеку... Плохим может быть только Oracle, FreeBSD (оскорбляющая всех своей BSDL) и тп.. а в FSF только святые (не забываем что grep развивается под патронажем GNU/FSF).

> что grep развивается под патронажем GNU/FSF).

Отлично. Он развивается и в нем полезная фича появилась. С чего вдруг такой сказочный батхерт? :)

у вас? я лишь напомнил что в новости забыли указать на проблемы с безопастностью...

> как лапяатые рекомендуют

Прожуй, потом говори.

>> как лапяатые рекомендуют
> Прожуй, потом говори.

Если он начнет жевать то, что держит во рту - получит сапогом по морде. И поделом.

> сколько из этих крахов можно использовать для атаки?

Т.е. ты как бы сам не знаешь, но ляпнуть чепуху очень хочется? Передерг отмечаем

> Линуксоиды делают все что можно

Где линуксоиды? Какие линуксоиды?
grep это GNU, линукс - это ядро.
Слушай завязывал бы ты уже бухать по утрам, печень отвалится и ты перестанешь нас своей альтернативной одаренностью радовать.

> лишь бы прятать свои ошибки в безопастности...

Э, да ты оракло-фоб, у них жабка обновляется только по расписанию, когда уже сотни уязвимостей в ней эксплуатируются

>> сколько из этих крахов можно использовать для атаки?
> Т.е. ты как бы сам не знаешь, но ляпнуть чепуху очень хочется?
> Передерг отмечаем

да нет, просто напоминаю о CVE-2012-5667, при том что анализировать код просто лениво.. Устало я за выходные :)

>>> сколько из этих крахов можно использовать для атаки?
>> Т.е. ты как бы сам не знаешь, но ляпнуть чепуху очень хочется?
>> Передерг отмечаем
> да нет, просто напоминаю о CVE-2012-5667, при том что анализировать код просто
> лениво.. Устало я за выходные :)

если ты устало -- не напрагайся,  не стоит тратить на нас время

на тебя не стоит. Но новичков надо предупредить. Что бы избавились от розовых очков и видели как замалчиваются проблемы безопасности. А ведь прошло меньше года с времен CVE-2012-5667 - но опять же предпочитают спрятать голову в песок и не замечать этого.

> на тебя не стоит. Но новичков надо предупредить. Что бы избавились от
> розовых очков и видели как замалчиваются проблемы безопасности. А ведь прошло
> меньше года с времен CVE-2012-5667 - но опять же предпочитают спрятать
> голову в песок и не замечать этого.

слушай, рип, я как-то пытался вести осмыслеенную беседу, пытался так-же как ты грубо набрасывать -- и итоге.... в итоге ничего -- ты просто дурак. жаль.

> я как-то пытался вести осмыслеенную беседу

С чем? с бревном? зачем?

>> на тебя не стоит. Но новичков надо предупредить. Что бы избавились от
>> розовых очков и видели как замалчиваются проблемы безопасности. А ведь прошло
>> меньше года с времен CVE-2012-5667 - но опять же предпочитают спрятать
>> голову в песок и не замечать этого.
> слушай, рип, я как-то пытался вести осмыслеенную беседу, пытался так-же как ты
> грубо набрасывать -- и итоге.... в итоге ничего -- ты просто
> дурак. жаль.

оо. переход на личности. Так есть что сказать по факту нового варианта CVE-2012-5667 спустя пол года?
или хамство - все что можно сказать?

>по факту нового варианта CVE-2012-5667 спустя пол года?

Пациент потерян для реальности.

> или хамство - все что можно сказать?

О.. линуксоиды для себя придумали паралельную реальность - когда баги в безопасности уже багами не являются ?:)  поздравляю. Ты так успешно показываешь свою не компетентность..

> слушай, рип, я как-то пытался вести осмыслеенную беседу

Понимаете, Павел, в чём дело.  У него шоры специфические -- когда дело о GNU/Linux, то тут тебе и CVE, и скандалы, и что угодно вытряхнет на стол.  А когда дело об оракле, где, по его же словам, не работает -- моментально дыры самозалечиваются, скандалы самозабываются и стол сверкает новеньким зелёным сукном.  Даже если речь опять же о GNU/Linux, только чуть другого фасона, чем НенавистнаяШляпа(tm).

Вы как хотите, а я общение с этим человеком прекратил.  Порой, не посмотрев на ник, отвечаю, иногда не спохватываюсь до отправки сообщения.  Над такими ошибками ведётся работа.

>> слушай, рип, я как-то пытался вести осмыслеенную беседу
> Понимаете, Павел, в чём дело.  У него шоры специфические -- когда
> дело о GNU/Linux, то тут тебе и CVE, и скандалы, и
> что угодно вытряхнет на стол.  А когда дело об оракле,
> где, по его же словам, не работает -- моментально дыры самозалечиваются,
> скандалы самозабываются и стол сверкает новеньким зелёным сукном.  Даже если
> речь опять же о GNU/Linux, только чуть другого фасона, чем НенавистнаяШляпа(tm).
> Вы как хотите, а я общение с этим человеком прекратил.

именно это-же сделал и я, потому что дураком я не всякого называю
>  Порой,
> не посмотрев на ник, отвечаю, иногда не спохватываюсь до отправки сообщения.
>  Над такими ошибками ведётся работа.

> на тебя не стоит. Но новичков надо предупредить.

У новичков в соседней ветке pf не фильтрует и wifi не заводится. Пройдите, маэстро! Непременно предупреждать!!

> на тебя не стоит. Но новичков надо предупредить. Что бы избавились от
> розовых очков и видели как замалчиваются проблемы безопасности.

Поэтому нефиг из себя дон-кихотов корчить: хочется отсутствия таковых проблем - используйте свежий софт. Если майнлайнщики говорят что надо обновиться - на это есть причины. При том причиной может быть невкусный баг или потенциальная дырка. И что характерно, все это есть и в другом софте. Более того, еще большой вопрос где качество кода лучше.

> меньше года с времен CVE-2012-5667

Ты так с ним носишься что просто обязан вытутаировать это на лбу. Ну так, чтобы новичков предупреждать.

> сколько из этих крахов можно использовать для атаки? берем подсовываем хлам в
> /var/log/messages и когда админ делает grep по логу... выполняем произвольный код..

Such injection issues are not treated as security issues © Debian security team

>> сколько из этих крахов можно использовать для атаки? берем подсовываем хлам в
>> /var/log/messages и когда админ делает grep по логу... выполняем произвольный код..
> Such injection issues are not treated as security issues © Debian security
> team

это тот team - от работы которого страдает интернет из-за дыры в openssl ?

> это тот team - от работы которого страдает интернет из-за дыры в openssl ?

Послушать линуксрипа - так дыры и баги только в дебиане, в линуксе и в гнутых утилах. Хотя если уж о новичках и вранье - вот это как раз наглое вранье и двойные стандарты. Баги и дыры есть в любом софте сложнее hello world. Но про это линуксхрип тактично умалчивает, ведь неудобно же признавать очевидное.

> Such injection issues are not treated as security issues

Если некто может писать в такие файлы - пожалуй они и в /dev/sda нули запишут. После чего не так уж и важно что они еще и в messages могли писать...

>> Such injection issues are not treated as security issues
> Если некто может писать в такие файлы - пожалуй они и в
> /dev/sda нули запишут. После чего не так уж и важно что
> они еще и в messages могли писать...

Смотря насколько произволен доступ что в лог, что в sda.  Можно долго переливать из пустого в порожнее, но при обсуждении вопросов безопасности конкретика полезней.

Сначала развалим инфраструктуру операционки до основания, а потом заявим: "зато у нас в grep теперь есть PCRE"

> Сначала развалим инфраструктуру операционки до основания, а потом заявим: "зато у нас
> в grep теперь есть PCRE"

Линуксмастрип, залогинься.

> Сначала развалим инфраструктуру операционки до основания,

Какую инфраструктуру? Какой операционки? И главное - при чем здесь греп?