The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Доступен ReOpenLDAP 1.1.6, форк проекта OpenLDAP

13.08.2017 21:20

Вышла новая версия ReOpenLDAP — форка проекта OpenLDAP, с устранением массы ошибок и ряда доработок для стабильной работы репликации. Проект ориентирован на надежность и производительность при использовании в решениях с высокой нагрузкой и промышленных системах в сфере телекоммуникаций. С выпуском 1.1.6 проект ReOpenLDAP отметил три года с момента своего основания (публичный форк появился чуть позже). Всё это время ReOpenLDAP работает 24x7 в инфраструктуре ПАО МегаФон, обеспечивая высоконагруженную обработку запросов в multi-master кластере с full-mesh репликацией.

Причиной создания форка стал отказ включения в основной состав OpenLDAP ряда исправлений из-за желания сохранения совместимости с устаревшими Си-компиляторами (совместимость с компиляторами без поддержки вариативных макросов, которые появились в стандарте C99, нарушалась лишь в одном патче из большой серии исправлений). После форка ветка ReOpenLDAP master поддерживается в стабильном состоянии и соответствует OpenLDAP/2.4.x, с добавлением отдельных доработок из OpenLDAP/master. Ветка ReOpenLDAP next соответствует следующей версии OpenLDAP/2.5.x.

Версия 1.1.6 аккумулирует работу 8 месяцев этого года и включает: более сотни коммитов, в том числе более 50 исправлений ошибок; поддержку musl-libc, а также ряд доработок для совместимости и упрощения сборки; Continuous Integration на инфраструктуре Travis-CI и Circle-CI.

С этим релизом ветка 1.1 получает статус архивно-стабильной. В ней будут исправляться ошибки, но какая-либо разработка будет прекращена. В свою очередь, работы в ветке 1.2 начнутся с переработки API в сопутствующих ldap-библиотеках с утратой совместимости с предыдущим версиями. Это позволит, с одной стороны, получить более прозрачное и удобное API, которое будет провоцировать меньше ошибок. С другой стороны, переработка API необходима для устранения неоднозначностей и адекватной работы статических анализаторов кода (Coverity, PVS-Studio и др.).

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

К сожалению, новые возможности не даются бесплатно. Для возможности их реализации в libmdbx был существенно переработан (и ещё не зафиксирован) внутренний формат БД, с потерей совместимости с предыдущими версиями.

