Изобретен новый способ хранения файлов

> Download the code and try it . If it runs, send me a success report. Then try to crash it and send me bug reports.

Хе-хе, самокритично однако.

К новости: новым способом я бы пожалуй не назвал.

> Что вы думаете о перспективах этих исследований?

Опять пытаются облегчить. ИМХО, очередная попытка обыдления. Или я не прав?

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

В бигл это все так и реализованно и в глобальном масштабе ;-) Так что идея не нова, а смысл велосипеда я лично не асиливаю.

Самый главный недостаток подхода - трудность поиска и удаления НЕНУЖНЫХ и ЗАБЫТЫХ документов. А еще рай для всякой вирусоподобной дряни.

имхо не прав.
не могу сказать, "правильным ли путем идут товарищи",
но, имхо, что-то такое пора придумывать/доводить до ума
21 век на дворе как никак.

>Что вы думаете о перспективах этих исследований?

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

А теперь по теме.

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

Тут ведь что интересно? Если сделать "ключевые слова"/категории иерархическими, то вообще ничего не меняется. "~/work/prj1/otchet" заменяем на "Работа :: Проект1 :: Отчет". Получается просто лишний костыль.

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

Есть, правда, и плюс -- "простой пользователь" сможет постичь концепцию симлинков. Типа того, что файл "teenAsianSluts.wmv" может лежать одновременно в папках/категориях "movie" и "pr0n".

Но минусы все пречеркивают. Кроме упомянутого выше рекомендую подумать, как будет выглядеть перенос файлов с одного компьютера на другой (где категории другие).

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

В общем, мой вердикт -- как средство от бардака в голове это решительно не подходит. А вот как способ более удобной работы с ФС (не отказа от нее!) -- очень даже может быть, надо пробовать. Я вижу это примерно как программу для заполнения тегов в mp3 файлах, то бишь средство "интеграции" чужих файлов в свою ФС.

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

>очередная попытка обыдления. Или я не прав?

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

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

s/симлинков/хардлинков/

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

Это все из области антинаучной фантастики. Либо дело очень далекого будущего. Пока люди-то не все осиливают понимание содержания текста.

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

http://russian.joelonsoftware.com/Articles/HowMicrosoftLosttheWaronA.html

Мне нравятся папки, мне нравится древовидная структура, и мне нравится распихивать файлы по папкам. Это логичная и понятная система. Все эти винфс - бред сумасшедшего.

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

> Самый главный недостаток подхода - трудность поиска и удаления НЕНУЖНЫХ и ЗАБЫТЫХ документов.

Откройте для себя поле даты последнего воспроизведения в Banshee, Rhythmbox, amaroK и пр.

Похоже, сейчас будет очередной спор между теми кто ел устрицы, и кто их видел.

ip1981++

Не зря ведь средства индексации придуманы. Хотя определённую область применения(хотя я пока таковой не вижу) она возможно и найдёт, но скорее как "альтернативное представление", как это случилось в том же amaroK-е, "умные" плейлисты не означают отмены id3-тегов. А хранение "метаинформации" снаружи используется очень давно, вспомнить хотя бы те же файлы descript.ion

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

> Тут ведь что интересно? Если сделать "ключевые слова"/категории > иерархическими, то вообще ничего не меняется. "~/work/prj1/otchet" > заменяем на "Работа :: Проект1 :: Отчет". Получается просто лишний > костыль.

вот мне тоже самое пожалуйста, только с приличным интерфейсом. что бы я мог сказать "ага!, эта дирка не только /home/Projects/aaa, но еще и /shared/Projects/group1/coolproject10/bbb". желательно что бы это еще и на разных дисках работало :-)

> Откройте для себя поле даты последнего воспроизведения в Banshee, > Rhythmbox, amaroK и пр.

охохо.. кабы atime еще и работал так как от него хочется.. потому что grep -r aaa bbb ни разу не означает что я в последнее время обращался к файлику bbb/ccc.

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

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

> Ещё лучше для каждого файла держать два ключевых слова...

