Debian vs FreeBSD

Медленно это.

Обычно вращение нужно делать при закачке фото основываясь на данных exif, либо интерактивно по команде, что еще более увеличивает требования к скорости.

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

Куда не кинь, со всех сторон выгодней иметь нормальный GD.

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

Значит вы любите собирать пакеты. Суть backports.org в том, чтобы предоставить готовые.

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

palladium2010 добавил 19.09.2010 в 18:35

Типа того ))

... либо не делают ни того ни другого и все не хуже bundled GD. Смотрите, там есть вариант и с расширением imagick.

Не нужно никакого "опыта в массах" - нужно посмотреть примеры в документации. Для "все преобразований" - вовсе нет нужды его использовать. Что мешает это сделать в конкретном примере одной функции?

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

Вы вообще ответили не на заданный вопрос: Вас спросили "почему без imagemagick"? Почему Вы взяли и ограничили варианты решений "проблемы"?

Что, ответ - "потому что мы обсуждаем debian"? Что там нету php5-imagick или imagemagick?

Вобщем, сильное ощущение желания "потрепаться", не более. Вы сказали: нет функции imagerotate. С Вами согласились, причем:

1) объяснили почему: в debian стараются не использовать bundled версии общедоступных библиотек;

2) объяснили, что: согласно документации программист и не обязан расчитывать на такую функцию везде, где заявлена поддержка gd;

3) объяснили где: найти разные варианты решения "проблемы", реализовав функцию другими средствами (все в той же документации);

4) объяснили, как: хостеру никто не запрещает пересобрать пакеты PHP под себя, включив bundled GD.

Да - функции нет, и быть не обязана, есть куча вариантов реализации функции сторонними средствами (для программистов) или вариант кастомизации сборки PHP (для хостеров). Что еще к этому добавить?

Самое правильное решение - пинать разработчиков GD, чтобы они забрали изменения в пхпшной GD, или разработчиков PHP, чтобы они запихнули свои наработки в upstream. Все выиграют.

Я не побрезгую взять deb-src с бакпортс (портировать самому на stable обычно влом, если есть готовое). Но сопровождать такой пакет - естественно буду сам. Бакпортс пока до security.debian.org еще далеко, расчитывать на какие-то систематические обновления безопасности - очень сложно.

fastcgi.

Второй спор - глуп, бессмысленен, необъективен.

Можно узнать, почему Вы обвинили меня в необъективности?

К вам такой вопрос - сколько на ваших серверах аккаунтов (или сайтов)? тех где работает fastcgi

>Можно узнать, почему Вы обвинили меня в необъективности?

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

>К вам такой вопрос - сколько на ваших серверах аккаунтов (или сайтов)? тех где работает fastcgi

Обычно - около 1-2. Но зато где-нибудь c десятком миллионов хитов :)

Если убрать и эту субъективность, то, по логике, php-cgi действует по принципу "1.5 процесса на 1 запрос" (да, suexec тоже можно посчитать), mpm-itk - "1 процесс на keepalive-сессию" (что, кстати, пагубно сказывается при использовании nginx-фронтенда, так как получается 1 процесс на 1 запрос), а fcgi - 1 процесс на [любое заданное число] запросов.

Ещё я видел забавной идеей поднятие для каждого пользователя своего apache в количестве 3-4 процессов, которые балансируются одним apache или nginx. Получается тоже достаточно хорошо - совмещает плюсы php-itk и fcgi.

Определенная доля субъективности, конечно, есть. Но Вы ведь не будете утверждать, что управление бинарными пакетами во фре устроено сравнительно примитивно, по сравнению с дебианом или даже центос? Это вполне объективно. И не относится к "узкой сфере задач". Но о таких вещах все, в общем-то и не спорили (подобные "споры" - это скорее "базары", где каждый расхваливает достоинства своего "товара").

Думал речь идет о "проблеме" с php5-gd.

Вы, я гляжу, идеалист. Если 9999 причин не пользоваться "лучшим", если есть "неплохое". Что не отметает наличия "лучшего".

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

В сущности, разве это не одно и тоже (что и фастцги)? Тот же php-fpm умеет масштабироваться по-типу prefork mpm. Зачем изобретать велосипед, когда все уже есть в апаче (+ куча других mpm).

он с использованием временного файла в качестве переходника между GD и IM. Ничего лучше там нет.

Как показано выше, опыта нет СОВСЕМ. Совмещая разнородное получится неэффективное. См. "Франкенштейн".

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

Ну, в текущей стабильной убунту это ведь как-то решили. Там функция есть.

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