Вышел (http://www.citadel.org/doku.php/news:citadel.7.50.released) релиз Citadel 7.50 (http://www.citadel.org/), продукта для организации коллективной работы, распространяемого в рамках лицензии GPLv3. Пакет включает в себя средства для чтения электронной почты, совместного планирования по календарю, адресную книгу, форум, списки рассылок, службу мгновенного обмена сообщениями. Работа производится через web-интерфейс, оформленный в "AJAX-стиле" и поддерживающий WYSWYG средства редактирования документов. Альтернативно распространяется клиент для запуска на локальной машине и  консольный клиент, работающий через telnet/SSH.

URL: http://www.citadel.org/doku.php/news:citadel.7.50.released
Новость: http://www.opennet.me/opennews/art.shtml?num=21301

• Вышел релиз Citadel 7.50, продукта для организации коллектив...,Voviandr, 22:52 , 16-Апр-09
• Вышел релиз Citadel 7.50, системы для организации коллективн...,iii, 23:27 , 16-Апр-09
  • Вышел релиз Citadel 7.50, системы для организации коллективн...,Voviandr, 23:45 , 16-Апр-09
    • Вышел релиз Citadel 7.50, системы для организации коллективн...,sergeyvp, 00:26 , 17-Апр-09
      • Вышел релиз Citadel 7.50, системы для организации коллективн...,Voviandr, 01:23 , 17-Апр-09
    • Вышел релиз Citadel 7.50, системы для организации коллективн...,Knuckles, 01:07 , 17-Апр-09
      • Вышел релиз Citadel 7.50, системы для организации коллективн...,Voviandr, 01:15 , 17-Апр-09
        • Вышел релиз Citadel 7.50, системы для организации коллективн...,Knuckles, 01:25 , 17-Апр-09
      • Вышел релиз Citadel 7.50, системы для организации коллективн...,анонимно, 01:37 , 17-Апр-09
        • Вышел релиз Citadel 7.50, системы для организации коллективн...,анонимно, 01:40 , 17-Апр-09
        • Вышел релиз Citadel 7.50, системы для организации коллективн...,Knuckles, 01:47 , 17-Апр-09
      • Вышел релиз Citadel 7.50, системы для организации коллективн...,User294, 04:51 , 17-Апр-09
        • Вышел релиз Citadel 7.50, системы для организации коллективн...,none, 13:02 , 17-Апр-09
          • Вышел релиз Citadel 7.50, системы для организации коллективн...,User294, 13:59 , 17-Апр-09
            • Вышел релиз Citadel 7.50, системы для организации коллективн...,none, 18:52 , 17-Апр-09
              • Вышел релиз Citadel 7.50, системы для организации коллективн...,pavel_simple, 20:10 , 17-Апр-09
              • Вышел релиз Citadel 7.50, системы для организации коллективн...,User294, 20:52 , 17-Апр-09
                • Вышел релиз Citadel 7.50, системы для организации коллективн...,none, 00:35 , 18-Апр-09
                  • Вышел релиз Citadel 7.50, системы для организации коллективн...,pavel_simple, 01:16 , 18-Апр-09
                    • Вышел релиз Citadel 7.50, системы для организации коллективн...,none, 10:39 , 18-Апр-09
                      • Вышел релиз Citadel 7.50, системы для организации коллективн...,pavel_simple, 23:20 , 18-Апр-09
                  • Вышел релиз Citadel 7.50, системы для организации коллективн...,User294, 18:16 , 18-Апр-09
        • Вышел релиз Citadel 7.50, системы для организации коллективн...,Аноним, 13:48 , 17-Апр-09
          • Вышел релиз Citadel 7.50, системы для организации коллективн...,User294, 14:46 , 17-Апр-09
            • Вышел релиз Citadel 7.50, системы для организации коллективн...,belpartizan, 14:47 , 18-Апр-09
              • Вышел релиз Citadel 7.50, системы для организации коллективн...,Пожалуйста, 00:08 , 20-Апр-09
                • Вышел релиз Citadel 7.50, системы для организации коллективн...,belpartizan, 00:28 , 20-Апр-09
                  • Вышел релиз Citadel 7.50, системы для организации коллективн...,Пожалуйста, 09:27 , 20-Апр-09
                    • Вышел релиз Citadel 7.50, системы для организации коллективн...,belpartizan, 09:53 , 20-Апр-09
              • Вышел релиз Citadel 7.50, системы для организации коллективн...,User294, 09:43 , 20-Апр-09
        • Вышел релиз Citadel 7.50, системы для организации коллективн...,Аноним, 13:52 , 17-Апр-09
          • Вышел релиз Citadel 7.50, системы для организации коллективн...,User294, 14:53 , 17-Апр-09
    • Вышел релиз Citadel 7.50, системы для организации коллективн...,trdm, 02:13 , 17-Апр-09
  • Вышел релиз Citadel 7.50, системы для организации коллективн...,User294, 04:39 , 17-Апр-09
• Вышел релиз Citadel 7.50, системы для организации коллективн...,Ivan, 01:42 , 17-Апр-09
• Вышел релиз Citadel 7.50, системы для организации коллективн...,trdm, 02:18 , 17-Апр-09
• Вышел релиз Citadel 7.50, системы для организации коллективн...,mvc, 02:57 , 17-Апр-09
  • Вышел релиз Citadel 7.50, системы для организации коллективн...,Юниксоид, 10:15 , 17-Апр-09
• Вышел релиз Citadel 7.50, системы для организации коллективн...,Billi, 07:08 , 17-Апр-09
• Вышел релиз Citadel 7.50, системы для организации коллективн...,mag, 09:31 , 17-Апр-09
• Вышел релиз Citadel 7.50, системы для организации коллективн...,anonymous, 10:46 , 17-Апр-09
• Вышел релиз Citadel 7.50, системы для организации коллективн...,rm, 11:01 , 17-Апр-09
  • Вышел релиз Citadel 7.50, системы для организации коллективн...,Hettikus, 11:33 , 17-Апр-09
• Вышел релиз Citadel 7.50, системы для организации коллективн...,rm, 11:54 , 17-Апр-09
• Вышел релиз Citadel 7.50, системы для организации коллективн...,pannikola, 01:44 , 19-Апр-09

опенсорсный аналог sharepoint-а ?

написан на С! респект! верю что произвлдительность высока)

