| 1.2, proDOOMman (?), 11:53, 16/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
Можно конечно бы было попробывать, но опять половина плагинов отвалится =(
А начинание отличное, да
| | |
| |
| 2.4, Annonymous (?), 12:13, 16/12/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
с nspluginwrapper не отваливаются, а с мозиловским врапером будет отваливаться?
не путайте plugins с extensions.
плагины это например флеш, багрепортами которого и завалена мозила
| | |
| |
| 3.16, proDOOMman (?), 15:13, 16/12/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
>не путайте plugins с extensions
И как тогда их перевести? Расширения? Или addons - дополнения? Уже все привыкли к названию "плагины"
| | |
| |
| 4.19, cgorbit (??), 16:58, 16/12/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Кто вам сказал, что все привыкли? Все, кого я знаю, говорят "расширения".
| | |
| |
| 5.49, Iv945n (ok), 03:20, 19/12/2009 [^] [^^] [^^^] [ответить]
| –1 +/– | |
> Кто вам сказал, что все привыкли? Все, кого я знаю, говорят "расширения".
Наверно все, кого Вы знаете, занимаются разработкой расширений.
| | |
|
|
|
| 2.48, me (??), 22:27, 18/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Можно конечно бы было попробывать, но опять половина плагинов отвалится =(
попробовать
| | |
|
| |
| 2.43, User294 (ok), 17:38, 17/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
Виндузятники застрелятся а те которые выживут убегут на линух, посмотрев насколько там все быстрее и памяти жрет меньше (особенно когда еще и мерж одинаковых страниц памяти прикрутят) :).
Вот так то наступит однажды вендекапец - браузер станет основной программой и в винде она будет работать хуже :). Остается только вопрос: а будем ли мы рады этому? Особенно красавцам типа гугля, сливающим во все стороны наши конфиденциальные данные.
| | |
| |
| 3.50, AdVv (ok), 15:59, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Виндузятники застрелятся а те которые выживут убегут на линух, посмотрев насколько там
>все быстрее и памяти жрет меньше (особенно когда еще и мерж
>одинаковых страниц памяти прикрутят) :).
>
>Вот так то наступит однажды вендекапец - браузер станет основной программой и
>в винде она будет работать хуже :). Остается только вопрос: а
>будем ли мы рады этому? Особенно красавцам типа гугля, сливающим
>во все стороны наши конфиденциальные данные.
Тут где то пробегали тесты, Win32 FF под Wine работает быстрее чем нативный Линуксовый. И врятли ситуация изменится.
| | |
| |
| 4.51, User294 (ok), 23:41, 21/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
Зато гугель хром вроде как ровно наоборот. А мир захватывать вроде гугл собирался все-таки :). И с мозиллой пожалуй изменится - если они приделают разные части браузера в разных процессах. У пинвгином с этим получше а если еще same page merging прикрутить а винды еще и тормознутся кучей неуклюжих фаеров и антивирусов, можно представить результат...
| | |
|
|
|
| 1.5, Damon (??), 12:13, 16/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
 Назад в прошлое? :-)
Казалось, время "многопроцессной архитектуры" ушло в прошлое, и пришло время многопоточности... Ан нет!
Идея данной технологии, безусловно интересная и полезная, только ведь, история развивается по спирали. Представляю анонс ФФ версии 10.х.у:
"... Текущий релиз был наконец-то целиком переведен на работу в режиме многопоточности. Отмечен существенный рост производительности...".
| | |
| |
| 2.6, barmaglot (??), 13:18, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
 Тут речь о совершенно разных вещах. Политика изолирования исполняемых потоков кода в разных процессах преследует одну единственную цель, - защиту от сбоев. Это как хадуп кластеры, или просто фолт-толлерантные системы: система в целом продолжает функционировать, выдерживая N-1 сбоев, где N кол-во дублирующих компонент.
