FreeBSD 8.0 Release

Я говорю о том, что xargs - не более чем внешний аналог -exec, а print0 передает строку в ASCIZ которую соотвественно жует xargs -0. В ОБОИХ случаях будет производится вызов внешней программы для КАЖДОГО файла (в данном случае). Вся разница - в хвостовом \00. Иногда это бывает полезно (пробелы в имени e.t.c). Так что вызовов rm будет ровно сколько же. В чем я и призывал Вас убедиться ... 8)

> Не ожидал что будет так просто. Но все-таки у Debian-а установщик гораздо более гламурный =)

Реально удивил. Чаще люди блуждают в трех соснах. :-D

> Условно «улучшенный» chroot, так и не ставший OpenVZ. То есть, внутри jail фряху другой версии, отличной от системной не разместить толком

На домашней машинке в Jail-ах. живет 6.4, 7.2 и 8.0-RC2. Ы?

> Я говорю о том, что xargs - не более чем внешний аналог -exec ... В ОБОИХ случаях будет производится вызов внешней программы для КАЖДОГО файла (в данном случае)

Твой ответ навевает на меня грусть. Т.е. ты банально просто не в курсе что именно делает xargs, зачем нужен -0 и как это вообще работает, и пытаешься мне рассказать, что я буду удивлён, если изучу реальное положение вещей. Я удивлён, но скорее тем, что мне пытаются запудрить мозг. Я тоже могу бы загадочно сказать, что если ты разберёшься, то будешь удивлён как всё на самом деле. Но упрощу задачу. xargs придуман именно как костыль для подобных случаев, когда все параметры разом не влазят в командную строку, и надо разбить запуск программы на несколько отдельных запусков, группируя аргументы по мере возможности. Т.е. в той неполной строке, которую я приводил, а не полная она была, поскольку я надеялся на достаточный уровень образованности, использовался ключ -0 (и -print0) не для аскии-зет строк как таковых, а для правильной передачи аргументов в случае, когда в аргументе есть пробел. Т.е. (условно) find /tmp -print0|xargs -0 rm -f — вызовет «rm -f» столько раз, сколько групп аргументов будет составлено. Рекомендую ещё раз прочитать мануалы и кукбуки, может наступит просветление, если ещё не достаточно.

Грустно.

Хехехе - а Вы все таки проверьте КАК это работает... В данном конкретном случае. 8)