>написан на С! респект! верю что произвлдительность высока)

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

http://linfoline.homedns.org/API/glib/index.html

http://linfoline.homedns.org/API/gobject/index.html

>http://linfoline.homedns.org/API/glib/index.html
>
>http://linfoline.homedns.org/API/gobject/index.html

спасибо за ссылки.

Ты конечно не поверишь, но такие вещи, как абстрактные структуры данных и алгоритмы можно реализовать не тольк в C++. Например, в Java (есть дженерики) (и да, Ява не тормозит), Pascal (sdl, джненерики в freepascal опять же).
Плюсы сильны несколько другими вещами.

>Ты конечно не поверишь, но такие вещи, как абстрактные структуры данных и
>алгоритмы можно реализовать не тольк в C++. Например, в Java (есть
>дженерики) (и да, Ява не тормозит), Pascal (sdl, джненерики в freepascal
>опять же).
>Плюсы сильны несколько другими вещами.

всё я знаю и про яву, и про паскаль, и даже про C# и моно, и про дженерики тоже.
сравнение идёт по линии - С vs С++, заметьте, я не говорил про то, что в других языках программирования аналога или замены абстрактным структурам данных и алгоритмам нет ( я знаю, что есть), я говорил про то, что в чистых сях без плюсов их реализовать самому напряжно.

>в чистых сях без плюсов их реализовать самому напряжно.

Так оно и не надо ;) Си нужно воспринимать как портабельный ассемблер, не более.

>как абстрактные структуры данных и алгоритмы можно реализовать не тольк в C++

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

>Java (есть дженерики) (и да, Ява не тормозит)

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

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

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

Понимаете, можно и зайца научить курить, но зачем? ;)

>Если я правильно понял, то джава - весьма посредственный клон с++

Вы неправильно поняли. Думаю, в очередной раз сравнивать C++ и Java тут бессмысленно, поэтому просто скажу, то Ява это абсолютно другая философия. Я считаю, что создатели Явы совершенно ничего не позаимствовали у плюсов. Ну за исключением скобок :)

