"Америка тупеет." (С) И если б только Америка...

yacc> Э... стоп. Либо ты на master NIS сервак ставишь так, что он берет данные с LDAP ( а это от сервака зависит - хоть в SQL хранить можно ), а клиенты ходят к нему через RPC-NIS ( т.е. у них в nsswitch.conf написано nis ), либо ты у них в nsswitch.conf прописываешь ldap и никакого NIS уже нет, а есть LDAP.

Чего стоп? LDAP — это протокол. Облегчённый для доступа к сервису x.500. Всё. То, что люди начинают понимать под словом LDAP — это уже их проблемы. Сам LDAP сервис (точнее x.500) строит только иерархическую модель хранения данных. С некоторыми зачатками сетевой (разрешаются ссылки в дереве наследований). Я видел сетевые реализации и на реляционных базах — ты сам про SQL говоришь. ССылку на стандарт LDAP-а я уже приводил в этом топике. Можно почитать.


А так был NIS, а стал LDAP — с точки зрения клиента — вс пофигу. И проблем с разными UID не возникает.


yacc> А я тебе про ОС как таковую говорил, а не про то, как ее продавать и лицензировать... Ты кого хоронишь - ОС или бизнес-модель продаж? ОС такого типа и поныне живет в здравии...


Тогда не понятно при чём тут глухие из Лондона — я тебе про модель говорил, а не ОС.

Mishka> Чего стоп? LDAP — это протокол. Облегчённый для доступа к сервису x.500. Всё.
Вообще-то для подсистемы NSS это еще и источник данных, равно как и NIS или files. И ведает доступом к нему соответсвующая so-шка-плагин. И конфликты возможны если некорректно перенесешь.

Mishka> Тогда не понятно при чём тут глухие из Лондона — я тебе про модель говорил, а не ОС.
Т.е. дело опять не в технической стороне, а в модели продаж?

yacc> Вообще-то для подсистемы NSS это еще и источник данных, равно как и NIS или files. И ведает доступом к нему соответсвующая so-шка-плагин. И конфликты возможны если некорректно перенесешь.

Модель данных и наполнение к модели — это уже не LDAP. Просто в народе уже привыкли называть его так. Отношение примерно такое же, как между http и html.

Mishka>> Тогда не понятно при чём тут глухие из Лондона — я тебе про модель говорил, а не ОС.
yacc> Т.е. дело опять не в технической стороне, а в модели продаж?

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

Mishka> Модель данных и наполнение к модели — это уже не LDAP. Просто в народе уже привыкли называть его так. Отношение примерно такое же, как между http и html.

Ну тогда оцени корректность своей фразы: "Ну, эту проблему давно решили с yellow pages. То бишь LDAP-м."
yellow pages - это другое названия Sun-овского протокола NIS для доступа к службе каталогов ( переименованного, потому как YP была зарегистрированная торговая марка ). А LDAP - другой протокол доступа к службам каталогов... С точки зрения NSS это разные источники данных типа служб каталогов, которые могут содержать разные данные и располагаться в разных местах. Если тебе охота данные одного источника распространять через другой по другому протоколу - это на твою фантазию. Но YP и LDAP - вещи не связанные - это два разных протокола.

yacc> yellow pages - это другое названия Sun-овского протокола NIS для доступа к службе каталогов ( переименованного, потому как YP была зарегистрированная торговая марка ). А LDAP - другой протокол доступа к службам каталогов... С точки зрения NSS это разные источники данных типа служб каталогов, которые могут содержать разные данные и располагаться в разных местах. Если тебе охота данные одного источника распространять через другой по другому протоколу - это на твою фантазию. Но YP и LDAP - вещи не связанные - это два разных протокола.

В том-то и дело, что на поверхности — YP, а в глубине LDAP. С точки зрения NSS ничего не поменялось. А в реале — LDAP — это как IP over IP. Ничего странного.

Mishka> В том-то и дело, что на поверхности — YP, а в глубине LDAP. С точки зрения NSS ничего не поменялось. А в реале — LDAP — это как IP over IP. Ничего странного.
С точки зрения NSS ничего не поменяется, если ты вместо nis напишешь ldap.

