1.2, c0rax (ok), 10:16, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Отлично.
Теперь ждем пару-тройку корректирующих релизов, и можно ставить на свои сервера.
Вот правда хостинги еще не скоро на нее перейдут, если конечно вообще перейдут, что довольно спорный вопрос.
| |
|
2.13, jesus (??), 11:57, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> хостинги еще не скоро на нее перейдут
ох уж эти сказочки... ох уж эти сказочники...
у некоторых слоупоков ещё 5.2 стоит, но это не значит, что все такие неумные
| |
|
|
|
|
6.64, Georges (ok), 15:53, 06/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> в настройки сервера. купите себе VPS и выбирайте там все что хотите
А без vps, возможность выбора версии PHP для всех клиентов на сервере ?
| |
|
|
4.19, terr0rist (ok), 13:08, 02/03/2012 [^] [^^] [^^^] [ответить]
| +2 +/– |
перевод чего? софта? хостинга? или ваших мыслей?
Для хостинга это вообще ноль проблем, если, конечно, изначально нормально устроена архитектура. Добавить ещё один выполняемый CGI-шник, знаете ли, не потребует даже рестарта httpd.
| |
|
|
6.26, terr0rist (ok), 18:11, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
1. Если уж на то пошло, то FastCGI - это разновидность CGI.
2. PHP-FPM "искаропки", как известно, не старше PHP 5.3.0. Который также далеко не везде даже с CGI.
3. Китч - это то, что у РНР до сих пор нет вменяемой альтернативы. Которая была бы сравнима по популярности, скорости, кол-ву расширений и простоте развёртывания.
Приходится писать на рнр и плеваться.
| |
|
7.38, cosmonaut (ok), 11:57, 03/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
>у РНР до сих пор нет вменяемой альтернативы. Которая была бы сравнима по популярности, скорости, кол-ву расширений и простоте развёртывания
python?
| |
|
8.63, PnD (??), 13:28, 06/03/2012 [^] [^^] [^^^] [ответить] | +/– | Я вообще-то не прогер, однако в админской части приходится иметь дело с массой... текст свёрнут, показать | |
|
9.65, arisu (ok), 19:44, 06/03/2012 [^] [^^] [^^^] [ответить] | +/– | что-то не видно любителей гвидобейсика со срыванием покровов то ли ниасилили мн... текст свёрнут, показать | |
|
|
|
|
5.22, MVK (??), 15:34, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
Ну если PHP был подключен через CGI (ха-ха-ха, бред полнейший), то действительно не проблема. Только через CGI на shared хостингах PHP никто не подключает из-за низкого перфоманса.
| |
|
6.28, terr0rist (ok), 18:35, 02/03/2012 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Ну если PHP был подключен через CGI (ха-ха-ха, бред полнейший), то действительно
> не проблема. Только через CGI на shared хостингах PHP никто не
> подключает из-за низкого перфоманса.
1. Если 80% российских хостингов - это никто, кто же тогда по-вашему "кто"? И вообще не рекомендую бросаться обобщающими словами: "Никогда не говори никогда".
2. Насчёт "бреда": а как ещё обеспечить выполнение разных версий всего-всего-всего? Хотя бы пыхов версий 4, 5.2, 5.3, помноженных на разные сейф моды, АРС, зенд-декодеры и пр. Вообще, CGI - единственное удобное решение для предоставления юзеру возможности конфигурировать пых (на шаред-хостинге). Есть ещё, конечно, всякие user-mode апачи в джейлах и пр, но тут уже неизвестно, что будет проще и быстрее.
3. Да и не такие уж большие потери на CGI для той ниши, на которую изначально рассчитан РНР - personal home pages :) А те, кто на пыхе пишет серьёзные проекты, наверно могут поднять его и на собственном физ/вирт серваке.
4. "Перфоманс" и программирование на рнр - вещи, совместимые в исключительно редких случаях. Кстати, тот же друпал и кое-какие другие известные системы (зенд) на некоторых хостингах были попросту запрещены - по причинам их перфоманса.
5. В принципе, нормальным людям давно очевидно, что скрипты и перформанс - вещи несовместимые. А как эти скрипты выполнять, CGI или модулем, это уже не столь важно, если они заново парсятся каждый раз. Именно поэтому и делают всякие APC, Zend optimizer, а так же node.js и тд. Надеюсь, что если node.js получит широкое распространение, перейду на него. А РНР пусть остаётся там, где ему и место исходя из названия.
| |
|
7.34, Georges (ok), 22:36, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
Если хостер будет запускать PHP как CGI это немного повысит нагрузку на сервер и сможет размещать на сервере немного меньше клиентов. Поэтому будет немного нерентабельно.
Сайты у клиентов последнее время жирненькие (Joomla Wordpress Bitrix Drupal) и если хостер будет использовать CGI то пользователи будут страдать от такой тормознутости и поищут другого хостера. Если конечно вы имеете ввиду именно CGI , а не FastCGI . С FastCGI производительность будет не так страдать.
Хотя часть движков имеют в списке своих технических требований Apache + mod_php , в этом случае хостеры с CGI отпадают.
| |
|
|
|
10.66, asd (??), 23:16, 06/03/2012 [^] [^^] [^^^] [ответить] | +/– | Это вопрос или утверждение Если вопрос, то почему нет в конце соответствующего ... текст свёрнут, показать | |
|
|
|
|
|
|
|
|
|
1.3, CSRedRat (ok), 10:27, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
А как там на счёт включения в базовый пакет расширенных кэширующих утилит? Вроде APC (Alternative PHP Cache, относится к акселераторам PHP) хотели включить по умолчанию. Правда он давненько не обновлялся.
| |
|
2.4, Аноним (-), 10:31, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
Кстати, тоже интересно почему. Т.е. я вообще не знаю причин, по которым нужно было бы не включать акселерацию кода. Просветите, если таковые вообще есть.
| |
2.8, jedie (?), 10:47, 02/03/2012 [^] [^^] [^^^] [ответить]
| –1 +/– |
Насколько мне известно APC входит в базовый состав уже с версии PHP 5.1
| |
|
1.9, ФФ (ok), 11:05, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Придётся поставить на локалхост и протестировать проекты.
| |
|
2.31, terr0rist (ok), 18:48, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Поддержку юникода в стандартные строковые функции так и не встроили?
хмм. А побайтно тогда какими функциями кодить?
| |
|
3.33, Аноним (-), 19:37, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
можно ими же, строковые функции ведь по моему должны с символами работать а не с байтами, количество байт определять в зависимости от текущей кодировки, ну а если надо работать именно с кусками памяти (байтами) то тут опять таки по моему лучше отдельные функции сделать, логичность и читаемость кода лучше будет
| |
|
4.42, terr0rist (ok), 14:35, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> можно ими же, строковые функции ведь по моему должны с символами работать
> а не с байтами, количество байт определять в зависимости от текущей
> кодировки, ну а если надо работать именно с кусками памяти (байтами)
> то тут опять таки по моему лучше отдельные функции сделать, логичность
> и читаемость кода лучше будет
что-то вы запутались.
Вот есть у меня блоб (binary large object). Как я с ним буду работать строковыми функциями, использующими кодировку??? Мне нужен побайтный доступ, а не посимвольный, да ещё и с проверкой допустимости (utf-x).
То, что нужно раздельные функции - я согласен, но как, пардон, переделать УЖЕ существующие строковые (побайтные) функции для поддержки кодировок, чтобы при этом не пришлось переписывать 146% кода? К тому же, сейчас и так есть mb_* функции, которые работают с кодировками. Нужно всего лишь сделать каждой бинарной функции пару - mb_*.
| |
|
5.50, Аноним (-), 01:03, 04/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
Эт гдеж то я запутался если вы согласны? К уже существующим однобайтным строковым функциям надо добавить поддержку работы с многобайтовыми символами, в зависимости от текущей кодировки, если она у вас однобайтная (вы ее так выставили), то никаких 146% переделывать не надо, а если работаете с многобайтной то они автоматически начинают работать с ней, тогда вне зависимости от кодировки строковые функции остаются строковыми и работают с символами а не байтами, и переделывать ничего не надо, а для работы с бинарными данными (байтами, LOB) отдельные побайтовые функции, и проверка допустимости utf тут уже дело десятое, если у вас utf, т.е. текст, работайте строковыми функциями, впрочем на уровне кусков памяти они свободно совмещаются.
| |
5.51, Аноним (-), 01:11, 04/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
ибо понимаете, сейчас фигня какая получается, для одних строк одни функции, для других другие, для лобов строковые, все это запутывает, а так все будет четко и понятно - для строк строковые, одни и те же вне зависимости от кодировки, а для лобов - лобные
| |
|
|
|
|
1.27, ILYA INDIGO (ok), 18:17, 02/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Наконец то дождались :)))
register_globals фтопку
magic_quotes_gpc фтопку
временные зоны в виде отклонения от гринвича фтопку
utf-8 по дефолту
сокращённый синтаксис для массивов
разыменование массивов
задание бинарных чисел
и общее ускорение в целом :))
Теперь осталось подождать пока это добро вместе с apache 2.4.1 соберут на openSUSE ...
По поводу быдлоадминов быдлохостеров они скорее сами ся в зад отымеют, чем откажутся от magic_quotes_gpc ON...
Остаётся надеется на отдельные сервера специально запущенные под 5.4.x
| |
|
2.30, terr0rist (ok), 18:47, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> Наконец то дождались :)))
> utf-8 по дефолту
угу, и терь каждый раз проверять, по дефолту оно или нет, как с magic_quotes =)
> сокращённый синтаксис для массивов
> разыменование массивов
вот ещё бы массив в виде объекта... Бесит то, что нельзя прозрачно использовать ArrayObject и массив.
> Остаётся надеется на отдельные сервера специально запущенные под 5.4.x
CGI.
Хотя даже под CGI и то появится это чудо на хостингах не раньше года-двух спустя...
| |
|
3.32, ILYA INDIGO (ok), 18:55, 02/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>> Наконец то дождались :)))
>> utf-8 по дефолту
> угу, и терь каждый раз проверять, по дефолту оно или нет, как
> с magic_quotes =)
Дефолт значит дефолт его проверять не нужно, конечно если собираетесь писать исключительно под 5.4 я имел ввиду что он поддерживает многобайтовые кодировки по умолчанию то меж utf-8 для всех операций со строками.
>> сокращённый синтаксис для массивов
>> разыменование массивов
> вот ещё бы массив в виде объекта... Бесит то, что нельзя прозрачно
> использовать ArrayObject и массив.
Ну не всё сразу :))
>> Остаётся надеется на отдельные сервера специально запущенные под 5.4.x
> CGI.
> Хотя даже под CGI и то появится это чудо на хостингах не
> раньше года-двух спустя...
На моём хостинге он будет сразу же как его или в зелёнке собирут, или я на Arch Linux перейду, а там уже если серьёзные заказы у меня будут то поиск сервера с 5.4.х будет проблема моего менеджера а не моя :)
| |
|
4.45, terr0rist (ok), 15:01, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>>> сокращённый синтаксис для массивов
>>> разыменование массивов
>> вот ещё бы массив в виде объекта... Бесит то, что нельзя прозрачно
>> использовать ArrayObject и массив.
> Ну не всё сразу :))
С РНР, по-видимому, уже не только "не сразу", но вообще никогда.
Смотрю на node.js. Вот там, надеюсь, будет "сразу".
>>> Остаётся надеется на отдельные сервера специально запущенные под 5.4.x
>> CGI.
>> Хотя даже под CGI и то появится это чудо на хостингах не
>> раньше года-двух спустя...
> На моём хостинге он будет сразу же как его или в зелёнке
> собирут, или я на Arch Linux перейду, а там уже если
> серьёзные заказы у меня будут то поиск сервера с 5.4.х будет
> проблема моего менеджера а не моя :)
Если бы в мире был только один хостинг и только ваш :) Увы, это не так.
| |
|
5.46, ILYA INDIGO (ok), 15:31, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>>>> Остаётся надеется на отдельные сервера специально запущенные под 5.4.x
>>> CGI.
>>> Хотя даже под CGI и то появится это чудо на хостингах не
>>> раньше года-двух спустя...
>> На моём хостинге он будет сразу же как его или в зелёнке
>> собирут, или я на Arch Linux перейду, а там уже если
>> серьёзные заказы у меня будут то поиск сервера с 5.4.х будет
>> проблема моего менеджера а не моя :)
> Если бы в мире был только один хостинг и только ваш :)
> Увы, это не так.
Ну, как говорится, хочешь изменить мир - начни с себя!
Я начал :))
| |
|
|
|
|
1.36, XoRe (ok), 06:37, 03/03/2012 [ответить] [﹢﹢﹢] [ · · · ]
| –3 +/– |
> версия 5.4 не обеспечивает полную совместимость на уровне API и конфигурации. При использовании PHP 5.4 может потребоваться модификация приложений и серверных настроек
Я так понимаю, на такие понятия, как "совместимость" и "поддержка старых версий" забили напрочь.
Уже сейчас детища zend optimizer делятся на "закодированные в php5.2" и "закодированные в php5.3".
Я так понимаю, к ним добавится "закодированные в php5.4".
5 баллов.
Хотя это, естественно, не так смертельно.
Есть сейчас файл /opt/php52/bin/php-cgi + zendoptimizer.so.
Добавится /opt/php53/bin/php-cgi + zendloader.so.
А php54 будет, как основная в системе.
Кстати, кто там ругался на говнохостинги с php-cgi?
Вот если бы в php больше заботились о совместимости, сейчас везде использовали бы 1(одну) версию php-fpm (с возможностью переключиться на mod_php, ради .htaccess).
И все просто обновили бы php до последней версии.
А так... mod_php4/php4-cgi/mod_php52/php52-cgi/mod_php53/php53-cgi/mod_php54/php54-cgi.
А когда выйдет php6.. ну, вы поняли)
| |
|
2.43, terr0rist (ok), 14:42, 03/03/2012 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Кстати, кто там ругался на говнохостинги с php-cgi?
кто ругался, не знаю, лично я всеми руками за хостинги с php-cgi
> Вот если бы в php больше заботились о совместимости
хм, уж нет уж. Пусть ломают всё к чёрту! Не нужна мне такая совместимость, при которой я должен буду в 21 веке писать код без нормальной работы с ООП и массивами, зато с уёжским magic_quotes и всем-всем-всем.
Хотя, честно, РНР уже задрал. И не меня одного. Почему-то в его светлое будущее уже совсем не верится, и даже скорее, желается ему подохнуть поскорее)))
| |
|
3.48, noname (??), 22:35, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>Хотя, честно, РНР уже задрал. И не меня одного. Почему-то в его светлое будущее уже совсем
>не верится, и даже скорее, желается ему подохнуть поскорее)))
Это вы еще не видели встроенный язык 1С.
| |
|
4.67, asd (??), 23:19, 06/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>>Хотя, честно, РНР уже задрал. И не меня одного. Почему-то в его светлое будущее уже совсем
>>не верится, и даже скорее, желается ему подохнуть поскорее)))
> Это вы еще не видели встроенный язык 1С.
Да уж, в точку.
Потому всё-таки перл, как бы его не ругали. Вполне себе решение.
| |
|
5.71, XoRe (ok), 13:48, 11/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
>>>Хотя, честно, РНР уже задрал. И не меня одного. Почему-то в его светлое будущее уже совсем
>>>не верится, и даже скорее, желается ему подохнуть поскорее)))
>> Это вы еще не видели встроенный язык 1С.
> Да уж, в точку.
> Потому всё-таки перл, как бы его не ругали. Вполне себе решение.
Если учесть, что на подходе perl6, который несколько отличается от perl5, там тоже будет веселый переход)
| |
|
|
|
2.47, pro100master (ok), 19:28, 03/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
а зачем вам optimizer?
Если ваш продукт хорош (а он должен быть хорош, ведь не будете же вы защищать убогое поделие:), его всё-равно купят. Ради поддержки хотя бы. А если кто-то зажмотился и скопировал - вам от этого ни холодно и не жарко - он всё-равно вам не заплатил бы. Это как с любым софтом. Какие либо системы защиты лишь усложняют (увеличивают стоимость) продукт, и не несут никакой пользы - всё ломается за разумное время. А если вы в ульранизкобюджетном секторе - вы всё-равно работаете за еду и стоимость копии и защиты равна стоимости тарелки супа.
| |
|
3.68, XoRe (ok), 01:12, 08/03/2012 [^] [^^] [^^^] [ответить]
| +/– |
> а зачем вам optimizer?
Представьте, что вы - хостер.
Ваш пользователь купил у вас хостинг по дорогому тарифу, заплатил сразу за год.
И ставит какой-то движок, закодированный zend optimizer под php5.2.
Спросите у него, зачем ему optimizer.
Предложите забить на движок, как на устаревший.
А он забьет на ваш хостинг.
| |
|
|
|