маловато будет! тем более что существующие файловые системы устроены не так.

Дайте мне нормальное средство текстового поиска по содержимому распространённых форматов типа pdf и можете смело отправляться нах в обнимку со своими winfs и прочей хернёй.

>> Самый главный недостаток подхода - трудность поиска и удаления НЕНУЖНЫХ и ЗАБЫТЫХ документов.
> Откройте для себя поле даты последнего воспроизведения в Banshee, Rhythmbox, amaroK и пр.
> Похоже, сейчас будет очередной спор между теми кто ел устрицы, и кто их видел.

Этих утриц все кушали еще более 25 лет назад. Отройте для себя access time и modification time, в Unix/Linux/Windows.

Кушать можно как в консоли man find , так и в GUI (KDE find file & folders)


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

"A human user cannot simply remember where everything is placed... Manual file management can quickly become overwhelming."

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

"Разруха не в клозетах, разруха в головах" (с) Булгаков

Beagle?

>> Тут ведь что интересно? Если сделать "ключевые слова"/категории иерархическими, то вообще ничего не меняется. "~/work/prj1/otchet" заменяем на "Работа :: Проект1 :: Отчет". Получается просто лишний костыль.

>вот мне тоже самое пожалуйста, только с приличным интерфейсом. что бы я мог сказать "ага!, эта дирка не только /home/Projects/aaa, но еще и /shared/Projects/group1/coolproject10/bbb". желательно что бы это еще и на разных дисках работало :-)

Ниасилил. Тебе надо ГУЙ для создания хардлинков?

> Кушать можно как в консоли man find , так и в GUI (KDE find file & folders)
забыл man stat и man locate.

если там какие-то преймущества над find+stat+locate - это маленькими патчами к locate, и kernel для online update notification.
Ну и GUI front-end к locate , а то пока только к find есть.

> Ниасилил. Тебе надо ГУЙ для создания хардлинков?

ага. а еще хардлинки на дирки и хардлинки или хотя бы способ атомарно поменять местами хардлинк и софтлинк. а еще..

s/и хардлинки //

>> Ниасилил. Тебе надо ГУЙ для создания хардлинков?

>ага. а еще хардлинки на дирки или хотя бы способ атомарно поменять местами хардлинк и софтлинк. а еще..

Кстати да. Меня удивляет отсутствие средств работы с *линками в konqueror. Может это каким костылем прикручивается?

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

Патчики - это неинтересно. Вас никто не заметит и не оценит. Здесь же цель видна явно и чётко - очень громко и вонюче пукнуть, чтоб все ахнули, умилились, всплеснули руками от восторга и носились с твоим "решением", как дурак с писаной торбой, ещё очень-очень долго. Конечному юзеру 95% всего этого нах не надо, но кого это волнует?

Интересно, а вот, к примеру, /dev тоже завернут в мегахранилище быдлодокументов? Ну, это я к тому, что кроме продвинутых секретарш/домохозяек, бывают и другие "пользователи" ФС. О них-то идеологи подумали или пока нет?

> Интересно, а вот, к примеру, /dev тоже завернут в мегахранилище быдлодокументов? Ну, это я к тому, что кроме продвинутых секретарш/домохозяек, бывают и другие "пользователи" ФС. О них-то идеологи подумали или пока нет?

Быдло более интересно, потому что его больше и оно охотнее отдаёт бабло за всякие погремушки.

> ага. а еще хардлинки на дирки и хардлинки или хотя бы способ атомарно поменять местами хардлинк и софтлинк. а еще..

Ниасилила ...
"хардлинк на диркУ" - это на /dev/null что ли?

А вот, например, в каком формате хранить изображения картин? Так, чтобы были теги: автор, название, размер картины, год создания (включая, например, "Вторая половина XIX века"), место хранения оригинала и т. д.

Уж не говорю, что к простому txt не хватает тегов.

Вот в таком направлении можно двигаться, это будет полезно.

Вы не поняли, но скорее всего просто не захотели понять.

