LINUX.ORG.RU

Моно опережает Java на Linux Desktop


0

0

Моно(технология основанная на стандартах разработанных Майкрософт)стала более популярной на рабочих местах c Linux.

Такие приложения как Bansee, Tomboy, GNOME Do стали популярны среди пользователей Линукс за последние 2-3 года.

«Моно, безусловно, более популярно на десктопе, чем Java. За поледние 3-4 года использования Линукс-десктопа, как основного я пользовался единичными Java приложениями» - говорит Stephen O’Grady, аналитик из RedMonk. «Мы видим настоящий рывок в разработке Моно приложений для Линукс» сказал он.

Проблемы с лицензированием Java для Линукс, дали Моно преимущество в несколько лет и возможность закрепиться да десктопе.

С ним не согласен Ian Murdock вицепрезидент по развивающимся технологиям в Sun Microsystems. Хотя он и не смог привести популярных приложений для Линукс десктопа, но считает что ещё рано говорить о том, что Моно обогнало Java. «Я редко пользуюсь моно приложениями» сказал он и добавил, что моно приложения малопопулярны за пределами Линукс сообщества.

В опросе проведённом SDTimes среди разработчиков, практически все согласились с тем, что Моно является более популярной технологией для Линукс десктопа чем Java.

Моно опережает Java на Linux Desktop(google translate)

>>> Mono outpaces Java in Linux desktop development

★★☆☆

Проверено: hibou ()

Ответ на: комментарий от Bioreactor

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

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

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

>Из данного треда.

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

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

> VBX->COM->ActiveX->DCOM->RDS->DAO->ADO->ADO.NET->... и все АБСОЛЮТНО_НОВЫЕ!

В отличие от этой хрени, дотнет действительно толков. Поэтому и пошёл в массы.

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

>Почему "почти" ?

Потому что тот же Эклипс юзает некоторые ненативные виджеты и в некоторых темах они хреново смотрятся :) Но это уже мелочи.

>но ,это не для слабых умов ...:)))


Угу. Даже тот же Netbeans уже нативностью похвастаться не может :-/ Вроде, и тема GTK-шная, но масса несоответствий и, что хуже всего, опять свой собственный кривой рендеринг шрифтов...

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

> Вот из-за таких "не путающих" программы и тормозят безбожно.

Тормозят они из-за плохих алгоритмов. Следите за алгоритмами. Оптимизируйте узкие места.

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

>Специально для тебя гидроцефала, каждый раз выделения памяти не происходит запрос у системы на её выделение, Java изначально при запуске создаёт буфер из которого сама JVM и раздаёт, это позволяет исключить накладные расходы на переключение контекстов в отличии от сишных malloc, calloc. Тоже самое и с освобождением памяти, она возвращается в буфер JVM.

Я то это знаю, а аналитеги ЛОРа щитают, что быстрее C ничего еще не придумано

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

>> VBX->COM->ActiveX->DCOM->RDS->DAO->ADO->ADO.NET->... и все АБСОЛЮТНО_НОВЫЕ!

>В отличие от этой хрени, дотнет действительно толков. Поэтому и пошёл в массы.

Вообще-то и эта хрень в массах сильно много использовалась...

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

>В отличие от этой хрени, дотнет действительно толков. Поэтому и пошёл в массы.

А вообще в самом C# слишком много многословности рассчитанной на слабоумных. Зачем-то сделали спецификаторы полиморфизма у методов, модификаторы параметров и прочее, прочее

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

> Java изначально при запуске создаёт буфер из которого сама JVM и раздаёт, это позволяет исключить накладные расходы на переключение контекстов в отличии от сишных malloc, calloc.

Скромно замечу, что такой менеджер памяти вполне можно намутить и для C.

Только это потянет за собой либо расход памяти на дыры, либо перемещающий GC, который уже требует VM, да.

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

> каждой аппликухе по копии JRE

Откуда такие сведения - "каждой аппликухе по копии JRE"?

> и либ

