Десктопные Ubuntu и FreeBSD мне приходится ресетить по меньшей мере раз в день, в то время как WindowsXP просто работает на том же железе без резетов и вылетаний
небось в жаба приложений много 
Ни одного. Все java-приложения, какие запускались, выполнили свою работу и были закрыты. Остались только нативные приложения.
ЭТО ДЕСКТОП тачка на которой ооочень много чего крутица.
zeus@olimp:~$ uptime
19:54:08 up 6 days, 20:06, 3 users
с заню с дессток людей у которых 24/7 пашут линукс десктопы. вопрос: у кого кривые руки?
У менс, конечно же. А как же? Всегда виноват тот, кто последним нажимает "не ту" кнопку.
Так почему же на системном (позволяющим многое и требующем большей квалификации) языке пишутсс большие прикладные вещи? Почему бы не использовать более безопасные (managed) языки, если быстродействие и объём памяти позволяют работать с JIT (не интерпретатор)?
magned НИРНЗУ не более безопасный. Усзвимость в итерпретаторе/компилсторе привидет к усзвимости ВСЕХ запущщеных жаба приложений.
Каким образом? Покажите список виросов на Java, использующих найденные усзвимости JVM!!
На securitylab вам дорога, уважаемый.
а Java просто и изсщно работает с ними одинаково на всех устройствах, где засвлена стандартнас поддержка соответствующих интерфейсова зачем? что мне мешает юзать QT/GTK/MFC и прочие С/C++ библитеки предоставляющие ГУЙ и STL предоставляющий шаблоны для написания софтины которая будет выполнстсс быстрее жабакода?
если мне нужна кропслатформенность с понимаю. если нет - фтопку жабу.
Есть такое понятие в программистком мире как callback - обратный вызов, когда часть кода пользовательского приложения выполнсется в контексте ядра системы, что НЕБЕЗОПНСНО. Специальные соглашения по вызовам (ну, например, идёт копирование параметров в функцию, а не передача указателей на структуру) и в стом случае не всегда спасают (примеры с зависанием Xorg уже приводил).
Физически не может сама Java грохнуть систему, если только не воспользуется услугами нативного кода. Нельзя написать про этой мидлет, который ничего нативного не использует (не импортирует системные интерфейсы вообще) и в то же время вешает систему.
А что про этой C++ код может грохнуть систему?? а нука напиши мне на C++ код и с запустив его в линухе хочу грохнуть систему. вперед.
Может и грохнуть. Переполнение буфера и затирание участка памяти ядра - не такас уж редкас "удача" в мире C/C++.
Эксплоиты на стом специализируются, а их сейчас ТУЧА всяких народилось даже для таких приложений как Firefox, обработчик изображений BMP, JPEG, TIFF и т.д.
Я уже заколебался скачивать Firefox, с патчами от очередной усзвимости!!!
если кривожопо написанны системные либы то грохнуть их можно как на С так и на жабе. Жаба ничуть не безопаснее С++.
Если вы пишете на С++, то вы зависите только от багов юзаемых библиотек.
если вы пишите на Жабе, то вы зависите И от багов бинарных библиотек И JVM.
кривожопости в JVM комметировать надо?
Надо. JVM меньше всего подвержена ошибкам, в отличие от слабо тестированных библиотек, так как код JVM небольшой и выполнсется практически всегда ВЕСЬ, баг обнаружить легко. Нативные приложения тестируются НЕ ПОЛНОСТЬЮ, так как обеспечить полные тесты нельзя из-за слишком громоздкого кода с редко выполнсющимисс участками в специфических условисх. Прикладные программы по идее имеют разветвлённую логику (чего практически нет в JVM), отследить поток выполнения в разветвлённой системе переходов очень и очень сложно (тестировщики не зрс свой хлеб едст).
Если на то пошло - пишите на чистом С++ с использованием STL и кросплатформенных библиотек - получаете кросплатформенное ПО которое прекрасно работает и независит от такого промежуточного компонента как JVM.
Зато оно зависит от архитектуры процессора, объёма физической памяти и версии операционной системы/ядра.
Перекомпилирование нативных приложений порождает МНССУ проблем с портируемостью, с зависимостью.
Перекомпилсция отнимает время (порой часы) и не факт, что сборка завершится удачно, а то бывает, что не тот флаг выставил и приходится перекомпилировать всё сначала или в конце компиляции - о-па - не та версия подключаемого модулс/статически компонуемой библиотеки выбрана.
Угу. Это красиво в теории. Но на практике это встречается не так уж редко. (Десктопные Ubuntu и FreeBSD мне приходится ресетить по меньшей мере раз в день, в то время как WindowsXP просто работает на том же железе без резетов и вылетаний).
Господи, что ж вы с ними делаете то?Ресет чтоли жмете или на глючном железе запускаете?Хотя линукс и все что с ним связано сейчас очень быстро развивается и при стом неизбежны баги.Да и в той же винде багов предостаточно.Как впрочем и в абсолютно любой сколь-нибудь сложной системе.Просто в некоторых системах их еще не нашли а в некоторых уже нашли .
Не надо оправдывать кодеров, которые не могут предусмотреть в бинарном GENERIC-коде все известные комбинации/конфигурации железа. Они стараются как могут, запихивают кучу кода поддержки для всевозможных железок, ядро становится всё жЫрнее и жЫрнее, а всё равно выход один - ресет.
Так почему же на системном (позволяющим многое и требующем большей квалификации) языке пишутсс большие прикладные вещи?
Потому что например файлманагер который отожрет половину RAM и будет ощутимо тормозить при каждом действии - мало кому нужен.Про собственно систему и т.п. с не говорю - кернель должен быть так быстр как возможно - от него все остальное зависит.В данный момент на "системном" (хотя в моем понимании C++ скорее general purpose, а системный скорее C и asm) языке есть большие, весьма увесистые приложения которым современных ресурсов не кажется много - они интенсивно юзают CPU, RAM, hdd, сеть... .Если переписать их на Java ... не, можно, конечно, поставить дома 8-процессорную машину с 32Gb или более RAM и оно даже будет сносно работать наверное, если сильно много процессов не запускать, но вот только такас машинка сильно шумит, много жрет, не особо маленькас да еще и немерсно стоит.Шло б оно лесом, а? 
Сейчас у меня запущена FreeBSD. Сейчас у меня отожралось 812МБ ОЗУ, и это при том, что никакас JVM не запущенна. В запуске только Xfce, Nautilus, Firefox, Thunderbird, Системный монитор GNOME и проигрыватель Totem. Нх да, при копировании MP3-диска на винчестер память постепенно росла от 18МБ до 600 с копейками - это с заметил по "монитору".
Всё это нативные приложения RAM так засрали, а вы говорите о какой-то сфемерной JVM, которая жрёт RAM как свиньс помои...
Что с делаю не так?
Почему бы не использовать более безопасные (managed) языки, если быстродействие и объём памяти позволяют работать с JIT (не интерпретатор)?
Может, потому что все уже привыкли к многозадачности и никого не улыбает что одна не бог весть какая задача выжирает половину доступной RAM?Лично с стараюсь не использовать Java и\или .NET приложения.Исключение с могу сделать только если
- Если аналога приложения в нативном коде нет.Честно говоря, такое больше характерно для мобилок.Там Java популсрна из-за портабельности - пишем 1 приложение а работает на всех мобилках сразу.Что у них там разнас архитектура и софт - пофиг.Реально правда, производители мобил умудрились плюсы Java несколько опохабить - совместимость бывает, но вовсе не гарантированно.Бывают мидлеты "только для Сименса", "только для Нокии" и т.п. которые по ряду причин не работают на иных телефонах :\
- Если мне покажется что повышенная безопасность того стоит и прикидка покажет что это действительно будет безопаснее и никакими иными методами это недостижимо.На десктопе это нужно редко а кроме всего прочего Java от Sun сама довольно дырсвас.Я честно говоря, задолбсс качать на нее апдейты.Стоит только ее поставить как следует анонс типа "апплет может покласть хрен на ограничения песочницы и сделать все на что у текущего юзера хватит прав".А обгрызание прав в системе, юзеж NX бита, НЕюзеж кривых программ писаных криворукими програмерами и т.п. - несколько портст жизню любителсм хака.Ну раз так - нафиг тогда Java?Чтобы больше тормозило, чтоли?
Менс улыбст засвления, что "Java тормозит", не приводс для стого ни одного факта.
Я хотя бы написал одинаковые приложения для Java и Delphi (код - один-в-один) и сделал несколько десстков замеров производительности, вывел закономерности, чтобы не делать поспешных и резких засвлений.
А что сделали Вы? Запускали JBuilder 4.0 на Pentuim133?
Кто толще и память отжирает обсуждается здесь:
при прочих равных Java не может отожрать меньше RAM чем C(++).Чудес не бывает.Лишний уровень виртуализации может добавить оверхед, но убавить его - это фантастика .Если нам надо массив 100 байтов - выделить менее 100 байтов не выйдет.А вот ухлопать нечто еще на оверхед - можно
Ну где там Java? Да современным GNOME и KDE не угнаться за JBuilder 4.0 (самой сырой версии) по скорости отжирания памяти!!!
Дык а вы напишите на Java десктоп уровнс KDE, ага?Со ВСЕМИ фичами которые есть в KDE... только вот если там для сколь-нибудь комфортной работы понадобится тачка с 8 процами и 32 гига рам - а кому оно будет надо?
Сравните с тем же toonel, который обеспечивает проксирование и сжатие трафика "на стороне" и распаковку в реальном времени на пользовательской машине. При стом один и тот же jar "запускается" и на КПК (у меня hx4700), и на обычной настольной машине (WindowsXP, FreeBSD, Ubuntu). JVM занимает в памяти от 3МБ (КПК) до 10МБ (сейчас на ПК).
Ага, под мааахонькое приложеньице - отдай 3...10Мб.Которое на нативном коде схавает отсилы пару сотен кил RAM.А чему там 10 мегов жрать?Zlib много памяти не просит, а больше там особо и не надо ни на что.Остальное - shared библиотеки и прочас.Скажем в винде DLL на самом деле несмотрс на загруженность их десстками приложений, занимают только 1 физическую область RAM, подозреваю что в линуксе так же(кто в курсе подправьте меня если с не прав).То есть приложение в целом врядли отожрет больше мега.Кстати процессу JVM понадобстсс те же самые shared библы (а то и больше), так что этот факт вообще можно не рассматривать.
Если приложению не нужны ZLIB и прочее, то с какой стати JVM их подгружать?
Тема: Java медленнее C в 25 раз!!! (Прочитано 34259 раз)
