Кстати список всех уволенных:
http://ex-mozilla.org/date.html

На текущий момент - 784 человека.

Да, попытка сделать броузер конкурент для IE не удалась, прямо скажем

>>>Да, попытка сделать броузер конкурент для IE не удалась, прямо скажем.

Да, согласен, сложно конкурировать с MS по количеству требуемых машинных ресурсов, дырок в защите и дегенеративному интерфейсу. Прямо скажем, НЕВЕРОЯТНО сложно!

2Cybem: да ладно вам. IE работает явно быстрее мозиллы. И интерфейс весьма и весьма удобен. Дырки в защите, конечно, есть, но не так много, как принято считать. Последний год-два они подправили ситуацию. А что будет с мозиллой - поживём увидим. Найдут спонсора - будет развитие, не найдёт - загнутся.

Похоже это список не уволенных сейчас, а уволенных за последние несколько лет.

все, пипец мазиле.

По потребляемым ресурсам Mozilla, безусловно, вне конкуренции :-)

>IE работает явно быстрее мозиллы. И интерфейс весьма и весьма удобен

Скорость - понятно за счет чего.

А про интерфейс: на вкус и цвет товарищей нет (догадался что пропустил?).

Скорость скорости рознь. Например у меня страницы грузятся не в пример IE быстрее. Но что ресурсы жрет, то жрет.

У нас в офисе уже 70% перешли на мозиллу.
Она просто уделала и ИЕ и аутглюк и ОЕ и оперу по всем статьям.
Последней каплей стал спам-резак...

Есть недостатки у мозиллы и первый из них - отсутствие стабильной и одновременно достаточно фичастой версии. Надеюсь, 1.4 станет со временем как раз такой.

Мозилла уже давно плывет сама и нетскейп ей только помеха. Наконец то развитие пойдет по более естественному пути - пути наращивания стабильности и скорости, а не каких достижение то неизвестных целей АОЛ. АОЛ и броузер просрал и аську просрет...

Это всё фигня. Mozilla.org уже основали фонд поддержки разработки. Среди участников которого числится и AOL.
Кроме того, новая версия Gecko в броузере Firebird (бывший Phoenix) гораздо эффективнее чем существующий, так что весь опыт Neyscape идёт лесом.

2Ikonta_521: мне, как пользователю, по барабану, за счёт чего эта скорость. А удобство - действительно, дело вкуса. Но сказать, что у него денегератиынй интерфейс - это извините. Налицо религиозная нетерпимость. Несерьёзно это как-то. Не надо бояться признать, что МС что-то сделали хорошо, надо постараться это перенять.

Тут вот вспомнилось, чего мне не хватает в мозилле: загрузки картинок по требованию. Ради экономии трафика я отключил графику. Но иногда нужно какую-нибудь картинку посмотреть. В ИЕ можно по правой кнопке докачать конкретную картинку, а в мозилле приходится лезть в настройки, разрешать графику и обновлять страницу. Неудобно... Собственно, это основная причина, почему я не перешёл на мозиллу, когда работаю под виндой

епта я под виндой мазилу юзаю уже лет 5, на лялих перейду тоже ее буду юзать. да, она хочет ресурсов больше ие, но показывает все быстрее. и все держит, в отличие от всяких ие и глючных опер. а файроберд просто сказка

To Eugene_Korobko (*) (2003-07-16 19:40:11.685332)

То, чего тебе так нехватало появилось в Mozilla 1.4. Также по правой кнопке выбираешь View image и получаешь то, что хотел.

Это организационно-административное событие:

http://www.gnomedesktop.org/article.php?sid=1222

Да избавляется AOL от балласта... А что касается фондов, то это все по большому счету фигня, т.к. ну дала AOL денег (2млн), но этого хватит максимум на год (из расчета что будет работать 12-15 человек).

Получаю.... В новом табе :( Версия 1.4

>Также по правой кнопке выбираешь View image и получаешь то, что хотел

Получаю.... В новом табе :( Версия 1.4

For Korobko http://www.xulplanet.com/downloads/prefbar/

>>IE работает явно быстрее мозиллы. И интерфейс весьма и весьма удобен

>Скорость - понятно за счет чего.

А расскажи, а? За счет чего скорость? Мне непонятно. Я всегда думал, что MS в IE просто код хороший написали. А на самом деле используют турбинный акселератор софта, который также куплен у какой-нибудь компании, которая занимается тюнингованием программ от MS :)...Brabus от софта :)

Скорость IE обусловлена тем, что чась критического кода MS выполняется в привелегированом уровне - т.е. уровне ядра.

