Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 348
Ожидалось, что WinFS станет именно такой системой. Жаль, забросили.
ну скорее не забросили а не осилили :) это как у американцев были разработки оружия где пули бы изготавливались из подручного мусора: затраты на использование не окупаются.
Я думаю всё-таки именно забросили.
Суть в том, что «дерев каталогов и возможность делать ярлыки» это то, что среднестатистический пользователь может осилить умом.
теперь вот появились Библиотеки в которых можно смотреть контент из разных папок.
глупо разрабатывать WinFS, если даже все возможности NTFS — непосильная тяжесть для большинства пользователей.
замороченные файловые системы нужны только Вам, мне и %username%
Суть в том, что «дерев каталогов и возможность делать ярлыки» это то, что среднестатистический пользователь может осилить умом.
теперь вот появились Библиотеки в которых можно смотреть контент из разных папок.
глупо разрабатывать WinFS, если даже все возможности NTFS — непосильная тяжесть для большинства пользователей.
замороченные файловые системы нужны только Вам, мне и %username%
но теги-то в висте появились…
С одной стороны, вы правы — главной особенностью, приведшей к такой популярности компьютеров, явилась их возможность хранить, передавать, обеспечивать доступ к гигантским и недоступным до этого объёмам информации. Нужно этот доступ сделать удобным.
С другой стороны, само понятие удобства очень различается для разных людей. Мне, например, ужасно неудобно, когда данные лежат «по тегам», я везде пытаюсь их организовать в иерархию — даже в системах, которые изначально не предполагают иерархического строения. (Поэтому же мне не нравятся и форумы типа phpbb, но нравится phorum и организация комментариев на хабре ;).
И меня в этом смысле больше всего устраивает именно иерархическая структура файловых систем. Её неплохо бы дополнить механизмом тегов для ускорения некоторых отдельных операций, но нельзя заменить этим механизмом.
Вообще-то, лет пять назад были шумные слухи про WinFS. Это примерно то, о чём вы пишете — теги с частичной автоматизацией, MS SQL Server Lite для индексирования, NTFS как бэк-энд. С другой стороны, я видел немало попыток сделать такую штуку на базе fuse (напр. tagsistant). Тот факт, что все эти проекты находятся в зачаточной стадии, заморожены или заброшены, уже косвенно намекает на то, что в массе пользователю всё это не нужно…
С другой стороны, само понятие удобства очень различается для разных людей. Мне, например, ужасно неудобно, когда данные лежат «по тегам», я везде пытаюсь их организовать в иерархию — даже в системах, которые изначально не предполагают иерархического строения. (Поэтому же мне не нравятся и форумы типа phpbb, но нравится phorum и организация комментариев на хабре ;).
И меня в этом смысле больше всего устраивает именно иерархическая структура файловых систем. Её неплохо бы дополнить механизмом тегов для ускорения некоторых отдельных операций, но нельзя заменить этим механизмом.
Вообще-то, лет пять назад были шумные слухи про WinFS. Это примерно то, о чём вы пишете — теги с частичной автоматизацией, MS SQL Server Lite для индексирования, NTFS как бэк-энд. С другой стороны, я видел немало попыток сделать такую штуку на базе fuse (напр. tagsistant). Тот факт, что все эти проекты находятся в зачаточной стадии, заморожены или заброшены, уже косвенно намекает на то, что в массе пользователю всё это не нужно…
Массового пользователя очень приучили к папкам. Переучить сразу практически невозможно. Но, я думаю, когда поток информации станет сбивать с ног, такая организация хранения данных станет востребована.
В онлайне-же такие системы имеют успех.
В онлайне-же такие системы имеют успех.
Не знаю, меня вот приучили к иерархии. В файловой системе это директории; в dokuwiki — пространства имён; в программировании — те же пространства имён, интерфейсы, классы; в природе — генеалогическое дерево, филогенетическое дерево, кварк-нуклон-ядро-атом-молекула-вещество-органелла-клетка-орган-организм-общество; в обществе — социальная иерархия, начальники, начальники начальников и президент; в технике — системы, надсистемы, подсистемы (пример, соответственно: автомобиль, личный транспорт, двигатель; а у них — свои под- и над-системы: у двигателя — подсистема цилиндры, у личного транспорта — надсистема транспорт). В
Иерархии — везде и всюду, они естественны; зато ваших «тегов» в природе нет.
Человек так устроен, что наиболее естественно и просто понимает именно природные структуры, и всё, созданное им, так или иначе моделирует окружающий мир. Например, парадигма программирования, которая тоже привела к популярности компьютеров — это ООП, которая фактически предлагает строить иерархию классов и объектов.
Область классификации информации — не исключение. Здесь тоже естественна иерахия.
Иерархии — везде и всюду, они естественны; зато ваших «тегов» в природе нет.
Человек так устроен, что наиболее естественно и просто понимает именно природные структуры, и всё, созданное им, так или иначе моделирует окружающий мир. Например, парадигма программирования, которая тоже привела к популярности компьютеров — это ООП, которая фактически предлагает строить иерархию классов и объектов.
Область классификации информации — не исключение. Здесь тоже естественна иерахия.
Теги это тоже иерархия и классификация, просто не исключающая связи многие ко многим.
Не предлагайте отказываться от традиционной иерархии. Она, к слову сказать, далеко не сразу появилась — первые ОС не знали такого понятия, как «иерархическая файловая система», я как-то сталкивался с такой системой MSX.
Предложите, как можно естественно вписать теги в иерархическую структуру. Идеальный результат примерно такой: у каждого объекта видим ровно одного родителя (не больше и не меньше, исключение — корневой объект, нет родителя); но видим также горизонтальные связи между объектами, в которых объединение происходит по наличию сходных признаков (тегов).
В ФС придётся добавить не только концепцию похожести (тегов), но и концепцию соответствующих связей между объектами. Ваша ошибка заключается втом, что вы, вместо того, чтобы добавить эти новые связи естественным образом (да, это очень сложно, это-то и есть главная проблема!) пытаетесь полностью исключить старые, и заменить их новыми.
Предложите, как можно естественно вписать теги в иерархическую структуру. Идеальный результат примерно такой: у каждого объекта видим ровно одного родителя (не больше и не меньше, исключение — корневой объект, нет родителя); но видим также горизонтальные связи между объектами, в которых объединение происходит по наличию сходных признаков (тегов).
В ФС придётся добавить не только концепцию похожести (тегов), но и концепцию соответствующих связей между объектами. Ваша ошибка заключается втом, что вы, вместо того, чтобы добавить эти новые связи естественным образом (да, это очень сложно, это-то и есть главная проблема!) пытаетесь полностью исключить старые, и заменить их новыми.
Все же, безболезненно исключить связи старые (иерархические) — возможно. Представьте ФС, основанную на реляционной либо постреляционной БД. В таком случае, объекты могут быть связаны, теоретически, различным образом. Четкую иерархию возможно построить и на такой ФС, но в то же время она будет гибка и заточена под указанные выше нужды.
Подвижки в этом деле уже были. BeFS вроде БД из себя представляет. Ну и мечты о «Единой среде» Фримана в том же направлении развивались\развиваются.
Подвижки в этом деле уже были. BeFS вроде БД из себя представляет. Ну и мечты о «Единой среде» Фримана в том же направлении развивались\развиваются.
Зато пользоваться такой системой для чего-либо, кроме упорядочивания фотографий, будет нельзя. И даже для фотографий не совсем удобно будет (например, у меня ключевой критерий классификации фотографий — дата, т.к. это единственный отличительный признак, который есть абсолютно у них у всех). Мне теги нужны как помощь, но неприемлемы как замена.
Здесь нет ни слова о тегах, есть много слов о базе данных. =) Дата — всего лишь одно из полей, по которому можно производить поиск.
Согласен с рассуждениями. Считаю, что рациональное зерно есть также и в мяслях автора по поводу тегов.
Мой вывод: теги должны быть иерархическими.
Это примерно (очень примерно) эквивалентно хорошей структуре папок на винчестере, где файл всегда лежит в нужном месте, причём в других соответствующих папках на этот файл идут символические ссылки.
Скажу больше: я попытался реализовать систему иерархических тэгов для упорядочивания информации на сайте. Это действительно упростило поиск _нужных_ данных в разы. При этом, к сожалению, стал несколько более сложным интерфейс.
И всё же, я уверен что за этим будущее.
Мой вывод: теги должны быть иерархическими.
Это примерно (очень примерно) эквивалентно хорошей структуре папок на винчестере, где файл всегда лежит в нужном месте, причём в других соответствующих папках на этот файл идут символические ссылки.
Скажу больше: я попытался реализовать систему иерархических тэгов для упорядочивания информации на сайте. Это действительно упростило поиск _нужных_ данных в разы. При этом, к сожалению, стал несколько более сложным интерфейс.
И всё же, я уверен что за этим будущее.
безболезненно — нельзя. мне будет больно.
мне будет трудно быть уверенным в результате по запросу, если ФС может выдавать результат как объекты, которые теоретически могут быть связаны различным, неизвестным мне способом. =)
> Все же, безболезненно исключить связи старые (иерархические) — возможно. Представьте ФС, основанную на реляционной либо постреляционной БД. В таком случае, объекты могут быть связаны, теоретически, различным образом. Четкую иерархию возможно построить и на такой ФС, но в то же время она будет гибка и заточена под указанные выше нужды.
Чуствую, что пользователь, пользуясь такой ФС, в первую очередь сделает теги, по смыслу аналогичные именам директорий. И объединит файлы именно по такому признаку. Ну чтобы знать, где что лежит. В результате вы опять получите обычную иерархическую ФС, но сделанную на основе тегированной ФС :)
Чуствую, что пользователь, пользуясь такой ФС, в первую очередь сделает теги, по смыслу аналогичные именам директорий. И объединит файлы именно по такому признаку. Ну чтобы знать, где что лежит. В результате вы опять получите обычную иерархическую ФС, но сделанную на основе тегированной ФС :)
> пример, соответственно: автомобиль, личный транспорт, двигатель; а у них — свои под- и над-системы: у двигателя — подсистема цилиндры, у личного транспорта — надсистема транспорт
> кварк-нуклон-ядро-атом-молекула-вещество-органелла-клетка-орган-организм-общество
Это не иерархия, а устройство. Не путайте.
Дом не надсистема над кирпичами и цеметном, он из них сделан.
> кварк-нуклон-ядро-атом-молекула-вещество-органелла-клетка-орган-организм-общество
Это не иерархия, а устройство. Не путайте.
Дом не надсистема над кирпичами и цеметном, он из них сделан.
Целое состоит из своих частей. Это «иерархия», которая в случае автомобиля называется «устройство». Короче, устройство — это частный случай иерархии.
В смысле, как бы-да :)
Хех :) что же вы так. В суть понятия надо проникать, а не поверхностно «на примерах» рассматривать ;)
Я все равно в сути не согласен.
Устройство автомобиля и принцип хранения информации — это разные вещи.
Но раз уж я дал ссылку на формальное определние то вынужден признать, что формально вы правы.
Устройство автомобиля и принцип хранения информации — это разные вещи.
Но раз уж я дал ссылку на формальное определние то вынужден признать, что формально вы правы.
Здесь не идёт речь о формализме. Я просто вижу, что ПО СУТИ устройство какого-либо механизма — иерархично, «по уровням» — колесо состоит из деталей, само является деталью подвески, которая тоже является деталью автомобиля. Мне для установления связи «иерархия»-«устройство» не нужно строить явное определение, типа того, которое есть в википедии, и искать там подходящий пример из списка; тем более, что я сам способен легко построить подходящее определение понятию.
Это не формализм, как раз наоборот. И прав я в данном случае не формально, а как раз наоборот ;)
Кстати говоря, вот вам и пример — вам самому сейчас потребовалось воспользоваться иерархией. Вы и сами не заметили. Для того, чтобы связать эти два понятия (иерархия и устройство), вам потребовалось определение — описание этих понятий в более абстрактных терминах, то есть, вы поднялись на ступеньку, на уровень иерархии абстракций.
От такой ступенчатой иерархической структуры вы никуда не уйдёте. Она встроена в природу человека.
Это не формализм, как раз наоборот. И прав я в данном случае не формально, а как раз наоборот ;)
Кстати говоря, вот вам и пример — вам самому сейчас потребовалось воспользоваться иерархией. Вы и сами не заметили. Для того, чтобы связать эти два понятия (иерархия и устройство), вам потребовалось определение — описание этих понятий в более абстрактных терминах, то есть, вы поднялись на ступеньку, на уровень иерархии абстракций.
От такой ступенчатой иерархической структуры вы никуда не уйдёте. Она встроена в природу человека.
Ваши доказательства субъективны. И линия доказательства вашей правоты верна только для вашего мироощущения.
Мне вот например иерархические структуры неприятны и постоянно ставят меня в тупик. Я хочу уйти от них.
Могу-ли я использовать это как аргумент? Нет. И если не лезть в википедию и не брать формальное определение иерархии, то я не согласен, с тем что устройство автомобиля — иерархическая структура. Одни и те-же детали могут быть использованы в разных узлах. А кварк может стать частью любой молекулы. В жесткой иерархии путь вниз и вверх всегда известен.
Мне вот например иерархические структуры неприятны и постоянно ставят меня в тупик. Я хочу уйти от них.
Могу-ли я использовать это как аргумент? Нет. И если не лезть в википедию и не брать формальное определение иерархии, то я не согласен, с тем что устройство автомобиля — иерархическая структура. Одни и те-же детали могут быть использованы в разных узлах. А кварк может стать частью любой молекулы. В жесткой иерархии путь вниз и вверх всегда известен.
Это и есть суть иерархии. Мы берём кирпичики, и строим из них объекты, которые сами потом используем как кирпичики.
Для этого-то иерархия и потребовалась — чтобы вывести свойства миллиардов объектов из небольшого количества правил — из нескольких кирпичиков и правил обращения с ними. Меньше правил — легче жить.
И успех очевиден — вместо рассмотрения отдельных липы, дуба, клёна и сосны, мы можем сказать слово «дерево» — и это очень упрощает, например, подсчёт. Именно этим мы отличаемся от индейцев — у нас есть абстракция «дерево». Общество не развилось бы до современного состояния, если бы у него был только язык индейцев.
Да и вообще, если вглядеться — все успехи человечества на поприще исследования природы связаны с улучшением и уточнением иерархической систематизации. Причём, не только природы «естественной», а и «гуманитарной» — посмотрите на устройство книги, журнала, статьи, рассказа. Там всё состоит из частей, которые состоят из глав, которые состоят из абзацев, которые состоят из строк, которые состоят из знаков. И наиболее прогрессивные языки добавляют уровень иерархии — строки состояит из слов, которые состоят из знаков (букв), а менее прогрессивные — теряют его, слова сами являются знаками.
Для этого-то иерархия и потребовалась — чтобы вывести свойства миллиардов объектов из небольшого количества правил — из нескольких кирпичиков и правил обращения с ними. Меньше правил — легче жить.
И успех очевиден — вместо рассмотрения отдельных липы, дуба, клёна и сосны, мы можем сказать слово «дерево» — и это очень упрощает, например, подсчёт. Именно этим мы отличаемся от индейцев — у нас есть абстракция «дерево». Общество не развилось бы до современного состояния, если бы у него был только язык индейцев.
Да и вообще, если вглядеться — все успехи человечества на поприще исследования природы связаны с улучшением и уточнением иерархической систематизации. Причём, не только природы «естественной», а и «гуманитарной» — посмотрите на устройство книги, журнала, статьи, рассказа. Там всё состоит из частей, которые состоят из глав, которые состоят из абзацев, которые состоят из строк, которые состоят из знаков. И наиболее прогрессивные языки добавляют уровень иерархии — строки состояит из слов, которые состоят из знаков (букв), а менее прогрессивные — теряют его, слова сами являются знаками.
А чем это противоречит классификации тегами?
Я не говорю, что противоречит. У кварков есть цвет, аромат, заряд, масса — это, если угодно, их теги.
Я говорю про то, что иерархию невозможно исключить, от неё нельзя отказаться. Её можно расширить.
Я говорю про то, что иерархию невозможно исключить, от неё нельзя отказаться. Её можно расширить.
Позволю себе не согласится. Иерархия — искусственна, и удобна только чтобы классифицировать. Вспомните, как вы выбираете (или указываете на) объекты в реальном мире:
— Где твоя машина? Вон (красная), (возле грузовика).
— Помоги вспомнить песню: (Наша), (мужик поет), что-то про любовь
Не могу вспомнить не одного примера, чтобы я в разговоре использовал иерархию.
П.С. Мне легче понять, что общество, как и атом (можно поделить), чем то, что общество состоит из кварков.
— Где твоя машина? Вон (красная), (возле грузовика).
— Помоги вспомнить песню: (Наша), (мужик поет), что-то про любовь
Не могу вспомнить не одного примера, чтобы я в разговоре использовал иерархию.
П.С. Мне легче понять, что общество, как и атом (можно поделить), чем то, что общество состоит из кварков.
В реальном мире я указываю на объекты, описывая их. При этом, я пользуюсь абстракциями: не «Ford Focus», а «машина», не «MAN что-то-там», а «грузовик» и т. п.
Это — иерахия, иерархия абстракций. Ею пользуется каждый, постоянно, и не задумываясь. Это она привела общество к современному виду.
Это — иерахия, иерархия абстракций. Ею пользуется каждый, постоянно, и не задумываясь. Это она привела общество к современному виду.
Делаю громкое заявление: Человек не способен построить иерархию, не разделив объекты по признакам (проставив теги).
Взять биологию: До сих пор вносят изменения в иерархию Линнея, это показывает, что для построения иерархии требуются усилия. Было бы интересно проследить историю появления иерархий в истории человечества.
Взять биологию: До сих пор вносят изменения в иерархию Линнея, это показывает, что для построения иерархии требуются усилия. Было бы интересно проследить историю появления иерархий в истории человечества.
Точно, теги — сходные признаки — нужны для классификации. Правда, некоторые иерархии возникают по-другому — например, атомные ядра, нуклоны и кварки появлялись как математические абстракции.
Но потом появилась иерархия этих самых признаков. Она обеспечила помимо группировки объектов ещё и их упорядочивание.
Но потом появилась иерархия этих самых признаков. Она обеспечила помимо группировки объектов ещё и их упорядочивание.
Согласен полностью с иерархией тэгов.
Не в целях рекламы, а в целях обмена опытом, хочу сказать, что в своё время сделал сравнительно универсальный движок сайта для хранения и поиска информации по набору иерархических тэгов. Любой информации, любой тематики.
Будет интересно — скину адрес для посмотреть.
В этом направлении, кстати, сейчас движутся Маркет.Яндекс, сами того не зная. )
Так вот, самое главное: работа с иерархическими тэгами оказалась слегка тяжёлой для рядового пользователя. Здесь бы скорее обсудить формы их представления для юзера. Вот это действительно большой вопрос.
Не в целях рекламы, а в целях обмена опытом, хочу сказать, что в своё время сделал сравнительно универсальный движок сайта для хранения и поиска информации по набору иерархических тэгов. Любой информации, любой тематики.
Будет интересно — скину адрес для посмотреть.
В этом направлении, кстати, сейчас движутся Маркет.Яндекс, сами того не зная. )
Так вот, самое главное: работа с иерархическими тэгами оказалась слегка тяжёлой для рядового пользователя. Здесь бы скорее обсудить формы их представления для юзера. Вот это действительно большой вопрос.
>В реальном мире я указываю на объекты, описывая их. При этом, я пользуюсь абстракциями: не «Ford Focus», а «машина», не «MAN что-то-там», а «грузовик» и т. п.
Вот именно, что описывая, а не классифицируя. Вы оперируете признаками объекта, а не его точным местоположением в определённой иерархии.
К примеру, если Вас спросят «какая у Вас рыбка в аквариуме», Вы скорее всего скажете «золотая рыбка: такая оранжевая с полупрозрачным хвостом и плавниками». Я очень сильно сомневаюсь, что Вы скажете что-то вроде «Царство: Животные, Тип: Хордовые, Подтип: Позвоночные, Надкласс: Рыбы, Класс: Костные рыбы, Отряд: Карпообразные, Семейство: Карповые, Род: Караси, Вид: Золотая рыбка» %)
Так и с файлами: я хочу «фотки», «из Штатов», «июль 2009», а не "/home/mikhail/data/pics/photos/2009/2009.07.01. Поездка в Штаты/*.jpg" :)
Вот именно, что описывая, а не классифицируя. Вы оперируете признаками объекта, а не его точным местоположением в определённой иерархии.
К примеру, если Вас спросят «какая у Вас рыбка в аквариуме», Вы скорее всего скажете «золотая рыбка: такая оранжевая с полупрозрачным хвостом и плавниками». Я очень сильно сомневаюсь, что Вы скажете что-то вроде «Царство: Животные, Тип: Хордовые, Подтип: Позвоночные, Надкласс: Рыбы, Класс: Костные рыбы, Отряд: Карпообразные, Семейство: Карповые, Род: Караси, Вид: Золотая рыбка» %)
Так и с файлами: я хочу «фотки», «из Штатов», «июль 2009», а не "/home/mikhail/data/pics/photos/2009/2009.07.01. Поездка в Штаты/*.jpg" :)
Это потмоу что память у нас ассоциативная память.
Есть одно но…
Дело в том, что один объект является частью различных систем, например «Вася Пупкин» — муж Маши Пупкиной (система «семья») или «Вася Пупкин» — выпускник МГИМО (система «образование»), было бы два тега найти было бы проще.
Дело в том, что один объект является частью различных систем, например «Вася Пупкин» — муж Маши Пупкиной (система «семья») или «Вася Пупкин» — выпускник МГИМО (система «образование»), было бы два тега найти было бы проще.
/цветной/жёлтый
/объёмный/круглый
куда поместить жёлтый мяч?
тэги должны выстраиваться в иерархии, а не объекты…
/объёмный/круглый
куда поместить жёлтый мяч?
тэги должны выстраиваться в иерархии, а не объекты…
Я-бы все-таки ушел от слова иерархия, подменив его словом связь.
Согласен. Причём в общем случае иерархий тэгов может быть несколько, т.к. любой объект можно классифицировать по целому ряду свойств. В каждой конкретной задаче может быть ровно столько иерархий тэгов, сколько необходимо (или достаточно?) для быстрого поиска нужного объекта в разных ситуациях.
Почему нет? Я всю еду могу разделить по признакам «вкусное» и «невкусное», а могу и по признакам «легко приготовить» и «тяжело приготовить», а также «халява», «дёшево», «дорого» и «за всю жизнь не накоплю». И нафиг мне тут иерархия? По этим меткам я очень быстро могу найти халявную, вкусную еду, которую легко готовить. И никак ты тут не придумаешь такую хитрую иерархию, чтобы она помогала так же быстро выбирать еду, как метки.
Хм, у массового пользователя на рабочем столе винды красуется Новая папка[n+1], не думаю, что он проникся иерархичностью ФС
дело не только в переучить, а в перепроектировании систем на очень глубоком уровне.
gmail какбэ вполне даже переучил.
Не соглашусь с тем, что в массе пользователю все это не нужно. То, что пользователь не считает, что ему это нужно, не означает, что ему это ненужно. Люди в массе своей боятся и не любят нового. Сказать честно, что ты не хочешь что-то новое, что ты никогда еще и не видел, нельзя — ведь ты не знаешь, что это. Поэтому когда люди говорят, что они не хотят нового, они просто маскируют свой страх.
Так что, если серьезно, проблема WinFS была не в том, что она была никому не нужна, а то, что пытались все вместе сделать — и WinFS, и Avalon, и Windows Shell.
Вообще структурность в проекте была недостаточной для успешного завершения проекта :(
Впрочем, не переживайте… Эти возможности еще появятся в SQL Server. :) А там, глядишь, и в Windows. И, в конце концов, не Windows единым живо человечество.
Так что, если серьезно, проблема WinFS была не в том, что она была никому не нужна, а то, что пытались все вместе сделать — и WinFS, и Avalon, и Windows Shell.
Вообще структурность в проекте была недостаточной для успешного завершения проекта :(
Впрочем, не переживайте… Эти возможности еще появятся в SQL Server. :) А там, глядишь, и в Windows. И, в конце концов, не Windows единым живо человечество.
Это означает только то, что разработка такого подхода стоит много денег и времени.
Ну, у меня и на Винде LightRoom раскладывает все фотки по папкам, а пикаса тегирует и сортирует. С фильмами всё тоже достаточно просто — они складываются в папочку Media/Video в настройках загрузчиков. Музыку ещё не пробовал особенно раскладывать, но, думаю, Itunes или Songbird с этим справятся.
В итоге, только папка Downloads представляет из себя нагромождение хлама. Но, думаю, для того она и создана :)
В итоге, только папка Downloads представляет из себя нагромождение хлама. Но, думаю, для того она и создана :)
Тэги — это хорошо, но отказываться от привычной древовидной структуры не стоит.
Если только потому что она привычная, то стоит.
Тот, кто минус поставил, напишите пожалуйста, почему не согласны. Интересно-же.
Привычно != удобно.
Каждому нравится своё, я например свихнусь искать по тегам нужный мне код среди нескольких тысяч файлов.
Иерархию придумывали не просто что бы была, она удобна в нужном месте.
Каждому нравится своё, я например свихнусь искать по тегам нужный мне код среди нескольких тысяч файлов.
Иерархию придумывали не просто что бы была, она удобна в нужном месте.
p.s. Я не минусовал.
Да, я забыл написать, что сценарий разработки ПО — совсем другое дело. Здесь как раз иерархическая структура очень полезна. Я писал статью глазами фронтенда. А об инженерном подходе как раз первый абзац.
Что программисту удобно — пользователю зло. :)
Что программисту удобно — пользователю зло. :)
Ну что верно то верно, но всё же это проблема не файловой системы, а операционной системы, это она должна предоставлять пользователю удобный вид.
В фотографиях, видео, музыке, теги — это удобно, согласен на 100%.
В документах, 50/50.
Программисту/админу, как явление чёрта в церков поглумиться )
В фотографиях, видео, музыке, теги — это удобно, согласен на 100%.
В документах, 50/50.
Программисту/админу, как явление чёрта в церков поглумиться )
>Что программисту удобно — пользователю зло. :)
обратное тоже верно
обратное тоже верно
Зачем же менять файловую систему, если вам не нравятся ее представления?
Просто используйте другое представление.
Персональные поисковики уже лет 10 как существуют.
Просто используйте другое представление.
Персональные поисковики уже лет 10 как существуют.
Зачем мне искать файлы, если я знаю, где что у меня лежит? Я поиском пользуюсь в лучшем случае раз в месяц, уж по любому операция ручного перехода в нужную мне папку быстрее чем поиск и выборка нужного файла среди тегов.
Первое что приходит на ум: организовать веб-сервер без древовидной фс не получится.
Второе — как будет не древовидная фс выглядеть с точки зрения ос?
Второе — как будет не древовидная фс выглядеть с точки зрения ос?
Я был-бы очень признателен, если бы вы привели доказательство своего утверждения.
Это вопрос технической реализации, которого я бы не хотел касаться в данном топике.
1. Я собираюсь отказаться от вложенности потому что это и есть древовидная иерархия.
Вместо этого, если необходимо, можно иметь связанные теги, которые будут эмулировать узлы дерева для спецзадач (скажем разработка ПО, где иерархия действительно удобна).
2. Я не могу придумать ей массового применения.
Вместо этого, если необходимо, можно иметь связанные теги, которые будут эмулировать узлы дерева для спецзадач (скажем разработка ПО, где иерархия действительно удобна).
2. Я не могу придумать ей массового применения.
Не будет никакой длинющей колбасы файлов, будут теговые выборки. Чтобы представить себе теговую ФС, нельзя смотреть на нее принципами древовидной.
Полностью теговая файловая система использует в качестве системы координат, некие теги, как автоматические, так и пользовательские. Автоматические делятся на системные ( необходимые системе, чтобы находить нужные файлы), и те, которые просто проставляются сами при попадании нового файла в систему (дата, тип и т.д.).
Теги могуть быть связаны между собой, чтобы возможно было эмулировать узлы (например для сценария разработки ПО)
Теги могуть быть связаны между собой, чтобы возможно было эмулировать узлы (например для сценария разработки ПО)
В теговую ты просто помещаешь файл куда-то. В худшем случае всегда найдется по имени.
Автоматическое тегирование я описал в середине статьи.
Так то что инфы нет, это же простор для работы. Мой предыдуший проект «Веборама», умеет распознавать и подписывать музыку и клеить к ней каверы. Еще 10 сервисов умеют тоже самое.
Для фильмов вот-вот появятся такие-же, уверен (если их уже нет).
Такую информационную базу можно построить вокруг любой сущности.
Я просто немного в будущее смотрю, потому что знаю, что до массового производства моих идей еще далеко.
Для фильмов вот-вот появятся такие-же, уверен (если их уже нет).
Такую информационную базу можно построить вокруг любой сущности.
Я просто немного в будущее смотрю, потому что знаю, что до массового производства моих идей еще далеко.
Thinking out of box…
А если представить себе, что массивы могут быть 3-хмерными? Т.е. у нас есть пространства контента? И что есть меню типа Pie Menu, позволяющие переноситься (как бы телепортироваться, или «прыгать») по пространству контента.
Мне кажется, в этом случае вопросы иерархии становятся гораздо более интересными… А если связи при этом будут слабо светящимися нитями, соединяющими сущности, представляющие те или иные события из реального мира?
А если еще будут механизмы фильтрации этого трехмерного пространства по типу контента, по вашим интересам??
А если представить себе, что массивы могут быть 3-хмерными? Т.е. у нас есть пространства контента? И что есть меню типа Pie Menu, позволяющие переноситься (как бы телепортироваться, или «прыгать») по пространству контента.
Мне кажется, в этом случае вопросы иерархии становятся гораздо более интересными… А если связи при этом будут слабо светящимися нитями, соединяющими сущности, представляющие те или иные события из реального мира?
А если еще будут механизмы фильтрации этого трехмерного пространства по типу контента, по вашим интересам??
Почему нельзя рассматривать //фото/отпуск/анапа/я.jpg как теги? Ничто не мешает вам использовать обычную иерархическую ФС как тэговую с помощью несложной надстройки. На любителя такскзть. А вот обратного пути нет.
>Почему нельзя рассматривать //фото/отпуск/анапа/я.jpg как теги?
Потому что на том же самом фото может быть не только «я», но и «жена», а само фото может относиться не только к «анапа», но и к «море». А если на фото есть, к примеру, ещё и крокодил, то на него можно повесить тег «животные».
Итого: в случае поиска по тегам это фото вылезет и по запросу «я»+«животные» (например, вместе с фотками меня на фоне белых медведей из ленинградского зоопарка), и по запросу «я»+«жена» (например, вместе с фотками со свадьбы), и по запросу «жена»+«море» (например, вместе с фотками из Турции, куда жена ездила с подругами).
Как Вы сможете организовать подобное средствами файловой системы? После привычки к такому комфорту обратного пути, действительно, не будет ;)
Потому что на том же самом фото может быть не только «я», но и «жена», а само фото может относиться не только к «анапа», но и к «море». А если на фото есть, к примеру, ещё и крокодил, то на него можно повесить тег «животные».
Итого: в случае поиска по тегам это фото вылезет и по запросу «я»+«животные» (например, вместе с фотками меня на фоне белых медведей из ленинградского зоопарка), и по запросу «я»+«жена» (например, вместе с фотками со свадьбы), и по запросу «жена»+«море» (например, вместе с фотками из Турции, куда жена ездила с подругами).
Как Вы сможете организовать подобное средствами файловой системы? После привычки к такому комфорту обратного пути, действительно, не будет ;)
Посмотрите BeFS.
А вы не могли бы по-подробнее описать что за UPnP AV, или какой вы могли бы посоветовать? Баш скрипт тоже заинтересовал, можно на него взглянуть? Просто что-то не приходят мысли как вы определяете куда надо повернуть фотографию…
в фотографии хранится какая-то инфа по поводу ее угла поворота, иначе, например, preview в макоси не смог бы сам поворачивать фотки при просмотре. Но это если с фотоаппарата, если просто картинка, то… :)
1. Mediatomb / mediatomb.cc, для него написано куча скриптов, которые тегируют всю медиатеку.
2. media.tbms.ru:1982/process.photos.rar
2. media.tbms.ru:1982/process.photos.rar
А расширения файлов за теги вы не считаете?
В MacOS как раз происходит подобное. Для простого конечного пользователя программы ставятся «куда-то», документы тоже лежат «в компьютере», пользователь не думает где и что у него лежит. Он просто использует Finder.
есть одно но:
когда в вас все в одной папке и с тегами, это хорошо только с вашей стороны.
подключите это носитель информации к любой другой системе и получите кашу их файлов, в которых невозможно разобраться.
+ когда знаешь где, в какой папке и что и в каком виде находится — тренируется память. не надеешься на технику, а сам знаешь и в случае чего не потеряешь.
а в целом может мысли и правильные, только слишком уж кардинальные.
когда в вас все в одной папке и с тегами, это хорошо только с вашей стороны.
подключите это носитель информации к любой другой системе и получите кашу их файлов, в которых невозможно разобраться.
+ когда знаешь где, в какой папке и что и в каком виде находится — тренируется память. не надеешься на технику, а сам знаешь и в случае чего не потеряешь.
а в целом может мысли и правильные, только слишком уж кардинальные.
> подключите это носитель информации к любой другой системе и получите кашу их файлов, в которых невозможно разобраться.
Вот я и хочу, чтобы теги стали так-же естественны как файлы и папки. Поэтому они должны работать на уровне файловой системы, а не операционной.
> + когда знаешь где, в какой папке и что и в каком виде находится — тренируется память. не надеешься на технику, а сам знаешь и в случае чего не потеряешь.
Также, например, можно оправдывать распечатывание всех документов, чтобы ничего не пропало.
Вот я и хочу, чтобы теги стали так-же естественны как файлы и папки. Поэтому они должны работать на уровне файловой системы, а не операционной.
> + когда знаешь где, в какой папке и что и в каком виде находится — тренируется память. не надеешься на технику, а сам знаешь и в случае чего не потеряешь.
Также, например, можно оправдывать распечатывание всех документов, чтобы ничего не пропало.
про первое соглашусь частично, ибо может это все и так распрекрасно, но всеобщей согласованности от производителей вы никогда не дождетесь. конкуренция и т.п.
про второй совсем не соглашусь, т.к. сравнение не верное в корне. я не предлагаю «складывать так, что бы запомнить», а «запоминать как что сложено».
про второй совсем не соглашусь, т.к. сравнение не верное в корне. я не предлагаю «складывать так, что бы запомнить», а «запоминать как что сложено».
Я не хочу чтобы появилась одна универсальная ФС. Я хочу чтобы они все каким-то образом начали поддерживать теги. Можно-же сейчас читать NTFS под Linux и наоборот.
Теги в HFS+ (Mac OS X) поддерживаются. А работать с файлами без запоминания что где находится поможет quicksilver.
вы ж серьезный человек, и сами понимаете, что «каким-то образом» зависит от разработчиков, а не все на это будут тратить время.
под макось тоже можно читать нтфс, но только писать на нтфс с бубнами.
под макось тоже можно читать нтфс, но только писать на нтфс с бубнами.
Зачем все смешивать? Например теги для музыки и кода будут просто мешать друг другу, eg если любители PinkFloyd выпустят одноименный фреймворк. То есть придется организовывать namespaces. Но ведь это уже есть сейчас на уровне приложений!
Необходимы также системы для автоматического перевода между системами тэгов и иерархией.
Например, Разложить музыку в иерархии по шаблону «%Artist%/%Year% — %Album%/%TrackNo% — %Title%»
Также подписать тэги, предположив логику иерархии по шаблону…
Например, Разложить музыку в иерархии по шаблону «%Artist%/%Year% — %Album%/%TrackNo% — %Title%»
Также подписать тэги, предположив логику иерархии по шаблону…
подключите это носитель информации к любой другой системе и получите кашу их файлов, в которых невозможно разобраться.
А почему бы на других системах тегам не выглядеть как иерархическая структура со связями многие к многим на базе тупых симлинков? Как обходной вариант.
Иногда ты просто забываешь как называется документ/песня/фильм. Помнишь просто какой-то отрывок. Вот в таких случаях, зайти в папку и посмотреть весь список произведений – очень помогает. Так что отказываться от «ирархических БД», в пользу «плоских-тегированных» я бы не стал.
Идеальный вариант это совмещать оба эти варинта и именно по этому пути сейчас активно идет развитие.
Идеальный вариант это совмещать оба эти варинта и именно по этому пути сейчас активно идет развитие.
В тэгированной системе вы бы сделали соответствующую выборку и просмотрели бы ее.
Какую выборку? Из всей музыки на компьютере? Из всех фильмов? Думаю это не самый лучший вариант, по сравнению с грамотно организированной системой папок.
Нет. Зачем из всей музыки. Я бы сделал поиск из всей меланхоличной музыки английских исполнителей записанной после 2000 года. Думаю в этой выборке я бы быстро нашел Radiohead Nude 2007
«Вся меланхоличная музыка» — откуда берётся?
музыка — тег
меланхолия — тег
оба свойства могут назначаться как автоматом(на основе анализа звука, на основе отзывов о дорожек в интернете) так и рукам
меланхолия — тег
оба свойства могут назначаться как автоматом(на основе анализа звука, на основе отзывов о дорожек в интернете) так и рукам
Нет-нет, имеется ввиду — откуда берётся музыка для разбора по тегам? Из «все музыки».
Т.е. вы от «всей музыки» уйти не сможете. Выборка по тегам «меланхолия» по-любому будет происходить из абсолютно всей музыки. А если учесть, что музыка — это тег, то — абсолютно из всей информации, имеющейся на диске.
Дороговато, я предпочту иерархию — гораздо, на порядки дешевле.
Т.е. вы от «всей музыки» уйти не сможете. Выборка по тегам «меланхолия» по-любому будет происходить из абсолютно всей музыки. А если учесть, что музыка — это тег, то — абсолютно из всей информации, имеющейся на диске.
Дороговато, я предпочту иерархию — гораздо, на порядки дешевле.
Так ведь индексация на то и нужна, чтобы ускорить процесс фильтрации по тегам. Более того, фильтрующие запросы могут быть произвольной сложности, в том числе и по дате создания файла, дате выпуска альбома, ритму, возрасту клавишника и так далее. Поиск по всему диску будет проходить за миллисекунды. А вот обход дерева — это по-настоящему дорогая операция.
Выборку, соответствующую логике той папке в которую вы бы зашли. Ведь «зайти в папку» это есть частный случай выборки (по той логике, которую вы назначили папке)
Да. Но фишка иерархической структуры, в том что ты всегда имеешь достаточно ограниченное множество тегов в конкретный момент из которого можешь выбирать. В чисто теговой организации, ты должен выбирать из всего множества тегов всегда. Что зачастую сильно усложняет выборку.
Конечно, вы можете последовательно, спускаться вниз набирая разные варианты того что вам приходит в голову. Но по сути это будет менее удобно чем обычный файловый менеджер.
Конечно, вы можете последовательно, спускаться вниз набирая разные варианты того что вам приходит в голову. Но по сути это будет менее удобно чем обычный файловый менеджер.
а чего вас так пугает поиск по всему? индексы давно придуманы, не бойтесь!
зато с папками вы постоянно рискуете забыть, в какую папку чего положили, и оно может там лежать годами, забытое, неиспользуемое…
зато с папками вы постоянно рискуете забыть, в какую папку чего положили, и оно может там лежать годами, забытое, неиспользуемое…
Теги не избавят вас от проблемы «забывчивости». Они лишь переведут ее в иную плоскость. =)
я так понял, что вы ратуете за преимущество человеческого поиска — увидел папку «Видео» — ага, значит все видео тут, заходим в неё, и просматриваем уже подпапки…
а то, что некто (допустим, другой пользователь или пьяный пользователь :) ) положил какое-то видео в папу Фотки, система не учитывает. И в таком случае результат человеческого просмотра (=поиск не машинными средствами) будет не полным.
с тегами, особенно автоматически расставляемым, такого можно избежать. причем это не потребует от пользователя вообще никаких усилий — ему не надо будет думать, в какую папочку сохранить файл, как назвать подпапку, чтобы через полгода по имени папки можно было понять, что в ней лежит и т.п.
а то, что некто (допустим, другой пользователь или пьяный пользователь :) ) положил какое-то видео в папу Фотки, система не учитывает. И в таком случае результат человеческого просмотра (=поиск не машинными средствами) будет не полным.
с тегами, особенно автоматически расставляемым, такого можно избежать. причем это не потребует от пользователя вообще никаких усилий — ему не надо будет думать, в какую папочку сохранить файл, как назвать подпапку, чтобы через полгода по имени папки можно было понять, что в ней лежит и т.п.
Ну во-первых если вводить автоматическую систему проставления тегов, то кто вам мешает сделать автоматическую систему создание директорий и поддиректорий?
Во-вторых, если система все таки не автоматическая, то опять же проблема «другого пъяного пользователя» никуда не денется. Если я протегировал (назвал папку) «Хорошая музыка», то не факто что для кого-то другого, она будет являться хорошей (даже не факт, что для пъяного меня она будет являеться хорошей =) ). И это, как раз то, что я имел ввиду когда говорил что проблема «забывчивости» неистребима.
Во-вторых, если система все таки не автоматическая, то опять же проблема «другого пъяного пользователя» никуда не денется. Если я протегировал (назвал папку) «Хорошая музыка», то не факто что для кого-то другого, она будет являться хорошей (даже не факт, что для пъяного меня она будет являеться хорошей =) ). И это, как раз то, что я имел ввиду когда говорил что проблема «забывчивости» неистребима.
> Ну во-первых если вводить автоматическую систему проставления тегов, то кто вам мешает сделать автоматическую систему создание директорий и поддиректорий?
Автоматическая система как раз ключевой момент. Заставив ее работать хорошо человечество победит необходимость в иерархическом хранении информации.
Подумайте: пути типа "/home/merlin/clients/base" — это же теги! Опа, оказывается, теги можно забыть, да?
это не теги.
/storage/base.db[merlin, clients, 2008, archive] — вот это теги
/storage/base.db[merlin, clients, 2008, archive] — вот это теги
Почему это не теги? Почему вы разделяете теги запятыми, но не слешами? В чём разница?
разница в том, что в иерархии (которой является система папок), у объекта может быть только один родитель.
А с тегами это не так.
И я могу написать
/storage/base.db[merlin, clients, 2008, archive]
а потом, если базой пользуется еще и arthur, я могу добавить тег
/storage/base.db[merlin, arthur, clients, 2008, archive]
но если у меня
/home/merlin/clients/base,
то мне придется сделать второй путь
/home/arthur/clients/base
видите? clients повторяется 2 раза. А если в системе есть излишнее дублирование, значит она не вполне эффективна.
А с тегами это не так.
И я могу написать
/storage/base.db[merlin, clients, 2008, archive]
а потом, если базой пользуется еще и arthur, я могу добавить тег
/storage/base.db[merlin, arthur, clients, 2008, archive]
но если у меня
/home/merlin/clients/base,
то мне придется сделать второй путь
/home/arthur/clients/base
видите? clients повторяется 2 раза. А если в системе есть излишнее дублирование, значит она не вполне эффективна.
Вы описали разные объекты, естественно, что они описываются разными тегами.
какой-такой разный объект? у нас же hardlink'и на одну и ту же базу
и, простите, тег — это слово или фраза. в этом смысле, если в пути к файлу есть /clients/, то это один и тот же 'clients'.
В противном случае путь — никакие не теги в принципе. Теги — это способ описания смысла содержимого!
и, простите, тег — это слово или фраза. в этом смысле, если в пути к файлу есть /clients/, то это один и тот же 'clients'.
В противном случае путь — никакие не теги в принципе. Теги — это способ описания смысла содержимого!
А что, /home/merlin/clients/base — это не описание содержимого? Это клиент base пользователя merlin (я просто прочитал теги в другом порядке, в том, который мне был удобен в данный момент).
Или как я про фильмы писал, режиссёр/год/название — это не описание содержимого? Это фильм название режиссёра, вышедший в году.
Зато, в отличие от вас, я могу обеспечить однозначность объектов: Михалков/2009/фильм и Захаров/2009/фильм — разные фильмы, несмотря на то, что оба 2009 и оба — фильм. Но они похожи: они оба — 2009.
Одними же тегами идентифицировать объект не удастся. Должен быть «primary key».
Или как я про фильмы писал, режиссёр/год/название — это не описание содержимого? Это фильм название режиссёра, вышедший в году.
Зато, в отличие от вас, я могу обеспечить однозначность объектов: Михалков/2009/фильм и Захаров/2009/фильм — разные фильмы, несмотря на то, что оба 2009 и оба — фильм. Но они похожи: они оба — 2009.
Одними же тегами идентифицировать объект не удастся. Должен быть «primary key».
Если вы будете видеть теги home, merlin, clients, base а программа будет обращаться к
getDataByTags([home, merlin, clients, base]);, то вы попадете в одно и тоже место.
Primary Key несколько надуманная проблема.
getDataByTags([home, merlin, clients, base]);, то вы попадете в одно и тоже место.
Primary Key несколько надуманная проблема.
Уныло это потому что на фотографиях могут быть теги «Жена» и «Сын», и если я хочу иметь эти подборки отдельно, то Фото\Анапа\2008 мне ничем не поможет. И мозг мой в этом не виноват.
> Замените «Спсособ» на «Способ» в обоих пунктах.
Спасибо Ж)
Спасибо Ж)
Автор не полностью переложил в статью то, что было написано в книге по проектированию интерфейсов Алана Купера.
Там как раз говорится о том, что вы сказали. Типа мозга не хватает, чтобы создать иерархическую структуру. При этом там приведено несколько способов, которые позволят избежать ее и сделать в сто раз удобней для людей. Именно для обычных конечных простых пользователей, которые не являются инженерами и компьютерными специалистами. Которые не знают, что такое папка, иерархия. Прочитаете, поймете о чем говорил автор этого поста.
Кстати, в той же книге и написано, откуда появились папки, рабочий стол и зачем это было нужно и почему тогда (несколько десятков лет назад) не было возможности сделать иначе.
Там как раз говорится о том, что вы сказали. Типа мозга не хватает, чтобы создать иерархическую структуру. При этом там приведено несколько способов, которые позволят избежать ее и сделать в сто раз удобней для людей. Именно для обычных конечных простых пользователей, которые не являются инженерами и компьютерными специалистами. Которые не знают, что такое папка, иерархия. Прочитаете, поймете о чем говорил автор этого поста.
Кстати, в той же книге и написано, откуда появились папки, рабочий стол и зачем это было нужно и почему тогда (несколько десятков лет назад) не было возможности сделать иначе.
Ну, вам надо смотреть в сторону Джефа Раскина и его ZoomWorld:
— Ссылка на соответствующую главу книги «Интерфейс».
К слову, EXT2 и EXT3, как и многие другие хорошие ФС, позволяют ссылаться на один inode нескольким «файлам». Простой механизм ссылок. Не теги, но уже что-то. И совсем не убогие ярлыки из Win, которые вы так не любите.
Вообще, идеи есть в этом направлении и они вполне реализуемы, как в виде прослойки между пользователем и базовой ОС, так и в виде самостоятельной системы. Например, поиск новых метафор для пользователя. Почему обязательно рабочий стол? Почему картотека (папки)? Почему дискретные файлы, а не пространство данных? Все это необходимо пересмотреть. А еще важно, чтобы пользователь никогда не думал о такой штуке, как тип файла. Система должна сортировать поступающую информацию по группе признаков и привязывать к соответствующему ПО, в котором и будут организованы данные того или иного типа.
— Ссылка на соответствующую главу книги «Интерфейс».
К слову, EXT2 и EXT3, как и многие другие хорошие ФС, позволяют ссылаться на один inode нескольким «файлам». Простой механизм ссылок. Не теги, но уже что-то. И совсем не убогие ярлыки из Win, которые вы так не любите.
Вообще, идеи есть в этом направлении и они вполне реализуемы, как в виде прослойки между пользователем и базовой ОС, так и в виде самостоятельной системы. Например, поиск новых метафор для пользователя. Почему обязательно рабочий стол? Почему картотека (папки)? Почему дискретные файлы, а не пространство данных? Все это необходимо пересмотреть. А еще важно, чтобы пользователь никогда не думал о такой штуке, как тип файла. Система должна сортировать поступающую информацию по группе признаков и привязывать к соответствующему ПО, в котором и будут организованы данные того или иного типа.
В Win тоже есть symbolic links. Их непопулярность как бы говорит о том, что обычному пользователю они не нужны.
может просто ими пользоваться неудобно? Кстати, link-файлами все пользуются, потому что их использование просто, понятно и всегда под рукой.
а с-линки в эксплорере до сих пор делать нечем.
а с-линки в эксплорере до сих пор делать нечем.
Товарищ говорил как раз не о симлинках, а о хард-линках. Это не ссылка на файл, это равнозначный элемент файловой системы, ссылающийся на ту же самую область диска, что и оригинал. Т.е. обращение с этим файлом идёт так же, как и с оригиналом, он имеет тот же размер, его можно открыть на чтение/запись и так далее. Просто как бы клон оригинала, но без дублирования на диске. Грубо говоря — один и тот же файл, доступный из разных мест.
Поддержка хардлинков на NTFS появилась даже раньше, чем симлинков (хардлинки — ещё в NT4, симлинки — с Win2k). А используются они под Windows слабо во многом из-за того, что в дефолтовом виндовом интерфейсе (в частности в файловом менеджере Explorer) нет удобных, понятных и доступных средств для их создания и работы с ними.
>
Удивительно, казалось-бы, после перехода на такую «враждебную к пользователю» операционную систему, как Линукс я осознал насколько легко и просто жить без необходимости раскладывать все по папкам. Музыка и видео у меня скачиваются в одно место, а интерфейсом служит UPnP AV сервер, который сам определяет теги для контента: тегирует исполнителями, альбомами, жанрами, годами и т.д. песни; видео — актерами и режиссерами плюс сериалы — сезонами и сериями. Я даже честно не знаю что и как у меня в этой папке, которая названа media происходит.
>
простите, Вы когда-нибудь запускали wmp?
>
Программы в Линуксе тоже ставятся так, что я даже не подозреваю о том, что файловая система есть и что она как-то устроена.
>
ставили программу под Windows инсталлятором?
или Вы не с Windows перешли во «враждебную систему»?
Удивительно, казалось-бы, после перехода на такую «враждебную к пользователю» операционную систему, как Линукс я осознал насколько легко и просто жить без необходимости раскладывать все по папкам. Музыка и видео у меня скачиваются в одно место, а интерфейсом служит UPnP AV сервер, который сам определяет теги для контента: тегирует исполнителями, альбомами, жанрами, годами и т.д. песни; видео — актерами и режиссерами плюс сериалы — сезонами и сериями. Я даже честно не знаю что и как у меня в этой папке, которая названа media происходит.
>
простите, Вы когда-нибудь запускали wmp?
>
Программы в Линуксе тоже ставятся так, что я даже не подозреваю о том, что файловая система есть и что она как-то устроена.
>
ставили программу под Windows инсталлятором?
или Вы не с Windows перешли во «враждебную систему»?
> простите, Вы когда-нибудь запускали wmp
Да
> ставили программу под Windows инсталлятором?
Ставил. Yes|No|I Accept->Choose Location->Next->Next->Next->Reboot?
VS
apt-get install
Да
> ставили программу под Windows инсталлятором?
Ставил. Yes|No|I Accept->Choose Location->Next->Next->Next->Reboot?
VS
apt-get install
что здесь кроме Choose Location относится к ФС?
А я пока не знаю зачем мне задали те вопросы.
>что здесь кроме Choose Location относится к ФС?
Вы пропустили несколько пунктов ;)
Пойти на сайт автора программы, скачать файл инсталлятора, сохранив его в какой-нибудь каталог на жёстком диске, потом открыть этот каталог в любимом файл-менеджере и запустить файл инсталлятора.
Все эти вещи давно уже стали настолько привычными и «естественными» (да-да, в кавычках), что попросту не замечаются.
В случае Linux файловая система не задействована вообще: тыкнуть в меню «Установка программ», выбрать программу, нажать «Установить». Понятия не имея (и не желая иметь об этом понятие), куда она установилась и из каких файлов состоит.
Вы пропустили несколько пунктов ;)
Пойти на сайт автора программы, скачать файл инсталлятора, сохранив его в какой-нибудь каталог на жёстком диске, потом открыть этот каталог в любимом файл-менеджере и запустить файл инсталлятора.
Все эти вещи давно уже стали настолько привычными и «естественными» (да-да, в кавычках), что попросту не замечаются.
В случае Linux файловая система не задействована вообще: тыкнуть в меню «Установка программ», выбрать программу, нажать «Установить». Понятия не имея (и не желая иметь об этом понятие), куда она установилась и из каких файлов состоит.
>Да
ну так вот, процитированный мной абзац в точности описывает wmp.
>Ставил. Yes|No|I Accept->Choose Location->Next->Next->Next->Reboot?
еще пару раз cancel забыли :)
три щелчка мыши и программа установлена, впрочем это Выше уже написали.
>А я пока не знаю зачем мне задали те вопросы.
затем, чтобы показать Вам, что приведенные Вами примеры иллюстрируют, простите, хуй знает что. в «невраждебной» системе все точно также, как Вы описали, а каким образом это все относится к файловой системе вообще сложно представить.
ну так вот, процитированный мной абзац в точности описывает wmp.
>Ставил. Yes|No|I Accept->Choose Location->Next->Next->Next->Reboot?
еще пару раз cancel забыли :)
три щелчка мыши и программа установлена, впрочем это Выше уже написали.
>А я пока не знаю зачем мне задали те вопросы.
затем, чтобы показать Вам, что приведенные Вами примеры иллюстрируют, простите, хуй знает что. в «невраждебной» системе все точно также, как Вы описали, а каким образом это все относится к файловой системе вообще сложно представить.
В какой строке текста я вообще коснулся системы отличной от Линукса, а уж тем более стал что-то с чем-то сравнивать.
Проблема в том, что в винде инсталлятор ещё нужно где-то найти. Мне нужен, например, gimp, или apache, или amarok или ещё что. Я пишу apt-get install [name] и всё. Или же графическим путём — через установку/удаление программ, всё, что нужно — поставить галочки рядом с нужными программами. Мне не нужно искать в сети сайт производителя, искать там где скачать дистрибутив (далеко не все сайты логичны), качать, запускать, кликать по кнопкам. Я лично очень хорошо ощутил эту разницу, когда перешёл на линукс.
Поздравляю, вы только что описали Nepomuk :)
Согласен полностью. С тех пор как начал пользоваться M2 (почтовый клиент) проникся всякими ярлыками и тегами к каше информации. Потом гугл в своей почте делал аналогичные подвижки. Объемы информации уже не те, что были раньше, в голове уже всего не удержать, и никаких папок не хватает. Слишком многопараметрично всё чтобы различать всё лишь в одной плоскости иерархии.
Причем, переход-то несложен. На существующую иерархию надо сделать оболочку, которая будет всё представлять кашей с тегами. Потом останется только отвыкнуть от папок и постепенно про них забыть как мы забыли про многие другие дедеовские методы и решения.
Так хотелось WinFS.
P.S. Меня только смущает четкость всех этих тегов, будут определенные проблемы по первости.
Причем, переход-то несложен. На существующую иерархию надо сделать оболочку, которая будет всё представлять кашей с тегами. Потом останется только отвыкнуть от папок и постепенно про них забыть как мы забыли про многие другие дедеовские методы и решения.
Так хотелось WinFS.
P.S. Меня только смущает четкость всех этих тегов, будут определенные проблемы по первости.
Тогда вы не сможете передавать информацию с тегами в другие системы. :(
Верно. В принципе, то же самое происходит и при взаимодействии несовместимых ФС — часть информации теряется: потоки NTFS при копировании на extX, права доступа при копировании на FAT32 и тому подобное.
Что поделать… В тех других системах нет средств выражения того, что если в этой, на то они и другие. Если будет две тегированных системы, которые несовместимы, то информация о тегах будет с необходимостью теряться. Если совместимы — нет ничего сложного в том, чтобы сохранить эту информацию.
Кстати, POSIX-совместимые поддерживают расширенные атрибуты — setfattr, getfattr и пр. Вот вам и механизм хранения тегов; при копировании они тоже копируются с файлом, теряться не будут. Осталось сделать механизм индексирования и интерфейс.
Что поделать… В тех других системах нет средств выражения того, что если в этой, на то они и другие. Если будет две тегированных системы, которые несовместимы, то информация о тегах будет с необходимостью теряться. Если совместимы — нет ничего сложного в том, чтобы сохранить эту информацию.
Кстати, POSIX-совместимые поддерживают расширенные атрибуты — setfattr, getfattr и пр. Вот вам и механизм хранения тегов; при копировании они тоже копируются с файлом, теряться не будут. Осталось сделать механизм индексирования и интерфейс.
Поддержка «тегов» со стороны файловой системы есть и называется «жёсткие ссылки» (хардлинки). И лично я ими довольно часто пользуюсь для этой цели. Вот, хорошо бы была поддержка со стороны DE/объектной среды использования хардлинков для каталогизации. Только к сожалению, DE пошли по пути популяризации, максимум, что придумали — это Nepomuk и Zeitgeist. Только плохо, что метаданные хранятся во внешних хранилищах а не рядом с описываемыми данными.
в Win ксо жалению до сих пор нет интуитивного способа создавать и использовать хардлинки. ну либо по крайней мере он мне не известен
Ну, не могу согласиться с Вами. Жесткие ссылки абсолютно ни как не отвечают принципам тэггирования, предлагаемого автором топика. Они всего лишь позволяют обойти ограничения строгой иерархичности файловой системы, не более того. Использование тэгов подразумевает некую каталогизацию, категоризацию данных, не зависящую от фактического местонахождения файла. Причем поддержа тэггирования должна осуществляться на уровне файловой системы, а OS и DE должны лишь использовать интерфейсы этой файловой системы для поиска и быстрого доступа к нужным данным.
Начнём с того, что любая файловая система реализует 2 вещи: (1) собственно абстракцию-объединение данных раскиданных на диске, называемую файлом и (2) каталогизацию этой информации в удобном для пользователя виде.
В общем-то, каталогизация информации для файловой системы, по большому счёту, не обязательна. Она введена, по сути, только для реализации концепции удаления/отлинковки файлов и освобождения физического места под них (в некоторых FS — ещё и для хранения некоторой метаинформации о файлах). Так что любая группировка файлов определённого типа в каталоги — это задача теггирования. В противном случае можно было бы скинуть все файлы в один каталог, предварительно позаботившись об эффективном индексе. К примеру, я знаю, что «тег» "/bin/sh" определяет файл-программу активной командной оболочки по умолчанию, а «тег» "/bin/cat" — файл-программу дубликации и объединения содержимого дескрипторов. Мне совсем необязательно знать, специальные ли эти файлы, или те же, что и у файла "/bin/busybox". Или, может, там определяется, что реальный файл определяется другой записью в каталоге. Вся логика работы с информацией определяется этими метками, которые записаны в стартовых скриптах и бинарных программах, причём реальное соответствие меток можно менять в процессе работы системы.
Соответственно, линки из каталогов на индексные блоки файлов (или на индекс первого блока файла в таблице их размещения) — это и есть поддержка теггирования на уровне файловой системы. Смысл каталожных записей-тегов в любом случае определяется внешним образом (например, где линкуются файлы, принадлежащие тому или иному пользователю).
К примеру, ничто, кроме ограничений FS, не мешает использовать в качестве имён каталожных записей конкатенацию RDFовских URI (например, процент-кодированных) для субъекта и предиката, а в качестве прилинкованного файла — файл специального синтаксиса (типа), который определит объект отношения, отличный от простого бинарного файла. Другое дело, что смысла так делать нет, поскольку с тегами надо как-то работать, как-то организовывать составные ключи для поисков и т.п. — т.е. полноценную базу знаний лучше делать с помощью специализированных средств.
Но во всяком случае, лично для меня вполне хватает сделать для определённых файлов изображений ссылки в каталогах ".../кто изображён", ".../год фотографирования" и ".../описание поездки".
В общем-то, каталогизация информации для файловой системы, по большому счёту, не обязательна. Она введена, по сути, только для реализации концепции удаления/отлинковки файлов и освобождения физического места под них (в некоторых FS — ещё и для хранения некоторой метаинформации о файлах). Так что любая группировка файлов определённого типа в каталоги — это задача теггирования. В противном случае можно было бы скинуть все файлы в один каталог, предварительно позаботившись об эффективном индексе. К примеру, я знаю, что «тег» "/bin/sh" определяет файл-программу активной командной оболочки по умолчанию, а «тег» "/bin/cat" — файл-программу дубликации и объединения содержимого дескрипторов. Мне совсем необязательно знать, специальные ли эти файлы, или те же, что и у файла "/bin/busybox". Или, может, там определяется, что реальный файл определяется другой записью в каталоге. Вся логика работы с информацией определяется этими метками, которые записаны в стартовых скриптах и бинарных программах, причём реальное соответствие меток можно менять в процессе работы системы.
Соответственно, линки из каталогов на индексные блоки файлов (или на индекс первого блока файла в таблице их размещения) — это и есть поддержка теггирования на уровне файловой системы. Смысл каталожных записей-тегов в любом случае определяется внешним образом (например, где линкуются файлы, принадлежащие тому или иному пользователю).
К примеру, ничто, кроме ограничений FS, не мешает использовать в качестве имён каталожных записей конкатенацию RDFовских URI (например, процент-кодированных) для субъекта и предиката, а в качестве прилинкованного файла — файл специального синтаксиса (типа), который определит объект отношения, отличный от простого бинарного файла. Другое дело, что смысла так делать нет, поскольку с тегами надо как-то работать, как-то организовывать составные ключи для поисков и т.п. — т.е. полноценную базу знаний лучше делать с помощью специализированных средств.
Но во всяком случае, лично для меня вполне хватает сделать для определённых файлов изображений ссылки в каталогах ".../кто изображён", ".../год фотографирования" и ".../описание поездки".
Ага, а потом попробуйте удалить какой-нибудь файл с десятком хардлинков, или скопировать его, сохранив все тэги. Это понятно, что find может найти все файлы, с одинаковым inode, но это совсем не интуитивно.
Хардлинки и теги — разные вещи.
Хардлинки и теги — разные вещи.
Для этого хардлинки и созданы, что бы отлинковывание от одного каталога не повлекло пропажи файлов. Если надо удалить файл — достаточно «убрать все теги» в соответствующем интерфейсе.
Для копирования, действительно, надо использовать спецкоманду (rsync). Но ведь, что бы правильно скопировались обычные метаданные файлов так, как вам надо, необходимо тоже использовать соответствующую программу и соответствующий её ключ.
> Это понятно, что find может найти все файлы, с одинаковым inode, но это совсем не интуитивно.
В принципе, это единственное разумное зерно, о котором заставил задуматься NickMitin: где/как хранить индекс обратных ссылок по инодам. Единственная сложность здесь — производительность, т.к. такой индекс необходимо будет обновлять для каждого действия с каталогом. Т.е. по хорошему эту задачу надо отдать СУБД. Необходимо только договориться разработчикам интерфейсов с теггированием, о том, как искать соответствующие файлы этой СУБД в корневом каталоге тома.
Тогда придётся подключать том через FUSE или использовать файлы-трансляторы в стиле HURD.
Но, в принципе, можно реализовать и внутри файловой системы extX, только смысл? Даже с ресурсными форками MacOSX есть огромная проблема, связанная с тем, что они тихо пропадают при копировании на файловую систему, не поддерживающую данную фичу. С тегами будет ещё сложнее.
Поэтому технологически проще использовать иерархии каталогов + хардлинки в качестве НОМ различных систем теггирования + локальные базы обратных ссылок на файлы, обновляемые при
монтировании и других дисковых операциях.
Для копирования, действительно, надо использовать спецкоманду (rsync). Но ведь, что бы правильно скопировались обычные метаданные файлов так, как вам надо, необходимо тоже использовать соответствующую программу и соответствующий её ключ.
> Это понятно, что find может найти все файлы, с одинаковым inode, но это совсем не интуитивно.
В принципе, это единственное разумное зерно, о котором заставил задуматься NickMitin: где/как хранить индекс обратных ссылок по инодам. Единственная сложность здесь — производительность, т.к. такой индекс необходимо будет обновлять для каждого действия с каталогом. Т.е. по хорошему эту задачу надо отдать СУБД. Необходимо только договориться разработчикам интерфейсов с теггированием, о том, как искать соответствующие файлы этой СУБД в корневом каталоге тома.
Тогда придётся подключать том через FUSE или использовать файлы-трансляторы в стиле HURD.
Но, в принципе, можно реализовать и внутри файловой системы extX, только смысл? Даже с ресурсными форками MacOSX есть огромная проблема, связанная с тем, что они тихо пропадают при копировании на файловую систему, не поддерживающую данную фичу. С тегами будет ещё сложнее.
Поэтому технологически проще использовать иерархии каталогов + хардлинки в качестве НОМ различных систем теггирования + локальные базы обратных ссылок на файлы, обновляемые при
монтировании и других дисковых операциях.
есть же Gnome-related проект, который это реализует.
А совсем отказаться от иерархии не получится так легко и просто. Можно только обернуть всё ещё одни уровнем абстракции
А совсем отказаться от иерархии не получится так легко и просто. Можно только обернуть всё ещё одни уровнем абстракции
ВНЕЗАПНО: ln -s
Напишите скрипт, который даст вам приятный интерфейс, и будут вам тэги. По крайней мере у меня именно так )
Напишите скрипт, который даст вам приятный интерфейс, и будут вам тэги. По крайней мере у меня именно так )
Хм :)
в области хемо и биоинформаткии сейчас очень большая проблема с семантикой, которая должна использоваться для описания любых если не всех биологических и химических процессов. Из огромного стэека бесполезной/полубесполезной информации с ее помощью структурируют инфорамцию. Думаю, что от древа тэгов никуда не денешся.
в области хемо и биоинформаткии сейчас очень большая проблема с семантикой, которая должна использоваться для описания любых если не всех биологических и химических процессов. Из огромного стэека бесполезной/полубесполезной информации с ее помощью структурируют инфорамцию. Думаю, что от древа тэгов никуда не денешся.
А в мире инженеров реализация всегда превалирует над интерфейсом.
Вот и с файловой системой так.
Да-да, те же самые стеллажи (диски) с коробками и ящиками (папки), в которых хранятся перфокарты (файлы).
Вообще-то стеллажи, папки и т.п. появились задолго до инженеров. Подобная структура хранения очень естественная для человека. Возьмите в пример библиотеки, появившиеся задолго до открытия электричества, не говоря о изобретении компьютеров.
Меня волнует вопрос зачем переносить принцип устройства файловой системы в интерфейс работы с ней?
Принцип устройства файловой системы вобщем-то повторяет интерфейс хранения данных до изобретения файловых систем.
Меня папки очень часто ставят в тупик. В какую папку положить рабочий документ, техническое задание...
Это означает лишь что вы не можете продумать хорошую иерархическую структуру.
А если подняться на еще уровень выше, то какую ценность как единица информации несет папка? А никакой! Это просто тег, причем тег со связью один-к-одному то есть на одну единицу нормального контента можно назначить только один тег...
Неправда, это не тег, а элемент иерархии. Опять же для вас папка не несет никакой информации, если не можете сделать нормальную иерархическую структуру.
Вкладывать теги друг в друга. Тогда мы получаем унылый беспомощный иерархический рубрикатор.
Вот уж где трабла для мозга это нелинейная иерархия.
Использовать ярлыки в других папках. Извините, занятие для извращенцев.
Между прочим Линукс, который вы хвалите ниже, изобилует линками.
… я осознал насколько легко и просто жить без необходимости раскладывать все по папкам.
Музыка и видео у меня скачиваются в одно место, а интерфейсом служит UPnP AV сервер, который сам определяет теги для контента:… Я даже честно не знаю что и как у меня в этой папке, которая названа media происходит.
Лично я как-то привык знать где и что у меня лежит. Терпеть не могу если софт начинает решать за меня где что и как хранить. В рамках разумного, конечно, как, например, линуксовые соглашения о структуре rootfs.
Увы, приходится сталкиваться с папками и файлами, когда работаешь с документами, потому что отсутствие механизма тегирования на уровне ФС, лишает меня возможности положить все в одну папку и забыть про ее устройство.
И получаете «кашу» из тегов. Да, возможно, я не способен произвести нормальное тегирование, поэтому для меня это «каша».
Естественно, при системе тегирования навигацией по контенту становится поиск, а основным представлением — его результаты.
Поиск зависит от реализации. Поиск не гарантирует что вы не найдете лишнего или что не пропустите что-то нужное. Отчатси поэтому и важно знать самому что где лежит.
Тем кому отказ от папок кажется чем-то немыслимым и ужасным, подумайте над тем, что вы, скорее всего пользуетесь поискоориентированной файловой системой каждый день. Это Гугл. :)
Если бы была возможность построить нормальную иерархию для всего контента, по которому ищет Гугл, при этом иерархию приемлимую для всех людей (ведь каждый построил бы по-своему), то поиск был бы на порядок быстрее и качественнее.
Вот и с файловой системой так.
Да-да, те же самые стеллажи (диски) с коробками и ящиками (папки), в которых хранятся перфокарты (файлы).
Вообще-то стеллажи, папки и т.п. появились задолго до инженеров. Подобная структура хранения очень естественная для человека. Возьмите в пример библиотеки, появившиеся задолго до открытия электричества, не говоря о изобретении компьютеров.
Меня волнует вопрос зачем переносить принцип устройства файловой системы в интерфейс работы с ней?
Принцип устройства файловой системы вобщем-то повторяет интерфейс хранения данных до изобретения файловых систем.
Меня папки очень часто ставят в тупик. В какую папку положить рабочий документ, техническое задание...
Это означает лишь что вы не можете продумать хорошую иерархическую структуру.
А если подняться на еще уровень выше, то какую ценность как единица информации несет папка? А никакой! Это просто тег, причем тег со связью один-к-одному то есть на одну единицу нормального контента можно назначить только один тег...
Неправда, это не тег, а элемент иерархии. Опять же для вас папка не несет никакой информации, если не можете сделать нормальную иерархическую структуру.
Вкладывать теги друг в друга. Тогда мы получаем унылый беспомощный иерархический рубрикатор.
Вот уж где трабла для мозга это нелинейная иерархия.
Использовать ярлыки в других папках. Извините, занятие для извращенцев.
Между прочим Линукс, который вы хвалите ниже, изобилует линками.
… я осознал насколько легко и просто жить без необходимости раскладывать все по папкам.
Музыка и видео у меня скачиваются в одно место, а интерфейсом служит UPnP AV сервер, который сам определяет теги для контента:… Я даже честно не знаю что и как у меня в этой папке, которая названа media происходит.
Лично я как-то привык знать где и что у меня лежит. Терпеть не могу если софт начинает решать за меня где что и как хранить. В рамках разумного, конечно, как, например, линуксовые соглашения о структуре rootfs.
Увы, приходится сталкиваться с папками и файлами, когда работаешь с документами, потому что отсутствие механизма тегирования на уровне ФС, лишает меня возможности положить все в одну папку и забыть про ее устройство.
И получаете «кашу» из тегов. Да, возможно, я не способен произвести нормальное тегирование, поэтому для меня это «каша».
Естественно, при системе тегирования навигацией по контенту становится поиск, а основным представлением — его результаты.
Поиск зависит от реализации. Поиск не гарантирует что вы не найдете лишнего или что не пропустите что-то нужное. Отчатси поэтому и важно знать самому что где лежит.
Тем кому отказ от папок кажется чем-то немыслимым и ужасным, подумайте над тем, что вы, скорее всего пользуетесь поискоориентированной файловой системой каждый день. Это Гугл. :)
Если бы была возможность построить нормальную иерархию для всего контента, по которому ищет Гугл, при этом иерархию приемлимую для всех людей (ведь каждый построил бы по-своему), то поиск был бы на порядок быстрее и качественнее.
ППКС! Об этом же я писал чуть выше :)
> Это означает лишь что вы не можете продумать хорошую иерархическую структуру.
> Это означает лишь что вы не можете продумать хорошую иерархическую структуру.
Не могу и этого не скрываю. И не понимаю зачем-бы мне это нужно было.
Не могу и этого не скрываю. И не понимаю зачем-бы мне это нужно было.
Затем, чтобы структурировать данные. Иерархическая структура исконно используется природой для упорядочивания, вы чем-то хуже остальной природы?
Я хочу иметь дополнительные аттрибуты у данных, которые позволять объединять их в логические блоки. Иерархическая файловая система мне в этом не помогает, а мешает.
Хорошо у вас есть фильм. Район №9. Какую иерархию вы выстроите?
Фильмы/2009/sci-fi/Райнон №9
Фильмы/sci-fi/2009/Райнон №9
Фильмы/свежак/Райнон №9
Фильмы/от ольги/Райнон №9
вы для всех документов можете выстроить однозначную иерархию?
Фильмы/2009/sci-fi/Райнон №9
Фильмы/sci-fi/2009/Райнон №9
Фильмы/свежак/Райнон №9
Фильмы/от ольги/Райнон №9
вы для всех документов можете выстроить однозначную иерархию?
Да, для всех. В данном случае, режиссёр/год/фильм
вы наверное никогда со сложными иерархиями не работали… где не десяток, а тысячи категорий и они не всегда однозначно друг в друга вкладываются.
кстати, а как в вашей структуре выбрать все фильмы 2009 года? все равно придется поиск по всем режиссёрам запускать.
кстати, а как в вашей структуре выбрать все фильмы 2009 года? все равно придется поиск по всем режиссёрам запускать.
Так в случае тегов всё равно придётся поиск по всем режиссёрам запускать. Никакого преимущества не получается.
а в случае иерархии — ну, все фильмы 2009 года да, а все фильмы Михалкова — нет.
И не машите на индексы, индексировать упорядоченную информацию — имена файлов в директории — одно, какой бы сложной не была уже имеющаяся схема упорядочивания; индексировать разнородную информацию — са-авсем другое, гораздо сложнее и дороже. Сравните объём метаданных ФС на серверах и объём индекса гуголя, который описывает ту же самую информацию, что эти серверы; сложность устройства ФС и гуголя; надёжность ФС и надёжность гуголя.
а в случае иерархии — ну, все фильмы 2009 года да, а все фильмы Михалкова — нет.
И не машите на индексы, индексировать упорядоченную информацию — имена файлов в директории — одно, какой бы сложной не была уже имеющаяся схема упорядочивания; индексировать разнородную информацию — са-авсем другое, гораздо сложнее и дороже. Сравните объём метаданных ФС на серверах и объём индекса гуголя, который описывает ту же самую информацию, что эти серверы; сложность устройства ФС и гуголя; надёжность ФС и надёжность гуголя.
Ага я прихожу к вам в гости и с чем нить не сильно крепким и предлагаю посмотреть свежий фантастический фильм. Во точно тут на днях про какой-то Район на хабре читал.
Опишите алгоритм поиска в вашей иерархии?
Опишите алгоритм поиска в вашей иерархии?
Так же, как и в случае тегов — по имени ;)
Хорошо, названия не помню, помню что фантастика. И? Как найти его в вашей иерархии?
Драйвер файловой системы может поддерживать настраиваемые «динамические теги». Скажем, можно один раз настроить тег «свежак» на
и тогда все фильмы и музыка не старше 100 дней будут считаться свежаком.
Останется только выделить все сущности с тегами «фильм», «фантастика» и «свежак».
Кстати, с помощью автотегов можно проставлять и теги «фильм», «музыка» и т.п.
Но тут возникает проблема интернационализации. В US-локали фильмам будет проставляться тег «movie», а в RU — «фильм». И все автотеги, зависящие от этого тега, накроются медным тазом.
свежак = CreationDate >= Now — (60 days) AND HasTags(«фильм», «музыка»)
и тогда все фильмы и музыка не старше 100 дней будут считаться свежаком.
Останется только выделить все сущности с тегами «фильм», «фантастика» и «свежак».
Кстати, с помощью автотегов можно проставлять и теги «фильм», «музыка» и т.п.
Но тут возникает проблема интернационализации. В US-локали фильмам будет проставляться тег «movie», а в RU — «фильм». И все автотеги, зависящие от этого тега, накроются медным тазом.
Кстати. «свежий» — синоним «2009»
Вот вы выстроили однозначную логику для организаци иерархии данных у себя на компе. Скачиваете данные (например музыку какого-то исполнителя) а в них логика построения иерархии отличается от вашей.
Ваши действия?
Каждый раз ручками перестраивать иерахию (переименовывать, перемещать папки)?
Интегрировать «как есть», тем самым ломая однозначность логики своей иерархии?
Ваши действия?
Каждый раз ручками перестраивать иерахию (переименовывать, перемещать папки)?
Интегрировать «как есть», тем самым ломая однозначность логики своей иерархии?
Вопрос не мне, но тем не менее
~/шняга/111/посмотреть/Райнон №9 :)
~/шняга/111/посмотреть/Райнон №9 :)
Основная задача ФС (для пользователя) — это упорядочение данных и предоставление доступа к ним. Обратите внимание на слово «система» в аббревиатуре «ФС». Это суть пользовательского интерфейса ФС.
Задача «обеспечить целостность» лежит вообще-то на оборудовании, просто оказалось, что часть этой задачи выгодно переложить на бак-энд ФС, так получается коммерчески выгоднее, дешевле, чем делать более надёжное оборудование (обеспечивать защиту от сбоев питания и прочего). Это вообще не должно волновать пользователя.
Задача «обеспечить целостность» лежит вообще-то на оборудовании, просто оказалось, что часть этой задачи выгодно переложить на бак-энд ФС, так получается коммерчески выгоднее, дешевле, чем делать более надёжное оборудование (обеспечивать защиту от сбоев питания и прочего). Это вообще не должно волновать пользователя.
Чё, вы каждый раз так делаете? Мне вас жаааааалко!
Я пишy «cat fopen example» > myfile.txt
Я пишy «cat fopen example» > myfile.txt
Вы так написали, как-будто это первый закон Ньютона. :)
Затем же, зачем и тегирование или любой другой способ навести порядок в информации.
Да, не сочтите эти слова за оскрбление. Ведь про себя я написал я не способен произвести нормальное тегирование, поэтому для меня это «каша».
Да, не сочтите эти слова за оскрбление. Ведь про себя я написал я не способен произвести нормальное тегирование, поэтому для меня это «каша».
Потому что лично меня это сосем не волнует.
Не волнует и не смущает. Я-же пользователь.
Кстати, если уж вы говорите о пользовательском интерфейсе, вам достаточно будет пользовательских программ для обращения к вашим тегам. В частности, виндовые (да и не только) «папки» уже давно не одно и то же, что и каталог на уровне файловой системы (к примеру, возьмите что-то типа Zip folders или удалённых сетевых файловых хранилищ).
Можно взять и написать виртуальный интерфейс доступа к данным так, как вы этого хотите.
А потом поделиться с нами — было бы здорово.
Можно взять и написать виртуальный интерфейс доступа к данным так, как вы этого хотите.
А потом поделиться с нами — было бы здорово.
Нет, интерфейс я писать не хочу, их уже 100500 и без меня. Я хочу чтобы через поколение ФС поддерживали-бы теги, а ОС имели-бы хороший интерфейс к этому функционалу.
чем вас не устраивают файловые потоки?
куда более универсальное средство.
куда более универсальное средство.
Никто ими не пользуется.
будьте первым!
даже проводник с IE ими пользуются, хоть и для других целей
даже проводник с IE ими пользуются, хоть и для других целей
Никто ими не пользуется для тегирования
Тогда поясните, что вы подразумеваете под поддержкой теггирования на уровне ФС? Технические способы вам предоставлены: файловые потоки и использование отдельной иерархии каталогов.
Или вы на самом деле хотите, что бы поддержка тегов пришла со стороны разных вендоров, причём совместимым образом? Тогда как определять смысл? К примеру, если вы воткнёте винт друга и станете искать по тегу «Жена» — вы же не захотите смотреть жену друга (если, конечно, вы этого специально не добивались).
Или вы на самом деле хотите, что бы поддержка тегов пришла со стороны разных вендоров, причём совместимым образом? Тогда как определять смысл? К примеру, если вы воткнёте винт друга и станете искать по тегу «Жена» — вы же не захотите смотреть жену друга (если, конечно, вы этого специально не добивались).
Да, именно этого я и хочу. Чтобы теги стали сущностью уровня файла или папки.
А если я при вставленном диске друга попробую поискать «жену», то произойдет тоже самое, если у него там есть файлы или с именем «жена».
А если я при вставленном диске друга попробую поискать «жену», то произойдет тоже самое, если у него там есть файлы или с именем «жена».
Т.е. на самом деле речь идёт о том, что бы сделать обратный индекс «тегов» (в виде «обратных ссылок») по инодам… В принципе, это доступно примитивной базой данных. Вопрос только в обеспечении ссылочной целостности. Надо подумать, как это реализовать — мне кажется это уже где-то есть…
По второй части — про «жену». :) Вам достаточно просто текстовых тегов или нужна какая-то семантичность: не просто «жена», а «жена NickMitin» (к примеру)?
Не понимаю что это меняет.
Ну, в принципе, на таком простом уровне — ничего. Но, вообще, представьте себе, что куча компов в вашей сети экспортирует файлы с тегами, которые актуальны для гораздо меньшего количества персон. Теги становятся неактуальными. Собственно, идея Semantic web в том, что бы работать с такими смысловыми различиями легко. Что бы можно было отфильтровать либо всех жён, либо только своих, смотря что нужно. :)
тегами тоже никто не будет пользоваться, вот увидите
Их никто не будет назначать. Это естественно. Нужно придумать крутой автомат по назначению тегов.
Надеяться, что все будут тегировать свой контент с улыбкой на лице — глупо.
Надеяться, что все будут тегировать свой контент с улыбкой на лице — глупо.
Да не надо ничего назначать! Откройте для себя strigi, nepomuk, тем более, что вы с Linux знакомы!
Поставьте персональный гугль и перестаньте смущаться совсем :)
Как говорили выше — правильный путь не отказаться от иерархии, а объединить ее с тегами. Мне кажется, что это ближе всего к Gmail получится.
ИМХО новая идея должна не перечеркивать старую (как классическое использование тэгов перечеркивает классическую иерархию), а усовершенствовать её.
Я бы предложил:
А) Тэги в формате не просто «%значение%», а «%имя%: %значение%» т.е как они сделаны в ID3
B) Поддержка иерархии в тэгах, например (навскидку) «жанр: фантастика / научная фантастика»
Что также поможет приверженцам класической иерархии %)
В.1) Можно подумать об иерархии не только значения, но и имени тэга…
Я бы предложил:
А) Тэги в формате не просто «%значение%», а «%имя%: %значение%» т.е как они сделаны в ID3
B) Поддержка иерархии в тэгах, например (навскидку) «жанр: фантастика / научная фантастика»
Что также поможет приверженцам класической иерархии %)
В.1) Можно подумать об иерархии не только значения, но и имени тэга…
(A): или в формате префикс: значение (или в виде полного URI), как предлагается в «Semantic web»
(B) и (B.1): Т.е. подумать об онтологиях и о языках её описания/определения.
(B) и (B.1): Т.е. подумать об онтологиях и о языках её описания/определения.
в RDF префиксы только для различения пространства имён.
тоесть только чтобы имена были уникальными.
если в формулах семантического веба
subject predicate object или subject property value
objectом может быть только «файл», получается тоже самое имя-значение.
тоесть только чтобы имена были уникальными.
если в формулах семантического веба
subject predicate object или subject property value
objectом может быть только «файл», получается тоже самое имя-значение.
Вообще-то и в RDF, и в N3 префиксы только для удобного сокращения. Никто не мешает писать полные URI.
> получается тоже самое имя-значение.
Да, т.е. для классификации файлов predicate будет «classifiesFile» или «isDepictedInFile». Но никто не мешает подгрузить внешнюю онтологию, что бы например проставленное отношение:
«my: Жена my:isDepictedInFile file:///var/tmp/pub/tanya.jpg .»
при просмотре файловой системы женой автоматически трансформировалось в:
«wifes: Я husbands:isDepictedInFile file:///mnt/husbands_nfs/pub/tanya.jpg .»
> получается тоже самое имя-значение.
Да, т.е. для классификации файлов predicate будет «classifiesFile» или «isDepictedInFile». Но никто не мешает подгрузить внешнюю онтологию, что бы например проставленное отношение:
«my: Жена my:isDepictedInFile file:///var/tmp/pub/tanya.jpg .»
при просмотре файловой системы женой автоматически трансформировалось в:
«wifes: Я husbands:isDepictedInFile file:///mnt/husbands_nfs/pub/tanya.jpg .»
я имел ввиду немного наоборот поставленные утверждения
file:///var/tmp/pub/tanya.jpg mime:type mime:image
file:///var/tmp/pub/tanya.jpg dc:topic my: жена
file:///var/tmp/pub/tanya.jpg dc:author allter.habrahabr.ru
file:///var/tmp/pub/tanya.jpg dc:date «2009-08-27»
file:///var/tmp/pub/tanya.jpg my:wearingStyle my:nude
тогда поисковые запросы можно делать типа:
«найти изображения моей голой жены сделанные алтером в августе этого года»
или с подключением логики:
«когда это альтер фотал мою голую жену»
и результатом будут даты с пруфлинками на файлы
в принципе, интересная идея…
file:///var/tmp/pub/tanya.jpg mime:type mime:image
file:///var/tmp/pub/tanya.jpg dc:topic my: жена
file:///var/tmp/pub/tanya.jpg dc:author allter.habrahabr.ru
file:///var/tmp/pub/tanya.jpg dc:date «2009-08-27»
file:///var/tmp/pub/tanya.jpg my:wearingStyle my:nude
тогда поисковые запросы можно делать типа:
«найти изображения моей голой жены сделанные алтером в августе этого года»
или с подключением логики:
«когда это альтер фотал мою голую жену»
и результатом будут даты с пруфлинками на файлы
в принципе, интересная идея…
Угу — тогда надо придумать удобный интерфейс для простановки таких тегов (или найти существующий). Давно уже хочу, например, что бы было просто не только делать из большой фотки фотки в «веб-разрешении», но и просматривать такие фотки в режиме «только уникальные» со ссылками на актуальные версии, как это реализовано в некоторых веб-галереях.
я соглашусь, что подобный пересмотр парадигмы назревает. и связано это прежде всего с усложнением семантики хранимой информации.
поясню — под словом «семантика» я в данном случае понимаю связь объекта внутри компьютера с внешним смыслом (In Real World). Как файл или папка могут быть связаны с чем-то из реального мира? Это может быть название — одна связь, и еще дата — вторая связь. Ну, и расширение файла может что-то означать — хотя традиционно расширение используется для маркирования внутрисистемных смыслов.
Когда компьютеры преимущественно считали данные, это всех устраивало. Сейчас компьютеры помогают людям в их повседневных делах — и количество смыслов, с которыми хочется связать внутренние объекты, возрастает. Так, один и тот же файл, например, фотка может быть связан и местом — Анапой, и с людьми, которые там изображены — Маша, Петя и Коля, и еще там красивый закат. Все эти смыслы конечно можно запихнуть в одно название — «Анапа 2008 с Колей Машей и Петей, и красивый закат.jpg» — но это будет полный бред.
(Люди, которые говорят, что достаточно сделать hardlink'и в разные папки и иметь одинаковые файлы с разными названиями, типа
\Media\2008\Анапа.jpg
\Media\Анапа\закат.jpg
\Media\Коля\С Машей.jpg
\Media\Маша\Анапа 2008.jpg
\Media\Петя\Маша.jpg
не представляют, о чем говорят. Даже из полного пути нельзя извлечь информацию, что у этого файла одно и тоже содержание. А заглянуть в одну папку, запомнить размер и дату файла, затем в другую папку — там запомнить размер и дату файла, сравнить — понять что это одно и тоже… и так много раз — на это даже программистский мозг не способен, не говоря уж о простом пользователе. А какой интересный будет результат запроса по словам «Анапа закат Коля Маша Петя 2008» — вылезут пять файлов с одним и тем же! )
А семантика может быть не только у фоток, самое ценное — это документы, у которых описаны семантические поля, что приближает нас к Web3.0
И разумеется, такие вещи, как семантическая стуктура, должны иметь поддержку не на уровне программ, а на уровне операционных систем или даже глубже — на уровне структур хранения данных.
В общем, NickMitin все правильно говорит, я и сам об том же думаю.
поясню — под словом «семантика» я в данном случае понимаю связь объекта внутри компьютера с внешним смыслом (In Real World). Как файл или папка могут быть связаны с чем-то из реального мира? Это может быть название — одна связь, и еще дата — вторая связь. Ну, и расширение файла может что-то означать — хотя традиционно расширение используется для маркирования внутрисистемных смыслов.
Когда компьютеры преимущественно считали данные, это всех устраивало. Сейчас компьютеры помогают людям в их повседневных делах — и количество смыслов, с которыми хочется связать внутренние объекты, возрастает. Так, один и тот же файл, например, фотка может быть связан и местом — Анапой, и с людьми, которые там изображены — Маша, Петя и Коля, и еще там красивый закат. Все эти смыслы конечно можно запихнуть в одно название — «Анапа 2008 с Колей Машей и Петей, и красивый закат.jpg» — но это будет полный бред.
(Люди, которые говорят, что достаточно сделать hardlink'и в разные папки и иметь одинаковые файлы с разными названиями, типа
\Media\2008\Анапа.jpg
\Media\Анапа\закат.jpg
\Media\Коля\С Машей.jpg
\Media\Маша\Анапа 2008.jpg
\Media\Петя\Маша.jpg
не представляют, о чем говорят. Даже из полного пути нельзя извлечь информацию, что у этого файла одно и тоже содержание. А заглянуть в одну папку, запомнить размер и дату файла, затем в другую папку — там запомнить размер и дату файла, сравнить — понять что это одно и тоже… и так много раз — на это даже программистский мозг не способен, не говоря уж о простом пользователе. А какой интересный будет результат запроса по словам «Анапа закат Коля Маша Петя 2008» — вылезут пять файлов с одним и тем же! )
А семантика может быть не только у фоток, самое ценное — это документы, у которых описаны семантические поля, что приближает нас к Web3.0
И разумеется, такие вещи, как семантическая стуктура, должны иметь поддержку не на уровне программ, а на уровне операционных систем или даже глубже — на уровне структур хранения данных.
В общем, NickMitin все правильно говорит, я и сам об том же думаю.
Это все понятно, тэги это хорошо итд. Но основной вопрос — как вы представляете интерфейс доступа в рамках такой модели?
Поясняю. Вот у нас есть директория 1, в ней директории 2,3 и файлик 4 в директории 3. Т.о. что бы открыть файл 3, необходимо получить доступ к объекту с скажем так uri file:///1/3/4. Или /1/3/4. Допустим у файла есть тэги «фильм, фантастика». Допустим что можно получить доступ как /фильм/4 или /фантастика/4. А как если несколько тегов? /фильм/фантастика/4? /фантастика/фильм/4? Следовательно мне нужно строить сразу ВСЕ дерево для поиска? А как в этой радости искать? Как и какие теги выводить пользователю? У меня же могут быть тысячи тегов на разные случаи. Не буду же я выбирать на каждом этапе пути из тысяч возможных. Или вы предлагаете ходить по несуществующему дереву в слепую?
Поясняю. Вот у нас есть директория 1, в ней директории 2,3 и файлик 4 в директории 3. Т.о. что бы открыть файл 3, необходимо получить доступ к объекту с скажем так uri file:///1/3/4. Или /1/3/4. Допустим у файла есть тэги «фильм, фантастика». Допустим что можно получить доступ как /фильм/4 или /фантастика/4. А как если несколько тегов? /фильм/фантастика/4? /фантастика/фильм/4? Следовательно мне нужно строить сразу ВСЕ дерево для поиска? А как в этой радости искать? Как и какие теги выводить пользователю? У меня же могут быть тысячи тегов на разные случаи. Не буду же я выбирать на каждом этапе пути из тысяч возможных. Или вы предлагаете ходить по несуществующему дереву в слепую?
Интерфейсы файловых систем разрабатываются уже 50 лет. Вы хотите, чтобы я тут в комментах решил все проблемы, которые могут возникнуть у теговых систем?
Погуглите, какими примитивными были файловые системы на ленточных накопителях. В начале ленты хранится TOC — список маркеров начала файлов. Выбираешь нужный файл, затем система перематывает плёнку и запускается считывание данных. Ни тебе аттрибутов, ни папок — ничего! И сравните что у нас теперь?
Я не очень понял проблему, которую вы попытались описать, если честно. Но в ваших рассуждениях заметен стереотипный подход. Вы пишете «строить дерево для поиска», «пути из тысяч возможных». Зачем? Если файл существует, у него есть уникальный тег — id, допустим. Это его обозначение для системы. Для человека нужно более понятное описание, допустим, тег "". Нет, лучше писать конкретно.
Итак, у нас есть файл с тегами: [123456789, «Звездные войны», «Атака Клонов», «mkv», «кино», «фантастика», «дубляж», «AC3», «русский», «английский», «hdtv», «720р», «torrents.ru»]
Понятно, что однозначно файл определяется только уникальным тегом с номером, но пользователю может быть достаточно выбрать или ввести теги «Атака клонов» и «720p», и он получит тот самый единственный файл, который соответствует этим критериям.
Конечно, если это огромная файловая помойка или есть много версий похожих файлов, то нужно вводить теги, которые помогут различить файлы, но в принципе это не отличается от текущей ситуации, когда есть
StarWars: Attack of the Clones.HDTV.AC3.Rus.Eng[torrents.ru].avi
и
StarWars_-_Attack of the Clones_-_720p_AC3_[Rus,Eng](torrents.ru).avi
Пользователю эти два варианта предоставляют одинаково много/мало информации о содержимом. Только в случае, когда вся полезная информация кодируется в имени файла, зачем нужно их раскидывать по папкам? А если начать использовать имена папок как теги, то возникает диллема — либо имя папки дублирует информацию в имя файла, например
\Видео\HDTV\StarWars: Attack of the Clones\StarWars: Attack of the Clones.HDTV.AC3.Rus.Eng[torrents.ru].avi
либо в папке лежит файл с коротким именем
\Видео\HDTV\StarWars: Attack of the Clones\SW2.avi
и имя файл без полного пути к нему несёт мало информации. А захотите вы скопировать файл на флешку или DVD — будете всю структуру папок ради одного файла дублировать?
В общем, вот примерно такие вопросы юзабилити нужно решать.
Погуглите, какими примитивными были файловые системы на ленточных накопителях. В начале ленты хранится TOC — список маркеров начала файлов. Выбираешь нужный файл, затем система перематывает плёнку и запускается считывание данных. Ни тебе аттрибутов, ни папок — ничего! И сравните что у нас теперь?
Я не очень понял проблему, которую вы попытались описать, если честно. Но в ваших рассуждениях заметен стереотипный подход. Вы пишете «строить дерево для поиска», «пути из тысяч возможных». Зачем? Если файл существует, у него есть уникальный тег — id, допустим. Это его обозначение для системы. Для человека нужно более понятное описание, допустим, тег "". Нет, лучше писать конкретно.
Итак, у нас есть файл с тегами: [123456789, «Звездные войны», «Атака Клонов», «mkv», «кино», «фантастика», «дубляж», «AC3», «русский», «английский», «hdtv», «720р», «torrents.ru»]
Понятно, что однозначно файл определяется только уникальным тегом с номером, но пользователю может быть достаточно выбрать или ввести теги «Атака клонов» и «720p», и он получит тот самый единственный файл, который соответствует этим критериям.
Конечно, если это огромная файловая помойка или есть много версий похожих файлов, то нужно вводить теги, которые помогут различить файлы, но в принципе это не отличается от текущей ситуации, когда есть
StarWars: Attack of the Clones.HDTV.AC3.Rus.Eng[torrents.ru].avi
и
StarWars_-_Attack of the Clones_-_720p_AC3_[Rus,Eng](torrents.ru).avi
Пользователю эти два варианта предоставляют одинаково много/мало информации о содержимом. Только в случае, когда вся полезная информация кодируется в имени файла, зачем нужно их раскидывать по папкам? А если начать использовать имена папок как теги, то возникает диллема — либо имя папки дублирует информацию в имя файла, например
\Видео\HDTV\StarWars: Attack of the Clones\StarWars: Attack of the Clones.HDTV.AC3.Rus.Eng[torrents.ru].avi
либо в папке лежит файл с коротким именем
\Видео\HDTV\StarWars: Attack of the Clones\SW2.avi
и имя файл без полного пути к нему несёт мало информации. А захотите вы скопировать файл на флешку или DVD — будете всю структуру папок ради одного файла дублировать?
В общем, вот примерно такие вопросы юзабилити нужно решать.
Я говорю о том, что интерфейс вашей системы с тегами будет абсолютно не совместим с интерфейсом доступа к файлам в иерархической системе. Таким образом требуется полностью переписать _все_ ПО. Собственно говоря вопрос — зачем это делать, если можно реализовать необходимый функционал в том ПО, которое этого действительно требует?
Этого требует все ПО. Надо сначала придумать как круто реализовать теги (чтобы не мыслить ограничено), а потом подумать как не сломать все, что до этого написано.
~$ for path in `dpkg-query -L bash`; do [ -f $path ] && echo $path; done
/bin/bash
/etc/skel/.bashrc
/etc/skel/.profile
/etc/skel/.bash_logout
/etc/bash.bashrc
/usr/share/doc/bash/CHANGES.gz
/usr/share/doc/bash/NEWS.gz
Представьте себе что etc, usr, share, doc, bash это теги, а символ "/" обозначает «И».
Тег текущего пользователя — его имя или "~"
Команды выполняются, при просмотре тега отображаются сопряженные теги и файлы
/bin/bash
/etc/skel/.bashrc
/etc/skel/.profile
/etc/skel/.bash_logout
/etc/bash.bashrc
/usr/share/doc/bash/CHANGES.gz
/usr/share/doc/bash/NEWS.gz
Представьте себе что etc, usr, share, doc, bash это теги, а символ "/" обозначает «И».
Тег текущего пользователя — его имя или "~"
Команды выполняются, при просмотре тега отображаются сопряженные теги и файлы
tag:///тип: видео: фильм/жанр: фантастика — выводит список фильмов по тэгам
file:///4 — выводит конкретный файл
file:///4 — выводит конкретный файл
Все, что вы описали, Алан Купер опубликовал еще в первом издании About Face. И дал довольно целостное решение.
С тэгами есть одно большое неудобство — их надо проставлять. И чем больше объём информации тем меньше желание это делать.
Папка, если хотите, является интуитивно понтяным тэгом по-умолчанию. «Дополнительные» тэги легко добавиь в винде без всяких примочек — правый клик на файле -> свойства -> сводка -> ключевые слова. Эти данные учитываются при поиске, но я не думаю что их кто-то заполняет. Например, я скачал mp3, есть тэги — хорошо, нет — не очень, но самому их проставлять банально лень, в лучшем случае переименую файл, чтобы можно было определить что это такое.
Папка, если хотите, является интуитивно понтяным тэгом по-умолчанию. «Дополнительные» тэги легко добавиь в винде без всяких примочек — правый клик на файле -> свойства -> сводка -> ключевые слова. Эти данные учитываются при поиске, но я не думаю что их кто-то заполняет. Например, я скачал mp3, есть тэги — хорошо, нет — не очень, но самому их проставлять банально лень, в лучшем случае переименую файл, чтобы можно было определить что это такое.
когда файлов 10 000, то все их не переименуешь… :(
«переименую файл» или «загляну в папку и все пойму» расходует человеческое время, и если есть возможность это автоматизировать, это надо автоматизировать.
речь о том, что базовые теги должны проставляться автоматически и поддерживаться на уровне средства хранения данных, а не на уровне ОС или приложения. ОС или приложение должны осуществлять интерфейс к управлению тегами, в частности, ОС должна анализировать файлы и расставлять теги, какие сможет понять. В идеальном случае система должна анализировать содержание на уровне семантики, что по сути является идеологией Web3.0 aka Семантический Интернет.
«переименую файл» или «загляну в папку и все пойму» расходует человеческое время, и если есть возможность это автоматизировать, это надо автоматизировать.
речь о том, что базовые теги должны проставляться автоматически и поддерживаться на уровне средства хранения данных, а не на уровне ОС или приложения. ОС или приложение должны осуществлять интерфейс к управлению тегами, в частности, ОС должна анализировать файлы и расставлять теги, какие сможет понять. В идеальном случае система должна анализировать содержание на уровне семантики, что по сути является идеологией Web3.0 aka Семантический Интернет.
Так поиск среди автоматических тегов — реализовыван. Скажите, что, нет средств найти все варианты исполнения песни Money на жёстком диске? У меня — есть, у меня есть strigi, который индексирует всё, что он умеет (теги музыкальных файлов, имена файлов, типы файлов, метаданные из документов, EXIF из картинок), так что среди «автоматных» тегов поиск есть.
В «ручных» тегах я не нуждаюсь — у меня есть структура директорий, и поиск по ней — быстрый. Имена директорий ничем не хуже ваших тегов, даже лучше — помимо группировки, я имею упорядочивание.
В «ручных» тегах я не нуждаюсь — у меня есть структура директорий, и поиск по ней — быстрый. Имена директорий ничем не хуже ваших тегов, даже лучше — помимо группировки, я имею упорядочивание.
А как автоматизировать расстановку тэгов на видео, аудио, фотках без ИИ? Вроде бы есть веб сервисы, которые по названию аудио/видео файла выдают теги, но на для моих фоток, они бесполезны — надо просматривать каждую и писать: «Я», «Я, Аня, пляж», «Кот», тем более по закону Мерфи искать захочется по несуществующему тегу («закат»), все варианты не предусмотришь.
Имена папок + название файла = минимальное возможное количество усилий и даже на это способны немногие. Файловая система здесь совершенно не причём и поддержка есть, например, альтренативные потоки в NTFS. Просто при большом объеме некатегоризированной информации никто не будет маниакально проставлять все возможные теги. У пользователей как правило находятся более важные дела. Я часто откладываю подобную работу на потом, которое никогда не наступает.
Имена папок + название файла = минимальное возможное количество усилий и даже на это способны немногие. Файловая система здесь совершенно не причём и поддержка есть, например, альтренативные потоки в NTFS. Просто при большом объеме некатегоризированной информации никто не будет маниакально проставлять все возможные теги. У пользователей как правило находятся более важные дела. Я часто откладываю подобную работу на потом, которое никогда не наступает.
Да всё потому, что придумывали ФС те, кто с компьютером работают, каждый день, и лишь потом, по желанию, используют компьютер как средство развлечения. Это почти как сравнивать каталог библиотеки с двумя-тремя полками над вашим рабочим столом.
Если вы создали документ для работы — для вас критически важно, на следующий день, быстро найти именно его, выполнив конечное количество кликов мышью, вместо того, что бы догадываться как его протегирует система и наедяться, что он окажется на первой странице результатов вашего замечательного поисковика.
Для повседневной работы, строгая, иерархическая система полностью себя оправдывает (прим. при соответствующей культуре обращение с ней, конечно). Для музыки, фоток, видео, справочника по вашему любимому языку, состоящему их нескольких тысяч отдельных файлов — система тегирования и поиска действительно полезна, но стоит ли это возлагать на ФС и ОС, не уверен, Spotlight в OS X не плозосправлется с такими с задачей на ряду с классической реализацией ФС.
На мой взгляд, задачу поиска и доступа к данным лучше возложить на конечные приложения (плееры, редакторы) которые гораздо лучше знают что тэгировать и как каталогизировать, либо добавить в оболочку ОС отдельный проводник / Finder который по-другому сможет представить данные, и организовать быстрый поиск и доступ к ним.
P.S. Ещё один аргумент к вышесказанному, необходимость поддержки API для приложений, там всё придётся оставить как есть.
P.P.S. Может кто-то хочет отказаться от самого понятия «файла», как еденицы организации, изоляции, манипуляции и представления данных?
Если вы создали документ для работы — для вас критически важно, на следующий день, быстро найти именно его, выполнив конечное количество кликов мышью, вместо того, что бы догадываться как его протегирует система и наедяться, что он окажется на первой странице результатов вашего замечательного поисковика.
Для повседневной работы, строгая, иерархическая система полностью себя оправдывает (прим. при соответствующей культуре обращение с ней, конечно). Для музыки, фоток, видео, справочника по вашему любимому языку, состоящему их нескольких тысяч отдельных файлов — система тегирования и поиска действительно полезна, но стоит ли это возлагать на ФС и ОС, не уверен, Spotlight в OS X не плозосправлется с такими с задачей на ряду с классической реализацией ФС.
На мой взгляд, задачу поиска и доступа к данным лучше возложить на конечные приложения (плееры, редакторы) которые гораздо лучше знают что тэгировать и как каталогизировать, либо добавить в оболочку ОС отдельный проводник / Finder который по-другому сможет представить данные, и организовать быстрый поиск и доступ к ним.
P.S. Ещё один аргумент к вышесказанному, необходимость поддержки API для приложений, там всё придётся оставить как есть.
P.P.S. Может кто-то хочет отказаться от самого понятия «файла», как еденицы организации, изоляции, манипуляции и представления данных?
fix:… хоя, к примеру, Spotlight в OS X не плохо справлется с такой задачей, на ряду с классической реализацией ФС…
>отказаться от самого понятия «файла»
это было бы любопытно. :) интересно пофантазировать, что могло бы получиться.
это было бы любопытно. :) интересно пофантазировать, что могло бы получиться.
Я думал и об этом, но пока не придумал ничего, чего бы «не было в Симпсонах (с)»
Ничего не получится. Это понятие останется. Максимум — переименуется (мокросовт пытался переименовать «файл» в «документ»). Это слишком базовое понятие в теории информации — последовательность данных, имеющая имя — чтобы исчезнуть.
Что это за фричество вы мне подсунули?
Вы наверное путаете основы и выводы.
Например, отказаться от понятия «электрон» наука не сможет никогда. Оно может модифицироваться, перестанет считаться нейтральным, переименуется, и т. д., но само понятие об электроне как о некоей единице заряда, которая может быть выделена в свободном виде, останется. Это понятие появилось задолго до появления собственно слова «электрон» — оно появилось практически сразу же с первых опытов по электростатике.
Например, отказаться от понятия «электрон» наука не сможет никогда. Оно может модифицироваться, перестанет считаться нейтральным, переименуется, и т. д., но само понятие об электроне как о некоей единице заряда, которая может быть выделена в свободном виде, останется. Это понятие появилось задолго до появления собственно слова «электрон» — оно появилось практически сразу же с первых опытов по электростатике.
А что, про TagFS никто не вспомнил?
Если абстрактно рассматирвать сложность или мозговые усилия, то иерархически класифицировать(разделить на папки) все таки затратнее, чем описание объекта(тегирование).
Что касается файловой системы, как писали выше, саму файловую систему менять незачем, нужно менять на уровне приложения или операционной системы(теже музыкальные библиотеки с тегами).Тоесть разделить доступ к информации с ее хранением.
В обще с музыкой и фильмами не все так однозначно.
Они уже тегированы — год выпуска, жанр, актеры все есть в описании фильма или же в ID3, а мы уже потом эти теги обрабатываем, разбивая на папки. Тоесть выполняем работу машины.
На данный момент есть программы для определенных файлов: музыкальные библиотеки, есть для набора различных файлов:Google Desktop, Yandex Desktop.
Но, все таки, такого рода программам есть куда расти.
Что касается файловой системы, как писали выше, саму файловую систему менять незачем, нужно менять на уровне приложения или операционной системы(теже музыкальные библиотеки с тегами).Тоесть разделить доступ к информации с ее хранением.
В обще с музыкой и фильмами не все так однозначно.
Они уже тегированы — год выпуска, жанр, актеры все есть в описании фильма или же в ID3, а мы уже потом эти теги обрабатываем, разбивая на папки. Тоесть выполняем работу машины.
На данный момент есть программы для определенных файлов: музыкальные библиотеки, есть для набора различных файлов:Google Desktop, Yandex Desktop.
Но, все таки, такого рода программам есть куда расти.
Теги нужно поддерживать на уровне FS!
вот к примеру, есть файл aha-take_on_me.mp3. Без тегов у него объем 3 500 00 байт, но пользователь Вася добавил тег «NewAge», тег «1985», тег «Track 01» и тег «Best Collection». Куда эти теги записались? Правильно, в сам файл. В результате размер файла стал уже не 3 500 000, а 3 500 031 байт.
Для файловой системы — это разные файлы, а для Васи — один и тот же файл. Более того, у них будет разный хэш и с раздачей торрентов с этим файлом будут проблемы.
вот к примеру, есть файл aha-take_on_me.mp3. Без тегов у него объем 3 500 00 байт, но пользователь Вася добавил тег «NewAge», тег «1985», тег «Track 01» и тег «Best Collection». Куда эти теги записались? Правильно, в сам файл. В результате размер файла стал уже не 3 500 000, а 3 500 031 байт.
Для файловой системы — это разные файлы, а для Васи — один и тот же файл. Более того, у них будет разный хэш и с раздачей торрентов с этим файлом будут проблемы.
Я полагаю так, в случае с mp3 все, что отоноситься к самом у произведению (автор, название, год выпуска, жанр) заведомо должно хранитьяс в этом файле со времени его создания как часть самого произведения, а тег «Best Collection» это личное и его пользователь тегирует сам и это не нужно вставлять в файл.
И как в случае с фотогалереей метаинформация и теги должны храниться отдельно от файла с изображением.При этом изменять файловую систему незачем.
И как в случае с фотогалереей метаинформация и теги должны храниться отдельно от файла с изображением.При этом изменять файловую систему незачем.
Что за максимализм?
Если кому-то удобнее теги, то это не повод удалять другую структуру. Иерархия — простой способ ограничить контекст. Можно тегами полностью сэмулировать иерархию, но сделав, например линейный список файлов с тегами, нам придется постоянно кэшировать запросы по тегам в поиске, оптимизируя которую мы придем к сохраненным выборкам, сохранив которые на диске, мы опять вернемся к существующей иерархии :)
Мне например дерево тоже не полностью удовлетворяет, но симлинки меня полностью устраивают.
Если кому-то удобнее теги, то это не повод удалять другую структуру. Иерархия — простой способ ограничить контекст. Можно тегами полностью сэмулировать иерархию, но сделав, например линейный список файлов с тегами, нам придется постоянно кэшировать запросы по тегам в поиске, оптимизируя которую мы придем к сохраненным выборкам, сохранив которые на диске, мы опять вернемся к существующей иерархии :)
Мне например дерево тоже не полностью удовлетворяет, но симлинки меня полностью устраивают.
Не совсем так. Закэшированные поисковые запросы можно будет изменять и удалять, не затрагивая при этом сами данные. И пусть структура сохранённых запросов будет древовидной (хотя это и не обязательно, можно и для них использовать теги), этот способ, тем не менее, более гибкий, чем у существующих ФС. Чем-то похоже на библиотеки в Windows 7.
Таким образом автор не справился с упорядочиванием информации в иерархической структуре, но мечтает что кто-то за него будет проставлять теги…
Удивительно, казалось-бы, после перехода на такую «враждебную к пользователю» операционную систему, как Линукс я осознал насколько легко и просто жить без необходимости раскладывать все по папкам. Музыка и видео у меня скачиваются в одно место, а интерфейсом служит UPnP AV сервер, который сам определяет теги для контента: тегирует исполнителями, альбомами, жанрами, годами и т.д. песни; видео — актерами и режиссерами плюс сериалы — сезонами и сериями. Я даже честно не знаю что и как у меня в этой папке, которая названа media происходит.
Фотографии я сгружаю с фотоаппарата в один контейнер и баш-скрипт раскладывает их по папкам сам, поворачивая, делая превьюшки и добавляя их в веб-интерфейс просмотра.
Программы в Линуксе тоже ставятся так, что я даже не подозреваю о том, что файловая система есть и что она как-то устроена.
А какой у вас windows то был? или вы как всегда ругаетесь на XP? :)
Я даже и не знаю где у меня лежит музыка. подозреваю, что часть где-то на винте а часть где-то у брата, сестры и отца на компах так, как когда они их зачем-то выключают у меня некоторые песни не проигрываются :(
вчера отключили инэт… и я вспомнил, что Василий К. лежит у моего друга на компе (10км от меня).
Фото у меня лежит в D:\Фото. возможно они там даже в каком-то определённом порядке лежать.
смотрю через через Библиотеки.
Документы хранятся в папке C:\Users\baks\Documents. просто тупо кучей файлов. ни разу туда не заходил.
жмём левым мизинцем на win, вводим 1-2 слова из документа и жмём Enter (иногда 2-3 раза «стрелку вниз»).
Куда у меня устанавливаются программы? О_о
я всегда думал, что в «C:\Program Files», а недавно выяснилось, что большинство прог лежи в «C:\Program Files (x86)».
в общем не понял я что вы хотели донести этим постом… Лично я считаю, что древовидная структура очень удобна тем, что она очень понятна большинству пользователей. А на неё уже можно навесить любые извращения. и Вы легко можете дописать и встроить в интерфейс Линукса и Винды свои.
Я может чего не понимаю, но почему нельзя сочетать иерархию и теги? Я давно так храню файлы, только для тегов естественно приходится пользоваться каталогизатором. Работаешь и хранишь файлы в иерархии каталогов, но если надо к примеру найти все файлы по какой-либо тегу юзаешь каталогизатор. Была б такая фс цены бы ей не было.
Теги уже давно применяются для той же музыки. Любой музыкальный проигрыватель имеет свою «библиотеку», где хранит музыку по тегам, а не по папкам.
Я лично этим не пользуюсь, т.к. люблю точно знать, где и что у меня находится и полностью всё это контролировать. А если на винтах столько говна, что вы не в состоянии в нём разобраться — пора их нафиг отформатировать. Не будьте Плюшкиным, всё это есть в интернете.
Я лично этим не пользуюсь, т.к. люблю точно знать, где и что у меня находится и полностью всё это контролировать. А если на винтах столько говна, что вы не в состоянии в нём разобраться — пора их нафиг отформатировать. Не будьте Плюшкиным, всё это есть в интернете.
Кстати, если покупать музыку, то там с тегами всё в порядке, можно сразу жить (в itunes) и не думать о файловой системе. А вот как автоматически оформлять теги для пиратской музыки из разных источников — не представляю, тем более если имеем дело с надёрганными отдельными треками.
Так что вот выход — жить по честному :-)
С покупными фильмами уже сложнее — не слышал чтобы ним прикручивался imdb ID, подобная мета-информация.
Так что вот выход — жить по честному :-)
С покупными фильмами уже сложнее — не слышал чтобы ним прикручивался imdb ID, подобная мета-информация.
Хотя, бывает, конечно, и свободная музыка…
А вот как автоматически оформлять теги для пиратской музыки из разных источников — не представляю, тем более если имеем дело с надёрганными отдельными треками.
MusicBrainz?
Покупать музыку можно не только в виде mp3 :)
Обычно freedb спасает, но случай отдельных треков, конечно, патологический
Обычно freedb спасает, но случай отдельных треков, конечно, патологический
Посмотрите на LFS
Думаю не стоит отказываться от иерархии.
Файловая система должна быть доступна из скриптов.
Набросок работы с фс
~$ # слева иерархическая фс, справа — теги
~$ # теги разделяются символом "/"
~$ # текущая метка — "~" — я
~$ mv /mnt/flash/agile_web_development.pdf dev/rails/book/
~$ cd rails/
~/rails$ ls
book sreencast podcast project
~/rails$ cd
~$ # копирование с расстановкой тегов
~$ musicmv /mnt/flash/radiohead music
~$ # тагов слишком много, необходима выборка категорий
~$ ls music/:artist
bach beethoven…
~$ ls book/:press
orelly pragmatics
~$ # копирование в иерархическую фс
~$ cp -r «music/bach/:cd/:track — :title» /mnt/flash
Система требует большого количества данных. Они доступны для некоторых типов информации (музыка, фотографии), обработка других требует ручного ввода данных (ISDN). Должны быть сложности в интеграции с существующими средствами.
Думаю не стоит отказываться от иерархии.
Файловая система должна быть доступна из скриптов.
Набросок работы с фс
~$ # слева иерархическая фс, справа — теги
~$ # теги разделяются символом "/"
~$ # текущая метка — "~" — я
~$ mv /mnt/flash/agile_web_development.pdf dev/rails/book/
~$ cd rails/
~/rails$ ls
book sreencast podcast project
~/rails$ cd
~$ # копирование с расстановкой тегов
~$ musicmv /mnt/flash/radiohead music
~$ # тагов слишком много, необходима выборка категорий
~$ ls music/:artist
bach beethoven…
~$ ls book/:press
orelly pragmatics
~$ # копирование в иерархическую фс
~$ cp -r «music/bach/:cd/:track — :title» /mnt/flash
Система требует большого количества данных. Они доступны для некоторых типов информации (музыка, фотографии), обработка других требует ручного ввода данных (ISDN). Должны быть сложности в интеграции с существующими средствами.
СУБД еще ни кто не отменял, если ФС не устраивает.
не поленюсь ещё раз про отказ от иерархии —
возможно, пользователю будет гораздо удобнее
«левым мизинцем нажав кнопку и набрав пару тэгов»
он этого не сможет сделать софт.
софту нужно совершенно точно и однозначно знать где его файлы.
с этой целью облака тэгов не справятся.
возможно, пользователю будет гораздо удобнее
«левым мизинцем нажав кнопку и набрав пару тэгов»
он этого не сможет сделать софт.
софту нужно совершенно точно и однозначно знать где его файлы.
с этой целью облака тэгов не справятся.
не, нифига. У файла есть номер (inode) где он лежит. А где он в папке отображается — это уже хрень и вообще файловой системой не используется. Приложения, почти все, сейчас-таки смотрят лишь на путь к файлу, но умные (а-ля Amarok плеер под KDE) уже научились даже НЕ ПРЕРЫВАТЬ произведение если файл перемещаешь в другую папку вообще нахрен. Все предельно просто: смотрится inode (на случай хардлинков) и плюс в теги пишется uid. По этим двум вещам мало тго что можно всегда за файлом следить, так ещё и если перекодировать — uid в тегах останется =).
далее, в том же linux сейчас «теги» используются мегаактивно через символические ссылки.
ну скажем
/dev/by-uuid/uuuid-device
/dev/by-name/named-device -> /dev/by-uuid/uuuid-device
/dev/by-capacity/500gb/1 -> /dev/by-uuid/uuud-device
ну и так далее в таком духе. Плюсы решения очевидны — endpoint всегда один, хотя его линки имеют точно такие же права. При этом всегда можно докопаться до настоящего инодного файла.
короче, в linux/macosx в этих всех тегированиях и тп в фс элементарно нет смысла. Под виндой же я тоже когда-то парился по этому поводу… лет эдак 5 назад.
далее, в том же linux сейчас «теги» используются мегаактивно через символические ссылки.
ну скажем
/dev/by-uuid/uuuid-device
/dev/by-name/named-device -> /dev/by-uuid/uuuid-device
/dev/by-capacity/500gb/1 -> /dev/by-uuid/uuud-device
ну и так далее в таком духе. Плюсы решения очевидны — endpoint всегда один, хотя его линки имеют точно такие же права. При этом всегда можно докопаться до настоящего инодного файла.
короче, в linux/macosx в этих всех тегированиях и тп в фс элементарно нет смысла. Под виндой же я тоже когда-то парился по этому поводу… лет эдак 5 назад.
а ну если очень хочется
/my files folder/file.txt
ln /my files folder/file.txt /my folder/tagA/file.txt
ln /my files folder/file.txt /my folder/tagB/file.txt
усё, у нас аж 3 ссылки на 1 inode в системе. Файлы абсолютно идентичные, при удалении/изменении любого, все остальные тоже изменятся. Физически на винте это все равно 1 файл. Ограничение — такие линки можно делать только в пределах одной фс (т.е. одного раздела фс) — по понятным причинам: иначе inode #12345 может быть хоть на 10 разных разделах и вести на разные файлы.
/my files folder/file.txt
ln /my files folder/file.txt /my folder/tagA/file.txt
ln /my files folder/file.txt /my folder/tagB/file.txt
усё, у нас аж 3 ссылки на 1 inode в системе. Файлы абсолютно идентичные, при удалении/изменении любого, все остальные тоже изменятся. Физически на винте это все равно 1 файл. Ограничение — такие линки можно делать только в пределах одной фс (т.е. одного раздела фс) — по понятным причинам: иначе inode #12345 может быть хоть на 10 разных разделах и вести на разные файлы.
уже вроде упоминал — ИМХО лучшая (квази-идеальная) навигация по тэгам сделана в del.icio.us.
(в плагине для файрфокса).
если вам интересна тема —
оно стоит того, чтобы зарегистрироваться, поставить плагин и импортировать туда закладки.
этот подход вполне совместим с иерархией и потому приемлем и для софта.
в качестве интерфейсного решения ещё можно подумать на тему mindmap.
(в плагине для файрфокса).
если вам интересна тема —
оно стоит того, чтобы зарегистрироваться, поставить плагин и импортировать туда закладки.
этот подход вполне совместим с иерархией и потому приемлем и для софта.
в качестве интерфейсного решения ещё можно подумать на тему mindmap.
похоже на Evernote в какой-то степени, не?
А если я вдруг забыл что я хочу найти? =) Для этого и нужны папки. Они user-friendly ^_^
При определении оптимальных принципов организации данных следует исходить из того, что данные для пользователя в разных случаях могут представлять собой сырые «данные», «информацию», «знания» или «мудрость», и на каждом из этих уровней будут удобны разные инструменты и способы организации.
Работа с «данными» — это их копирование, перемещение, удаление, архивация и т. д. Это когда мы не лезем внутрь файлов, но нам требуются удобные средства управления их существованием, полнотой и сохранностью (либо гарантированным уничтожением). Поскольку такие монолитные структуры данных мы генерируем (и ликвидируем) динамически, оптимальным здесь будет именно иерархическое представление в виде файловой системы: одни структуры данных представляют собой под- или надмножества других. Не для юзера, так для админа.
Работа с «информацией» — это уже анализ формально регистрируемых признаков данных и их классификация по ним. Здесь уже простой иерархии будет недостаточно, а внедрение в нее множественных ссылок может вызвать неполадки на уровне «данных», что мы и наблюдаем в одной из русских версий Vista: там папка Documents and Settings (ака Users) формально содержит внутри саму себя, из-за чего возникают глюки при попытке подсчитать общий размер файлов на диске — одни и те же файлы учитываются множество раз, покуда хватает длины пути ФС. В целом все сводится к организации виртуальных папок (библиотек), важным свойством которых является то, что разные виртуальные папки могут содержать в себе одни и те же физически существующие данные. К примеру, все фотографии могут храниться рассортированными по датам или сессиям передачи с камеры, но в то же время пользователь может ввести альтернативную классификацию по лицам, местам съемки, условиям съемки и каким-либо другим критериям. Обращение к таким файлам будет производиться из той же командной строки, но с использованием другого синтаксиса, скажем, как в CGI-запросах, с поддержкой логических операций над критериями отбора. При этом внедрение БД-подобных схем обращения к данным не должно препятствовать возможности классического обращения к ним (что уже нарушено в Windows из-за замещения виртуальными папками физических, типа Temporary Internet Files).
На более высоких уровнях DIKW-иерархии предусматривается внедрение расширенных средств автоматизации операций первых двух уровней, содержит в себе обновляемую базу средств отчетности, анализа и визуализации данных (те же mind maps, к примеру), и в конечном итоге ведет с пользователем своего рода диалог, уточняя по ходу дела, что именно ему требуется сделать. И чтобы избежать недоразумений, пользователю крайне желательно уметь общаться с машиной на более низких уровнях. Не обязательно делать это постоянно, скорее уметь при необходимости — так же как разжечь костер, оказать первую помощь и т. д. по Хайнлайну. Большинство современных проблем с так называемыми ламерами происходит из-за абсолютного отсутствия понимания последними базовых принципов работы железа и ОС. И если продолжать по-майкрософтовски прятать от них эти особенности (даже когда они активно желают их знать), то в будущем, по мере возрастания роли ИТ и ИИ во всех сферах деятельности, это чревато куда большими проблемами, чем сейчас. Грубо говоря, если человек не контролирует железо, то железо контролирует человека.
Таким образом, какие бы новые, продвинутые и удобные средства работы с данными/информацией/знаниями/мудростью не включались в состав ОС, это не повод создавать препятствия (и снижать при этом производительность и эффективность) на более низких уровнях. ФС нуждается в расширении, а не вытеснении.
Работа с «данными» — это их копирование, перемещение, удаление, архивация и т. д. Это когда мы не лезем внутрь файлов, но нам требуются удобные средства управления их существованием, полнотой и сохранностью (либо гарантированным уничтожением). Поскольку такие монолитные структуры данных мы генерируем (и ликвидируем) динамически, оптимальным здесь будет именно иерархическое представление в виде файловой системы: одни структуры данных представляют собой под- или надмножества других. Не для юзера, так для админа.
Работа с «информацией» — это уже анализ формально регистрируемых признаков данных и их классификация по ним. Здесь уже простой иерархии будет недостаточно, а внедрение в нее множественных ссылок может вызвать неполадки на уровне «данных», что мы и наблюдаем в одной из русских версий Vista: там папка Documents and Settings (ака Users) формально содержит внутри саму себя, из-за чего возникают глюки при попытке подсчитать общий размер файлов на диске — одни и те же файлы учитываются множество раз, покуда хватает длины пути ФС. В целом все сводится к организации виртуальных папок (библиотек), важным свойством которых является то, что разные виртуальные папки могут содержать в себе одни и те же физически существующие данные. К примеру, все фотографии могут храниться рассортированными по датам или сессиям передачи с камеры, но в то же время пользователь может ввести альтернативную классификацию по лицам, местам съемки, условиям съемки и каким-либо другим критериям. Обращение к таким файлам будет производиться из той же командной строки, но с использованием другого синтаксиса, скажем, как в CGI-запросах, с поддержкой логических операций над критериями отбора. При этом внедрение БД-подобных схем обращения к данным не должно препятствовать возможности классического обращения к ним (что уже нарушено в Windows из-за замещения виртуальными папками физических, типа Temporary Internet Files).
На более высоких уровнях DIKW-иерархии предусматривается внедрение расширенных средств автоматизации операций первых двух уровней, содержит в себе обновляемую базу средств отчетности, анализа и визуализации данных (те же mind maps, к примеру), и в конечном итоге ведет с пользователем своего рода диалог, уточняя по ходу дела, что именно ему требуется сделать. И чтобы избежать недоразумений, пользователю крайне желательно уметь общаться с машиной на более низких уровнях. Не обязательно делать это постоянно, скорее уметь при необходимости — так же как разжечь костер, оказать первую помощь и т. д. по Хайнлайну. Большинство современных проблем с так называемыми ламерами происходит из-за абсолютного отсутствия понимания последними базовых принципов работы железа и ОС. И если продолжать по-майкрософтовски прятать от них эти особенности (даже когда они активно желают их знать), то в будущем, по мере возрастания роли ИТ и ИИ во всех сферах деятельности, это чревато куда большими проблемами, чем сейчас. Грубо говоря, если человек не контролирует железо, то железо контролирует человека.
Таким образом, какие бы новые, продвинутые и удобные средства работы с данными/информацией/знаниями/мудростью не включались в состав ОС, это не повод создавать препятствия (и снижать при этом производительность и эффективность) на более низких уровнях. ФС нуждается в расширении, а не вытеснении.
Очень хочется крикнуть используй Mac OS X, где фото лежит в iphote, музыка, видео, телешоу, подкасты итд в itunes, и тебя не волнует где это хранится на компе. Сразу есть поиск, разбивка на событие фильтрация итд итп.
На самом деле, продвижение в иерархии папок — не что иное, как поиск по тегом из набора имеющихся, с сужением области поиска. Поэтому грамотно продуманная структура папок зачастую позволяет найти файл быстрее, чем «придумать»/«найти ассоциацию» с тегом, искать по этому тегу, да еще и получать множество смежных результатов и выбирать из них.
Поэтому, мое мнение — самой удачной была бы смешанная система: когда структуру папок задаешь ты сам, но и теги можешь назначать (+автотеги). Тогда каждый поиск интуитивно будет выполнен пользователем самым удобным способом.
p.s. Все дело в том, что для неточного поиска сложно придумать набор тегов для поиска, который значительно ограничит результат, из которого, в свою очередь, можно быстро выбрать. Поэтому иногда проще отдаться алгоритму сужения поиску, заходя во вложенные папки — при грамотной иерархии категоризация происходит очень быстро, на подсознательному уровне.
Поэтому, мое мнение — самой удачной была бы смешанная система: когда структуру папок задаешь ты сам, но и теги можешь назначать (+автотеги). Тогда каждый поиск интуитивно будет выполнен пользователем самым удобным способом.
p.s. Все дело в том, что для неточного поиска сложно придумать набор тегов для поиска, который значительно ограничит результат, из которого, в свою очередь, можно быстро выбрать. Поэтому иногда проще отдаться алгоритму сужения поиску, заходя во вложенные папки — при грамотной иерархии категоризация происходит очень быстро, на подсознательному уровне.
Не знаю, прочитает ли кто этот пост, но всё же попытаюсь рассказать про концепцию, придуманную мной, «когда мне не хотелось спать» =)
Файловая система должна быть плоским хранилищем файлов и тегов. Тег — это по сути тот же файл, но ФС выделяет его в отдельный вид сущностей. Тегам, как и файлам, можно присваивать теги.
Более того, можно делать рекурсивные присваивания. Например, тег «system-tag» сам по себе является системным, поэтому он протегирован самим собой. К системным тегам, кроме того, можно отнести тег «hidden», означающий, что файл, или тег, которому он присвоен, является скрытым.
Получается, что тегу «hidden» присвоен тег «system-tag», а тегу «system-tag» присвоен тег «hidden».
Всем тегам присвоен системный тег «tag». Можно ещё ввести системные теги «read-only», «creation-date» и т.п.
В системе также будут зарегистрированы теги «author», «album», «title» и т.п. Аудиофайлу присваиваются теги «Sonata Arctica», «Silence», «Tallulah». Тегу «Sonata Arctica» присваивается тег «author», тегу «Silence» — «album», а тегу «Tallulah» — «title». С помощью такой теговой иерархии отпадает путаница с одинаковыми именами тегов (например, если фильм называется Silence, но мы хотим найти именно альбом группы Sonata Arctica, то мы сможем указать искать файлы, помеченные тегом Silence/album)
Теги, как я уже сказал, будут представлены в ФС в виде файлов, поэтому они могут содержать и полезную информацию внутри себя, такую как локализованные имена (album -> альбом), принцип присваивания (в случае автотегов) и т.п.
Хотел бы я попользоваться такой системкой…
Файловая система должна быть плоским хранилищем файлов и тегов. Тег — это по сути тот же файл, но ФС выделяет его в отдельный вид сущностей. Тегам, как и файлам, можно присваивать теги.
Более того, можно делать рекурсивные присваивания. Например, тег «system-tag» сам по себе является системным, поэтому он протегирован самим собой. К системным тегам, кроме того, можно отнести тег «hidden», означающий, что файл, или тег, которому он присвоен, является скрытым.
Получается, что тегу «hidden» присвоен тег «system-tag», а тегу «system-tag» присвоен тег «hidden».
Всем тегам присвоен системный тег «tag». Можно ещё ввести системные теги «read-only», «creation-date» и т.п.
В системе также будут зарегистрированы теги «author», «album», «title» и т.п. Аудиофайлу присваиваются теги «Sonata Arctica», «Silence», «Tallulah». Тегу «Sonata Arctica» присваивается тег «author», тегу «Silence» — «album», а тегу «Tallulah» — «title». С помощью такой теговой иерархии отпадает путаница с одинаковыми именами тегов (например, если фильм называется Silence, но мы хотим найти именно альбом группы Sonata Arctica, то мы сможем указать искать файлы, помеченные тегом Silence/album)
Теги, как я уже сказал, будут представлены в ФС в виде файлов, поэтому они могут содержать и полезную информацию внутри себя, такую как локализованные имена (album -> альбом), принцип присваивания (в случае автотегов) и т.п.
Хотел бы я попользоваться такой системкой…
А что насчёт nepomuk — не есть ли это шаг к тегированию?
А как насчет en.wikipedia.org/wiki/Desktop_search?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Файловые системы — отстой