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

Ошибки плагинов тут не ошибки браузерописателей.

>2.5Гб — перебор, имхо

100 вкладок — перебор, имхо

>>Да тут даже не о технической некомпетентности идёт речь (мы уже все поняли, что о SIGSEGV ты никогда не слышал). Если понимание термина услуга ограничено лишь серверами, то диагноз гораздо плачевнее. Браузерыж не сервера, пусть падают ка каждый запрос.

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

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

Ошибки плагинов тут не ошибки браузерописателей.

Это говорит только о том, что гугловцы оценивают себя более критично (ага, у меня и SeaMonkey, и Firefox падают и без плагинов).

Opera 10.53 Alpha со 130-ю вкладками + вся система = 358 Мб.

> хромиум менее устойчивый браузер, чем FF, и это общеизвестный факт.

Эээ... напомни мне, когда был релиз? А том может оказаться, что вы пользуетесь даже не альфа-версиями, а снапшотами.

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

А ты не расскажешь, как посчитал эту вероятность?

инженеры Мозиллы поступили так же

нет, не так, они поступили как раз разумно - затолкали в песочницу _чужой_ код.

Гугловцы получили это автоматически.

Что смешно? IE самый популярный браузер.
Если имелось в виду «браузерами под linux» - ну ладно, Firefox, Chromium, Opera, Konqueror.

>вот поэтому я юзаю фф

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

Там написано: которые получилось проверить. И написано, почему, в частности, не был протестирован конкерор.

> Ошибки плагинов тут не ошибки браузерописателей.
Ну, по-хорошему браузер не должен запускать бажный код плагинов.


А вообще, у меня с 4гигами сафари(веб кит) сидит нормально, жрет <1гига все нормалек.

А фаерфокс - это просто смешно. Не знаю, как исследователь мерял, но у меня он больше жрет, чем хром с теми же вкладками. Ни хром, ни сафари у меня ни разу не падали, а юзал я их больше чем фаерфокс.


Да, посмеялся над буу32, таких смешных мальчишек давно не встречал)) отжог пацан))

И как он не будет его запускать? ИИ на лиспе?

Охотно верю, что файрфокс с сотней аддонов будет жрать больше даже uzbl'а.

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

Они изолируют чужой код. Каким образом можно поработать над его качеством?

реквестирую сравнение с w3m

А с wget'ом тебе тоже сравнить может быть?

> но в итоге цель не достигнута - хромиум менее устойчивый браузер, чем FF, и это общеизвестный факт. что косвенно может указывать на то, что усложнение логики при запихивании табов в отдельный процесс повлекло больше ошибок, чем от которых они защитились.

знаешь, тебе так идет быть толстеньким с маслянисто-зеленоватым оттенком... ))

>Эээ... напомни мне, когда был релиз? А том может оказаться, что вы пользуетесь даже не альфа-версиями, а снапшотами.

Это всё отмазки, гугловцы давно пеарят его на каждом углу. Если предлагают пользоваться - значит считают, что готов.

>Хотя явно открывать большее 40-ка вкладок это уже болезнь

Это не Мицгол зе Вэбмастер ли, случаем, жаловался, что у него ФФ тормозит при 90+ открытых вкладках? Причем по его утверждению, все их он активно при этом использует (для своего гипертекстового фидонэта, вестимо).

> Эээ... напомни мне, когда был релиз? А том может оказаться, что вы пользуетесь даже не альфа-версиями, а снапшотами.

если нет релиза, то значит, и сравнивать нечего?

А ты не расскажешь, как посчитал эту вероятность?

я её не считал.

Гугловцы получили это автоматически.

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

>> Эээ... напомни мне, когда был релиз? А том может оказаться, что вы пользуетесь даже не альфа-версиями, а снапшотами.

Это всё отмазки, гугловцы давно пеарят его на каждом углу.

И что? Firefox и Mozilla тоже пеарились на каждом углу задолго до релиза, обычная практика в FOSS («release early, release often»).

А на самом деле

сравнение некорректно ;) Какой смысл сравнивать браузеры, построенные на разных архитектурах? Да, Chromium жрёт много памяти, точно также много будет жрать любое приложение, построенное на модели процессов, а не потоков (+накладные расходы на переключение контекстов). Можно ещё было бы какой-нибудь Java-браузер включить в тестирование ;) чтобы совсем страшно было.

Мне кажется, автор статьи хотел показать вовсе не зажор памяти (который зависит, как было правильно сказано, от наличия flash/javascript/etc на сайте), а поведение браузеров в экстремальных ситуациях и, как бы это правильно сказать, корректность их написания. Выяснилось, что у Chromium проблемы с имплементацией дизайна («также, при большом количестве вкладок невозможно перемещаться между ними: на табах перестали быть видны фавиконки, а затем таббар и вовсе наехал на кнопки закрытия/сворачивания»), что «Firefox адски течет» (впрочем, это известно и без того), что в reconq «после открытия 120 вкладок при нажатии и удержании Ctrl+W они стали весьма шустро закрываться обратно, но счастье длилось недолго: упал реконк».