На самом деле разнести приложение на разные процессы идея хорошая:
1. Сетевая часть в одном единственном процессе (многопоточном).
2. Визуализацию в один единственный для всех процесс (многопоточный). Визуализация должна быть лёгкой, очень лёгкой, - просто отображение отрендереных данных.
3. Парсинг HTML и JS отдельно для каждого сайта. И тут можно разные страницы сайта в разных потоках парсить. Если где-то бяка, то свалится только один процесс.
4. Рендеринг тоже для каждого сайта отдельно. Та-же байда.
5. Плагины соответственно в отдельных процессах не нужны. Одного процесса для всех плагинов достаточно. Нужна изоляция на уровне API. Как для AddOn-ов в WoW.
| | |
| |
| 3.11, XoRe (ok), 14:24, 16/12/2009 [^] [^^] [^^^] [ответить]
| +1 +/– | |
>5. Плагины соответственно в отдельных процессах не нужны.
Поправлю.
Как раз это разработчики и делают:
>полностью изолированного выполнения плагинов, работа которых осуществляется в рамках отдельных процессов | | |
| 3.23, Damon (??), 18:38, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Тут речь о совершенно разных вещах...
Дык это... Я не спорю, что это, в принципе, здорово! Как я писал, идея понравилась, добавлю, что ессно, поддерживаю сие начинание. :-)
Просто позабавило яркое подтверждение тезиса о развитии истории по спирали. Вот я и продолжил аналогию.
| | |
| 3.35, sluge (ok), 12:27, 17/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
судя по материалу-фишка в том что один и тот же поток будет заниматся и JavaScript, и HTML, и GUI и прочим. просто таких процессов будет много!
| | |
|
| 2.14, XoRe (ok), 14:28, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Назад в прошлое? :-)
>Казалось, время "многопроцессной архитектуры" ушло в прошлое, и пришло время многопоточности... Ан
>нет!
>Идея данной технологии, безусловно интересная и полезная, только ведь, история развивается по
>спирали. Представляю анонс ФФ версии 10.х.у:
>"... Текущий релиз был наконец-то целиком переведен на работу в режиме многопоточности.
>Отмечен существенный рост производительности...".
Могу указать на один момент - многопоточное приложение писать сложнее, чем многопроцессное.
Поэтому для кого-то реализовать быструю и безопасную фичу легче реализовать в многопроцессном приложении.
А кто-то просто не осиляет)
Или осиляет, но за бОльший промежуток времени.
| | |
| |
| 3.24, Damon (??), 18:47, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Могу указать на один момент - многопоточное приложение писать сложнее, чем многопроцессное.
Да нет, сложность написания и там и там одинаковая. Просто при использовании "многопроцессной" модели так и так придется пользоваться объектами синхронизации при обмене данными, по другому не получиться. А в многопоточном приложении, порой, возникает желание (и есть возможность) секономить и обратиться к переменной напрямую, чем многие злоупотребляют, вот и возникают порой трудноуловимые чудеса. Если же быть аккуратным и "следовать рекомендациям лучших собаководов" (С), то отнюдь не сложнее. Точнее, писать-то совсем не сложно, а вот заставить потом корректно работать... :-)
| | |
| |
| 4.41, barmaglot (??), 17:01, 17/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Да нет, сложность написания и там и там одинаковая.
+1
>Точнее, писать-то совсем не сложно, а вот заставить потом корректно работать... :-)
Ну синхронизация на стэке и бог в помощь :)
Именно поэтому, я перешёл в своё время на С++, операции на стэке облегчают жизнь и практически сводят к 0 необходимость отладки. Да можно наворотить проблем и тут. Немного других проблем, но тем не менее портящих жизнь. Панацеи от кривых рук просто нет. А С++ слегка помогает навести порядок в мыслях и коде ...
| | |
|
|
|
| 1.7, Andy (??), 13:51, 16/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Отлично, как раз этого больше всего и не хватало. Ещё желательно, чтобы можно было для плагинов выставлять ограничения на потребляемые ресурсы.
| | |
| |
| 2.13, Артм (?), 14:25, 16/12/2009 [^] [^^] [^^^] [ответить]
| +1 +/– | |
Я смотрю на это с точки зрения того, что перенимается правильный опыт и технологии.
Или вы любитель изобретать колесо?
| | |
|
| 1.9, anonymous (??), 14:13, 16/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– | |
Сначала наделали кучу концептульно дырявых plugin'ов, потом делаем изолированное окружение для запуска (!!!) того, чему не доверяем.
Например, и flash и JavaScript сильно повышают возможности атаки.
| | |
| |
| 2.12, XoRe (ok), 14:24, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>Сначала наделали кучу концептульно дырявых plugin'ов, потом делаем изолированное окружение для запуска
>(!!!) того, чему не доверяем.
>
>Например, и flash и JavaScript сильно повышают возможности атаки.
Ну так их можно не включать, если не доверяете
| | |
| 2.15, szh (ok), 15:10, 16/12/2009 [^] [^^] [^^^] [ответить]
| +1 +/– | |
> Например, и flash и JavaScript сильно повышают возможности атаки.
И дают море полезных возможностей.
P.S. noscript + flashblock
| | |
| |
| 3.21, anonymous (??), 17:55, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>> Например, и flash и JavaScript сильно повышают возможности атаки.
> И дают море полезных возможностей.
> P.S. noscript + flashblock
Как-то не очень логично: сначала "море полезных возможностей" а потом тут же noscript + flashblock. Т.е. всё же есть подозрение, что "море полезных возможностей" не только для сидящего по эту сторону экрана?
| | |
| |
| 4.30, be_nt_all (ok), 22:27, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
Чего нелогичного. Если вы не находитесь в зоне повышенного риска (или у вас период обострения паранойи) — noscript + flashblock. В остальное время используем полезные возможности.
Философское отступление: ...мир, понимаете ли, плохо соответствует правилам бинарной логики, здесь очень редко уместно «или - или» (такие вопросы хорошо задавать только уперев ствол парабеллума в лоб врага). Здесь работает «и... и...»...
| | |
| 4.32, szh (ok), 00:52, 17/12/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Можно делать полезные вещи, можно вредные. Noscript помогает разрешать пользу и запрещать вред
| | |
| |
| 5.34, anonymous (??), 09:54, 17/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
> Можно делать полезные вещи, можно вредные. Noscript помогает разрешать пользу и запрещать вред
Ну прям как антивирус какой-то! ;-)
| | |
|
|
|
|
| 1.10, fi (ok), 14:18, 16/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Давно пора!!! И чтоб можно было безболезненно их отстреливать.
| | |
| |
| 2.36, sluge (ok), 12:29, 17/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
а что, есть люди, которые сморят PDF через FF? е-мае, куда я попал!
| | |
|
| 1.18, аноним (?), 16:13, 16/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
такс, посчитаем: 15 вкладок по 40 мб каждая плюс диспетчер >= 600 Мб
"память сегодня стоит копейки" (tm)
| | |
| |
| 2.20, szh (ok), 17:27, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
слова shared memory тебе ни о чем не говорят ?
Ты еще наверно и расход памяти по virtual size меряешь ?
| | |
| |
| 3.22, аноним (?), 18:12, 16/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
ты запусти хром и убедись сегодня, не дожидаясь тестовой сборки мазилы
| | |
|
|
| 1.25, Аноним (-), 18:55, 16/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
А если Electrolysis включить на 3.6b4 (dom.ipc.plugins.enabled на true) ничего плохого не будет?
| | |
| 1.33, upyx (ok), 04:54, 17/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Что-то FireFox все больше становится похож на неуправляемого монстра. Браузер вместо ОС? Cloud окружение для масс? Будущее настигает...
| | |
| |
| 2.47, szh (ok), 19:29, 17/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Что-то FireFox все больше становится похож на неуправляемого монстра
Когда кажется кретится надо.
> Браузер вместо ОС?
>Cloud окружение для масс? Будущее настигает...
ДА
| | |
|
| 1.38, sluge (ok), 12:32, 17/12/2009 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
никогда бы не подумал что распиливание потоков на отдельные процессы приведет к росту производительности. проведите простой эксперимет-у себя в винде експлорер переведите в режим когда каждое окно будет работать в отдельном процессе, получите нефиговые тормоза
| | |
| |
| 2.39, pavlinux (ok), 13:38, 17/12/2009 [^] [^^] [^^^] [ответить]
| +/– |
>никогда бы не подумал что распиливание потоков на отдельные процессы приведет к
>росту производительности. проведите простой эксперимет-у себя в винде експлорер переведите в
>режим когда каждое окно будет работать в отдельном процессе, получите нефиговые
>тормоза
Так надо их по разным процам/ядрам разгонять!
| | |
| |
| 3.44, аноним (?), 18:08, 17/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>надо их по разным процам/ядрам разгонять
оставили бы привычный режим работы для несчастных обладателей <40-ядерников
| | |
|
| 2.42, barmaglot (??), 17:03, 17/12/2009 [^] [^^] [^^^] [ответить]
| +1 +/– |
Основная идея не в увеличении производительности, а в повышении надёжности.
| | |
| |
| 3.45, аноним (?), 18:09, 17/12/2009 [^] [^^] [^^^] [ответить]
| +/– | |
>Основная идея не в увеличении производительности, а в повышении надёжности.
код надо писать нормально и соответствующим инструментарием - тогда проблем не будет
| | |
|
|
|
