Переворачиваются. ЧЯДНТ?
Повторяю, если Ваш девелопер читать документацию не умеет - это не совсем проблема дебиан. Ему никто не обещал, что данная функция будет работать в любой инсталяции, где заявлена поддержка расширения gd. Вот открутят от PHP возможность использовать что-то кроме bundled GD - тогда другое дело.
А пока - проверяйте нужные функции. Нету - используйте что-то для замены. В самой доке есть несколько альтернативных реализаций в несколько строчек.
Не вижу особой проблемы, из-за которой стоит превращать систему в помойку, не используя системную GD либу. По хорошему, надо пинать PHP разработчиков внести свои изменения в upstream GD.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=321237
?
Там подробно и очень доступно изложены причины, почему это пока wontfix. И народ активно ищет пути решения проблемы. Собственно, написано что в squeeze вроде исправили, что странно.
А вообще, для танкистов на сайте лучших собаководов написали:
Увы, если люди совсем читать документацию не умеют - тут ни дебиан, ни фря не помогут.
Можно подробнее? Тестовый пример, настройки php при которых такое наблюдается.
Проверяйте переменные дальше в приложении, определяйте что запрос не является валидным. Как-то так. Т.е. вполне разумная политика.
Сам с подобным пока не сталкивался, в смысле чтобы эта стратегия была проблемой.
Совратили? 🚬
1) Не "улучшена". Это исправление безопасности. Как я уже написал - скорее всего все Ваши остальные проблемы также уже исправлены.
2) Абы чего не всунут. Как правило, патчат офф версию только ради исправления багов, реже - меняя как-то функциональность (новые плюшки, адаптация к дебиановским стандартам и т.п.).
А версию в стабильной ветке - патчат вообще лишь по поводу исправлений безопасности или критических багов (например, могущих привести при работе приложения к потере данных). Крайне редко при этом добавляется/меняется функциональность. Случай max_file_uploads - пример безвыходной ситуации. Исправить проблему иначе было просто нельзя, наверное.
Знаете, а вот у меня в стандартном дебиановском php.ini с версии аж 5.2.6.dfsg.1-1+lenny4 появилась вдруг строчка
max_file_uploads=50
К чему бы это?
И они есть в дебиановском PHP Вы хотите сказать? Тогда пример ошибки в студию, номер CVE. С удовольствием сам отошлю мейнтейнерам багрепорт и сделаю бекпорт патча, устраняющего уязвимость. Коль исправление уже есть в другой минорной версии PHP. Только слабо верится, что подобное уже не сделано.
Вы не путайте, пожалуйста, 5.2.6 с офф сайта и пакеты с аналогичными цифирками в репах Debian :) Там есть еще цифирки в версиях пакета, они изменяются и в пределах стабильной ветки.
Например, сейчас в репозиториях src-пакет php5 версии 5.2.6.dfsg.1-1+lenny9. Рассказать что значат буковки и цифирки позади основной версии - или сами разберетесь?
Это только один пример. Так делают многие. Вообще, ИМХО, обвешивать "хостенк" кучей фич - часто не самая лучшая идея. С маркетоидной точки зрения - куча галочек в тарифном плане, конечно, "внушаить". А с технической - приводит к усложнению поддержки всего этого добра. Т.е. либо падает качество (как обычно), либо растет цена (менее обычно).
А я знаю крупные хостинги вообще без зенда.
Но Вы ответили только на один (второй) вопрос.
Видимо, далеко не все вообще знают про pkg_* во фре, коль из портов апач собирают на каждом сервере :D Но речь ведь зашла о том, что хоть оно и есть - больно убого (по сравнению с дебианом или центос).
Деж Вы такие тазики берете? Хотя ежели фря - с этим действительно может быть туго.
Но вообще - плясать от железа - это от бедности или глупости. Плясать надо от удобства управления системой, простоты решения ей необходимых Вам задач. От человека, короче. Которому со всей этой байдой работать. А вот с железом - нужно просто выяснить сперва про то, поддерживается ли оно системой полноценно. Если нет - повод подумать сперва о другом железе, а не системе.
Вообще, советы типа "пересобрать все под процессор", "ставить то, что удобно железу" - это из разряда советов "установщиков"/"настройщиков". Которые ставят систему клиенту по принципу "поставил и забыл". Будут проблемы - с этим будет трахаться другой "настройщик". Либо клиент заплатит денюжку снова - ежели что "поломалось".
Попробуйте за фиксированную (и сравнительно небольшую) денюжку постоянно сопровождать "настроенные" таким образом сервера и чинить все оговоренные контрактом проблемы. Сильно подозреваю, что всякое желание играться без нужды флажками компилятора - исчезнет.
Ну а что с этим - любая современная система должна в принципе без особых проблем работать. В посте lissyara имелись в виду, по-видимому, возможные проблемы с периферией типа дискового контроллера или сетевого. Редко, но такое бывает.
Я бы больше назвал подобное рукоблудством, а не ручной работой :) ИМХО. Даже при настройке очень специфичного веб-проекта, под который персонально выделен сервер (или целая пачка). Есть куча гораздо более разумных вещей на что имеет смысл потратить свое время и деньги клиента.
А Вы спросите не про "установщик пакетов", а про нормальную систему сборки, установки и дистрибуции софта. И лучше не на "форуме пользователей FreeBSD", а у людей, которые имели хорошую практику работы с debian или даже centos. И, соответственно, смогут сравнивать.
Накой черт там что-то делать "индивидуально"? Тазики все одинаковые, в пределах исполняемых ими ролей (прокси, бакенд, mysql-сервер и т.п.)
На большом хостинге ввод-вывод сервера в эксплуатацию - задача рутинная. Может и не каждый день, но раз в неделю - уже весьма вероятно.
А почему "умножить", а не "сложить", например? "Вычесть", или вообще "разделить"?
Что гарантированно получается - геморой. Сложная гетерогенная инфраструктура, о которой нужно помнить дополнительно кучу мелких тонкостей сборки, ради каких-то долей процента.
Это не велосипед, а практика разумных людей. Весь репозитарий дебиана/фри дублировать не придется - пересобираете как нужно отдельные пакеты и кладете в свой реп. Для совсем танкистов: пересборка этих пакетов потом потребуется далеко не при каждом обновлении в официальном репе. Только (и то не факт) при выходе очередного релиза - так в дебиан.
Влегкую найду, сам подобным занимался (хостинговая компания, мягко говоря, далеко не самая маленькая в России, хостинг был именно на фре). А вот буратин, которые собирают софт из портов на каждом хостинговом сервере - нужно уже искать с фонарем (в районе "хостенков" из одного сервера).
Можно собрать свой боинг, при желании :)
Только зачем? Нехилые трудозатраты, а нормальные люди уже подобное и весьма качественно сделали (как стандартная инфраструктура управления пакетами в дебиан) - может заняться полезной работой вместо этого?
PS: Чтобы портировать cupt на фрю - нужно сперва портировать dpkg. А потом еще есть всякие тулзы для управления сборкой, для построения репозитариев, для ... - короче, если Вы хотите из фри сделать дебиан, то это уже сделано. Я упоминал. В порте есть и cupt.
Дык MPM-то какой? Неужели таки воркер?
Час - это жестоко 😂
Нда. Это, пожалуй, единственный момент в котором фря однозначно рулит :D (Хотя бывают девушке и красивше).
Подобную вариацию логотипчика пингвина мне привести слабо :(
1) чем?
2) можно обновиться до более новой версии в squeeze (5.3.2, насколько я помню).
Только на двух? Я бы например допотопную систему управления пакетами во фре - даже сравнивать не стал с дебиановской. Удобство управления/модификации системы - не на последнем месте стоит. Вообще, наверное проще сказать на чем она "не отдыхает", чем наоборот.
Да никто в здравом уме на десятке хостинговых серверов такого не делает. Есть во фре бинарные пакеты, только убогие - от формата и инфраструктуры сборки, до способа их дистрибуции.
Это именно и является, как правило, мелочью. Архитектурные особенности хостинга (наличие фронтенда, кеширования, различных акселераторов динамики) - это на порядки существеннее скажется.
32bit - RIP
Потому что "бинарные" дистрибутивы также учитывают архитектуру. А прирост производительности, как правило, минимален (а кривыми ручками - можно получить и деградацию).
Плюс, пересобрать пакеты в бинарных дистрибутивах и сделать для своего "хостенка" репозитарий пакетов - как два пальца. Так нормальные люди и делают. Что во фре, что в debian.
"Мне ненужных" != "ненужных".
PS: Собственно, фанатам фри можно попробовать посмотреть в сторону Debian/GNU kFreeBSD - этот порт официально войдет в следующий релиз.