>(и да, Ява не тормозит),

Ага, только на интенсивных вычислениях и работе с памятью сливает всего-то в каких-то 2.5-3 раза сям, а так фигня :).Пример: http://quicklz.com/ - думаю им не резонно свою же либу чмырить =).На одном и том же алгоритме и жава и сишарп - в нехилой жо... по сравнению с сями.И кстати а чего это на якобы не тормозящей жаве никто не пишет всерьез архиваторы, видеокодеки и прочее добро где производительность реально важна?Зато выхлопов от жабистов и дотнетчиков про то как оно не тормозит почему-то навалом.В отличие от не тормозящих программ, особенно тех где скорость работы натурально имеет значение, а не как в гуе где 99.9999(9)% времени прога ждет реакции юзера и плюс-минус в 3 раза - не так сильно заметно (и то, гуйное жава-дотнетовское добро сразу заметно - по ублюдочной скорости реакции контролов на юзерские действия, дикому выжирону памяти и общей тормознутости).

архиваторы не пишут..., мда
jar - это что?
а вы в курсе, что некоторые (критичные) ф-ции - напрямую обращаются в нативную реализацию?
JNI типа
примеры можно найти в разных ЖВМ, например в ИБМ для Lotus Domino - много таких
SWT - тоже вызывает длл платформы

а ваше личное негативное восприятие не нужно отображать на язык

>jar - это что?

Хаха, это зип-архивы.Дреееееевний такой формат.И чего?Вы мне нормальный архиватор покажите, ну там что-то типа 7-зипа например.С приличным сжатием и скоростью работы.

>а вы в курсе, что некоторые (критичные) ф-ции - напрямую обращаются в
>нативную реализацию?

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

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

А что, мое восприятие как-то меняет факты насчет скорости работы жава-программ?В общем то одна из причин негативного восприятия - так это то что все виденные программы на жабе были довольно тормозными и без зазрения совести кушали дохрена оперативки.А уж если программам на жаве надо что-то похитрее чем кнопки жать... ну вон на соурсфорже лежит какая-то жава-байда для работы с GPS приемниками на основе чипсета MTK.Дык блин, у этой поделки грабли - с ее прямими обязанностями.Оно, пардон, с компортом (в т.ч. и виртуальным, поверх блутус\юсб) горбато работает.Ужас.Что следующее?Разучимся реагировать на кнопки клавиатуры?Замечательные, бэть, программы.

>[оверквотинг удален]
>
>А что, мое восприятие как-то меняет факты насчет скорости работы жава-программ?В общем
>то одна из причин негативного восприятия - так это то что
>все виденные программы на жабе были довольно тормозными и без зазрения
>совести кушали дохрена оперативки.А уж если программам на жаве надо что-то
>похитрее чем кнопки жать... ну вон на соурсфорже лежит какая-то жава-байда
>для работы с GPS приемниками на основе чипсета MTK.Дык блин, у
>этой поделки грабли - с ее прямими обязанностями.Оно, пардон, с компортом
>(в т.ч. и виртуальным, поверх блутус\юсб) горбато работает.Ужас.Что следующее?Разучимся реагировать на
>кнопки клавиатуры?Замечательные, бэть, программы.

вы что-то пытаетесь навязать ;) ...

как должна работать ВМ сама - в воздухе чоль?

ничего не тормозит - Лотус Нотес на линухах (в эклипсовом исполнении) стартует за 1-2 сек.

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

да ВМ сама отъест память, но для сложной проги это не самая затратная часть работы

а снятие головной боли по очистке памяти (в теории ;) - является большим преимуществом, в любом случае - в плюсах хуже с этим

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

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

а вот вы о разном спорите -- один говорит тормозит, второй - что хороший язык.

а я к java  (и к языку и в sun'овской его реализации в часности) отношусь с должным уважением, но о том что тормозит и память жрёт спорить не стану.

Под задачу нужен инструмент, но не придумали (видимо) ещё идеального языка программирования, и хорошо что java развивается и находит новые ниши применения.

>вы что-то пытаетесь навязать ;) ...

