The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Разработчики Firefox обратили внимание на проблемы с работой..., opennews (ok), 18-Янв-11, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


29. "Разработчики Firefox обратили внимание на проблемы с работой..."  –9 +/
Сообщение от iZEN (ok), 18-Янв-11, 14:13 
"Браузер ложит Xorg" —  это ещё один Epic Fail программистов C/C++!
Ответить | Правка | Наверх | Cообщить модератору

36. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от анонимный_обыватель (?), 18-Янв-11, 14:17 
> "Браузер ложит Xorg" —  это ещё один Epic Fail программистов C/C++!

предлагаете писать на дотнетовских закорючках, или я юмора не понял?

Ответить | Правка | Наверх | Cообщить модератору

44. "Разработчики Firefox обратили внимание на проблемы с работой..."  –4 +/
Сообщение от User294 (ok), 18-Янв-11, 14:36 
> "Браузер ложит Xorg" —  это ещё один Epic Fail программистов C/C++!

А ты на яве на своей роди графическую подсистему с 3D, птичкадятел? Как, слабо? А мы посмотрим какой ты там FPS сможешь выжать. Ессно мы не забудем ввинтить 1280х1024, максимальные настройки качества графики. Правда есть опасения что считать придется в итоге не кадры в секунду а скорее секунды на кадр, но разве изенов такие мелочи волнуют? ;)

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

79. "Разработчики Firefox обратили внимание на проблемы с работой..."  –3 +/
Сообщение от iZEN (ok), 18-Янв-11, 17:22 
>> "Браузер ложит Xorg" —  это ещё один Epic Fail программистов C/C++!
> А ты на яве на своей роди графическую подсистему с 3D, птичкадятел?
> Как, слабо?

Java3D под IE4 в 1999 году на PCI-карточке с 2МБ набортного ОЗУ не ложило графическую подсистему Windows NT 4.0 Workstation SP4.

> А мы посмотрим какой ты там FPS сможешь выжать.

25 FPS подойдёт?

> Ессно мы не забудем ввинтить 1280х1024, максимальные настройки качества графики. Правда
> есть опасения что считать придется в итоге не кадры в секунду
> а скорее секунды на кадр, но разве изенов такие мелочи волнуют?
> ;)

Да уш лучше 12 FPS, чем красный экран смерти.

Ответить | Правка | Наверх | Cообщить модератору

81. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от Аноним (-), 18-Янв-11, 17:34 
> Java3D под IE4 в 1999 году на PCI-карточке с 2МБ набортного ОЗУ не ложило графическую подсистему Windows NT 4.0 Workstation SP4.

Это конечно же просто чудесно и познавательно однако... и хде она сегодня эта Java3D? Или кто-то верит, что 3D в браузерах в дальнейшем будет сделано через это самое место? :)

Ответить | Правка | Наверх | Cообщить модератору

84. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от iZEN (ok), 18-Янв-11, 17:42 
>> Java3D под IE4 в 1999 году на PCI-карточке с 2МБ набортного ОЗУ не ложило графическую подсистему Windows NT 4.0 Workstation SP4.
> Это конечно же просто чудесно и познавательно однако... и хде она сегодня
> эта Java3D?

Она сегодня в мобильниках. Иногда задействует OpenGL ES, если есть такая возможность.

Ответить | Правка | Наверх | Cообщить модератору

85. "Разработчики Firefox обратили внимание на проблемы с работой..."  +1 +/
Сообщение от Аноним (-), 18-Янв-11, 17:44 
> Она сегодня в мобильниках. Иногда задействует OpenGL ES, если есть такая возможность.

Да, сегодня в мобильниках без 3D уже никуда, факт! Ни позвонить ни посрать ни попу вытереть - как без рук её богу ;)

Ответить | Правка | Наверх | Cообщить модератору

148. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 19-Янв-11, 12:15 
> Она сегодня в мобильниках.

Ну и где нормальные игры на этом? Чтонить уровня quake или NFS, например? Мне ни разу не попадалось. Хрень с пятью угловатыми полигонами которая бездалостно тормозит - это не есть нормальная игра, имхо. А чего-то приличнее мне на яве как-то не попадалось.

> Иногда задействует OpenGL ES, если есть такая возможность.

Угу. Задействуют. При том нормальные гамезы - из нативного кода. Если игра писана на яве - это сигнал того что писали ее чтобы по быстрому срубить бабла. Со всеми вытекающими.

Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

157. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от iZEN (ok), 19-Янв-11, 16:42 
>Ну и где нормальные игры на этом? Чтонить уровня quake или NFS, например? Мне ни разу не попадалось.

Погугли. Получишь массу результатов с картинками.

>При том нормальные гамезы - из нативного кода.

Отраслевой стандарт JSR-239 "Java Binding for the OpenGL ES API". Погугли, в каких мобильниках реализован, узнаешь много нового.

Ответить | Правка | Наверх | Cообщить модератору

172. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 19-Янв-11, 22:20 
> Погугли. Получишь массу результатов с картинками.

Зачем мне картинки? Вы мне нормально работающее чтонить покажите, что не вызывало бы рвотного рефлекса.

> Отраслевой стандарт JSR-239 "Java Binding for the OpenGL ES API". Погугли, в
> каких мобильниках реализован, узнаешь много нового.

Я вообще не понимаю на кой буй покупать мобильник умеющий OpenGL ES но не умеющий ничего кроме явы. Это какой-то тонкий и недостуный мне вид извращений: хотеть видеоакселератор и хотеть работать с ним из тормозной ява-виртуалки. Геймдевы судя по всему любовью к извращениям страдают меньше - почему-то все более-менее нормалные игры написаны как нативный код.

Ответить | Правка | Наверх | Cообщить модератору

176. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от анон (?), 19-Янв-11, 23:19 
> работать с ним из тормозной ява-виртуалки

Разработанная под девайс "тормозная ява-виртуалка" легко и непринужденно крутится на ARM9 c Jazelle например. А гигагарцев, скажу я вам... там нет

Ответить | Правка | Наверх | Cообщить модератору

204. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 21-Янв-11, 15:04 
> Разработанная под девайс "тормозная ява-виртуалка" легко и непринужденно крутится на ARM9
> c Jazelle например.

Ага, видел я как оно там легко и непринужденно крутится. Какая-то мазня из нескольких полигонов выжимает несколько FPS. Выглядит сие довольно тошнотворно. Да что там, элементарная аська ака Jimm стартует ...цать секуд. Что аж прогрессбар для индикации того что оно не встало раком а просто грузится требуется. В результате мну пользуется теперь n900. И пиджин там стартует без всяких прогрессбаров, и графика и эффекты - весьма даже, с приличным FPS'ом. А вы наслаждайтесь этой вашей явой на ARM9, если оно вам надо. А я не фанат тормозилова и убогих недопрограмм.

> А гигагарцев, скажу я вам... там нет

220MHz ARM9 с DDR оперативкой по своей скорости работы легко и непринужденно сделает по скорости 486-е на 100МГц с тормозным EDO RAM. На которых дум весьма плавно бегал с довольно приличной картинкой.

Ответить | Правка | Наверх | Cообщить модератору

97. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 18-Янв-11, 18:40 
> Java3D под IE4 в 1999 году на PCI-карточке с 2МБ набортного ОЗУ
> не ложило графическую подсистему Windows NT 4.0 Workstation SP4.

Я рад за вас. А много вы видели тех кто бы этим пользовался? :)
Вы указали плюсы но забыли о минусах. А я вам их напомню:
1) JRE в браузере стартовало не менее минуты, аццки хрустя винтом. И все ради запуска сраного апплета на пару кило. Вымораживает неимоверно!
2) Оно быстро сжирало почти всю память. Ну а скорость работы свопящейся системы - сами понимаете.
3) Когда апплет завершался, оно не торопилось отдавать память. В итоге в системе висела аццкая JVM выжирающая память. На просто свое висение.
4) Мне как-то не доставила скорость работы всего этого.
5) Мне было не прикольно качать по диалапу обновления JRE на десятки мегабайтов чуть ли не раз в неделю. Мало багов в браузере, давайте еще вывесим всей сети баги в этом монстре под сто мегов размерами, ага.
6) Оно как-то слишком дофига всего умеет. Соваться к локальной ФС, сокеты создавать. Первое позволяет меня расшарить всему интернету и умыкнуть у меня все что угодно, вплоть до сохраненных паролей. Второе позволяет проабузить сетевые дела для сканирования структуры интранета и сбора информации, сканирования и прочая.
6.1) Номинально конечно для этого нужно быть доверяемым апплетом, но как-то вот были баги секурити что неподписаный недоверяемый аплет может впарить себя как доверяемый. По сути безопасность явы приемрно равна скачке и запуску наобум трояов из интернета. Спасибо, вот вы и запускайте троянов с сайтов.

>> А мы посмотрим какой ты там FPS сможешь выжать.
> 25 FPS подойдёт?

Смотря для чего. Для нормальных 3D игр типа шутеров - нет, разумеется: там порогом играбельности считается что-то типа 30FPS, это минимальная планка мало-мальски комфортной игры. А на современных LCD еще и надо осиливать картинку в нативном разрешении монитора, иначе она выглядит как дерьмо (интерполяция у большинства лцдшников совершенно отвратительная). При этом скорости много не покажется.

Для типа куль демо "смотрите мы еще и так можем" - да. Правда, юзеры врядли станут этим пользоваться долго и всерьез. Кстати WebGL - что-то из той же оперы. У него правда шансов поболее. Потому что посторонний JVM не нужен.

> Да уш лучше 12 FPS, чем красный экран смерти.

Не знаю что такое красный экран смерти, но чертовски уверен что не буду например играть на 12 FPS вообше. Это будет не игра а постоянная борьба с тормозами. Кстати, на подумать: старина Кармак на хилом 486 проце с жутко тормозной оперативой (любой современный ARM в телефоне порвет все это как тузик грелку одной левой) чисто софтварно без всяких акселераторов выжимал явно поболее... :)

Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

105. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от iZEN (ok), 18-Янв-11, 19:14 
>> Java3D под IE4 в 1999 году на PCI-карточке с 2МБ набортного ОЗУ
>> не ложило графическую подсистему Windows NT 4.0 Workstation SP4.
> Вы указали плюсы но забыли о минусах. А я вам их напомню:
> 1) JRE в браузере стартовало не менее минуты, аццки хрустя винтом. И
> все ради запуска сраного апплета на пару кило. Вымораживает неимоверно!

В каком году? После выхода Java2 1.3 JVM и rt.jar грузились довольно быстро.

> 2) Оно быстро сжирало почти всю память. Ну а скорость работы свопящейся
> системы - сами понимаете.

64МБ было НОРМАЛЬНЫМ для Java тех времён.

> 3) Когда апплет завершался, оно не торопилось отдавать память. В итоге в
> системе висела аццкая JVM выжирающая память. На просто свое висение.

При закрытии браузера/окна с апплетом выгружалась и JVM. Нечего тут говорить про "неторопливо". Это с недавних пор используется Java QuickStart, что, впрочем, можно отключить в окне настроек JVM.

> 4) Мне как-то не доставила скорость работы всего этого.

Мне кажется, ты просто не видел, как это работает. И, да, Java3D может использовать OpenGL (Windows, Unix) и DirectX (только Windows) — есть разные сборки. Я использовал обе версии под Windows, разницы не ощутил.

> 5) Мне было не прикольно качать по диалапу обновления JRE на десятки
> мегабайтов чуть ли не раз в неделю.

Дистрибутив JRE во все времена занимал чуть меньше 15МБ.

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

Апплеты физически не могут открыть соединение не к тому серверу, с которого они загружены. Всё это — благодаря ПРОДУМАННОЙ системе безопасности Java2, в отличие от C/C++ плагинов.

> 6) Оно как-то слишком дофига всего умеет. Соваться к локальной ФС, сокеты
> создавать.

Что разрешил, то и умеет. Никто тебя не заставлял не глядя нажимать "Ok" на вопрос о разрешении повышения привелегий.

> 6.1) Номинально конечно для этого нужно быть доверяемым апплетом, но как-то вот
> были баги секурити что неподписаный недоверяемый аплет может впарить себя как
> доверяемый. По сути безопасность явы приемрно равна скачке и запуску наобум
> трояов из интернета. Спасибо, вот вы и запускайте троянов с сайтов.

Я так понял, что ты JavaScript давно не отличаешь от Java Applets.

>> Да уш лучше 12 FPS, чем красный экран смерти.
> Не знаю что такое красный экран смерти, но чертовски уверен что не
> буду например играть на 12 FPS вообше. Это будет не игра
> а постоянная борьба с тормозами. Кстати, на подумать: старина Кармак на
> хилом 486 проце с жутко тормозной оперативой (любой современный ARM в
> телефоне порвет все это как тузик грелку одной левой) чисто софтварно
> без всяких акселераторов выжимал явно поболее... :)

Однако на яве написаны современные шутеры уровня Quake2, которые без тормозов работают на мобильных телефонах. Почему так, а?


Ответить | Правка | Наверх | Cообщить модератору

163. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 19-Янв-11, 19:31 
> В каком году? После выхода Java2 1.3 JVM и rt.jar грузились довольно быстро.

Уже точно не помню, конец 90х-начало 2000х, как раз машина с 64Мб памяти была. Пока там в мозилле ява взлетит - задолбаться можно было ждать. В итоге паршивый апплет на пару кило ставил браузер в позу на минуту примерно. Что как-то не радовало.

> 64МБ было НОРМАЛЬНЫМ для Java тех времён.

Наверное у нас разные понятия о нормальном. Мне вот не нравится когда у меня система тормозит и постоянно свопится.

> При закрытии браузера/окна с апплетом выгружалась и JVM.

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

> Нечего тут говорить про "неторопливо".

Т.е. от неудобных фактов предлагается избавиться? :)

> Это с недавних пор используется Java QuickStart, что, впрочем, можно
> отключить в окне настроек JVM.

Я уже давно избавился от всего этого "счастья" просто методом деинсталла. Попутно - ниакие сцуки не шарятся у меня в интранете, не лепят сокеты, не пытаются сунуться в обход прокся в браузере, пошариться по ФС и прочая. И дыры в этом монстре теперь меня не волнуют. Как по мне - одни плюсы. Минусов от деинсталла я не заметил вообще. За ~десятилетие мне ни разу не попадалось в вебе ничего полезного что потребовало бы явы. Значит она не нужна для веба.

>> 4) Мне как-то не доставила скорость работы всего этого.
> Мне кажется, ты просто не видел, как это работает.

В свое время видел. Больше смотреть не захотелось. А, ну да, на мобильнике я тоже пробовал поиграть в "типа 3D" игрушки. Этим громким термином назывались уродства из десятка полигонов которые даже на экране 176х220 с процом 220МГц умудрялись тормозить. Хотя дум например куда резвее бегал на куда более хилом i486 с тормозной оперативкой, выдавая 320х240 с непозорным FPS и намного более сложной картинкой. Сами таким уродством и пользуйтесь, имхо.

> И, да, Java3D может использовать OpenGL (Windows, Unix) и DirectX

Пусть себе может. Мну не понимает нафига это надо. Для веба ява изврат. Серьезные гамезы все-равно придется на си++ писать. Ява с 3D остается нишей отдельных извращенцев и фетишистов.

> Дистрибутив JRE во все времена занимал чуть меньше 15МБ.

Всего полтора часа кача файла по диалапу. Сущая фигня, право. Особенно если цены на диалап вспомнить.

> Апплеты физически не могут

Это как? Кабель из сетевой карты при поползновении апплета выпадает, чтоли? :)

> открыть соединение не к тому серверу, с которого они загружены.

Как минимум, аплеты могут нагло положить на настройки прокси. И вообще лепить сокеты как душе угодно. Потенциально например положив на фильтрацию трафика на проксе и прочая. В общем потенциально ведет к обходу ограничений установленных с теми или иными целями, сбору данных о интранете или соединении в интернет или прочая. А если вспомнить что бывают баги с подпихиванием левого аплета как trusted, при том бывали они неоднократно - так можно и полноценный хаксорский прокси/спамбота поиметь себе на машину. А мне это надо?

> Всё это — благодаря ПРОДУМАННОЙ системе безопасности Java2, в
> отличие от C/C++ плагинов.

Угу, эту продуманную систему безопасности ломали весьма немало. Кстати, трояны на яве как-то умудряются проспамить даунлоад линку самого себя себя же по ICQ. Как они это делают? Понятия не имею. Факт в том что ява-бнопня рассылает ссыль на саму себя же, в надежде на дурака. А если дурак ее запускает - она рассылает себя всему контактлисту аськи этого олуха. Как оно получает доступ к контактлисту - я тоже без понятия. Видимо где-то эта ваша продуманная система безопасности лажается. Слишком оно навернутое и неочевидое. И наверняка с жуткой кучей багов из-за своей навернутости.

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

