1. Главная
  2. Dеmimurych

Dеmimurych: Комментарии

Главные вкладки

11 декабря 2010 в 15:40

в друпале, по умолчанию, как и в любой нормальной системе, не возможности показывать пароли пользователей.

потому как в базе хранятся хещи паролей. А не сами пароли. хеш получается при помощи необратимой функции. То есть зная функцию и зная хеш, нет возможности получить изначальный пароль.

3 декабря 2010 в 17:44

То что написал хостер в пояснении, очень похоже на то что он врет.
И вот почему.

Любая zero day уязвимость linux ядра (да и любого другого) стоит немалых денег.
Ими не разбрасываются ради масс дифейсов.

Дальше возможны два пути развития:
1) хостер не соврал, а это означает что в течении пары дней выйдет новое ядро с исправлением уязвимости
2) хостер соврал и никакого ядра не будет.

UPD1:
оказывается масс дифейсы начались еще 25. А сегодня 3. Хостер врет.

24 ноября 2010 в 13:08

Простите что не в тему.
посмотрел, но так и не понял в чем профит флеша для решения тех задач которые решены в Zoomify. Все то же самое делается очень просто на банальном javascript.

16 ноября 2010 в 0:52

"RxB" wrote:
Знатный оптимизатор, правда он за premature optimization

иронизируешь или тролишь?
0.5 секунды на запрос от одного клиента это катастрофа для сервера.

16 ноября 2010 в 0:50

"Crea" wrote:
Ну и что ?
А на всеми любимом движке Vbulletin так вообще темы кастрируют - закрывают и создают клоны, чтобы не тормозило. И вроде бы, все довольны ? При таком количестве комментариев у вас элементарно на InnoDB будут запросы тормозить из-за пейджера.
Я бы назвал это экстримальными условиями. Для таких случаев и предусмотрены администраторы, которые могут ручками добавить любуй индекс и оптимизацию.

15 ноября 2010 в 22:12

"<a href="mailto:volocuga@drupal.org">volocuga@drupal.org</a>" wrote:
Но согласитесь, в реальных условиях в это слабо верится. Почему не 50.000?

потому что взяты именно реальные условия.

тестовая платформа содержит точную копию базы с продакшена.

11 ноября 2010 в 11:38

Набор шаманских манипуляций которые применимым к дефолтовой установке и
действительно приведут к увеличению производительности.

Очень мало времени уделено оптимизации сервера mysql и самой базы drupal

А ведь перевод некоторых(мы вообще используем все) таблиц с формата myisam к innodb дает заметный прирост производительности в проектах где в одно и тоже время сайтом пользуется много человек.

8 ноября 2010 в 19:25

я используйте ffmpeg в связке с php-ffmpeg
http://ffmpeg-php.sourceforge.net/

впрочем и без полсденего задача тривиальна
ffmpeg -i video.flv -an -ss 15 -vframes 1 -s 640x480 -y -f mjpeg screen_640_480.jpg

-ss 15 — кадр будет с 15 секунды.

4 ноября 2010 в 11:58

стало быть разруха не в клозетах а в головах.

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

у меня есть стойкое убеждение, что на ресурсе, на котором появляется много вкусного материала люди смотрят на спам с иронией.

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

6 октября 2010 в 19:53

в убунту 10 04 идет пхп 5.3
друпалу нужен php 5.2

если вы плаваете в том как работать с линукс - сначала научитесь работать с ним. Иначе при ваших ресурсах вы будете долго ломать голову над производительностью.

Найдите человека который вас проконсультирует лично.

7 сентября 2010 в 14:57

"<a href="mailto:volocuga@drupal.org">volocuga@drupal.org</a>" wrote:
"серьёзные" - я имею ввиду высоконагруженные с уникальными фичами. Например, набивший оскомину Фейсбук. Нельзя такое сделать на Друпале. Или Фликр. Или Soundcloud. Или Plentyoffish

толсто.

28 мая 2010 в 17:39

подобного рода оптимизации играют какую то роль только в случае
1. неверной работы с кешем браузера или
2. первой загрузки страницы.

в 1 случае с администратором и так все ясно. никакие модули типа паралелс не помогут
в 2 случае слабое место в загрузке сайта будет не в последовательной или параллельном методе загрузки скриптов а в загрузке вообще. Стилей скриптов и прочих внешних ресурсов.

27 мая 2010 в 10:10

простите НО
1. нормальный скрипт должен висеть на document ready
2. нормальный хостинг должен отдавать gzip версии js кода с expire заголовками.

пункт 1 и 2 полностью нивелирует необходимость публикации скриптов в футере.

23 мая 2010 в 23:17

позорище а не сайт

по всем параметрам.
от дизайна до технической реализации.

особенно рыдал над качеством видео и бездарной интеграции фловплеера. даже псевдо стриминга осилить не смогли.