Я всего лишь высказал свое отношение к таким программам.

>как должна работать ВМ сама - в воздухе чоль?

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

>ничего не тормозит - Лотус Нотес на линухах (в эклипсовом исполнении) стартует
>за 1-2 сек.

Стартануть - это полдела.А работать потом с человеческой скоростью пожирая умеренно ресурсов - оставшаяся часть.Время старта программы - это критерий, гм, чего?По моим наблюдениям - долго стартуют программы на дотнете.Особенно при первом запуске - это вообще пи$#ц.Видел стартующие минут по пять на довольно нехилом P-IV 2.8. Я такой жести даже при загрузке программ с магнитофона не припоминаю - и то едва ли пару минут грузилось...

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

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

>тем более для ВМ можно ограничить её потребление

Да, замечательно - если прога налетит на лимит, она просто вылетит (а какие у нее варианты то есть если памяти не дали?)

>и байткод поддается лучшей оптимизации и предсказуемо в сравнении в оптимизацией для
>плюсов,

Вот докажите это не пустым трындежом а конкретными бенчмарками.Вон тот же quicklz - чем вам не алгоритм?Достаточно прост чтобы запортировать за разумное время и даже референсный вариант который можно взять за точку отсчета - уже есть.Ну вот и покажите нам на практике крутую оптимизацию от правильных кодеров которая натянет сишную версию той же либы?Не хотите? :)

>как пример - виртуальные классы и методы - замедляют работу программы (да
>и оптимизация там невозможна)

И тем не менее, в сях\сях++ можно выжать достойную скорость если оно надо, а хотя-бы и избегая тормозных конструкций.Почему-то игрушечники вон все требовательные к ресурсам гамезы (не тетрис а что-нить 3-мерное, полноэкранное например) тоже вон пишут на сях\сях++.И ничо, работает.При том дум II у меня бегал с 320х240 и пристойным FPSом на 133МГц проце класса 486, с видяхой без 3D ускорителя и архитормозной по современным меркам оперативкой EDO RAM.А на мобилке с хваленой жавой на мелком экране 3D даже с пятком полигонов - никак даже пяток FPS родить не может.Все виденные 3D игры на жаве-тормзилово!Хоть и соотв. апи есть вроде, и работает на 220 МГц ARM-е, с быстрой DDR-памятью и т.п. - по скорости работы такая система запросто обставит того 486 антика пожалуй.

>да ВМ сама отъест память, но для сложной проги это не самая
>затратная часть работы

Еще всякие накладные расходы будут.И когда garbage collector'у вздумается все притормозить - тоже вопрос интерсный.В результате понятно почему мало-мальски серьезные геймдевы на яву и близко не смотрят.Как и те кого интерсовала производительность.

>а снятие головной боли по очистке памяти (в теории ;) - является
>большим преимуществом, в любом случае - в плюсах хуже с этим

Тут вы в чем-то правы, кроме того, дятлов делающих ошибки типа buffer overrun поменьше будет если их согнать на языки где так лохануться нельзя.Ну и будут они писать тормозные программы на этом.Которым то нельзя, это не можно... как вон тот горбыль хреново работающий с компортами про который я писал.Не, для всякой бизнес-хрени где главное чтобы было написано еще вчера, вагон глюков могут и простить если хоть как-то работает, скорость не нужна (в крайнем случае машину помощнее поставят) и потребление памяти до балды (бизнесмены богатые, если что - докупят оперативки :D) - нормально вполне.Но вон кого-то как видим не устроило - сделали более ядрено, на сях, с беркелеевской базой.В этом случае тормозить по идее толком нечему.

>это не доказывает ущербности язка