2Llama:

> Скорость IE обусловлена тем, что чась критического кода MS выполняется в привелегированом уровне - т.е. уровне ядра.

Одно слово - Бред.

> 2Cybem: да ладно вам. IE работает явно быстрее мозиллы. Eugene_Korobko (*) (2003-07-16 17:29:55.042898)

Если сравнивать скорость мозиллы под винду и ИЕ, то последний работает, может чуть шустрее. Но если сравнить ИЕ и мозиллу под линух, твой ИЕ рядом не валялся. Мозилла под линух, имхо, работает даже шустрее, чем опера под винды.

2 Llama: Ой, насмешил :)... Где бы IE не располагался, скорость его работы от этого не зависит! Код в любом кольце работает с одинаковой скоростью :)

> 2Ikonta_521: мне, как пользователю, по барабану, за счёт чего эта
> скорость. А удобство - действительно, дело вкуса. Но сказать, что у
> него денегератиынй интерфейс - это извините. Налицо религиозная
> нетерпимость. Несерьёзно это как-то. Не надо бояться признать, что
> МС что-то сделали хорошо, надо постараться это перенять.

Ничё что я за Ikonta отвечу? ;-)

Евгений, честно говоря, Gecko быстрее движка IE. Говорю это как прожжённый "виндузятник" :) Но что есть то есть.
Просто этот народ стал, вместо того, чтобы довести движок до совершенства и сделать его пригодным для _лёгкого_ встраивания в другие приложения (вообще-то можно, но через Ж) - ставить эксперименты с интерфейсом и т.д.
В результате, к сожалению, имеем хороший задел со странной реализацией.

А тормозит у мозиллы только интерфейс, рендеринг тут ни при чём. Хотя от этого не легче.

2Zubok (*) (2003-07-16 21:12:41.305964):

> А расскажи, а? За счет чего скорость?

Скажи лучше, хренли тебя в аське не видно? ;-)))

Скорость IE обусловлена тем, что основная часть кода постоянно находится в памяти. Даже если ни одного окна IE не открыто.

2последний аноним: Я тебя разочарую, но и ты не угадал, ибо то, что у IE некоторые основные библиотеки в памяти (это так и есть), то это влияет только на скорость запуска и без того маленького code trace Ослика. Но вот если ты уже запустил браузер, то можно же уже утверждать, что он уже весь в памяти? Ведь так? Вот теперь и начнем сравнивать, и сравнение будет не в пользу Мозиллы. А вот похожие результаты показывает сравнение Opera vs. IE.

А проблемы все в all-in-one архитектуре Мозиллы (которая должна измениться в скором будущем), а также в том, что используется XML GUI (XUL), а также в том, что есть пока проблемы с X Window System по производительности.

2Zubok:
Графика в нулевом кольце. Как в ДОСе - прямо в видеопамять шарашили.
Поэтому и рисует он быстро, несмотря на тупой код, и междумордие не
тормозит.

> Gecko быстрее движка IE. Говорю это как прожжённый "виндузятник" :)

Тут не могу привести сколько-нибудь весомых аргументов против, ибо помню, что ты там очень давно игрался с ActiveX-компонентом для встраивания Мозильного движка.

Но и сейчас Мозильный движок слишком огромен. В нем нет true modularity. только сейчас началась работа по разбиению Мозиллы на куски. Чем это все кончится -- посмотрим. Ведь столько приложений ждут этого. Нужно, к примеру, к какому-нибудь небольшому приложению посмотреть быстренько хелп на html. Бац -- загрузилась маленькая часть мозиллы, которая отвечает за парсинг html и рендеринг (с/или без css -- можно было бы выбрать через API Gecko Runtime), нужно в интернет "по большому" -- загрузилось все, что нужно (причем тут тоже можно сделать так, что JavaScript, например, загружается по требованию). Ну и т.д. Можно много приложений привести, где нужен хороший движок. Например, можно вспомнить такие приложения, как RealPlayer и др, которые имеют в себе малюсенькие браузеры для обеспечения необходимого сервиса. Нужно почту посмотреть с вложенными html -- пожалуйста. Я на минутку представил себе, как я только что полученное письмо получаю в быстром Sylpheed, а потом нажимаю на прикрепленный html и... о боже... грузятся 10 Мб кода!!!). Вот от безысходности в одной из веток sylpheed прикручивают этот... pure html browser Dillo... который не то, чтобы JavaScript не умеет, он CSS не умеет :)))

