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

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

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

Для поиска по дате теги не нужны. К тому же у фотоаппаратов часто бывает сбитое время, поэтому все фотографии могут оказаться с тегом „2001 год”. Поиск по дате вручную созданного каталога в этом случае имеет больше шансов на успех.

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

Место можно отразить в имени каталога, опять теги не особо нужны.
Опять-таки можно отразить в имени, например „Пьянка с Васей и Серёгой” или „Корпоратив с коллегами”. А отмечать каждого человека на каждой фотографии отдельно никакого терпения ни у кого не хватит. Получается что качество упорядочённости информации в любом случае зависит от пользователя, поэтому непонятно зачем нужно менять шило на мыло.

А можно и вынести в тэги (никаких свойств файлов, расширений, имён и т.д. — всё это тэги). Т.е. именно что разницы почти никакой, но решение получается более общее. А разница будет когда, например, ты захочешь посмотреть все фотки, сделанные в Праге, а год фото от 2005 до 2010. Мало ли, сколько раз ты бывал в Праге, едва ли ты захочешь изучать каждый альбом по отдельности. А если ещё и захочешь, чтобы на фото был Андрей, то просто добавишь ещё один фильтр, благодаря чему найдёшь нужное фото ещё быстрее. Касательно ручного добавления тэгов: лица сейчас распознаются автоматически (а ещё можно пользоваться функционалом социальных сетей…), место дописывается самим устройством. Захочешь поменять — выберешь группу фото и изменишь нужные тэги. Это не то же самое, что работать с каждым файлом по отдельности. Импортировал кипу фоток с фотоаппарата — этой же кипе и проставил нужные тэги.

Вот из-за такого подхода до сих пор и жопа с ФС.

Жопа с ФС — потому что все пытаются создать свой непереносимый велосипед разной степени кривизны вместо допиливания реализаций текущей концепции, у которой ещё есть потенциал.

Если абсолютно все файлы будут протегированы — поиск по тегах будет не быстрее обычного поиска по именам.

man СУБД.
man locate (mlocate/rlocate)
man любой приличный каталогизатор

И, таки, man поиск файлов по пути.

а ещё можно пользоваться функционалом социальных сетей

Кстати, да. Очень не хватает тэговой линковки локальных файлов и их удалённых копий у знакомых. Расставляет товарищ теги с мордами на фотках с пьянки, но локально у тебя они не появятся. Есть некие зачатки подобного только у Гугла с Пикасой, но и то лишь зачатки и только в одну сторону.

потому что все пытаются создать свой непереносимый велосипед разной степени кривизны вместо допиливания реализаций текущей концепции, у которой ещё есть потенциал.

«Реализация текущей концепции, у которой ещё есть потенциал» была и у MS-DOS FAT. Что не помешало перейти на длинные имена вместо допиливания descript.ion или files.bbs (хотя многие каталогизаторы и файловые менеджеры с таким форматом прекрасно работали, от ACDSee до 4dos и DOS Navigator).

Надоело кормить тебя.

Имхо, тут проблема глобальнее из-за разобщённости сервисов в интернетах и сильной разницы между облаком и локалхостом. Вот такую я простыню по этому поводу в своё время написал, вдруг интересно: ОС и сайты будущего [моё ИМХО]. Причём, мне кажется, разрулить проблему не сильно сложно, достаточно сделать свой а-ля андроид и договориться с держателями сервисов типа гугла, вк, фб и прочих. Собственно, владельцы сервисов сами интегрируют свои сервисы в планируемую систему при должной популярности этой системы. А глядя на успехи всяких там мобильных убунт, фф и прочих, думаю, шансы есть :)

Касательно ручного добавления тэгов: лица сейчас распознаются автоматически (а ещё можно пользоваться функционалом социальных сетей…), место дописывается самим устройством. Захочешь поменять — выберешь группу фото и изменишь нужные тэги.

Нужно добавить в ФС функцию распознавания лиц, и не надо будет морочиться с тегами.

Нужно добавить в ФС функцию распознавания лиц, и не надо будет морочиться с тегами.

Слишком толсто.

Никаких отличий от нынешней концепции в плане ухудшения: нельзя показать свалку — покажи ещё фильтры (тэги)

Вот есть у меня, например, 100К картинок. Сколько раз мне нужно будет выбирать теги пока оно не покажет мне хоть что-то? А если миллион?

Аналогично ты искал бы в иерархии каталогов

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

В конце концов, обычно на альбомы всё-таки разбивают

Т.е. без иерархии всё равно никуда не уедешь.

А вообще, сбитая дата — это уже какие-то быдлопроблемы, серьёзно. Таким людям можно совершенно спокойно вываливать свалку из фото без сортировки

А если фотоаппарат не мой?

А разница будет когда, например, ты захочешь посмотреть все фотки, сделанные в Праге, а год фото от 2005 до 2010

Поэтому я всегда называю свои каталоги с фотографиями по шаблону „место — год-месяц-число [— уточняющий комментарий]” и у меня таких проблем не бывает.

А если ещё и захочешь, чтобы на фото был Андрей, то просто добавишь ещё один фильтр, благодаря чему найдёшь нужное фото ещё быстрее. Касательно ручного добавления тэгов: лица сейчас распознаются автоматически (а ещё можно пользоваться функционалом социальных сетей…)

И всю эту информацию можно записать поверх существующей иерархии ФС, например, в тех же NTFS-потоках.

Это не то же самое, что работать с каждым файлом по отдельности. Импортировал кипу фоток с фотоаппарата — этой же кипе и проставил нужные тэги

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

Т.е. именно что разницы почти никакой

Так зачем платить больше?™

Что не помешало перейти на длинные имена

Хороший пример допиливания текущей концепции с сохранением совместимости.

Вот есть у меня, например, 100К картинок. Сколько раз мне нужно будет выбирать теги пока оно не покажет мне хоть что-то?

Picasa показывает 100К картинок сразу и без фильтрации.

Хороший пример допиливания текущей концепции с сохранением совместимости.

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

Надоело кормить тебя.

Аргументы закончились? Слив засчитан.

Вот есть у меня, например, 100К картинок. Сколько раз мне нужно будет выбирать теги пока оно не покажет мне хоть что-то? А если миллион?

Абсолютно та же проблема, что и с каталогами.

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

Тэги тоже создаёшь ты. Только вместо фиксированного формата у тебя информация по кускам. Не «место — год-месяц-число», а «место», «год», «месяц» и «число». И «альбом». Заметь, с каталогами у тебя нет выбора, либо «альбом», либо хитрый формат хранения, который тебе надо продумать заранее.

Т.е. без иерархии всё равно никуда не уедешь.

Разумеется. Вот только с заданной руками иерархией у тебя один фильтр выше другого, а тут смесь фильтров, логические «и» и «или» (нужность второго сомнительна, но всё же).

А если фотоаппарат не мой?

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

Поэтому я всегда называю свои каталоги с фотографиями по шаблону „место — год-месяц-число [— уточняющий комментарий]” и у меня таких проблем не бывает.

А потом ты понимаешь, что хер ты в этом найдёшь все фотки с Коляном (потому что в уточняющий комментарий все действующие лица не влезут в удобочитаемом формате).

И всю эту информацию можно записать поверх существующей иерархии ФС, например, в тех же NTFS-потоках.

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

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

Выделил эту кипу, проставил тэги (если тех, что уже есть, не хватает). Т.е. аналогично закидыванию в альбом.

Так и теговая система ничего не обязана ломать

ТС предлагает концепцию без иерархии.

Путь к файлу может быть просто атрибутом

Может. Остаётся вопрос с эффективным хранением этих атрибутов и производительностью на жёстких дисках.

Picasa показывает 100К картинок сразу и без фильтрации.

Но найти в них что-то без дополнительных фильтров всё равно невозможно.

Абсолютно та же проблема, что и с каталогами.

Только в случае каталогов лишь я решаю как будет организована каталогизация данных и оптимальное соотношение между количеством „вертикальных” и „горизонтальных” уровней, а в случае тегов придётся жрать что дают. К тому же непонятно каким образом различать файлы на разных устройствах, подключённых к компьютеру, тоже тегами? А если устройств больше одного, например несколько флешек и USB-винт с коллекцией?

смесь фильтров, логические «и»

Ссылки же.

Демагогия какая-то.

Вполне жизненная и довольно частая ситуация.

Пропиши свои даты тогда.

Мне достаточно сделать это всего один раз в имени каталога вместо поиска и выбора нужных файлов среди всех изображений 2001 года.

А потом ты понимаешь, что хер ты в этом найдёшь все фотки с Коляном

Увы, у меня пока ни разу такой потребности не было. Зачем мне смотреть фотки с Коляном?

Я сторонник ломания

Ломать — не строить.

вместо горождения костылей поверх устаревшего мусора

Это не костыли, это штатная функция ФС. На счёт устаревшего — тоже вопрос спорный, всё равно пока из работающего ничего лучшего нет.

ТС предлагает концепцию без иерархии.

ты пофиг уже на ТС.. :-)

уже всё обсудили и пришли к выводу что тэгирование это дополнительная функциональность (реализованния на низком уровне и в ФС (в дополнении к традиционной иерархии) и в прикладном софте)

только так можно сделать.

а если реализовать только в прикладном софте — то будут возникать мелкие неприятности (но кривенько\глючненько\тормознутенько это работать всёже сможет:))

уже всё обсудили и пришли к выводу что тэгирование это дополнительная функциональность (реализованния на низком уровне и в ФС (в дополнении к традиционной иерархии) и в прикладном софте)

только так можно сделать.

а если реализовать только в прикладном софте — то будут возникать мелкие неприятности (но кривенько\глючненько\тормознутенько это работать всёже сможет:))

Да, именно так.

а можно сделать в два этапа:

сначало реализовать только в прикладном софте (кривенько\глючненько\тормознутенько)... а потом каким-то образом договориться об API с разработчиками файловых систем, и уже реализовать тоже самое с поддержкой файловых систем.

вся проблема наверное и есть как раз «договориться» :-)

по карйней мере — реазилация внутри файловой системы — без прикладного софта — на мой взгляд вообще безполезное дело :-) .. первым делом надо прикладной софт: тегированные файловые манагеры, тегированный либре-офис, и т д :-)

кстате — по поводу прикладного софта — что это за хрень такая в Гноме? http://i2.minus.com/iJLYJtOtP58rT.png .. оно работает? :-)

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

Файловая система на основе тэгов (комментарий)

Но найти в них что-то без дополнительных фильтров всё равно невозможно.

Это подмена предмета спора (о производительности).

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

man СУБД.
man locate (mlocate/rlocate)
man любой приличный каталогизатор

кстате!

мы тут затронули «man», а ведь и с ним есть тоже интересный феномен(!), что касается каталогизации и поиска:

$ cat /etc/cron.daily/man-db 
#!/bin/sh

[...]

UPDATEMANDB="/usr/bin/mandb --quiet"

[...]

${UPDATEMANDB}

exit 0

я так понял что в почти каждом дистрибутиве есть (зачем-то?) этот cron-файл..

неуж-то по какой-то причине man не может работать без всей этой переиндексации %) %)..

Индексировать пути к файлам? А чем это лучше каталогов с индексом в реальном времени?

Это подмена предмета спора (о производительности).

Я говорил не только о производительности. Всё равно от всех 100К файлов перед глазами пользы мало.

Но найти в них что-то без дополнительных фильтров всё равно невозможно.

Кстати, тут возникает интересный момент — как именно представить пользователю выбор тегов если их много? Вываливать весь список-простыню не вариант, вводить вручную — долго и есть вероятность ошибки. Можно использовать автодополнение, но мышкой накликать путь в ФМ всё равно быстрее получается. Разве что вводить иерархию тегов подобно иерархии каталогов, но и здесь количество элементов на горизонтальном уровне может быть слишком велико.

в мак оси теперь есть это

А есть живые люди, кто этим пользуется? Выше уже отписавались, и я тоже применение этой фишке не нашёл.

