«Скомпилируй однажды, запускай везде» - это не только Java!

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

В JavaFX сейчас самое интересное - это, ИМХО, язык JavaFX Script.

Что касается Java SE и апплетов, тут есть продвижения в виде "Consumer JRE":

http://java.sun.com/developer/technicalArticles/javase/consumerjre/
http://java.sun.com/developer/technicalArticles/javase/java6u10/

>"Скомпилируй однажды, запускай везде"- это не только Java!

Но еще и 3-4 сотни гентушников с инфарктом.

>64-битные версии не нужны до тех пор пока у вас <4Gb RAM.

Не стОит с таким апломбом демонстрировать свой ламеризм:)

>Дело в том что я не видел извращенцев, ставящих в свою машину именно 3.5Gb (или_сколько_там_надо_чтобы_понадобился_pae). Обычно ставят или 4 планки по 1, или 2 по 2.

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

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

И все перейдут на Xы? Счас:) Фишка в приложениях типа AIR - что нужен некий оббобщенный рантайм (типа JRE/.NET) и все - а с деплоем приложения проблем никаких + все over HTTP - как показывает практика файрвол нужен с одной целью - сделать вид что в TCP протоколе 1 порт - HTTP и все остальное пустить через него. И это объективная реальность.

>А то что никакая корпорация и тем более таможня, ФПС, МВД, КГБ, и пр. не будет пользоваться онлайн-офисом просто по причине запрета выхода с ведомственной сети в интернет, это ты понимаешь?

А что "сеть" для тебя уже обозначает "интернет" мой юный друк? Ты где-то здесь углядел прогнозы что все перейдут на былогугл и быдлолив?

зачем нужны ява и эйр, если есть дотнет?

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

Зачем это вообще всё нужно, если серьёзные приложения пишутся на С и собираются под каждую платформу отдельно? Про производительность по-моему уже никто и не думает.

> Про производительность по-моему уже никто и не думает.

Иногда скорость разработки софта важнее, чем его производительность.

Есть несколько (я знаю 3) языков, позволяющих писать довольно быстрый (быстрее чем Java) софт в приемлемые (быстрее, чем на C) сроки, но их по тем или иным причинам почти никто не использует.

Можно их огласить?

Эта информация Вам ничем не поможет, если вы их уже не знаете. Да и причины для того, чтобы их не использовать вполне объективные: Отсутствие историй успешного их применения, отсутствие необходимых библиотек, глючность компиляторов...

Про производительность реализаций различных языков можно посмотреть здесь: http://shootout.alioth.debian.org

>При этом на всех компьютерах эти приложения будут одинаково...

...не работать

> Вообще-то когда уже >3Gb нужны.

В Линухе нужны когда RAM>700 с чем-то мег. В противном случае будет использоваться костыль под названием HIGHMEМ, поскольку нехватит адресного пространства, чтобы отобразить всю имеющуюся физическую память, и может потребоваться доболнительный временный маппинг при манипуляции с таблицами страниц.

Adobe AIR? Только вдоль.

> Впротивном случае будет использоваться костыль под названием HIGHMEМ, поскольку нехватит адресного пространства, чтобы отобразить всю имеющуюся физическую память

Ерунда какая. Все прекрасно отображается. Костыль под названием highmem нужен для того чтобы несколько изменить стратегию аллочения памяти, и выделить дополнительное пространство под таблицу страниц, которая должна лежать ниже первого метра.

Из 32битного режима абсолютно непринужденно адресуется ровно 4 gb физической памяти. Другое дело что под одну задачу средствами архитектуры как правило нельзя выделить все 4gb, так как надо где-то держать os.

>>"Скомпилируй однажды, запускай везде"- это не только Java!

>Но еще и 3-4 сотни гентушников с инфарктом.

разве что в воображении обкурившихся дистрофанов-вантузятников

>Из 32битного режима абсолютно непринужденно адресуется ровно 4 gb физической памяти. Другое дело что под одну задачу средствами архитектуры как правило нельзя выделить все 4gb, так как надо где-то держать os.

А если этой задаче еще нужно мапить файл или видеопамять?

>"Скомпилируй однажды, запускай везде" - это не только Java!

Расскажите это Томми"!

>Иногда скорость разработки софта важнее, чем его производительность.

Я бы даже сказал - так практически всегда.

Не читал, но осуждаю. У меня даже флэш в браузере отключен.

