Чихать на память. У меня постоянно не больше 1 из 4 ГБ занято. Готов отдать FF гектар памяти чтобы он работал так же как и Chromium или быстрее. Да, на Gentoo FF работает как Chromium на Ubuntu, но тут дело в системе и Chromium на Gentoo вообще срабатывает моментально. FF остатеся тормозом. Рад что слез с него.

> Акцент на «значительные»

вкладочек сколько считали, а? 120? сколько процессов получилось? откуда значительные затраты? голова не плечах есть или калькулятор нужен?

>> То есть ты считаешь, что development snapshot должен быть так же безглючен, как финальная версия?

Я считаю если не готово - не предлагай, не будем и судить.

Повторю: «release early, release often» - стандартная практика FOSS.

Ни разу не очевидно. Откуда в процессной модели значительно большие требования по памяти?

«Multiple threads can exist within the same process and share resources such as memory, while different processes do not share these resources.» (http://en.wikipedia.org/wiki/Thread_(computer_science))

Хотя насчёт значительных может и погорячился.

P.S. Вот здесь говорится о том, что RSS вообще не показатель, ибо каждый раз считает разделяемые библиотеки.

> вкладочек сколько считали, а? 120? сколько процессов получилось? откуда значительные затраты? голова не плечах есть или калькулятор нужен?

Калькулятор нужен. А то мой может насчитать только 480К чистого оверхэда - на стеки ядра.

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

> Но в любом случае за ошибки в плагинах ответственны не браузеры.


так же можно сказать, что за хреновый жаваскрипт браузер не несет ответственности

> «Multiple threads can exist within the same process and share resources such as memory, while different processes do not share these resources.»

Дело в том, что процессам и не нужно разделять per-thread ресурсы, если каждая нить обслуживает свою вкладку - вкладки независимы.

да, не несёт, и потому джабаскрипт спроектирован безопасным, чтобы ошибки программ на js не могли вылезти за пределы интерпретатора.

> хромиум сырой, не смотря ни на что. понимаешь?

А ты понимаешь, что назвал разумную архитектуру костылями?

я пояснил критерии её неразумности. знаешь байку про хакера и солонки в общественной столовой?

>>> То есть ты считаешь, что development snapshot должен быть так же безглючен, как финальная версия?

Я считаю если не готово - не предлагай, не будем и судить.

Повторю: «release early, release often» - стандартная практика FOSS.

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

> > «Multiple threads can exist within the same process and share resources such as memory, while different processes do not share these resources.»

Дело в том, что процессам и не нужно разделять per-thread ресурсы, если каждая нить обслуживает свою вкладку - вкладки независимы.

Ну да, а общий набор переменных состояния браузера (те же закладки, наличие информации в кэше браузера, наконец X-овый контекст вывода) тоже не нужен?

>так же можно сказать, что за хреновый жаваскрипт браузер не несет ответственности

А что, за него несут ответственность «инженеры мозиллы», которые и наделали в нем ошибок?

Да, да, конечно. Ведь на javascript можно написать только безопасный код!

> мы начинаем его тестировать и имеем право судить о качестве.

Суди, не вопрос. Только слишком далеко идущих выводов не делай.

> Да, да, конечно. Ведь на javascript можно написать только безопасный код!

«да, да, конечно. ведь в отдельном процессе можно написать только безопасный код!»

> Ну да, а общий набор переменных состояния браузера (те же закладки, наличие информации в кэше браузера, наконец X-овый контекст вывода) тоже не нужен?

Это же копейки.

больше всех памяти съел легковесный браузер uzbl

Led Bicycle.

Что-то полюбили в последнее время слово «убогий» заменять словом «легковесный». Это нехорошо.

>> вкладочек сколько считали, а? 120? сколько процессов получилось? откуда значительные затраты? голова не плечах есть или калькулятор нужен?

Калькулятор нужен. А то мой может насчитать только 480К чистого оверхэда - на стеки ядра.

Хотя что это я... в Линуксе же модель 1:1, так что для каждой нити всё равно создается стек ядра... значит, явные накладные расходы - только структуры менеджера памяти. Не знаю, правда, как их подсчитать.

Цвета на графики не очень голубой и синий у меня очень-очень похоже выглядят. Да и тест немного неумный... лучше бы они сравнили отзывчивость (;

>Ты сам это видел или прочитал самопальный советский пеар? Если жигуль и разовьёт 200 км/ч в городе (в чём я не уверен - у роторных двигателей много проблем), то финишируют передняя и задняя части авто по отдельности, т.к. жёсткости кузова у жигулей нема.

Видел конечно но не в городе - никто не развалился, а вот иномарины только дым нюхали, бэхи в том числе да в общем все :) Естественно по управляемости им не сравниться и с поворотами они так не справляются как иномарки.

>полюбили в последнее время слово «убогий» заменять словом «легковесный». Это нехорошо.

Зато позитивно.

> Видел конечно но не в городе - никто не развалился, а вот иномарины только дым нюхали, бэхи в том числе да в общем все :) Естественно по управляемости им не сравниться и с поворотами они так не справляются как иномарки.