Кроме того, скрытая реклама ;) LeechCraft.

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

>Ну, по-хорошему браузер не должен запускать бажный код плагинов.

В смысле, запускать сразу отдельным процессом? По-видимому, когда это начиналось, о таком еще не думали. Но в любом случае за ошибки в плагинах ответственны не браузеры.

> Они изолируют чужой код.

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

>сравнение некорректно ;) Какой смысл сравнивать браузеры, построенные на разных архитектурах?

Расскажи это 90% их юзеров.

>>И в-третьих - кому нужны 120 вкладок открытых?

Нужны.

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

120 вкладок в одном окне - неюзабельно, наверняка. А 30x4?

Перезагрузить браузер. Это шутка такая, да? А если вдруг придётся перезагрузить компьютер? Ну перезапустишь, раз надо, минута-полторы в фоне. Хорошо, если раз в день, а то там кто-то неделями не выгружает. Нашли проблему.

> если нет релиза, то значит, и сравнивать нечего?

Сравнивать можно, но некоторых выводов делать нельзя.

теперь у них и свой, и чужой код падает.

Что вполне естественно для стадии активной разработки.

ты в зеркало смотришься, дурилка.

> Что вполне естественно для стадии активной разработки.

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

> Да, Chromium жрёт много памяти, точно также много будет жрать любое приложение, построенное на модели процессов, а не потоков

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

Какая разница, на какой оно архитектуре? Юзеру-то это неважно.

Также, такие описание — скорее более похожи на ремарки, и заметки, сделанные в процессе тестирования потребления памяти. А набор сайтов везде одинаковый.

А еще скрытая реклама Ароры и остальных браузеров, которые там упомянуты, ага.

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

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

И вообще сама проблема, которую раздули гугловцы мне кажется сильно преувеличена. Что они пытаются изолировать? Левые глючные плагины? У меня их нет (или можно их отключить). Да в любом случае от запуска плагина в отдельном процессе сам браузер не должен жрать в разы больше памяти. Тогда что ещё - JS код? Но он изначально разрабатывался с учётом безопасности. У нас нет прямого доступа к памяти, ФС, как то есть скажем у С-шных программ. Там-то есс-но нужен жёсткий контроль.
Т.е. что в принципе может такого ужасного натворить JS-код, чтобы оправданно было от пользователя требовать в разы большие затраты памяти?

Opera наше все.

Можно закапывать, вместе с BSD>

>И что?

И то, что нечего отмызвать свою глюкавость на раннюю версию.

> о сырости продукта я и говорю

Ты говорил о том, что архитектура, защищенная от ошибок, не нужна.

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

Flash же.

> Ты говорил о том, что архитектура, защищенная от ошибок, не нужна.

такого я не говорил.

> нечего отмызвать свою глюкавость на раннюю версию.

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

Сравнил сейчас потребление памяти ароры и хрома с помощью pmap (мерялась только память которая не разделяется между процессами). ИМХО так точнее данные (память указана в килобатах):

me@eugene-laptop:~$ uname -a
Linux eugene-laptop 2.6.32-21-generic #32-Ubuntu SMP Fri Apr 16 08:09:38 UTC 2010 x86_64 GNU/Linux
me@eugene-laptop:~$ ./memcount.sh chrome
2743140
me@eugene-laptop:~$ ./memcount.sh arora
2292628

Скрипт замеряющий потребление памяти:

#!/bin/sh
pgrep $1|xargs -i sh -c "sudo pmap -d {}|sed -n 's/.*private: \([0-9]*\)K.*/\1/p'"|tr '\n' '+'|sed s/.$/\\n/|bc

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

ОМГ, еще один... )) потому, что у процесса бОльший отпечаток памяти, по сравнениею с тем же потоком.

флеш смело можно вынести в отдельный процесс. на отдельном компьютере, отключённом от сети.

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

XSS же.

>> Ты говорил о том, что архитектура, защищенная от ошибок, не нужна.

такого я не говорил.

Неужели?

boo32> нормальные инженеры будут разрабатывать софт без костылей.

наверное, тебя все неправильно поняли.

нет, не все, а только ты.

>Т.е. что в принципе может такого ужасного натворить JS-код, чтобы оправданно было от пользователя требовать в разы большие затраты памяти?

Спионерить сохраненные пароли к сайтам и счетам?

>> Да, Chromium жрёт много памяти, точно также много будет жрать любое приложение, построенное на модели процессов, а не потоков

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

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

>флеш смело можно вынести в отдельный процесс. на отдельном компьютере, отключённом от сети

Электрической, причем.

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

ОМГ, еще один... )) потому, что у процесса бОльший отпечаток памяти, по сравнениею с тем же потоком.

На вопрос ответь. Могу его повторить: откуда в процессной модели значительно большие требования по памяти? Акцент на «значительные».

> нет, не все, а только ты.

Не только :D

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

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

только.