Мне как пользователю не интересно лезть в консоль и задавать рекурсивный поиск по каталогу с музыкой, чтобы узнать, что я давно не слушал. Нет, мне вовсе несложно это сделать. Мне даже не лень прочитать соответствующие маны. Только зачем? Я просто сделаю в баньши smart playlist, который будет динамически обновляться по запросу, скажем, "всё, что я не слушал больше месяца". Это _удобно_, потому что я сразу получаю доступ к тому, что ищу.

Точно так же я не буду сломя голову бегать по каталогам с фотографиями и среди кучи ненужного отсеивать нужное. Я просто сделаю в F-Spot поиск по меткам и _сразу_ увижу отсеянное. Видите ли, я ценю своё время и экономлю его.

Кому-то нравится по любому поводу лазить в консоль и по сто раз запускать просмотрщики/прослушивательщики? На здоровье. Только не называйте это потом мейнстримом :)

В любом формате, в который можно записать тэги IPTC. А если нельзя, то пользоваться софтом, который пишет так называемый sidecar, то есть сопровождающий файл к этим файлам изображений.

Файловые, шмайловые... вот жеж людям в выходные делать нефиг... ext3/jfs - наше фсио! А еще чуть-чуть - и ZFS вообще всех зарулит.

>В бигл это все так и реализованно и в глобальном масштабе ;-) Так что идея не нова, а смысл велосипеда я лично не асиливаю.

Если переписать бигль с нуля, выкинув нафиг моно, тогда смысл изобретения чего-то другого пропадет.
ИМХО, подобный инструмент должен быть написан и использоваться в стиле slocate.

Подходы индекса не новы и сие поделие на жаве:
http://srcportal.net/is.html
пыталось сразу поддержать веб-интерфейс над склерозницей (индексом) и любую FS под низОм. Индекс имхо должен быть вне иерархии и не портить оригинальные файлы (Вместо тагов - использовать смещения от начала файла).
Предлагается совместно разработать RFC для формата/протокола для текстового индекса (если не использовать BDB, или LightSQL - как тот мужик), так как ascii текст - всех переживёт включая краши дисков и частичные потери индекса (в отличие от бинарей).

Кстати тот проект я забросил - кому близка идея и кто всерьёз захочет развивать (и не перегружать ненужностями) - подхватите пожалуйста (у меня к сожалению нет сейчас времени). http://sourceforge.net/projects/ais/
Можно поменять на GPL.
Из минимальной функциональности нужен ещё только кажется intersection (union прост) - для ключей, и всё.
В идеале надо - драг-энд-дропы через клипборд и нативные плагины для мозиллы и мейл-клиентов.
Тогда одним махом/кликом - инфа летит к вам в коробочку в тот момент когда вы её встретили (и только тот один/первый раз когда вы к ней соприкасаетесь, не считая бекапов) и вы её вытяните по тем-же ключам в отдалённом будущем из селла или через войс-интерфейс ;)
(второе соприкосновение)
Это вместо мутыженья файлопомоек и траты жизненных циклов на поддержание доступности информации.

Это же человековская природа, блин - ассоциативные связи.

/Anode

С какой это радости?

Симлинки создаются, хе-хе, при перетаскивании файла в новое место, там dropdown menu возникает: скопировать файл, переместить его или создать символическую ссылку. C хардлинками, да, хуже.

>тэги IPTC

Спасибо.

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

http://strigi.sourceforge.net/

http://www.solarix.ru/index-en.shtml

>>Самый главный недостаток подхода - трудность поиска и удаления НЕНУЖНЫХ и ЗАБЫТЫХ документов

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

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

