«за каким хреном тебе знать, как зовутся файлики на диске и какого они размера?»

>А рэйд или lvm не помогает? (Я действительно не в курсе)

LVM по NFS не работает :) И не позволит использовать переносной винт. Фактичеки LVM - это соединение нескольких физических устройств в один логический раздел. А задача стоит - в создании ссылок _между_ логическими разделами.

Вот у меня как раз внешний, через USB, винт на 120Гб, где я храню документальные фильмы. Хардлинки на него я не сделаю никак.

> Вообще, давно нужно переходить (но это - уже будущее) к системе объектов-агентов.

Какие умные, ничего не значащие слова.

> Есть объект "Актёр" с полями "Имя", "Фамилия", "Биография"... Есть объект "Фильм" с кучей ссылок на разных "Актёров". Со ссылкой на "Бинарные данные" - сам фильм. "Актёр" может задать запрос по всем "Фильмам" и получить список объектов, ссылающихся на него - "Фильмов", "Музыки" и т.п...

Открой для себя Semantic Web без всяких "агентов".

> Т.е. надо - ты высылаешь "Актёра" "Янковского" товарищу по почте. И если у него есть фильмы с его участием - то они слинкуются на него сами

Ага, а если Янковский, к примеру, не только актер, но и режиссер, сценарист, писатель, политик и альпинист, то появится еще охренительная иерархия классов, причем единая, т.к. твой класс "Актер" должен совпадать с классом "Актер" у твоего товарища, чтоб было понимание. И т.п. Это уже даже не Semantic Web, а что-то близкое к http://www.cyc.com/technology -- глобальная онтология обо всем на свете, включая собачку Янковского, на которую будут ссылки из объекта "Актер Янковский" :)

>Открой для себя Semantic Web без всяких "агентов".

Открой для себя современную терминологию.

>Ага, а если Янковский, к примеру, не только актер, но и режиссер, сценарист, писатель, политик и альпинист, то появится еще охренительная иерархия классов

Тебя никто не заставляет прописать сразу всё. Точно также, как скачанный музыкальный файл кто-то положит в downloads, а кто-то в My Music/В/Владимир Высоцкий/1968. Песня о Волге/09. Корабли.ogg

> И т.п. Это уже даже не Semantic Web, а что-то близкое к

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

>Со временем эти костыли отольются во что-то более изящное, массовое и, главное, единообразное.

Инвалидная коляска на гусеничном ходу с автономным дизель-генератором? )))

> Как хардлинк хотя бы на другой винчестер, блин, сделать. Ты хоть когда-то ln пользовался? NFS ему... :D

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

Идея не нова, но она слишком великолепна, чтобы быть по нормальному реализована. Например я помню что чтото качал по обкурке, и положил это в дирректорию MyTempLinupsDownloads, чтобы потом всю эту накачаную кучу разгребсти (не помню все что накачал, но помню что чтото нужное). Следовательно, чтобы реализовать подобную схему с БД подобными ФС, необходимо добавлять также и избыточные малонужные атрибуты типа temp, temporarity, linups, lyalix, linuh, linux downloads, my, trash. А уж как через них придется добираться по мета атрибутам... Вообще праздник.

> Открой для себя современную терминологию.

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

>У термина "агент" очень много разных значений

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

> Агент - это инкапсулированный объект, который может проявлять активность

А зачем в данном случае активность?

>А зачем в данном случае активность?

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

Я наивно думал, что в Mac OSX именно так и сделано - я ошибался?

Только следует подумать, что с другого компьютера тоже захотят смотреть на вашу коллекцию варезов. Ну и помни cудьбу WinFS.

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

Что наводит меня на мысли, что на уровне fuse это делать не нужно, а нужно просто использовать системы десктопного поиска.

>а нужно просто использовать системы десктопного поиска.

1)костырь

2)неудобно

3)DE-зависимо

4) Не обеспечит ни в малейшей степени описанного функционала :)

>Вот только как его научить понимать, где доки по программированию а где по экономике

Вручную, как же иначе....

>и чтоб разбирал и pdf и chm и djvu

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

> Чтобы, например, "Янковский" мог выдать по запросу все фильмы, ссылающиеся на него.

При передаче объекта на другую машину, "активность" тоже будет передаваться? Вообще, я не понимаю, зачем это должен делать объект "Янковский"? Чем тебя не устраивает текущая схема, при которой есть API, у которого ты запрашиваешь, например, все элементы каталога. Заметь, не у каталога запрашиваешь, а у API.

> 1)костырь

В текущем виде -- да. Ибо центром современных костылей является GUI, а не поиск.

> 2)неудобно

Неудобно что?

> 3)DE-зависимо

Это GUI зависимо. Оторви поисковый движок в отдельный процесс и предоставь библиотеку API. Не вижу принципиальной разницы с новым API fs, кроме того, что 1) не надо эту муть тянуть в драйвер fs, 2) в качестве storage может использоваться какая угодно fs и вообще все что угодно.

>При передаче объекта на другую машину, "активность" тоже будет передаваться?

Да.

>Вообще, я не понимаю, зачем это должен делать объект "Янковский"?

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

Предусматривать всё в API - это глупо.

Рулит микроядерность :D

> Рулит микроядерность :D

Не микроядерность, а наноядерность, сколько можно повторять.

>и чтоб разбирал и pdf и chm и djvu

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

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

> Да.

Ух, ё... Т.е. эта бодяга будет завязана на байткод-машину? И это должно быть _встроено_ в fs? :crazy:

> Затем, чтобы скрыть от системы реализацию потрохов конкретного агента.

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

> Предусматривать всё в API - это глупо.

Т.е. идея плавно скатилась с метаинформации на "всё в системе -- суть программа"? Нафиг-нафиг. Security пойдет просто лесом: вам вордовых макровирусов мало?

> Рулит микроядерность :D

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

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

Ещё раз. У тебя сейчас все файлы лежат как
/0001.dat
/0002.dat
/0003.dat

или, всё же, как

/home/midos/video/вечеринка.avi
/usr/src/linux/.config
...

?

Думаю, всё же, во втором стиле.

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

Так как же, это тебе ReiserFS/ext3/xfs сортирует сама, или же ты каталоги ручками вводишь, а расширения и имена файлов - с ними бегают?

Так почему же ты обсуждаемой системе запрещаешь то же самое делать?

>Т.е. идея плавно скатилась с метаинформации на "всё в системе -- суть программа"?

Всё в системе - есть ("суть" - неверная морфология) агент.

Агенты - содержат в том числе и некий код.

>Security пойдет просто лесом

Java Applet'ы, JavaScript, Flash, SVG(?) - это что, всё посылает секьюрити лесом, что ли? Вроде бы уж сколько лет существуют. Более того - почти на каждой десктопной машине...

Действительно. Зачем что-то вообще знать? Надо плодить мертворождённые проекты на саурсфорже и войти в историю как непревзойдённо хамский тролль-гопник. Поистине, великий Путь! :)

> Агенты - содержат в том числе и некий код.

> Java Applet'ы, JavaScript, Flash, SVG(?) - это что, всё посылает секьюрити лесом, что ли?

1) В общем, да, хотя большинство самых критичных дыр уже залатали, а развитие практически застопорилось. Будут активно развиваться -- будут дыры. Но тут концептуальные различия -- applet'ы, flash и т.п. работают каждый в собственной песочнице, практически полностью изолированной от окружающего мира. В случае с метаданными (mata-applet'ами?) и способностью агентов самостоятельно находить sibling'ов, они имеют доступ к твоим данным. Дальше лишь вопрос соц. инженерии сбагрить тебе файл со spyware-metaapplet и заставить тебя зааплоадить его обратно вместе с собранной инфой.

2) Java Applet и пр. это два API вместо одного. Внешнее API серьезно ограничено -- запустить, показать и т.п. Т.е. ничего domain specific, никаких полезных действий, специфичных для предметной области, фактически нет. В дополнение -- внутреннее API, которое предоставляет applet'у окружающий мир в виде заранее заданной ограниченной модели.

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

3) В случае пассивных метаданных ничто не мешает определить отдельные атрибуты как бинарные данные -- байт-код апплета, если сильно засвербит в одном месте.

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

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

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

Для несведующих: вам сюда: http://www.linux.org.ru/view-message.jsp?msgid=114929&page=-1

> Ну а по поводу моего отношения к файловым системам - был тут уже этот базар неоднократно, да и не только тут - в fido7.ru.linux флейм стоял такой, что модератору за плюсомёт пришлось взяться. Суть такова - я считаю концепцию иерархических файловых систем убогой и пригодной лишь в качестве крайне низкоуровневого хранилища информации, над коим должна жить куда как более продвинутая СУБД, каталогизирующая пользовательские данные в куда как более осмысленном виде, а не по одному лишь ключу - пути и имени, как это делается в FS. Так что как раз на практике, а не в плане общефилософском, я и предпочитаю БД файлопомойкам, всегда и везде.

Antichrist

А сюды уже месяц не писали!