Хорошо, если вы перепишете хотя-бы тот же quicklz (именно на яве, без читерства с вызовами нативного кода) и он натянет сишную версию (где там у нас хваленая оптимизация?) - я признаю что на яве можно и не тормозные программы писать.Но вот как-то исторически сложилось что по тормознутости и монстрильности обычно гуйные программы ранжируются имхо так: самые легкие - GTKшные, но они и слишком просты зачастую.И некоторые аспекты GTK типа уродских диалогов открытия файлов - не рулят.Исключение - WxГлюкдовс с его си++ позволяет писать програмерам довольно навернутые, монстрильные и тормозные программы с рядом противных особенностей у данной библы и даром что юзается GTK.KDEшно-Qtшное добро обычно более увесистое чем гномовское, но и более навороченное обычно.Жавистое добро вообще как правило бесит тормозной работой и переходит порог моей толерантности к тормозам софта и потреблению оперативы(хотя с этим полегче, она дешевая, что впрочем не значит что я готов подарить фоновой байде типа торента дофига оперативы - оно должно сидеть в фоне и не тормозить систему, ИМХО).В этом плане довольно приятна та же трансмиссия например.Простенькая но зато и незаметная в плане схаваных ресурсов - можно оставить работать допустим без ущерба FPSам в какойнить игрухе.В многозадачной системе вообще чем меньше ресурсов жрет каждая задача - тем лучше.Благо задач обычно хочется запустить довольно много :)

как бы вам объснить, чтоп об одном говорили ;)
игры - когда САН сделает движки подо все платформы, тогда и игры будут на джава
кодеки - аналогичная история
поймите - ВМ и есть большая длл (условно) обеспечивающая кроссплатформенность
выж не  станете переписывать (без крайней нужды) библиотеки поставляемые с QT или пытаться самому реализовать их ф-ционал...

про компрессоры - САН напишет, я воспользуюсь ;)
ежели припрет - сделаю на на JNI, но в этом случае мне придется постигать особенности всех платформ или сделать тока для одной (двух)

проводите аналогию с QT (ВМ) и вы поймете мою т.з.

др. словами - недостаток ВМ - то, что я вынужден ждать реализации от САН (или сообщества), ежели не хочу сам реализовывать для всех платформ
таже история будет и в случ. с QT ;)

пи-код в дельфях и васике - не лучший вариант (тежеяйца)
плюсы без библиотек имеют чисто теоретический интерес ;)

утилиты, при отсутствии нативной реализации в ВМ, писать на джаве бессмысленно (очевидно)

ну вот не нужно сравнивать то, что сравнивать не нужно

dll это никакая не виртуальная машина.

только формально ;), а задумайтесь по сути...
что делает ВМ - байт код исполняет, но исполняет с пом. вызовов нативной платформы (в конечном результате)
терь рассмотрим типичны программы...
что имеем - обращения к специфичным либам с параметрами, ормирование запросов к: БД, вебсервисам, ХТТП, мыльные протоколы, IM...
др. словами формируются некие стринги и скалярные типы, кот. потом обрабатываются либами и затем, еще, и перечисленными сервисами
все более популярны патерны программирования...
они врядли добавят скорости ;), зато гибкость обеспечена

а в случае вызова простых ф-ций ВМ из джава проги - происходит прямой вызов нативного кода

>только формально ;), а задумайтесь по сути...

если вы так продолжите "формально" - то и зайти можете далеко, только ни туда куда нужно.

1. на java написано достаточно кода, которые не использует никакие библиотеки, за исключением быть может 10 библиотечных вызовов.

2. jni на то и jni, что придуман быть прослойкой между java и dll.

3. вм никогда не была, и не будет так-же проста как dll, просто потому что задачи и условия работы разные.

4. вм ВСЕГДА будет тормознее нативного кода, другое дело, что может и не так сильно, чтобы например писать на с/c++ или тем более asm.

5. каждой задаче - свой инструмент.

>игры - когда САН сделает движки подо все платформы, тогда и игры
>будут на джава

Жава есть под винды, линукс и наверное мак.Мало чтоли?Игры на жаве - есть.Ну там тетрис.Пакман.И подобная ерунда.В которую на спектрумах и подобных гоняли с их 64 кило оперативы и процом на пару МГц :).А вот что-то уровня Nexuiz?Quake 3?Как минимальная планка.Не хотите изобразить?:)

>кодеки - аналогичная история

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

>поймите - ВМ и есть большая длл (условно) обеспечивающая кроссплатформенность

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

>про компрессоры - САН напишет, я воспользуюсь ;)

