LINUX.ORG.RU
← ZoneLayout под LGPL
RHEL: планы →
  1 2 3 4 5
Ответ на: комментарий от anonymous

>Было действительно необходимо ставить столько расширений? Или просто жрём, пока брюхо не лопнет (есть такое заболевание)?

foxytunes, flashblock, biet-o-zilla, forecastfox, adblock plus - это все.

fugu ★
()
Ответ на: комментарий от Vovanchic

> На PI/32Mb RAM пользовался Opera 5/7

opera 5,6 еще можно было пользоваться на 48М. Они, если не ошибаюсь, собирались еще с motif, а не с qt?

afair, на 32М mozilla после 1.0 работать не будет, хотя бы + eще 16М ей надо. Не проверял, но P1/48M тянет mozilla suite и firefox одновременно из под разных пользователей, один удаленно на X-терминал. Вполне юзабельно.

Впрочем, не проверял

anonymous
()
Ответ на: комментарий от anonymous

В смысле на 32М не проверял, только на 48M.

anonymous
()
Ответ на: комментарий от KRoN73

Есть настройка browser.cache.memory.enable, по идее если это то о чем я думаю, то лучше это дело отрубить, ибо зачем кешировать по второму разу то, что уже кешируется самой ОС (а для недавно посещенного, закинутого в дисковый кеш и, например, в случае /home на XFS - почему бы такому и не случиться?)...

Gharik ☆
()
Ответ на: комментарий от MYMUR

Sun T2000? нормальная такая машинка для дома и офиса :)

Gharik ☆
()
Ответ на: комментарий от SteepZ

> Вас для линукса не затрудняет программы ставить?

Многих затрудняет. У suser'а спроси. Он зачем-то выбирает дистр, где всё нужное уже есть.

> А юзеры только радоваться будут, что ФФ становится удобней при расширениях.

С чего ты взял, что ВСЕХ юзеров интересуют внутренности того окошка, которое им показывает "интернет"? Им бы на порнуху посмотреть, и всё. Не надо из всех делать маньяков по своему образу и подобию, у нормальных людей есть и лругие увлечения, а не только кампутиры.

anonymous
()
Ответ на: комментарий от Phoenix49

Ыыыыы.... :) Тута он, тута:

<table><tr><td><table><tr><td><table>& lt;tr><td><table><tr><td><table><tr><t d><table><tr><td><table><tr><td><table ><tr><td><table><tr><td><table><tr> <td><table><tr><td><table><tr><td>< table><tr><td><table><tr><td><table><t r><td><table><tr><td><table><tr><td> ;<table><tr><td><table><tr><td><table> <tr><td><table><tr><td><table><tr>< td><table><tr><td><table><tr><td><tabl e><tr><td><table><tr><td><table><tr> ;<td><table><tr><td><table><tr><td>< ;table><tr><td><table><tr><td><table>< tr><td><table><tr><td><table><tr><td&g t;<table><tr><td><table><tr><td><table> ;<tr><td><table><tr><td><table><tr>< ;td><table><tr><td>Deep tables test</td></tr></table></td></tr></table>< /td></tr></table></td></tr></table></td>& lt;/tr></table></td></tr></table></td></tr&g t;</table></td></tr></table></td></tr></t able></td></tr></table></td></tr></table> </td></tr></table></td></tr></table></td& gt;</tr></table></td></tr></table></td></ tr></table></td></tr></table></td></tr>&l t;/table></td></tr></table></td></tr></table ></td></tr></table></td></tr></table>< /td></tr></table></td></tr></table></td>& lt;/tr></table></td></tr></table></td></tr&g t;</table></td></tr></table></td></tr></t able></td></tr></table></td></tr></table> </td></tr></table></td></tr></table></td& gt;</tr></table></td></tr></table></td></ tr></table></td></tr></table></td></tr>&l t;/table></td></tr></table></td></tr></table >

Просто твой недобраузер его съел, а опера всё нормально показала.

anonymous
()
Ответ на: комментарий от anonymous

> Например, P1/48М RAM . Opera 7,8,9 тормозит до неюзабельности, Mozilla/Firefox можно пользовать.