Пользуюсь случаем хочется ответить на частый вопрос "Почему нет пакетов?": ReOpenLDAP ориентирован на достаточно специализированные сценарии применения, для которых не представляется возможным создать универсальную конфигурацию и собрать соответствующий пакет. Во всех известных (авторам) случаях используются адаптированны под собственные нужды конфигурации (опции configure, включая подключаемые модули и оверлеи), в частности используются монолитные сборки с LTO.

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

  1. Главная ссылка к новости (https://github.com/leo-yuriev/...)
  2. OpenNews: Перевод интервью c главным архитектором проекта OpenLDAP
  3. OpenNews: OpenDJ - новый открытый LDAP-сервер, продолживший развитие Sun OpenDS
  4. OpenNews: Доступен модуль авторизации LDAP для nginx (nginx-auth-ldap)
  5. OpenNews: Релиз свободного LDAP-сервера Mandriva Directory Server 2.4.1
Автор новости: Леонид Юрьев
Тип: Программы
Короткая ссылка: https://opennet.ru/47015-openldap
Ключевые слова: openldap, ldap, reopenldap
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (82) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 22:21, 13/08/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Чем оно отличается от OpenLDAP? С апстримом синхронизируется или нет?
     
     
  • 2.2, Леонид Юрьев (?), 22:37, 13/08/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Да, "синхронизируется".
    Хотя "апстрим" кошмарен, если разобраться )

    Рекомендую глянуть wiki, там более-менее всё рассказано = https://github.com/leo-yuriev/ReOpenLDAP/wiki

    Более подробный вариант = http://0x1.tv/ReOpenLDAP_%E2%80%94_%D1%81%D0�)

     
     
  • 3.3, Леонид Юрьев (?), 22:39, 13/08/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Упс, безопасный вариант второй ссылки = http://bit.ly/2fD7sCL
     
     
  • 4.33, Michael Shigorin (ok), 16:25, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> OSSDEVCONF-2016
    > Упс, безопасный вариант второй ссылки = http://bit.ly/2fD7sCL

    Кстати, приезжайте в этом году :)

    И ещё кстати: заметил сборку reopenldap-2.4.44 для эльбруса, не расскажете? (начиная с того, что нынче с версионированием)

     
     
  • 5.35, erthink (ok), 17:03, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Постараюсь Но увы обещать не могу Тут вот надо-бы в Брюссель ехать на https... большой текст свёрнут, показать
     
     
  • 6.52, Shtirlitsus (??), 15:05, 16/08/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Если кратко, то это не я, а ребята из РедСофт.

    клевета. мы под Эльбрус ReOpenLdap не собирали.

     
     
  • 7.55, erthink (ok), 17:12, 16/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> Если кратко, то это не я, а ребята из РедСофт.
    > клевета. мы под Эльбрус ReOpenLdap не собирали.

    Пардон, у меня "под подозрением" были только вы ;)
    Точнее я был уверен...

    Больше идей нет, пакетов не видел, и патчей тоже.

    Причем там были мелкие гадости, которые поправил кажется весной.
    Чел собирал с libc-muls, кажется для ARM и там что-то повылазило (git log --oneline | grep musl).
    Поэтому для Эльбруса оно в лоб не собралось-бы.

    Но если будут вести - маякните pls.

     
     
  • 8.89, Michael Shigorin (ok), 19:33, 22/08/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Записал в тудушку спросить при встрече ... текст свёрнут, показать
     

  • 1.5, Аноним (-), 00:08, 14/08/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +6 +/
    > В свою очередь, работы в ветке 1.2 начнутся с переработки API в сопутствующих ldap-библиотеках с утратой совместимости с предыдущим версиями.

    Речь вот об этой наркомании? :

           int ldap_search_ext(
                  LDAP *ld,
                  char *base,
                  int scope,
                  char *filter,
                  char *attrs[],
                  int attrsonly,
                  LDAPControl **serverctrls,
                  LDAPControl **clientctrls,
                  struct timeval *timeout,
                  int sizelimit,
                  int *msgidp );

     
     
  • 2.11, erthink (ok), 07:41, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    gt оверквотинг удален Нет В этом API просто много параметров и пугающие LDAPC... большой текст свёрнут, показать
     
     
  • 3.28, Аноним (-), 14:08, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Вы видели первую версию API ldap_search(), без _ext* ? Вот это называется "логично и корректно", а то что я привел - уже писали долбаные наркоманы, попытавшиеся запихнуть множество из того, что раньше настраивалось через десяток вызовов ldap_set_option() opaque-хэндла в параметры одного вызова поиска.

    Вся сокетная подсистема на этом стиле живёт, весь ioctl, netlink, и много кто ещё (sqlite, mysql, ...). И только авторы openldap-а Дартаньяны, и знают как надо библиотечное api проектировать для Си.

    А то что там в коде можно найти ещё более лютый ппц - я ни минуты не сомневаюсь.

     
     
  • 4.37, erthink (ok), 17:38, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    ldap_search просто вызывает ldap_search_ex подставляя кучу NULL Использоват... большой текст свёрнут, показать
     

  • 1.8, Ph0zzy (ok), 06:15, 14/08/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Если OpenLDAP не подошел может быть было лучше эти посмотреть:
    * http://directory.apache.org/
    * http://directory.fedoraproject.org/
    ?
     
     
  • 2.9, Аноним (-), 06:25, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    FDS вряд ли им подойдет, т.к. неторопливый на их нагрузках (сказывается использование bdb)
     
     
  • 3.10, erthink (ok), 07:16, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    > FDS вряд ли им подойдет, т.к. неторопливый на их нагрузках (сказывается использование
    > bdb)

    Да, примерно так, но хуже.

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

    Один из "неподконтрольных хипстеров" пробовал AD (и из 2008, из 2012, и еще каких-то форточек), но результат был стабильно жуткий.

     
     
  • 4.29, PnDx (ok), 14:21, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Поставить OpenLDAP+HDB|MDB репликой к 389DS|FDS мульти-мастеру?
    1. Управляемость.
    2. Нагрузочная способность.
    3. Профит.
    (4. Нюансы: не поддерживает навороченных хэшей (в 389DS всё на плагинах) и иных плюшек.)
     
     
  • 5.30, erthink (ok), 15:35, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Увы, это все нереально 389DS не справляется с требуемой нагрузкой Если было-бы... большой текст свёрнут, показать
     
     
  • 6.41, PnDx (ok), 20:09, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Да, и в моём случае корень проблемы даже не столько в BDB как таковой на чтении... большой текст свёрнут, показать
     
  • 4.34, Michael Shigorin (ok), 16:28, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Один из "неподконтрольных хипстеров" пробовал AD (и из 2008, из 2012,
    > и еще каких-то форточек), но результат был стабильно жуткий.

    В одном федеральном органе такой AD держался на сильно специальном контракте по поддержке -- интересно, что там сейчас...

     
     
  • 5.63, arkan (?), 13:22, 17/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    >> Один из "неподконтрольных хипстеров" пробовал AD (и из 2008, из 2012,
    >> и еще каких-то форточек), но результат был стабильно жуткий.
    > В одном федеральном органе такой AD держался на сильно специальном контракте по
    > поддержке -- интересно, что там сейчас...

    Не знаю про какой Вы там федеральный орган, но я лично участвовал во внедрении OpenLdap как полноценная замена виндовой AD в крупной компании
    Результаты были вполне хорошие но вот с управляемостью все на самописных скриптах кастылях и тому подобном оставляла желать лучшего
    Да и специалистов как то особо и не нашлось кто отвечал бы чисто за это направление.
    На сколько я знаю сейчас там этот OpenLdap стоит как дополнительный под какие то там задачи


     
     
  • 6.90, Michael Shigorin (ok), 19:36, 22/08/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > Не знаю про какой Вы там федеральный орган, но я лично участвовал
    > во внедрении OpenLdap как полноценная замена виндовой AD в крупной компании

    Вообще LDAP -- не замена AD (который надмножество покорёженного LDAP), это самбу смотреть надо; например, http://altlinux.org/SambaDC (кстати, у нас недавно завелось и на эльбрусе).

     
  • 2.12, erthink (ok), 08:15, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Если OpenLDAP не подошел может быть было лучше эти посмотреть:
    > * http://directory.apache.org/
    > * http://directory.fedoraproject.org/
    > ?

    У OpenDJ или 389DS будет шанс обогнать ReOpenLDAP по скорости только при замене движка хранения на libmdbx.

    Но OpenDJ -- это ява и тамошние ценители седеют просто глядя на код LMDB/libmdbx, даже через JNI.

    А 389DS очень сильно заражен Berkeley DB. Дрянная днк BDB там прослеживается в половине проекта и для возможности подключения другого backend-а нужно проделать большую работу = вычистить хвосты BDB и сформировать достаточный внутренний API для plugable подсистемы хранения.

     
     
  • 3.14, Ph0zzy (ok), 08:50, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    т.е. проблема именно в неприятии java?
    а значит ApacheDS пролетает из-за этого же?
     
     
  • 4.17, erthink (ok), 09:17, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Что значит неприятие Java Неприятие кем Пролетает где Безотносительно Apach... большой текст свёрнут, показать
     
  • 4.23, andy (??), 10:29, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Это не проблема, это реалии жизни. Потому, что большая часть того,
    что пишется на java, являет собой кучу гуано.
     
  • 3.16, Ph0zzy (ok), 09:09, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    а на счет этого
    http://directory.apache.org/mavibot/
    движка что скажете?
     
     
  • 4.26, erthink (ok), 11:40, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    С Mavibot в работе я не сталкивался Судя по описанию его устройство очень близк... большой текст свёрнут, показать
     
     
  • 5.27, Ph0zzy (ok), 12:37, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Последние несколько лет сильно за темой не слежу, так что эта новость первая, которую вижу по данной тематике. Складывается впечатление, что по теме застой. Так что отсутствие свежих бенчмарков показательно.
     
     
  • 6.31, erthink (ok), 15:56, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Я бы не сказал что застой, точнее он только в OpenLDAP причины в моем понимании... большой текст свёрнут, показать
     

  • 1.13, Аноним (-), 08:44, 14/08/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    >хочется ответить на частый вопрос "Почему нет пакетов?"

    хорошо, а почему нет ебилдов?

     
     
  • 2.20, erthink (ok), 09:31, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Потому-что нам они не нужны, а вы их не сделали.
    Welcome = https://github.com/leo-yuriev/ReOpenLDAP/issues/35 :)
     

  • 1.15, Аноним (-), 09:06, 14/08/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    В чем преимущества по сравнению с 389 Directtory Server (RedHat Directory Server)?
     
     
  • 2.18, erthink (ok), 09:23, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > В чем преимущества по сравнению с 389 Directtory Server (RedHat Directory Server)?

    Повторю еще раз = скорость.

    Чтобы у 389DS были шансы сравниться с OpenLDAP или ReOpenLDAP нужно вместо Berkeley DB использовать https://github.com/leo-yuriev/libmdbx или хотя-бы какой-нибудь WiredTiger.

    Причем я полностью согласен, что 389DS сейчас имеет гораздо более красивый и надежный код. Но вот backend хранения - из прошлого века.

     
     
  • 3.22, Аноним (-), 10:28, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    А вы пробовали с Red Hat на эту тему поговорить (разумеется с бенчмарками и прочими пруфами)?
     
     
  • 4.25, erthink (ok), 11:00, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Говорить по-сути не о чем Проблема в другом, и уже давно как бревно в глазу У ... большой текст свёрнут, показать
     

  • 1.19, Аноним (-), 09:26, 14/08/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +4 +/
    Бурханыч еще и в сторону LDAP развивает Интернет?
     
     
  • 2.88, erthink (ok), 00:23, 21/08/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Бурханыч еще и в сторону LDAP развивает Интернет?

    Слоупок я, дошло о чем спрашивали ;)

    Может и развивает, но мне об этом ничего не известно.

    Если говорить о ReOpenLDAP, то эта работа была сделана исключительно для решения проблем возникших (достаточно неожиданно) при внедрении одного из решений Петер-Сервис внутри МегаФона.

    С сентября 2016 проект не аффинирован с какой-либо коммерческой структурой (не считая публичных сервисов: github, travis-ci и т.п.).

     

  • 1.21, Ph0zzy (ok), 10:25, 14/08/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    может быть, если бы вы в своих репозиториях в гитхабе использовали другой язык, удалось привлечь внимание большего количества разарботчиков?
     
     
  • 2.24, erthink (ok), 10:40, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Да, конечно, это очевидно.

    Но "не все так однозначно". Собственно главная проблема унаследована от OpenLDAP.

    Исходный код кошмарен с точки зрения читаемости и подводных камней. Эффективно с ним работать может только авторы, точнее сам Ховард и может-быть кто-то еще.

    Всем остальным приходиться тратить массу времени на понимание написанного, особенно всех взаимосвязей и side effects.

    Поэтому, на самом деле, вне зависимости от языка и прочих ритуалов привлечения внимания, в ReOpenLDAP не будет много больше разработчиков чем в исходном OpenLDAP.

     

  • 1.32, ALex_hha (ok), 16:13, 14/08/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    А почему не LibreLDAP/LibreOpenLDAP? Зачем ломать стереотпы
     
     
  • 2.36, erthink (ok), 17:16, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Исходная цель ReOpenLDAP была попроще = навести минимальный порядок и поправить баги мешающие (мягко говоря) эксплуатации.

    Ну и Libre тогда только у офиса была, стереотипов еще не было )

     

  • 1.38, лютый жабист__ (?), 18:22, 14/08/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Если такие прямо несусветные запросы к производительности, почему не взяли просто in memory rdbms?
     
     
  • 2.39, лютый жабист__ (?), 18:23, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • –1 +/
    fix: не rdbms конечно, а dbms
     
     
  • 3.40, erthink (ok), 19:01, 14/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > fix: не rdbms конечно, а dbms

    Начиналось с другого, совсем.

    Просматривался вариант реализовать одну из подсистем с участием LDAP-сервера.
    Кроме этого, в "принципе не помешал-бы" некий работающий LDAP-blackbox.
    Протестировали производительнось, прошел только OpenLDAP.
    Проблемы всплыли много позже, и тогда меня позвали починить...

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

    Но если абстрагироваться от истории, то inmemory+wal конечно подходит.
    Но тогда Костин tarantool был ещё не так крут/готов, а главное - OpenLDAP работал в тестах и никто не ожидал "напильника" в два года.

     
     
  • 4.42, лютый жабист__ (?), 11:52, 15/08/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Есть полно промышленных решений особенно на почитаемой вами жабе которые не надо было ждать :D итого архитектора на мыло, трудозатраты не оценили путём, два года ваяли велосипед
     
     
  • 5.43, erthink (ok), 12:47, 15/08/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Есть полно промышленных решений особенно на почитаемой вами жабе которые не надо
    > было ждать :D итого архитектора на мыло, трудозатраты не оценили путём,
    > два года ваяли велосипед

    У вас есть неточность - на java НЕТ промышленных (и не промышленных) решений которые могут заменить или как-то конкурировать с ReOpenLDAP. Даже без репликации они уступают в 5-10 раз (точнее сказать сложно: разное железо, схемы, характер запросов и т.д.) при условии работы in-memory. А как только требуется фиксация на диске, то java неожиданно заносит и все тонет в IOPS.

    Далее, если разобраться, то все "промышленные решения на яве", на деле оказываются чуть менее чем XY-ней, примерно везде где нужна производительность (а не "кони в вакууме" или "фабрики фабрик для фабрик молотков"). А все исключения из этого наблюдения устойчиво попадают в шаблон: сверху на яве рисуются кнопочки и "IB-розочки", а снизу через JNI все делает C/C++.

    Причем на 20% в этом виновата сама Java, с "парой чемоданов батареек" в виде виртуальной машины, сборки мусора и т.п.
    И на 80% - экосистема, где здравый смысл принесен в жертву религии шарообразных абстракций, паттернов и некого стиля.

    Вот только уточню: в огромной массе других случаев java - отличный язык и технология, в том числе более дешевый.

     
     
  • 6.44, erthink (ok), 13:51, 15/08/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Чуть наброшу по теме Java.

    Все ошибаются, и нисколько я не исключение. Поэтому, если (вдруг) все-таки есть какие-то java-решения на замену ReOpenLDAP, то я вам советую/прошу предложить их в billing.ru. Может даже поучаствовать во внедрении.

    Жабу там беззаветно любят, если не ошибаюсь - уже лет 15.
    Однако, все-же есть риски что не примут (пошлют). Ибо уже года 3 (могу ошибаться) срывают сроки релизов из-за того, что "промышленные решения на java" работают чуть медленнее чем надо (а чертовы мегагерцы перестали расти).

    Причем, там же можно будет выяснить (лицом к лицу) актуальность общеизвестных и как-бы основных причин (руки из попы, люди-снежинки, танцорам что-то мешает) плохих java-показателей. Ну и показать "как надо".

    Короче, всячески рекомендую.

     
     
  • 7.45, лютый жабист__ (?), 09:04, 16/08/2017 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Ибо уже года 3 могу ошибаться срывают сроки релизов из-за того По личному оп... большой текст свёрнут, показать
     
     
  • 8.48, erthink (ok), 12:12, 16/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Я там ответил, но получилось в новой ветке видимо промазал по ссылке ... текст свёрнут, показать
     
  • 8.59, Аноним (-), 10:31, 17/08/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    В способности тру-жабистов нагрузить в полку все 100500 ядер системы даже обычны... текст свёрнут, показать
     

  • 1.46, erthink (ok), 11:56, 16/08/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > По личному опыту - в телекомах ЗП ровно вдвое ниже, чем у нормального бизнеса.

    Не заметил.

    > Соответственно, то что кто-то там сидит и три года за еду срывает сроки, ничего не доказывает.

    На самом деле платят и ищут профи.
    Просто предложите свои услуги, если не слабо:
    - https://hh.ru/vacancy/20985959
    - https://hh.ru/vacancy/20965714

    Мои компетенции можно по-обсуждать публично:
    - http://www.highload.ru/2017/abstracts/2837.html
    - http://www.highload.ru/2017/abstracts/2838.html
    - В Калуге на http://bit.ly/2w9xWTq
    - В Брюсселе на https://ldapcon.org/2017/

    Приходите. Welcome.

    На всякий, еще раз замечу:
    - Java отличный язык, особенно когда C/C++ не подходит (non reasonable) или их не осилили/загoвнoкодили.
    - разработка на Java всегда будет менее трудозатратной (дешевле) чем аналогичное C/C++.
    - правильно сделанная программа на Java всегда будет медленнее и прожорливее аналога на C/C++.

     
     
  • 2.47, erthink (ok), 12:09, 16/08/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Ох, судя по описанию java-вакансии в Петер-Сервисе еще не все пальцы отгорели от засовывания highload в розетки типа ElasticSearch и Cassandra :)

    И причины появления http://www.scylladb.com не вразумили, жаль.

     
  • 2.49, лютый жабист__ (?), 12:26, 16/08/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    > На самом деле платят и ищут профи.

    По вакансии не скажешь, что ищут профи. "Ожидания" уровня простого жабакодера. з/п не указана. Ещё и Питер.

    "правильно сделанная программа на Java всегда будет медленнее и прожорливее аналога на C/C++."

    Ты опять неправ. Про утилизацию железа уже писал. Из личных наблюдений сишные Постгрес, Монго, Оракле на например 12-ядернике дальше 1-2 ядер НИКОГДА не вылазят. Мои жабные поделки - легко, иногда даже без доп телодвижений (те же Collections из core многопоточны из коробки).

    Кстати, из общения с продуктами Positive Technologies. SIEM полный шлак по сравнению со ВСЕМИ рассмотренными конкурентами. Сканер сети шлак, а цена космос. Только менеджеры говорливые, обещают что "вот-вот всё станет круто". Так что предлагаю авторитетом не давить ;)

     
     
  • 3.50, erthink (ok), 13:10, 16/08/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Ну я уже понял что вы у нас коренной уникум из defaultcity и за еду в Питер не... большой текст свёрнут, показать
     
     
  • 4.51, лютый жабист__ (?), 14:42, 16/08/2017 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Какие кадры на hl встречаются, ржу не могу... Увы, си днище, потому что нормальные прогеры пишут сразу в машинных кодах. И субд и распределенные системы. А си ваше тормозит и глючит, особенно с -O3, знаем, плавали.
     
     
  • 5.54, erthink (ok), 17:05, 16/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    > Какие кадры на hl встречаются, ржу не могу... Увы, си днище, потому
    > что нормальные прогеры пишут сразу в машинных кодах. И субд и
    > распределенные системы. А си ваше тормозит и глючит, особенно с -O3,
    > знаем, плавали.

    Да, понимаю.
    Но вы держитесь, нас всех когда-нибудь вылечат ;)
    Короче, шанс еще есть, держитесь!

     
  • 5.58, bOOster (ok), 06:23, 17/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Гражданин, в твоем кривом мозгу не созрело что JAVA изначально тоже писана на C? И собирается с теми-же -O ключами?
    "де$илы, $ля" (с)
     
     
  • 6.61, лютый жабист__ (?), 11:48, 17/08/2017 [^] [^^] [^^^] [ответить]  
  • –2 +/
    >JAVA изначально тоже писана на C

    И посмотри сколько ДЫРИЩ в каждой версии. Жду не дождусь когда жабку перепишут на rust-е, а си и на этой задаче пойдёт в помойку ;)

     
     
  • 7.69, bOOster (ok), 21:09, 17/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Ну а rust видимо из "святым духом" программировался из сферического вакуума простанства и времени… (facepalm)
     
     
  • 8.87, лютый жабист__ (?), 16:36, 19/08/2017 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Такой сверхироничный ламер, просто диву даюсь Раст это компилятор, пусть его хо... текст свёрнут, показать
     
  • 4.56, Лис (?), 21:48, 16/08/2017 [^] [^^] [^^^] [ответить]  
  • –4 +/
    Я жабу не люблю, но насколько я знаю, за счёт вирт. машины можно делать runtime-оптимизации недоступные сишке и отчего жаба будет быстрее в определённых случаях.
    Так что про скорость света это может быть несколько ошибочно.
     
     
  • 5.57, erthink (ok), 23:32, 16/08/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Я жабу не люблю, но насколько я знаю, за счёт вирт. машины
    > можно делать runtime-оптимизации недоступные сишке и отчего жаба будет быстрее в
    > определённых случаях.
    > Так что про скорость света это может быть несколько ошибочно.

    JIT и интроспекция действительно позволяют делать некоторую оптимизацию, но вот кол-во случаев когда это получается и дает результат не так много:
    1. Всяческое "совсем" позднее связывание (включая подгрузку каких-то классов на ходу), что в случае java перетекает в следующий подпункт;
    2. Генерация кода самой программой;
    3. Если выясняется что какой-то метод вызывается очень часто, в том числе когда часть или все параметры зафиксированы;

    В C/C++ штатного JIT конечно нет, но при необходимости есть несколько вариантов (NativeJIT, LLVM, даже jithabr).

    Подпункты же 1 и 3 примерно не актуальны, т.е. дают выигрыш в экосистем java, а в C/C++ и без них нормально.

    Поэтому, в качестве итога = за счет упомянутых оптимизаций java может обогнать только плохой (плохо спроектированный или бездумный) код C/C++. Но в этом может быть и прелесть явы: можно упopото вить веревки из паттернов и абстракций, потом вжух и в продакшин, и оно будет работать (только медленнее C/C++).

     
  • 5.64, лютый жабист__ (?), 17:21, 17/08/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    >скорость света, скорость света, скорость света

    Гуру из Positive Technologies видимо не знает, что в теоретической физике уже лет 100 как вполне допускается передвижение быстрее С. ;) wormhole называется. Что самое смешное, аналогия вполне в тему - движение тушки в пространстве это цепочка си - ассемблер - машинные инструкции. Си тут ДАЛЕКО не "скорость света".

    А на мейнфреймах с Z/OS некоторые операции жабы исполняются сразу процом. Вполне себе такой wormhole. Си в пролёте... ;)

     
     
  • 6.65, Аноним (-), 17:55, 17/08/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Тоже слышал про сжатие пространства и отрицательную энергию.
    Но трицательный IQ вижу впервые, это прохая реклама для жабы.
     
  • 6.66, лютый жабист__ (?), 18:04, 17/08/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Кстати, ещё очевидный тезис, не раз его озвучивал. JVM проектируют и программят зубры, навроде Шипилева. А прожки пишут простые Васи-погромисты. Половина из них чуть лучше среднего, а половина так и хуже среднего. Только не надо блабла, что сишнике все сплошь с IQ 150++

    Поэтому равнять оптимизации Васи-погромиста и оптимизации Шипилёва - признак небольшого ума. Итого прога на жабе из под обычного прогера-жабиста может легко обогнать прогу на си обычного прогера-сишника. Шах и мат, братишки! Надоело очевидное рассказывать...

     
     
  • 7.68, erthink (ok), 20:36, 17/08/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Оставьте вы Леху в покое, его уже и так допекли разные грамотеи.

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

    К примеру, вот возьмите и реализуйте на java это = https://github.com/leo-yuriev/t1ha
    Некоторые "идиоты" (включая меня) утверждают, что это толком не возможно (будет в 4-6 раз медленнее) - покажите обратное.

    Если (вдруг) не получится, то можно сделать пользу = пробросить вызовы через "Critial Natives" = https://bugs.openjdk.java.net/browse/JDK-7013347
    Попробуйте сделать bench, посмотрите в v-tune и т.д.
    Море возможностей...

     
     
  • 8.70, bOOster (ok), 21:19, 17/08/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Знатно потролилил убогого Хотя это и реализуется, и почти без падения производ... текст свёрнут, показать
     
     
  • 9.72, erthink (ok), 21:27, 17/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Не, это было лишнее Удалил ... текст свёрнут, показать
     
  • 9.75, erthink (ok), 22:43, 17/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    В java нет uint64_t, поэтому умножение u64xu64- u128 придется делать через , ... текст свёрнут, показать
     
  • 8.80, лютый жабист__ (?), 05:17, 18/08/2017 [^] [^^] [^^^] [ответить]  
  • –5 +/
    The Future will Positive which are not uses specific hardware tricks это ты про ... текст свёрнут, показать
     
     
  • 9.81, Аноним (-), 12:32, 18/08/2017 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Ну так предложите автору исправления Посмейтесь вместе с носителем языка и пока... текст свёрнут, показать
     
     
  • 10.82, лютый жабист__ (?), 16:53, 18/08/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Если не заниматься тактодрчерством, а брать практические задачи, например FTSдви... текст свёрнут, показать
     
     
  • 11.84, erthink (ok), 21:50, 18/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Все практические задачи состоят из простых действий, каждое из которых корректне... большой текст свёрнут, показать
     
     
  • 12.85, лютый жабист__ (?), 06:02, 19/08/2017 [^] [^^] [^^^] [ответить]  
  • –3 +/
    Ты наверное из далекого будущего пишешь, ScyllaDb появилось на 10 лет позже Каси... текст свёрнут, показать
     
  • 11.91, Michael Shigorin (ok), 19:44, 22/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    то мне на той неделе одни люди говорили о том, как собираются жабу менять на ... текст свёрнут, показать
     
  • 7.78, Led (ok), 00:01, 18/08/2017 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > JVM проектируют и программят зубры,

    Зубры, мкаки, хомячки и прочие насекомые - много вас таких.

     
  • 7.86, Павленскй (?), 10:39, 19/08/2017 [^] [^^] [^^^] [ответить]  
  • +3 +/
    Хм, ява вместо брусчатки. Коллега что-ли?
     

  • 1.67, erthink (ok), 18:40, 17/08/2017 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    RTFM.

    Запросы поиска/чтения в ReOpenLDAP и libmdbx масштабируются линейно по ядрам CPU.

     
     
  • 2.74, Лис (?), 22:20, 17/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо за интересный проект.
    Такой вопрос.
    Хочу использовать libmdbx как хранилище в golang, я нашёл биндинг к LMDB https://github.com/bmatsuo/lmdb-go но наверное для libmdbx его нужно адаптировать, если да то насколько сильно?
    До этого думал использовать boltdb (для реалтайм хранилища/горячего кэша), но судя по описанию в биндинге даже стандартный LMDB в сочетании с го дают большую скорость чем родной болт.
     
     
  • 3.76, erthink (ok), 23:12, 17/08/2017 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Спасибо за интересный проект.
    > Такой вопрос.
    > Хочу использовать libmdbx как хранилище в golang, я нашёл биндинг к LMDB
    > https://github.com/bmatsuo/lmdb-go но наверное для libmdbx его нужно адаптировать, если
    > да то насколько сильно?
    > До этого думал использовать boltdb (для реалтайм хранилища/горячего кэша), но судя по
    > описанию в биндинге даже стандартный LMDB в сочетании с го дают
    > большую скорость чем родной болт.

    Да, нужно адаптировать.
    Но думаю изменения будут небольшие и в основном механические.

    Однако, вынужден предупредить - формат БД и API в master и devel еще не зафиксированы.
    Революций в API не будет, но какие-то доработки в байндингах точно потребуются.
    А формат БД и внутренности будут меняться достаточно серьезно.

    Старую стабильную версию из stable/0.0 использовать не рекомендую. В свое время (для МегаФона) одним из требований была совместимость по формату БД. Поэтому многие принципиальные фичи были невозможны.

    Дополню: Совместимость текстового формата dump/restore будет поддерживаться, в том числе с LMDB (если вдруг это не так - то это баг).

     
     
  • 4.79, Лис (?), 00:30, 18/08/2017 [^] [^^] [^^^] [ответить]  
  • +/
    Спасибо за ответ.
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру