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

У файловых систем и реляционных СУБД разные ниши применения.
В определённой перспективе ОС в состав обязательных компонентов
будет включать СУБД, и будет (лучше, чем сейчас) стандартизован
API доступа. Но файловая система как таковая вряд ли отомрёт,
поскольку всегда будет потребность в быстром иерархическом
хранилище большого количества неструктурированных объектов.
СУБД с этой задачей тоже может справиться, но намного медленнее
и с предъявлением непомерных требований к использующим этот
функционал приложениям.

>Или, скажем, сколько уже бумаг computer scientist'ы понаписали про
>различные типизированные и
>реляционные файловые системы, например? Десять лет? Двадцать? Так ведь до сих
>пор каждый сраный плеер тащит за собой свой велосипед библиотеки, вместо
>того, чтобы прекратить этот беспорядок. В Dolphin'е теги, вот, ввели, недавно...

Есть несколько очень старых, но применяемых и даже развивающихся по сей день ОС,
где эта концепция была всерьёз (без упрощений и весьма качественно) реализована.
Примеры - HP (DEC) OpenVMS и IBM z/OS (ранее MVS). Однако реальная востребованность
этого функционала оказалась не слишком велика.