Ой... Похоже, кто-то в 1996 году таки изобрёл машину времени! Поздравляю с удачным перемещением в будущее на 10 лет!

anonymous
()
Ответ на: комментарий от anonymous

>Сборка по умолчанию gtk2 + pango + -O0 ? Бывает :)

Нет, на ноуте WindowsXP

>но странички отображаются и протягиваются быстро без задержек.

Даже на Celeron-1700 при сложных страницах с насыщенными вставками картинок и т.п. Фокс формально листает немного быстрее (если считать скорость пролистывания страницы от начала до конца), но он занимается липой - он рисует страницы асинхронно :D В результате, если я в Опере беру мышой скроллбар, тащу вниз и на ходу вижу всю нужную мне информацию, то в Фоксе что-то увидеть в таком режиме НЕВОЗМОЖНО. Приходится отсанавливать время от времени скроллинг.

KRoN73 ★★★★★
()
Ответ на: комментарий от Benedict

>Немного не по теме, но в Konqueror-е текст виден :)

Дык, приятный браузер. Если б не глючил - может быть, хотя бы на форумах в нём сидел :) (В третий раз предвосхищая вопрос "где глючит?" - вот прямо на этом форуме, раздел "Мои комментарии" на заглавной, при кликании по ссылкам теряется анкор. 3.5, 3.5.2 :))

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

> Огнелис сука тормоз жуткий, особенно на ноуте

try firefox 2.0 alpha

michwill ★★★★★
()
Ответ на: комментарий от anonymous

>Вас не смущает отсутствие <HTML> в начале страницы?

Нет, потому что лепилось просто, чтобы показать этот баг Фокса. А проявляется он хоть с HTML, хоть без него :) Не я его нашёл, между прочим, на ЛОРе тут ещё в прошлом году писали.

KRoN73 ★★★★★
()
Ответ на: комментарий от KRoN73

>Нет, потому что лепилось просто, чтобы показать этот баг Фокса.
а это точно баг? может где-нибудь в users.c можно ограничитель уровней вложености отключить?

Anonymous ★★★★★
()
Ответ на: комментарий от anonymous

Вставлю свои пять копеек: несколько лет назад использовал P166MMX/80Mb, galeon (первой версии тогда) был очень быстрым во всех планах, phoenix 0.4 (ff, для тех кто не понял) gtk1/noxft интерфейс тормозил, показывал страницу так же медленнее. Потом его пооптимайзили, он стал показывать так же быстро, тормоза в интерфейсе легкие остались, но можно было уже использовать gtk1/xft сборку и было вполне себе ничего.

Опера же (7) была диким тормозом. Во-первых при открытии нескольких вкладок с большими страницами памяти жрала больше, чем ff, а на 80mb каждый мегабайт на счету, и тормозила очень сильно. qt-интерфейс был в меру нормальным - не сильно тормознее gtk1, но скорость рендеринга, скроллинг и своп из-за расхода памяти просто ужасали.

Причем запускаешь оперу - памяти жрет меньше, чем фокс. Начинаешь открывать табы - вот тут-то ее прожроливость и сказывается. Особенно если страницы большие, скажем книжка на мегабайт.

PS всем, у кого еще тормозит фокс/не работает back-forward/etc: запустите его без pango (или просто возьмите сборку с mozilla.org) и сотрите/почистите профиль.

anonymous
()
Ответ на: комментарий от anonymous

1> Например, P1/48М RAM . Opera 7,8,9 тормозит до неюзабельности, Mozilla/Firefox можно пользовать.

2>Ой... Похоже, кто-то в 1996 году таки изобрёл машину времени! Поздравляю с удачным перемещением в будущее на 10 лет!

То бишь против утверждения "1" возражений нет.

anonymous
()
Ответ на: комментарий от anonymous

> То бишь против утверждения "1" возражений нет.

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

anonymous
()
Ответ на: комментарий от KRoN73

> Фокс формально листает немного быстрее (если считать скорость пролистывания страницы от начала до конца), но он занимается липой - он рисует страницы асинхронно :D В результате, если я в Опере беру мышой скроллбар, тащу вниз и на ходу вижу всю нужную мне информацию, то в Фоксе что-то увидеть в таком режиме НЕВОЗМОЖНО.

