В срочном порядке выпущен релиз PHP 5.1.6 (http://www.php.net/downloads.php#v5), в котором устранена ошибка появившаяся в PHP 5.1.5 и приводящая к полной неработе ограничений устанавливаемых директивой memory_limit на 64-битных системах.URL: http://www.php.net/
Новость: http://www.opennet.me/opennews/art.shtml?num=8208
Вот есть на опеннете раздел "Проблеммы безопасности". А давайте еще сделаем два раздела: "Проблеммы безопасности и новые версии ПХП" и "проблеммы безопасности и новые версии ядра Линукс". И уберем это из основной ветки новостей....
+1 на пред. сообщение
единственно я думаю можно "Проблеммы безопасности и новые версии ПХП"
именовать просто "Новые версии ПХП" - и так понятно зачем ети версии нужны
Логично было бы вообще убрать обсуждение новостей!
Ну, я на самом деле это не серьезно... про отдельную колонку. Просто больно часто эти две темы последнее время в новостях появляються, так что как то раздражать начали. Те кому надо (хотя надо это, наверно, подовляющему большенству, в том числе и мне) и так узнают об этом.
А обсуждение отключить можно как раз таки для этих двух тем, потому как в комментах тока флейм разводиться аля "какой пхп дрявый и кривой" и "какой линукс дрявый и тоже плохой". А потом начинают кричать "Ой, вы тут Лор разводите!" ... Вообщем ни чего интересного :-(
Не, обсуждение новостей порой интереснее читать, чем сами новости. Не надо убирать!
Да и выделять отдельные колонки под ЧихПых, с безопасностью которого и так все понятно, по-моему не надо
Дожили! Горя не знали! ... теперь опять апдейт... жесть.
А ведь и правда не работали ограничения. Пришлось откатиться обратно на 5.1.4 с таким расходом памяти как на 5.1.5, а тут на тебе, вот в чем плюшка была.
впервые обновляться не надо :) УРА ТОВАРИЩИ!
Господа, а может мне кто объяснить, зачем юзать пхп, когда есть перл и питон?
за тем что php достаточно удобный и гибкий язык (для своих задач разумеется), а во вторых не обязательно самому на нем писать -- много всякого готового и вкусного на нем писаного приходится использовать (ну хоть тот же phpBB).
Кстати, вопрос от вопроса. А зачем (действительно, зачем????) юзать python/perl если есть php?
Я просто рад до безумия что компания Инлайн-Техноложис создала свой биллинг на перле... Ведь думат же люди. Представляю что-бы было если все это хозяйство было написано на пхп.
Честное слово - я понимаю тех, кто пхп юзает давно. Привыкли, затарились. Но нынче - действительно, зачем?Ведь, извиняюсь, коноебит многие пхп-сайты и - часто. Моего товарища пхп-сайт хакнули, по-деццки. Я его спрашиваю - что делать-то будешь? Да хз - отвечает. Я готовый шаблон юзаю (врать не буду - phpBB или что другое) - где там разобраться?
И, действительно, может в отдельную ветку все эти казусы с пхп? Постоянно - одно и то же в комментах, одно и то же, после прочтения новости - =а зачем оно?=
Не поймите меня превратно, понимаю и =за= и =против= пхп, но, может, действительно - что-то поменять в новостях? (:
А если вдруг _всё_ устраивает? ;) Или ты думаешь что если вдруг кто-то напишет не на пхп - то всё станет вдруг сразу супер секурным?
Ты знаешь, мне это напоминает ситуацию с мониторами LG. Их всегда куча в ремонтных сервисах. И вот когда спрашивают - что это? Мониторы плохи? Или чините плохо? Мастера сервисного центра гордо отвечают: просто наша фирма торгует этими мониторами на всю округу. Поэтому, дескать, и в ремонте их навалом - ну очень их много поломанных, а вот представьте - сколько не поломанных (: в пересчете на общий процент продаж.Не станет все суперсекурным. Но есть вероятность, что ламеры от сохи не станут юзать перловые и питоновые скрипты, а останутся на пхп (: Иными словами - пусть себе в деревне покупают дешевый LG, а тот, кто при памяти - купит себе подороже и получше (:
Ты так и не ответил _зачем_ мигрировать на perl/python если и так всё устраивает.
>Ты так и не ответил _зачем_ мигрировать на perl/python если и так
>всё устраивает.Да, пожалуй, и незачем (: ведь =очень многие web-программисты кроме него ничего и не знают= (dmitri) ((:
Тогда уж про обновления ядра линуха тоже можно отдельную ветку.
Зря вы так, есть новость значит про нее надо сообщить, а обсуждение это приложение к новости, а поповоду дого что не использовать php - это не реально, уж больно моного web-программистов кроме него ничего не знают.
А теперь быстренько сообразите-ка мне web-ориентированный (это подчеркиваю) язык (только не тыкайте в перл/питон - писать echo/print/sprintf/printf/... для каждого выводимого блока - есть бред в сравнении с вставкой статического шаблона в пыхпых). И, кстати, про секурность говорили не раз, и не только в ветках про пыхпых: линуксоиды вон любят отговариваться, мол "отключи дырявые модули, и будет тебе секурность", девелоперы на сях говорят: "в чем ся виноваты, если разработчик туп и не проверяет входные параметры?" и т.д... Дыры-то находят в конкретных модулях, использование которых со стороны можно ОЧЕНЬ сильно ограничить (ну проверьте 10 раз входной параметр, отсеките всё ненужное, а уже только остаток кидайте в пусть и дырявую функцию - да хрен вас кто тогда поломает!!!). Кстати, в подавляющем большинстве случаев дыры относятся к разряду "надо залить сплойт на сайт и оттуда запустить" - дык не дайте залить. Либо если дали залить - не дайте запустить. Ну и вот недавняя дыра, дававшая якобы DoS: проверяли, запускали, работает... НО DoS, почему-то не даёт. Валится не корневой httpd, а лишь тод thread, что непосредственно обслуживал процесс. Угадайте, что происходит по отвалу одного из thread'ов апача? Всё просто: корневой httpd порождает взамен его новый.
Согласен. Большинство возгласов "А у моего друга опять пхпбб форум поломали" говорит лишь о том, что у подобных распространённых скриптов куча проблем и, вообще говоря, не понятно, на что надеются люди, поставившие "из коробки" какой-то потенциально небезопасный скриптец и не приложившие голову для минимальной настройки его окружения. Я, конечно, понимаю, что проблема с мемори_лимит (пусть даже только на х64) - довольно таки серьёзная штука, но вот почему-то основная масса недовольства направлена на конкретные продукты. Если кто-то на си фигню напишет, вы тоже будете говорить, что язык - лажа полная? Так уж сложилось, что "из коробки" либо будет ограничена функциональность, либо всё будет настолько открыто, что страшно выставлять в мир - всегда нужно приложить хотя бы какой-то напильник и правильно спроектировать то, что вы хотите использовать. Протыкать кнопки в визарде и получить рабочую и секурную инсталляцию для какой-то конкретной (зачастую уникальной) системы/инфраструктуры - это ж фантастика, либо это должен быть такой визард, который после каждого шага открывает в редакторе очередной конфиг с пожеланиями что-нибудь подхатчить.
>А теперь быстренько сообразите-ка мне web-ориентированный (это подчеркиваю) язык (только не тыкайте
>в перл/питон - писать echo/print/sprintf/printf/... для каждого выводимого блока - есть
>бред в сравнении с вставкой статического шаблона в пыхпых).Может того, матчасть подучить? Чтобы глупости не писать.
Угу, именно. Так что, вопрос вы поняли. Я жду примеров.
>Угу, именно. Так что, вопрос вы поняли. Я жду примеров.Тот же py-django.
>>Угу, именно. Так что, вопрос вы поняли. Я жду примеров.
>
>Тот же py-django.Угу. И тот же Mason, Template Toolkit.
TT:
Отличнейшим образом организована работа с массивами. Как там советуют: копируйте хеш в объект-массив...Бредим дальше?
>TT:
>Отличнейшим образом организована работа с массивами. Как там советуют: копируйте хеш в
>объект-массив...
>
>Бредим дальше?Может быть стоит все-таки подучить матчасть?
ТТ нормально работает и с хешами и с массивами, никаких объектов изобретать для этого не нужно.Для особых любителей совместить морду и логику - это можно сделать на Mason.
Да помилуйте, этот пример даже на википедии лежит:Так, при попытке доступа к ключу объекта hashobj.key, будет произведена попытка вызова метода key, и если такого метода нет, результатом будет пустое значение.
При попытке обращения к элементу arrayobj.$index, где index — индекс требуемого элемента, как и в предыдущем случае, Template Toolkit попытается вызвать метод с таким именем. А методов с именами 0, 7, 12 и т. д. в языках программирования, в общем-то, не бывает.
Сами учите кривую матчасть...
PS. Так все-таки признайтесь, чем же именно Вам пыхпых плох?
>PS. Так все-таки признайтесь, чем же именно Вам пыхпых плох?
А толком никто и не сможет ответить. Начали изучать технологию для крутости. Потом когда каждый студент начал маломальски писать на пыхе, это уже стало "некруто". Почитав форумы "поняли" что "круто" это perl, python и ruby. На вопрос "чем круче?" могут ответить только "чем пхп!". И постоянная подмена понятий "язык" и "виртуальная машина": нашли exploit в ВМ это значит язык - говно. ;)
Лет 10 назад я выбирал, на чем бы мне написать простенький веб-скрипт.
Выбирал между php и perl. Сходил на официальный сайт php и увидел 3 подряд новости об исправленных критических ошибках. Это определило выбор.С того времени ничего не изменилось.
>С того времени ничего не изменилось.
Так ты выбирал язык или виртуальную машину? Ты программер или админ? Что именно тебя не устроило?
Цитирую вас:
> Отличнейшим образом организована работа с массивами. Как там советуют: копируйте хеш в объект-массив...В ТТ проблемы с работой с массивами и хешами нет. Это вы по незнанию сказали.
http://www.template-toolkit.org/docs/plain/Manual/Variables....В русской Википедии говорится о том, что к blessed массиву или хешу нельзя обратиться, как к массиву и хешу - только как к объекту. Проблема в самом примитивном случае решается с помощью пары методов set/get. Мне за ~2 года использования не удалось наступить на подобные грабли ни разу. Признайтесь, вы TT изучали по Википедии? :)
Если эти грабли вам обойти так тяжело, используйте Mason. Там их нет.
> PS. Так все-таки признайтесь, чем же именно Вам пыхпых плох?
О, мне вполне достаточно регулярного чтения Багтрака :)
Т.е. тулзы, написанные на сях Вы тоже категорически не используете? И даже ОСь писали под себя с нуля на асме/иных языках? По багтраку ся (на нем, кстати пых писан) далеко впереди самого пыха будет...
> Тот же py-django.Да-да...
php:
if(isset($a) && $a && isset($b) && $b) {}py-django:
{% if athlete_list %}
{% if coach_list or cheerleader_list %}
We have athletes, and either coaches or cheerleaders!
{% endif %}
{% endif %}Продолжаем бредить кривыми поделиями...
>py-django:
>{% if athlete_list %}
> {% if coach_list or cheerleader_list %}
> We have athletes, and either coaches or cheerleaders!
> {% endif %}
>{% endif %}
>
>Продолжаем бредить кривыми поделиями...А что в этой конструкции плохого? То, что даже дизайнер не запутается? Дак шаблоны для того и придумали, чтобы отделить логику от морды или я не прав?
AND/OR придумали, конечно же для дураков, которыми django-девелоперы, естественно, не являются...
в догонку: каким образом Вы собираетесь защищать свой труд при использовании предложенных Mason, TT или Django? Только не говорите, что по жизни альтруисты и на продажу никогда ничего писать не собираетесь (как говорится, не зарекайся)!
>в догонку: каким образом Вы собираетесь защищать свой труд при использовании предложенных
>Mason, TT или Django? Только не говорите, что по жизни альтруисты
>и на продажу никогда ничего писать не собираетесь (как говорится, не
>зарекайся)!Что вы подразумеваете под "защищать"?
Заказчик платит за разработку и поддержку.
Если код требует какой-то программной защиты - значит задача несложная и типичная
(это верно для web-приложений).
Такие задачи неинтересны.
Под защищать подразумевается наличие возможности преобразования исходного кода в малочитаемый человеком бинарный код (кстати, еще и ускоряющего работу).