java -classpath и/или (если определен конкретный тип задач и условий их выполнения) $JAVA_HOME/jre/lib/ext/*.jar уже не модно?

"копии либ" позволяют на одной машине поддерживать две задачи - например, одна на 2-м спринге, а другая на 2.5. Естественно, в ext в этом случае копировать джарники не надо.

Это удобно в больших проектах. Проектах реальных, промышленного масштаба. Не для хелловордистов.

Очень редко используемые (например, в Mac OS X) "копии JRE" позволяют поддерживать унаследованные приложения. Хотя, учите матчасть:

javaс -source версия_исходников -target версия_целевой_VM

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

> >> М-дя... Детская вера в чудеса и серебряные пули...

>> Ну вы можете и дальше кодить в машинных кодах, не вопрос.

> Итак, товарищи, у нас есть два пути: писать под Моно или в машинных кодах. Самому не смешно?

Это был какбэ намёк, что вы так и не поняли, что прогресс в прикладном программировании идёт по пути облегчения жизни кодера, повышения надёжности кода и одновременного понижения требований к классификации кодера.

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

> Вообще-то и эта хрень в массах сильно много использовалась...

А дотнет - ещё больше. Примером тому собснно моно и есть.

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

> некоторые ненативные виджеты и в некоторых темах они хреново смотрятся

Пример?

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

>Скромно замечу, что такой менеджер памяти вполне можно намутить и для C.

>Только это потянет за собой либо расход памяти на дыры, либо перемещающий GC, который уже требует VM, да.

Это и так понятно, без замечаний. Речь шла о JVM и Cи с моей стороны, а не о Си + VM

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

>> Вообще-то и эта хрень в массах сильно много использовалась... >А дотнет - ещё больше. Примером тому собснно моно и есть.

Так и количество компьютеров с того времени сильно выросло, всё объясняется механически

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

>> Maven мне сам найдет нужные либы, соберет проект и задеплоит его.

> Без доступа в Сеть не сможет.

Сможет сможет. Нужно или подтянуть нужные либы в локальное репо ИЛИ прописать откуда брать либы в сам pom.xml

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

> Зачем-то сделали спецификаторы полиморфизма у методов,

Мала-мала оптимайзить вызовы хотят. Это из той же песни, что struct.

> модификаторы параметров и прочее

out - вообще вреден, но иногда может пригодиться. ref - на мой взгляд, действительно лишняя конструкция.

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

> Однако, отсюда следует сделать вывод, что клиенты на дотнет сливают там, где вполне справлялись клиенты на Дельфях?

Нет, разумеется, нельзя.

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

>> каждой аппликухе по копии JRE

> Откуда такие сведения - "каждой аппликухе по копии JRE"?

Я тебе ссылку на описание дал - почитай, а?

>> и либ

> java -classpath и/или (если определен конкретный тип задач и условий их выполнения) $JAVA_HOME/jre/lib/ext/*.jar уже не модно?

Не слежу за жаба-модой. Ты вообще не к тому человеку прицепился.

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

>В отличие от этой хрени, дотнет действительно толков.

В отличие от этой наколенной хрени дотнет грамотно уворовали с достойной реализации поэтому и активно пихают в массы

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

>Так и количество компьютеров с того времени сильно выросло, всё объясняется механически

Угу , "механически" :))
А некоторые "механически" и ласты сложили. (Borland, Delfi)

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

>В отличие от этой наколенной хрени дотнет грамотно уворовали с достойной реализации поэтому и активно пихают в массы

ню ню , а никак с С++ слямзили ?

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

>> Зачем-то сделали спецификаторы полиморфизма у методов, >Мала-мала оптимайзить вызовы хотят. Это из той же песни, что struct.

Это понятно, речь про то, что сделали через жопу, как обычно у M$. Правильнее было бы java way сделать, а именно если нужно оптимизировать путём отказа от полиморфизма использовать спецификатор final или static или privat.

>out - вообще вреден, но иногда может пригодиться.

проще коротко живущий объект возвращать...

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

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

Да чушь это. Чтобы ваять формы прикладные на Delphi7 можно было ничему не учиться ВООБЩЕ. Чтобы ваять на WPF думаешь тоже ничегошеньки знать не надо? Ога, ты ошибаешься

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

>Угу , "механически" :)) >А некоторые "механически" и ласты сложили. (Borland, Delfi)

Мусье, Borland это производитель языка и среды программирования Delphi. И правильно пишется именно DelPHi, и использование множественного числа в твоём предложение неправильно.

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

> проще коротко живущий объект возвращать...

Не проще, а правильней. Просто иногда лишний класс городить - избыточно, проще аутом.

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

> Да чушь это. Чтобы ваять формы прикладные на Delphi7 можно было ничему не учиться ВООБЩЕ.

Да. Результат будет очень, очень хреновый, но действительно -- можно.

> Чтобы ваять на WPF думаешь тоже ничегошеньки знать не надо?

Именно так, ничего. Я переводил VS Express и смутно помню, что там всё расчитано на таких же "дельфистов" :)

> Ога, ты ошибаешься

Как ты понимаешь, мне достаточно найти *один* пример в мою пользу, да ;)

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

>Да чушь это. Чтобы ваять формы прикладные на Delphi7 можно было ничему не учиться ВООБЩЕ. Чтобы ваять на WPF думаешь тоже ничегошеньки знать не надо? Ога, ты ошибаешься

Ruby и принцип наименьшего удивления .

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

>Да чушь это. Чтобы ваять формы прикладные на Delphi7 можно было ничему не учиться ВООБЩЕ. Чтобы ваять на WPF думаешь тоже ничегошеньки знать не надо? Ога, ты ошибаешься

Т.е. dot.net не только не ускоряет работу программиста в сравнении с Delphi, но и сильно её затрудняет?

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

> Borland это производитель языка и среды программирования Delphi.
И не только DelPHi, с & c++ тоже - но , видимо, вы уже не застали это.

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

>И не только DelPHi, с & c++ тоже - но , видимо, вы уже не застали это.

Вообще-то я ещё с turbo С + turbo vision начинал,

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

>Вы ещё Turbo Prolog вспомните.

Я вспомню - мегаштука.

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

> Вы ещё Turbo Prolog вспомните.

Тут упомянуто в ином смысле ( см пассаж с"автоматом"), и конкуренция лукаво не замечается.


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

>метод деплоя "каждой аппликухе по копии JRE и либ" придумал не я.

Его придумали в те годы, когда большинство компьютеров не имело постоянного безлимитного доступа в инет, особенно в сибири и за МКАДом. Изначально же classpath задумывался как указание JVM с каких "сетевых ресурсов" вытягивать нужные классы, но для этого нужен дешевый интернет

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

> одновременного понижения требований к классификации кодера

да, этого я и правда не понял :))))))))))))

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

>Утипути. Ты сравниваешь динамические языки со статическими? И еще удивляешься, когда тебя называют "старым толстым троллем"

JVM не знает, байткод с какого языка ей подсунули, с Java, с Groovy, с Clojure или еще с какой-нить Kawa

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

> JVM не знает, байткод с какого языка ей подсунули, с Java, с Groovy, с Clojure

Айлол. Значит, все баталии вокруг invokedynamic были зря? %)

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

>Установил Debian 5.0 - открыл для себя java программу aTunes.

Вот хоть что-то новое упомянули :))
Хотя при живом дистре в 5 DVD софта еще и шарится по интернету в поисках плееров и 10 метров в пакете - странно это как-то.

> Хоть она и играет посредством мплеера,


Или на xine.

> однако сделано удобно.


Угу , игнорируя оформление окон в системе и двойной клик мышкой,
оттяпал аж 170 Мб при старте (и ~237 Мб при останове) оперативы для одной мелодии на Amd64 Sid - да ,это оооочень удобно.:)))
Да весь Gnome c плюшками меньше расходует памяти и Rhythmbox потребляет ОЗУ на порядок меньше.

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

> Зачем-то сделали спецификаторы полиморфизма у методов, >Мала-мала оптимайзить вызовы хотят. Это из той же песни, что struct.

Еще можно вспомнить break в switch, отсутствие которого -- синтаксическая ошибка. Т.е. написать "сквозной" switch в стиле С низзя. Не берусь судить, плохо это или хорошо, но почему бы просто не сказать: switch действует а-ля паскаль, break не нужен?

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

>Не берусь судить, плохо это или хорошо, но почему бы просто не сказать: switch действует а-ля паскаль, break не нужен?

Сишный ситаксис диктует по-привычке сквозные case. И кто-то так и сделает и потом будет пытаться понять, почему не работает. Так что, как минимум, предупреждение тут нужно.

...

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

Так что меньше всего ошибок потенциальных именно в варианте с ошибками без break. Хотя это и не особо красиво :)

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

> >Тормозят они из-за плохих алгоритмов. Следите за алгоритмами. Оптимизируйте узкие места. +1000 Верно!

Так а кто спорит? Просто возможности дотнет/моно в плане оптимизации этих самых узких мест довольно ограниченны.

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

> Сишный ситаксис диктует по-привычке сквозные case

Ну и как это смотрится -- вводить достаточно м-м... необоснованный синтаксис в языке исключительно чтобы ублажить неофитов от С++?

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

>> Не слежу за жаба-модой.

> Тем не менее Вы-таки почему-то следите за Джава-трэдами.

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

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

Ну, в этом языке слишком много взято от Си++ :)

KRoN73 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.