Нет, все читается.

Речь о скорости протяжки, при которой еще возможно пробегать текст _на ходу_, но достаточно быстрой, чтобы на P100-200 проявились задержки и рывки при таскании движка мышой.

Если надо быстро протянуть страницу на несколько экранов, не читая, то mozilla/ff это делает в разы быстрее opera. Проверено с секундомером :)

anonymous
()
Ответ на: комментарий от Anonymous

>а это точно баг?

Ну, ясен пень, что это не баг, а фича. Но сделанная поперёк стандартов. Ибо я не помню в w3c ограничения на вложенность таблиц :)

>может где-нибудь в users.c можно ограничитель уровней вложености отключить?

Предлагаешь это делать простому юзеру?

...

А так, в XXI веке иметь буфера фиксированных размеров под такие вещи - это явно моветон :)

У меня памяти - уже год, как гигабайт. Понадобится (пока не требовалось) - хоть два, хоть 3Гб поставлю. Это сегодня копейки. Однако ж в браузере - копеечное ограничение :)

KRoN73 ★★★★★
()
Ответ на: комментарий от anonymous

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

Подтверждаю.

>PS всем, у кого еще тормозит фокс/не работает back-forward/etc: запустите его без pango (или просто возьмите сборку с mozilla.org) и сотрите/почистите профиль.

Еще проще: при сборке --enable-default-toolkit=gtk и --enable-optimize=-O3 .

anonymous
()
Ответ на: комментарий от anonymous

> Не знаю, мне в лавку старьёвщика сначала надо сбегать, у меня такого чуда нет.

Для задач X-терминал + отладка/cчет по мелочи + web даже P1 избыточен в разы :) Мне долго хватало VAXstation 3100, там было ~20МГц/8M :)

anonymous
()
Ответ на: комментарий от lenin

Оперу в такой конфигурации не пробовал,
а FF 1.5.0 работал (и не так уж и плохо(конечно с тюнингом)) на 32 Мб (хотя дело было давно, может там и 16Мб стояло, но точно не 48Мб )
=)

Atlant ★★★★★
()
Ответ на: комментарий от Phoenix49

>Memory havayet ne izza memory leaka, ne raz uje bilo skazano

Скорее "ne raz uje bilo navrano".

>Knopki nazad - vpered otkrivayut stranici pochti mgnovenno, pochemu ?

1. Это отключаемо. 2. Почему закрытие _всех_ табов не приводит к освобождению памяти?

По-моему, только фанатик может спорить с тем, что память в FF течёт как через решето.

Dimentiy ★★
()
Ответ на: комментарий от Dimentiy

>2. Почему закрытие _всех_ табов не приводит к освобождению памяти? По-моему, только фанатик может спорить с тем, что память в FF течёт как через решето.

Нет, это обычный эффект фрагментации памяти. Никакого вранья тут нет. Могу дать ссылки.

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

mr ★★
()
Ответ на: комментарий от Dimentiy

> По-моему, только фанатик может спорить с тем, что память в FF течёт как через решето.

Вы неправы. /* стараемся из'ясняться предельно литературно */

Leak detection tools алгоритмических утечек памяти ни в FF, ни в Mozilla, ни в Seamonkey _не находят_.

См., например, https://bugzilla.mozilla.org/show_bug.cgi?id=324081#c9

Как было отмечено выше, это проблема glibc и проявляется для ____всех____ графических браузеров под linux.

См., например, вывод malloc_stats() для Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=324081#c17

anonymous
()
Ответ на: комментарий от vada

ну дык. Есть смысл обновиться до 1.5.0.4

anonymous
()
Ответ на: комментарий от MYMUR

>Запарил. AMD Athlon 64 3500+ с гигом рамы --- это правильный комп или нет? Так вот ДАЖЕ НА НЕМ ФФ переключается по табам заметно для глаза. И вперед-назад тоже. Опера --- мгновенно.

А огрелис вообще на АМД плохо работает. Я пару раз пробовал. Отказался. Тормозит и проц безумно жрет.

vada ★★★★★
()

У кого FF собран с Pango, а он этого не знает, то можно для проверки Pango отключить:

MOZ_DISABLE_PANGO=1; firefox

Если скорость та же, то FF собран был без него. Pango очень здорово замедляет работу браузера и сильно грузит процессор. Потом эту переменную можно записать в файл ~/.mozilla/firefox/rc . Если такого файла нет, то его надо создать.

Zubok ★★★★★
()
Ответ на: комментарий от vada

> А огрелис вообще на АМД плохо работает.

То бишь один и тот же маш. код для x86 на AMD транслируется в неэффективный внутренний микрокод, а на Intel все пучком?

anonymous
()

Ммм... пятница.... :)

anonymous
()
Ответ на: комментарий от vada

> А огрелис вообще на АМД плохо работает. Я пару раз пробовал. Отказался. Тормозит и проц безумно жрет.

Чё за бред? Я сейчас пишу из 1.5.0.2, который стоит под slackware-current на Athlon-900 (разогнан до 1 GHz). Жрёт он свои VIRT=106m, RES=38m SHR=15m, но тормозит у него только download manager (когда ж он сдохнет-то?).

А проц он при переключении табов (или в начале загрузки страницы) жрёт на любом проце, аж MPLayer в эти моменты заикается. Но это gecko, т.к. то же самое в Seamonkey.

yozhhh ★★★
()
Ответ на: комментарий от anonymous

>С чего ты взял, что ВСЕХ юзеров интересуют внутренности того окошка, которое им показывает "интернет"? Им бы на порнуху посмотреть, и всё. Не надо из всех делать маньяков по своему образу и подобию, у нормальных людей есть и лругие увлечения, а не только кампутиры.

Так и запишем: Opera хорошо подходит только для тех, кому надо "порнуху смотреть и всё". :)))

caddr ★
()
Ответ на: комментарий от caddr

> Так и запишем: Opera хорошо подходит только для тех, кому надо "порнуху смотреть и всё". :)))

Ага. А кто любит поковыряться в ж.. (пардон, поиметь секс с установкой и обновлением расширений), тот выбирает ff :)

anonymous
()
Ответ на: комментарий от anonymous

Какая же все-таки дырявая поделка этот Firefox. Уязвимости находят одну за одной, и конца этому не видно. Хорошо хоть автоапдейт догадались сделать, а то трындец бы полный вышел. Зато как они кричали про безопасность! Громче всех!

anonymous
()
Ответ на: комментарий от anonymous

>firefox безопаснее IE. Точка.

Ну да, для домохозяек сойдет. А вообще, в последнее время теперь даже это правило не очень-то соблюдается. Дыры в FF сейчас находят чаще и в бОльших количествах чем у многострадального IE.

>Ссылки на ущерб от какой-л. уязвимости в FF в студию.

Зачем вам обязательно ссылка? Вам нужен конкретный пример с подробностями, именами, фамилиями? Вы не можете просто допустить, что если существует уявзимость, существует эксплоит, есть не пропатченный браузер, то взлом и ущерб можно нанести не в теории, а очень даже на практике?

anonymous
()
Ответ на: комментарий от anonymous

> Как было отмечено выше, это проблема glibc и проявляется для > ____всех____ графических браузеров под linux.

У меня Win32 :) И glibc, соответственно, нету.

Но я регулярно вижу VMSize > 200MB при количестве открытых табов, равном 0.

Dimentiy ★★
()
Ответ на: комментарий от mr

>Нет, это обычный эффект фрагментации памяти.

Значит, надо пулы использовать, а не оставлять как есть. Посмотри на исзходники APR. Вот поэтому Apache2 память не кушает, хотя аллоцирует тоже порядком.

End-user-у пофиг, почему именно память кушается.

Dimentiy ★★
()
Ответ на: комментарий от KRoN73

>>Стандарты говорят (как я помню), что кешировать post страницы не надо ... ку ?

>Можно ссылку на этот стандарт, если, конечно, он не в твоей голове выдуман?

ftp://ftp.rfc-editor.org/in-notes/rfc2616.txt

