LINUX.ORG.RU
решено ФорумTalks

ФС на тегах

 , ,


0

2

Не помню где(может на lor) пролетало выражение, мол мы используем файловые системы построенные на теоретических наработках 40-летлей давности и никто не хочет это менять. Видимо всех все устраивает, т.к. ФС на базе тегов пока нет(не считая userspace наработок над fuse).

Пример ФС на базе тегов:

  • Плоская ФС. Только файлы, никаких каталогов и дерева каталогов.
  • Фактически у файла есть три атрибута: имя, inode, облако тегов;
  • Облако тегов может состоять из любого числа тегов в том числе вложенных;
  • Теги доступа: Владелец; группа; rwx; Переменная $PATH пропадет за ненадобностью;
  • Тег типа. По аналогии с mime;
  • Теги времени: Создание/Модификация/Последний доступ к файлу;
  • Теги ПМ: Имя пакета; Версия; Дата установки. Первый реальный юзкейс - установка нескольких версий ПО с возможностью выбора произвольной через указания тега версии(например через переменные окружения);
  • Теги системы инициализации. Специально для адептов Поттеринга с их ln -s /dev/null ...
  • Теги «временных файлов» - которые удаляются при входе/выходе пользователя;
  • Теги предыдущих версий. По аналогии с версиями ПО, файл копируется и получает тег бекапа с датой создания и комментарием(если необходимо).
  • Место вкладок и закладок в ФМ займут сохраненные наборы тегов;

Да, за этим делом надо будет следить(объединять похожие теги и чистить мусор), но идея имеет место на жизнь.

P.S. А вообще мне древовидной fs хватает с головой. Просто интересно, почему такую очевидную идею до сих пор не реализовали.

Deleted

Ответ на: комментарий от Deleted

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

понятнее опиши

cvs-255 ★★★★★ ()
Ответ на: комментарий от cvs-255
somefile = {
 acl = {group= "xxx"; user="yyy";access="644"};
 pm = {packagename="supersoft"; version="1.1b"; install-date="12.04.2074"};
 mime = "application/gzip";
 ...
};

т.е. узнать пакет из которого был установлен файл можно из тега pm.packagename

Deleted ()
Ответ на: комментарий от Deleted

Ну и чем это отличается от того, что пакетный менеджер будет класть файлы в /pm/supersoft итп, как в винде любят?

cvs-255 ★★★★★ ()
Ответ на: комментарий от cvs-255

Тем что не надо будет вести отдельную базу файлов принадлежащую каждому пакету(/var/lib/dpkg/info/*.list у debian например), файлы котороые создает пакет можно автоматом маркировать ка кпренадлежащие этому пакету для последующего удаления(тут конечно возникает вопрос. что делать с файлами, которые относятся к контенту и не должны быть удалены) и можно будет ставить несколько версий одной программы одновременно.

Deleted ()
Ответ на: комментарий от Deleted

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

cvs-255 ★★★★★ ()

Каждая задача имеет простое, очевидное для всех, неправильное решение.

Некоторое время назад энтузиазм вызванный развитием вычислительной техники создал некоторое эйфорическое представление что ещё немного, ещё совсем чуть-чуть, ещё совсем небольшой рывок и компьютеры заговорят как люди. Да они уже говорили на почти чистом английском языке: for i in a b c d ; do echo $i ; done. Но оказалось что на самом деле нет...

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

Но википедия тоже пользуется системами для хранения именованных областей данных, мы также знаем их как файловые системы. Правда мы этого не видим. В основном это надо для работы СУБД, которая использует ФС как хранилище. Естественно нас не интересует как это выглядит. Также, википедия использует ФС непосредственно для хранения например изображений. Правда как это организованно нас тоже не интересует.

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

Правда проблема википедии в том, что она не имеет ровно никакого смысла пока она не заполнена данными. Современная википедия значима именно как результат работы множества людей, заполняющих её. А технически она могла бы быть реализована любыми другими программными средствами. Можно написать на php как сейчас или на lisp, prolog, или например на forth, а данные хранить в СУБД или напрямую на некой продвинутой ФС с метками и иерархиями. Мы это не увидим за веб интерфейсом, а работать с информацией самостоятельно вычислительная техника всё равно пока не может.

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

Кстати, что тебя на самом деле интересует: информация или новые, прогрессивные способы хранения таковой? Или возможность автоматизировать с ней работу?

sin_a ★★★★★ ()

Тег для ПМ придётся r-o делать, либо городить «словарь» системных не для юзера тегов. Неясно что делать со скачанным файлом — либо ручками вдалбливать (что приведёт к сносу очередного гениального творения программистов через 20 минут), либо теги сами приплывают, со всякими бесплатно_без_смс/ШОК_смотреть_до_конца/... (что приведёт к сносу очередного гениального творения программистов через 20 минут). Само количество тегов на файл придётся ограничивать, иначе вероятен dos тегами.

sehr ()
Ответ на: комментарий от sin_a

Кстати, что тебя на самом деле интересует: информация или новые, прогрессивные способы хранения таковой?

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

Кстати, этот текст цитата или чисто твое рассуждение?

Deleted ()

Вся эта фигня является атрибутом фс, а не файла. Как следствие: непереносимость, избыточность, непрозрачность(в плане работы с сетевыми ресурсами). Любое read-only - химическая кастрация.

mutronix ★★★★ ()
Ответ на: комментарий от pi11

Представляю какой срач из тэгов будет в системе.

Все без исключения файлы будут иметь теги Kappa, EBIN :-DDDDDDDDDD и YOLO.

mutronix ★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.