Файловая система на основе тэгов

Это ПО давно есть и всем доступно.

А какое ПО, простите? Совсем не в курсе.

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

А какое ПО, простите? Совсем не в курсе.

Про узнавание лиц в Picasa выше в теме уже писали. Теггированием музыки при недостатке исходных данных неплохо занимается Musicbrainz (под Linux я использую Picard). Симлинки для видео (жанры/года/люди/рейтинги) у меня расставляет вообще самописный скрипт. Аналогично расставляются служебные симлинки по EXIF-данным фотографий для материалов астрофото. И т.д.

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

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

Зато также, как и тогда, отпадёт надобность в ряде костылей. И появится намного больше возможностей.

Без конкретики это тяжело комментировать. Но скорее не согласен.

Да, потенциально искать будет легче, и это единственная фича. Правда пока что не придумали удобный интерфейс. Более того, скорее всего понадобятся дополнительный костыли, так как с этими сущностными нужно работать. Так что количество костылей не уменьшится, а увеличится. ИМХО,

Без конкретики это тяжело комментировать.

Конкретики было полно уже. Как мне без костылей и пересканирований получить список фильмов с участием Олега Янковского? Список RAW, снятых с ISO 1600 при температуре 28°C? Список музыки в жанре Rock, которую я не слушал больше года?

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

Ага. Как и единственная фича длинных имён перед 8.3 — возможность указать длинное имя. При чём для длинных имён тоже не было удобных интерфейсов.

Так что количество костылей не уменьшится, а увеличится. ИМХО,

Было бы интересно посмотреть, что бы б ты писал в 1995-м про LFN :)

Конкретики было полно уже. Как мне без костылей и пересканирований получить список фильмов с участием Олега Янковского? Список RAW, снятых с ISO 1600 при температуре 28°C? Список музыки в жанре Rock, которую я не слушал больше года?

Если ты правильно назвал файл/каталог - обычным find. В последнем кейсе - по дате обращения. В некоторых случаях (как в случае RAW) если ты не хочешь называть файлы/каталоги, find + show_meta + grep - однострочник легко решит проблему.

Было бы интересно посмотреть, что бы б ты писал в 1995-м про LFN :)

Без «бы»: я достаточно давно общаюсь с компьютером. Я эту фичу очень приветствовал.

Если ты правильно назвал файл/каталог - обычным find

Как мне найти обычным find фильмы с участием Олега Янковского?

В некоторых случаях (как в случае RAW) если ты не хочешь называть файлы/каталоги, find + show_meta + grep - однострочник легко решит проблему.

Вот это всё и есть страшные костыли.

Без «бы»: я достаточно давно общаюсь с компьютером. Я эту фичу очень приветствовал.

Тогда странно, что тебе не нравится идея DBFS. При минимальных затратах можно получить несравнимо больше возможностей, чем дал уход с 8.3

Как мне найти обычным find фильмы с участием Олега Янковского?

В названии файла укажи.

В некоторых случаях (как в случае RAW) если ты не хочешь называть файлы/каталоги, find + show_meta + grep - однострочник легко решит проблему.

Вот это всё и есть страшные костыли.

То есть Nepomuk, Beagle или какой-то монстроидальный просмотрщик фото - это не костыли, а однострочник - костыль???

Я тебе больше скажу: я вот тоже общался с товарищами, которые расхваливали поиск фотографий «с ISO 1600 при температуре 28°C». Так вот за рюмкой чая они потом признавали, что это требуется раз в пятилетку. Так что нужно смотреть не только на возможности, но и на восстребованоть.

Тогда странно, что тебе не нравится идея DBFS

Мне идея нравится, но не в том виде, в котором она сейчас представляется. Нельзя совсем уходить от древовидной структуры. Это должна быть надстройка, такой себе «универсальный язык метаданных», чтобы не иметь свой костыль для mp3, свой для jpeg и т. п. И работать максимально стандартными средствами. Самое близкое что есть - расширенные атрибуты. Но, к сожалению, мало инструментов с ними умеют работать. В основном только CLI утилиты; даже тот же mc не копирует их, я уже не говорю о других «продвинутых» инструментах. Я, кстати, под этому поводу создал feature request для mc, воз и ныне там: https://www.midnight-commander.org/ticket/2468 (проголосуй, что ли).

