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

 
1 22 23 24 25 26 27 28

Mishka

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

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


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


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


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

yacc

старожил
★☆

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

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

Mishka

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

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

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

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

yacc

старожил
★☆

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

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

Mishka

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

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

HolyBoy

аксакал

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

yacc

старожил
★☆

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

Mishka

модератор
★★☆
yacc> С точки зрения NSS ничего не поменяется, если ты вместо nis напишешь ldap. :)
Кто-то говорил про разные источники данных. :P
 
RU Владимир Малюх #21.03.2008 06:23  @HolyBoy#20.03.2008 23:07
+
-
edit
 
HolyBoy> Вопрос ВМ.
HolyBoy> Скажи пожалуйста, что составляет сложность в создании "серьезной" САПР?
HolyBoy> Написание той части, что обеспечивает твердотельное моделирование, расчет прочностей и прочего, что требуется в работе конструктору, помимо, само собой, обыкновенного рисования чертежей и выдачи задания для станков с ЧПУ?

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

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

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

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

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

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

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

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

yacc

старожил
★☆

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

HolyBoy

аксакал

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

Mishka

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

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

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

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

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

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

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

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


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

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

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> Случаи разные бывают. :)
Случай как правило один и тот же - хочется быстрее переставить, чтобы по-нормальному администрировать, не перенастраивая клиентов. :)
 
RU Владимир Малюх #21.03.2008 17:50  @HolyBoy#21.03.2008 15:41
+
-
edit
 
HolyBoy> Благодарю, Владимир, за столь обширный и подробный ответ.

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

Mishka

модератор
★★☆
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стр текста по делу вышло :)

А можно где-то до твоего диссера добраться?
 
RU Владимир Малюх #22.03.2008 08:57  @Mishka#22.03.2008 05:51
+
-
edit
 
Mishka> А можно где-то до твоего диссера добраться?

Где-то лежит на сайте института, в ктором совет - я не помню, лучше я тебе пдф-ку пришлю, если так интерсно, адрес вроде у меня есть. На самом деле бумага - довольно формальная как сам понимаешь, чтоб стандарту соответствовать :) Ну и не все карты раскрыты.
Maschinen muessen "idiotensicher" werden  
+
-
edit
 

Mishka

модератор
★★☆
Давай. Интересно. Я почитаю и буду с вопросами приставать.
 
RU Владимир Малюх #22.03.2008 19:28
+
-
edit
 
Оказалось архив у меня на работе лежит - так что если не завтра, то в понедельник вышлю. Там в общем-то все банально с точки зрения идеи, все очень небанально на практике с точки зрения реализации и особенно внедрения в реальность.
Maschinen muessen "idiotensicher" werden  
Это сообщение редактировалось 22.03.2008 в 19:35

yacc

старожил
★☆

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

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

Mishka

модератор
★★☆
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.
 

yacc

старожил
★☆

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

Так что не надо мне сказок рассказывать про NSS.
 
Это сообщение редактировалось 23.03.2008 в 05:54

Mishka

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

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

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

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

yacc

старожил
★☆

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

Миш, ну мне же прекрастно видно, что если LDAP ты знаешь, то в NSS ты плаваешь. И наверняка даже не представляешь в каких случая LDAP-NIS bridge ( так это по другому называется ) делать не следует и из каких ограничений это вытекает. :)
 
Это сообщение редактировалось 23.03.2008 в 13:31
RU HolyBoy #23.03.2008 13:22  @Владимир Малюх#21.03.2008 17:50
+
-
edit
 

HolyBoy

аксакал

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

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

RUS_7777

опытный

сегодня мельком глянул одну передачу по ТВ, какой то конкурс среди школьников был, отвечали школьники на вопросы, я включился как раз на вопросе, в честь какого ученого была названа единица напряжения в электротехнике, посовещавшись школьники ответили, что в честь Ома, правильный ответ, Вольт.
 
1 22 23 24 25 26 27 28

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru