Firefox 32 перешёл (http://www.mozilla.org/en-US/firefox/32.0beta/releasenotes/) на стадию бета-тестирования, что ознаменовало прекращение формирования базовой функциональности и сосредоточение всего внимания на выявлении ошибок и контроле качества. Одновременно сформирована (http://www.mozilla.org/en-US/firefox/33.0a2/auroranotes/) aurora-ветка Firefox 33. Новые возможности Firefox 33 ещё точно не утверждены, так как на стадии тестирования aurora-ветки будет произведена оценка готовности для релиза тех или иных новшеств. Загрузить бета-выпуск можно на данной странице (http://www.mozilla.org/firefox/beta/), а aurora-версию здесь (http://www.mozilla.org/firefox/aurora/). Релиз Firefox 32 намечен на 2 сентября, а Firefox 33 на 14 октября.Улучшения, ожидаемые (https://www.mozilla.org/en-US/firefox/33.0a2/auroranotes/) в Firefox 33:
- В Firefox встроена реализация (http://www.opennet.me/opennews/art.shtml?num=39898) аудио- и видеочата, построенного с использованием технологии WebRTC и доступного для вызова через меню. Реализация примечательна тем, что позволяет напрямую организовать канал связи между двумя браузерами с поддержкой WebRTC без передачи трафика через промежуточные серверы, без установки внешних плагинов, на любых устройствах и операционных системах.Код чата построен с использованием платформы OpenTok (http://tokbox.com/opentok/), предоставляющей средства для организации прямой передачи видео между пользовательскими системами. Для организации безопасного шифрованного P2P-соединения между браузерами применяются API PeerConnection и DataChannels с использованием шифрованного транспортного протокола DTLS (http://en.wikipedia.org/wiki/Datagram_Transport_Layer_Securi... (http://en.wikipedia.org/wiki/Secure_Real-time_Transport_Prot... и системы организации установки сетевых соединений ICE (http://en.wikipedia.org/wiki/Interactive_Connectivity_Establ.... Для передачи контента применяются аудиокодек Opus (http://en.wikipedia.org/wiki/Opus_(audio_format)) и видеокодек VP8 (http://en.wikipedia.org/wiki/VP8).
- Интеграция поддержки видеокодека H.264 за счёт использования открытой компанией Cisco библиотеки OpenH264 (http://www.opennet.me/opennews/art.shtml?num=38662). &n...Бинарную сборку библиотеки OpenH264 можно задействовать в сторонних продуктах без каких-либо ограничений и отчислений, так как компания Cisco в данном случае выступает лицензиатом MPEG LA. Проект Mozilla воспользовался данной особенностью и предоставил пользователям возможность загрузки подходящего для текущей операционной системы кодека с сайта Cisco (по умолчанию библиотека не входит в состав Firefox). Основными мотивами поддержки H.264 в Firefox является предоставление средств для работы с уже существующим накопленным в Сети контентом и обеспечение совместимости с другими браузерами, до момента широкого распространения свободного кодека Daala (http://www.opennet.me/opennews/art.shtml?num=37242).
- Переработаны механизмы хранения строк и обработки строковых данных, что позволило сократить потребление памяти и увеличить производительность строковых операций. Ранее все символы в строке хранились в UTF-16 и занимали два байта, теперь символы диапазона Latin1 занимают один байт. В итоге, при открытии англоязычного интерфейса Gmail потребление памяти на хранение строк сократилось почти в два раза, с 11 до 6.4Мб. Для кириллицы выигрыш не столь ощутимый, но всё равно значительный с учётом того, что около 30% строковых данных на таких сайтах подпадают в диапазон Latin1 за счёт HTML-разметки и JavaScript-кода.
<center><a href="https://blog.mozilla.org/javascript/files/2014/07/JS-String-... src="http://www.opennet.me/opennews/pics_base/0_1406407672.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
Кроме того, внесены оптимизации, позволившие хранить большую часть мелких строковых данных в inline, без выделения для них отдельных областей в куче. Помимо сокращения потребления памяти указанные изменения позволили добиться повышения прозводительности за счёт более быстрой обработки однобайтовых данных. Например, тест regexp-dna из состава Sunspider стал выполняться на 36% быстрее на системах x86/x64 и 48% на ARM. В тесте Kraken JSON ускорение составило 11% для x86/x64 и 20% для ARM;- Проведена работа (https://dutherenverseauborddelatable.wordpress.com/2014/06/2... по увеличению надёжности сохранения резервных копий внутренних БД и обеспечению гарантированного восстановления после сбоя;
- Добавлен новый бэкенд CSP (Content Security Policy), обеспечивающий интеграцию в web-браузер специального HTTP-заголовка для защиты от организации межсайтового скриптинга (XSS) и подстановки в страницы "IFRAME/JavaScript src" блоков;- Расширены возможность поиска с вводом запроса в адресной строке;
- В JavaScript добавлена поддержка типа Symbol (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... определённого в спецификации ECMAScript 6 и применимого для идентификаторов свойств объектов;
- Представлен программный интерфейс DOMMatrix;
- Прекращена поддержка отладочного сервиса JSD (JavaScript Debugger Service) в пользу Debugger API (http://developer.mozilla.org/en-US/docs/Tools/Debugger-API);- В инструменты для разработчиков добавлено средство для наглядной оценки перерисовываемых элементов и добавлен редактор кривых Безье;
- Улучшения в версии для платформы Android:
- Возможность восстановления случайно закрытой вкладки;
- Интерфейс для просмотра недавно закрытых вкладок;
- Функция закрытия сразу всех вкладок;
- Опция автоматического переключения на новую или приватную вкладку;
- Опция для очистки данных после завершения сеанса.Улучшения, представленные (https://www.mozilla.org/en-US/firefox/32.0beta/releasenotes/) в бета-версии Firefox 32:
- Задействована (http://www.janbambas.cz/new-firefox-http-cache-enabled/) по умолчанию новая подсистема локального кэширования HTTP-запросов, в которой представлено много улучшений, в том числе оптимизированная для первой отрисовки система приоритезации запрсоов, поддержка предварительной загрузки для ускорения отображения больших объемов контента, режим отложенной записи для исключения блокировок при первой отрисовке, поддержание пула наиболее часто используемых заголовков HTTP-ответов, быстрая проверка наличия данных в кэше по индексу, более продвинутый алгоритм вытеснения устаревших данных из кэша, защита от повреждения кэша из-за краха браузера, более низкое потребление памяти;
- Интеграция сборщика мусора Generational Garbage Collector (https://wiki.mozilla.org/JavaScript:GenerationalGC), который позволяет достигнуть более высокой производительности и уменьшить потребление памяти в ситуации хранения большого числа объектов, живущих короткое время;
- Включена (https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinn... поддержка механизма привязки открытых ключей (Public Key Pinning), позволяющего явно определить сертификаты каких удостоверяющих центров допустимо использовать для заданного сайта. Если для установки защищённого соединения применён валидный сертификат выписанный иным удостоверяющим центом, соединение будет отвергнуто из-за подозрения в MITM-атаке с использованием поддельного сертификата;- Поддержка соединения к HTTP-прокси с использованием защищённого канала связи (HTTPS);
- Прекращено доверие для некоторых (https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NS... 1014-разрядных корневых сертификатов;
- Увеличена производительность менеджера дополнений и системы управления паролями;- В панели поиска обеспечено отображения числа найденных на странице совпадений;
- В менеджере паролей добавлена возможность просмотра метаданных логина;
- Vibration API приведён...
URL: http://www.mozilla.org/en-US/firefox/32.0beta/releasenotes/
Новость: http://www.opennet.me/opennews/art.shtml?num=40280
> http://www.opennet.me/opennews/pics_base/0_1406407672.pngну и куда подевались умники, который думали что 32-бита (i386~i686) ЯКОБЫ экономит прям-как-офигеть-сильно используемую память , по сравнению с 64-битами (x86_64) ? :-)
что якобы память почти-вся забита сплошняком укозателями :-).. ХАХАХАХА! [я смеюсь вам в лицо!]
видели картику? воткнули? осознали правду-матушку?
Умники такого не говорили, да и вообще читай про что график.
Умники остались при своём мнении.
Если бы ты читал внимательно, то понял почему цифры на 32-х и 64-х битных системах схожи.
Во-первых, в тексте и на графиках приводится объём строк, а строки в основном это (парам-парам!) символы, которые в обоих системах занимают один и тот же объём.
Во-вторых, в тексте сказано, что маленькие строки стали размещаться в стеке, а не в куче, что совсем не увеличивает расход памяти, т.к. стек всегда фиксированного размера.
> Во-первых, в тексте и на графиках приводится объём строк, а строки в основном это (парам-парам!) символы, которые в обоих системах занимают один и тот же объём.ну тык -- если детально рассматривать каждую подсистему -- то в итоге так и получиться -- что то-одни-то-другие данные.
где-то строки, где-то массивы чисел (в i686 и x86_64 -- числа тоже занимают одинаковый объём).. где-то наборы bitmap-данных.
этих указателей там кот наплакал -- по сравнению со всем остальным!
Кстати, далеко не все числа имеют одинаковый размер. В плюсах гарантированно разный имеют size_t, ptrdiff_t и т.п.
и long разный. (может быть и не разным по спецификации. но на практике разный).и что?
ты понимаешь о чём я -- мало кто использует long. а size_t это вообще специфичный тип и нужен он лишь в тех местах где нужен size_t.
ни кто не будет тебе делать массив из чисел size_t! :-) .. это нонсенс! :-)
обычные числа -- это либо обычный int , либо uint32_t\sint64_t\uint32_t\sint64_t с явным указанием размера. вот из них и будут делать массивы!
> и long разный. (может быть и не разным по спецификации. но на
> практике разный).
> и что?
> ты понимаешь о чём я -- мало кто использует long.Прочтите определение struct timespec и удивитесь. Ну, то есть, многие могут и не замечать, что они передают-правят, но ведь факт-то налицо. И это просто ПЕРВЫЙ пример, пришедший из головы. Можете запустить теперь поиск ручками по исходникам, отличных от ваших собственных, и удивиться.
> а size_t
> это вообще специфичный тип и нужен он лишь в тех местах
> где нужен size_t.
> ни кто не будет тебе делать массив из чисел size_t! :-) ..
> это нонсенс! :-)libstdc++, Perl, libssl, vi, unbound... Это то, что простенький egrep нашёл за несколько минут на уже валяющихся локально исходниках.
Специфичный? Так у всего на свете есть своя специфика. У компиляторов, например, есть специфика - в результате своей работы частенько сообщают о проблемах в исходном коде программ... и что?
> обычные числа -- это либо обычный int , либо uint32_t\sint64_t\uint32_t\sint64_t с явным
> указанием размера. вот из них и будут делать массивы!Массивы будут делать из того, что нужно сейчас и для текущей задачи. От того, что вы по жизни считаете в основном посетителей на сайтах, считальщики секунд до попадания ракеты в чей-то борт не становятся малозначимыми. И наоборот.
Ну я из таких умников. Причем я лично это дело мерял - потребление памяти 64-битными версиясми файрофкса и старой Оперы было примерно в полтора разв больше, чем у 32-битных. И, как ты понимаешь, не верить своим галазам и измерениям у меня оснований нет. Впрочем, когда эти оптимизации долетят до SeaMonkey (я файрфоксом не пользуюсь теперь) - повторю, может правдв хорошо соптимизировали.Ну и, опять же, просто из программистского опыта - любая сложная система обычно состоит в основном из указателей. Так как "All problems in computer science can be solved by another level of indirection".
А вообще - в кои-то веки приличнные версии должны быть, мало шелухи и много оптимизаций. Теперь ждем пока оно до SeaMonkey дойдёт.
Оно все так же тормозит на слабых компьютерах в отличии от хрома?
кто ж знает то.в эпоху когда новые компьютеры стали такими дешёвыми -- о том что происходит на старых (слабых) компьютерах -- теперь можно только догадываться :-) ..
если только случайно найти на мусорке старый (слабый) компьютер -- то вот только тогда можно было бы узнать -- тормозит ли там Firefox или нет :-D
и вот ещё какой вопрос -- что с этой информацией делать?
допустим что я как-то смог узнать тормозит ли оно там. (предположим что тормозит). и что дальше? как это мне может помочь?
всё равно ведь сидеть за слабым (старым) компом ни кто не будет, так как там даже банальное DE будет тормозить и нервировать..
Зачем так много текста о том, что вам неведомо? Недавно мучился с двумя такими агрегатами. ФФ лучше хрома работает, тормозит только с флешем.
Этого в биореактор.
>всё равно ведь сидеть за слабым (старым) компом ни кто не будетЯ сижу. И буду сидеть ещё долго.
> И буду сидеть ещё долго.не угадал. :)
и ,кстати, чем быстрее ты это сам поймёшь -- тем будет для тебя же и лучше
Ты преувеличиваешь значение жирносайтов и Крузиса.
> Ты преувеличиваешь значение жирносайтов и Крузиса.можно поработать-на-работе недельку и купить на заработанные деньги комп, на котором программы не тормозят. (но игры будут тормозить -- да. или вообще не пойдут)
и спрашивается -- зачем тратить нервы ковырясь со старой ржавой техникой? :)
ну ладно. допустим вы не согласны. но тогда просто на материнской плате старого компа -- высохнут\взбучатся конденсаторы -- и комп начнёт зависать на ровном месте. и после этого всё равно придётся пойти и потратить 7000 рублей на новый комп.
просто вам повезёт, если конденсаторы высохнут побыстрее. и побыстрее сломается этот ваш старый комп. хоть после этого вы перестанете мучиться :-)
Пока нынешняя техника работает как часы -- никто не мучается.
Хром, который на нескольких вкладках гига 2 отжирает махом, определённо для слабых компьютеров.
оно все так-же тормозит на Nvidia :-\
не всегда. иногда перманентно (часами) жрет проц, вне зависимости от того какие вкладки открыты, и открыты ли вообще.
У меня как раз комп на 500 мб ОЗУ. Айсвизел чувствует себя нормально. От Хрома пришлось избавиться по причине отжирания при многих открытых вкладках. Ну и фф лучше интегрируется в линукс, что ни говори. Альтернатив ему не вижу.
>У меня как раз комп на 500 мб ОЗУ.Огласите видеокарточку, пожалуйста.
ATI Radeon 9600 128мб
Спасибо. У меня с одним гигом памяти и FX 5700 128mb с проприетарным драйвером геккообразные еле ворочаются.
>У меня как раз комп на 500 мб ОЗУ.Держись! там
Да мне больше и не надо, всё летает. Вот 256 мб уже в наш век не хватает, тут я не спорю.
> Поддержка API Encrypted Media Extensions, развиваемого организацией W3C и реализующего элементы поддержки DRM (Digital Rights Management) для организации защиты от копирования видеоконтента, встраиваемого в web-страницы через HTML5-тег video.Лучше бы поддержку WebP запилили https://bugzilla.mozilla.org/show_bug.cgi?id=856375
Зачем? WebP ведь не нужен.
Ты не нужен
>Включена поддержка механизма привязки открытых ключей (Public Key Pinning), позволяющего явно определить сертификаты каких удостоверяющих центров допустимо использовать для заданного сайта. Если для установки защищённого соединения применён валидный сертификат выписанный иным удостоверяющим центом, соединение будет отвергнуто из-за подозрения в MITM-атаке с использованием поддельного сертификата;Джва года ждал
Пару месяцев назад пытался мигрировать с Chrome на Firefox. Хватило на неделю. Открыл для себя Maxthon так на нем и остался.синхрони
Что, непривычно без зонда в анусе?
Как бы на зонды мне всегда плевать было. Просто ушел с гугл почты, и встал вопрос о смене браузера, ибо в хроме привязка своей почты для синхронизации, только платная. На Firefox может быть и остался бы, да только на него некоторых расширений не оказалось, которые работают в Maxthon от Chrome. А так как Maxthon облачный браузер, да еще и Flash от хрома прикручивается без плясок то выбор был очевиден.
> да еще и Flash от хрома прикручивается без плясок то выбор был очевиден.кто же тебе мешал всегда сидеть на Firefox, но при этом открывать (в другом окне) Google Chrome в момент когда ты захотел поиграть в Весёлого_Фермера (или что у вас там, любителей flash-игрушек)
Толсто. Здесь только два варианта. Либо вы плохо подумали перед тем как это написать, что считаете что Flash нужен только для игр и прочих развлечений. Либо вам просто еще нечем думать а следовательно пора за учебники так как 1 сентября в школу.
> Flash нужен только для игра для чего же ещё? раскажите-ка нам
все популярные видео-хостинги уже работают без flash. (а не популярные -- настолько не популярны и унылы [1tv.ru , russia.tv] -- что можно и не думать о них даже).
а может быть вы любитель лицезреть яркую-динамичную-пёструю flash-рекламу? :-D
--------------------------------------------------
отказаться от flash (и от adobe reader) -- это значит в том числе обезапастить себя от вирусов.
держать flash на готове только из-за того что *вдруг* где-то он понадобиться -- слишком рисковано, так как больше вероятности что появиться вирус на компьютере чем сайт который нужно будет прям необходимо (во_что_бы_то_ни_стало) открыть через flash.
Жирнота 100%
Давно оставил попытки мигрировать на chrome c firefox
Давно мигрировал на seamonkey, да там и остался.
Вот бы ещё разработчики аддонов на него мигрировали.
Больше половины расширений требуют только правки манифеста. Хотя кое-что (например, последний Scrapbook) хотелось бы, конечно.
>синхрониВнезапно активировался зонд?
>> Открыл для себя Maxthon так на нем и остался.синхрони
> Внезапно активировался зонд?ахахаха! сделал мой день! :-D
>до момента широкого распространения свободного кодека DaalaОн так и не распространится никогда - хомячки будут упорно жать в h264, как сейчас жмут DivX-ом и XviD-ом, мотивируя это совершенно бредовыми выкладками. Посмотрите на mp3 - уже давно есть vorbis, aac и opus, но люди и не думают уходить с него, причём используют самый примитивный режим сжатия с постоянным битрейтом, вместо намного более продвинутых и качественных ABR и VBR. Это карго культ отягощенный синдромом утёнка и пока YouTube жрёт avi'шки, а производители браузеров внедряют h264 - он будет процветать.
>В инструменты для разработчиков добавлено средство для наглядной оценки перерисовываемых элементов и добавлен редактор кривых Безье
Да чоужтам пилите сразу полноценный векторный редактор в браузере, а то Inkscape вроде бы загнулся.
>Новый инструмент Web Audio Editor для инспектирования графа AudioContext и изменения свойств узлов AudioNodes;
И свободных DAW что-то маловато - запилите в браузер и его. Заодно и свою реализацию графов DirectShow сделайте - мне их под Линуксом всегда нахватало.
Почему все браузеры со времён ишака пытаются стать полноценной ОС или хотя бы неотделимой её частью?
Потому, что большинство использует компьютер в качестве запускалки браузера.
И когда им (крайне редко) надо запустить что-то другое они поднимают рёв: "не хотим выходить из браузера в страшный мир ОС, программ и прочих непонятностей. Впилите нам почтовик, аудиоплеер и сиськи в браузер."
Разработчики впиливают.
У некоторых получается Опера, у кого-то хромОСь, а у тысяч других просто говно.
Опера уже не получается.
Не лучше ли выкатить обзор почле релиза?
Вообще-то кормёжка обещаниями — главная черта современного развитого общества. Это вы в средневековье привыкли хвалиться готовыми результатами.
В плане потребления памяти i386 более рационально использует данный ресурс. Как минимум на 20% меньше, и как максимум до 2-х кратного превосходства над x86_64. Оптимизация в браузере носит частный характер.
когда же во фрайерфокс крайзис запилят? долго ждать ещё?
Как у него дела с производительностью? 640 ядер хватит всем?
Новость интересная, но почему нет более ранней информации о выпуске тормозиллы- альфа? :-)
Перешёл на Огнелиса (30.0) с Хромиума. Блин, насколько же удобнее. Только плагин Zoom Page ведёт себя черезжопно — сайты не увеличивает, хотя некоторые настроены на текст 170%. У кого-нибудь также происходит?
И где взять бетку 32 для Суси?
> Блин, насколько же удобнееИнтерфейс шлак, некоторые спецификации веба шалят и css тоже ...
Плюсы: Потребление памяти, производительность намного выше нет тормозов при повторном DNS request
Интерфейс нормуль. Зато HTML5 на Ютюбе везде пашет. )
> некоторые спецификации веба шалят и css тожеЛол, это можно сказать про любую версию любого браузера.
на стабильной мозиле это более всего заметно.
Ты мало смотрел на то, что порой вытворяет Хром, не говоря уже об Ишаке.