В названии файла укажи

А ещё десятки других людей, жанры, года, оценки, страны... Длины-то имени в ФС хватит на такой мегакостылище? :D

То есть Nepomuk, Beagle или какой-то монстроидальный просмотрщик фото - это не костыли, а однострочник - костыль???

Всё перечисленное — костыли, компенсирующие недостаток ФС.

Так вот за рюмкой чая они потом признавали, что это требуется раз в пятилетку

А кому-то и 8.3 хватало по уши и кто-то длинные имена и сейчас раз в пятилетку использует. И что?

Так что нужно смотреть не только на возможности, но и на восстребованоть.

Всё перечисленное мной востребовано часто. Я в теме подробно расписывал. А то, что кому-то это не нужно — так многим и длинные имена не нужны. И уж точно мало кому сегодня нужна сортировка по каталогам.

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

1. Никто не заставляет уходить от дерева. Сколько раз уже в теме было, что путь вполне может быть таким же атрибутом?

2. Дерево — это очень убогая и ограниченная структура. Позволяет разложить только по одному классификатору не допускающему множественность родителей. Вот я делаю сейчас материал по китайскому вертолёту Z-19. Куда его класть? В /countrues/china/z-19? /companies/harbin/z-19? /helicopers/military/china/z-19?

Любой реальный объект имеет массу способов классификации. Дерево позволяет осуществить только один из способов. Что делать с остальными?

Это должна быть надстройка, такой себе «универсальный язык метаданных», чтобы не иметь свой костыль для mp3, свой для jpeg и т. п.

Ну так о том спор с самого начала и идёт. Что нужна такая система.

Самое близкое что есть - расширенные атрибуты.

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

Но, к сожалению, мало инструментов с ними умеют работать.

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

Всё перечисленное — костыли, компенсирующие недостаток ФС.

Нет. nepomuk и лбая DBFS- это КОСТЫЛЬ, а однострочник - это... это просто рабочий инструмент. Или ты все однострочники костылями называешь?

А ещё десятки других людей

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

И что?

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

Дерево — это очень убогая и ограниченная структура. Позволяет разложить только по одному классификатору

Есть линки.

материал по китайскому вертолёту Z-19. Куда его класть?

Определи теги. Соедини их в путь, и все равно в каком порядке. А далее ты легко найдешь его по find.

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

find . По имени можно, по дате, атрибутам... аналогично - по xattr.

Как об стенку горох. Ладно, проехали.

Попробуй формализовать то, о чём ты говоришь.

Что такое метки? Ты говорил о классификации и метки по сути это действительно именно классификация. Но что такое классификация? По большому счёту, это одна из основных функций нервной системы, таковых всего две: распознавание и классификация. Но на практике классификацию можно классифицировать на два вида: хорошая и плохая. Пример плохой нам, как известно, приводит Борхес. Хорошая-же, это по видимому та, которая приносит ту или иную пользу.

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

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

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

Надеюсь это достаточно формально? :)

Надеюсь это достаточно формально? :)

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

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

Это было много букв.

Это было художественное описание механизма. Или ты думаешь что у меня в рукаве расшифровка структуры? Тогда я бы не тут трепался.

И, да, конечно «в этом нет ничего нового, ибо вообще ничего нового нет». В природе есть эволюция и нет революций.

А вообще мы говорим о разных путях развития. Экстенсивном и интенсивном.

А вообще мы говорим о разных путях развития. Экстенсивном и интенсивном.

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

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

Сначала я хотел написать что реальность нас рассудила, одинаково не реализовав ни один случай. Но потом вспомнил про BeFS.

Кстати, а почему ты её не используешь? Ну да, линукс, и прочая гетерогенная сеть, но представим себе сферический NAS в вакууме. С болтом^W гайкой внутри. И волшебная DBFS^W BeFS расшаривается со всеми своими возможностями?