yacc> С точки зрения NSS ничего не поменяется, если ты вместо nis напишешь ldap.
Кто-то говорил про разные источники данных.

HolyBoy> Вопрос ВМ.
HolyBoy> Скажи пожалуйста, что составляет сложность в создании "серьезной" САПР?
HolyBoy> Написание той части, что обеспечивает твердотельное моделирование, расчет прочностей и прочего, что требуется в работе конструктору, помимо, само собой, обыкновенного рисования чертежей и выдачи задания для станков с ЧПУ?

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

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

То же самое с ЧПУшными и расетными делами - в мире десятки уже готовых пакетов САМ и САЕ, главное обеспечить сопрягаемость конструкторской системы с ними. Крупные игроки в САПР протсо покупают компани-разработчиков таких систем, так сдели в SolidWorks купив COSMOS, так сдела Dassault, купив ABAQUS..

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

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

Все это усложняется тем, что специалистов по архитеткуре САПР очень немного и крайне сложно их вырастить. Для того, чтобы набраться реального опыта, нужно сделать и реализовать 2-3-4 проекта, причем первые будут наверняка не очень удачные - такова жизнь, опыт набирается только на ошибках. Оплатить такие экзерсизы в течение 5-10 лет - мало кто может себе позволить. Как горят люди в этом вопросе многоопытные (Барнар - создатель CATIA, Пейн - SolidWorks, Джон Валкер - отец AutoCAD) реально таких вот проектантов САПР в мире от силы полторы-две сотни человек, мнгоие знакомы лично либо по перписке. Отдельная пролема - в силу сугубо коммерческой основы всей отрасли, исследовательские результаты редко публикуются открыто, то чтто можно горить друг-другу - также весьма ограничено. Посемумахровым цветом цветет "шпионаж" - все тратят уйму ресурса на изучение других продуктов, по крупицам выуживая и заимствуя идеи. Более того, есть спрос на такой анализ, сделанный сторонними компаниями, не занимающимися разработкой своеих продуктоы. В частности, часть моих служебных обязанностей нынче - такой анализ на заказ, причем порой от прямо конкурирующих организаций

До сих пор довольно много хлопот, проб, ошибок и отнсительных неудач в области пользовательского интерфейса. До сих пор удобства и иестественности работы, какое было на кульмане, не достигнуто Да работать стало эффективнее, но и сложнее. Сейчас большиенадежды возлагаются на "возврат к кульману" в виде экранов с пером. Крупноформатные ЖКИ и современные стилусы в отличие от "световых перьев" 70-80-х на самом деле удобны. Но тут приходится персматривать, причем в мелочах всю систему GUI, ранее ориентриованную на мышки и, во многом, на клавиатуру. Довольно сложно переломить стереотипы удобтсва для программистов-разработчиков, которые не всего и не во всем годны для инженеров. Например - любимые програмистами "горячие клавиши" малопопулярны у конструкторов, больше мыслящих и работающ не текстовыми а геометрическими и визуальными образами.

Одна из жестоких болячек рынка САПР - обмен данными и форматы. Сейчас в ходу более 40 разных и практически нет систем 100% перносящих информацию из одной системы в дургую. Всегда что-то теряется, то специфическая информация, то параметризация, а то и просто элементы геометрии. "Договриться" пока не удается, "крупняки" не очень склонны менять свои платформы, да и что делать с уже накомпленными данными - неясно.. А обмениваться приходится все чаще и чаще, бо смежники, партнеры, поставщики готовых изделий.

yacc>> С точки зрения NSS ничего не поменяется, если ты вместо nis напишешь ldap.
Mishka> Кто-то говорил про разные источники данных.
Данные, доступные по разным протоколам, в общем случае не обязаны храниться в одном и том же хранилище и быть одинаковыми... Для NSS - это метод разделения. То, что ты прокси из одного протокола в хранилище, доступное по другому протоколу напрямую сделал - это на твой вкус, потому как и так сделать никто не запрещает, хотя и запрос пойдет через два вызова по соответсвующим протоколам ( NIS на RPC организован, а LDAP идет напрямую по сокету ), а не по одному одного протокола. Я даж знаю почему так зачастую делают

yacc> Данные, доступные по разным протоколам,

Я к тому же. Это не разные источники — это разные способы получения.

yacc> в общем случае не обязаны храниться в одном и том же хранилище и быть одинаковыми...

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

yacc> Для NSS - это метод разделения. То, что ты прокси из одного протокола в хранилище, доступное по другому протоколу напрямую сделал - это на твой вкус, потому как и так сделать никто не запрещает, хотя и запрос пойдет через два вызова по соответсвующим протоколам

Транспорт никогда не играл ключевую роль в этом.

yacc> ( NIS на RPC организован, а LDAP идет напрямую по сокету ),

RPC идёт тоже по сокету. Это вполне нормально. RPC это протоколы уровня выше 5. А LDAP на 6 не выходит — у него могут быть проблемы с единым представлением данных — он не определяет кодировку.


yacc> а не по одному одного протокола. Я даж знаю почему так зачастую делают

Случаи разные бывают.

Mishka> Я к тому же. Это не разные источники — это разные способы получения.
Зря придераешься к концептуальным тонкостям - это уже имя нарицательное Тем более что LDAP серверов из основных - раз-два-три и обчелся: AD, ADAM, SunONE ( iPlanet ), OpenLDAP ну еще парочку-тройку. Посему можно смело это считать источником данных.

Mishka> Транспорт никогда не играл ключевую роль в этом.
Транспорт определяет каким протоколом ( NIS, LDAP, DNS, NIS+ ) соотвествующий протоколу плагин NSS пойдет к этому источнику. На то он и плагин.

Mishka> RPC идёт тоже по сокету. Это вполне нормально. RPC это протоколы уровня выше 5. А LDAP на 6 не выходит — у него могут быть проблемы с единым представлением данных — он не определяет кодировку.
В Unix есть UTF-8 и он понимается всеми С-функциями типа getpwnam и т.п., которые предоставляет NSS. И более того NIS - протокол, который использует другой протокол ( RPC ) выше транспортного уровня ( UDP/TCP ), а для LDAP достаточно транспортного уровня.

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

HolyBoy> Благодарю, Владимир, за столь обширный и подробный ответ.

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

yacc> Зря придераешься к концептуальным тонкостям - это уже имя нарицательное Тем более что LDAP серверов из основных - раз-два-три и обчелся: AD, ADAM, SunONE ( iPlanet ), OpenLDAP ну еще парочку-тройку. Посему можно смело это считать источником данных.

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

yacc> Транспорт определяет каким протоколом ( NIS, LDAP, DNS, NIS+ ) соотвествующий протоколу плагин NSS пойдет к этому источнику. На то он и плагин.

Правильно. плагин. Какой источники за ним никто не знает. С точки зрения самой прораммки верхнего уровня — источник не протокол.

yacc> В Unix есть UTF-8 и он понимается всеми С-функциями типа getpwnam и т.п., которые предоставляет NSS. И более того NIS - протокол, который использует другой протокол ( RPC ) выше транспортного уровня ( UDP/TCP ), а для LDAP достаточно транспортного уровня.

Нет, UTF-8 — это всего лишь UNICODE. А уровень 6 — это представление данных. Тот же FTP имеет задатки этого — понишь командочки ASCII и BINARY? Поэтому представление бинарных данных (в LDAP-е они могут быть бинарными) никакого отношения к UTF-8 не имеют. Если ты только не собираешься всё переводить в символьный вид и обратно.

yacc> Случай как правило один и тот же - хочется быстрее переставить, чтобы по-нормальному администрировать, не перенастраивая клиентов.

Это с точки зрения админа.

В.М.> Упс - я-то как раз старался покороче На самом деле - тут книги писать можно. У меня дисер например был как раз по расширямой архитектуре, даже поверхностно - 60стр текста по делу вышло

А можно где-то до твоего диссера добраться?

Mishka> А можно где-то до твоего диссера добраться?

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

Mishka> Придераюсь потому, что протоколы сейчас моя специальность. Ситуация я тебе примерно с html и http проиллюстрировал.
Ну... это еще не повод придераться
Mishka> Правильно. плагин. Какой источники за ним никто не знает. С точки зрения самой прораммки верхнего уровня — источник не протокол.
С точки зрения программы верхнего уровня есть API для NSS, а уж интимные дела хранения данных ей не интересны.

Mishka> Нет, UTF-8 — это всего лишь UNICODE. А уровень 6 — это представление данных. Тот же FTP имеет задатки этого — понишь командочки ASCII и BINARY? Поэтому представление бинарных данных (в LDAP-е они могут быть бинарными) никакого отношения к UTF-8 не имеют. Если ты только не собираешься всё переводить в символьный вид и обратно.
Давай я тебе слово магическое скажу - RFC2307 - найди там мне BINARY .... Можешь для разнообразия пробежаться по MS SFU схемам и тоже BINARY поискать

yacc> Давай я тебе слово магическое скажу - RFC2307 - найди там мне BINARY .... Можешь для разнообразия пробежаться по MS SFU схемам и тоже BINARY поискать

А чего ты мне исторический информационный RFC подсовываешь. Ты читай определение протокола.
http://www.ietf.org/rfc/rfc4511.txt?number=4511 — это третья версия. Различия со второй я приведу позже.

"стр. 44":

Protocol peers MUST be prepared to handle invalid and arbitrary-
length protocol encodings. Invalid protocol encodings include: BER
encoding exceptions, format string and UTF-8 encoding exceptions,
overflow exceptions, integer value exceptions, and binary mode on/off
flag exceptions. The LDAPv3 PROTOS [PROTOS-LDAP] test suite provides
excellent examples of these exceptions and test cases used to
discover flaws.

 

"стр. 59-60":

Appendix C. Changes

This appendix is non-normative.

This appendix summarizes substantive changes made to RFC 2251, RFC
2830, and RFC 3771.
...


C.1.7. Section 4.1.5.1 (Binary Option) and others

- Removed the Binary Option from the specification. There are
numerous interoperability problems associated with this method of
alternate attribute type encoding. Work to specify a suitable
replacement is ongoing.

 

Вполне себе нормальное двоичное кодирование. Особенно BER из ASN.1.

Так что не надо мне сказок рассказывать про протокол LDAP.

Mishka> А чего ты мне исторический информационный RFC подсовываешь. Ты читай определение протокола.
Затем что речь идет по конкретную подсистему - NSS и там все конкретно для плагина определено - какого сорта данные он вытаскивает и в каком виде они представлены. Ну и зачем ты мне общий вид LDAP предлагаешь?

Так что не надо мне сказок рассказывать про NSS.

yacc> Затем что речь идет по конкретную подсистему - NSS и там все конкретно для плагина определено - какого сорта данные он вытаскивает и в каком виде они представлены. Ну и зачем ты мне общий вид LDAP предлагаешь?

Ни фига. Речь идёт про LDAP и мои придирки к нему. Это ты пыдаешься выдать подсистему за LDAP.

yacc> Так что не надо мне сказок рассказывать про NSS.

Не надо мне сказок рассказывать про LDAP.

Mishka> Ни фига. Речь идёт про LDAP и мои придирки к нему. Это ты пыдаешься выдать подсистему за LDAP.
Найди мне это место. Не я называл LDAP YP... Речь изначально была не про LDAP, как протокол, а про место, где хранить информацию об аккаунтах, а использует это NSS, и каким протоколом к этому хранилищу ходить.

Миш, ну мне же прекрастно видно, что если LDAP ты знаешь, то в NSS ты плаваешь. И наверняка даже не представляешь в каких случая LDAP-NIS bridge ( так это по другому называется ) делать не следует и из каких ограничений это вытекает.

В.М.> Упс - я-то как раз старался покороче На самом деле - тут книги писать можно. У меня дисер например был как раз по расширямой архитектуре, даже поверхностно - 60стр текста по делу вышло

Да, но в нем я увидел ответы на свои еще не заданные вопросы, поэтому такая реакция.