это как раз искуственная иерархия - вносит гемморой. Дерево - это подмножество графа и наши ассоциации/категории почти никогда нельзя втиснуть в иерархию. Потом ключевые слова не должны быть уникальны, их может быть 2, 1, даже 0 (в последнем случае мы увы не ценим уже проделанную мозгом работу по отнесению данного документа к какой-то категории, и это тоже легально - предпочесть grep'ать документ в будущем. Но - если работа (пусть за секунду) проделана - почему не сохранить эту работу в виде ключа-ассоциации? И скорее всего именно этот ключ придёт в голову когда нибудь в будущем.

Какой бред сумасшедшего коммивояджера!!

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

Я настаиваю - что авто-индексация, поиск итд - совершенно ортогонально ассоциативным связям. Последние - это то что прошло через вас и там задержалось, то-есть что осталось у вас в голове. И это как пойнтеры _из_ мозга конкретного человека во внешние ресурсы. То что намолотит там авто-индексатор - ничем не отличается от миллионов записей которые изрыгнёт гугель (они - шум, и пока через мозг не пройдут - ничто). В пределе - все токены, слова и их сочетания из текста, что будет стремиться просто к словарю - для больших текстов. Вот _прочитав_ и осознав пару записей - вы сможете что-то сказать. Минимум сознания - ваша ассоциация. У другого человека - может быть, и скорее всего - совершенно своё.
Когда вы принимаете решение grep'пить ФС - то ставите задачу и получаете результат. В этот момент ваш мозг получает новые пойнтеры. Их нельзя терять - сохраните то на что вы потратили процессорное время в виде ключей!

>Пока люди-то не все осиливают понимание содержания текста.

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

Угу, а еще текстовый поиск по содержанию картинок, видео, куче custom форматов типа какого-нибудь MindManager и т.д. Не уверен, что в такой системе нужно хранить все (уверен, что не), но лично я внятную реализацию очень хотел бы видеть. Правда, кроме free-tagging нужен выбор из иерархического списка категорий - но файл должен уметь принадлежать к нескольким категориям! А симлинки - можно, наверное, и с ними извратиться, но неудобно - в частности, поиск плохой. Но что однозначно - этот подход не прокатит для "нормального" юзера. Там мозги нужны в комплекте.

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

Они не ленятся - они боятся.
Их запугали: в компутерах всё не так. Имя состоит из 8 букв и ещё 3 букв разделённых точкой ;)
(ну, может, сейчас немного не так, но далеко не ушло)
Это из опыта преподавания в колледже и курсах для взрослых во времена dos3.3. Тогда было проще. 2 панели нортона (ступор на дуализме одного и того-же файла в 2х обличьях, но это не в счёт по сравнению с количеством кнопок и крестиков, наверное). Ступор наступает - когда много чужого и непонятного. Иерархические (какие-какие? Почему оно (подавляющее) должно маппить мир в иерархию), директории, файлы, да ещё их различие. вашу мать - не надо столько других слов. Ключевые слова - это имена, и всё. Дата - другой индекс, может единственно идущий автоматом. Сделайте работу с компьютером простой! Имя (одно из) - получай список, выбирай, нах. Просто как яйца.

если уж на то пошло - самый удобный интерфейс для масс - command-line.
Тётки боявшиеся кнопки Turbo - тащились от Доса (в отличие от NC), если его, конечно, нормально преподать.
Диалог с компутиром посредством текста или голоса и выбор из списка (результата) - несравнимо по простоте с pattern-recognition каких-то дополнительных indirections в виде пиктограмм меняющих свой look-and-feel с каждой новой версией (т.е. mapping что-есть что надо обновлять постоянно), да ещё все единицы информации спрятаны в глубинах иерархий и энкодированы в бинарные форматы.
Я ху^тащусь с этого прогресса, дорогая редакция.

требую изменить HIG:
В любых случаях нужно не более 2 главных видимых компонентов (и то чтобы не было скроллинга консоли): поле для ввода текста и поле для работы.
На последнем может появляться список для дальнейшего выбора или помощь, закрывая собой поле для работы. Всё.
Максимальная производительность труда - обеспечена (про правильном подборе списков).
Для обеспечения подобной системы нужна плоская масштабируемая (B-tree-based) файловая система (типа беркли-дб), но желательно не бинарная (из соображений восстанавливаемости, поддержки итд), короче Hash/Map.