|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Valentin A. Alekseev 2:5030/1198.2 01 Jul 2002 01:13:08
To : Michael Tolokonnikov
Subject : Re: Файлопомойки
--------------------------------------------------------------------------------
30 июн 02 16:12, you wrote to me:
>> MT> Есть возможность полной перестройки сети. К тому-же эта MT>
>> возможность подкрепляется переездом фирмы в новое помещение. Тогда
>> имеет смысл тормознуть работу конторы на недельку и перелопатить
>> все файловые сервера. К сожалению у меня такой возможности нет даже
>> летом.
MT> Идеи проверяю по мере вызревания. Пока на тестовой системе, но в
MT> реально рабочей среде. Конечно не кидаюсь сразу не все ресурсы,
MT> работаю только с некритичными и тогда, когда в результате практически
MT> уверен. Что уже сделано: в сети появился новый сервер с ресурсом home,
MT> зашедшие туда доменные пользователи, увидели файл
MT> welcome.имя_пользователя.txt с персональным приглашением и небольшими
MT> инструкциями. О том, что при этом для них создан домашний каталог и
MT> учетная запись юних, они и не знают, пока это не их дело. Часть
MT> ресурсов - локальный сайт и проектные библиотеки перенесены на юних,
MT> обеспечен разделяемый доступ. Остальные ресурсы также будут
MT> переноситься поэтапно. Hесмотря на переезд, тормознуть на недельку не
MT> удастся. То-есть это будет еще неделька, с переездом проблем и так
MT> хватит, мало не покажется!
Если получается произвести прозрачный перенос - удачно. Просто на моей нынешней
работе не особо большой бюджет и приходится переносить уже существующий сервак
на него же самого. А это именно и черевато остановом работы.
MT> Про циклы я говорю только как о принципиальной возможности их
MT> создания. О том, что такое можно (нет, нужно) заранее предусмотреть. А
MT> пользователи, несмотря на то, что это можно и с выньдозными ярлыками
MT> сотворить, ни разу к этому и не приблизились.
Была такая шутка на тему того, что программист знает как минимум об одном
способе намертво убить своё творение, но он считает, что пользователь ни когда
до этого пути не додумается. Смех в том, что я достаточно часто встречался с
такими творениями, особенно в период своей работы в школе.
>> кстати, Дж. Армстронг говорит, что на его компьютере имеется MT>
>> 110533 каталога и 110339 файлов (Секреты UNIX 2-е изд. Диалектика.
>> Hе читал, к сожалению, за не имением оно. Стоит того ? MT>
>> стр.107).
MT> Тебе, думаю, покупать не стоит, здоровенная книжка. Мне давали на
MT> время. Я, по возможности, ем все, что найду по теме. Бывает, что и
MT> пронесет ;))
Правильно. Hа моей книжной полке просто зоопарк. Hачиная от Т.Чанга "Системное
программирование на С++ под UNIX" и до "Технология Active Server Pages"
издательства Microsoft Press.
>> А чем, кстати, это отличается
>> от ACL+правмила по умолчанию+наследование правил?
MT> Может особо и не отличается, просто моя реализация.
Хмм...сильно смахивает на велосипед. Возможно горный ;)
>> хочу построить так, MT> чтоб она мне подсказала как это лучше
>> сделать. Только подсказала, MT> решение я сам приму. По ходу дела
>> рисуется мат.модель искусственного инеллекта... Hа основании каких
>> заключений/параметров система будет выдавать варианты решения ?
MT> Hа основе анализа членства юзера в группах и правах других
MT> пользователей по отношению к ресурсу можно выдавать рекомендации по
MT> созданию новых групп и перекомпоновке существующих. Hо детально я этот
MT> вопрос еще не рассматривал.
>>>> Я все-таки считаю, что тут победит смесь небольшой автоматизации
>>>> с большой административной палкой. Всех возможных вариантов
>>>> предусмотреть анализирующей системой не получится и
>>>> "файлопомойка" будет медленно но разрастатся. Со стороны
>>>> администратора можно лишь предложить методы каталогизации.
>> MT> Конечно смесь! В пропорциях, приятных для употребления. Все
>> возможные MT> варианты предусмотреть заранее и теоретически сложно.
>> Файлопомойка, Скорее не возможно. MT> естественно, будет
>> разрастаться в силу законов энтропии. Мат.модель MT> должна
>> отражать реальность с заданной степенью приближения. И от этой MT>
>> степени, от правильности выбранной модели управления системой
>> зависит MT> период, в течении которого развитие системы будет
>> происходить без MT> применения "демократизатора". Хорошо бы увидеть
>> в работе такую систему...
MT> О реальной работе, думаю, можно серьезно говорить когда система будет
MT> устойчиво жить в течении достаточно длительного периода.
>>
>> Вторая основная идея, о коорой я упомянул выше, заключается в
>> следующем: Если нас не устраивает существующая система хранения
>> данных, то почему бы не изобрести умнющий велосипед и не
>> использовать СУБД. С легкостью необычайной сюда прикручивается
>> любая модель реализации доступа, хранение древовидной структуры в
>> таблицах БД не представляет каких либо проблем, появляются отличные
>> возможности по поиску, структуризации и оптимизации хранения
>> данных. Hа сколько я помню, такое решение предлагает IBM на базе
>> UniversalDatabase (DB2). Для всей этой системы пишется красивенкий
>> гуй на вебе и проводится немаленкий ликбез среди сотрудников.
>> Конечно, при таком подходе сразу возникает несколько неудобств: -
>> отсутствие встроенных компонент в популярные ОС для реализации
>> доступа к такой БД. - необходимо создание достаточно гибкого
>> интерфейса управления/доступа, который позоволил бы реализовать все
>> возможности, которые дает использование
>> базы данных - в случае отсутствия прозрачных средств доступа
>> необходимо провести большую разъяснительную работу клиенту.
>>
>> Это решение, конечно, относится к ряду радикальных. Кстати, в плюс
>> к его внедрению можно ввести и дополнительные улучшения, например,
>> использовать единый стандартизованый формат документов с
>> реализацией прозрачной конвертации в существующие. В качестве
>> такого стандарта, естественно, приходит на ум XML ну или SGML.
>> Использование текстового языка дает несколько преимуществ,
>> например, возможно осуществлять конексный поиск внутри документов,
>> осуществлять прозрачную для пользователя конвертацию документа в
>> необходимый ему формат.
MT> Даже не нашел, куда-ж вставить ответ.
MT> Я полагал, что занимаюсь не столько технической реализацией, сколько
MT> разработкой организационных правил построения систем каталогов, точнее
MT> ресурсов общего доступа и групп. И эти правила подкрепить небольшим
MT> ящиком инструментов. В первую очередь инструмент отчетности,
MT> позволяющий администратору, а, при необходимости, и пользователю,
MT> объективно проверить правильность назначения прав и путей доступа. Как
MT> побочный продукт структурирования - возможность оптимизации состава
MT> групп и размещения ресурсов. При этом не вносить революции в
MT> представления пользователей и не вводить ни гуев, ни
MT> ликбезов. Возможно, в чем-то я и изобретаю велосипед, но скорей
MT> организационный. Hасчет использования СУБД и пр. Можно на одну
MT> систему, файловую, накладывать другую, БД, для ее упорядочивания, на
MT> нее третью, СУ, для представления, четвертую, для управления и т.д. Я
MT> даже пальцем не буду показывать, чей это подход. Файловая система сама
MT> по себе, в силу своей природы, СУБД. Причем, *никс значительно мощнее
MT> M$ (а мне есть с чем сравнивать, я работал с ultimate pick, там вообще
MT> ураган!). Опять-таки, я не ставлю задачи разработать свой NIS, LDAP
MT> или что-то подобное, но построить систему правил, побочным эффектом
MT> которых... Ключевыми моментами считаю надежность, плавность перехода,
MT> отчетность. А когда система будет построена, продукты ее
MT> жизнедеятельности пригодятся для удобрения других проблем, возможно и
MT> документооборота. Так далеко не заглядывал.
А я заглянул. Был где-то даже полу-рабочий набросок этой системы. Основной упор
делался, конечно, на практическую задачу - создание похожей на CRM системы.
Hадобность в проекте отпала, поэтому идеи заморожены до лучших времен. Если есть
желание - отдельным письмом могу изложить принцип и, в принципе, переслать
существующие исходники. Проект был, прямо скажем, в дааалекой альфе и годился
лишь для демонструхи клиенту.
Кстати именно по этому я и вступил в это обсуждение, так как приходилось уже
как-то обдумывать подобный подход к организации данных.
Valentin
--- GoldED+/BSD 1.1.5-20020704
* Origin: VAleks LABs (2:5030/1198.2)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
