Здравствуйте, Lonely Dog, Вы писали:

LD>Добрый день!

LD>Стоит задача разработки кроссплатформенного сервера. Требуется работа на Windows и Linux. Взаимодействие с базами данных, LDAP-каталогами (вместо баз данных), нативным кодом. Вот думаю, на чем лучше писать.
LD>1. С# — все задачи покрываются кроме поддержки Linux. Нет уверенности в том, что Mono достаточно стабилен. С другой стороны, я немнлого знаю .NET, мне будет легче контролировать разработку.
LD>2. C++ — У меня вообще нет опыта кроссплатформенной разработки. Т.е. нет уверенности в том, что будут использоваться правильные библиотеки, подходы и пр. Кроме того, работа с базами данных на C# проще. Да и все остальное делается быстрее.
LD>3. Java — наверное лучший выбор. Вот только я Java вообще не знаю. Никогда ничего не писал. Т.е. на первых порах надо будет ее осваивать. И будет сложно контролировать команду.
LD>4. Python — мы не готовы отдавать исходный код. Возможно, его можно обфусцировать. Но опять же, Питон я почти не знаю. И какие там есть либы, подходы, инструменты не в курсе.

LD>Коллеги, может вы что-нибудь подскажите?

Без знания конкретики, с такими условиями(сервер, кроссплатформ, работа с базой) — java. C шарпом и моно правда могут быть проблемы там, где их не ждете. Плюсы можно конечно, но будет дольше и затратнее.
То, что на джаве никогда не писали — это не проблема, так как она простая как пробка, и во многом похожа на шарп.

Здравствуйте, avpavlov, Вы писали:


LD>>Собственно, другие продукты такой же направленности (Oracle, Novell) пишутся на Java. Думаю, питон тут вообще не подходит (на 95%).

A>А зачем писать свой сервис? Проще поставить ЛДАП и каждое приложение завязать на него. Куча софта и так уже поддерживают ЛДАП из коробки, так что в нашем случае это было именно доделка своих приложений.

Потому-что LDAP (и куча приложений) не поддерживают отпечатки пальцев, сетчаки глаза, БСК и пр. А мы поддерживаем.

Здравствуйте, Аноним, Вы писали:

LD>>Коллеги, может вы что-нибудь подскажите?
А>Попробуй посмотреть на http://pocoproject.org, С++ серверная часть на ней пишется очень легко и просто.
Спасибо, посмотрю!

Здравствуйте, Lonely Dog, Вы писали:

A>>А зачем писать свой сервис? Проще поставить ЛДАП и каждое приложение завязать на него. Куча софта и так уже поддерживают ЛДАП из коробки, так что в нашем случае это было именно доделка своих приложений.
LD>Потому-что LDAP (и куча приложений) не поддерживают отпечатки пальцев, сетчаки глаза, БСК и пр. А мы поддерживаем.
Вообще говоря, поддерживают. То есть, им пофиг — получаем каким-нибудь образом Kerberos ticket, а дальше оно само.

Здравствуйте, Lonely Dog, Вы писали:

LD>Собственно, другие продукты такой же направленности (Oracle, Novell) пишутся на Java. Думаю, питон тут вообще не подходит (на 95%).

не знаю что там за продукты такой же направленности у оракла, а с Novell NDS я работал оч плотно. и нет, оно не на Java! там все внутренности на С (разумеется). от Java там только средство администрирования (ConsoleOne), и то, местами платформо-зависимое (было). Была еще нелепая попытка сделать ГУЙ на сервере (!) на Java (начиная с NW5)... было жутко!

насчет разных авторизаций: я еще в конце 90стых с помощью Novell NDS логинился голосом -- а ты говоришь "не поддерживается"
кроме голоса было доступно куча другой биометрии (железа для которой я в жизни не видывал).

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

Здравствуйте, Cyberax, Вы писали:

C>Вообще говоря, поддерживают. То есть, им пофиг — получаем каким-нибудь образом Kerberos ticket, а дальше оно само.
Ну так вопрос именно в получении этого тикета. Для этого нужно куда-то отправить данные пользователя.
И собрать их перед этим. А это все-таки зависит от технологии аутентификации.

Здравствуйте, zaufi, Вы писали:

Z>Здравствуйте, Lonely Dog, Вы писали:

LD>>Собственно, другие продукты такой же направленности (Oracle, Novell) пишутся на Java. Думаю, питон тут вообще не подходит (на 95%).

