* [Comm] Мысль по поводу организации общего файлохранилища (для обсуждения) @ 2008-12-10 7:30 Денис Черносов 2008-12-10 10:24 ` [Comm] Мысль по поводу организации общего файлохранилища ( для обсуждения ) Yuri Bushmelev 0 siblings, 1 reply; 5+ messages in thread From: Денис Черносов @ 2008-12-10 7:30 UTC (permalink / raw) To: ALT Linux Community general discussions Навеяно вот этой статьей и экспериментами с Ruby On Rails и вдохновением от wiki-технологий: http://www.calculate-linux.ru/%D0%9E%D1%80%D0%B3%D0%B0%D0%BD%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F_%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F_%D1%84%D0%B8%D0%BB%D1%8C%D0%BC%D0%BE%D0%B2 Проблема: Чаще всего общие файлохранилища превращаются в файлопомойки, в которых даже хозяева файлов не могут разобраться. Это и перерасход места и потери рабочего времени на поиск и многочисленные дублирования со всеми вытекающими. Плюс целый букет проблем из области безопасности: трудности с настройками резервного копирования утечка корпоративных секретов, нелицензионный софт и пиратский медиаконтент и т.п. Отказ от файловых систем в пользу систем документооборота не всегда оправдан, поскольку накладывает достаточно много других ограничений и лишает традиционных преимуществ - понятность абстракции, высокое быстродействие и т.п. Причины: 1) отсутствие общепринятых паттернов файловой иерархии для большинства случаев (включая соглашения об именовании файлов и каталогов и разделения доступа к ним). Их не предлагают по умолчанию в таких продуктах, как Samba или Nfs (примеры настройек для папок верхнего уровня не в счет - это просто специализация файлопомоек) и этому не учат ни в школах ни на курсах. Замкнутый круг - культуры нет, потому что её нет нигде. 2) отсутствие автоматических средств для быстрой организации умолчальных деревьев каталогов, выставления прав на них, заполнения и актуализации метаинформации о содержимом каталогов, автоматическом перемещении, переименовании, удалении файлов и каталогов. Нет смысла обвинять пользователей в том, что они не хотят выполнять изо дня в день работу более подходящую для роботов. При наличии формализованных соглашений, становится возможным создание скриптов на все случаи жизни (как это сделано в Ruby On Rails). Остается только один вопрос - как, не порождая новых сущностей (хотя бы на стороне клиента) и зависимостей реализовать это на базе samba, nfs, ftp. Очевидно, через адресацию - несуществующий адрес воспринимается, как команда и при осмысленности этой команды и наличии достаточных прав на её выполнение - вуаля! Что интересно - можно прикручивать этот модуль для отработки именно несуществующих адресов, а это практически не повлияет на быстродействие системы в целом. А в качестве доп. вкусностей еще мечты: при наличии проблем, диагностическое сообщение (возможно с предугадываниями, типа "наверное вы хотели вот этого" и/или подсказками - "если хотите того, то начните сначала с этого"). Преимущества: Будучи единожды разработанным, такой модуль будет легко адаптируемым для самых разных файловых (а может и других) систем и ситуаций, потому что каждая команда будет всего лишь набором нескольких элементарных команд... Которые нужно выполнять в контексте безопасности того пользователя, который породил команду. Скрипты будут настраиваемы даже начинающими администраторами. И все эти настройки будут совершаться на стороне сервера. Как доп. опция реализации - позволить клиенту хранить в сетевой домашней папке собственные скрипты и проверять их наличие вместе с общесистемными. Это дополнительный уровень удобства, который также повысит склонность пользователей к формализации структуры каталогов и именования файлов. Что скажете? Баян? Утопия? ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Comm] Мысль по поводу организации общего файлохранилища ( для обсуждения ) 2008-12-10 7:30 [Comm] Мысль по поводу организации общего файлохранилища (для обсуждения) Денис Черносов @ 2008-12-10 10:24 ` Yuri Bushmelev 2008-12-10 11:12 ` Денис Черносов 0 siblings, 1 reply; 5+ messages in thread From: Yuri Bushmelev @ 2008-12-10 10:24 UTC (permalink / raw) To: ALT Linux Community general discussions В сообщении от Среда 10 декабря 2008 Денис Черносов написал(a): > Навеяно вот этой статьей и экспериментами с Ruby On Rails и > вдохновением от wiki-технологий: > > http://www.calculate-linux.ru/%D0%9E%D1%80%D0%B3%D0%B0%D0%BD%D0%B8%D0%B7% >D0%B0%D1%86%D0%B8%D1%8F_%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F_% >D1%84%D0%B8%D0%BB%D1%8C%D0%BC%D0%BE%D0%B2 > > Проблема: > Чаще всего общие файлохранилища превращаются в файлопомойки, в которых > даже хозяева файлов не могут разобраться. Это и перерасход места и > потери рабочего времени на поиск и многочисленные дублирования со > всеми вытекающими. Плюс целый букет проблем из области безопасности: > трудности с настройками резервного копирования утечка корпоративных > секретов, нелицензионный софт и пиратский медиаконтент и т.п. > Отказ от файловых систем в пользу систем документооборота не всегда > оправдан, поскольку накладывает достаточно много других ограничений и > лишает традиционных преимуществ - понятность абстракции, высокое > быстродействие и т.п. Прям постановка проблемы из текста моей диссертации, которую я бросил, написав три главы и кусок кода. > Причины: > 1) отсутствие общепринятых паттернов файловой иерархии для большинства > случаев (включая соглашения об именовании файлов и каталогов и > разделения доступа к ним). Их не предлагают по умолчанию в таких > продуктах, как Samba или Nfs (примеры настройек для папок верхнего > уровня не в счет - это просто специализация файлопомоек) и этому не > учат ни в школах ни на курсах. Замкнутый круг - культуры нет, потому > что её нет нигде. А вы представляете себе типовые паттерны на все случаи жизни с учетом субъективности каждого пользователя ресурса? Если так, то вам, совершенно определенно, можно выступать с семинарами по логической организации корпоративных хранилищ данных. И это не шутка :) > 2) отсутствие автоматических средств для быстрой организации > умолчальных деревьев каталогов, выставления прав на них, заполнения и > актуализации метаинформации о содержимом каталогов, автоматическом > перемещении, переименовании, удалении файлов и каталогов. Нет смысла > обвинять пользователей в том, что они не хотят выполнять изо дня в > день работу более подходящую для роботов. Тоже сильно похоже на кусок из моего диссера :) > При наличии формализованных соглашений, становится возможным создание > скриптов на все случаи жизни (как это сделано в Ruby On Rails). > Остается только один вопрос - как, не порождая новых сущностей (хотя > бы на стороне клиента) и зависимостей реализовать это на базе samba, > nfs, ftp. Нужно просто информационные ресурсы раскладывать по каталогам так, чтобы это устраивало субъективность всех пользователей помойки. > Очевидно, через адресацию - несуществующий адрес воспринимается, как > команда и при осмысленности этой команды и наличии достаточных прав на > её выполнение - вуаля! > Что интересно - можно прикручивать этот модуль для отработки именно > несуществующих адресов, а это практически не повлияет на > быстродействие системы в целом. А в качестве доп. вкусностей еще > мечты: при наличии проблем, диагностическое сообщение (возможно с > предугадываниями, типа "наверное вы хотели вот этого" и/или > подсказками - "если хотите того, то начните сначала с этого"). Тут ничего не могу сказать.. Искусственный интеллект на уровне доступа к данным я не рассматривал. Я предпочитаю использовать его на уровне публикации ресурсов. > Что скажете? Баян? Утопия? Скажу, что такие вещи существуют. Обычно они входят в состав корпоративных систем документооборота и стоят много денег. Простейший случай - авторубрикаторы. Об их качестве ничего сказать не могу - не трогал. Я занимался частным случаем "помойки" для реализации хранилища документации. Там попроще, поскольку внутри есть текст, который можно классифицировать. Берем "помойку", проводим частотный анализ текста в каждом документе, выбираем N наиболее частоупотребимых слов в ресурсе (за исключением стоп-слов) и подаем на вход кластеризатора (в моем случае - нейронная сеть в режиме кластеризатора). Выходов у сети либо по количеству категорий, если дерево категорий одноуровневое, либо некоторое фиксированное число (например, 7), если категории могут быть вложенными (в этом случае, кластеризация проводится несколько раз по количеству уровней в дереве). Запоминаем, где был сигнал, подаем следующий документ. В результате, получаем соответствие документов, которые подавались на вход кластеризатора, сигналам на его выходе (то есть, категориям). Обзываем категории, ориентируясь на смысл сгруппированных документов, создаем соответствующее дерево на файловой системе и раскладываем документы соответствующим образом. Далее, нейронная сеть переключается в режим классификатора (отключаем обучение). Новые документы заливаются в спул, там их подхватывает классификатор, считает частотность и прогоняет ее через нейронку. По результатам классификации, документы кладутся в нужный каталог. Периодически (в зависимости от частоты появления новых документов) можно проводить кластеризацию и сравнивать ее результаты с тем, что есть сейчас. Как расхождение превысит некоторый лимит, переупорядочиваем структуру каталогов и документов в них (благо, это можно делать автоматизированно). Вкратце, так. Но это все - чистая теория. Эксперименты я не провел. Поэтому, вполне может оказаться, что документы, собранные кластеризатором в одну категорию, на самом деле имеют очень мало общего. И для кластеризации недостаточно учитывать только частотность слов, но еще придется учитывать их взаимное расположение. Все это тащит за собой неслабый матаппарат, который я не люблю :) Для случаев нетекстовой информации (фильмы, музыка, графика, ПО) эта схема может быть использована по каким-либо метаданным (тегам, сопроводительным файлам и т.д.). Это была моя утопия, от которой я когда-то отказался, потому что потерял интерес к теме и занимался на тот момент совсем другими вещами. -- С уважением, Бушмелев Юрий ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Comm] Мысль по поводу организации общего файлохранилища ( для обсуждения ) 2008-12-10 10:24 ` [Comm] Мысль по поводу организации общего файлохранилища ( для обсуждения ) Yuri Bushmelev @ 2008-12-10 11:12 ` Денис Черносов 2008-12-10 11:26 ` Yuri Bushmelev 0 siblings, 1 reply; 5+ messages in thread From: Денис Черносов @ 2008-12-10 11:12 UTC (permalink / raw) To: ALT Linux Community general discussions 10 декабря 2008 г. 14:24 пользователь Yuri Bushmelev <jay4mail@gmail.com> написал: > В сообщении от Среда 10 декабря 2008 Денис Черносов написал(a): >> Навеяно вот этой статьей и экспериментами с Ruby On Rails и >> вдохновением от wiki-технологий: >> >> http://www.calculate-linux.ru/%D0%9E%D1%80%D0%B3%D0%B0%D0%BD%D0%B8%D0%B7% >>D0%B0%D1%86%D0%B8%D1%8F_%D1%85%D1%80%D0%B0%D0%BD%D0%B5%D0%BD%D0%B8%D1%8F_% >>D1%84%D0%B8%D0%BB%D1%8C%D0%BC%D0%BE%D0%B2 >> >> Проблема: >> Чаще всего общие файлохранилища превращаются в файлопомойки, в которых >> даже хозяева файлов не могут разобраться. Это и перерасход места и >> потери рабочего времени на поиск и многочисленные дублирования со >> всеми вытекающими. Плюс целый букет проблем из области безопасности: >> трудности с настройками резервного копирования утечка корпоративных >> секретов, нелицензионный софт и пиратский медиаконтент и т.п. >> Отказ от файловых систем в пользу систем документооборота не всегда >> оправдан, поскольку накладывает достаточно много других ограничений и >> лишает традиционных преимуществ - понятность абстракции, высокое >> быстродействие и т.п. > > Прям постановка проблемы из текста моей диссертации, которую я бросил, > написав три главы и кусок кода. > >> Причины: >> 1) отсутствие общепринятых паттернов файловой иерархии для большинства >> случаев (включая соглашения об именовании файлов и каталогов и >> разделения доступа к ним). Их не предлагают по умолчанию в таких >> продуктах, как Samba или Nfs (примеры настройек для папок верхнего >> уровня не в счет - это просто специализация файлопомоек) и этому не >> учат ни в школах ни на курсах. Замкнутый круг - культуры нет, потому >> что её нет нигде. > > А вы представляете себе типовые паттерны на все случаи жизни с учетом > субъективности каждого пользователя ресурса? Если так, то вам, совершенно > определенно, можно выступать с семинарами по логической организации > корпоративных хранилищ данных. И это не шутка :) > >> 2) отсутствие автоматических средств для быстрой организации >> умолчальных деревьев каталогов, выставления прав на них, заполнения и >> актуализации метаинформации о содержимом каталогов, автоматическом >> перемещении, переименовании, удалении файлов и каталогов. Нет смысла >> обвинять пользователей в том, что они не хотят выполнять изо дня в >> день работу более подходящую для роботов. > > Тоже сильно похоже на кусок из моего диссера :) > >> При наличии формализованных соглашений, становится возможным создание >> скриптов на все случаи жизни (как это сделано в Ruby On Rails). >> Остается только один вопрос - как, не порождая новых сущностей (хотя >> бы на стороне клиента) и зависимостей реализовать это на базе samba, >> nfs, ftp. > > Нужно просто информационные ресурсы раскладывать по каталогам так, чтобы это > устраивало субъективность всех пользователей помойки. > >> Очевидно, через адресацию - несуществующий адрес воспринимается, как >> команда и при осмысленности этой команды и наличии достаточных прав на >> её выполнение - вуаля! >> Что интересно - можно прикручивать этот модуль для отработки именно >> несуществующих адресов, а это практически не повлияет на >> быстродействие системы в целом. А в качестве доп. вкусностей еще >> мечты: при наличии проблем, диагностическое сообщение (возможно с >> предугадываниями, типа "наверное вы хотели вот этого" и/или >> подсказками - "если хотите того, то начните сначала с этого"). > > Тут ничего не могу сказать.. Искусственный интеллект на уровне доступа к > данным я не рассматривал. Я предпочитаю использовать его на уровне > публикации ресурсов. > >> Что скажете? Баян? Утопия? > > Скажу, что такие вещи существуют. Обычно они входят в состав корпоративных > систем документооборота и стоят много денег. Простейший случай - > авторубрикаторы. Об их качестве ничего сказать не могу - не трогал. > > Я занимался частным случаем "помойки" для реализации хранилища документации. > Там попроще, поскольку внутри есть текст, который можно классифицировать. > > Берем "помойку", проводим частотный анализ текста в каждом документе, > выбираем N наиболее частоупотребимых слов в ресурсе (за исключением > стоп-слов) и подаем на вход кластеризатора (в моем случае - нейронная сеть > в режиме кластеризатора). Выходов у сети либо по количеству категорий, если > дерево категорий одноуровневое, либо некоторое фиксированное число > (например, 7), если категории могут быть вложенными (в этом случае, > кластеризация проводится несколько раз по количеству уровней в дереве). > Запоминаем, где был сигнал, подаем следующий документ. > > В результате, получаем соответствие документов, которые подавались на вход > кластеризатора, сигналам на его выходе (то есть, категориям). Обзываем > категории, ориентируясь на смысл сгруппированных документов, создаем > соответствующее дерево на файловой системе и раскладываем документы > соответствующим образом. > > Далее, нейронная сеть переключается в режим классификатора (отключаем > обучение). Новые документы заливаются в спул, там их подхватывает > классификатор, считает частотность и прогоняет ее через нейронку. По > результатам классификации, документы кладутся в нужный каталог. > Периодически (в зависимости от частоты появления новых документов) можно > проводить кластеризацию и сравнивать ее результаты с тем, что есть сейчас. > Как расхождение превысит некоторый лимит, переупорядочиваем структуру > каталогов и документов в них (благо, это можно делать автоматизированно). > > Вкратце, так. Но это все - чистая теория. Эксперименты я не провел. Поэтому, > вполне может оказаться, что документы, собранные кластеризатором в одну > категорию, на самом деле имеют очень мало общего. И для кластеризации > недостаточно учитывать только частотность слов, но еще придется учитывать > их взаимное расположение. Все это тащит за собой неслабый матаппарат, > который я не люблю :) > > Для случаев нетекстовой информации (фильмы, музыка, графика, ПО) эта схема > может быть использована по каким-либо метаданным (тегам, сопроводительным > файлам и т.д.). > > Это была моя утопия, от которой я когда-то отказался, потому что потерял > интерес к теме и занимался на тот момент совсем другими вещами. > Круто!!! Нет, серьезно! У меня были мысли попроще. 1) Интеллект на уровне создания ресурсов - безусловно епархия сис. админа и руководства. Прописывается в оф. документе и доводится до каждого. Ну, скажем, /{корзина,бухгалтерия,мультимедиа,шаблоны,home} 2) Первый шаг, он же паттерн, или соглашение: фиксированное <=7-9 жестко заданных каталогов верхнего уровня. Т.е. каталог верхнего уровня доступен на запись только админу и вложенные каталоги верхнего уровня создаются только по бумажке сверху. Которая также доводится до большинства. Как варианты: /{актуальное,архив}; /{2008,2007,..}; /{001,002,..}; /{достоверная информация, неполная информация,нужно уточнить}; /{man, howto,info,guide,book,..}; /{конфеденциальное, для интранета, на ftp}; /{самарский филиал,брянский филиал,..}; /{video,audio,games,soft}. Если основных проектов немного и все долгоиграющие, то можно их лепить на вершину. В автоматизации не нуждается ибо делается достаточно редко. В идеале - один раз. 3) Далее идут типовые паттерны для подкаталогов. Например, список ФИО из какой-то БД, номера от одного до N, даты в любом количестве и формате, список категорий (также из какой-то БД - это же можно в скрипте настроить). Общие какие-то параметры можно выделить: "создавать папку tmp","создавать папку arhiv", "чистить по расписанию", "чистить по маске" и т.п. Некоторые параметры будут выполняться немедленно, а другие сохранятся в .metadata и будут инструкцией для скрипта исполняемого по крону. Начать можно с самого малого и простого. 2-3 варианта. И выглядеть это должно как-то так: ---------------------- $ls /smb/srv/media/video . .. $cd /smb/srv/media/video/#create/mediapattern/Metallica/ $ls /smb/srv/media/video/Metallica/ . .. mpeg4/ dvd/ blue-ray/ readme.txt ----------------------- Т.е. хочется именно попроще - командовать через адресацию. А синтаксис команд максимально приблизить к вики-движкам и/или RoR. Сразу же возникает целый веер вопросов. Например, как будет себя вести команда: $cat /smb/srv/media/video/#create/mediapattern/Metallica/ Но это уже второй вопрос... > -- > С уважением, > Бушмелев Юрий > _______________________________________________ > community mailing list > community@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/community ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Comm] Мысль по поводу организации общего файлохранилища ( для обсуждения ) 2008-12-10 11:12 ` Денис Черносов @ 2008-12-10 11:26 ` Yuri Bushmelev 2008-12-10 11:49 ` Денис Черносов 0 siblings, 1 reply; 5+ messages in thread From: Yuri Bushmelev @ 2008-12-10 11:26 UTC (permalink / raw) To: ALT Linux Community general discussions В сообщении от Среда 10 декабря 2008 Денис Черносов написал(a): > 10 декабря 2008 г. 14:24 пользователь Yuri Bushmelev > 1) Интеллект на уровне создания ресурсов - безусловно епархия сис. > админа и руководства. Прописывается в оф. документе и доводится до > каждого. Ну, скажем, /{корзина,бухгалтерия,мультимедиа,шаблоны,home} В одной знакомой компании структура каталогов на, так называемых, "общих папках" регламентирована корпоративными стандартами. Сначала, вроде бы, даже наказывали за несоблюдение. Зато теперь - тишь и благодать. Все знают, где что лежит, и что самое главное - что куда класть. Так что, там обошлись организационными мерами. -- С уважением, Бушмелев Юрий ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Comm] Мысль по поводу организации общего файлохранилища ( для обсуждения ) 2008-12-10 11:26 ` Yuri Bushmelev @ 2008-12-10 11:49 ` Денис Черносов 0 siblings, 0 replies; 5+ messages in thread From: Денис Черносов @ 2008-12-10 11:49 UTC (permalink / raw) To: ALT Linux Community general discussions 10 декабря 2008 г. 15:26 пользователь Yuri Bushmelev <jay4mail@gmail.com> написал: > В сообщении от Среда 10 декабря 2008 Денис Черносов написал(a): >> 10 декабря 2008 г. 14:24 пользователь Yuri Bushmelev > >> 1) Интеллект на уровне создания ресурсов - безусловно епархия сис. >> админа и руководства. Прописывается в оф. документе и доводится до >> каждого. Ну, скажем, /{корзина,бухгалтерия,мультимедиа,шаблоны,home} > > В одной знакомой компании структура каталогов на, так называемых, "общих > папках" регламентирована корпоративными стандартами. Сначала, вроде бы, > даже наказывали за несоблюдение. Зато теперь - тишь и благодать. Все знают, > где что лежит, и что самое главное - что куда класть. Так что, там обошлись > организационными мерами. > Я еще не говорил, что перфекционизм хуже геморроя? Хочется "заглянуть за горизонт", помечтать... Вдруг найдутся единомышленники. А если серьезно, то это исключение из правил. Побольше бы таких исключений. Многие мелкие конторки до этого дорастают только тогда, когда весь рабочий состав сменился на четыре раза, ничего найти невозможно и размеры помойки просто пугают. Ну и про источники вдохновения я уже написал. Мне почему-то показалось, что возможность одной командой создать заготовленную структуру каталогов покорит сердца офисных работников. Ибо, как сказал какой-то линуксоид: "это дает ощущение могущества, а к могуществу привыкаешь быстро". > -- > С уважением, > Бушмелев Юрий > _______________________________________________ > community mailing list > community@lists.altlinux.org > https://lists.altlinux.org/mailman/listinfo/community ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2008-12-10 11:49 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-12-10 7:30 [Comm] Мысль по поводу организации общего файлохранилища (для обсуждения) Денис Черносов 2008-12-10 10:24 ` [Comm] Мысль по поводу организации общего файлохранилища ( для обсуждения ) Yuri Bushmelev 2008-12-10 11:12 ` Денис Черносов 2008-12-10 11:26 ` Yuri Bushmelev 2008-12-10 11:49 ` Денис Черносов
ALT Linux Community general discussions This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/community/0 community/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 community community/ http://lore.altlinux.org/community \ mandrake-russian@linuxteam.iplabs.ru community@lists.altlinux.org community@lists.altlinux.ru community@lists.altlinux.com public-inbox-index community Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.community AGPL code for this site: git clone https://public-inbox.org/public-inbox.git