Спасибо за поддержку. Меня просто немного раздражает прямолинейный маркетинг. Потому что на сайте, скажем, Сафари - он "самый быстрый", у Оперы - она, IE8 проходит тест ACID2, который вроде как сломан.
Большинство будет пахать, а некоторые пашут уже сейчас, если отключить проверку версий. Плюс насколько я понял для плагинов написали новую подсистему (точнее библиотеку), так что они теперь должны работать быстрей.
Потому что все браузеры по разному поддерживают CSS. Я на эту тему писал статью когда-то, где jQuery рассматривалась именно как библиотека для верстальщика. Просто надо найти определенный компромисс: что описывать с помощью CSS, а что выносить в скрипты. В первом случае - самые универсальные вещи, по втором - то, что по разному поддерживается или требует хитрых выборок и действий. ИМХО, разумеется. :)
Согласен с вами по поводу jQuery - она полностью кроссбраузерная и позволяет работать на только с CSS-селекторами, но и с XPath (правда в последний версии этот функционал вроде вынесли в плагин). И вес к тому же в 4-5 меньше.
Позволю себе с вами не согласиться по поводу недостаточной продуманности и архитектуры. Данная ошибка фактически относиться к низкоуровневым, и при том проявляется в достаточно нестандартном окружении (по крайне мере для иностранных разработчиков) - под линуксом и в русской локали. Разработчики все-таки больше ориентируются на других пользователей, а данный баг мог исправить только отечественный разработчик (еще раз спасибо Олегу Крылову). А к продуманности и архитектуре это не относиться.
Фактически у ФФ на данный момент есть только одна проблема с архитектурой, которую видно не вооруженным глазом - фрагментация памяти.
Спасибо за толковое объяснение. Про то, что плагин (точнее "расширение", а еще точнее "дополнение" :) ) надо обязательно сказать. Насколько я понял он также не у всех работает должным образом.
Насколько я понимаю плагины пишутся не на Си - так что это не универсальное решение. А сейчас код добавлен прямо в ядро, правда насколько я его смотрел немного костыль напоминает, но я могу ошибаться, потому что у меня опыта с GTK - нет.
Это не мое интеврью - его брал насколько я понял один из админов Mozilla Russia - ragnaar (внизу статьи есть ссылка). Мне просто понравилось очень интервью, потому что на такие программисты вносят большой вклад в развитии Open Source.
Баги фиксить - может быть, если время будет. Вообще багов должно быть минимум - ведь будет объявлен тендер на разработку трояна, одним из условий которого будет отсутствие ошибок.
Я надеюсь, что они выпустят пакеты для популярных линукс-дистрибутивов, чтобы не компилировать. А то еще не все смогут собрать и установить.
В третьей версии как раз переписали аллокатор для XPCOM, но этого явно не достаточно. Во-первых, большинство программистов вообще за отказ от этой компонентной модели (это будет сделано в четвертой версии), а во-вторых, использование другой модели распределения приведет к необходимости переписания других частей браузера. Поэтому "просто" выбрать другой способ организации памяти, получиться не раньше четвертой версии, а нам остается только в настройках выставить освобождение памяти при минимизации и урезать размер кеша в памяти.
Полностью с вами согласен. Уже второй раз натыкаюсь на перевод этой статьи и один хуже другого. В данном случае сильно подкачало название :(
Более того, людям, которые хотят почему огенный лис ест много памяти (особенно под никсами), крайне рекомендую немного изучать программирование, особенно почитать о фрагментации памяти и об аллокаторах. Тогда станет понятно, что не всякая утечка - ошибка программиста, а просто способ организации выделения памяти.
Один из разработчиков писал в блоге, что по его замерам проблемы прежде всего кроются именно в не самом эффективном способе выделения памяти, особенно под кеш изображений.
Так что вы хотели, батенька. У этих страниц выше релевантность по мнению яндекса, и наверное на них больше тематических ссылок. Самому подобные квесты решать не приходилось, ибо пользуюсь гуглом, а он больше любит оригинальные тексты. Разумеется, все выше сказанное, ИМХО.
Фактически у ФФ на данный момент есть только одна проблема с архитектурой, которую видно не вооруженным глазом - фрагментация памяти.
http://weblogs.mozillazine.org/roadmap/a…
Я надеюсь, что они выпустят пакеты для популярных линукс-дистрибутивов, чтобы не компилировать. А то еще не все смогут собрать и установить.
Более того, людям, которые хотят почему огенный лис ест много памяти (особенно под никсами), крайне рекомендую немного изучать программирование, особенно почитать о фрагментации памяти и об аллокаторах. Тогда станет понятно, что не всякая утечка - ошибка программиста, а просто способ организации выделения памяти.
Один из разработчиков писал в блоге, что по его замерам проблемы прежде всего кроются именно в не самом эффективном способе выделения памяти, особенно под кеш изображений.