Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 64

>в этом им помогали Том Шустер

Мне кажется, над Fx уже давно стоило поработать человеку с такой фамилией.
Всего голосов 36: ↑31 и ↓5+26
Т. е. с фамилией «Сапожников»?
Всего голосов 3: ↑3 и ↓0+3
позволит усложнить поиск уязвимостей в браузере

Мне одному кажется, что лучше его облегчить с целью их закрытия?
Всего голосов 19: ↑17 и ↓2+15
Наверное, имелось ввиду «усложнить использование найденных уязвимостей». Но кто его знает… =)
Всего голосов 3: ↑3 и ↓0+3
Подчеркивание есть, а дополнительных процессов не вижу, Linux.
Посмотрим, когда заработает.
Всего голосов 1: ↑1 и ↓0+1
НЛО прилетело и опубликовало эту надпись здесь
Считаю необходимым процитировать оригинал:
Собрала операционка все браузеры и строго говорит: Предупреждаю! Любого, кто будет чрезмерно жрать память, сразу буду бить по наглой рыжей морде!
Всего голосов 16: ↑9 и ↓7+2
К сожалению это так. Chrome это единственный браузер выжирающий ВСЮ память на компьютере по своим соображениям. Сейчас я хоть на FF спасаюсь, ибо он даже гипотетически не может отъесть больше 2 ГБ, а на практике не отъедает даже более 1, при этом видно, что он убирает неиспользуемые страницы из памяти (видимо на диск скидывает), если и тут введут этот ад с мультипроцессностью, я уже и не знаю, что буду делать :( Иногда, при написании статей, для Chrome не хватает 8 ГБ установленной на компе памяти, и это, ИМХО, фейл, а тот же набор вкладок в FF отжирает около 1 ГБ, и при этом ничего не тормозит, а с Chrome cистема уже колом встаёт :(
Всего голосов 5: ↑5 и ↓0+5
некропостинг, но все же… сжирает 2,7 Гб смело ;)
Всего голосов 1: ↑1 и ↓0+1
Так FF уже тоже мультипроцессорный вроде как :( Пока думаю «решить проблему» втыканием в IDE слот CF карты через переходник и переносом туда файла подкачки, но если честно потихоньку хочется убивать… сначала процессы, потом людей ^_^
Всего голосов 1: ↑1 и ↓0+1
НЛО прилетело и опубликовало эту надпись здесь
Это разница. Сравнивали потребление однопроцессорной версии с многопроцессорной.
Всего голосов 4: ↑4 и ↓0+4
Ну у меня фф со старта жрет 700 мб с 25 открытых вкладок.
Всего голосов 2: ↑1 и ↓10
Давно пора, аж стыдно за Firefox было последние пару лет
Всего голосов 21: ↑7 и ↓14-7
С чего бы?

— Память Firefox ест значительно меньше других браузеров благодаря усилиям, связанным с проектом «memshrink».
— Плагины и так давно запускаются в отдельных процессах.
— Мифическая безопасность из-за процессов-песочниц на 95% компенсируется тем, что уже много лет кучи для данных и сгенеренного JS-кода и так разделены между табами и фреймами. А без JS и без плагинов заставить браузер выполнять какой-то код? Ну не знаю.
— Тормоза тоже убрали в рамках проекта «Snappy»

Так что у FF и так все хорошо. Будет еще лучше, но совсем чуть-чуть.
Всего голосов 35: ↑30 и ↓5+25
Иногда Firefox зависает на какой нибудь странице и всё. Ничего нельзя сделать кроме как ждать или выгрузить приложение целиком. Возможность принудительно закрыть только одну вкладку была бы отличным решением.
Всего голосов 12: ↑9 и ↓3+6
Безопасность процессов-песочниц — не мифическая. В Хроме даже инжектнув свой код в процесс вкладки ты фиг что с ним сделаешь — ни к диску, ни к другим процессам, ни к сети доступа нет. Сидишь в аквариуме и глазками только моргаешь. Процесс лисы имеет все привилегии, безопасности на уровне ОС в нём нет никакой.
Всего голосов 3: ↑3 и ↓0+3
Вопрос в том, что заинжектить код в процесс браузера практически невозможно. Для этого есть две возможности: JS и плагины. Плагины и так в отдельном процессе-песочнице уже много лет. А с JS-ом все очень сложно. Базовая идея: подобрать такой код на JavaScript, чтобы при JIT-компиляции результирующий машинный код делал то, что хочется атакующему. Задача эта сложная, и живых примеров подобных атак даже в «лабораторных» условиях еще не создано.
Всего голосов 3: ↑2 и ↓1+1
Для этого есть две возможности: JS и плагины

Я бы не был так категоричен. Очень редко, но бывают уязвимости парсеров html, css или библиотек для работы с изображениями и др.
Всего голосов 3: ↑3 и ↓0+3
Насчёт памяти, сравнивая с Оперой, не вижу результатов этих усилий.
Всего голосов 4: ↑1 и ↓3-2
Первый вопрос, который возникает у большинства, связан с потреблением оперативной памяти. Пользователи убеждены, что больше процессов значит больше занятой памяти.

Я всеми руками за нововведение – главное чтобы потом не стало как в хроме, 10 подпроцессов при 50-ти вкладках и «он уже лёг ногами по направлению взрыва и накрылся простынёй»
Всего голосов 12: ↑11 и ↓1+10
А я вот на FF уже только потому, что Chrome, как бы у него там с защитой вкладок было лучше/хуже, тупо не умеет переключать табы по Ctrl+Tab.

Это я к тому, что соревнования браузеров ведутся уже давно, но, сделай хромовцы Ctrl+Tab, это был бы аргумент посильнее всяких там «многих процессов» :)
Всего голосов 4: ↑3 и ↓1+2
Это что-то конкретно у вас с ним не то. У меня переключение работает как в Убунте, так и на Маке.
Всего голосов 3: ↑3 и ↓0+3
Хм… Надо было написать подробнее:

я предпочитаю, чтобы, если у меня открыты 20 вкладок, но я работаю с двумя (переключаюсь попеременно между), то каждое нажатие Ctrl+Tab переносило бы меня в предыдущую вкладку. Т.е. нажал Ctrl+Tab, отпустил, нажал Ctrl+Tab — вижу при этом только две последние.

А Хром при любом нажатии Ctrl+Tab дальше по кругу отправляет, т.е. все 20 вкладок по очереди.

В Firefox для таких целей можно приделать плагин, а вот Хром комбинацию Ctrl+Tab не дает ни на что повесить — посему народ извращается, делая Ctrl+Q и прочие комбинации, которые близко к Ctrl+Tab. Близко — но не Ctrl+Tab, сами понимаете.
Всего голосов 6: ↑6 и ↓0+6
Так понял. Мне как-то удобнее гонять по кругу, а назад через Ctrl+Shift+Tab.
Всего голосов 5: ↑4 и ↓1+3
странно, у меня FF последней версии, но Ctrl+Tab работает по кругу
Всего голосов 2: ↑2 и ↓0+2
Я лично использую en.design-noir.de/mozilla/ctrl-tab/, вроде то же можно включить в настройках, но я не искал долго.

В Хроме же даже плагин не помогает, нельзя там на эту комбинацию клавиш забиндиться…
Всего голосов 4: ↑4 и ↓0+4
Большое спасибо! К такому удобному переходу между используемыми вкладками привык в продуктах JetBrains. Надо будет обязательно попробовать плагин.
Всего голосов 1: ↑1 и ↓0+1
Можно выставить browser.ctrlTab.previews в true, при переключении табов будут рисоваться превьюшки, и побочным эффектом будет как раз порядок переключения.
Всего голосов 3: ↑3 и ↓0+3
За что и люблю Хабр! ;)

Спасибо!
Всего голосов 2: ↑2 и ↓0+2
Tab Mix Plus позволяет настроить массу всякого, связанного с вкладками, в том числе и это.
Всего голосов 5: ↑5 и ↓0+5
От этого комбайна пришлось избавиться: он умеет слишком много, а это не всегда хорошо во всех отношениях оказывается. Перешел на «Ctrl-Tab» — тот делает именно что надо.

Теперь попробую рекомендованный выше подход, выставить browser.ctrlTab.previews в true — не люблю обрастать плагинами.
Всего голосов 2: ↑2 и ↓0+2
Раньше в chrome удобнее было Ctrl + -> и Ctrl + < — , а потом сделали как везде по Ctrl + Tab и Ctrl + Shift + Tab :(, если первое ещё юзабельно, то второе сочетание уже не так удобно, да и возможности быстро щёлкнуть вперёд — назад тоже не стало.
Всего голосов 2: ↑2 и ↓0+2
Мне интересно с низкоуровневой точки зрения. Чем процессы лучше потоков? Лучше управляются ОС? Или быстродействие повысится за счёт разнесения вкладок на разные процессы? А почему не потоки? Вот сейчас у меня в запущенной в винде последней лисе 58 потоков, так что при желании она загрузит все 4 ядра. Значит, мы не теряем производительность за из-за того, что всё работает на одном ядре.
У меня сейчас в лисе открыто около 150 вкладок (оставим в стороне вопросы как, зачем и почему), большинство из них не подгружены и висят поскольку постольку. При этом лиса отъедает 0.45-10% процессора. А что будет, если на каждую хотя бы подгруженную (около 15 из 150 сейчас) вкладку будет по процессу? А если все 150? Ладно, что та же нагрузка будет распределена по процессам, но мы получаем оверхед на переключения контекста.
Открываю Comodo Dragon (вариант хрома), 5 вкладок, 7 процессов + мастер-процесс, итого 8. Они в сумме генерируют около тысячи дополнительных смен контекста в секунду! При том, что кроме них работает ещё 66 процессов, с кучей потоков каждый и отъедающий
Всего голосов 2: ↑1 и ↓10
1. Процессы падают сами по себе, не руша друг друга, креш потока часто означает креш приложения.
2. Процессы могут жить в уютных песочницах, не пересекаясь друг с другом и с другими процессами вообще ни в чём.
3. Процессы могут следить друг за другом, перезапускать упавшие.
4. Процессы можно контролировать менеджером задач, на счёт потоков можно только узнать их количество.
5. В процесс можно подгрузить чужую дллку-плагин, не боясь, что она упадёт или сделает что-то плохое (по вышеуказанным причинам — песочницы, взаимный контроль).

Я вообще тоже не вижу причин внедрения мультипроцессности для производительности. Но вот для модульности, стабильности, удобства контроля, безопасности — это да.
Всего голосов 10: ↑10 и ↓0+10
1) Согласен, но не так часто это происходит.
2) Пожирание памяти. Плюс они хотят использовать общие кеши, так что концепция полного разделения песочниц уже не работает.
3) Этим занимается мастер процесс и это входит в первый пункт (т.к. достаточно очевидно).
4) Убить отдельный поток можно (правда, не стандартным таск менеджером, но обычному юзеру подобное и не снилось). Полагаю речь идёт о сравнительно безопасном убийстве вкладки.
5) Таким образом, если у меня будет 20 вкладок с флешем, то подгрузится он 20 раз? Прощай память.
В целом фишки любопытные, но кроме моих доводов против привели ещё доводы ниже. И так ли востребованы эти фичи?
Всего голосов 1: ↑1 и ↓0+1
Странно, коммент обкусило… итак, его окончание:
При том, что кроме них работает ещё 66 процессов, с кучей потоков каждый и отъедающий
Всего голосов 1: ↑1 и ↓0+1
Facepalm, хабр. Он скушал всё, что шло после " < ", т.к. оно было вплотную к скобке
При том, что кроме них работает ещё 66 процессов, с кучей потоков каждый и отъедающий < 0.05% процессорного времени каждый. И без Хрома получается ~13к смен контекста.

Поэтому я против переделки текущей архитектуры даже при её недостатках, пока не появятся более серьёзные причины, чем те, что обозначены в посте.
Всего голосов 1: ↑1 и ↓0+1
А я наоборот, люблю FF за то, что он не забивает мне Task Manager кучей своих процессов.
Всего голосов 6: ↑6 и ↓0+6
А зачем вы смотрите в таск-менеджер?
Всего голосов 8: ↑5 и ↓3+2
У меня на 2м мониторе виджетами на рабочем столе выведены процессы (по памяти/процессору), загрузка процессора/памяти/сети. Мне очень нравится :)
Всего голосов 2: ↑2 и ↓0+2
Это, наверное, единственное, почему я еще не перешел на FF.
Когда разрабатываешь фронтенд и происходит, например, зацикливание, то очень неудобно перезагружать FF целиком.
Всего голосов 4: ↑3 и ↓1+2
Вроде как когда-то уже был подобный коммент, где-то год назад. Тогда проверили, музилка предлагает оборвать бесконечный цикл секунд через 15-20 после того, как он все зафризит. Это, конечно, неудобно, надо достаточно долго ждать, но все же не все так страшно.
Всего голосов 5: ↑5 и ↓0+5
Да, но когда проект надо сдавать (а нервы уже сдают), то 20 секунд превращается в ад ;)
Всего голосов 1: ↑1 и ↓0+1
Я не говорю, что это выход. И ни в коем случае не говорю, что это плюс. имеется ввиду, что не все так ужасно ии критично, как кажется на первый взгляд.
Всего голосов 1: ↑1 и ↓0+1
Пощупал. Плавности в анимации вкладок действительно добавилось довольно заметно, но начал ощутимо подлагивать скроллинг в текущей вкладке во время загрузки страницы в других. В любом случае, очень рад, что этот проект не забросили.
Всего голосов 1: ↑1 и ↓0+1
«Файерфокс» остаётся самым стабильным браузером в мире.