Потом не надо забывать, что есть такая тема, как Embedded и PDA, куда пихать теперяшнюю Мозиллу... впрочем, не буду о грустном. ;) А ведь это потерянные рынки, недополученная известность проекту...

> Просто этот народ стал, вместо того, чтобы довести движок до совершенства и сделать его пригодным для _лёгкого_ встраивания в другие приложения (вообще-то можно, но через Ж) - ставить эксперименты с интерфейсом и т.д. В результате, к сожалению, имеем хороший задел со странной реализацией.

Вот-вот...

> А тормозит у мозиллы только интерфейс, рендеринг тут ни при чём. Хотя от этого не легче.

Да и рендеринг я пока нахожу не шибко быстрым. Я бы его окрестил так: приемлемый по времени. Вот у Оперы рендеринг быстрый... она такая живенькая, быстренькая... :)

> Скажи лучше, хренли тебя в аське не видно? ;-)))

Мой анлимит приказал долго жить :)... Пока захожу, но эпизодически... Возможно, не встретились ;)

2Die-Hard: Ответь на вопрос: куда по-твоему шарашит графику X Server после того, как получил необходимые команды по X Protocol на отрисовку битмапов, прямоугольников, щрифтов? :)... В COM-порт? В USB? Но ведь как-то графика появляется в памяти видеокарты? Мистика :) А как ты думаешь, зачем XFree86 при старте выясняет, распределение памяти у видюхи? Уж не для того, чтобы туда писать? А зачем делали специализированные XFree86_S3, XFree86_Mach и прочие сервера? понятно, что рисование идет тоже напрямую. Или ты думаешь, что напрямую в устройства писать может только код в нулевом кольце? :)

Кстати, а что ты имел в виду про "междумордие"? Это переключение между несколькими окнами Mozilla? Это да... так и есть... но кто в этом виноват? скорее всего все звенья цепи -- GUI Mozilla и XFree86.

> Ответь на вопрос: куда по-твоему шарашит графику X Server после того, как получил необходимые команды по X Protocol на отрисовку битмапов, прямоугольников, щрифтов?

Ключевое слово - "после". Запросы эти тоже надо сформировать/раскодировать.

> Или ты думаешь, что напрямую в устройства писать может только код в нулевом кольце? :)

Да. Запросы к устройствам, сделанные в непривилегированном коде обычно перехватываются и обрабатываются кодом в нулевом кольце.

2Zubok (*) (2003-07-16 23:40:11.219844):

"Как в ДОСе - прямо в видеопамять шарашили" - образное выражение, смотри на прошедшее время. Программы, пользовавшие БИОСовские/ДОСовские функции, тормозили, а шарящий пипл шарашил в видеопамять.

Графика в нулевом кольце позволяет минимизировать цепочку оберток (хотя в НТе этого сделать не удалось ввиду дебильной архитектуры), напрямую программировать контроллеры и (главное) избегать накладок на переключение контекста при бегании из нулегого кольца в пятое при системных вызовах.

> Ключевое слово - "после". Запросы эти тоже надо сформировать/раскодировать.

Об этом я тоже ужа написал в пункте -- "виновата Xfree86" (принцип или реализация -- оффтопик) :)

> Да. Запросы к устройствам, сделанные в непривилегированном коде обычно перехватываются и обрабатываются кодом в нулевом кольце.

Тут ты не совсем прав, как мне кажется. В защищенном режиме есть возможность (которая называется aliasing), которая позволяет отобразить на одно и то же физическое адресное пространство (в нашем случае видеопамять) разные области с разными логическими адресами (изолированными). Могу подкрепить слова ссылками на текст про программирование в защищенном режиме :)

Скорее всего, для прямого доступа в видеопамять из пользовательского кольца и используется этот механизм, но только с разрешения ядра. Скорее всего, есть там какой-нибудь системный вызов, который позволяет создать в пользовательском кольце логическое адресное пространство для прямого доступа к видюхе, но только туда и никуда больше! Как конкретно это реализовано в ядре Linux -- я не знаю (но для общего интереса я постараюсь выяснить этот вопрос). Никаких перевызовов явно не осуществляется, иначе эта ОС стала бы явным лузером на рынке :)... Вы только подумайте, если при каждой записи в видеопамять была какая-то обертка? Вы бы в TuxRacer бы не резались ;)

***Offtopic***

Кто нибудь знает как к dillo русский подрулить? Заранее спасибо!

2Zubok & Die-Hard: вы бы сначала определились кто больше жрет CPU -- сам движок рендеринга, то бишь процесс трансляции хтмл-кода в лейаут и операции отрисовки или сами операции отрисовки (давайте их разделим?). В первом случае и спорить бессмысленно.

2 последний аноним: Да понятно, что наше обсуждение взаимодействия с видеопамятью уже далеко ушло от темы Мозиллы, но раз уж затронули... :)

Надо еще много чего разделить. Надо отделить еще скорость отрисовки GUI, занимаемую память и много чего другого. У меня сейчас на машине стоит два браузера, сделанных не на XUL -- это Opera и SkipStone (последний на Мозилловском движке, но морда на GTK+, т. е. я исключил из сравнения неповоротливость XUL). Opera оказалась посто рекордсменом по скорости парсинга/рендеринга по сравнению со SkipStone. Скорость именно парсинга я предпочел сравнивать на скорости открытия HTML-файлов, содержащих много по-разному форматированного текста без графики (по-моему, весьма честный тест). Опера открывает файлы просто моментально и толоса прогресса уходит вверх (файлы, напомню очень большие) с огромной скоростью. SkipStone просто делает это нереально долго. Потом переключение между "мордами" в Opera очень быстрое в Linux (хуже, конечно, чем в виндах, но все же)...

2Zubok: в линухе это сделано так: у X-сервера есть MIT-SHM екстеншн (see xdpyinfo), который позволяет клиентским колам напрямую писать в память X-сервера (читай в видеопамять), выкидывая X-протокол нах&й. Если бы было иначе, никаких 3Д-шутеров и фильмов под линухом не было бы в прынципе.

2Die-Hard: касательно нашего обсуждения про видеопамять. Читать надо про Linux Mamory Mapping (mmap). С помощью системных вызовов можно делать следующие вещи:

1. Memory Allocation in the Kernel 2. Translation Virtual to Kernel Virtual Address 3. *внимание* Mapping Kernel Virtual Addresses into User Space 4. Mapping non-kernel Virtual Addresses into User Space

*Наверное*, svgalib, а также DirectFB, а также расширения DRI, DRM, DGA у иксов используют именно этот механизм для доступа к адресным пространствам видеопамяти и адресным пространсвам драйверов для framebuffer. Вот.

> Тут ты не совсем прав, как мне кажется. В защищенном режиме есть возможность (которая называется aliasing), которая позволяет отобразить на одно и то же физическое адресное пространство (в нашем случае видеопамять) разные области с разными логическими адресами (изолированными). Могу подкрепить слова ссылками на текст про программирование в защищенном режиме :)

Не знал, что это так называется. Память в адреса процесса естественно отобразить можно, но ты хорошо знаешь механизм реализации этой байды на х86? ИМХО, тут либо при каждом щелчке шедулера переписывать таблицы страниц (в коде уровня 0 :) ), либо обрабатывать (в коде уровня 0 :) ) page fault при каждом обращении к якобы видеопамяти. И при этом заморачиваться с синхронизацией.

Ссылками пожалуйста подкрепи - не хочу погибать в невежестве.

> Вы только подумайте, если при каждой записи в видеопамять была какая-то обертка? Вы бы в TuxRacer бы не резались ;)

А зачем собственно нужна "прямая запись в видеопамять"? Или аппаратное ускорение уже отменили? Удобней же сказать "нарисуй линию от сих до сих", чем менять цвета пикселей. Аппаратный Х Server - вот светлое будущее.

anonymous (*) (2003-07-17 01:25:12.357306): Так это ты не мне говори :)).. Я же и говорю, что так и делается. А вот это SHM extension делает mmap напрямую в /dev/mem, скорее всего (хотя сейчас появились более быстрые методы, которые позволяют ускорить работу при работе иксов с linux kernel framebuffer (если таковой используется). Например, mtrr в ядрах Linux.

anonymous (*) (2003-07-17 01:36:12.680059): Да игрушки это отдельная песня. Речь тут шла про обычный такой... наш родной... пользовательский интерфейс. А, проще говоря, про обычные пиктограммки, картинки, джипеги, гифы :))... Их отрисовка к ускорению для игрушек мало какое отношение имеет. Рисование любой пиксельной картинки. фотографии и пр. всегда когда-то заканчивается записью в видеопамять) :)

народ, вы в какую-то байду ударились :(. При чем здесь линух? :) Есть X-сервер, который реализует посредством драйвера видеокарты доступ к видеокарте, как он это делает это его личное дело (может, например, аппаратно реализовать GL-операции), повторю еще раз: клиентские колы могут посредством MIT-SHM екстеншна (то бишь через shared-memory X-сервера) поиметь видеопамять. Или вас интересует как X-сервер имеет драйвер? (нет, ну я согласен конечно, что драйвер это часть ядра)