все уже давно есть, просто кто-то пишет херню на лоре вместо полезного кода. так и живем :(

Вышла новая версия LFS

Apple все уже давно придумала и реализовала: http://en.wikipedia.org/wiki/Newton_(platform)#Data_storage

Эта система вполне себе работала и не тормозила, пока её не убил Джобс вместе со всем PDA-подразделением.

У него в ФС вместо дерева — граф?

А кто будет забивать все эти теги? Пользователь? Он может добавить два тега — „изображение” и „скан”, а потом забыть и безуспешно искать его среди документов. К тому же ему нужно задавать и помнить как можно больше тегов, иначе потом он среди гор всего остального мусора никогда ничего нужного не найдёт.

Это, конечно, главная проблема. Однако часть тегов можно добавлять автоматически - по типу файла, по источнику (с камеры - фото, со сканера - скан), из метаинформации, естественно.

Это указывается в момент создания папочки „Фотографии с шашлыков 2013 года”.

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

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

А теперь после этого выбери фотографии 2013 года, на которых есть я или моя мама

Это оторванный от реальности юзкейс.

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

Когда я Пикасу запускаю, она по дефолту выдаёт сразу все мои 53 тыс. фоточек. И не чихнёт.

Дело не в том, что не может, а в том, что неудобно. Файлы затем и бьют на подкаталоги, чтобы «группировать».

На практике в 99% случаев людей интересует набор фотографий, сделанных в конкретном месте и в конкретное время, например, „пьянка на днюхе у Васи 2014” или „отпуск 2013 в Зажопинске”.

Да ладно? Я вот недаво показывал родителям фото за 2013 год. Выбрал год, выбрал рейтинг, выбрал где я есть обязательно. И включил слайд шоу.

Пользователь проставит, если он работает с библиотекой. У меня стоит много что из того, что надо. Да и лица сам определит, год записан, гео информация есть. Еще пара простых движений в GUI и остальная информация появляется

А есть живые люди, кто этим пользуется? Выше уже отписавались, и я тоже применение этой фишке не нашёл.

Немного есть. Надо, чтоб софт подтянулся

Но это частный случай, конечно. Из-за отсутствия теговой функциональности в ФС, работает только внутри конкретной программы.

Apple решили проще. У них есть возможность выбирать объекты в диалоге выбора файлов прямо из библиотек. А уж софту они шлют пути.

Чего вы переливаете из пустого в порожнее?

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

А вот зачем портить ФС? теги для не медиа файлов чуть более чем бесполезны, т.к. достаточно имени, даты и пути.

т.к. достаточно имени, даты и пути

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

Уже сейчас можно положить в корень ФС файл registry.db (sqlite3) и заносить туда теги и пр. информацию. Как раз для оценки на сколько каждого из вас хватит заносить туда инфу на каждый чих, делать запросы, и тд.

http://en.wikipedia.org/wiki/Logic_File_System

На ЛОРе успели обсудить лет пять назад.

инфу на каждый чих

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

namazu и прочие полнотекстовые поиски уже есть

У него в ФС вместо дерева — граф?

Нет. Он говорил, что всякий раз, когда формируется уровень над файловой системой (в виде БД), это свидетельствует лишь о том, что файловая система не отвечает нашим потребностям. И что при правильной ФС лишние прослойки не нужны.

Дело не в том, что не может, а в том, что неудобно

Очень удобно. Несравнимо удобнее просмотра по отдельным каталогам в других менеджерах.

А вот зачем портить ФС? теги для не медиа файлов чуть более чем бесполезны

Так никто не заставляет прописывать теги для каждой .so (хотя тоже много служебной информации можно бы было из заголовка файла в теги перенести, всякие исправления при перелинковках находились бы без пересканирования, а одним запросом и т.п.)

Тут бы для медиафайлов унифицированную систему тегов — это огромный шаг бы вперёд был. Задал запрос «Royal Republic», получил всю музыку, видео, фоточки и заметки. Разве плохо? Попробуй сейчас вывести в своей коллекции все фильмы, в которых снимался, скажем, Олег Янковский.

Уже сейчас можно положить в корень ФС файл registry.db (sqlite3) и заносить туда теги и пр. информацию

И что делать, когда ты переименуешь файл или перекинешь на другой раздел?

Вот если бы ФС поддерживала такую мелочь — это реально был бы огромный скачок вперёд. У меня половина всяких вручную организуемых каталогов упростилась бы. Раз — и у меня одним запросом список RAW'ов, сделанных с нужным ISO, нужной выдержкой и нужной температурой для использования в качестве dark'ов при астрофото. А сейчас приходится городить костыли с симлинками.

Возможно ли на уровне ФС (обозначенной архитектуры) делать выборки аналогичные тем, что в SQL? По удобству и по скорости?

На ЛОРе успели обсудить лет пять назад.

Да каких 5, как минимум более 10 лет:
«Storage» - будущее файловых систем?