The OpenNET Project / Index page

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



"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9.2"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9.2"  +/
Сообщение от opennews (??), 27-Ноя-20, 14:00 
После двух месяцев разработки состоялся выпуск библиотеки libmdbx 0.9.2 (MDBX) с реализацией высокопроизводительной, компактной встраиваемой базы данных класса ключ-значение. Код libmdbx распространяется под лицензией OpenLDAP Public License. libmdbx является глубокой переработкой СУБД LMDB и по заявлению разработчиков превосходит своего прародителя по надежности, набору возможностей и производительности...

Подробнее: https://www.opennet.me/opennews/art.shtml?num=54153

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по времени | RSS]


1. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от Аноним (1), 27-Ноя-20, 14:00 
И как оно, стоит использовать?
Ответить | Правка | Наверх | Cообщить модератору

38. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –2 +/
Сообщение от trdm (ok), 28-Ноя-20, 00:08 
Вот всегда думал как же эту фигню используют?
пример использования можно?
Ответить | Правка | Наверх | Cообщить модератору

52. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +2 +/
Сообщение от abu (?), 28-Ноя-20, 15:19 
Как пишут, ноги растут из СУБД LMDB. А она используется, насколько помню, в OpenLDAP, например. Выбираешь в конфиге, как хранить данные, выбираешь lmdb, собственно - начинает хранить. А в OpenLDAP уж ключей-значений, по очевидным причинам, просто завались.  
Ответить | Правка | Наверх | Cообщить модератору

63. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –1 +/
Сообщение от Аноним (63), 28-Ноя-20, 19:21 
Не следует. Используя эту базу вы продвигаете её (в результате чего она может получить больше вклада от сторонних людей, после чего она может быть использована в системе записи передаваемой по сети информации для закона Яровой под авторством того же Юрьева) и карьеру её автора, вместо того, чтобы помочь ей загнуться, продвигая её конкурентов, авторы которых не заискивают, демонстрируя лояльность через надписи вроде

>Please don't use my work, if you are associated with Adolf Hitler, Stepan Bandera, George Soros, Michael Hodorkovsky, either support an actions of these felons.

и установку на аватару изображения рядового военнослужащего (даже если он и действительно служил на флоте, гордиться тут тут совершенно нечем), развёрнутого задом (что демонстрирует отношение к наблюдающим эту аватару).

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

64. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +1 +/
Сообщение от erthink (ok), 28-Ноя-20, 19:24 
Лечитесь, еще есть шансы.
Ответить | Правка | Наверх | Cообщить модератору

79. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +2 +/
Сообщение от Страшный аноним (?), 29-Ноя-20, 13:22 
Походу это - неоперабельный случай.
Вы заметили как это либероидного ананима бомбануло от осуждения гитлера и бандеры? Как черта от православного креста.
Зачем-то приплел закон Яровой, забыв упомянуть про тотальный контроль и прослушку америкнанской АНБ, Сноудена, Асанжа и других политзаключенных так называемого "Запада".
Хотя... это же "демократы", они фиалками какают и все делают для демократии, даже бомбят свадьбы в Афганистане и Ираке исключительно демократическими гуманными бомбами - у них там в соросовских методичках именно так и написано.
Ответить | Правка | Наверх | Cообщить модератору

83. "(offtopic) о лицемерии или некомпетентности"  +/
Сообщение от Michael Shigorinemail (ok), 30-Ноя-20, 10:55 
> Зачем-то приплел закон Яровой

Вишенка на торте: Яровая-то в политику пришла через "Яблоко".  Так что когда начинают вопить -- так и стоит возражать: "но это же ваша баба!" :]

Ответить | Правка | Наверх | Cообщить модератору

90. "(offtopic) о лицемерии или некомпетентности"  +/
Сообщение от Аноним (90), 02-Дек-20, 00:46 
Не надо софистики, она в сторону проживавших какое-то время в/на Украине тоже работает с равно абсурдными результатами. Тут более с Пеньковским сравнение уместно.
Ответить | Правка | Наверх | Cообщить модератору

101. "(offtopic) о лицемерии или некомпетентности"  +/
Сообщение от Аноним (-), 03-Дек-20, 09:53 
> Вишенка на торте: Яровая-то в политику пришла через "Яблоко".  Так что
> когда начинают вопить -- так и стоит возражать: "но это же ваша баба!" :]

Это баба-хамелеон: перекрашивается в тот цвет который в данный момент наиболее выгоден. И конечно она ничья - хапает с кормушки себе.

Ответить | Правка | К родителю #83 | Наверх | Cообщить модератору

100. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от Аноним (-), 03-Дек-20, 09:44 
> Вы заметили как это либероидного ананима бомбануло от осуждения гитлера и бандеры?
> Как черта от православного креста.

Тут проблема в том что это некое дополнительное ограничение, при том указанное где-то сбоку, при отсылке к типовой лицензии на видном месте. К тому же мало ли что еще завтра автор напишет. Может ему цвет кожи не понравится, или там разрез глаз. Зря он это, политоту в софт тащит. Можно подумать, сторонники перечисленных базу key-value себе не найдут.

Ответить | Правка | К родителю #79 | Наверх | Cообщить модератору

92. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –4 +/
Сообщение от Аноним (92), 02-Дек-20, 21:56 
Судя по твоему bio на жидхабе тебе самому надо лечиться
Ответить | Правка | К родителю #64 | Наверх | Cообщить модератору

2. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –5 +/
Сообщение от Lex (??), 27-Ноя-20, 14:06 
Чем оно лучше/хуже в сравнении с той же SQLite ?
Ответить | Правка | Наверх | Cообщить модератору

4. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +12 +/
Сообщение от llolik (ok), 27-Ноя-20, 14:12 
Сравнивать key-value с реляционной БД - ну такое себе сравнение, как тёплое и квадратное, примерно.
Ответить | Правка | Наверх | Cообщить модератору

5. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –1 +/
Сообщение от Аноним (5), 27-Ноя-20, 14:16 
тогда чем оно лучше BerkleyDB?
Ответить | Правка | Наверх | Cообщить модератору

9. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +6 +/
Сообщение от erthink (ok), 27-Ноя-20, 14:57 
- Быстрее.
- Нет deadlock-ов и других глюков.
- Меньше "серебряных пуль" типа как-бы репликации и т.п.
- Лицензия.

Остальное знают Яндекс и Google.

Ответить | Правка | Наверх | Cообщить модератору

31. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –7 +/
Сообщение от Аноним (31), 27-Ноя-20, 19:17 
> Остальное знают Яндекс и Google.

Взоржал

Ответить | Правка | Наверх | Cообщить модератору

34. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +2 +/
Сообщение от erthink (ok), 27-Ноя-20, 19:26 
>> Остальное знают Яндекс и Google.
> Взоржал

Очередной эксперт с LOR'а по BerkeleyDB или Rust?

Ответить | Правка | Наверх | Cообщить модератору

36. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –5 +/
Сообщение от anonxxx (?), 27-Ноя-20, 21:21 
Я не понимаю людей, использующих твои наработки и прочитавшие описание твоего профиля на github.
Ответить | Правка | Наверх | Cообщить модератору

39. Скрыто модератором  +/
Сообщение от CrazyAlex (?), 28-Ноя-20, 01:23 
Ответить | Правка | Наверх | Cообщить модератору

40. Скрыто модератором  +/
Сообщение от fske (?), 28-Ноя-20, 03:35 
Ответить | Правка | Наверх | Cообщить модератору
Часть нити удалена модератором

45. Скрыто модератором  +3 +/
Сообщение от erthink (ok), 28-Ноя-20, 13:03 
Ответить | Правка | Наверх | Cообщить модератору

47. Скрыто модератором  +1 +/
Сообщение от erthink (ok), 28-Ноя-20, 13:13 
Ответить | Правка | Наверх | Cообщить модератору

49. Скрыто модератором  +2 +/
Сообщение от fske (?), 28-Ноя-20, 14:32 
Ответить | Правка | Наверх | Cообщить модератору

55. Скрыто модератором  +1 +/
Сообщение от fske (?), 28-Ноя-20, 16:58 
Ответить | Правка | Наверх | Cообщить модератору

56. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +2 +/
Сообщение от мяя (?), 28-Ноя-20, 17:26 
Политота действительно портит впечатление (сама по себе). Лучше её убрать так как мешает распространению хорошего продукта.
Ответить | Правка | К родителю #36 | Наверх | Cообщить модератору

58. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –3 +/
Сообщение от Michael Shigorinemail (ok), 28-Ноя-20, 18:29 
Это фильтр, очевидно.
Ответить | Правка | Наверх | Cообщить модератору

99. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +1 +/
Сообщение от Вы забыли заполнить поле Name (?), 03-Дек-20, 01:14 
> Это фильтр, очевидно.

Может вы еще спрашиваете предпочтения в сексе при приеме на работу?

Ответить | Правка | Наверх | Cообщить модератору

65. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –1 +/
Сообщение от Аноним (63), 28-Ноя-20, 20:42 
Не, наоборот оставить. Как заходишь в профиль - так сразу желание оказывать позитивное влияние на его карьеру пропадает. И не надо говорить, что влияние равно нулю - если бы влияние было 0, то на GH это никто бы не выкладывал. На гитхаб выкладывают то, к чему нужно привлечь народ со стороны, чтобы потом заслуженно заявлять "а я автор либы/программы, от которой зависят тысячи программ и которой пользуются миллионы человек".
Ответить | Правка | К родителю #56 | Наверх | Cообщить модератору

93. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от Аноним (92), 02-Дек-20, 22:03 
> Меньше "серебряных пуль" типа как-бы репликации и т.п.

Что это означает? В libmdbx нет же репликации.

Ответить | Правка | К родителю #9 | Наверх | Cообщить модератору

98. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –1 +/
Сообщение от erthink (ok), 02-Дек-20, 22:20 
>> Меньше "серебряных пуль" типа как-бы репликации и т.п.
> Что это означает? В libmdbx нет же репликации.

https://habr.com/ru/post/459862/#comment_20414205

Ответить | Правка | Наверх | Cообщить модератору

10. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от Аноним (10), 27-Ноя-20, 15:00 
Не стоит забывать о кейсах где эта недореляционная БД именно как kv и используется.
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

11. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +3 +/
Сообщение от пох. (?), 27-Ноя-20, 15:00 
Ну же, жду ваших откровений, хперты - что может помешать мне хранить key-value в sqlite?

То есть если бы вас спрашивали наоборот - чем оно хуже sqlite - ответ был бы именно "тем что умеет только key-value".
Но вас спрашивают - чем лучше? Сочнее, мжвячнее, нажористее?

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

17. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +4 +/
Сообщение от erthink (ok), 27-Ноя-20, 15:06 
Дублирую, см. https://www.opennet.me/openforum/vsluhforumID3/121987.html#9
Ответить | Правка | Наверх | Cообщить модератору

20. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +1 +/
Сообщение от пох. (?), 27-Ноя-20, 15:23 
Ну вот, распугал всю еду!

(там, правда, осталось неопределенным, насколько реальные use pattern похожи на эти тесты)

Ответить | Правка | Наверх | Cообщить модератору

18. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –1 +/
Сообщение от Lex (??), 27-Ноя-20, 15:15 
Кнчн. не шибко корректно, но..
Обе они решают задачу хранения данных, обе - вроде бы годятся во встройщину..
Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

94. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –1 +/
Сообщение от Аноним (92), 02-Дек-20, 22:05 
Вообще у тех же leveldb и rocksdb есть сравнение производительности с sqlite. Ну возьми да положи байты в sqlite по ключу да сравни произодительность. В чем проблема?

Да и как бы вот https://www.sqlite.org/src4/doc/trunk/www/index.wiki на почитать

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

96. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –1 +/
Сообщение от erthink (ok), 02-Дек-20, 22:15 
> Вообще у тех же leveldb и rocksdb есть сравнение производительности с sqlite.
> Ну возьми да положи байты в sqlite по ключу да сравни
> произодительность. В чем проблема?

В том что кто-то не умеет читать:
1) https://www.opennet.me/openforum/vsluhforumID3/121987.html#9
2) https://github.com/erthink/libmdbx#performance-comparison


> Да и как бы вот https://www.sqlite.org/src4/doc/trunk/www/index.wiki на почитать

Вот пожалуйста и ознакомтесь.

Ответить | Правка | Наверх | Cообщить модератору

97. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от Аноним 222222 (?), 02-Дек-20, 22:16 
Вообще у тех же leveldb и rocksdb есть сравнение производительности с sqlite. Ну возьми да положи байты в sqlite по ключу да сравни произодительность. В чем проблема?

Да и как бы вот https://www.sqlite.org/src4/doc/trunk/www/index.wiki на почитать

Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

6. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от Moomintroll (ok), 27-Ноя-20, 14:20 
> Чем оно лучше/хуже в сравнении с той же SQLite ?

Несравнимо:

> класса ключ-значение

https://ru.wikipedia.org/wiki/База_данных_«ключ-значение»

vs

https://ru.wikipedia.org/wiki/Реляционная_база_данных

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

14. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от Аноним (10), 27-Ноя-20, 15:02 
База данных и база данных сравнимы замечательно.
Ответить | Правка | Наверх | Cообщить модератору

19. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –1 +/
Сообщение от Lex (??), 27-Ноя-20, 15:21 
хранение данных vs хранение данных
возможно во встраиваемых решениях vs возможно во встраиваемых решениях

О да, разница очевидна и невероятно принципиальна

п.с: вы, когда думаете, положить ли что-то в пакет( ссылка вики на ПАКЕТ ) или в коробку( ссылка вики на КОРОБКА ) тоже называете их "несравнимыми", ведь одно из них, скорее всего, из полиэтилена, а другое - из картона ?

Ответить | Правка | К родителю #6 | Наверх | Cообщить модератору

37. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –1 +/
Сообщение от kai3341 (ok), 27-Ноя-20, 22:59 
Принципиально различаются режимы работы. Когда подрастёшь, расскажу, чем отличаются Oracle от MySQL (+MariaDB) от MSSQL и от PostgreSQL, хотя все они реляционные БД.

Hint: сильно разные структуры данных, со своими преимуществами и болячками

Ответить | Правка | Наверх | Cообщить модератору

80. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –1 +/
Сообщение от Lex (??), 29-Ноя-20, 15:35 
>> Чем оно лучше/хуже в сравнении с той же SQLite ?
> Когда подрастёшь, расскажу, чем отличаются Oracle от MySQL (+MariaDB) от MSSQL и от PostgreSQL, хотя все они реляционные БД

И ведь плевать, что изначальный вопрос был совсем не о том и твои "рассказы" нафиг не нужны, не так ли ?

Ответить | Правка | Наверх | Cообщить модератору

16. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +2 +/
Сообщение от erthink (ok), 27-Ноя-20, 15:05 
Как-то уже обсуждали, см. ветку https://www.opennet.me/openforum/vsluhforumID3/121987.html#9
Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

3. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +1 +/
Сообщение от InuYasha (??), 27-Ноя-20, 14:10 
Надо будет поподробней узнать, что за ключи-значения туда влазят. А то вдруг годнота...
Ответить | Правка | Наверх | Cообщить модератору

12. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +2 +/
Сообщение от erthink (ok), 27-Ноя-20, 15:01 
Есть конкретные цифры: https://github.com/erthink/libmdbx#limitations

Если кратко, то:
- поддерживаются ключи больше чем в LMDB, он меньше чем в SQLite.
- иначе говоря. не поддерживаются длинные ключи, которые приводят к деградации производительности b+tree.

Ответить | Правка | Наверх | Cообщить модератору

7. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от Ivan_83 (ok), 27-Ноя-20, 14:22 
Во, походу это я был тот единственный страдалец из Miranda NG у кого свежая миранда с этой БД под вайном не работала.
Ответить | Правка | Наверх | Cообщить модератору

15. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +1 +/
Сообщение от erthink (ok), 27-Ноя-20, 15:03 
Там всё равно хватает проблем, см. https://github.com/miranda-ng/miranda-ng/issues/1209#issueco...
Ответить | Правка | Наверх | Cообщить модератору

8. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +2 +/
Сообщение от Аноним (8), 27-Ноя-20, 14:51 
Чем оно лучше оригинальной lmdb
Ответить | Правка | Наверх | Cообщить модератору

13. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +3 +/
Сообщение от erthink (ok), 27-Ноя-20, 15:01 
Есть конкретный список: https://github.com/erthink/libmdbx#improvements-beyond-lmdb
Ответить | Правка | Наверх | Cообщить модератору

24. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от Аноним (24), 27-Ноя-20, 16:16 
Чем lmdb, же.
Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

21. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –2 +/
Сообщение от Аноним (21), 27-Ноя-20, 15:26 
А почему у неё такое странное название?
Ответить | Правка | Наверх | Cообщить модератору

22. Скрыто модератором  –1 +/
Сообщение от mos87 (ok), 27-Ноя-20, 15:53 
Ответить | Правка | Наверх | Cообщить модератору

23. Скрыто модератором  –1 +/
Сообщение от Аноним (21), 27-Ноя-20, 16:08 
Ответить | Правка | Наверх | Cообщить модератору

25. Скрыто модератором  +/
Сообщение от mos87 (ok), 27-Ноя-20, 16:52 
Ответить | Правка | Наверх | Cообщить модератору

26. Скрыто модератором  +1 +/
Сообщение от Аноним (26), 27-Ноя-20, 16:58 
Ответить | Правка | К родителю #23 | Наверх | Cообщить модератору

35. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от Капитан Очевидность (?), 27-Ноя-20, 21:15 
LMDB eXtended.
Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

27. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –3 +/
Сообщение от Аноним (27), 27-Ноя-20, 17:07 
Windows 2000/XP (для Miranda NG). - кто то еще этим пользуется?

Наверно это та группа которая ненавидит Electron ?

Ответить | Правка | Наверх | Cообщить модератору

28. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +6 +/
Сообщение от Аноним (28), 27-Ноя-20, 17:56 
>Наверно это та группа которая ненавидит Electron ?

Как будто что-то плохое.

Ответить | Правка | Наверх | Cообщить модератору

33. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от VladSh (?), 27-Ноя-20, 19:24 
Что 'группа' или что 'ненавидит'?
Ответить | Правка | Наверх | Cообщить модератору

41. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +3 +/
Сообщение от fske (?), 28-Ноя-20, 03:40 
Да.
Ответить | Правка | Наверх | Cообщить модератору

102. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от Аноним (-), 03-Дек-20, 13:30 
> Наверно это та группа которая ненавидит Electron ?

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

Ответить | Правка | К родителю #27 | Наверх | Cообщить модератору

50. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +2 +/
Сообщение от Аноним (50), 28-Ноя-20, 14:33 
Positive Technologies... хм... рука москвы?
Ответить | Правка | Наверх | Cообщить модератору

73. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +1 +/
Сообщение от erthink (ok), 29-Ноя-20, 07:53 
И голова, и деньги...
Вообще всё в Москве происходит!
Ответить | Правка | Наверх | Cообщить модератору

84. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +2 +/
Сообщение от InuYasha (??), 30-Ноя-20, 12:48 
Давай, как-нить понаеду, произойдём по Красной площади :)
Ответить | Правка | Наверх | Cообщить модератору

86. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от Michael Shigorinemail (ok), 30-Ноя-20, 13:05 
Лёнь, маякни ;-)  Глядишь, мини-опеннетовку учиним.
Ответить | Правка | Наверх | Cообщить модератору

88. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +1 +/
Сообщение от InuYasha (??), 30-Ноя-20, 14:08 
Замётано )
Ответить | Правка | Наверх | Cообщить модератору

51. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от Аноним (51), 28-Ноя-20, 15:08 
Рассматривал сабж для локального, перзистентого хранилища для веб-приложения (настройки, ключи, очередь задач - все что хотелось бы рядом держать) которое юзает нормальную постгрю для всего нелокального - хотелось ACID.
Но остановился на sqlite c денормализованной схемой, ибо не нашел под сабж аналога sqlite browser чтобы в случае чего отладить у заказчика.
Может плохо искал?
Ответить | Правка | Наверх | Cообщить модератору

53. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +1 +/
Сообщение от erthink (ok), 28-Ноя-20, 16:13 
Есть намерение делать драйвер для FastnoSQL, но всё никак руки не дойдут.

https://github.com/erthink/libmdbx/issues/9

Ответить | Правка | Наверх | Cообщить модератору

70. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от Аноним (63), 29-Ноя-20, 00:37 
>sqlite browser

А почему не DBeaver?

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

71. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +1 +/
Сообщение от Имя (?), 29-Ноя-20, 01:50 
Как пример, речь о том что разных инструментов для "зайти и посмотреть" гораздо больше, тяжеловесные клиенты не нужны для моей задачи, оверкилл.
Ответить | Правка | Наверх | Cообщить модератору

74. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от erthink (ok), 29-Ноя-20, 08:07 
На всякий, для информации.

Попробовал еще раз локально собрать FastNoSQL из исходников, чтобы затем добавить поддержку libmdbx. Не выходит.

В моём понимании там какая-то адова смесь кривых/неумелых сценариев CMake и дополнительных костылей на питоне.

--

Вроде-бы собрать FastNoSQL получилось у Виталия Липатова из ALT (http://sisyphus.ru/ru/srpm/Sisyphus/fastonosql/spec).
Но мне эти заклинания не помогли.

Вполне вероятно что я стар, туп, не шарю "как собирать" питоном и т.д и т.п.
Но меня разочаровывают CMake-сценарии в FastNoSQL, а питоновские костыли тошнотворят.
WTF > 50%.

Поэтому, помогу если кто-то возьмется, но сам делать не буду пока сборка FastNoSQL не станет вменяемой.

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

77. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от erthink (ok), 29-Ноя-20, 09:30 
>[оверквотинг удален]
> костылей на питоне.
> --
> Вроде-бы собрать FastNoSQL получилось у Виталия Липатова из ALT (http://sisyphus.ru/ru/srpm/Sisyphus/fastonosql/spec).
> Но мне эти заклинания не помогли.
> Вполне вероятно что я стар, туп, не шарю "как собирать" питоном и
> т.д и т.п.
> Но меня разочаровывают CMake-сценарии в FastNoSQL, а питоновские костыли тошнотворят.
> WTF > 50%.
> Поэтому, помогу если кто-то возьмется, но сам делать не буду пока сборка
> FastNoSQL не станет вменяемой.

Автор FastNoSQL обиделся на сформулированное выше и закрыл дальнейшее обсуждение на github.
https://github.com/fastogt/fastonosql/issues/36
Буквально:

> Некрасиво разговариваете чтоб вам отвечать.

Тем не менее, открыто говоря, сборочные скрипты FastNoSQL плохи и многократно демонстрируют как (локальную) техническую безграмотность (т.е. незнание как лучше/правильно), так и нежелание наводить что-либо приводить порядок (т.е. лень).

Так понятнее?

Ответить | Правка | Наверх | Cообщить модератору

81. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +1 +/
Сообщение от Аноним (81), 29-Ноя-20, 20:06 
братюнь, вполне возможно, что скрипты плохи, но это не повод нападать на автора скриптов. автор делает такое же спо как и ты, и делает это так как считает нужным, что возможно не всегда соответствует твоим представлениям о том, что хорошо и что плохо. со стороны это выглядит не красиво, я считаю, что ты не прав. бытиё неприятным человеком не приблизит тебя к твоей цели. подумай об этом.
Ответить | Правка | Наверх | Cообщить модератору

82. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от Michael Shigorinemail (ok), 30-Ноя-20, 10:49 
Знаете, если мне говорят, что я криворукий (я, а не код плох) -- я весь такой могу возмутиться, но если говорят по существу, то отмазываться "чуйствительностью" или там кричать "жизни криворуких важны, а ты, пряморукая скотина, даже патч не прислал на полпроекта!" -- ну вот вообще никак _мне_ не поможет.

"Извини, это [был] мой уровень и в этом направлении развиваться не планирую; если хочешь, покажи класс" -- и то честней.

Так что смотря какие цели у кого.  "Платон мне друг, но истина дороже" -- не вчера уж было сказано.

Ответить | Правка | Наверх | Cообщить модератору

85. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +2 +/
Сообщение от Аноним (85), 30-Ноя-20, 13:01 
не стоит оправдывать скандальность высокими материями. надо было сначала разобраться и вообще туда не лезть если нет желания с этим связываться. скрипты приходят и уходят, завтра их перепишут, а испорченные отношения останутся.
Ответить | Правка | Наверх | Cообщить модератору

87. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +2 +/
Сообщение от llolik (ok), 30-Ноя-20, 13:40 
> не стоит оправдывать скандальность

Не буду оценивать скандальность, но, справедливости ради, сборка там реально сташный и странный трындец.

Ответить | Правка | Наверх | Cообщить модератору

89. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +1 +/
Сообщение от Аноним (85), 01-Дек-20, 00:57 
вполне возможно, я сам не смотрел и не собираюсь. просто говорю как это выглядит со стороны. пытаюсь помочь. ему кстати ответили вполне корректно и тоже довольно прямо, не утаивая истину.
Ответить | Правка | Наверх | Cообщить модератору

78. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +1 +/
Сообщение от erthink (ok), 29-Ноя-20, 09:57 
Nonetheless, anything that is bullshit must be noted as a bullshit, including a lot of libmdbx internals inherited from LMDB.

https://github.com/erthink/libmdbx/issues/9#issuecomment-735...

Rrds.

Ответить | Правка | К родителю #74 | Наверх | Cообщить модератору

57. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от мяя (?), 28-Ноя-20, 17:36 
>  Продолжено совершенствование online документации.

Не хватает простых примеров использования.
Подобного этому https://github.com/erthink/libmdbx/blob/master/example/examp...
Где бы были все стандартные операции — добавление, изменение, удаление, поиск по ключу, значению.

Ответить | Правка | Наверх | Cообщить модератору

62. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от erthink (ok), 28-Ноя-20, 18:52 
С радостью приму PR, особенно с примером для нового С++ API.
Ответить | Правка | Наверх | Cообщить модератору

59. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от Michael Shigorinemail (ok), 28-Ноя-20, 18:46 
> make -j8 all test

...
> && echo '#define MDBX_BUILD_TARGET "E2K"' \

...
> No error is detected, elapsed 0.007 seconds

;-)

Ответить | Правка | Наверх | Cообщить модератору

60. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от erthink (ok), 28-Ноя-20, 18:48 
>> make -j8 all test
> ...
>> && echo '#define MDBX_BUILD_TARGET "E2K"' \
> ...
>> No error is detected, elapsed 0.007 seconds
> ;-)