Да уж. Поэтому я просто не ставлю яву вообще. Особенно в браузер. Была охота хаксорские программы с интернета выполнять, аж 2 раза.

>> 6.1) Номинально конечно для этого нужно быть доверяемым апплетом, но как-то вот
>> были баги секурити что неподписаный недоверяемый аплет может впарить себя как
>> доверяемый. По сути безопасность явы приемрно равна скачке и запуску наобум
>> трояов из интернета. Спасибо, вот вы и запускайте троянов с сайтов.
> Я так понял, что ты JavaScript давно не отличаешь от Java Applets.

При чем тут яваскрипт вообще? Я именно про Java. Вы где-то видите слово JavaScript в моем комментарии? Вас глючит? Я прекрасно понимаю чем JS отличается от Java. Только не понимаю где вы JS увидели у меня в коменте :)

> Однако на яве написаны современные шутеры уровня Quake2,

Современные шутеры уровня квейк2 - это оригинально, если вспомнить в каком году квейк вышел. Кстати а чойта пользователи мобилок не рубаются часами в эту самую кваку на яве? Достали вы уже с вашей теоретической крутизной. Где оно нормально работающее и на практике, а? :)

> которые без тормозов работают на мобильных телефонах. Почему так, а?

Хм... так где же Quake 2 на яве на телефонах пользователей? Почему-то я ни разу не видел квак 2 на яве у пользователей телефонов. А что, его даже реально туда втиснуть, вместе с ресурсами и даже будет работать и даже с нормальной скоростью?

Ответить | Правка | Наверх | Cообщить модератору

178. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от iZEN (ok), 20-Янв-11, 00:31 
>> В каком году? После выхода Java2 1.3 JVM и rt.jar грузились довольно быстро.
> Уже точно не помню, конец 90х-начало 2000х, как раз машина с 64Мб
> памяти была. Пока там в мозилле ява взлетит - задолбаться можно
> было ждать.

Java Plug-in для Mozilla был готов (прикручивался без танцев с бубном), кажется, в 2001 году — как раз вместе с выходом Java2 1.3, в JRE которой был интегрирован плагин для Firebird и Mozilla.

> В итоге паршивый апплет на пару кило ставил браузер
> в позу на минуту примерно. Что как-то не радовало.

MS JVM в IE на тот момент была самая быстрая Java-машина на десктопах; Sun HotSpot был ещё в зародыше. Так что не ври.

>> 64МБ было НОРМАЛЬНЫМ для Java тех времён.
> Наверное у нас разные понятия о нормальном. Мне вот не нравится когда
> у меня система тормозит и постоянно свопится.

Памяти добавь, чтобы не свопилась. Сейчас норальным считается четыре гига рамы и два ядра. У меня 7,5ГБ ОЗУ, из которых сейчас занято 28%: FreeBSD 8-STABLE, RAID-Z, в памяти висят: Xfce4 ~ 350МБ, Firefox ~ 213МБ, Thunderbird ~ 96МБ, Transmission ~ 94МБ, RSSOwl ~ 83МБ. Удивлён, что приложение на Java занимает меньше всех? Я — нет.

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

Ответить | Правка | Наверх | Cообщить модератору

185. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 20-Янв-11, 11:58 
> в 2001 году — как раз вместе с выходом Java2 1.3,
> в JRE которой был интегрирован плагин для Firebird и Mozilla.

Возможно, я не помню уже деталей. Помню что попробовал разок поставить, т.к. набрел на какой-то апплет типа сетевого тетриса и мне стало просто любопытно посмотреть что за штука - как выглядит, что вообще может, etc. Выглядело как новые возможности для веба. Потуга запустить несчастный тетрис, при апплете оного мизерного веса ... занимала ~минуту. Браузер кстати при этом нещадно клинило. Пока стартила jvm - даже в другую вкладку было не переключиться, а стартила ява весьма долго для какого-то там тетриса.

> MS JVM в IE на тот момент была самая быстрая Java-машина на
> десктопах; Sun HotSpot был ещё в зародыше. Так что не ври.

А в каком месте я соврал? Что Java у меня в Mozilla запускалась минуту? А то что там в IE было - мне было довольно фиолетово. Потому что браузить веб нажимая back и forward и/или колупаться между несколькими окошками вместо того чтобы открыть новую вкладку меня как-то не радовало. И как-то так получилось что во времена использования мной IE (да, давным давно бывало даже такое) мне ни 1 ява-апплета вообще не попалось. Один единственный попался вот при юзании Mozilla Suite, только результат знакомства с технологией совсем не доставил.

> Памяти добавь, чтобы не свопилась. Сейчас норальным считается четыре гига рамы и
> два ядра.

Да, все так. Только ява нафиг не нужна оказалась. Ни на десктопе, ни в вебе.

> Xfce4 ~ 350МБ,

Что ты с ним для этого сделал, изверг? :)

>Firefox ~ 213МБ,

А, ну конечно, а тот факт что HTML, JS и прочие XUL ни разу не являются сями - мы проигнорируем? Ведь надо обосрать си :). Зато в случае явы мы забудем про то что JVM на сях писана, да? Ведь надо выпятить яву. Так и запишем, угу :)

> Thunderbird ~ 96МБ, Transmission ~ 94МБ, RSSOwl ~ 83МБ. Удивлён,
> что приложение на Java занимает меньше всех? Я — нет.

Ну ты б еще hello world на яве с опенофисом бы сравнил и сделал далеко идущие выводы. Я правда почему-то думал что сравнивать имеет смысл более-менее похожие программы с похожим функционалом. А лучше одинаковые алгоритмы вообще, как на quicklz.com. Иначе сравнение ежей и ужей получается :)))

> <остальной бред поскипан,

Так не бредь? :)

Ответить | Правка | Наверх | Cообщить модератору

206. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от iZEN (ok), 28-Янв-11, 21:17 
Специально для тебя: Garbage Collection наглядно http://habrahabr.ru/blogs/java/112676/
— там объясняется почему программе на Java не хватает памяти и что она делает в этом случае. А в обсуждениях есть посты с наглядной метрикой пространства памяти и перспективы улучшения ситуации.
Ответить | Правка | Наверх | Cообщить модератору

141. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от б.б. (?), 19-Янв-11, 08:29 
Мне жаль тебя расстраивать, но для вывода 3д оно использовало позорный C/C++ код. Никто драйверы на java не писал, java3d это лишь обёртка над низкоуровневыми функциями. И да, при проблеме на уровне драйвера opengl оно точно так же роняло бы windows в bsod.
Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

164. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 19-Янв-11, 19:32 
> Мне жаль тебя расстраивать, но для вывода 3д оно использовало позорный C/C++ код.

Ну вот, вы сломали картину идеального мира этому глуповатому жабисту. Как вам не стыдно? :)

Ответить | Правка | Наверх | Cообщить модератору

177. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от iZEN (ok), 20-Янв-11, 00:20 
> Мне жаль тебя расстраивать, но для вывода 3д оно использовало позорный C/C++
> код. Никто драйверы на java не писал, java3d это лишь обёртка
> над низкоуровневыми функциями.

Я в курсе, капитан Очевидность.

> И да, при проблеме на уровне драйвера opengl
> оно точно так же роняло бы windows в bsod.

Чё-то не роняло. Сколько ни запускал — на карточках с/без аппаратной акселерации OpenGL или DirectX — всё стабильно работало.


Ответить | Правка | К родителю #141 | Наверх | Cообщить модератору

53. "Разработчики Firefox обратили внимание на проблемы с работой..."  +2 +/
Сообщение от Аноним (-), 18-Янв-11, 15:09 
> "Браузер ложит Xorg" —  это ещё один Epic Fail программистов C/C++!

Ваще-то это косяк проектировщиков ОС.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

60. "Разработчики Firefox обратили внимание на проблемы с работой..."  –3 +/
Сообщение от User294 (ok), 18-Янв-11, 15:30 
>> "Браузер ложит Xorg" —  это ещё один Epic Fail программистов C/C++!
> Ваще-то это косяк проектировщиков ОС.

Интересно, каким боком? И как поступают правильные проектировщики? И, главное, где они, эти правильные, с их операционками? Только не надо кивать на винды, где интелский видеодрайвер легко и непринужденно ставит раком всю графическую подсистему, так что потом только ресет работает, а анимированные курсоры могли вообще сорвать башню ядру. Потому что тоже не шедевр, особенно если посмотреть на всякие там GDI, которые никуда не делись и по сей день активно юзаются :)

