Один из разработчиков Mozilla сообщил (http://blog.mozilla.com/products/2011/07/15/goals-for-multi-.../) о возобновлении работ, связанных с проектом Electrolysis (https://wiki.mozilla.org/Electrolysis), в рамках которого запланирован перевод Firefox на многопроцессную архитектуру, при которой пользовательский интерфейс и обработка контента будут обрабатываться разными процессами. Кроме того, рассматривается возможность использования многопроцессной модели для обеспечения полной изоляции отдельных вкладок, виджетов, групп вкладок и страниц одного домена.
Часть наработок проекта уже интегрирована в Firefox 4 и используется для выполнения плагинов в отдельных процессах. Кроме того, в Mobile Firefox 4.0 для платформы Android уже задействован механизм обработки вкладок разными процессами. Отмечается, что процесс перехода на многопроцессорную модель достаточно сложен и длителен, новая архитектура будет внедряться постепенно. Конкретные сроки не указаны, но с учетом 16-недельн...URL: http://blog.mozilla.com/products/2011/07/15/goals-for-multi-.../
Новость: http://www.opennet.me/opennews/art.shtml?num=31227
Да неужели... Возобновлили они. ВОЗОБНОВИЛИ! А какого, спрашивается, они его останавливали то? У этого проекта должен быть высший приоритет, они ночами спать не должны, а Electrolysis развивать. У Firefox и так сейчас самый тормозной интерфейс, а они только раскачиваться начали...
Они никому ничего не должны.
Ну да, конечно. А пользователи просто мимо проходят. Лис уже несколько месяцев стабильно долю теряет, не нужно быть экстрасенсом, чтобы понять почему. А они BrowserID и прочую чушь изобретают.
Пруфлинк http://gs.statcounter.com/
Это уже другой вопрос, возможно, так и запланировано.
Что-то не врубаюсь я в этот хитрый план. Не поясните? Может в таком случае лучше сразу свернуть проект, закрыть разработку?
"Just for fun" никто не отменял. Ну неинтересно разработчикам это делать, вот и не делают.
Зашибись логика. Только вот такой продукт тогда вообще людям показывать нельзя, пусть сами себе делают и сами с ним играются. Далеко они на таком принципе уедут? Скоро вообще все пользователи от них убегут, вообще никаких обязательств не останется. Будут сидеть, играться...
> Зашибись логика. Только вот такой продукт тогда вообще людям показывать нельзя, пусть сами себе делают и сами с ним играютсяа ктоже это людей ПИНКАМИ на www.getfirefox.com загонет? люди сами заходят и скачивают.. или сами рекламируют перед своими друзьями :-)
Эти господа весьма активно рекламируют свой продукт. Были бы средства как у гугла, они бы и по телевизору рекламу гнали. И при этом они абсолютно забивают на пользователей. Объясните мне, кому из них нужен Share или BrowserID? А кому нужна скорость? Думаю ясно, как должны быть расставлены приоритеты...
много думаете. шли бы лучше свой браузер писать
А по вашему пользователь думать вообще не должен. С какого перепугу я должен что-то писать, я не так много хочу. Всего лишь нормальной отзывчивости интерфейса. Которую кстати давно уже обещают, но пока как было тормозом, так и осталось. А в это время конкуренты без лишних слов все давно сделали. Что хром, что опера летают, а фокс - еле шевелится.
не так много хотите - значит вам не так много денег нужно перечислить разработчикам.
угомонись, истеричкавозьми скачай альфа-лису и окажи людям помощь - потести
Уже второй год на исключительно на альфах и сижу.
переходи на ночные сборки
Собственно я их и имею в виду. В новом цикле разработки nightly обозначаются как a1, т.е это альфы, а aurora - это a2
заметно что на них ты и сидишьназвание хоть ночных сборок в гугле нашел?
> Объясните мне, кому из них нужен
> Share или BrowserID? А кому нужна скорость? Думаю ясно, как должны
> быть расставлены приоритеты...думаю те инженеры которые занимаются BrowserID -- НЕ занимаются оптимизацией памяти броузера :-) . и это никак не связанно с тем что "они покачто заняты своими BrowserID". просто это *НЕ_их* область знаний :-)
Мозила создала "подразделение" которое устраняет проблемы с памятью.. в эти подразделения вошло определнное число инженеров....
...другие-же инженеры которые умеют делать чтото другое -- занимаются чемто другим.. (логично?) :-)
* * * * * * * * * * * * * * * * * * *
...кому из пользователей нужен BrowserID? да это главным образом технология для www-инженеров вобщемто(!), а не напрямую для пользователей :-)..
пользователи *вынуждены* НЕ пользоваться BrowserID (и *вынуждены* НЕ пользоваться OpenID), до тех пор пока их не начинают внедрять www-инженеры... даже если пользователи ОЧЕНЬ сильно хотят :-)
...BrowserID позицианируется как *первичный* способ авторизации на сайтах (а НЕ как вторичный способ типа OpenID). и не просто так, а благодаря своей архитектуре.
скажите -- где вы видили хоть один сайт, в котором можно былобы залогиниваться по OpenID_URL и при этом получить *полнофункциональный* вид аккаунта? (OpenID на тех сайтах где он есть -- это типичные гостевые учотные записи.. поэтому всё-равно приходится на техже сайтах регистрироваться через новый login/password.. бред-же, какой год на дворе)
BrowserID призван архитектурно-устранить в OpenID те недостатки которые помешали стать ему *первичным* способом авторизации... [оно и понятно -- авторизация через аудентификацию-с-привлечением-третьих-серверов -- не позволяет OpenID стать первичным. BrowserID производит аудентификацию пологаясь на криптографию, минуя сервера третьих сторон -- это совсем другое дело]
...и Мозилла в этом направлении сделала для всего человечества *очень* большой прогресс!
и вы можете например действительно (малоли!?) хотеть чтобы группа которая занимается BrowserID -- расформировалась... но даже если так случится -- врядле это скажется на эфективность работы группы-инженеров по устранению утечек памяти :-)
Есть третий вариант. Увольняем разработчиков BrowserID, на освободившиеся средства расширяем группу, занимающуюся электролизом. Все счастливы. А BrowserID можно и отложить до лучших времен, когда вылезут из той ямы, в которой они оказались с производительностью своего продукта.
> Есть третий вариант. Увольняем разработчиков BrowserIDУвольняем откуда, простите? :)
Из Mozilla Corporation, или где там они работают...
а кто ты такой что будешь увольнять людей?
Лично я никого увольнять не буду
так говоришь, кагбудто мог
> BrowserID производит аудентификацию пологаясь
> на криптографию, минуя сервера третьих сторон — это совсем другое дело]«пологаясь». my ass.
а то, что ты ни разу не знаешь, ни как работает опенид, ни как работает брофзерид — это из твоих слов попросту очевидно.
> Думаю ясно, как должны быть расставлены приоритеты...Спрошу как менеджер менеджера: у Вас-то что сейчас в приоритете?
// ныряя опять с напильником в один уже оживающий proof of concept
понаехало юзеров с проприетарщины. Это опен сорс, абсолютли ноу ворранти.
>Скоро вообще все пользователи от них убегутБегите, не задерживайтесь.
Не хочу я от него бежать. Он мне нравится своей настраиваемостью, не могу я уже в других браузерах работать. Но такое отношение разработчиков к первостепенной задаче мне не нравится.
не хочу, не могу, не нравится... красна девица
деньги разработчикам уже перевел?
При чем тут мои деньги? Я должен заплатить им, чтобы они сделали нормальный продукт? Да и я сильно сомневаюсь, что чьи-то деньги что-нибудь изменили. Скорее они пошли бы на тот-же BrowserID, а то и новый проект какой-нибудь запилили. Очень уж любит mozilla дурью мучиться.И да, не нужно мне хамить, я к вам уважительно отношусь.
При том, что тратить личное время разработчики за бесплатно не всегда хотят. А тем более решать сложные задачи оптимизации. А вот BrowserID попилить вечерком, ради лулзов, самое то.
А что лично ты сделал для того, чтобы ускорить интерфейс фаерфокса?
А что я могу сделать? Электролиз за них написать? Так я не программист. Если знаете, как это можно сделать, напишите. Если не знаете, то к чему вообще вы это написали?
т.е. сам ничего не сделал, деньги разработчикам зажал, а они, стало быть, должны?
ты какбе можешь пересесть на быстрый ие9, сафари или хром.
или найти денег и нанять индусов который запилят тебе в фаерфокс нужные тебе вещи
Непрограммисты больше всего клок волос и вырывают...
> Только вот такой продукт тогда вообще людям показывать нельзяЛюдям можно показывать все, что угодно.
> вообще никаких обязательств не останется.
Их и не было никогда.
> Пруфлинк http://gs.statcounter.com/это откудаже такие говноданные? доля IE больше 43% ???!! да не смешите мои тапочки, IE плятётся на уровне 20% :-D
не иначе как статистика M$.com
ты даже не осилил внимательно прочитать ссылку которую цитируешь. Ниже картинки глаза не осилил опустить ?
> Пруфлинк http://gs.statcounter.com/
И даже тут доля фф упала...
Себе должны. Если не хотят оказаться в хвосте и похерить свой долгий труд, то игнорировать такие вещи уж точно не стоит.
> У этого проекта должен быть высший приоритетПоддерживаю. Это же очевидно. А зачем минусуют? Неужели никому непонятно?
> У этого проекта должен быть высший приоритет, они ночами спать не должны, а Electrolysis развивать. У Firefox и так сейчас самый тормозной интерфейс, а они только раскачиваться начали...Что-то я не уверен что он будет быстрее при 50 процессах на 50 табах. Хватило бы 1 отдельного процесса для основного интерфейса для отзывчивости. Хорошо что притормозили в общем.
Вот-вот, из-за их промедления в данном вопросе я пишу это сообщение не из Firefox, а из Chrome.
Предсказуемое потребление памяти. Ключевыми проблемами Firefox остается большая фрагментация памяти, трудности с перераспределением памяти, невозможность отдачи уже полученной от ОС памяти, утечки памяти. Данные проблемы не являются специфичными для Firefox и неизбежно возникают у любого длительно работающего процесса, интенсивно манипулирующего блоками памяти.тоесть по их логике течет абсолютно все?:)
Утечка памяти != фрагментация памяти. Фрагментированную память можно дефрагментировать. А утечка есть утечка, это занятая память. Короче, читай про динамическое распределение памяти, кучу, стек и т.д., потом пиши сюда комменты
А никто утечки с фрагментациями и не ровнял. Утечек тоже избежать можно, путём правильной приоритезации процессов и верным динамическим распределением/балансировкой памяти приложений. И делать это можно не только на уровне системного планировщика, но и на уровне самого приложения, вводя квоты/лимиты потребления и операции высвобождения памяти в процессе его работы.
> Утечек тоже избежать можно, путём правильной приоритезации процессов и верным динамическим распределением/балансировкой ..blahblahblah<утечки-памяти> -- это <ошибки> инженеров .. причём БАНАЛЬНЫЕ ошибки (граничащие вообще с опечатками), а не ошибки неправильной архитектуры
[например инженер может создать (банально опечатавшись) внутри структуры-цыклической-природы -- СИЛЬНУЮ ссылку вместо СЛАБОЙ.. и тем-самым получить неудаляемуй объект, в определённых условиях]
о каких ещё планировщиках вы говорите? :-)
избежать утечек памяти -- можно.. да... нужно "всеголишь" допускать меньше ошибок (не допускать ошибок при работе с ресурсами/памятью) :-)
а <фрагментация-памяти> -- это НЕ <ошибки> инженеров
> а <фрагментация-памяти> -- это НЕ <ошибки> инженеровЭто ошибка программистов. Получил блок памяти на таб, использовал, закрыл таб, отдал память. Места для утечки и фрагментации нет. Почему так не работает?
>> а <фрагментация-памяти> -- это НЕ <ошибки> инженеров
> Это ошибка программистов. Получил блок памяти на таб, использовал, закрыл таб, отдал
> память. Места для утечки и фрагментации нет. Почему так не работает?Не все так просто, когда память выделяется динамически и блоками фрагментация неизбежна. Но собственно в найтли версии это уже исправили.
что исправили? фрагментацию? так она неисправима, как и баги в программах
> что исправили? фрагментацию?метод выделения блоков памяти и их сортировку.
И что им мешает арены какие-нибудь для вкладок использовать? Нет, надо наваять GC. Как будто нет опыта его использования и никтоне знает, как неэффективно системы с GC (тем более самопальным в плюсах) используют память.
>>Данные проблемы не являются специфичными для Firefox и неизбежно возникают у любого длительно работающего процесса, интенсивно манипулирующего блоками памятиSCADA системы годами работают без перезагрузок, и ничего. Всё дело в руках.
Неужели я дождусь быстрого лиса! А то уже как полгода на хром перешел. Тянет обратно, но как только попользуюсь, понимаю, что уже привык к скорости.
ИМХО, долго ждать придется. Они уже года 2 назад рассказывали, как хорошо будет жить простому юзеру под многопоточным фоксом. Думаю, при лучшем раскладе, раньше какого-нибудь firefox 15 мы электролиз не увидим. Хотя отрисовку Direct2D в процесс уже в 8 версии обещают (сначала обещали в 7, не факт, что не перенесут на 9)
какую еще отрисовку?
https://wiki.mozilla.org/Platform/Features/ElectrolysisTextu...
что ещё за direct2d ? O_o
сейчас подвисает одно ядро, добьёмся, чтобы подвисали все!
Всем сразу не угодишь - либо долгий плавный переход с кучей legacy к новой архитектуре, либо резкий скачок к новой архитектуре. И в том, и в том случае потеря N пользователей.
На момент появления FF ситуация была другой, многоядерность не была главной тенденцией и многопроцессность не давала столько преимуществ. А Chrome появился недавно, уже в эту эпоху и сразу был спроектирован под текущую ситуацию.
Время покажет кто быстрее - Mozilla сменит ахрхитектуру FF или Google наберёт пользовательскую базу и базу разработчиков расширений Chrome.
>И в том, и в том случае потеря N пользователей.Неправильно. В одном случае потеря N пользователей, в другом M.
Загадка:
N ? M
А мне вот лично глубоко наплювать чего там и как с архитектурами, реализациями, процентами и т.д.... сижу на Фоксе уже 6 лет, хотя пробывал за это время пользоваться различными другими браузерами (не потому что Фокс не устраивает, а просто - посмотреть дабы). Да - Опера быстрее, и Хром быстрее, и Макстон вебкитовый быстрее... но однако почему-то при всех их плюсах через 1-2 часа работы в них начинает тянуть запустить ОгнеЛис.
Причем, вот вроде бы все быстрее открывается, интерейс отзывчивее, и расширений куча для того же Хрома, а вот все равно в итоге запускаешь ОгнеЛис и продолжаешь работать в нем.
Я чот не понимаю первого абзаца... Смешались в кучу треды-кучи.
Я так понимаю аффтары мурзилки с ПОТОКАМИ не очень знакомы?
Если-бы они делали ЮИ в одном потоке, а кучу сгребали в другом -- глядишь и не тормозило-бы.А ещё проще -- делали-бы новую кучу каждые ХХ times и когда на старую ссылок не оставалось-бы уничтожали её. Возможен вариант с копированием в новую кучу, если данных достаточно мало.
В упор не понимаю зачем многопроцессность, если есть треды.
В статье же написано зачем. Если у вас есть опыт разработки програмных комплексов, то станет понятно, что весь функционал складывать в один процесс потоками - опасно и для безопасности программы(глюк в одном, а падает весь функционал, общее адресное пространство), отладки, скорости, и т. д. Да и реализация тредов разная везде.
по ссылке инфо подробнее, включая обсуждение в комментариях.> Я так понимаю аффтары мурзилки с ПОТОКАМИ не очень знакомы?
Ах моська, знать она не глупа раз лает на ...
Многопроцессность имеет еще одно преимущество перед многопоточностью: продление жизни 32-битных архитектур. Сегодня многие приложения (особенно написанные на C++) уже упираются в лимит 32-битной виртуальной адресации. Разнеся функциональность по нескольким адресным пространствам в примерно равных пропорциях, остроту проблемы можно снизить в несколько раз, не меняя логику распределения памяти в программе.
> Многопроцессность имеет еще одно преимущество перед многопоточностью: продление жизни
> 32-битных архитектур.Да кому они сча упёрлись. Эти 32 бита. У тех у кого 32 всё равно памяти не хватит чтобы несколько процессов Мурзилки выдержать :)
да и на один-то не особо. потому что точка монтирования рук у разработчиков того… несколько ниже, чем требуется.