Ну вот и ждите пока сан что-то там (не)сделает, ага.А мне не нравится когда что-то могут сделать только божки из (сан, M$, ...) а вы сами - пролетаете.Сан и микрософт - конторы большие, не гибкие.Под лично ваши хотелки прогибаться и не подумают.И если мне там какойнить ogg vorbis нужен, пока его в нативном коде реализует сан или микрософт я могу вероятно ждать до глубокой старости и есть неслабый шанс так и не дождаться этого.

>проводите аналогию с QT (ВМ) и вы поймете мою т.з.

До некоторой то степени вы правы, но факты штука упрямая - ну не попадалось мне программ которые были бы легкими, быстрыми и при том хорошо бы работали так что пользоваться было бы приятно.Тот же Azureus как-то впечатления пушинки не производит.Напротив, довольно-таки неповоротливое такое монстрило.В итоге если есть юзер с хилой машиной и ему надо торент - я советую не питоновую поделку Deluge и не ява-поделку Azureus. Я советую маленький и легкий transmission, писаный на сях (морда юзает GTK).Который у юзеря будет просто работать и не будет жрать вагон памяти (которой у него мизер) и не будет грузить проц (который у юзера дохлый).

>таже история будет и в случ. с QT ;)

В случае си/си++ нормально написанный исходник без вопросов компилится что на i386, что на Sparc, что на AMD64, что на ARM.Именно поэтому тот же х64 линух ненапряжно юзать (в отличие от виндов кстати).Весь тот же софт что и для i386 версии - вот он, перекомпилили и он тут работает.Все что требуется - 1 раз скомпилить под платформу.И все.При том это даже не обязательно проблемы автора кода - майнтайнеры разных систем зачастую сами  скомпилят и соберут пакеты под вон ту систему и поддерживаемые ей архитектуры :).Также в природе есть билд-сервисы которые могут автоматически собрать нечто под вагон разных архитектур и систем.

Итого - есть QT, есть допустим Psi.И меня на AMD64 десктопе радуют.И знакомых на i386 тоже.А теперь у меня есть карманный девайс, Nokia N800 - на ARM.На ней - тоже есть Qt. и кто-то скомпилил и Psi.И оно - работает.В общем то примерно так же как и на десктопе.Это - хорошая портабельность, ибо я вижу работу одной и той же либы и программы как минимум одновременно на i386, AMD64, ARM.И на любой другой платформе с достаточными ресурсами увижу...

А теперь мы берем допустим Jimm (J2ME).Как достаточно неплохую аську, вполне симпатично выглядящую на мобилах.И что мы обнаруживаем?На десктопе просто так - вообще фиг запустишь, надо какие-то нетривиальные танцы с бубном, потому что для десктопов J2ME официально как бы нет.А на андроиде допустим запустить - это вообще реально?Для сей/сей++ то все просто - рекомпил, ну может еще построение пакета под вон ту систему и архитектуру, если по уму. И ... все.С жавой все круто в теории а на практике тем не менее те же си/си++ куда портабельнее и есть под кучу архитектур под которую жабы - просто нету, или нету нужной редакции или чтобы запустить нужную редакцию нужен такой бубен что ни 1 юзер так делать все-равно не будет.Вообще не понимаю - зачем жабисты развели такой кавардак с несовместимыми версиями и самопальными реализациями типа андроида...

>пи-код в дельфях и васике - не лучший вариант (тежеяйца)

А я с этим и не спорил.Тот же вьюжл васик всегда отличался тормознутостью а потому использовался только пионерией для написания мелких программ(в лучшем случае, в хучшем мат юзеров стоял адский).Опять же - вспомнилась еще 1 прога работающая с компортом.На васике этом самом.Автор заявил минимальные требования: P-IV 2.8GHz. Дело в том что на меньшем оно не успевало выгребать данные из файла компорта и теряло данные а автор был к тому же достаточно дубов чтобы надеяться что в многомегабайтном потоке данных никаких проблем не будет.Отсюда и минимальные требования - если что-то меньше, прога работала через жо! :).Восторг ее юзеров (у которых между прочим слились битые бэкапы флеш-памяти их устройств, при заливке просто убивающие устройства) вы себе представляете - автора красочно втаптывал в грязь всяк кто получил битый бэкап :).После такого "теплого" приема клиентурой аффтар освоил с++ билдер и переписал программу в менее черезжопном виде.