Firefox 25.0.1, 3.12.2-1-ARCH, x86_64. Вот это (можно открывать, не убъет..) до сих пор убивает огнелиса и всю систему, перезагрузится можно только посредством магии SysRq. Прекрасно понимаю что это прекрасно лечится средствами ОС… но мне кажется что это проблема именно firefox'a. У chromium'a например просто отмирает вкладка…
Всего голосов 1: ↑1 и ↓0+1
Запустил. Firefox 25.0.1, OS X 10.8.5, x86_64, отрисовало прогресс-бар где-то на четверть, после трехсекундной паузы или типа того Firefox предложил завершить выполнение скрипта. Я согласился, после чего закрыл вкладку. Пишу вам. Все работает, систему перегружать не пришлось. Может, это все-таки проблема не совсем Firefox-а? :)
Всего голосов 4: ↑4 и ↓0+4
Погуглил немного: про это уже тут писали; страдают не все, в том числе повезло пользователям OS X; был багрепорт по этому поводу, но разработчики считают что фитча, так и должно быть:
Sounds like a straightforward resource consumption issue — especially with a 64-bit build, we can keep allocating lots and lots of memory. Eventually, your OS will start complaining or having issues, but I don't think there's anything we can (or should) do.
Всего голосов 1: ↑1 и ↓0+1
Рискну выглядеть ололо-фанбоем, но по моему скромному личному мнению, проблема действительно не относится к проблеме Firefox как таковой. Если какая-то программа потребляет слишком много системных ресурсов и мешает остальным, то решение этой проблемы — головная боль именно операционной системы и никого другого.

Правильным поведением со стороны ОС было бы сохранение отзывчивости всех остальных программ на прежнем уровне и «зависание» браузера, пока он не закончит с выделением всех canvas-ов. А как избежать зависания самого браузера, должен решать уже сам браузер :) Как вариант — переложить задачу на операционную систему, создав отдельные процессы. Как другой вариант, выдавать квоты на потребление ресурсов разным вкладкам и использовать асинхронность/сопроцедуры вместо многопоточности.
Всего голосов 3: ↑3 и ↓0+3
Отчасти вы правы. Можно ограничить процесс квотами по памяти, с системой все будит хорошо — пострадает только Firefox, но мне лично кажется это не нормально когда интерпретатор считает: скрипту надо 54Gb памяти… дадим или умрем! Лично как по мне, так луше прибивать скрипт если он захотел например больше 1Gb. Только в настройках ФФ я нигде такого не нашел, может просто плохо искал?
Всего голосов 1: ↑1 и ↓0+1
Нет-нет, вы говорите о более радикальном реагировании на превышение квоты. Я же изначально думал о троттлинге — в случае превышения локальной квоты вводить задержки в функции выделения памяти путем формирования очереди этих вызовов и ожидания освобождения памяти от менее ограниченных задач. Т.о. тот, кто хочет слишком многого, все равно будет работать, но при этом не будет мешать остальным, которые памятью пользуются более разумно.