>В результате инсульта скончался Джон Биррел (John Birrell), известный разработчик проекта FreeBSD, более 12 лет участвующий в развитии проекта. Среди разработок Джона можно отметить портирование технологии динамической трассировки DTrace, разработку библиотеки libdwarf, портирование FreeBSD на архитектуры DEC Alpha и Sun UltraSPARC-T1 (Niagara), создание многопоточной (pthread) библиотеки libc_r. :(

Вечной памяти ему. grep -r «John Birrell» /usr/src/sys/* выдало кучу всего. Жаль что от нас ТАКИЕ люди уходят.

Есть подозрение что блистательным примером и конкретикой меня не огорошат. Хех... 8)

Родные службы лучше Пингвинутых знают, причём годами, что надёжнее.

Информация ФСБ России

Так что слили дорогие, живущие на подножном корме корпораций и при этом вопящие о свободе выбора африканских слов.

>Родные службы лучше Пингвинутых знают, причём годами, что надёжнее.

Собственно к чему это? Давайте начнем обсуждение ВК «Эльбрус»? Да и как обстоят дела с отечественной криптографией?

Они новость о релизе поместят или ЛОРом ограничатся?

Я хочу послушать твою версию. А то, понимаешь, 12 лет назад оно работало именно так, как я описал. Понимаю, что много воды утекло, может и не уследил чего, поэтому ты уж вкратце, пожалуйста, просвети меня.

Мне незачем, спроси админов локалхоста, которые без сакрального знания в комментариях конфигурационных файлов ничего не могут сделать

> Но есть общее решение, которое работает везде,

И это решение - «find /path -exec rm {} \;»

через -print0 | xargs -0, и оно обоснованно оптимизировано.

-print0 подразумевает GNU find, который не везде есть. И есть подозрение, что на его установку времени уйдет больше, чем весь оверхед от -exec, тем более, что во многих реализациях find его нету

> -print0 подразумевает GNU find

Ёмайо. Оно у меня работало 12 лет назад в SCO OpenServer. Я не поленился и нашёл man find(1) от FreeBSD 8.0, 7.2, 4.9, 2.0.5 — везде есть -print0. Я не понимаю, я с роботами общаюсь? M-x doctor я уже 9 лет назад посмотрел, не сильно впечатлило.

установите переменную kern.argmax побольше и будет вам счастье.

>> -print0 подразумевает GNU find

Ёмайо. Оно у меня работало 12 лет назад в SCO OpenServer. Я не поленился и нашёл man find(1) от FreeBSD 8.0, 7.2, 4.9, 2.0.5 — везде есть -print0.

Ок, утверждение о GNU find было неверным (оно верно для моей системы, но не верно в общем случае). Но это не меняет сути дела, заключающейся в том, что print0 не является частью стандарта. См. здесь:

http://www.opengroup.org/onlinepubs/009695399/utilities/find.html

Вобщем, получается, что ваше утверждение о том, что -print0 работает везде - неверно. Как, впрочем, и утверждение о том, что «find /path -exec rm {} \;» работает эффективно с точки зрения количества вызовов rm. Оно, конечно, может работать эффективно, вызывая rm со списком файлов, но это не будет соответствовать стандарту.

Однако, вариант «find /path -exec rm {} +», предусмотренный стандартом, в плане эффективности ничуть не хуже варианта c -print0. GNU find его умеет, насчет всяких SCO утверждать не буду.

У меня в системе (OpenSolaris) для каталога с 8189 файлами получаются следующие результаты:

find /path -exec rm {} \; - 8189 вызовов rm find /path -exec rm {} + - 1 вызов rm gfind /path -exec rm {} \; - 8189 вызовов rm gfind /path -exec rm {} + - 4 вызова rm gfind /path -print0 | gxargs -0 rm - 4 вызова rm

Так что стандартный вариант получается наиболее эффективным.

А если учесть еще накладные расходы на передачу имен файлов в xargs через конвейер ;-) Хотя они, конечно, намного меньше накладных расходов на вызов rm 8189 раз.

Сорри:

find /path -exec rm {} \;             - 8189 вызовов rm
find /path -exec rm {} +              - 1 вызов rm
gfind /path -exec rm {} \;            - 8189 вызовов rm
gfind /path -exec rm {} +             - 4 вызова rm
gfind /path -print0 | gxargs -0 rm    - 4 вызова rm

Конкретно у нас были сомнения в том, что при такой вот конфигурации, как у вас, собранный бинарник приложения под 7.х потом будет нормально работать в обычном окружении. Как собирались ваши jails 6.4 и 7.2?

> find /path -exec rm {} +

в случае rm(1) лучше использовать опцию -delete у find(1), коя не требует отдельного exec()

7.2 собирался из сорцов. 6.4 слит с ISO-шки. разумеется на ноде ядро собрано с COMPAT_FREEBSD6 и COMPAT_FREEBSD7. Собственно я не вижу причин, по которым приложение, собранное на ранних версиях не будет работать. Обратную совместимость никто не отменял. Ну и разумеется для запуска бинаря от 7.х на восьмерке придется поставить compat-ы из портов.

>>Ёмайо. Оно у меня работало 12 лет назад в SCO OpenServer. Я не поленился и нашёл man find(1) от FreeBSD 8.0, 7.2, 4.9, 2.0.5 — везде есть -print0. Я не понимаю, я с роботами общаюсь? M-x doctor я уже 9 лет назад посмотрел, не сильно впечатлило.

А может, там и есть GNU Find. o.O

> Однако, вариант «find /path -exec rm {} +»

Ну, если посмотреть предыдущее обсуждение, то остальные участники find vs xargs про «+» ничего не говорили. Для случая -exec command {} +: The command line is built in much the same way that xargs builds its command lines, т.е. по хорошему, они должны быть эквивалентны, что и получается в твоём случае с gfind.

Аргумент про OpenSolaris интересен, я солярис последний раз в 2001м видел, но тема тут была FreeBSD :)

Кстати да, самое толковое замечание 8)

Поздравляю!!!

официально вышел!!!

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

Gtk 2.18 и GNOME 2.28 в коллекции портов FreeBSD!

Обновляемся.

(я же говорил, что FreeBSD 8.0 выйдет с новым Гномом)

> val-amart потерли последний коммент, а я как раз хотел спросить, что там такого замечательного в routing domains openbsd, чего я не сделаю в freebsd >=7.2

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

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