Z>не знаю что там за продукты такой же направленности у оракла, а с Novell NDS я работал оч плотно. и нет, оно не на Java! там все внутренности на С (разумеется). от Java там только средство администрирования (ConsoleOne), и то, местами платформо-зависимое (было). Была еще нелепая попытка сделать ГУЙ на сервере (!) на Java (начиная с NW5)... было жутко!
Например Novell Access Manager.


Z>насчет разных авторизаций: я еще в конце 90стых с помощью Novell NDS логинился голосом -- а ты говоришь "не поддерживается"
Z>кроме голоса было доступно куча другой биометрии (железа для которой я в жизни не видывал).
Ну дело не только в логоне в NDS. А в поддержке кастом-приложений. Аутентификации с мобильных клиентов, поддержке AD FS.

Здравствуйте, Lonely Dog, Вы писали:

LD>Здравствуйте, Cyberax, Вы писали:

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

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

Здравствуйте, smeeld, Вы писали:


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

Ага, именно так.

Здравствуйте, Lonely Dog, Вы писали:

C>>Вообще говоря, поддерживают. То есть, им пофиг — получаем каким-нибудь образом Kerberos ticket, а дальше оно само.
LD>Ну так вопрос именно в получении этого тикета. Для этого нужно куда-то отправить данные пользователя.
LD>И собрать их перед этим. А это все-таки зависит от технологии аутентификации.
В общем, я бы писал на Java или Python. Если сервису много не нужно, то хватит самого дохлого железа последних 5 лет на любой вариант.

Здравствуйте, Cyberax, Вы писали:

C>В общем, я бы писал на Java или Python. Если сервису много не нужно, то хватит самого дохлого железа последних 5 лет на любой вариант.
Спасибо! Сам склоняюсь к одному из этих варинтов. Пока остается открытым вопрос со скрытием исходников питона.

Здравствуйте, Lonely Dog, Вы писали:

LD>Здравствуйте, Cyberax, Вы писали:

C>>В общем, я бы писал на Java или Python. Если сервису много не нужно, то хватит самого дохлого железа последних 5 лет на любой вариант.
LD>Спасибо! Сам склоняюсь к одному из этих варинтов. Пока остается открытым вопрос со скрытием исходников питона.

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

Здравствуйте, savitar, Вы писали:


S>я использую Cython на питтонном коде для сокрытия исходников и некоторого ускорения, если последнее важно, то применяя augmenting, можно добиться очень сильного
ускорения, в 10-ки раз, при этом, это все еще питон в котором я гоняю палку в PyCharm'е, а в продакшн идет натив. рекомендую.
Ага, спасибо!

Здравствуйте, smeeld, Вы писали:

S>boost не подойдёт?

и при чем тут буст?

Здравствуйте, Abyx, Вы писали:

S>>boost не подойдёт?

A>и при чем тут буст?

Кроссплатформен, сэр. В смысле по исходникам.
В смысле нужно только перекомпилировать, и не нужно переписывать.

Здравствуйте, Lonely Dog, Вы писали:

C>>В общем, я бы писал на Java или Python. Если сервису много не нужно, то хватит самого дохлого железа последних 5 лет на любой вариант.
LD>Спасибо! Сам склоняюсь к одному из этих варинтов. Пока остается открытым вопрос со скрытием исходников питона.
Поставляйте только .pyc-файлы, и ещё слегка их обфусцируйте.

Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, Lonely Dog, Вы писали:

C>>>В общем, я бы писал на Java или Python. Если сервису много не нужно, то хватит самого дохлого железа последних 5 лет на любой вариант.
LD>>Спасибо! Сам склоняюсь к одному из этих варинтов. Пока остается открытым вопрос со скрытием исходников питона.
C>Поставляйте только .pyc-файлы, и ещё слегка их обфусцируйте.

не знаю на счет обфускации, но давать только .pyc думая, что ты не даешь исходники, это очень наивно. это https://github.com/wibiti/uncompyle2 поможет развеять сомнения.

Здравствуйте, Lonely Dog, Вы писали:

LD>...

еще вариант языка: Go (golang)? или это уже слишком...

Здравствуйте, smeeld, Вы писали:

S>>>boost не подойдёт?

A>>и при чем тут буст?

S>Кроссплатформен, сэр. В смысле по исходникам.
S>В смысле нужно только перекомпилировать, и не нужно переписывать.

да, там разве что ASIO с сокетами, а ТСу надо БД, LDAP и еще хз знает что.

Здравствуйте, Abyx, Вы писали:


A>да, там разве что ASIO с сокетами, а ТСу надо БД, LDAP и еще хз знает что.

API клиентских либ у всех СУБД тоже, чаще всего, одинаковое, что для unix-like, что под win.