При превышении же глобальной квоты (которая на весь браузер), возможно, следует просто перенести проблему на плечи скрипта, и начать сыпать вполне обычными OutOfMemoryError-ами, которые в худшем случае вполне официально убьют скрипт, а в лучшем скрипт поймет, что что-то делает неправильно и исправит это. Или умрет :)
Всего голосов 2: ↑2 и ↓0+2
Упс… начинаю понимать. Формально вы правы: ОС должна справедливо разделять ресурсы между процессами а процессы — адекватно реагировать на выделение/отказ в выделении. Судя по вашему первому комментарию, OS X умеет сказать процессу: «баста, памяти ты больше не получишь» а Firefox, реагирует на это тем, что прибивает вкладку решившую кушать много памяти. В моем случае тоже все правильно: Firefox'у дают память — он ее использует, и вполне возможно готов отреагировать на сообщение об исчерпании памяти. Но Linux отдает все что у него есть, и геройски погибает. Я пробовал решать эту проблему только через cgroups, возможно существуют более мягкие решения.

Занимательно, что по поводу этой же ошибки говорят в багзиле ядра (я думаю с точки зрения ОС нет особой разницы между хромом и ФФ):
This appears to be a google chrome bug in that it tries to allocate most of your memory — you might want to set vm overcommit to disallow heavy overcommit then chrome would I think be killed

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

Большое спасибо за ваши комментарии. Страница-убийца это забавно, но распределение ресурсов и особенно поведение ОС в момент их исчерпания это уже интересно.
Всего голосов 1: ↑1 и ↓0+1
На то оно и nightly…
Всего голосов 2: ↑2 и ↓0+2
Я думаю, что проблема не в найтли, а в том, что теперь содержимое вкладки изолируется от всего остального, в том числе и плагинов. Придётся либо создавать виртуальную копию каждого плагина для каждой отдельной вкладки, либо копию содержимого вкладки под плагин. Хотя это всего лишь догадки, т.к. я не знаком с архитектурой FF.
Всего голосов 1: ↑1 и ↓0+1
В расширениях для перехода на многопроцессорную архитектуру придется внести очень много изменений.
Собственно, расширения основной тормоз перехода.
Всего голосов 5: ↑5 и ↓0+5
Всегда был большим поклонником Firefox и пользовался им до последнего месяца. Настолько сильно тормозить начал. Ни переустановка, ни удаление всех дополнений не помогли. Очень долго запускался, зависал во время работы. Весь нэт перелазил, но не нашел решения проблемы. Пришлось полностью перейти на хром. Немного не привычно, но в общем тоже нормально :) Очень надеюсь что теперь получше станет.
Всего голосов 6: ↑1 и ↓5-4
мне это менее интересно, чем перевод браузера на 64 бита. Уже скоро новые версии Винды перестанут выпускаться в 32-битной сборке, а ФФ никак не движется в этом направлении (я имею в виду отсутствие стабильных сборок, альтернативная 64-битная и у меня есть).
Всего голосов 3: ↑2 и ↓1+1
Очевидно же, чтобы было за что бить по наглой рыжей морде :)
Всего голосов 1: ↑1 и ↓0+1
очевидно же, что более полное использование возможностей современной архитектуры значительно улучшает работу браузера, ускоряет разработку и производительность приложения, а также даёт возможность задействовать некоторые новые возможности, в т.ч. новые механизмы безопасности.
Всего голосов 2: ↑1 и ↓10
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Показать лучшие за всё время

Ваш аккаунт

Разделы

Информация

Услуги

Техническая поддержка
© 2006–2024, Habr