>плюсы без библиотек имеют чисто теоретический интерес ;)

А какие проблемы с библиотеками?На допустим AMD64, ARM и в принципе любой иной архитектуре есть все те же библиотеки что и на i386.Как минимум - то что опенсорцное.Исключение разве что дилетансткие приблуды написанные непортабельно, такого среди библиотек включаемых к дистры я к счастью не заметил.

>утилиты, при отсутствии нативной реализации в ВМ, писать на джаве бессмысленно (очевидно)

Это типа намек что надо нативный костыль, вот тогда жаба дескать сойдет?Хм, оригинально.

Опять двадцать пять. Хватит уже глупости повторять. По хорошему прошу - загляни в код quicklz, автор НЕ java программист. Так и на Си можно написать тормозной отстой.

>Опять двадцать пять. Хватит уже глупости повторять. По хорошему прошу - загляни
>в код quicklz, автор НЕ java программист.

Ну так напишите ваш вариант компрессора, кодека, ... чтоб он уделал современных сишных аналогов написанных без халтуры, с оптимизацией.Ну вон H.264, LZMA или еще что-нить тяжеленькое попробуйте вон написать на яве.А для начала можете и просто quicklz переделать, так как вам угодно, обещаю забенчить переделанный вариант в сравнении с сишным во всех позах, если вы на это сподвигнетесь как крутой жава-програмер.Он сравнительно простой.Какие проблемы то?А то жиденькие отмазки жава-кодеров - заманали.Отмазки - есть.Быстрого софта, особенно того в котором скорость натурально важна - не вижу.Зато теоретических распальцовок о скорости - это всегда пожалуйста.

>Ну так напишите ваш вариант компрессора, кодека, ... чтоб он уделал современных
>сишных аналогов написанных без халтуры, с оптимизацией.Ну вон H.264, LZMA или
>еще что-нить тяжеленькое попробуйте вон написать на яве.А для начала можете
>и просто quicklz переделать, так как вам угодно, обещаю забенчить переделанный
>вариант в сравнении с сишным во всех позах, если вы на
>это сподвигнетесь как крутой жава-програмер.Он сравнительно простой.Какие проблемы то?А то жиденькие
>отмазки жава-кодеров - заманали.Отмазки - есть.Быстрого софта, особенно того в котором
>скорость натурально важна - не вижу.Зато теоретических распальцовок о скорости -
>это всегда пожалуйста.

Неуважаемый троль, расскажите ка мне о XSLT процессоре на С/С++, который был бы быстрее чем saxon (написанный на чистой java). И не надо расказывать что XML/XSLT не нужно.

>Неуважаемый троль, расскажите ка мне о XSLT процессоре на С/С++, который был
>бы быстрее чем saxon (написанный на чистой java). И не надо
>расказывать что XML/XSLT не нужно.

http://www.davidpashley.com/articles/xslt-benchmarks.html

>>Неуважаемый троль, расскажите ка мне о XSLT процессоре на С/С++, который был
>>бы быстрее чем saxon (написанный на чистой java). И не надо
>>расказывать что XML/XSLT не нужно.
>
>http://www.davidpashley.com/articles/xslt-benchmarks.html

Этот бенчмарк несколько устарел.
В последниз версиях уже появилась куча дополнительных оптимизаций запросов (а в коммерческой версии ещё и компиляция XPath в JVM код). Пол года назад он (в версии 8.5) давал до 5Mb/s на огромных XML (около 500ֵMb). Остальные XSLT процессоры просто не тянули такие объёмы.

>>http://www.davidpashley.com/articles/xslt-benchmarks.html
>
>Этот бенчмарк несколько устарел.
>В последниз версиях уже появилась куча дополнительных оптимизаций запросов (а в коммерческой
>версии ещё и компиляция XPath в JVM код). Пол года назад
>он (в версии 8.5) давал до 5Mb/s на огромных XML (около
>500ֵMb). Остальные XSLT процессоры просто не тянули такие объёмы.

Это лишь подверждает правило: На Java идеально оптимизированные программы работают так же быстро, как посредственно написанные на С/С++.