Ответить | Правка | Наверх | Cообщить модератору

57. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от eSyr (ok), 18-Янв-11, 15:20 
> "Браузер ложит Xorg" —  это ещё один Epic Fail программистов C/C++!

Программистов драйверов X.Org, всё же. Язык тут ни при чём.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

65. "Разработчики Firefox обратили внимание на проблемы с работой..."  –1 +/
Сообщение от JL2001 (ok), 18-Янв-11, 15:59 
>> "Браузер ложит Xorg" —  это ещё один Epic Fail программистов C/C++!
> Программистов драйверов X.Org, всё же. Язык тут ни при чём.

если язык с лёгкостью позволяет писать неаккуратно - он фактически стимулирует ошибки

Ответить | Правка | Наверх | Cообщить модератору

68. "Разработчики Firefox обратили внимание на проблемы с работой..."  +1 +/
Сообщение от eSyr (ok), 18-Янв-11, 16:25 
>>> "Браузер ложит Xorg" —  это ещё один Epic Fail программистов C/C++!
>> Программистов драйверов X.Org, всё же. Язык тут ни при чём.
> если язык с лёгкостью позволяет писать неаккуратно - он фактически стимулирует ошибки

Разруха, она не в клозетах, а в головах.

Ответить | Правка | Наверх | Cообщить модератору

80. "Разработчики Firefox обратили внимание на проблемы с работой..."  +1 +/
Сообщение от JL2001 (ok), 18-Янв-11, 17:32 
>>>> "Браузер ложит Xorg" —  это ещё один Epic Fail программистов C/C++!
>>> Программистов драйверов X.Org, всё же. Язык тут ни при чём.
>> если язык с лёгкостью позволяет писать неаккуратно - он фактически стимулирует ошибки
> Разруха, она не в клозетах, а в головах.

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

Ответить | Правка | Наверх | Cообщить модератору

82. "Разработчики Firefox обратили внимание на проблемы с работой..."  +1 +/
Сообщение от Аноним (-), 18-Янв-11, 17:38 
> я приверженец точки зрения что человека надо пинками гнать к светлому будущему
> иначе мы будем вечно иметь пхп-стайл программирование и постоянно вычищать опечатки,
> забытые инициализации, забытые освобождения явно неиспользуемых ссылок, нульпойнтеры
> и переполнения

Пардон конечно за нескромный вопрос но - и много лично у Вас этих стай горе-пхп-программистов? Что доставляют Вам ежедневную столь нестерпимую Боль? Ну хотя бы пара-тройка то сотен наберется? Чтобы было кого конкретно пинать и гнать гуртом к светлому будущему..

Ответить | Правка | Наверх | Cообщить модератору

88. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от JL2001 (ok), 18-Янв-11, 17:48 
>> я приверженец точки зрения что человека надо пинками гнать к светлому будущему
>> иначе мы будем вечно иметь пхп-стайл программирование и постоянно вычищать опечатки,
>> забытые инициализации, забытые освобождения явно неиспользуемых ссылок, нульпойнтеры
>> и переполнения
> Пардон конечно за нескромный вопрос но - и много лично у Вас
> этих стай горе-пхп-программистов? Что доставляют Вам ежедневную столь нестерпимую Боль?
> Ну хотя бы пара-тройка то сотен наберется? Чтобы было кого конкретно
> пинать и гнать гуртом к светлому будущему..

как бы так ? http://lurkmore.ru/images/9/9d/Dobeisa.jpeg

мне хватает кода в дорабатываемых мной проектах чтоб иметь представление о вопросе

Ответить | Правка | Наверх | Cообщить модератору

205. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 21-Янв-11, 15:08 
> как бы так ? http://lurkmore.ru/images/9/9d/Dobeisa.jpeg

403 Forbidden - Как говорится, FAIL!

> мне хватает кода в дорабатываемых мной проектах чтоб иметь представление о вопросе

Ну, если учесть что вы даже линку работающую привести не можете, я представляю что там у вас в проектах творится. Таких пинателей самих поди первым делом пинать надо.

Ответить | Правка | Наверх | Cообщить модератору

86. "Разработчики Firefox обратили внимание на проблемы с работой..."  –2 +/
Сообщение от JL2001 (ok), 18-Янв-11, 17:45 
>>>>> "Браузер ложит Xorg" —  это ещё один Epic Fail программистов C/C++!
>>>> Программистов драйверов X.Org, всё же. Язык тут ни при чём.
>>> если язык с лёгкостью позволяет писать неаккуратно - он фактически стимулирует ошибки
>> Разруха, она не в клозетах, а в головах.
> я приверженец точки зрения что человека надо пинками гнать к светлому будущему
> иначе мы будем вечно иметь пхп-стайл программирование и постоянно вычищать опечатки,
> забытые инициализации, забытые освобождения явно неиспользуемых ссылок, нульпойнтеры
> и переполнения

добавлю ещё что язык - это инструмент и он должен облегчать работу а не усложнять (мб конешно у меня в сях мало опыта но вспоминая как начинал изучать Java, C# или D сейчас - проект понимается куда проще)

Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

109. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от Crazy Alexemail (??), 18-Янв-11, 20:15 
Оно как бы да, но в жабе регулярно возникает ощущения жонглирования со связанными руками. Уж больно примитивный язык. А примитивность эта, понятное дело, выливается в большие объёмы кода, нужного, чтобы её компенсировать. Плюсы, при всех своих неудобствах, много больше позволяют. Впрочем, насчёт D соглашусь - достойно у них вышло :-) Правда начинает хотеться большего - AST-макросов, например, или пользовательских операторов - но это я уже зажрался :-)
Ответить | Правка | Наверх | Cообщить модератору

111. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от Crazy Alexemail (??), 18-Янв-11, 20:16 
> Оно как бы да, но в жабе регулярно возникает ощущения жонглирования со
> связанными руками. Уж больно примитивный язык. А примитивность эта, понятное дело,
> выливается в большие объёмы кода, нужного, чтобы её компенсировать. Плюсы, при
> всех своих неудобствах, много больше позволяют. Впрочем, насчёт D соглашусь -
> достойно у них вышло :-) Правда начинает хотеться большего - AST-макросов,
> например, или пользовательских операторов - но это я уже зажрался :-)

Единственное - IMHO, стоило бы сделать какой-нибудь MinimalD без GC...

Ответить | Правка | Наверх | Cообщить модератору

124. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от JL2001 (ok), 18-Янв-11, 22:58 
>> Оно как бы да, но в жабе регулярно возникает ощущения жонглирования со
>> связанными руками. Уж больно примитивный язык. А примитивность эта, понятное дело,
>> выливается в большие объёмы кода, нужного, чтобы её компенсировать. Плюсы, при
>> всех своих неудобствах, много больше позволяют. Впрочем, насчёт D соглашусь -
>> достойно у них вышло :-) Правда начинает хотеться большего - AST-макросов,
>> например, или пользовательских операторов - но это я уже зажрался :-)
> Единственное - IMHO, стоило бы сделать какой-нибудь MinimalD без GC...

а вы как любитель тёплого лампового звука можете обосновать чем плох GC ? и прошу вас, без ссылок на жаву и си# - там виртуальные машины вобще-то

Ответить | Правка | Наверх | Cообщить модератору

186. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 20-Янв-11, 12:10 
> а вы как любитель тёплого лампового звука можете обосновать чем плох GC

Попыткой заменить мозг програмера и как следствие - не думающими головой програмерами, уповающими на то что "оно само все сделает". И в итоге куча неочевидных утечек памяти, которые обнаруживаются далеко не сразу. При этом у поклонников GC еще и хватает наглости верещать что оно избавляет от утечек памяти. Ну да, конечно, я на примере реально существующих команд жабистов и дотнетчиков это во весь рост заметил. При том почему-то есть ощущение что сишники какимнить valgrind-ом проблемы с памятью вычисляют явно проще и быстрее. Во всяком случае, ни разу не видел чтобы сишные програмеры неделю бы бодались с отловом утечек. Жабистов и дотнетчиков бодающихся неделю с неочевидным результатом - видел.  

Ответить | Правка | Наверх | Cообщить модератору

123. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от JL2001 (ok), 18-Янв-11, 22:48 
> Оно как бы да, но в жабе регулярно возникает ощущения жонглирования со
> связанными руками. Уж больно примитивный язык. А примитивность эта, понятное дело,
> выливается в большие объёмы кода, нужного, чтобы её компенсировать. Плюсы, при
> всех своих неудобствах, много больше позволяют. Впрочем, насчёт D соглашусь -
> достойно у них вышло :-) Правда начинает хотеться большего - AST-макросов,
> например, или пользовательских операторов - но это я уже зажрался :-)