ЗЛО!!!

Вступай и компелируй! В месте мы сила!

>64-битные версии не нужны до тех пор пока у вас <4Gb RAM.
>svr4 (*) (24.04.2008 22:58:54)

Далеко не так, вы бы почитали для чего ЕЩЁ 64 бита используются.
Могу только небольшой пример дать, думаю там сами погуглите:
доп 8 регистров в новой glibc по возможности юзаются для передачи параметров в функцию, а не пресловутый стек, улавливаете?

Adobe AIR нам не нужен

Триумфальное шествие теперь уже гплной явы, многим пидорам не даёт покоя. Фтопку адоб и мелкомяхких!

>доп 8 регистров в новой glibc по возможности юзаются для передачи параметров в функцию, а не пресловутый стек, улавливаете?

Если бы он улавливал, то не писал этот ламерский бред в каждом треде.

>Могу только небольшой пример дать, думаю там сами погуглите: доп 8 регистров в новой glibc по возможности юзаются для передачи параметров в функцию, а не пресловутый стек, улавливаете?

А как только эта функция вызывает другую, все эти параметры отправляются... в стек. Так какая разница раньше они там оказались или позже?

Большее количество регистров помогает только немного уменьшить количество операций загрузки-выгрузки промежуточных данных из стека между вызовами функций. Итог - 64-битные программы менее эффективны, если в них нет 64-битных целочисленных вычислений, и им не нужно больше 2Гб памяти.

>Ерунда какая. Все прекрасно отображается. Костыль под названием highmem нужен для >того чтобы несколько изменить стратегию аллочения памяти, и выделить >дополнительное пространство под таблицу страниц, которая должна лежать ниже >первого метра.

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

>А как только эта функция вызывает другую, все эти параметры отправляются... в стек. Так какая разница раньше они там оказались или позже?

Дурень, бля, иди кури чем отличается fastcall от stdcall.

>Эта информация Вам ничем не поможет, если вы их уже не знаете.

Педон, Похапэ? Или клисп, хаскель, ерланг?

>доп 8 регистров в новой glibc по возможности юзаются для передачи параметров в функцию, а не пресловутый стек, улавливаете?

А ничего, что вершина стека всегда в кеше и накладные расходы фактически нулевые?

>>Иногда скорость разработки софта важнее, чем его производительность.

>Я бы даже сказал - так практически всегда.

Не скорость разработки софта, а скорость введения проекта в экплуатацию.

Очень быстро написанный _неработоспособный_ на данном железе и под заданной нагрузкой софт всегда хуже медленно разработанного, но работающего ПО.

Автор добавь метку "ненужно" И вообще на ЛОР-е надо завести такую практику: народ сказал не нужно -> ставим метку "ненужно" и не морочим людям голову

Эта шняга не умеет проигрывать что-то отличное от mp3! И ей низзя писать звук с микрофона в файл на винте. Низачот!

>Педон, Похапэ? Или клисп, хаскель, ерланг?

ФОКСПРО

>А ничего, что вершина стека всегда в кеше и накладные расходы фактически нулевые?

Это ты про DOS? А то у нас в мультизадачной ОС немножко по-другому: стеков столько, сколько процессов/тредов.

>Большее количество регистров помогает только немного уменьшить количество операций загрузки-выгрузки промежуточных данных из стека между вызовами функций.

Про "немного" - это ты сам придумал?

>Итог - 64-битные программы менее эффективны, если в них нет 64-битных целочисленных вычислений, и им не нужно больше 2Гб памяти.

Итог: ты сам для себя сказки пишешь, потому что "дык, читать нЕчего".

>Это ты про DOS? А то у нас в мультизадачной ОС немножко по-другому: стеков столько, сколько процессов/тредов.

И что, стек процесса из-за этого не окажется в кеше? Таки адрес возврата полюбому в кеш кладется.

>И что, стек процесса из-за этого не окажется в кеше? Таки адрес возврата полюбому в кеш кладется.

Какого именно стека? Адрес возврата какого именно процесса? Прежде чем нести бред, почитай хотя бы недавнюю дискуссию на lklm про "4К стек для ядра по-умолчанию" - почему 4К стек для x86_64 ядра всегда достаточно, а для x86_32 и 8K мало.

>Очень быстро написанный _неработоспособный_ на данном железе и под заданной нагрузкой софт всегда хуже медленно разработанного, но работающего ПО.

