В процесі обговорення єдино вірного способу організації ієрархії каталогів файлової системи сформулював таку думку.
Файл взагалі зайве поняття. Якщо точніше, то воно зайве для користувача і навіть, найчастіше, для системного адміністратора. Максимум, кому може знадобитися працювати з файлами, це програмісту, і то не факт. Для всіх інших робота з файлами є суррогатом інших потрібних їм операцій.
Тепер трохи детальніше. Теорія підказує нам, що файл це іменована область дискової памяті. Однак, як і в випадку будь-якої компютерної памяті, дуже часто трапляється так, що ізольований фрагмент памяті сам цінності не має, для роботи з ним потрібно звертатися до інших фрагментів. Скажімо, будь-який документ має нульову цінність без програми, що здатна з ним працювати; поштове повідомлення містить вкладені документи; відеоряд повязаний з кількома звуковими доріжками; для відображення мапи потрібно також прочитати піктограми; креслення генплану потрібно підкладати як тло під креслення комунікацій, і т.д. Отже, можемо сказати, що чіткого поділу на ізольовані частини дискової інформації бути не може. Це означає, що спроба розмістити цю інформацію в файлах призводить або до дублювання інформації в багатьох файлах (напр., шаблон документа копіюється в новостворений документ), або до неавтономності файла (напр., виконуваний модуль програми не може сам по собі бути перенесений на іншу систему). Обидва варіанти призводять до того, що при виконанні дискових операцій людині доводиться враховувати деякі неочевидні речі наприклад, що встановлену програму перенести на іншу машину простим копіюванням навряд чи вийде.
З іншого боку, користувачу і не потрібно зазвичай переносити «файли». Йому треба перенести документ, налаштування, програму. Іменовані фрагменти памяті його мало цікавлять. В тому числі, незрозуміло, навіщо користувачу вникати в те, що, скажімо, AutoCAD растрову основу креслення зберігає в окремому файлі, а Photoshop всі шари зберігає в одному. Що довідка може зберігатися у вигляді каталогу з .html-файлами, а може в одному .chm-файлі. Якщо користувач перенесе файл на інший компютер, а той не відкриється через брак другого файла, він буде лаятися на розробників програми і буде, що характерно, правий. Тому що йому не треба переносити файл йому треба перенести документ.
Для тих, хто трохи орієнтуєтся в програмуванні, приведу просту аналогію для прояснення абсурдності нинішної «файлової» парадигми зберігання інформації. Аналогом дискового файла в оперативній памяті є виділений блок цієї памяті. Роботу з цими блоками проводить операційна система і низькорівнева система керування памяттю програми, т.зв. memory manager. Можна написати програму на мільйон строк і ні разу не заморочитись прямою роботою з цими блоками. Така пряма робота потрібна тільки для дуже специфічних застосувань антивірусів, програм діагностики апаратного забезпечення, високонавантажених обчислювальних завдань. Більшість програмістів без проблем обходяться без цього.
Крім того, я не знаю жодної програми, яка дозволила б користувачу безпосередньо оперувати блоками памяті. Такі операції завжди виконуються опосередковано: користувач повідомляє програму, яку операцію необхідно виконати з даними, і ця операція виконується, але зі специфічною для кожного типу даних обробкою. У випадку дискової ж памяті чомусь безпосередня робота користувача з блоками памяті вважається нормою.
Насамкінець не можу не відмітити, що деякий поступ в цьому питанні все ж помітний. Скажімо, дуже великим кроком в напрямку від файлів є package manager'и різних дистрибутивів linux та інших unix-систем. З їх допомогою практично відпадає потреба морочитися з файлами програм: установка програми полягає не в копіюванні файлів, а в прямій директиві пакет-менеджеру «встановити такий-то пакет». Коли аналогічні системи стануть стандартами de facto також в області керування налаштуваннями та документами, можна буде сказати, що більше половини шляху пройдено.