В случае с saxon мы имеем дело не со скоростью Java, а с хорошо написанными опитимизированными алгоритмами. Надеюсь Вы не собираетесь отрицать, что если этиже оптимизации (как компиляция XPath например с помощью LLVM и более продвинутые алгоритмы) перенести в libxslt, то приведенный выше бенчмарк повторится с похожим соотношением, только уже с другими цифрами.

>Это лишь подверждает правило: На Java идеально оптимизированные программы работают так же
>быстро, как посредственно написанные на С/С++.
>
>В случае с saxon мы имеем дело не со скоростью Java, а
>с хорошо написанными опитимизированными алгоритмами. Надеюсь Вы не собираетесь отрицать, что
>если этиже оптимизации (как компиляция XPath например с помощью LLVM и
>более продвинутые алгоритмы) перенести в libxslt, то приведенный выше бенчмарк повторится
>с похожим соотношением, только уже с другими цифрами.

Я утверждаю что скорость будет примерно одинаковой. В Java код компилируется с помощью Jit (а он не менее эффективен чем gcc), а уменьшение скорости идёт из-за большего количества cache miss (а в saxon в процесе работы память почти не перераспределяется).

А в этих тестах вполне возможно для каждой xslt запускался JVM. А пока он скомпилирует весь байткод в нативный код, это требует некоторого времени.

К слову о бенчмарках (хоть и со старой Jvm но результат показателен): http://www.idiom.com/~zilla/Computer/javaCbenchmark.html

Так что Java не медленнее С/С++ в прямых руках.

>Неуважаемый троль,

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

> расскажите ка мне о XSLT процессоре на С/С++,

Как только вы перепишете жава-вариант quicklz так чтобы он (без читов с вызовом нативного кода) уделал сишный, я подумаю над тем чтобы изучить этот вопрос :)

Пример Azureus потребляет в разы меньше CPU чем Deluge (у которой ядро на с++, и только UI на питоне).

>Пример Azureus потребляет в разы меньше CPU чем Deluge (у которой ядро
>на с++, и только UI на питоне).

Хреново реализовать можно что угодно.А этот азуреус - тормозное блоатваре.Например, трансмиссия и т.п. работает и на мелких роутерах и на моей n800 и прочая.Этому вашему блоатваре такое не грозит - просто не влезет по ресурсам.Вообще =)

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

+1024
сам пробовал самопальные списки создавать дабы руку набить...
глюков наелся по-уши.
STL реально удобная веЩь!

> написан на С! респект! верю что произвлдительность высока)

Да и в беркелеевской базе тормозить особо нечему.Наверное ядреная штука...

О! Видать живы ещё настоящие индейцы, такие, как те мега-дядьки что в своё время писали all-in-one-Интернет-стеки для ДОС...

а русификация есть?

дайте C++ MVC CGI! прошу уже год никто ничего не предложил! ;-(

Ну и кому такой кошмар нужен ?
http://www.webtoolkit.eu/wt/src/hello.C

Дешевле купить ещё серверы.

Посмотрел, ставится на удивление просто и приятно.
Интерфейс слабоват, до Zimbra не дотягивает.

C и Berkeley DB ? ребята действительно суровый попались, только высокая производительность совокупности этих компонентов оправдывает немало затраченного на разработку времени.

ЗЫ: сам не совсем понял че написал

> Вместо внешней СУБД хранение данных Citadel производится в Berkeley DB базе.

Ночной кошмар системного администратора.

все бы ничего но !для аутлука
You can demo the Insight Connector, free for 30 days....везде развод
опять получается работаем только либо на линухе либо , платим...:(

Всем хочется кушать.

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

Всё замечательно - но для СНГ - не канает - с кирилицей никак. Вернее с utf8 - ни Кои ни 1251 не пробовал. Кстати -  не такая уж она и шкстрая. И ксати - она оказывается из bbs разрослась - админить удобнее всего через как раз через нее.
Но танцы с бубнами не помогли. Вернее так - если использовать её как набор IMAP + POP3 + Jabber + MailMan - в одном флаконе - сойдёт с пивом - но не дай бог с содержимым поработать средствами bbs или веб-интерфейса - "всё пропало - гипс снимают".