Серьезно, хочу возвращения BeFS или, по крайней мере, сращения идей ZFS/BTRFS с идеями BeFS.
Потому что ну правда, это бы убрало столько дублирующихся усилий по организации данных в приложениях разного толка.
Прогам BeOS не нужен был каталогизатор, за них все делала файловая система и файловый менеджер.
То есть, врубись еще раз, читатель, папка с МП3шками, например - это и есть твоя фонотека, с метаданными, видимыми в таблице в "проводнике", обложками там же, и всем таким. Все, что нужно - это натравить на нее плеер. Ну, а плеер - это просто плеер.
Да, что-то такое пытался сделать Windows в свое время (вспомнить ту же Висту, например), но их ФС - хуита, а руки у MS из жопы, и в обход ФС это сделать тоже не получилось.
@drq это не прижилось, думаю, потому, что идея плохая. Зачем на уровне фс хранить километр атрибутов (на метаданные жесткие ограничения, они не волшебные), они и сейчас есть и это слишком низкий уровень, используемый в основном системными утилитами. Намного проще спецсофту самому этим заниматься, от формата зависит как и в каких границах.
@drq это обусловлено производительностью. 4кб меты в кэш проца влезет, а 4мб превьюхи нет. Фс должна быть очень быстрой и с метой работать мгновенно. Если подумать и других границ вагон.
@3draven Вот у кого-кого, у BeFS с производительностью не было проблем вообще. Вообще в принципе вся система была невероятно быстрая, более отзывчивая, чем даже Linux.
И да, это было на говенном Целероне 300 без кэша.
@drq это спорное утверждение, надо проверять путем сравнения производительности работы с десятками тысяч файлов в папках. Хз. Я не верю в бесплатные фишки.
@3draven А разве эти ограничения обусловлены чем-то *физическим*? Вроде как, для самого диска данные есть данные есть данные, разве нет?