Ну это обязательно, и на всех версиях что дотянулся.

Ответить | Правка | Наверх | Cообщить модератору

75. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от erthink (ok), 29-Ноя-20, 08:34 
>>> make -j8 all test
>> ...
>>> && echo '#define MDBX_BUILD_TARGET "E2K"' \
>> ...
>>> No error is detected, elapsed 0.007 seconds
>> ;-)
> Ну это обязательно, и на всех версиях что дотянулся.

@maxim.chirkov, тут движок форума "детектировал атаку", попросил уведомить, но всё-таки разместил ответ.

Ответить | Правка | Наверх | Cообщить модератору

61. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от erthink (ok), 28-Ноя-20, 18:49 
>> echo '#define MDBX_BUILD_TARGET "E2K"'
>> No error is detected, elapsed 0.007 seconds
> ;-)

Ну это обязательно, и на всех версиях что дотянулся.

Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

66. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от временный_аноним (?), 28-Ноя-20, 21:55 
Ну вот почему mdbx.c++, а не mdbx.cpp?
Ответить | Правка | Наверх | Cообщить модератору

76. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от erthink (ok), 29-Ноя-20, 09:00 
Хм, а "почему c++, а не сpp?" и "/usr/bin/c++, а не /usr/bin/cpp?" и т.д.
Ответить | Правка | Наверх | Cообщить модератору

91. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +1 +/
Сообщение от Аноним (92), 02-Дек-20, 21:54 
Чем лучше RocksDB?
Ответить | Правка | Наверх | Cообщить модератору

95. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –1 +/
Сообщение от erthink (ok), 02-Дек-20, 22:11 
> Чем лучше RocksDB?

RTFM = https://github.com/erthink/libmdbx#comparison-with-other-dat...

Ответить | Правка | Наверх | Cообщить модератору

103. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –3 +/
Сообщение от Аноним (-), 03-Дек-20, 13:38 
А где там вообще хоть какое-то сравнение чего-то? И где хотя-бы токийский кабинет, чтоли? Кстати для тех кто на C++ хотел - они тоже уже переписали. И даже сервер сделали.
Ответить | Правка | Наверх | Cообщить модератору

104. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –2 +/
Сообщение от Вы забыли заполнить поле Name (?), 03-Дек-20, 15:22 
Да какой смысл искать в этих графиках смысл? Еще и ссылка на самописную тулзу для сравнения. Все эти сравнения всегда затачиваются под себя от нежелания/неумения настроить другие реализации в тесте.

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

Ответить | Правка | Наверх | Cообщить модератору

105. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –1 +/
Сообщение от Вы забыли заполнить поле Name (?), 03-Дек-20, 15:25 
Даже не удосужился к себе текст скопипастить. Молоде чо. Надеюсь следишь за актуальностью.

Ой, а как же ты даешь ссылку на либо на go, которую разрабатывает страна не признающая Крым частью России.

Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору
Часть нити удалена модератором

112. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от Lefsha (ok), 06-Янв-21, 01:43 
Привет каким образом собрать ReOpenLDAP, чтобы осталась совместимость с последней версией OpenLDAP?

Не работает никакой вариант с nss-pam-ldapd:

In file included from pagectrl.c:35:
../compat/ldap_compat.h:49:5: error: conflicting types for 'ldap_parse_page_control'
   49 | int ldap_parse_page_control(LDAP *ld, LDAPControl **ctrls,
      |     ^~~~~~~~~~~~~~~~~~~~~~~
In file included from pagectrl.c:33:
/usr/include/ldap.h:1731:1: note: previous declaration of 'ldap_parse_page_control' was here
1731 | ldap_parse_page_control(LDAP *ld, LDAPControl **ctrls, ber_int_t *count,
      | ^~~~~~~~~~~~~~~~~~~~~~~

Проблема очевидно в том, что nss-pam-ldapd хочет unisgned long для count,
а ReOpenLDAP предлагает ber_int_t, который int32

Очевидно, что со стандартной библиотекой все работает.


Отсутствует libldap.so который нужен другим библиотекам или программам.
Например php.


Или поставлю вопрос по другому - какая последняя версия обеспечивает совместимость
с OpenLDAP?

Ответить | Правка | К родителю #82 | Наверх | Cообщить модератору

113. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +1 +/
Сообщение от Сам Lefsha (?), 06-Янв-21, 04:00 
Может лучше issue на гитхабе оформить, ну или сразу писать в спортлото?
Ответить | Правка | Наверх | Cообщить модератору

114. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –1 +/
Сообщение от Lefsha (ok), 06-Янв-21, 10:25 
Не думаю, что есть смысл. Автор изменил все что мог изменить.
Тем самым сделал программу не совместимой ни с чем.

Это не ошибка о которой можно рапортовать.

Зачем автор это сделал - загадка. Наверно, чтобы никто не использовал.

Ответить | Правка | Наверх | Cообщить модератору

115. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +2 +/
Сообщение от erthink (ok), 06-Янв-21, 14:20 
Исторически в оригинальном OpenLDAP есть ldap-библиотека, которая предназначена для ldap-клиентов, но при этом также используется внутри самого сервера. Кроме этого, есть еще одна библиотека для серверной части и серверных ldap-утилит.

В ReOpenLDAP эти две библиотеки были объединены, так как это именно сервер, а предоставление клиентских ldap-библиотек и/или обеспечение совместимости не планировалось, и никогда не входило в цели. Такое объединение позволило устранить избыточность кода, что-то выбросить, что-то починить, переделать и т.д.

Кроме внесения изменений и слияния библиотека также была переименована, что исключает какие-либо конфликты с традиционными библиотеками от OpenLDAP.

---

Отказ от предоставления клиентской ldap-библиотеки в ReOpenLDAP более чем оправдан - грубо говоря там ад, с массой сторонних эффектов и глюков. Код не только очень плохой и не прозрачный, но и небрежно написанный. При починке серверной части многое пришлось резать и переделывать. При этом обеспечить совместимость было крайне сложно (скорее невозможно с учетом side effects), и тем более невозможно было протестировать. С другой стороны, я чинил именно сервер, т.е. не было цели чинить или переписывать клиентскую ldap-библиотеку больше чем нужно для устойчивой работы сервера.

Например, ReOpenLDAP можно собрать с включением hipagut (встроенный чекер памяти), при этом любой клиентский код вместо malloc/free должен использовать hipagut-функции для блоков памяти передаваемых или получаемых от ldap-библиотеки, что невозможно в случае стороннего код использующего библиотеку.

Поэтому никакой совместимости с OpenLDAP быть не может.

---

Что касательно вашей проблемы при сборке - НЕОБХОДИМО и достаточно обеспечить использование правильных include-путей при сборке какого-либо кода использующего ldap:

1. Всё что работает на стороне сервера ReOpenLDAP нужно собирать с заголовочными файлами и библиотеками ReOpenLDAP. Это обеспечивается (проверялось при разработке) при сборке ldap-модулей/плагинов внутри ReOpenLDAP. Поэтому, если вам нужно собрать какой-то сторонний модуль, то (видимо) проще всего добавить его в ReOpenLDAP. Так или иначе, самое главное - не смешивать со вторым пунктом.

2. Всё что работает на клиентской стороне нужно собирать с заголовочными файлами и библиотеками из состава linux-дистрибутива или OpenLDAP. Так или иначе, самое главное - не смешивать с первым пунктом.

---

На всякий:

- OpenLDAP кошмарен. RedHat выбросил это дерьмо из RHEL совершенно оправдано. Чем раньше вы откажитесь от OpenLDAP и его библиотек, тем меньше будет боли.

- ReOpenLDAP гораздо меньшее дерьмо, но всё же устранить проблемы и недостатки можно только переписав код.
Разработка ReOpenLDAP велась для МегаФона и закончена летом 2016. Насколько мне известно, еще (примерно) через год МегаФон начал процесс миграции на Tarantool (что оправдано) и давно завершил его.
А с 2019 я приостановил доработку ReOpenLDAP и перенос исправлений из openLDAP, так как это требовало много времени и ресурсов, при слабой популярности у пользователей.
Поэтому, если требуется поддержка и/или ReOpenLDAP, то нужно искать спонсоров и/или волонтеров.

Тем не менее, при необходимости репликации (тем более multi-master) я рекомендую использовать ReOpenLDAP. Если же репликаций не нужна, то можно взять OpenLDAP, но еще лучше - любой другой ldap-сервер.

Ответить | Правка | К родителю #112 | Наверх | Cообщить модератору

116. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –2 +/
Сообщение от Lefsha (ok), 07-Янв-21, 14:28 
> Поэтому никакой совместимости с OpenLDAP быть не может.

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

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

А нет пользователей, нет bug reports - нет развития. Неужели багов совсем нет? - Есть конечно.
Значит смысл есть только в софте, которым кто-то пользуется.

В итоге пришлось послать все нафиг и поставить стандартный OpenLDAP.


> НЕОБХОДИМО и достаточно обеспечить использование правильных include-путей

Нет. Это не так! Есть несоместимость на уровне кода. Типы данных элементарно другие.
Я же привел пример. вместо unsigned long используется int, если размотать дебильные определения типов. Какую нафиг производительность это улучшает??? - Да никакую. А вот совместимость ломает.

Нафейхуа?


> Всё что работает на клиентской стороне нужно собирать с заголовочными файлами и библиотеками из состава linux-дистрибутива или OpenLDAP

Т.е. Вы хотите сказать, что несовместимость обоих пакетов не мешает сборки и работоспособности клиентских програм? - Я указал с какими программами проблемы - php и nss-pam-ldapd.
Уверен, что проблемы такого рода возникают со всеми клиентскими программами.

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

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


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

> OpenLDAP кошмарен. RedHat выбросил это дерьмо из RHEL совершенно оправдано

Сорри, но где альтернатива??? Кто угодно может выбрасывать что угодно. Но никто не предоставляет аналогичный функционал. Требования очень простые - полная интеграция пользователей внезависимости от сторонних программ использующих user authentication. Все, буквально все работает с OpenLDAP.

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

И наконец, "это дерьмо" работает. Просто работает. Я не вижу проблем. За несколько лет не было ни одной проблемы.

Я вообще столкнулся с выбором только по причине неудачной сборки OpenLDAP под Gentoo
без работы с mdb форматом. Они предлагают hdb по умолчанию. Проблема возникла в связи с перездом
из Arch на Gentoo. Под Arch все прекрасно работает и mdb поддерживается на ура.

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

В итоге просто сам собрал OpenLDAP с нужными опциями и все опять работает...

Я понимаю изменить все подряд внутри. Таже база данных - плевать какой там внутренний формат,
до тех пор пока интерфейс не сломан.

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


> ReOpenLDAP гораздо меньшее дерьмо, но всё же устранить проблемы и недостатки можно только переписав код.

Нет. Факты говорят о том, чо ReOpenLDAP гораздо большее дерьмо. Оно просто никому не нужно.


> требовало много времени и ресурсов, при слабой популярности у пользователей

Совершенно верно! НО! Этот путь Вы выбрали сами. Он программировался автоматически при выбранной стратегии развития проекта. Это был заезд в стену. Зачем?


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

Вы можете без проблем использовать свои функции и свои типы данных, НО только дополнительно
к стандартным.

Вы уверены, что некая функция может обеспечить лучший интерфейс и скорость - никто не мешает добавить такую функцию. Пусть библиотека весит в 2 раза больше. Пусть заг. файл будет больше.

Но! это оставит возможность людям пользоваться этим пакетом. Иначе в нем смысла 0.

Специальные пользователи типа Мегафонов всегда найдут себе решение проблемы в том числе написанное ими самими. Нельзя на них ориентироваться.


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

Времени нет ни у кого. Но пытаться копать программму в которой автор заменил ulong на int
нет никого желания. Остаются лишь сомнения в адекватности.

Прошу не принимать персонально к сердцу. А просто как информацию к размышлению. Несмотря на
возможное несогласие думаю како-то зерно тут есть.

Мне лично глобально концепция LDAP, которая из глубины веков не нравится совершенно.
Все устроено дико на первый взгляд. Китайский язык более понятен и адекватен.

Но есть одно НО. И это снова интеграция!!! Это условное дерьмо работает со всем!!! с чем мне
надо, чтобы оно работало. И нет никакой мало мальской альтернативы для того же самого.

Есть байка про 14 стандартов и новый лучший 15 стандарт. Тут тоже самое. Сделать этот 15ый стандарт может и дурак. А вот обеспечить интеграцию со всем софтом или прямо таки заставить
всех срочно это дело интегрировать врядли кто может без громких имен на рынке.

Но даже они слишком часто терпят неудачу в этом вопросе. Примеров масса.

Более лучший LDAP это гениальное решение. Но автор сам все испортил убив совместимость на корню.
И 15тый стандарт оказался никому не нужен. И справедливо не нужен. Жаль.

Ответить | Правка | Наверх | Cообщить модератору

117. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +2 +/
Сообщение от erthink (ok), 07-Янв-21, 15:32 
> Тогда и проект надо было называть по другому.

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

> А то якобы миллион улучшений, но пользы от них 0.000
> Вопрос интеграции с существующим софтом гораздо более важный вопрос нежели скорость работы.
>
> Да, скорость это приятно, но какой смысл от неуловимого Джо, который никому
> не нужен.
> А нет пользователей, нет bug reports - нет развития. Неужели багов совсем
> нет? - Есть конечно.
> Значит смысл есть только в софте, которым кто-то пользуется.

ReOpenLDAP делался не для абстрактных пользователей, а для решения проблем МегаФона.
Основные проблемы там были с адовой падучестью OpenLDAP и мега-проблемами в мульти-мастер репликации (OpenLDAP и сейчас может не только потерять отдельные апдейты, но и полностью удалить весь replication scope).

При этом проект (вcе доработки) удалось сохранить открытыми, хотя вся работа была профинансирована Петер-Сервисом.

> В итоге пришлось послать все нафиг и поставить стандартный OpenLDAP.

Если вас устраивает OpenLDAP, то зачем вы тратите мое время и делаетемненервы?

---

>> НЕОБХОДИМО и достаточно обеспечить использование правильных include-путей
> Нет. Это не так! Есть несоместимость на уровне кода. Типы данных элементарно
> другие.
> Я же привел пример. вместо unsigned long используется int, если размотать дебильные
> определения типов. Какую нафиг производительность это улучшает??? - Да никакую. А
> вот совместимость ломает.

Еще раз - вы что-то неверно понимаете.
Вы не можете собрать какой-то софт с reldap.lib, ибо это ДРУГАЯ библиотека.

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

Если вы собираете какие-то не-серверные модули, а софт работающий с ldap-сервером на клиентской стороне, то НИКАКОЙ взаимосвязи с ReOpenLDAP быть не должно.
Просто используйте заголовочный файлы и библиотеки из соответствующего libldap-devel пакета вашего дистрибутива.

---

>> Всё что работает на клиентской стороне нужно собирать с заголовочными файлами и библиотеками из состава linux-дистрибутива или OpenLDAP
> Т.е. Вы хотите сказать, что несовместимость обоих пакетов не мешает сборки и
> работоспособности клиентских програм? - Я указал с какими программами проблемы -
> php и nss-pam-ldapd.

Да, конечно, обязательно.
Поскольку протокол взаимодействия с ldap-сервером (через сеть и никак иначе) не изменился.

> Уверен, что проблемы такого рода возникают со всеми клиентскими программами.

Чушь.

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

Нет такой проблемы.
Если у вас возникает путаница, то вы сами смешали ужа с ежом.

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

Потому-что со стороны сервера ReOpenLDAP не нужно НИКАКИХ компонентов для сборки клиентских программ.
Более того, такое использование недопустимо.

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

Вы сами придумали какую-то интеграцию и какие-то проблемы.
Просто соберите сервер ReOpenLDAP, а не "интегрируйте" его с клиентскими модулями (на этом уровне для них нет разницы между OpenLDAP, ReOpenLDAP и любым другим ldap-сервером).


---

>> OpenLDAP кошмарен. RedHat выбросил это дерьмо из RHEL совершенно оправдано
> Требования очень простые - полная интеграция
> пользователей вне зависимости от сторонних программ использующих user authentication.

Весь клиентский софт будет работать с ReOpenLDAP без изменений и пересборки.
Чего еще вы хотите?

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

Вы делали что-то не то, от слова совсем.

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

Интерфейс с ldap-сервером - это запросы через сеть и здесь НИЧЕГО не изменилось.
А вы несете какую-то чушь, (видимо) не понимая сути.

>> ReOpenLDAP гораздо меньшее дерьмо, но всё же устранить проблемы и недостатки можно только переписав код.
> Нет. Факты говорят о том, что ReOpenLDAP гораздо большее дерьмо. Оно просто
> никому не нужно.

[...]
> нет никого желания. Остаются лишь сомнения в адекватности.

Ага, как говориться не делай добро и не придется за него расплачиваться ;)

Ответить | Правка | Наверх | Cообщить модератору

123. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –1 +/
Сообщение от Lefsha (ok), 08-Янв-21, 15:09 
>> Тогда и проект надо было называть по другому.
> Вы что-то принципиально не поняли, и пишите (уж извините) какую-то ерунду.
> Пожалуйста внимательно перечитайте мой ответ.

Нет. Не ерунду. Я ответил в другом сообщении про заг. файлы.

> Если вас устраивает OpenLDAP, то зачем вы тратите мое время и делаетемненервы?

Вроде бы естественное желание любого автора это то что его программой
будет пользоваться как можно больше людей. Отличный пример nginx.

Это не только почет и уважение, но и деньги.

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

> Еще раз - вы что-то неверно понимаете.
> Вы не можете собрать какой-то софт с reldap.lib, ибо это ДРУГАЯ библиотека.

Прекрасно! Согласен полностью! НО! Тогда измените название заг. файлов.
Это очень многого просить?

Неужели непонятно, что если Вы предоставляете нечти типа stdio.h, то в мышлении C/C++
вы берете на себя некую ответственность. Если Вы называете тоже самое mystdio.h,
то любая ответственность с Вас снимается.


>>> Всё что работает на клиентской стороне нужно собирать с заголовочными файлами и библиотеками из состава linux-дистрибутива или OpenLDAP
>> Т.е. Вы хотите сказать, что несовместимость обоих пакетов не мешает сборки и
>> работоспособности клиентских програм? - Я указал с какими программами проблемы -
>> php и nss-pam-ldapd.
> Да, конечно, обязательно.
> Поскольку протокол взаимодействия с ldap-сервером (через сеть и никак иначе) не изменился.

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

Ведь затык то случается именно в этом. Если бы заг. файл определял функцию A с параметром
B типа C, а клиентский софт эту функцию бы не использовал, потому как она предоставляется только для модулей работающих внутри, то и ошибки компиляции бы не возникло.

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

Как может быть по другому???

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

Это самый глупый ответ из возможных! Вы ведете себя неадекватно.

Я предоставил выдержку из лог файла компиляции. И все ошибки были именно в этом одном месте.
Вы не предоставилии НИЧЕГО для доказательства своей версии. Просто назвали все чушью.

Проверить мои доводы очень легко. Вместо этого Вы сами несете чушь.


>> Это снова вопрос интеграции. Название библиотек было переименовано, а вот название заголовочных
>> файлов нет! Это кошмар с точки зрения интеграции. Нельзя никому объяснить
>> почему 2 файла с одним именем имеют разное содержание.
> Нет такой проблемы.
> Если у вас возникает путаница, то вы сами смешали ужа с ежом.

Для упертых и для тех кто в танке или еще не протрезвел:

lber.h
lber_types.h
ldap_cdefs.h
ldap_features.h
ldap.h
ldap_schema.h
ldap_utf8.h
ldif.h
slapi-plugin.h

Эти файлы идентичны по названию в обеих якобы несовместимых библиотеках!!!
Но они же отличаются по содержанию, которое приводит к несовместимости.

Вы 9 раз сделали одну и туже ошибку? Врядли. Это было намеренно.

Есть только 1 файл openldap.h, которого нет у Вас.

Еще раз не надо завать чушью реальные вещи и если Вы не способны ответить на простой вопрос.

> Потому-что со стороны сервера ReOpenLDAP не нужно НИКАКИХ компонентов для сборки клиентских
> программ.
> Более того, такое использование недопустимо.

Вы умнее всех на свете????

Я еще раз повторяю, что теоретически может быть в Вашей позиции есть смысл.
Я сам придерживаюсь такой точки зрения. "Так не должно быть, но"
Реальность отличается от моего желания.

Если Вы настаиваете на своей правоте, то Вы берете nss-pam-ldapd или php с поддержкой ldap
и сами ручками компилируете их. Через условно 2-3 минуты Вы будете знать ответ.

Теперь Вы пишите в Спортлото... авторам всех клиентских программ и рассказываете им,
что так поступать недопустимо!!!

Вы сами то понимаете неадекватность своей позиции? Этот мир не будет прогибаться под Вас.

Что там теоретически правильно или нет - вопрос другой. Я Вам говорю про интеграцию,
про дружбу между программами. Вы можете идти на конфликт, но страдать будете ВЫ, а не они.
Есть в этом смысл? - По моему нет.


> Вы сами придумали какую-то интеграцию и какие-то проблемы.
> Просто соберите сервер ReOpenLDAP, а не "интегрируйте" его с клиентскими модулями (на
> этом уровне для них нет разницы между OpenLDAP, ReOpenLDAP и любым
> другим ldap-сервером).

Я этого и не делаю. Никаких модулей не собираю и не использую. Претензии не по адресу.

> Весь клиентский софт будет работать с ReOpenLDAP без изменений и пересборки.
> Чего еще вы хотите?

Чтобы он правда работал и главное перед этим собирался БЕЗ ошибок.


> Вы делали что-то не то, от слова совсем.

Я Вам привел ЛОГ файл. Вы способны на него посмотреть, сравнить то что у вас и то, что ждет
сторонняя программа и дать ответ по существу???

Скажите какой вообще теоретический смысл может быть слать вам Баг-репорты, если Вы на лог
файл отвечаете такую несуразицу?

Я НЕ сделал "что-то не то". Я сделал очень понятную вещь, которую абсолютно каждый может повторить. Включая Вас.

Мои претензии 100% обоснованы. - Ваш ответ - чушь.


> А вы несете какую-то чушь, (видимо) не понимая сути.

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

Одно дело Вы полностью понимаете, что именно Вам говорят - 2+2=5
И отвечаете - это чушь. все знают, что 2+2=4.

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


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

Мне кажется Вы перевернули картинку на изнанку. Весь наш спор и вся критика она для Вашей пользы.
Это я трачу свое время доказывая Вам очевидное. Если Вас критикуют - нужно радоваться.
Потому как самое страшное это забвение, а совсем не критика.
"Когда артист выступает перед пустым залом" - Вот чего надо бояться.

Вы сами говорили, что за работу получили вознаграждение. Так что нельзя сказать, что эта работа была проявлением альтруизма.

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

Сделать некий продукт это одно. Продать его публике это совсем другое.


Не нужно на меня обижаться. Если Вы немного подумаете, то поймете, что вреда я Вам никакого не нанес. Вы вольны игнорировать сказанное. Просто  обычно некий feedback это всегда хорошо.

И если возразить легко не получается, то это повод задуматься.

Ответить | Правка | Наверх | Cообщить модератору

118. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +2 +/
Сообщение от erthink (ok), 07-Янв-21, 15:56 
На всякий - если какие-то h-файлы изнутри ReOpenLDAP попали в install-targets, т.е. были установлены в /usr/include, то это действительно баг/недосмотр.

В этом случае заведите issue на github, постараюсь поправить как будет время.
Ну ил сразу засылайте PR с исправлением.

Ответить | Правка | К родителю #116 | Наверх | Cообщить модератору

119. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –2 +/
Сообщение от Lefsha (ok), 08-Янв-21, 14:09 
> На всякий - если какие-то h-файлы изнутри ReOpenLDAP попали в install-targets, т.е. были установлены в /usr/include

9 заголовочных файлов в ReOpenLDAP идентичны по названию и отличаются по содержанию
от OpenLDAP.

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

Либо Вы позиционируете свою программу как независимое произведение искусства
и тогда как порядочный человек Вы называете заголовочные файлы по другому.
Ровно как по другому Вы назвали сами библиотеки.

Либо Вы обеспечиваете полную совместимость хотя бы на уровне клиентских программ.

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

К сожалению это не так. Это беда С/C++ языков, где концепция заг. файлов это просто ущербно
и устарело. Rust в этом смысле просто подарок.

Но не суть.

Как я уже написал идеальным было бы решение - включения стандартных OpenLDAP файлов
в качестве заголовков для клиентского софта и использование своих имен для внутреннего
интерфейса.

Но даже если просто ваши имена файлов были бы другими, то это уже было бы решением.

А так Вы сидите на 2х стульях. И это самое плохое решение из возможных.

Не думаю, что Вы можете на уровне логики доказать обратное.

P.S. Нет смысла засылать патчи с переименованием файлов. Это не ошибка. Это то что делается намеренно!

Ответить | Правка | Наверх | Cообщить модератору

120. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от erthink (ok), 08-Янв-21, 14:25 
> Либо Вы обеспечиваете полную совместимость хотя бы на уровне клиентских программ.
> Для меня было новостью и честно говоря дикостью, что сторонние - клиентские
> программы
> требуют заг. файлы от OpenLDAP, хотя по идее должны просто соблюдать интерфейс
> и предоставлять такие файлы, если они нужны из своего набора заг. файлов.

Извините, но если вы не понимаете всего что было разжевано и повторено раз 10, то я не могу тратить на вас время.

Ответить | Правка | Наверх | Cообщить модератору

121. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +1 +/
Сообщение от erthink (ok), 08-Янв-21, 14:35 
> Не думаю, что Вы можете на уровне логики доказать обратное.

На всякий, последний раз, ради логики:
- все заголовочные файлы из ReOpenLDAP должны использовать ТОЛЬКО при сборке самого ReOpenLDAP и его модулей/плагинов.
- заголовочные файлы и библиотеки из ReOpenLDAP не предназначены для клиентского стороны и НЕ ДОЛЖНЫ использоваться при сборке клиентского ПО.
- ReOpenLDAP полностью совместим со всем клиентским ПО, так как протокол и формат данных при взаимодействии через сеть полностью сохранены/совместимы.

Всё, аминь.

Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

124. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –2 +/
Сообщение от Lefsha (ok), 08-Янв-21, 15:16 
>> Не думаю, что Вы можете на уровне логики доказать обратное.
> На всякий, последний раз, ради логики:

Вы это объясните авторам программ, которые используют ИДЕНТИЧНЫЕ заголовочные файлы.

У вас логика нарушена.

Ответить | Правка | Наверх | Cообщить модератору

125. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +1 +/
Сообщение от erthink (ok), 08-Янв-21, 15:29 
>>> Не думаю, что Вы можете на уровне логики доказать обратное.
>> На всякий, последний раз, ради логики:
> Вы это объясните авторам программ, которые используют ИДЕНТИЧНЫЕ заголовочные файлы.
> У вас логика нарушена.

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

Если по какой-то причине при сборке клиентского ПО попадают заголовочные файлы и/или библиотеки из ReOpenLDAP.
Либо наоборот, в сборку ReOpenLDAP попадают заголовочные файлы и библиотеки OpenLDAP.
То в обоих случаях сборка организована некорректно и результат будет заведомо неработоспособным.

Т.е. в принципе НЕЛЬЗЯ СМЕШИВАТЬ ReOpenLDAP и OpenLDAP.
А если не смешивать, то никаких проблем с разным содержимым заголовочных файлов быть не должно.

Тем не менее, можете оформить PR на github с переименованием (например добавлением префикса "reopenldap-") заголовочных файлов, конечно включая корректировку имен во всех файлах ReOpenLDAP.
Если всё будет сделано правильно (т.е. после прохождения review и корректировок), то я приму этот PR.

На этом всё.

Ответить | Правка | Наверх | Cообщить модератору

127. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –1 +/
Сообщение от Lefsha (ok), 08-Янв-21, 15:56 
> Тем не менее, можете оформить PR на github с переименованием (например добавлением префикса "reopenldap-") заголовочных файлов, конечно включая корректировку имен во всех файлах ReOpenLDAP.
> Если всё будет сделано правильно (т.е. после прохождения review и корректировок), то я приму этот PR.

Т.е. после долгих мучений мы таки признали, что не все так чисто...
Ну хоть так.

Извините и увольте. Но молить "барина" сделать по человечески я не буду.
Барин слишком долго распинался какую чушь я несу. А оказывается не чушь.

Я предпочту оставить Барина дальше на едине с его проектом.
Как я понимаю решили и сделать все остальные.

Только один совет оставлю на последок:

"Т.е. в принципе НЕЛЬЗЯ СМЕШИВАТЬ ReOpenLDAP и OpenLDAP."

включая заголовочные файлы...

Удачи.

Ответить | Правка | К родителю #125 | Наверх | Cообщить модератору

128. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +1 +/
Сообщение от erthink (ok), 08-Янв-21, 16:15 
Нет, не так.

Вы не верно организовали сборку какого-то клиентского ПО и/или ReOpenLDAP, но не смотря на многократные объяснения не смогли этого понять и продолжаете валить с больной головы на здоровую.

Поэтому, строго говоря, несли и продолжаете нести чушь.

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

Адью мосье.

Ответить | Правка | К родителю #127 | Наверх | Cообщить модератору

129. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +1 +/
Сообщение от Крым Наш (?), 08-Янв-21, 16:19 
Леонид, у вас ангельское терпение в отношении криворуких мудаков.
Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

130. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от Lefsha (ok), 12-Янв-21, 00:15 
> Нет, не так.

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

Я добавлю, что по мимо заголовочных файлов ReOpenLDAP
при инсталляции устанавливает бинарники в /usr/bin/,

которые ТОЖЕ идентичны тому что устанавливает OpenLDAP.

На этом доказательства невозможности установки 2 серверов можно считать доказанным.

Вы, будьте любезны, предоставьте ФАКТЫ опровергающие данные заключения,
которые базируются на фактах. Только не надо предлагать мне устанавливать все в /opt
или еще куда...

Итого:

Claims.

1. С одной стороны наименование почти всех файлов в новой библиотеке идентичны исходному продукту.
2. С другой стороны - совестимость между продуктами не декларируется и мало того заявляется отсутствие взаимозаменяемости - drop in replacement.


Вы можете говорить и думать что угодно. Но Вы не в состоянии пойти против фактов.
Так что я предлагаю Вам признать эти заключения. И подумать как это исправить.

Из позитивных моментов.

Я установил custom самосборную версию OpenLDAP, где есть только заг. файлы и клиентская библиотека. Таких версий нет в наличии. Стандартные опции не позволяют собрать такую версию.
Это ручками урезанная версия!!! Я специально акцентирую на этом внимание.

Версия ReOpenLDAP была поставлена в полном объеме. Это позволило как запустить сервер на имеющейся базе mdb и успешно собрать клиентские приложения.

Нужно молится, что я использую для этого Gentoo, где такие фокусы еще проходят.

В каких-то "редко" используемых дистрибутивах типа Ubuntu или Fedora это трюк не пройдет.
Копии файлов с идентичными именами будут затерты.

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

У автора Крым головного мозга. Но несмотря на это спасибо ему за рабочую программу.
Посмотрим как долго оно проживет...


Автору все таки посоветую не обижаться на критику и воспринимать ее как помощь, а не как нападение.

Ответить | Правка | К родителю #128 | Наверх | Cообщить модератору

131. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от erthink (ok), 12-Янв-21, 02:15 
Вы не достаточно компетентны, поэтому неверно трактуете положение дел и продолжаете валить с больной головы на здоровую.

1.
ReOpenLDAP не является пакетом какого-либо дистрибутива.
Его сборка и установка из исходных текстов предполагает наличие соответствующего опыта.
При этом ReOpenLDAP "ведет" себя совершенно ожидаемым образом (стандартное поведение configure, т.е. automake+autotools):
- по-умолчанию в качестве префикса используется /usr/local, а если вы сознательно ставите в корень, то должны понимать все последствия.
- совпадение имен каких-либо устанавливаемых файлов с имеющимися в файловой системе не является ошибкой, а затирание таких файлов является стандартным (обязательным) поведением.

Поэтому более-менее опытный админ будет устанавливать ReOpenLDAP (как и любой другой подобный софт) в /usr/local или /opt, либо "опакечивать" собственными руками, либо сознательно (с пониманием последствий) ставить по стандартным директориям (как вариант в chroot, docker и т.д.).

2.
ReOpenLDAP был сделан для МегаФона, как замена _серверной_ части OpenLDAP для решения проблем с нагруженной мульти-мастер репликацией (отсюда совпадение имен исполнимых модулей - обязательное требование).
Вы можете пользоваться результатом этой работы на основе принципов OpenSource.
Однако, никто не обещает (и тем более не гарантирует) что результат работы (в данном случае по требованиям МегаФона) подойдет "как есть" для других сценариев использования.

3.
ReOpenLDAP не предназначен (не было в целях) для одновременной установки вместе с OpenLDAP, но при необходимости это легко достигается установкой в /opt.
Все заголовочные файлы и библиотеки ReOpenLDAP не предназначены для сборки клиентского ПО, и не обязаны быть совместимыми с OpenLDAP.

---

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

Ответить | Правка | К родителю #130 | Наверх | Cообщить модератору

132. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  +/
Сообщение от Lefsha (ok), 12-Янв-21, 11:13 
> Вы не достаточно компетентны, поэтому

Доказательств моей некомпетенции предоставлено не было!
Это голословное обвинение. Так что это говорит больше о Вас, чем обо мне.

Я готов выслушать, в отличие от Вас, любые претензии  свой адрес, если будет аргументация.
Ее просто нет.

> 1. ReOpenLDAP не является пакетом какого-либо дистрибутива.

Миллион программ не являются пакетами дистрибутивов, когда находятся в исходниках.
В Gentoo таких 99% исключая пары бинарных пакетов, которые мало кто ставит.

Этот Ваш аргумент не работает и говорит о непрофессионализме.


> При этом ReOpenLDAP "ведет" себя совершенно ожидаемым образом (стандартное поведение configure, т.е. automake+autotools):

Если бы он себя еще не вел ожидаемым образом место ему было бы на помойке.
Сложно себе представить софт написаный под "automake+autotools" и под ними не работает...

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

Представьте, что софт написанный под cmake тоже под ним работает...
Да, больше. Сишная программа компилируется сишным же компилятором... С ума сойти.


>  затирание таких файлов является стандартным (обязательным) поведением.

Это вообще дремучая некомпетентность! За это надо бить по пальцам таких программистов.
До тех пор пока не по умнеют или перестанут быть в состоянии стучать по клавишам.
Любой, кто скажет такой бред провалит любое собеседование в эту же секунду!!!

И Вы смеете мне утверждать что-то о наличии компетенции??? Вы даже не понимаете какую чушь морозите. Ужас...


> более-менее опытный админ будет устанавливать ReOpenLDAP (как и любой другой подобный софт) в /usr/local или /opt

Вы деградируете на глазах. Как бы Вам это объяснить.... Есть такой анекдот про джигита, который
ездит на красный и стоит на зеленом... Во Вы его прекрасно напоминаете.

В вопросах интеграции софта Вы плаваете как в луже.

Нет. Ответ неверный. Если программист или админ будет ставить софт в /usr/local /opt итд
чтобы избежать конфликтов имен, то с гарантией 100% найдется другой программист, который
с этой же целью будет тоже ставить свой несовместимый софт в по такому же пути.

В итоге рано или поздно появится 1001 путей установки типа /opt1001
либо конфликт имен в случае всего 3х вариантов.

Задача программиста делать свой софт совместимым по пространству имен с другим софтом.
Тем более более или менее стандартным.

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

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

Вы либо заявляете, что перезаписывание имен при установке разными пакетами это нормально
и тогда нафиг разные там пути. Либо призываете каждый отдельный софт ставить по своему личному пути. Нельзя ратовать и за то и за другое. Это называется плюрализм мнений в одной голове.


> 2. ReOpenLDAP был сделан для МегаФона, как замена _серверной_ части

К сожалению далеко не всегда серверная и клиентская части разнесены по разным машинам.
Если бы это было так, то описываемых проблем не возникло.

> отсюда совпадение имен исполнимых модулей - обязательное требование

Может быть, но это снова противоречие самому себе! Совпадение имен происходит в КЛИЕНТСКОЙ
части софта. Если бы я мог оффициально ставить ТОЛЬКО серверную часть, то снова проблем не возникло бы.

OpenLDAP предлагает возможность поставить все БЕЗ сервера.
Если бы ReOpenLDAP позволил ставить только сервер, то это было бы идеальным решением.
Тем более, что Вы говорите, что клиентскую часть не оптимизировали или не меняли.

Т.е. мы опять и снова приходим к тому, что архитектурно было задумано неверно.
нужно было либо в рамках одного пакета предоставлять измененную серверную часть и не измененную
клиентскую, либо давать пользователям самим ставить ТОЛЬКО сервер.

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

Понятно, что ручками после установки по отдельному пути можно  оттяпать клиентскую часть,
что и было мной сделано. Потом все ставится по адекватным путям и прекрасно работает.

Если у меня не возникнет аллергия на Вас и Ваша упертость не изменится, то скорее всего
я объединю оба пакета в один клиентская от одного и серверная от другого.

Хотя честно говоря такая дремучесть в ответах наводит ужас. Но судя по тому, что вы ярый поборник Крыма все встает на свои места. Этот специальный ход мышления очевидно распространяется на все и не является чем-то особенным в отдельном вопросе. Уже неплохо.


> ReOpenLDAP не предназначен (не было в целях) для одновременной установки вместе с OpenLDAP

К сожалению в связи со сломанной Вами клиентской частью установка OpenLDAP это вынужденная мера!
У меня и в мыслях не было это делать.

Все таки неплохо бы помнить с чего _началась_ дискуссия. А то так и до анекдота - Папа, где море можной дойти. Этого бы совсем не хотелось.


> либо создайте свой fork где сделайте всё как считаете нужным.

судя по течению дискуссии форк это по сути единственный вариант в данном случае. жаль.
появится время - сделаю.

В любом случае я добился нужного для меня результата. И клиентская и серверная части работают.
Наверно потому, что я недостаточно компетен... Но оставим это на вашей совести.

Дальше общение не имеет смысла. Мы обозначили свои позиции. Я не приму Вашу. Вы не примите мою.

Удачи.

Ответить | Правка | К родителю #131 | Наверх | Cообщить модератору

109. "Выпуск высокопроизводительной встраиваемой СУБД libmdbx 0.9...."  –2 +/
Сообщение от Вы забыли заполнить поле Name (?), 03-Дек-20, 16:59 
Ну ты это автору объясни, который включил соответствующую цитату в README. Программирование и политика вещи несовместимые.
Ответить | Правка | К родителю #104 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

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