где можно поглядеть на сие чудо и их заезды? )

На графике midori график дальше 54 вкладок не пошел потому что хана ему настала, или потому что память больше 600мб и он опятьтаки загнулся?

люто плюсую.

>где можно поглядеть на сие чудо и их заезды? )

Я видел у рейсера один раз, не очень они популярны из-за малого ресурса двигателя, причем у него как раз был списаный гэбэшный вариант. Тут посмотри:

http://www.ladaonline.ru/catalog/index.php?SECTION_ID=355&SHOWALL_1=1

А как ее сравнивать, не научите?

> Мы сейчас говорим о том случае, когда ошибка произошла. Вне зависимости от того, кто в этом виноват. В данном случае треды поведут себя куда опаснее.

А почему опаснее? Посмотрим на это с другой стороны. Если процесс падает, потенциально это значит, что в нем можно выполнить произвольный код. А код, выполняемый в одном процессе, легко получит доступ к данным остальных процессов этого юзера. То есть безопасности данных это не способствует.

Смотрим дальше. Когда каждая вкладка - это отдельный процесс, то организовать взаимодействие между ними сложнее. А взаимодействовать им придется - у них много общих ресурсов, начиная от клавиатуры, мыши, кеша, аудио и плагинов, и заканчивая отдельными элементами страницы, ведь javascript одной вкладки может иногда управлять другой.

В потоковой реализации это было бы обычное IPC, но для разных процессов все намного сложнее. А чем сложнее код - тем больше в нем ошибок. А чем больше ошибок - тем хуже безопасность. С этой точки зрения хром - наименее безопасный браузер.

И на практике, когда хром падает, он падает весь, а не вкладками. Так где же на практике вся эта распиаренная безопасность?

Хана ему настала, но вроде как не от количества занятой памяти. Почитай соответствующий кусок текста.

Несмотря на то, что твой текст полон технических неточностей, ты в общем прав.

> Это же копейки.

Как сейчас пишут, вовсе могут быть и не копейки ;)

BTW, судя по исходникам хромиума, часть библиотек он таки линкует статически, что ещё отжирает память. В thread-модели такого не было бы (впрочем, статическая линковка библиотек — это костыль).

Класс!

Мой любимый браузер оказался лучшим. :)

> Как сейчас пишут, вовсе могут быть и не копейки ;)

Откуда там не копейки? Здравый смысл подсказывает, что память жрут: 1) DOM tree (которое по определению отдельное на каждую вкладку); 2) интерпретатор JavaScript, который тоже должен быть отдельный для каждой вкладки. Если вынести это в отдельный процесс, памяти они больше жрать не станут.

судя по исходникам хромиума, часть библиотек он таки линкует статически, что ещё отжирает память.

Для многопроцессной модели это неважно.

спасибо, почитаем )

>Chromium (chromium-bin-5.0.376.0_p44230) (без аддонов)

Firefox 3.6.3 (без аддонов)

олошеньки лоло. кто ж фуррифоксом то без обвесок пользуется? адблок поди памяти не жрет совсем?

Opera 10.10-r1 (более свежие версии неработоспособны вообще) (без всяких довесков)

два вопроса: 1. в каком месте они не работоспособны? 2. какие в опере могут быть довески?
и тем не менее, несмотря на всю сомнительность тестов, Опера таки лучше хрома. браво.

> Если процесс падает, потенциально это значит, что в нем можно выполнить произвольный код...

после этой х-ни остальное можно не читать XD

>> Если процесс падает, потенциально это значит, что в нем можно выполнить произвольный код...

после этой х-ни остальное можно не читать XD

Разжую для тупых программистов и обычных непрограммистов. Процесс «падает» чаще всего из-за того, что пытается обратиться к недоступной ему области памяти. Очевидно, разработчики не задумывали это при разработке кода, и раз это произошло, то выполнился совсем не тот, код, который должен был выполниться.

Например, при переполнении стека из-за парсинга какого-то левого яваскрипта после возврата из функции управление было передано на совершенно левую область памяти, и браузер упал. Соответственно, изменив этот «левый» яваскрипт, можно добиться того, что процесс будет передавать управление на заранее подготовленную область памяти с кодом.

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

Дальше, в зависимости от реализации в разных областях памяти могут храниться указатели на разные переменные. Повреждение таких указателей тоже может вызывать падение браузера. Но если один из них повредить хитрым образом, то вместо крэша это даст доступ к области памяти, которая не должна была быть доступна. Код таким образом не выполнить, но доступ к «закрытым» данным получить можно.

Ну что, теперь уже не так смешно?

нет, все еще смешно

...Процесс «падает» чаще всего из-за того, что пытается обратиться к недоступной ему области памяти...

Прям как в анекдоте про корову :)

- Коробочка квадратная.
- Значит, в ней что-то круглое.
- Раз круглое, значит оранжевое.
- Значит, апельсин.

т.е., ты не в курсе, как анализировать дамп упавшего процесса и написать эксплоит?

не смешно, потому что ничего не понял?

> не смешно, потому что ничего не понял?

Нельзя же так подставляться под обвинение в дислексии...

m> все еще смешно

действительно, прочитал по диагонали. но не думаю, что это называется дислексией, умник.

извини, не верно прочёл. отлично отжог, старик!

>А как ее сравнивать, не научите?

на глаз (;

Ахахаха!!!! Ушат холодной воды на хромиум-фанов.

Фаерфойс лучший!

> Процесс «падает» чаще всего из-за того, что пытается обратиться к недоступной ему области памяти. Очевидно, разработчики не задумывали это при разработке кода, и раз это произошло, то выполнился совсем не тот, код, который должен был выполниться.

ха-ха, клоунада в действии )) в том-то и дело, что обращаясь к недоступной странице памяти, процесс вызывает исключение segfault и аварийно завершается средствами самой ОС. В firefox'е процесс един для всех вкладок, поэтому, имея общую память, зловредный код из одной вкладки, может получить доступ и к другим, что логично, а так же положить и весь браузер (процесс един для всех вкладок, интерпретатора javascript'а, помним об этом, да?). В chrom'е на каждую вкладку выделяется свой процесс, поэтому уронив одну из вкладок, вызвав ошибку доступа к памяти, вкладка не потянет за собой весь браузер. И о чем ты спорил? ))

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

> в том-то и дело, что обращаясь к недоступной странице памяти

почему недоступная? она доступна, просто содержит мусор из переполненного буфера.

В firefox'е процесс един для всех вкладок, поэтому, имея общую память, зловредный код из одной вкладки, может получить доступ и к другим, что логично

но в фаерфоксе твоя реальность перестаёт работать, и там уже страница памяти доступна?

В chrom'е на каждую вкладку выделяется свой процесс, поэтому уронив одну из вкладок, вызвав ошибку доступа к памяти, вкладка не потянет за собой весь браузер.

потянет, ибо процессы-таки делят некоторые структуры в памяти, и при опаньке в одной вкладке в аут уходит весь браузер.

ты кроме бейсика в программировании что-нибудь понимаешь?