Для D3.0 запланировано следующее:
    AST макросы.
http://habrahabr.ru/blogs/programming/75451/

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

Ответить | Правка | К родителю #109 | Наверх | Cообщить модератору

149. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 19-Янв-11, 12:48 
> я приверженец точки зрения что человека надо пинками гнать к светлому будущему

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

Ответить | Правка | К родителю #80 | Наверх | Cообщить модератору

152. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от JL2001 (ok), 19-Янв-11, 14:29 
>> я приверженец точки зрения что человека надо пинками гнать к светлому будущему
> Лично мне не нужно светлое будущее в котором раздают пинки. Пусть жопа
> от пинков болит сугубо у вас, а мне такого счастья не надо.

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

Ответить | Правка | Наверх | Cообщить модератору

165. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 19-Янв-11, 19:48 
> добро пожаловать в демократичный капитализм с человеческим лицом.

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

Небольшое превью светлого будущего можно найти где-то в районе http://www.ruformator.ru/news/article06568/default.asp

> из человека надо выдавливать животное,

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

Ответить | Правка | Наверх | Cообщить модератору

90. "Разработчики Firefox обратили внимание на проблемы с работой..."  +3 +/
Сообщение от User294 (ok), 18-Янв-11, 18:01 
> если язык с лёгкостью позволяет писать неаккуратно - он фактически стимулирует ошибки

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

Вообще, такое почему-то очень похоже на попытку все-таки написать (и продавать - PROFIT!!!) Войну и Мир путем упихивания миллиона обезьян за печатные машинки, расстановкой загродок чтобы они не сбежали, старательной дрессировкой, чтобы жали более-менее правдоподобные кнопки и прочая. Только войной и миром результат все-таки не станет. И говнокоду от криворуких говнокодеров хорошей программой без ошибок - уж точно не бывать.

P.S. кстати многие логические ошибки бывают куда суровее и опаснее чем технические. Обезьяны почему-то упорно кивают на умные языки которые за них подумают и им жопу подотрут, но игнорируют этот простой факт. Хотя наиболее жуткие и проблемные последствия вылезают как правило именно из-за логических ошибок, не привязаннх к языкам *вообще* *никак*. Из-за логических ошибок теряются/искажаются/утекают данные. Из-за логических ошибок попадают на деньги. Из-за логических ошибок сталкиваются поезда и падают самолеты. Так ли при этом ужасен какой-то там несчастный крах?

Алсо, крах в целом - вообще не факт что что-то плохое. При крахе сразу видно что программа не работает корректно, ее можно сразу перезапустить с неискаженными данными + велика вероятность что кто-то сможет сделать "разбор полетов" по горячим следам. А что если краха не будет? Вообще, если произошла какая-то ошибка, а программа на нее забила - вариантов есть два: программа может или быть принудительно завершена дефолтным обработчиком ошибки ("крах"), т.к. нет оснований ожидать корректной работы программы, или она может попробовать продолжить работу, как будто все было ок. Только результат работы будет неопределен и возможны любые сюрпризы, которые появятся как только программа попробует сделать что-то, зависевшее от места на котором возникла проблема. Кстати оба подхода обработки ошибок в принципе возможны и для нативного и для манагед кода. Собссно все современные процессоры позволяют отделить программу от других программ и ОС в "песочницу", так что крах - всего лишь обнаружение процессором того факта что программа работает некорректно и попробовала сделать операцию которая не должна была происходить. Аппаратно или софтварно будет дернут обработчик по этому поводу и апаратный или виртуальный процессор при этом - вообще не так уж и принципиально. Принципиальное отличие только одно: можно или забить на ошибку, или не забить и вырубить программу. В первом случае программа продолжит работать, а глюк скорее всего окажется не замечен (зато он может больно вдарить потом, спасибо если не через неделю работы, когда хвостов уже точно не найти). Во втором программа срубится и будет стимул ловить глюк или баг. Который как ни крути, есть.

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

Ответить | Правка | К родителю #65 | Наверх | Cообщить модератору

94. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от iZEN (ok), 18-Янв-11, 18:13 
> Вопрос: почему глюкмэйкеры считают что некорректная работа программы лучше краха?

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

Ответить | Правка | Наверх | Cообщить модератору

108. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 18-Янв-11, 20:11 
> Просто потому, что программа ещё может побороться за свою живучесть

Уточним: она сможет лишь *непредсказуемо* *поглюкавить*. Забив на обработку проблемной ситуации. Т.к. если на проблемную ситуацию не было забито или же сбоев в логике работы вообще не было - тогда откуда взяться краху? Это ж лишь дефолтный обработчик вызываемый при обнаружении откровенно неправильной работы программы.

> в рамках отведённых ей аппаратных ресурсов,

Нюню. Если уж вы такой умный, то намекну: если система многозадачная, ресурсы в ней могут потреблять много программ сразу, прикиньте? И, кстати, это как билетная касса: у вас могут все разобрать перед самым носом. И выпролетите. Гарантий обратного никто не даст. Даже если в общем случае вы придя к кассе и получаете ваш билет, и даже 10 раз подряд вы его получили, это еще на значит что в 11й раз они не кончатся у вас перед носом.

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

Это как с билетами. Вы  можете забронировать билет заранее и твердо знать что тот билет - именно ваш, и никто его уже у вас не заберет. А можете надеяться на лучшее и переться наобум. Но можете при этом и обломаться, если все билеты раскупят до вас. Минус ессно "необходимость возни с бронированием" (выделение памяти заранее + свой аллокатор) и "переплата" (в плане сжирания ресурсов): чтобы не было шанса обломаться, надо выделить максимально необходимый кусок памяти сразу. И даже если часть памяти не требуется,но может потребоваться потом - отдавать ее низзя. По идее логика доступная даже неглупому школотенку. На примере с билетами, для особо непонятливых.

А на яве так сможете вообще? Или предполагается что Единственно Правильной логики встроенного аллокатора - хватит всем? ("совковая касса без услуги бронирования"). На сях кстати возможны и иные варианты логики - например периодические повторы попытки выделить память до успеха или таймаута считаемого фатальным, например. А на яве так сможете вообще? :)

> а не снести полсистемы (Xorg) из-за неподдерживаемой функциональности (крах).

Какой кондовый бред :). Не, изен, извини, конечно, но надежную систему твоего дизайна я бы юзать не стал.

P.S.: реально двинутые на надежности перцы программят примерно так: http://en.wikipedia.org/wiki/Immunity_Aware_Programming - это, конечно, сурово, но в некоторых местах надежности не бывает слишком много. Врядли вы оцените сбой например в софте микроконтроллера управляющего тормозами вашего авто? Или вы думаете что навороты типа антипробуксовочных и антиблокировочных систем - это такие аппаратные фичи? Ну да, щазз, потребный анализ ситуации с датчиков и принять решение может только микроконтроллер с своей фирмвариной. Приколитесь, написаной на си скорее всего (ну может на асме, но на голом асме нынче не модно в силу геморности и непортабельности). И, кстати, если бы такую же логику писали бы вы, на вашей яве - я бы вообще от такого авто держался за километр, а то глюки и баги в тормозной системе - как-то ссыкотная такая штука, а? Там обычно просто фирмварина проста как топор и вылизана до битика, глюкать тупо нечему ;).

Ответить | Правка | Наверх | Cообщить модератору

121. "Разработчики Firefox обратили внимание на проблемы с работой..."  +1 +/
Сообщение от iZEN (ok), 18-Янв-11, 21:40 
>> Просто потому, что программа ещё может побороться за свою живучесть
> Уточним: она сможет лишь *непредсказуемо* *поглюкавить*. Забив на обработку проблемной
> ситуации. Т.к. если на проблемную ситуацию не было забито или же
> сбоев в логике работы вообще не было - тогда откуда взяться
> краху? Это ж лишь дефолтный обработчик вызываемый при обнаружении откровенно неправильной
> работы программы.

try-catch в современных языках программирования никто не отменял. В блоке catch программа может определить неполадки и попытаться восстановить своё состояние до входа в блок try. В большинстве случаев такое поведение несмертельно для программы и позволяет продолжать её исполнение после выхода из обработчика исключительной ситуации.
Дебаты об исключениях: http://www.ibm.com/developerworks/ru/library/j-jtp05254/inde...

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