Hypertext Transfer Protocol -- HTTP/1.1

...

9.5 POST

The POST method is used to request

...

Responses to this method are not cacheable, unless the response includes appropriate Cache-Control or Expires header fields.

roller ★★★
()
Ответ на: комментарий от anonymous

>Вы не можете просто допустить, что если существует уявзимость, существует эксплоит, есть не пропатченный браузер, то взлом и ущерб можно нанести не в теории, а очень даже на практике?

было'б можно- нанесли'б.

а так- IMXO все "дыры" за последние непомнюсколько месяцев либо требуют для работы чтоб полное солнечное затмение выпало на пятницу 13, либо не дают злоумышленику никаких реальных возможностей для "развития атаки"

Anonymous ★★★★★
()
Ответ на: комментарий от Dimentiy

>У меня Win32 :) И glibc, соответственно, нету.

Это ж венда мерзавец вендузятник.

>Значит, надо пулы использовать, а не оставлять как есть. Посмотри на исзходники APR. Вот поэтому Apache2 память не кушает, хотя аллоцирует тоже порядком.

Спасибо за указание. Что-то такое про apache я слышал, но не знал что это APR называется.

Но применительно к firefox--наверно слишком долго переписывать firefox с пулами, да и как-то это противоречит идеологии программирования с его XUL'ом, afaik.

А портировать, например, аллокатор из openbsd 3.8/3.9 и проще, и универсальнее--другим программам помочь может.

mr ★★
()
Ответ на: комментарий от mr

>Это ж венда мерзавец вендузятник.

Какая же это венда. Вот виста - то настоящая венда, даже на VMWare криво ставится ;)

>Но применительно к firefox--наверно слишком долго переписывать firefox с пулами

Аллокатор от другой ОС - это хорошо конечно. Другим программам может помочь (или помешать ;). Только что мешает сделать в FF прослойку между glibc и выделением памяти на уровне языка (суть написать узкозаточенный Memory Manager и перегрузить new) - непонятно, увы :(

Хотя может я и не прав...

http://www.linux.org.ru/view-message.jsp?msgid=1369016#1370235 -- cut -- В prmem.c есть код, реализующий свой аллокатор, можно принудительно собирать с ним -- end --

Надо будет попробовать..

Dimentiy ★★
()
Ответ на: комментарий от Dimentiy

>Другим программам может помочь (или помешать ;)

Естественно, нету такой мысли делать его основным аллокатором в glibc. Просто толкового mmap-based аллокатора под линуксом по-моему вообще нет.

>Только что мешает сделать в FF прослойку между glibc и выделением памяти на уровне языка (суть написать узкозаточенный Memory Manager и перегрузить new) - непонятно

Мысль не совсем понятна. Если под этим Memory management имеются в виду пулы, то как как тогда new будет определять в какой пул ему размещать--так что прийдётся отличный от new оператор делать, с указание пулов, т.е. переписывать код существенно.

>В prmem.c есть код, реализующий свой аллокатор, можно принудительно собирать с ним -- end --

По-моему, это просто старый BSD-аллокатор. Отчасти совпадает с openbsd-аллокатором, но основан на sbrk, а не на mmap.

mr ★★
()
Ответ на: комментарий от Dimentiy

> У меня Win32 :) И glibc, соответственно, нету.

Какой именно windows? У windows XP и windows 2000 разные runtime libraries ?

На windows 2000 sp4 Firefox кушает очень умеренно и взад таки память отдает в нужном количестве. Со мной в комнате сидит человек с Firefox 1.0.* на windows 2000 на 64M RAM, распухания VM до 100-200М у него нет, типичное значение 35-50M.

> Но я регулярно вижу VMSize > 200MB при количестве открытых табов, равном 0.

Не бывает чудес. Посмотрите на browser.memory.cache.capacity в about:config, если это -1, то он устанавливаeт размер memory cache пропорционально кол-ву свободной памяти.

Или проблема в RTL опять таки :)

Как раз от windows-users жалоб на потребление памяти слышал меньше.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 3 4 5
← ZoneLayout под LGPL
Mozilla
RHEL: планы →