А что там не так? rpm сборки я делал сравнительно мало, но в дебиане аналогичное "под конкретную цель" - делается на ура.
Есть такой момент. Нешто там до сих пор вовсе ничего не патчат?
Ну, все 9999 причин перечислять было несколько влом...
Неа. Тогда будет не "лучшее", а "идеальное" (подставьте любой синоним превосходной степени).
Нагрузка другая. На массовом виртуальном хостинге может на 1000й висящий на нем сайт сегодня и вовсе не придут. На 756-м будет всего 10 обращений от пользователей за весь день (равномерно распределены). На 111-й придет пойсковик. Помучает немного, сделав 50 запросов и уйдет. И т.п.
Т.е. нагрузка очень неравномерная. Держать ради каждого хоста или хоть клиента свой апач - немного накладно будет. Нет?
Ну, сравнительно дешевый. От 1000+ хостов на сервере. ТП где-нить от 1-2$.
Объяснить сперва не пробовали? Попросить заменить оборудование? В моей практике вменяемый ДЦ такое позволял (сервер был взят только что, попросили - заменили на другой конфиг).
Да, действительно. Но не вижу чем это сильно худо. Довольно дешево все.
Ну вот в убунте и есть это самый тестинг. Думаете он там позолоченный какой стал, о того что назвали ubuntu? :)
Обсуждается не "бинарное распространение" в сравнении со сборкой, а убожества реализации этого самого "бинарного распространения" во фре, по сравнению с...
Мне тоже "нравится slackware" :) Но, боюсь, это из разряда ностальгии по былым временам, первым попавшим в руки дистрибутивам и т.п. Объективно, кроме как "поиграться" (если не на что больше потратить время) - она сейчас ни на что не пригодна.
Ну хорошо, притворюсь что верю - Вы не понимаете, о чем речь. Приведу пример.
На хостинге в 100-1000 тазиков стоит система XXX. Геройский админ приходит и с цифрами доказывает руководству, что обновление до системы YYY даст на 20% (цифра с потолка, но скорее оптимистическая) более производительную систему и вообще "нам будет все удобнее", оно "лучшее" (все честно и объективно). Так прям и бросятся обновлять до "лучшего"? Или останутся на "хорошем", но без потенциальных проблем обновления, необходимости менять и переписывать кучу всего в инфраструктуре, и т.п.?
Принципы-то те же, да нагрузка на массовом виртуальном хостинге принципиально другая, нежели на сервере с парой хорошо посещаемых сайтов. Нужно объяснять?
Вот и я о том, тут плюшек даже больше, чем при использовании специализированного php-fpm.
Тем не менее, для дешевого массового хостинга - это все не подходит.
Где там временный файл, какая функция расширения imagick его создает, от меня таясь?
Должны. И что? На всех не угодишь, а телепатический интерфейс для магического исполнения "хотелок" еще не придумали. Вот и требуется покуда программистам в документацию смотреть.
Ну раз "решено", то и в тестинге должно быть решено (там и написано fixed, но я не проверял).
В 5.3 вроде это автоматом решается, там можно использовать и внешнюю GD и новые функции из bundled. Вот так вроде-бы это и "решили" в ubuntu (равно как и в дебиане, откуда почти один в один передрали пакеты).
Определенная доля субъективности, конечно, есть. Но Вы ведь не будете утверждать, что управление бинарными пакетами во фре устроено сравнительно примитивно, по сравнению с дебианом или даже центос? Это вполне объективно. И не относится к "узкой сфере задач". Но о таких вещах все, в общем-то и не спорили (подобные "споры" - это скорее "базары", где каждый расхваливает достоинства своего "товара").
Думал речь идет о "проблеме" с php5-gd.
Вы, я гляжу, идеалист. Если 9999 причин не пользоваться "лучшим", если есть "неплохое". Что не отметает наличия "лучшего".
Вот вас к тому и спросили. Это, мягко говоря, не совсем "хостинг". Под последним словом все-таки обычно подразумевается массовый виртуальный хостинг. Наверное ТС тоже имел в виду этот смысл?
В сущности, разве это не одно и тоже (что и фастцги)? Тот же php-fpm умеет масштабироваться по-типу prefork mpm. Зачем изобретать велосипед, когда все уже есть в апаче (+ куча других mpm).
Можно узнать, почему Вы обвинили меня в необъективности?
... либо не делают ни того ни другого и все не хуже 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 еще далеко, расчитывать на какие-то систематические обновления безопасности - очень сложно.
Почему вдруг "тупого"? Зачем столько высокомерия-то - вполне приличный PHP код есть.
Почему попиксельный вариант не сгодится? Откуда Вы это знаете, не зная условий конкретной задачи?
Почему без? Еще руки связать за спиной и языком по клавиатуре код набирать ?
Там есть решения и с imagemagic. И с использованием внешних бинарников, и с использованием расширения (доступного в дебиан).
Еще раз - неумение заглянуть в документацию - не проблема дебиан. Ставьте девелоперов в угол, бейте по рукам, не давайте десерта - но обучите их смотреть туда и писать портируемый код. Либо прогибайтесь под таких быдлокодеров, ежели Вы хостер.
А я не использую бакпортс. ЧЯДНТ?
Дык здорово, чиво. Появился еще один официальный сервис. Какому-нибудь центосу тоже не помешал бы. Дак нету там. 🚬
Поставите на это денюшку?
Да нет, я же указал решения.
Нет, или Вы не знаете?
Оправдать ожидания среднестатистического "девелопера", который "ваяет скрипты", забив на необходимость заглянуть в документацию - боюсь, таки не является задачей дебиана.
Но раз Вы хостер (как в ТЗ топика) - есть и другое решение. "Прогнитесь" под таких "девелоперов", поправьте одну строчку в правилах сборки и соберите свои пакеты PHP. Пересобирать важные пакеты на хостинге - частая необходимость и по другим причинам (например, вам требуется еще более оперативно обновляться при проблемах безопасности; патчи меняющие стандартную функциональность). Дебиан очень просто позволяет развернуть свою инфраструктуру по сборке и дистрибуции пакетов.
Ни хрена себе "Ничего не видно."
Смотрим права на пути до /usr/local/www/zabbix включительно и файлах там. Правим.