Это — задача операционной системы и/или JVM. Пока что JVM показывает наилучшее управление ресурсами, чем, собственно, ядро ОС, глядя на то, как "текут картинки" и обваливается Xorg. :))

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

<...>
> А на яве так сможете вообще? Или предполагается что Единственно Правильной логики
> встроенного аллокатора - хватит всем? ("совковая касса без услуги бронирования").

В JVM есть разные стратегии распределения памяти и уборки мусора. Под разные задачи можно выбрать оптимальные.
Краткая история развития технологии утилизации памяти: http://www.ibm.com/developerworks/ru/library/j-jtp10283/inde...

Исправление модели памяти Java, часть 2: http://www.ibm.com/developerworks/ru/library/j-jtp03304/inde...

Сборка мусора и производительность: http://www.ibm.com/developerworks/ru/library/j-jtp01274/inde...


> На
> сях кстати возможны и иные варианты логики - например периодические повторы
> попытки выделить память до успеха или таймаута считаемого фатальным, например. А
> на яве так сможете вообще? :)

А зачем в программе на Java выделять себе память? Массив нужного размера создался — хорошо — можно использовать его под буфер. Сам по себе объект имеет небольшой оверхед около 80 байт служебной информации и живёт, пока на него есть хотя бы одна ссылка. Лично я предпочитаю работать с долгоживущими объектами, которые изменяют своё состояние, если это нужно, а не создавать новые и новые объекты-"однодневки", которых прибирает GC.

Ответить | Правка | Наверх | Cообщить модератору

168. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 19-Янв-11, 21:03 
> try-catch в современных языках программирования никто не отменял.

И что? В обработчике исключения далеко не все удосуживаются написать что-то осмысленное. А если уж хочется пообрабатывать ошибки осмысленно - даже на гольных сях это можно. Приколитесь? :)

> В блоке catch программа может определить неполадки

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

>  и попытаться восстановить своё состояние до входа в блок try.

Попытаться... да... удачи в этом начинании. На сях ксати тоже можно попытаться. А почему нет? Напримре в *никсах программа может навесить свои кастомные обработчики сигналов. На SIGSEGV в частности. Чем это будет так уж сильно отличаться от того же try-catch на большой блок кода? Если вы этого вдруг не знали - наверное в этом не си все-таки виноват, а вы? :)

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

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

>> как билетная касса: у вас могут все разобрать перед самым носом.
> Это — задача операционной системы и/или JVM.

Спасибо, Кэп. А я то и не подозревал что в роли кассы именно они.

> Пока что JVM показывает наилучшее управление ресурсами,

А JVM вааще является в этой нашей схеме с билетами всего лишь спекулянтом-перепродавцом билетиков, который получает билеты в той же кассе (у OS) и потом их вам перепродает. И, кстати, если вдруг спекулянта обломают в кассе с билетами - он и вас обломает при попытке купить у него билет, т.к. если у него нет билетов, взять ему их будет неоткуда. Плюс он может вас обломать если его лучший друг попросил придержать для него билетиков. Или если ему не нравится ваша морда лица. Или ... ну в общем ява может иметь свое мнение о том сколько вам память можно. Вторым уровнем, опосля мнения ОС на этот счет. Странно, правда? Утверждается что сие надежнее чем напрямую забронировать билет? Ну да, помечтайте :) В одном случае 1 точка отказа, в другом - 2, при том первая - такая же как в первом случае. С фига ли цепь из 2 звеньев лучше чем из одного по надежности? Вы жестоко прогуливали теорвер в инсте, или WTF? :)))

> чем, собственно, ядро ОС,

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

> глядя на то, как "текут картинки" и обваливается Xorg. :))

Как будто софт на яве не течет, ага. Ява наверное методом телепатии узнает когда програмер больше не собирается работать с вон той сущностью и можно уже ее убить, освободив занимаемую сущностью память под что-то еще. Не, извините, но чудес не бывает. Бывают только дураки которые верят в чудеса :P.

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

А *свою* стратегию - возможно подсунуть? Или как обычно - 640 Кб хватит всем, потому что умные дяди из сан/оракл так за вас решили?

> Под разные задачи можно выбрать оптимальные.

А парни из сана и оракла обладают телепатией чтобы предвидеть ВСЕ возможные типы задач?

> Краткая история развития технологии утилизации памяти:

Да, термин "утилизация" применительно к яве неплохо описывает то что оно делает с памятью :D.

> Сборка мусора и производительность:

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

> А зачем в программе на Java выделять себе память?

Да хоть горшком назовите. Созданием объекта, или как вам там угодно. В конечном итоге - это будет с точки зрения ОС трансформировано в выделение памяти, один хрен. Потоу что ядро не оперирует такими терминами. А как вы это там назовете - не так уж и интересно. Ну не malloc у вас сможет обломится, так new. И если скажем объект не создался и он был не для красоты - врядли получится корректно поработать дальше, правда? :) А 10 отличий - они в чем будут? Так, глобально? :)

> предпочитаю работать с долгоживущими объектами, которые изменяют своё состояние, если
> это нужно, а не создавать новые и новые объекты-"однодневки", которых прибирает GC.

Ну да, конечно. Ведь с new но без delete при активном создании объектов поиметь неочевидные утечки памяти - ни разу не проблема, правда? :))) Ведь достаточно оставить по недосмотру ссылку на какой-то временный объект, и GC его уже никогда не убьет. И будет .... утечка памяти! Та самая, которая якобы "невозможна" на яве, хи-хи ;).

Ответить | Правка | Наверх | Cообщить модератору

181. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от iZEN (ok), 20-Янв-11, 01:18 
>> В большинстве случаев такое поведение несмертельно для программы
> Ну так я уже сказал что если на ошибку положили болт -
> есть ровно 2 варианта что будет дальше: можно глюк обнаружить и
> убить программу. А можно не убивать и предоставить ей работать дальше.

Это только на сях имеют два выхода: segmentation fault или core dump — выбери из них лучшее. :)

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

В своё время написал программу для обработки данных, которая пыталась несколько раз выполнить определённую функцию чтения и записи данные в базу данных. Операция чтения данных из файла была ненадёжна, так что с первого раза обычно не выполнялась, но выполнялась со второго-третьего-...-пятого раза, и данные в итоге записывались в базу данных за приемлемое время. Так как функция изначально работала с внешним файлом, который мог быть эксклюзивно занят на время обновления другой программой, то вероятность словить IOException была близка к 50%. Но моя программа просто обрабатывала это исключение, прогоняла заново операцию чтения и добивалась считывания данных из этого файла без каких-либо последствий для себя в режиме 24x7.

>> В JVM есть разные стратегии распределения памяти и уборки мусора.
> А *свою* стратегию - возможно подсунуть? Или как обычно - 640 Кб
> хватит всем, потому что умные дяди из сан/оракл так за вас
> решили?

Да, можно подсунуть свою реализацию GC. Код OpenJDK6 и API открыты. Если чувствуешь себя более умным, чем разработчики JVM, проблем не существует.

>Ну не malloc у вас сможет обломится, так new. И
> если скажем объект не создался и он был не для красоты
> - врядли получится корректно поработать дальше, правда? :) А 10 отличий
> - они в чем будут? Так, глобально? :)

Объекты в Java создаются атомарно. Если new не может создать объект, то вылетит исключение времени выполнения (или проверяемое исключение, если определено в сигнатуре конструктора) и его тоже можно обработать, можно корректно завершить программу.

>> предпочитаю работать с долгоживущими объектами, которые изменяют своё состояние, если
>> это нужно, а не создавать новые и новые объекты-"однодневки", которых прибирает GC.
> Ну да, конечно. Ведь с new но без delete при активном создании
> объектов поиметь неочевидные утечки памяти - ни разу не проблема, правда?
> :))) Ведь достаточно оставить по недосмотру ссылку на какой-то временный объект,
> и GC его уже никогда не убьет. И будет .... утечка
> памяти! Та самая, которая якобы "невозможна" на яве, хи-хи ;).

Какие мы глупые! У нас нет профилировщика, чтобы анализировать сколько и каких объектов создаётся и не убирается во время работы нашей программы! Хи-хи. :))

Ответить | Правка | Наверх | Cообщить модератору

187. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 20-Янв-11, 12:34 
> Это только на сях имеют два выхода: segmentation fault или core dump
> — выбери из них лучшее. :)