Это парадокс. Медленно проект разрабатывается именно по причине неработспособности результатов быстрой разработки. Я бы посмотрел как быстро проекты пишутся на С. А на жабапитонодотнетах - на раз два.

>А что "сеть" для тебя уже обозначает "интернет" мой юный друк? Ты где-то здесь углядел прогнозы что все перейдут на былогугл и быдлолив?

Так в интранетах и так с БД в основном работают через Apache, Oracle ADF и подобное. Или ты думаешь, что OpenOffice с какой-то радости станет сетевым на уровне интранет? Что это решит, какие проблемы? Не даст начальнику сохранить .doc на локальной машине? Это можно запретить делать другим способом. Что еще?

>А что "сеть" для тебя уже обозначает "интернет" мой юный друк? Ты где-то здесь углядел прогнозы что все перейдут на былогугл и быдлолив?

А в интранетах уже и так с базой работают через Apache, Oracle ADF, IIS и подобное. Или ты думаешь, что OOffice станет вдруг интранет приложением и запускаться по сети? И зачем в интранет это нужно?

>Эта шняга не умеет проигрывать что-то отличное от mp3! И ей низзя писать звук с микрофона в файл на винте. Низачот!

в ~/.bash_history он тебе запишет так, что не отмоешься

P.S. и где таких идиотов находят, неужели в капусте?

> Итог - 64-битные программы менее эффективны, если в них нет 64-битных целочисленных вычислений, и им не нужно больше 2Гб памяти.

Иди на php пиши.

>Какого именно стека? Адрес возврата какого именно процесса?

Тред был про x86 with x86-64 и вопросы типа особенностей адресации памяти касались именно архитектуры ПЦ.
А какие, кстати, еще есть дуалистические процы, где можно выбрать, пользоваться ли 64 или 32?

>Прежде чем нести бред, почитай хотя бы недавнюю дискуссию на lklm про "4К стек для ядра по-умолчанию" - почему 4К стек для x86_64 ядра всегда достаточно, а для x86_32 и 8K мало.

И что это должно доказывать? Причем тут скорость? Можно придумать много случаев, где х64 будет выгоднее, и наоборот. Но на практике, почему-то на задачах, где 64-битность в явном виде не нужна, х64 обычно сливает.

Главное преимущество х64(точнее, недостаток ia32), кроме адресации, - это всегда используется современный набор инструкций и выкинут убогий fpu, в то время, как под 32 бинарные дистры часто собраны с march=i586, в лучшем случае i686, без всяких sse и тп

> Так в интранетах и так с БД в основном работают через Apache, Oracle ADF и подобное.

Работают, но не везде, далеко не везде...

> Или ты думаешь, что OpenOffice с какой-то радости станет сетевым на уровне интранет?

До звезды - ОО или какой ГуглеО, главное с таким-же функционалом.

> Что это решит, какие проблемы?

ГИБКОСТЬ. Все решения с "Apache, Oracle ADF и подобное" "железобетонные" - на каждый чих надо контору разрабов звать (ну да, для последних это рай :) С вкраплением "офисов" определённая часть (линейно зависящая от квалификации работников "клиента") программ становится более "дружелюбной".

> Не даст начальнику сохранить .doc на локальной машине? Это можно запретить делать другим способом. Что еще?

Не с того конца смотришь. Это даст огромное число приложений сделать "клиент-серверными" с одной стороны и гибкими как "офисный винегрет" с другой.

>Очень быстро написанный _неработоспособный_ на данном железе и под заданной нагрузкой софт всегда хуже медленно разработанного, но работающего ПО.

А вот если на предприятии есть штатный 1С-ник, код там неработоспособный абсолютно всегда, то там, то тут, несмотря на то, что эксплуатируется.

> А вот если на предприятии есть штатный 1С-ник, код там неработоспособный абсолютно всегда, то там, то тут, несмотря на то, что эксплуатируется.

Баги есть практически в любом софте. А иногда надо пусть 66% но прямо сейчас, нежели 99.9% через 5 минут (завтра, через неделю, "мы вам предоставим наш бизнес-план...")

офигеть, на Open Source конференциях Некрософт пеарится как хз кто, на ЛОРе новости о проприетарных поделках убогого Айра ... куда катиться мир ?

> Вступай и компелируй! В месте мы сила!

Все говорят, что мы _в_месте_. Все говорят, но не многие знают, в каком :)

(Це) ВЦ