https://opennet.dev/openforum/vsluhforumID3/77868.html Спустя всего несколько дней с момента устранения прошлой уязвимости (http://www.adobe.com/support/security/bulletins/apsb11-13.html) компания Adobe выпустила (http://www.adobe.com/go/getflash) внеплановое обновление Flash Player с исправлением очередной критической уязвимости (http://www.adobe.com/support/security/bulletins/apsb11-18.html). Проблема может привести к повреждению областей памяти Flash-плагина и запуску кода злоумышленника при обработке специально оформленного контента. В сети уже зафиксированы факты успешной эксплуатации уязвимости и появление Web-страниц, специально оформленных для проведения атаки на пользователей. <br><br><br>Проблеме подвержены все версии Flash Player, включая 10.3.181.23. Проблема устранена в версии 10.3.181.26 (http://www.adobe.com/go/getflash), которая уже доступна для платформ Windows, Solaris, Mac OS X и Linux. Обновление для платформы Android планируется выпустить до конца текущей недели.<br><br>URL: http://www.adobe.com/support/security/bulletins/apsb11-18.html<br>Новость: http://w https://opennet.dev/openforum/vsluhforumID3/77868.html#86 Fri, 17 Jun 2011 08:40:42 GMT &gt;Пирамида изображающая из 32-битной математики 64-битную, да еще на полутора убогих регистрах х86 запросто может это скомпенсировать. А поскольку нынче даже диски и файлы большие и без 64-битных чисел там не обходится - в любой программе так или иначе что-то с 64-бит числами может делаться.<br><br>стоимость кеш-промахов из-за раздутого кода может быть (т.е. на практике - как правило) больше, чем выгода от единичных 64-битных вычислений (если только их не большинство)<br> https://opennet.dev/openforum/vsluhforumID3/77868.html#85 Fri, 17 Jun 2011 02:30:36 GMT &gt; А я, наивный, смотрю ютуб в webm и почему-то не жалуюсь. Странно. <br><br>Наверно что-то посерьёзнее Pentium M 1.6? ;-)<br> https://opennet.dev/openforum/vsluhforumID3/77868.html#84 Thu, 16 Jun 2011 09:33:30 GMT Если RAM освобождатся не будет то надо проверить не осталось ли ссылок из js в dom обьект видео.<br> https://opennet.dev/openforum/vsluhforumID3/77868.html#83 Thu, 16 Jun 2011 08:16:58 GMT Если нельзя пользователям указать какой браузер использовать то без сторонних плагинов (как минимум для доп поддержки формата видео) никак. (я бы сразу посоветовал google chrome frame для IE)<br><br>Я бы резал бесконечные потоки на куски время от времени меняя src. Уже законченное &lt;видео&gt; можно убирать из DOM, по идее RAM память должна освободится.<br><br>Записать эти данные перед убиранием в кеш браузера можно в хроме, но не прямо на файловую систему, хотя кто их знает куда они сохраняют такую штуку как window.requestFileSystem(type, size, successCallback, opt_errorCallback) http://www.html5rocks.com/en/tutorials/file/filesystem/<br><br> https://opennet.dev/openforum/vsluhforumID3/77868.html#82 Thu, 16 Jun 2011 06:38:30 GMT Есть видеосервер, он концентрирует потоки с разных видеоисточников, преобразует и отдает клиентам. Нет файлов, это бесконечные потоки "реального времени". Вот и возникает вопрос, как сделать отображение такого потока в браузере без флеш ? Теоретически можно сделать так чтобы поток отдавался из URL и указать его в src &lt;video&gt;, но во первых насколько я понимаю это будет приводить к сохранению всего полученного в браузере, потому как &lt;video&gt; предполагает перемотку назад и повтор проигрывания, что в случае длительного просмотра (а так оно по условию задачи) приведет к забитию памяти (диска) и пр. косякам т.к. &lt;video&gt; не предназначен для просмотра бесконечных потоков, а рассчитан на конечные файлы. Во вторых, в каком формате гнать поток с сервера, половина клиентских браузеров (IE) насколько я понимаю хотят H264, остальные VP8 ?<br> https://opennet.dev/openforum/vsluhforumID3/77868.html#81 Thu, 16 Jun 2011 03:51:31 GMT Есть, но она застряла на версии 10.2.p3, не развивается, ошибки в ней не исправляют. хотя пользоваться ей можно.<br> https://opennet.dev/openforum/vsluhforumID3/77868.html#80 Thu, 16 Jun 2011 03:46:40 GMT &gt; А html5 в последнем ФФ - это показ диафильма.<br><br>А я, наивный, смотрю ютуб в webm и почему-то не жалуюсь. Странно. <br> https://opennet.dev/openforum/vsluhforumID3/77868.html#79 Thu, 16 Jun 2011 03:34:59 GMT &gt; Чтобы сделать mmap 20 гигабайтного файла и его могли эффективно совместно читать <br>&gt; 20 процессов.<br><br>Да даже без ммапов, если смещение в файле будет более 4Гб, это надо адресовать 64-битным числом. И файловая система будет везде 64-бит числа педалить. И драйвер диска как минимум 48-битные. Получается что 64 битные регистры - как-то и не лишние совсем в современном мире.<br><br> https://opennet.dev/openforum/vsluhforumID3/77868.html#78 Thu, 16 Jun 2011 03:27:06 GMT &gt; Зато адресация рагульная- <br><br>Что значит - рагульная? <br><br>&gt; привет модели памяти.<br><br>Модель памяти там получше чем у некоторых. По крайней мере, в х64 додумались наконец то сделать относительную адресацию. Алилуйя! Может хоть костыли типа релокейшнов отвалятся (это суть костыль убогой архитектуре, не умеющей относительную адресацию).<br><br>&gt; Опять. При интенсивной работе с памятью не факт что будет выигрыш.<br><br>Выигрыш или проигрыш - сильно зависит от того что программа делает. Если программа вообще не пользуется 64-бит числами и потребляет мало памяти - выиграть ей особо не на чем.<br><br>&gt; Так что нифига не все так радужно. Но кому принципиально иметь &gt;3G RAM<br>&gt; тому таки да, полезно. <br><br>Учитывая цены на оперативку, вполне можно это уже себе позволить в ряде случаев. Кстати, 32-битной программе как правило проблематично использовать по дефолту более 2 Гб. Даже если это нужно. <br>