> Рисование любой пиксельной картинки. фотографии и пр. всегда когда-то заканчивается записью в видеопамять) :)

Но вот рассчитывать какое значение в какое именно место видеопамяти записать (а также кэшировать загруженные картинки) должна именно специальная железка. Нех тратить на это ресурсы центрального процессора. :)

> повторю еще раз: клиентские колы могут посредством MIT-SHM екстеншна (то бишь через shared-memory X-сервера) поиметь видеопамять.

Вот я и интерересуюсь, как реализовано это расширение для линуха на х86. Чудес-то ведь не бывает.

> Память в адреса процесса естественно отобразить можно, но ты хорошо знаешь механизм реализации этой байды на х86? ИМХО, тут либо при каждом щелчке шедулера переписывать таблицы страниц (в коде уровня 0 :) ), либо обрабатывать (в коде уровня 0 :) ) page fault при каждом обращении к якобы видеопамяти. И при этом заморачиваться с синхронизацией.

Я думаю, что в случае с видеопамятью (которая физически не "размазана" по RAM и свопу, а является сплошным куском, который стоит намертво и не свопируется, и не перемещается никуда) работа Page Fault Handler'а сильно упрощена. Не надо, например, постоянно вычислять физическую страницу. Достоточно получить ее только при первом обращении к ней со стороны приложения. Поэтому overhead тут весьма невелик... Да потом еще учти, что есть и кеш у процессора.

Кстати, сейчас в ядре Linux есть определить стратегию работы с видеопамятью через регистры MTRR напрямую из пользовательского кольца! Это дает значительное ускорение, но эти регистры появились только, кажется, начиная с P-II.

anonymous (*) (2003-07-17 02:06:31.57784)

> Вот я и интерересуюсь, как реализовано это расширение для линуха на х86. Чудес-то ведь не бывает.

Все драйвера видеокарт в XFree86 работают в user-space. Для того, чтобы тебе работать в видеопамятью напрямую, тебе достаточно устройства /dev/mem. Его открываешь в режиме shared-memory, указываешь, сколько памяти тебе надо и область:

Открываешь девайс: f = fopen("/dev/mem", "r+"); Шаришь видеопамять: videbuf = mmap (NULL, 0x8000, PROT_WRITE, MAP_SHARED, f, 0xB8000 /* вот оно родимое!!! */) Дальше пиши как в массив... videobuf[0], videobuf[1] и т. д. ;)) Не забудь в конце munmap и fclose :)

все элементарно ;) Залезли в память и грязными руками там шнораем ;) со стороны /dev/mem эта фича поддерживается специальной функцией кернел-драйвера mem.o, которая тебе память предоставляет. А вот работает это все в драйвере mem.o сложнее. Там идут всякие вычисления страниц, адресная арифметика...

Так, вообще-то мы тут про мозиллу говорим... ;))... Но серьезный и интересный треп все-таки интересен, так как отпугивает пионЭров. Они любят скандальчики... слака vs. rest world :)... Заходят сюда, зевнут и пойдут дальше ;)

Между прочим у меня в Линуксе Мозилла быстрее и лучше идёт чем IE. А под Виндой надо оперу юзать, раз уж говорим про скорость и удобство

Re:

Если речь идет про табы в IE - MyIE или как его там.

Opera7 под линукс по моим собственным ощущениям уделывала все остальные браузеры на Mozilla-1.3 движке. После того, как вышла 1.4 отрыв оперы от, н-р, галеона (на 1.4 движке), ну, прямо скажем, не настолько велик (если вообще есть, kommersant.ru, по факту, грузится дольше в среднем). А учитывая тот факт, что опера у меня падает при попытке переназначить клавишу открытия таба на C-t (ну, привык я так), то, в общем, выигрыш от того, что она маленькая и быстрая для меня сводится практически к нулю (да, я подозреваю, что C-t уже на что-то назначена, но _падать_ от этого... фи...). В общем, опера было выбилась у меня в лидеры по запускаемым программам (ну, среди тех, которые не имют шорткатов в панели), но потом так и застряла на третьей позиции...

Сравнивать Mozilla и IE на винде мне сложно, хотя за спиной сидит дружок (Athlon-1.7K+, 256Mb RAM, XP Pro), который по доброй воле, и абсолютно без всякого принуждения или рекламы с моей стороны уполз на Firebird месяц-полтора назад, и обратно, вроде, не собирается. Ну, это уж не говоря о том, что поблизости все продвинутые виндузоиды используют оперу.