Black Jack: угу. А если принимающей стороне не принципиален content-type multipart/form-data вместо application/x-www-form-urlencoded, то можно и напрямую в качестве CURLOPT_POSTFIELDS передать массив.
> про то что стандартный hdd обрабатывает 70-100 мегабит в секунду
мегабайт. На линейном чтении (т.е. как раз там, где ssd дают эти свои >500 мб/с) у современных 7200rpm HDD и 180-200 мегабайт бывает в начале диска.
Ну я же написал, что искать L5420 надо, если вопрос стоит с энергопотреблением. Под полной нагрузкой будет жрать примерно в два раза меньше вашего, да малость быстрее на величину, заметную под лупой.
Поищите сравнение Q6600 и Q9450 - последний будет чуть быстрее L5420 за счёт чуть большей частоты.
Костыли - я бы проверял на isset($arResult["DISPLAY_PROPERTIES"]["MORE_PHOTO"]["FILE_VALUE"]["SRC"]) если true - то выводить только этот элемент. Если false - делать foreach по коллекции. Вариант vldud тоже должен быть достаточно стабильным.
В обоих случаях не забудьте проверить целиком $arResult["DISPLAY_PROPERTIES"]["MORE_PHOTO"]["FILE_VALUE"] на empty, а то оба предложенных костыля ошибутся и сделают глупость.
Да, если пакет A в списке рекомендуемых пакета B.
Можете собрать пустой meta-пакет, который будет для себя требовать A и B. Тогда при удалении B этот мета-пакет будет удалён по зависимостям, а A - останется никому не нужным и будет предложен к удалению autoremove.
Если под "ему" вы подразумевали LittleFatNinja, то да, печатаю я медленно и иногда забываю обновить страницу. Тем не менее, это ответ на заданный вопрос "Почему эта строка выдает ошибку?".
Если бы написали реальную задачу, хоть те же SDN - это интересно.
А помогать подставлять невиновных заказчиков под какие-то костыли и вендорлок в вашем лице - нет.
Это такой метод выстрелить себе в голову и не заметить. php.net/manual/en/book.reflection.php
Есть большая вероятность быстро превратить код в какую-то магию, в которой разобраться будет крайне сложно.
Отрубите планировщик - вот тогда увидите, что такое тупит. Да, NCQ тоже отключите.
Диск на 7200rpm физически не сможет больше 120 seek в секунду. Пластина крутится с такой скоростью, а писать её можно только в одном месте - под головкой. Ладно, возьмём современный диск на 4к секторах и ОС честно 4к блоками и пишет. Несложное вычисление - чистого случайного доступа максимум 480кб/с.
Затем вспоминаем, что ФС без журнала - это многие часы fsck при любой аварии. А ФС с журналом - так журнал тоже надо куда-то и когда-то писать. При том, когда-то потом его писать - это риск потом ничего не прочитать.
А если взять диски постарше, на честных 512 байтных секторах? 60кб/с.
А если взять диски на 4кб секторах, но на эмуляции 512 байтных секторов? Чтобы записать изменённые 512 байт, сначала надо прочитать эти 4кб данных с диска, затем изменить в них данные, затем записать обратно. Максимум 30кб/с.
Вот это - то, что может сделать железо. А ваш 1мб/с вместо этих радостных чисел - как раз плоды труда многих инженеров и программистов.