Повесь свой обработчик на SIGSEGV, мистер тормоз. И делай в нем все что твоей душе угодно. И чем это так уж принципиально отличается от catch? Да, кстати если я не говорил, у почти всех жабистов почему-то в try-catch в части которая catch - почему-то ... ничуть не менее пусто чем у типичных сишников. :)

> 50%. Но моя программа просто обрабатывала это исключение, прогоняла заново операцию
> чтения и добивалась считывания данных из этого файла без каких-либо последствий
> для себя в режиме 24x7.

Ой, надо же. На яве можно оказывается поймать I/O error. На сях тоже можно. И? Не догоняю, у кого и в каком месте наступает EPIC WIN :)

> Да, можно подсунуть свою реализацию GC. Код OpenJDK6 и API открыты. Если
> чувствуешь себя более умным, чем разработчики JVM, проблем не существует.

Это что, надо править сорц JVM? А более культурно из программы порулить - не катит? oO

> Объекты в Java создаются атомарно.

Круто. А malloc происходит не атомарно ли? Или опять же - В ЧЕМ ГЛОБАЛЬНОЕ ОТЛИЧИЕ? :)

> Если new не может создать объект, то вылетит исключение времени выполнения

А если malloc не сработает - или культурные люди поймают сразу, или, если они не культурные - вылетит SIGSEGV при попытке поработать с памятью там где ее не было. А 10 принципиальных отличий - они в чем? Если абстрагироваться от большей навороченности сущностей и их внутреннего устройства? :)

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

Неуспешный malloc тоже можно обработать. Более того, даже облажавшись это сделать, можно обработать хоть тот же SIGSEGV, информирующий нас о том что мы облажались. То что по дефолту реакция на него - просто выход, возможно, с коредампом - ну, круто. Это не значит что нельзя переопределить обработку этого сигнала. Просто, как многие жабисты вааще ничего осмысленного не пишут в catch, так что оно продолжает просто глюкать дальше, делая вид что вроде как работает, многие сишные програмеры не ловят SIGSEGV или ошибки выделения памяти, так что при обнаружении столь похабного бага прога просто сразу убивается.

> Какие мы глупые! У нас нет профилировщика, чтобы анализировать сколько и каких
> объектов создаётся и не убирается во время работы нашей программы! Хи-хи. :))

Ну, судя по тому как некоторые НЕДЕЛЯМИ корпят, пытаясь понять WTF, с довольно скромным результатом - не так уж этот Бэтмэн и крут... :)))

Ответить | Правка | Наверх | Cообщить модератору

155. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от JL2001 (ok), 19-Янв-11, 15:16 
> В сях, кстати, для повышения надежности работы программы можно хапнуть себе приличный
> кус памяти *заранее*, поюзать его и никому не отдавать, далее юзая
> уже его (можно выделять память более гранулярно уже из этого куска).

тота в линуксе бывает "выделено памяти 10 гигов, физической памяти 4 гига, свопа нет" - специально для таких умных кто запрашивает память но не использует - ОС память выделяет по факту использования а не по факту запроса

Ответить | Правка | К родителю #108 | Наверх | Cообщить модератору

159. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 19-Янв-11, 17:46 
> не использует - ОС память выделяет по факту использования а не
> по факту запроса

О, мне всегда было интересно - допрет ли кто до этого тонкого момента ;).

Я кстати тоже думал об этом. А это... сразу после выделения и используйте блок целиком, какие проблемы? :) Например, заполнив весь отхапанный массив чем-нибудь (рандомом, чтобы послать еще и дедупликаторы, если их вдруг на ваш зад внедрят). Кстати, если я правильно помню, такое поведение ОС можно запретить, если оно не нравится. В общем то оврекоммит - это некий поиск приключений на свою жопу (любая попытка декларировать большее количество ресурсов чем по факту есть и надеяться что по факту никто столько не поюзает - ненадежна по природе своей). ИМХО если волнует надежность работы при потенциально возможном душняке с памятью - пользоваться оверкоммитом врядли стоит.

Ответить | Правка | Наверх | Cообщить модератору

112. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от Crazy Alexemail (??), 18-Янв-11, 20:20 
А вот бороться в таких ситуациях свинство и есть. Не свинство - высыпать хорошую обильную диагностику чтобы было что разработчику отослать и вежливо сдохнуть, ничего больше не поломав.
Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

122. "Разработчики Firefox обратили внимание на проблемы с работой..."  +1 +/
Сообщение от iZEN (ok), 18-Янв-11, 21:55 
> А вот бороться в таких ситуациях свинство и есть.
> Не свинство -
> высыпать хорошую обильную диагностику чтобы было что разработчику отослать и вежливо
> сдохнуть, ничего больше не поломав.

Ну, так, Firefox4 написан на C++, у него нет стандартного стека исключений, который можно было бы вывести и сдохнуть, в отличие от Java-программ. Ничего не остаётся, как крошить Xorg.

Ответить | Правка | Наверх | Cообщить модератору

125. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от klalafuda (?), 18-Янв-11, 23:08 
> Ну, так, Firefox4 написан на C++, у него нет стандартного стека исключений, который можно было бы вывести и сдохнуть, в отличие от Java-программ. Ничего не остаётся, как крошить Xorg.

Вообще то, как IMHO не сложно догадаться прослушав хотя бы первый курс любого околоитешного ВТУЗа, виртуальная джава машина ни чем не отличается в указанном случае от firefox. Или любого другого пользовательского приложения. И если в результате его, возможно, некорректной работы вылетает критичный системный сервис.. Да, конечно, это джава виновата. И фокс. На пару с плюсами. Вне всяких сомнений.

Ответить | Правка | Наверх | Cообщить модератору

188. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 20-Янв-11, 12:40 
> Вообще то, как IMHO не сложно догадаться прослушав хотя бы первый курс
> любого околоитешного ВТУЗа, виртуальная джава машина ни чем не отличается в
> указанном случае от firefox.

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

Ответить | Правка | Наверх | Cообщить модератору

192. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от iZEN (ok), 20-Янв-11, 14:22 
> Более того, JS выполняющийся в браузере ничем принципиально не отличается от байткода выполняющегося в JVM.

Ой, ну и бред же ты несёшь иногда. :))))


Ответить | Правка | Наверх | Cообщить модератору

200. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 20-Янв-11, 21:18 
> Ой, ну и бред же ты несёшь иногда. :))))

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

Принципиальных отличий не так уж и много. А то что языки разные и вообще в одном случае байткод а в другом скрипт - это уже детали. А общий смысл действа и результат будет достаточно похож. Или в случае браузерного JIT ты уже не хочешь верешать о том как это суперкруто и какие там возможны офигительные оптимизации, блаблабла? :)))

Ответить | Правка | Наверх | Cообщить модератору

202. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от iZEN (ok), 21-Янв-11, 10:31 
> Принципиальных отличий не так уж и много. А то что языки разные
> и вообще в одном случае байткод а в другом скрипт -
> это уже детали.

Это — действительно детали. Но языки JavaScript и Java ещё ведь отличаются смыслом: один динамический, а другой статически типизированный. Модульность и публичный API для взаимодействия с библиотеками, предоставляемый средой исполнения Java, вообще не присущи JavaScript'у. И в этом разница между этими языками — колоссальная.

> А общий смысл действа и результат будет достаточно похож.

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

> Или в случае браузерного JIT ты уже не хочешь верешать
> о том как это суперкруто и какие там возможны офигительные оптимизации,
> блаблабла? :)))

JavaScript убог по своей природе.

Ответить | Правка | Наверх | Cообщить модератору

203. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 21-Янв-11, 14:56 
> Это — действительно детали. Но языки JavaScript и Java ещё ведь отличаются
> смыслом: один динамический, а другой статически типизированный.

Опять же, это детали :).

> Модульность и публичный API для взаимодействия с библиотеками,
> предоставляемый средой исполнения Java, вообще не присущи JavaScript'у.

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

> И в этом разница между этими языками — колоссальная.

Но мы говорили не о языках. А о их средах исполнения. JVM - среда исполнения Java апплетов. Браузер - среда выполнения JS. Я нахожу как-то весьма двухстандартным заметить что браузер писан на сях и обосрать си, но технично "не заметить" то же самое для JVM.

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

Спасибо, Кэп! :)

> JavaScript убог по своей природе.

А Java монструозна и как-то так оказалась нафиг не нужна ни в вебе, ни на десктопе. Ну кроме серверной стороны у всяких ынтерпрайзов, может быть :)

Ответить | Правка | Наверх | Cообщить модератору

156. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от JL2001 (ok), 19-Янв-11, 15:29 
>> если язык с лёгкостью позволяет писать неаккуратно - он фактически стимулирует ошибки
> Круто, оказывается это не програмер должен называться криворуким халтурщиком, это язык
> ему оказывается виноват. А потом мы еще удивляемся, когда в программах
> вылезают просто эпичные баги.

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


> P.S. кстати многие логические ошибки бывают куда суровее и опаснее чем технические.
> Обезьяны почему-то упорно кивают на умные языки которые за них подумают
> и им жопу подотрут, но игнорируют этот простой факт. Хотя наиболее
> жуткие и проблемные последствия вылезают как правило именно из-за логических ошибок,
> не привязаннх к языкам *вообще* *никак*. Из-за логических ошибок теряются/искажаются/утекают
> данные. Из-за логических ошибок попадают на деньги. Из-за логических ошибок сталкиваются
> поезда и падают самолеты.

поэтому язык обязан вынуждать писать максимально прозрачно для актуализации логики алгоритма

Ответить | Правка | К родителю #90 | Наверх | Cообщить модератору

169. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 19-Янв-11, 21:20 
> вы машинку авторства которой из этих двух сборочных линий предпочтёте ?

It depends. Роботы ведь могут управляться и бухим оператором, линия может обслуживаться бухим наладчиком, а технический контроль может быть спущен на тормозах, как это случается с всякими ТАЗами. С другой стороны, некоторые специалисты по тюнингу делают весьма крутые штуки, с отличным качеством исполнения, которые к тому же невозможно купить в магазине. Выбирая между продукцией автоТАЗа и крутым кастомным авто, я выберу ессно второе. Вот поделия от жабистов почти всегда отдают "автоТАЗовщиной".

> поэтому язык обязан вынуждать писать максимально прозрачно для актуализации логики алгоритма

Много умных слов ни о чем. Большая часть программ написанных на якобы хороших в этом плане языках на поверку обычно оказывается совершенно обычным дерьмецом. Запросто проигрывая программам на "кривом" и "неправильном" си, например. Наверное дело в том что как вы не запирайте обезьяну за печатной машинкой, а Толстым она не станет все-равно.

Ответить | Правка | Наверх | Cообщить модератору

72. "Разработчики Firefox обратили внимание на проблемы с работой..."  –2 +/
Сообщение от анон (?), 18-Янв-11, 16:45 
> "Браузер ложит Xorg" —  это ещё один Epic Fail программистов C/C++!

Согласен.
И количество батхерта в теме доказывает правоту твоего тезиса.

Ответить | Правка | К родителю #29 | Наверх | Cообщить модератору

93. "Разработчики Firefox обратили внимание на проблемы с работой..."  –1 +/
Сообщение от User294 (ok), 18-Янв-11, 18:09 
> И количество батхерта в теме доказывает правоту твоего тезиса.

Ну да, конечно, лучше если оно забило на ошибку, проработало полдня, а потом начались бы аццкие глюки и никто вообще никогда бы вообще не нашел их причину. Потому что состояние программы совсем не то уже, а то что от проблемного места что-то зависело - да кто ж там разберет и свяжет с глюками то? Спасибо, видел я как дотнетчики и жабисты эксепшны ловят. Детективы - отдыхают. Они порой неделями трахаются с какими-то неочевидными граблями, вылезающими при длительной работе программы. А уж пресловутые утечки памяти... я видел случаи когда жабисты и дотнетчики пытались неделями понять что за фигня с пожироном памяти: толи GC еще не сработал, толи они что-то кому-то не отдали. Выглядит сие весьма и весьма сурово. Извиняюсь, в севых програмах вон valgrind-ом можно под микроскопом каждый пук рассмотреть. А жабисты и дотнетчики почему-то аццки сношаются с своими гарбаж коллекторами, когда юзеры начинают метать кирпичи - "ваша программа сжирает всю доступную память и все загибается/тормозит". По-моему, некоторые преувеличивают плюсы своих подходов и кладут болт на имеющие место быть минусы.

Ответить | Правка | Наверх | Cообщить модератору

95. "Разработчики Firefox обратили внимание на проблемы с работой..."  –1 +/
Сообщение от Аноним (-), 18-Янв-11, 18:17 
>[оверквотинг удален]
> порой неделями трахаются с какими-то неочевидными граблями, вылезающими при длительной
> работе программы. А уж пресловутые утечки памяти... я видел случаи когда
> жабисты и дотнетчики пытались неделями понять что за фигня с пожироном
> памяти: толи GC еще не сработал, толи они что-то кому-то не
> отдали. Выглядит сие весьма и весьма сурово. Извиняюсь, в севых програмах
> вон valgrind-ом можно под микроскопом каждый пук рассмотреть. А жабисты и
> дотнетчики почему-то аццки сношаются с своими гарбаж коллекторами, когда юзеры начинают
> метать кирпичи - "ваша программа сжирает всю доступную память и все
> загибается/тормозит". По-моему, некоторые преувеличивают плюсы своих подходов и кладут
> болт на имеющие место быть минусы.

Потому что в руки насрать жабописцам. Напердячат кода, который за собой память не очищает, а потом не вспомнять, что надо коллектор позвать. Сто сессий отработало - прощай, 14 гигабайт мозгов. И начинается потом:

- Сколько памяти занимает Java?
- Сколько находит - столько и занимает!

Ответить | Правка | Наверх | Cообщить модератору

110. "Разработчики Firefox обратили внимание на проблемы с работой..."  –1 +/
Сообщение от User294 (ok), 18-Янв-11, 20:16 
> - Сколько памяти занимает Java?
> - Сколько находит - столько и занимает!

Да вот только недавно видел цирк:
- Шеф: Жрется XXXX оперативы! Вашумать! Кто жрет? Клиент гадит кирпичами - у него крютой сервер через несколько дней работы загибается!
- Жабисты: !!! (за кадром слышен конский топот каманды жабистов)
- Шеф: ??? Так это вы жрете или это у вас GC не дергается?!
[так проходит неделя]
- Жабисты: ну мы тут что-то нашли, но все-равно использование памяти почему-то со временм растет...

Занавес!

Ответить | Правка | Наверх | Cообщить модератору

117. "Разработчики Firefox обратили внимание на проблемы с работой..."  +1 +/
Сообщение от Knucklesemail (ok), 18-Янв-11, 20:40 
>Круто, оказывается это не програмер должен называться криворуким халтурщиком, это язык ему оказывается виноват. А потом мы еще удивляемся, когда в программах вылезают просто эпичные баги.

Ничего не напоминает?

Ответить | Правка | Наверх | Cообщить модератору

126. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от JL2001 (ok), 18-Янв-11, 23:10 
>[оверквотинг удален]
> Да вот только недавно видел цирк:
> - Шеф: Жрется XXXX оперативы! Вашумать! Кто жрет? Клиент гадит кирпичами -
> у него крютой сервер через несколько дней работы загибается!
> - Жабисты: !!! (за кадром слышен конский топот каманды жабистов)
> - Шеф: ??? Так это вы жрете или это у вас GC
> не дергается?!
> [так проходит неделя]
> - Жабисты: ну мы тут что-то нашли, но все-равно использование памяти почему-то
> со временм растет...
> Занавес!

кстати для незнаек - GC можно принудительно дёрнуть в цикле 10к раз (а "через несколько дней работы" это явно позволяет) после чего GC явно освободит всё что возможно - и вся остальная память - в логических граблях прогера

Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

146. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от Аноним (-), 19-Янв-11, 11:48 
> кстати для незнаек - GC можно принудительно дёрнуть в цикле 10к раз
> (а "через несколько дней работы" это явно позволяет) после чего GC
> явно освободит всё что возможно - и вся остальная память -
> в логических граблях прогера

Тру жава вей, ага. Главное чисто итераций цикла ещё побольше взять.

Ответить | Правка | Наверх | Cообщить модератору

170. "Разработчики Firefox обратили внимание на проблемы с работой..."  +/
Сообщение от User294 (ok), 19-Янв-11, 21:42 
> кстати для незнаек - GC можно принудительно дёрнуть в цикле 10к раз

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

> (а "через несколько дней работы" это явно позволяет) после чего GC
> явно освободит всё что возможно - и вся остальная память -
> в логических граблях прогера

Да никто не спорит что при делании и на яве можно отловить утечки, просто не вижу чем оно принципиально лучше чем без GC получается. Разные методы получить одно и то же ака просрать все полимеры^W память :)

Ответить | Правка | К родителю #126 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру