а кто вам сказал, что он не нужен?
парсер html это громадный движок с искуственным интеллектом а парсер xml лёгкий как пушинка. Отрасль мобильных устройств не будет ждать когда обычные мобильники будут иметь 300Mhz процессоры и 60 мег места под парсер в памяти уже сейчас нужно работать с более скромными ресурсами (и удешевление требует урезания этих ресурсов). итак xml единственное удовлетворяющее условиям творение.
PS а подумайте про семантический разбор, который парсером xml делается в 10 строчек кода, и подумайте насколько увеличится число простых сервисов берущих данные из сети.
обратная совместимость от XML к html отсутствует, поскольку они никогда не были родственниками.
проще говоря не требуйте от парсера PDF совместимости с RTF.
Никто не будет удалять парсер html 3.2 из десктопных браузеров, но в мобильниках его не будет и вам как разработчику ничего не останется как в будущем писать на xhtml/xml для поддержки новыми устройствами.
Да простит мне сообщество, у Сагалаева давно не осталось аргументов кроме личной неприязни к новизне. Сейчас он хватается за последнюю соломинку bug IE в отображении Content-type для xhtml отличного от text/html. (не смешно ли мерять жизнеспособность стандарта по глючному браузеру?)
PS Стоит отметить, что комментарии людей, полностью опровергающих его утверждения он просто удаляет, что иначе как подтасовкой и не назовёшь.
xhtml полностью проходит все парсеры html включая the bat и outlook поскольку это он Уже по спецификации. никто не мешает вам встраивать css в текст письма.
doctype это пометка для браузера (и только него) какой режим совместимости включать. На практике doctype xhtml strict мешает лишь вписывать в код страницы iframe, а во всём остальном соответствие ему позволяет делать разметку более близко к спецификации.
Что же это вы новьё и сразу на продакшн? Взяли бы отдельный винт (хоть на время у знакомых) чтобы всесторонне погонять, а уж потом делали выводы... ато получается, что не смогли установить и просто увидеть в работе, а уже недовольны =)
Отделение драйверов это не такая уж большая заслуга. тем более на фоне Linux/FreeBSD/Solaris где это реализовано ИЗНАЧАЛЬНО. Кстати увидите на стабильности это скажется очень мало, а на скорости заметно.
Аппаратное ускорение видео это слабое оправдание для окупания оборудования. Ну не стоит покупка видеокарты за $200 того, чтобы воспроизведение видео разгружало на 4% процессор за $100 тогда как он и так бОльшую часть времени простаивает.
ReadyBoost использует невосполнимый ресурс flash-память с ограниченным числом циклов чтение/запись что также бессмысленная трата в сравнении с организацией нормального swap на HDD.
К сожалению вынужден вас огорчить такая информация бессмысленна и бесполезна, поскольку производительность очень сильно зависит от конкретного включенного через SSi скрипта. самая высокая производительность на конкретном среднем сервере (~1700 запросов/сек) была нами отмечена на SSI-включении статического файла, когда оба эти файла находились на mfs (файловая система в памяти) через lighttpd, но уже отрабатывая "hello world" скриптом на Си через fast-cgi мы наблюдали падение до ~800. Думаю этого разброса вполне достаточно, чтобы перестать искать статистику и просто стараться проводить исследования на месте.
да, я выразился неточно и слегка ввёл вас в заблуждение.
в моём случае техническое задание учитывает пиковую нагрузку в 1-1.2млн хитов в сутки с учётом посещения 4х страниц каждым посетителем. В данный момент расчитывается сделать чтобы просмотр этих 4х страниц занимал не более 20 запросов (хитов) 16 из которых статические (картинки, скрипты, css). Задача не самая тривиальная, но и особой проблемы её реализация не представляет средние 12 запросов в секунду (25-30 на пике) можно реализовать и одним хорошим сервером, если удастся сделать статикой запланированный максимум запросов.
Кстати сделать ограничитель типа "не более 3х запросов за 30сек от одного IP" вполне возможно штатными средствами, чтобы те, кто часто жмёт refresh не сильно мешали сервису.
У меня модель матрицы видна при входе в "инженерное меню". (реально на этом мониторе оно не даёт ничего менять просто даёт дополнительную инфорамцию.)
достаточно просто расположить все оттенки рядом где ступени будут более заметны, там и нет отдельного оттенка. а те 262144 цвета всего лишь соответствуют разрядности матрицы по её технической спецификации.
Более глубокий чёрный цвет обещают соотношения контрастности 1000:1.
16.7 даёт корректное отображение стандартной картинки с глубиной 24 бита без всяких dither-эффектов. Это главный довод, из-за чего CRT до сих пор в строю.
У меня тоже нет никаких искажений характерных для "16.2млн". Чистые 24 бита и корректные гаммы (виден контраст между #fff и #fffffe а также между #000 и #000001), что и для prepress мониторов Barco очень круто.
Слишком грубые ИМХО цвета. даже как-то неестественно. Я остановился на MVA (BENQ FP91GP). Весьма доволен и глубиной чёрного и цветопередачей и углами просмотра.
Вот потому в стандартных поставках Linux такая возможность отсутствует вместе с компилятором. Можете больше не бояться этого процесса Ubuntu уже практически совсем обходится GUI-настройками
парсер html это громадный движок с искуственным интеллектом а парсер xml лёгкий как пушинка. Отрасль мобильных устройств не будет ждать когда обычные мобильники будут иметь 300Mhz процессоры и 60 мег места под парсер в памяти уже сейчас нужно работать с более скромными ресурсами (и удешевление требует урезания этих ресурсов). итак xml единственное удовлетворяющее условиям творение.
PS а подумайте про семантический разбор, который парсером xml делается в 10 строчек кода, и подумайте насколько увеличится число простых сервисов берущих данные из сети.
проще говоря не требуйте от парсера PDF совместимости с RTF.
Никто не будет удалять парсер html 3.2 из десктопных браузеров, но в мобильниках его не будет и вам как разработчику ничего не останется как в будущем писать на xhtml/xml для поддержки новыми устройствами.
PS Стоит отметить, что комментарии людей, полностью опровергающих его утверждения он просто удаляет, что иначе как подтасовкой и не назовёшь.
doctype это пометка для браузера (и только него) какой режим совместимости включать. На практике doctype xhtml strict мешает лишь вписывать в код страницы iframe, а во всём остальном соответствие ему позволяет делать разметку более близко к спецификации.
Аппаратное ускорение видео это слабое оправдание для окупания оборудования. Ну не стоит покупка видеокарты за $200 того, чтобы воспроизведение видео разгружало на 4% процессор за $100 тогда как он и так бОльшую часть времени простаивает.
ReadyBoost использует невосполнимый ресурс flash-память с ограниченным числом циклов чтение/запись что также бессмысленная трата в сравнении с организацией нормального swap на HDD.
американская звучит "you cost exactly as you payed" (ты стоишь ровно столько, сколько зарабатываешь)
в моём случае техническое задание учитывает пиковую нагрузку в 1-1.2млн хитов в сутки с учётом посещения 4х страниц каждым посетителем. В данный момент расчитывается сделать чтобы просмотр этих 4х страниц занимал не более 20 запросов (хитов) 16 из которых статические (картинки, скрипты, css). Задача не самая тривиальная, но и особой проблемы её реализация не представляет средние 12 запросов в секунду (25-30 на пике) можно реализовать и одним хорошим сервером, если удастся сделать статикой запланированный максимум запросов.
Кстати сделать ограничитель типа "не более 3х запросов за 30сек от одного IP" вполне возможно штатными средствами, чтобы те, кто часто жмёт refresh не сильно мешали сервису.
16.7 даёт корректное отображение стандартной картинки с глубиной 24 бита без всяких dither-эффектов. Это главный довод, из-за чего CRT до сих пор в строю.
Мадам знает толк в извращениях ©