Комментарии 78
64 только под мак планируется? а Windows?
забыл добавить
Though 64-bit Windows is now arriving, «It's not one of our supported-tier platforms,» Beltzner said.
Though 64-bit Windows is now arriving, «It's not one of our supported-tier platforms,» Beltzner said.
Неофициальные билды и Mozilla for Windows x64 спешат на помощь: www.mozilla-x86-64.com/
Сейчас у меня замечательно работает их билд FF 3.5b4 на Win 7 RC.
Сейчас у меня замечательно работает их билд FF 3.5b4 на Win 7 RC.
Я, право же, опасаюсь того, что изоляция процессов сверх меры усложнит сочинение некоторых видов расширений для Файерфокса. Если прежде можно было невозбранно передавать данные между разными окнами и тем более вкладками, то теперь придётся продираться дебрями межпоточной синхронизации, что не особенно вдохновляет меня, например.
думаю для этого предвидят облегчающие механизмы…
Несомненно. Но покамест чтение Mozilla.Dev.Planning и Mozilla.Dev.Platform не вселило в меня никакого особого оптимизма.
Однако, есть и свои плюсы… Честно говоря с выхода третьего FF все компьютеры, на которых я его пользую(особливо мак) стали сильно много задумываться… А рабочий компьютер с линухом так и вообще подвешивает фаерфокс при загрузке даже с 4! вкладками, правда не на долго. Если вкладок 12 — навсегда:)
Ну или по крайней мере терпения не хватило дождаться. А уж как раздражают подвисания всего фаерфокса из-за того, что начал подгружать тяжелую страницу… А компьютер рабочий не такое уж и говно — 1 гигабайт оперативы + 2.6ггц целерон.
Обидно, что огнелис 3 получился столь кривым…
Может конечно все дело в фаербаге, адблоке и pagespeed, но в этом я сильно сомневаюсь..:)
Ну или по крайней мере терпения не хватило дождаться. А уж как раздражают подвисания всего фаерфокса из-за того, что начал подгружать тяжелую страницу… А компьютер рабочий не такое уж и говно — 1 гигабайт оперативы + 2.6ггц целерон.
Обидно, что огнелис 3 получился столь кривым…
Может конечно все дело в фаербаге, адблоке и pagespeed, но в этом я сильно сомневаюсь..:)
Firefox 3.5 вроде бы стал быстрее думать на джаваскрипте, так что это может решить проблему прежде, чем выйдет Электролиз (Электролис).
Вообще говоря, странно, т.к. у меня с выходом третьего FF все страницы открываются быстрее и грузится тоже быстрее. Единственная проблема — sqlite, т.к. когда большая история посещений и много введенных данных, он закрывается долго. Но это лечится периодической очисткой этих данных.
Само по себе разделение на процессы не ускорит, а замедлит работу браузера на однопроцессорных системах, так как к самому происходящему коду добавится ещё межпроцессовая обвязка.
Просто теперь торможение одной вкладки не станет мешать другим, быть может. А на многопроцессорных системах ещё может случаться ускорение за счёт распараллеливания процессов на разные процессоры.
Просто теперь торможение одной вкладки не станет мешать другим, быть может. А на многопроцессорных системах ещё может случаться ускорение за счёт распараллеливания процессов на разные процессоры.
Про linux ни слова… А у меня там kubuntu 64bit…
Под kubuntu64 бегает еще так. Полгода сижу на 3.5 «shiretoco» build. Флеш через ж, конечно. Минимальное количество девелоперских плагинов пашет ок.
$ file /usr/lib64/firefox/firefox
/usr/lib64/firefox/firefox: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), stripped
Особой быстроты по сравнению с 32 битами не видно.
кеш ремонтировать не собираются… я так понимаю…
НЛО прилетело и опубликовало эту надпись здесь
НЛО прилетело и опубликовало эту надпись здесь
Главное преимущество изоляции процессов вкладок не в том, что они падают по отдельности (далеко не каждый день у меня Firefox вылетает), а в том, что их можно обрабатывать разными ядрами процессора. Что меня, как обладателя 4-ядерного процессора, действительно радует. Очевидно, что сайты будут становиться всё более тяжёлыми и мультимедийными, повсеместно будет внедрена видеореклама и т. п. Для комфортной работы в интернете требуются всё более мощные компьютеры. А увеличение мощности процессоров теперь идёт распараллеливанием на ядра. В i7 уже 8 логических ядер.
Кстати, вкладки ведь на то и вкладки, что смотришь-то только одну. Остальные большую часть времени бездействуют. Т.е. их процессы иногда можно будет и вообще «замораживать», на системном уровне. Страницы памяти долго простаивающих процессов выгружать и т.п.
В общем, есть надежда не только на повышение надёжности, но и скорости работы именно по этой причине. Хотя лично мне и так хватает, и того, и другого. Просто редко открываю слишком много вкладок, вовремя закрываю неактуальные, благо есть удобная история.
В общем, есть надежда не только на повышение надёжности, но и скорости работы именно по этой причине. Хотя лично мне и так хватает, и того, и другого. Просто редко открываю слишком много вкладок, вовремя закрываю неактуальные, благо есть удобная история.
Представь. Только ты выгрузил вкладку, а пользователь тут же на нее ткнул. Из кэша грузить ее будет дольше. Сразу же будет вердикт — новая версия ФФ тормозит.
Я предположил, что таким образом ФФ может выгружать долго бездействующие вкладки, в том случае, когда их много, а памяти уже мало. Т.е. в случае, когда система и без ФФ скорее всего скинет эти страницы памяти на диск. Сделает она это абы как, система же не знает, что там у ФФ записано. А ФФ знает. И по принципу «не трогайте, я сама» сделает тоже самое более осмысленно. А значит — быстрее. И быстрее восстановит.
Ничего интересного короче
мне одному кажется, что Мозилла уже не новатор и разработка ФФ стала по времени больше в сравнение с предыдущими версиями и другими браузерами?
Могу назвать одну особенность, которая в свежем Файерфоксе есть, а в других свежих браузерах вроде бы покуда отсутствует.
Это поддержка элемента <video> (из языка HTML 5) для подключения видеозаписей, записанных свободными и открытыми кодеками.
На www.tinyurl.com/Opera-10-lacks-video с грустью и недовольством сказывают, что даже в наипоследнейшей сборке Оперы 10 эта функция покамест отстутствует.
Это поддержка элемента <video> (из языка HTML 5) для подключения видеозаписей, записанных свободными и открытыми кодеками.
На www.tinyurl.com/Opera-10-lacks-video с грустью и недовольством сказывают, что даже в наипоследнейшей сборке Оперы 10 эта функция покамест отстутствует.
НЛО прилетело и опубликовало эту надпись здесь
и версия наверно будет ни 3.6 а 4.0!
Лиса… лиса… IE8 рулит!
Судя по названию Namoroka, выйдет он видать нескоро. )
А когда он уже перестанет жрать по 500-600 мб оперативной памяти к концу рабочего дня?
Тогда, когда люди научатся программировать клиентские приложения (фф тут непричем)
при чем тут когда научатся? это архитектура лисы такая изначально — все, что можно — на жабоскрипте, в т.ч. собственно интерфейс браузера, плагины и т.д, XUL чтоб его… А жабо скрипт порождает утечку памяти. где-то. :)
[s]посмотрите например на Opera — там везде С++, поэтому она такая маленькая и не жрет столько..[/s]
[s]посмотрите например на Opera — там везде С++, поэтому она такая маленькая и не жрет столько..[/s]
У меня при 2Гб оперативы, к концу рабочего дня под 1000-1200 кушает.
Ха, теперь с системой изоляции плагинов, ФФ будет тормозить еще медленнее. Может тогда людт перестанут им пользоваться.
К тому же как же их XUL, у них же весь браузер — это большая XML/HTML-страница, как они его интересно распараллелят.
К тому же как же их XUL, у них же весь браузер — это большая XML/HTML-страница, как они его интересно распараллелят.
НЛО прилетело и опубликовало эту надпись здесь
Например, движок на Си++, со своим языком для оформления (не тормозной HTML, и чтобы описание интерфейса на этом языке быстро рендерилось и компилировалось в бинарную форму, кешировалось и все такое), без Яваскрипта (ибо тормоз и память ест), может Lua но лучше C++ или D (или C# какой нибудь на крайняк, но не знаю насчет его производительности) и без CSS. То есть Xul но на други хтехнлоггиях, специально для этого придуманных.
HTML/CSS/javascript — в общем, неэффективные техгнологии для создания интерфейса, неэффективные в плане сложнности обработки и затрат ресурсов, следовательно надо сделать что то другое. Но на это надо много сил и времени, чего у Mozilla скоре всего нет. Ну тут, выбор или сделать быстро, или сделать качественно.
И еще. Плохо, что Firefox (как и многие другие проекты Open Source) основвывается на старых-рпестарых разработках, лучше бы его спроектировали с нуля, а так, когда над кодом много лет работают разные команды, получается не самый лучший результат.
И еще раз еще. Цена за кроссплатфорпменность должна быть разумной, нельзя чтобы программа из-за этого работала намного медленнее, или отказывалась от каких то выажных опций (имхо).
HTML/CSS/javascript — в общем, неэффективные техгнологии для создания интерфейса, неэффективные в плане сложнности обработки и затрат ресурсов, следовательно надо сделать что то другое. Но на это надо много сил и времени, чего у Mozilla скоре всего нет. Ну тут, выбор или сделать быстро, или сделать качественно.
И еще. Плохо, что Firefox (как и многие другие проекты Open Source) основвывается на старых-рпестарых разработках, лучше бы его спроектировали с нуля, а так, когда над кодом много лет работают разные команды, получается не самый лучший результат.
И еще раз еще. Цена за кроссплатфорпменность должна быть разумной, нельзя чтобы программа из-за этого работала намного медленнее, или отказывалась от каких то выажных опций (имхо).
НЛО прилетело и опубликовало эту надпись здесь
> У вас есть результаты бенчмарков, чтобы рассуждать об эффективности?
У меня есть опыт верстки. Простые вещи приходится делать всякими извратными способами, начиная например с вертикального выравнивания средстваими css. И я представляю себе, как происходит обработка, парсинг файлов, испольнение яваскрипта, чтобы иметь примерное предсьтавление об их неэффективноти. Все существующие браузеры (кроме ИЕ6, но у него свои недостатки) едят огромное количество памяти и работают медленно. Если бы (просто представим) интерфейс писать с использвоанием winAPI, программа будет потреблять в десятки раз меньше системных ресурсов. Я не призываю писать на WinAPI, простои привожу пример что можно сделать намного лучше.
Кроме того, в HTML очень легко сделать «тяжелую» верстку, например как на Хабре, когда при открытии страницы с большим количеством комментариев браузер просто подвисает. Казалось бы, что такое 200 комментариев по 200 байт каждый для компьютера с десятками миллионов байт оперативной памяти и быстродействием больше миллиарда операций в секунду, а он подвисает. О чем это еще говорит. кроме как неэффективности HTML/CSS (или их парсеров).
И Вообще, мы все знаем что эта технлогия делалась для отображения научных документов (преимущественно текстовых). Тяжелое наследие этого мы чувствуем до сих пор. Для интерфейсов нужно что-то другое.
> Они решили переписать весь код заново
Странно, я думал, только коммерческие разработчики ставят приоритетом захват рынка, а Open Source сообщество могло бы поставить качество — им-то что захватывать?
У меня есть опыт верстки. Простые вещи приходится делать всякими извратными способами, начиная например с вертикального выравнивания средстваими css. И я представляю себе, как происходит обработка, парсинг файлов, испольнение яваскрипта, чтобы иметь примерное предсьтавление об их неэффективноти. Все существующие браузеры (кроме ИЕ6, но у него свои недостатки) едят огромное количество памяти и работают медленно. Если бы (просто представим) интерфейс писать с использвоанием winAPI, программа будет потреблять в десятки раз меньше системных ресурсов. Я не призываю писать на WinAPI, простои привожу пример что можно сделать намного лучше.
Кроме того, в HTML очень легко сделать «тяжелую» верстку, например как на Хабре, когда при открытии страницы с большим количеством комментариев браузер просто подвисает. Казалось бы, что такое 200 комментариев по 200 байт каждый для компьютера с десятками миллионов байт оперативной памяти и быстродействием больше миллиарда операций в секунду, а он подвисает. О чем это еще говорит. кроме как неэффективности HTML/CSS (или их парсеров).
И Вообще, мы все знаем что эта технлогия делалась для отображения научных документов (преимущественно текстовых). Тяжелое наследие этого мы чувствуем до сих пор. Для интерфейсов нужно что-то другое.
> Они решили переписать весь код заново
Странно, я думал, только коммерческие разработчики ставят приоритетом захват рынка, а Open Source сообщество могло бы поставить качество — им-то что захватывать?
>>будет тормозить еще медленнее
То есть работать будет быстрее?
То есть работать будет быстрее?
честно говоря, не помню, когда у меня фаерфокс падал из-за незащищенного треда или сбоя чего-то там в табе…
а вот сколько памяти эта жирная лиса отжирает каждый раз — отлично помню!
а вот сколько памяти эта жирная лиса отжирает каждый раз — отлично помню!
Еще 3d планируют вроде как
lenta.ru/news/2009/03/25/web/
lenta.ru/news/2009/03/25/web/
лучше бы они его наконец-то под Cocoa переделали, а то такой колхоз от Mozilla в Snow Leopard'е это слишком
Да, этого не хватает, но я очень сильно сомневаюсь, что они будут этим заниматься. Очень.
Единственное, что наполняет моё сердце толикой надежды это то, что они живо интересуются 64-биткой под Мак.
Единственное, что наполняет моё сердце толикой надежды это то, что они живо интересуются 64-биткой под Мак.
Тогда уж пусть лучше Camino крутят пошустрее и функциональности добавляют имхо. Плагинов, например, очень не хватает. Есть там какие-то, но хотелось бы лисячьи.
«Естественно нас ждет улучшение быстродействия» omg ;)
Только вот деньжат в эпоху кризиса на новую 64-х битную аппаратуру пока нет :-)
Только вот деньжат в эпоху кризиса на новую 64-х битную аппаратуру пока нет :-)
64 bit… 64 bit…
сижу щас на 3.5 beta99, работает на ура и быстрее намного чем 3.0.11 при том что это только бета, представляю что будет когда будет релиз. Вообщем Mozilla красавцы =)
столько раз падал хром, и падал целиком, несмотря на все уверения
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что нас ждет после Firefox 3.5?