> Нужно. Мозги прочищает.

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

> Вспомни, хотя бы, простую рекомендацию для создания вебсерверов - если хотите пихать все в базу, то графические файлы туда не суйте, вместо этого храните ссылки на них (это в рекомендациях к связке apache + mysql).

Пользователь не администрит полноценные веб-серверы. А если хочет через веб зашарить какие-то документы да картинки - пожалуйста, в нынешних десктопах маленький персональный веб-сервер ставится сразу (во всяком случае, в macos и gnome). Вот тебе, дядя, папочка (не каталог!), положи туда документики-картинки-музычку - и люди тебя увидят по адресу ... И где тут место термину "файл"?

Не надо меня агитировать за файлы на уровне ОС. Они там нужны, необходимы - и я горло перегрызу за прицип "все есть файл" - но на уровне ОС. Не на уровне десктопа. Десктоп - этажом выше. И, кстати, позднее осознание этого факта ("отдельности" десктопа) привело к тому, что freedesktop.org начал устанавливать стандарты, которые надо было установить лет 10 назад.

Уже ж сказал. Документы, картинки, электронные таблицы, веб-странички, песенки, ... - объекты, не привязанные к понятиям внутри ОС. Привязанные к тем функциям, которые десктоп выполняет для пользователя.

>А дома у Вас железные сейфовые двери и решетки на окнах?

Две двери. Одна обычная, одна железная. ;)

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

Следуя такой логике, не нужно учить алгебру - четырех простейших операций достаточно.

Можно не учить геометрию. И, наверно, в топку литературу - и так же разговариваем.

Консоль хорошо учить тем, что дается понятие о файлах, операциях над ними, файловой системы и где что лежит.

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

Плодим идиотов, потом удивляемся вирусным эпидемиям и урону на миллиарды долларов.

>Пользователь не администрит полноценные веб-серверы. А если хочет через веб зашарить какие-то документы да картинки - пожалуйста, в нынешних десктопах маленький персональный веб-сервер ставится сразу (во всяком случае, в macos и gnome). Вот тебе, дядя, папочка (не каталог!), положи туда документики-картинки-музычку - и люди тебя увидят по адресу ... И где тут место термину "файл"?

Он переписывает файлы. А захочет себе картинку скачать - опять будет файл. И при чем тут вообще вебсервера? Я просто заметил, что использовать базу данных в качестве хранилища несколько неразумно.

Микрософт пытается это обойти индексированием файлов. Правда как пользователь должен файлопомойку по разделам/каталогам сортировать - мне пока неясно (увижу, пойму).

Это все попытки снизить порог вхождения. К чему приводит неразумное снижение порога вхождения мы видим на примере виндовых пользователей - зайди на форум, увидишь десять тысяч вопросов "где взять icq" (т.е. разума воспользоваться поисковиком не хватает) и т.п. Детские вопросы, которые решаются просто логическими умозаключениями.

Инструменты должны быть удобными, но это не значит, что их нужно сделать предельно идиотично-простыми, руководствуясь ложным лозунгом о том, что работать на компьютере учиться не нужно - "сел и работай" хорошо на простых приложениях типа wordpad. Когда из последнего пытаются сделать что-то посложнее, получается winword, хорошая программа до тех пор, пока не нужно, например, формул вагон набрать, или нормально спозиционировать много картинок и т.п.

В качестве примера продуманного приложения можно привести photoshop. Все предельно просто и мощно. Еще бы скриптов вместо action добавили, и ему бы цены не было. Для полноценной работы с фотошопом нужно учиться. Хотя простейшие операции ты сможешь сделать и без этого. Баланс соблюден.

Можно ли понизить порог вхождения в фотошоп? Можно. Например, вместо цветовых систем RGB/CMYK назвать их компьютерный цвет/печатный цвет, слои цветов убрать, а для индексированных изображений сделать установку "web". Затем на сохранение оставить "с потерей качества"/"без потери качества"/"эталон" (jpeg,png,psd). Убрать настройки клавиатурных шорткатов, убрать настройки принтеров (воспользуемся твоей парадигмой - общие настройки, единые для всех, поэтому у нас будет один принтер, а второй и третий мы выбрать просто не сможем). Несомненно, нужно выкинуть верхнюю линейку и вообще убрать возможность настраивать схемы палитр - по умолчанию же и так вроде удобная. Для 80%. Палитру "Параграф" тоже надо убить - захотят, переместят надпись, и вообще нефиг на картинках писать. Из слоевых эффектов оставить тень...

Нужно ли понижать порог вхождения в такой инструмент, как фотошоп? НЕТ.

И во многих инструментах его следовало бы повысить.

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

>Привязанные к тем функциям, которые десктоп выполняет для пользователя.

Это называется MIME-типы. Одно другому не мешает.

> ФС есть сетевая БД.

Древовидная

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

Svu выше приводил пример о различии между TCP/IP и http. То, о чем Вы говорите, правильно, но - с точки зрения машины.

Но не человек для машины а машина для человека.

А с точки зрения человека... Информация несколько не укладывается в древовидную структуру. Даже - в табличную БД. Возможно - в сетевую (о которой говрит Begemoth, но сетевых ФС вроде еще не сделали?). В реальном интерфейсе (человек - человек) информация кодируется в линейный текст, и делится на дискретные куски. Но собственно представление - очевидно богаче.

Возможно ФС - это оптимальный способ работы с диском (накопителем). БД может хранить данные в одном или нескольких файлах (или прямо на диске без ФС), с точки зрения данных неважно как это реализуется, главное что-бы удовлетворительно работало. А человек - имеет дело со знаниями, что есть - даже не БД, и понимание что есть "файл" (как и понимание - что есть tcp пакет, для веб серфера) - не нужно (хотя и, безусловно, может быть полезным, как игроки знают что короткий пинг - лучше длинного).

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

Да, svu, как это ни печально, на сегодня нет возможности отвлечься от этого уровня, и сегодня понимание того, что такое ФС - необходимость. Это можно пытаться обойти, но тут jackill прав, это оборачивается только минусами.

> Там, где информация обрабатывается, то есть - в нашей ЦНС

Где-где, простите?

> > Пользователю нужен универсальный (не зависящий от деталей реализации,
> > а отражающий суть задачи) способ работы с текстовой информацией.

> Пользователю файлы не нужны, как явление.
> Это излишняя сущность, которая удаляется бритвой.

Большая часть информации, с которой работает человек, имеет
иерархическую  древовидную структуру. Именно это и выражает 
принцип everything is a file. Хотя назвать (и реализовать)
эту структуру можно как угодно, но иметь несколько различных
реализаций в одной ОС -- это уж слишком. Вот эти ненужные, лишние
реализации (fooVFS'ы и иже с ними) и следует отрезать.

> Это, в силу ограничений интерфейса, информация сводится к тексту,

В силу ограничения _ЧЕЛОВЕЧЕСКОГО МОЗГА_, главным способом обмена информацией
является речь (устная или письменная). ОС, которая не хочет обмениваться
информацией _с человеком_ в удобной человеку форме, идет лесом.

> для удобства обмена.

Да, именно. Потому что человеку так удобнее. Это его native API :)

> То, о чем Вы говорите, правильно, но - с точки зрения машины.

В том то и дело, что с точки зрения человека. Для мозгов более
естественно работать с текстом, в котором есть какая-то иерархия,
а не с деталями реализации ОСи.

> А с точки зрения человека... Информация несколько не укладывается
> в древовидную структуру.

Что?! Речь -- вполне себе древовидная структура, тем не менее все, о
чем только может подумать человек, в нее укладывается.

> Возможно ФС - это оптимальный способ работы с диском (накопителем)
[snip]
> А человек - имеет дело со знаниями, что есть - даже не БД,
> и понимание что есть "файл"

Епт, ФС -- это просто древовидная структура, а как она реализована --
никого, кроме ее разработчиков, не #@ет!

> Но, увы, в виду несовершенства мира, на сегодня в машинах обрабатывающих
> информацию хранятся практически сырые данные,

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

> > ФС есть сетевая БД.

> Древовидная

Эээ... hardlinks?

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

Тогда ему сюда: http://antigreen.org/bioreactor

Не учишь матан -- превратишься в метан! (TM)

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

А Вы думаете, что если заменить файл (директория -- тоже файл)
на какое-то другое, смысл поменяется? Как было дерево -- так и
осталось...

> Не на уровне десктопа. Десктоп - этажом выше.

И шо, таки древовидная структура не подходит для его нужд?
Или пользователи предпочитают иметь дело с помойкой?

Everything should be made as simple as possible, but not one bit simpler

> Нужно ли понижать порог вхождения в такой инструмент, как фотошоп? НЕТ.

> И во многих инструментах его следовало бы повысить.

Точно!

> Угу. Но только когда оболочка будет нормальная (LISP), а Unix shell
> с его долбанутым синтаксисом.

apt-get install scsh sawfish

2Dselect:

Кстати, я так и не понял: чем тебя, собственно, не устраивает модный сейчас подход с прописыванием файлам метаданных, и дальнейшей их выборкой по произвольному критерию (SQL там или что-то свое - неважно)? Очевидно, что древовидная структура сводится к этому делу элементарно, но гибкость больше.

> Две двери. Одна обычная, одна железная. ;)

А решетки, решетки на окнах есть??

(/me чувствует себя полным лохом в домашней секурити - у него всего одна дверь в доме. И окна на первом этаже без решеток:).

scsh уже установлен. Но:

Он предназначен для написания скриптов, а не для интерактивной работы. Нормальная оболочка - в которой программы являются функциями и, сл-но, не выводят информацию на stdout, а возвращают некоторую структуру, содержащую это информацию. За вывод этой структуры пользователю отвечает специальная функция вывода (см. defstruct). Scsh не реализует такую оболочку, а лишь повышает удобства написания скриптов в Unix.

> Следуя такой логике, не нужно учить алгебру - четырех простейших операций достаточно.

Вполне допускаю, что НЕ ВСЕМ надо учить алгебру. Зачем она фермеру?

> Консоль хорошо учить тем, что дается понятие о файлах, операциях над ними, файловой системы и где что лежит.

А зачем это КАЖДОМУ??? Зачем пользователю, которому надо выполнять конкретный набор задач, знать это? Да, ассемблер хорошо учить тем, что дается понятие о том, какие команды на самом деле использует процессор, как работает с памятью и вводом-выводом. Только ЗАЧЕМ это пользователю?

> Это все попытки снизить порог вхождения. К чему приводит неразумное

Точно! Именно про снижение порога я и говорю.

> снижение порога вхождения мы видим на примере виндовых пользователей - зайди на форум, увидишь десять тысяч вопросов "где взять icq" (т.е. разума воспользоваться поисковиком не хватает) и т.п. Детские вопросы, которые решаются просто логическими умозаключениями.

И пускай! Пусть задают эти вопросы, глупые. Пусть отвечают друг другу. Таким образом они потихонечку растут (кстати, а некоторые ведь деньги делают на поддержке идиотов - чем не бизнес?). А когда надоест задавать эти вопросы (или станет стыдно за свою глупость) - пойдут, наконец, почитают чего-нибудь, с умными людьми побеседуют. Вот только не надо их тащить. Сделайте порог низким.

Снизить порог для фотошопа - не надо. Только не забудьте включить в базовую поставку paint. Ну, может, чего-нибудь _чуток_ посложнее. И таки да - изучать фотошоп нужно. Но изучать именно отталкиваясь от применения. А не от мантры "вначале было слово, и слово было файл".

> Потому что в противном случае каждый новый пользователь становится не мастером, а ремесленником, знахарем, который знает как что-то сделать, но не понимает, почему это делается именно так, а не иначе и не видит причинно-следственных связей.

ВСЕХ причинно-следственных связей не видит никто. Я вот имею довольно смутное представление о том, как процессоры устроены физически (что там происходит со всякими кремниями, металлами, медью и пр.). ЭТО делает меня ремесленником? Всегда есть некий предел у знания о взаимосвязях в мире. Если человек понимает, как и что устроено в ЕГО предметной области - зачем ему знать до деталей, как и что устроено в тех тулзах, которые он использует? Он только должен уметь ими пользоваться.

MIME-типы - это деталь реализации, создающая у пользователя видимость богатства разных типов видимых объектов. Не надо говорить, как оно реализовано. Надо думать, как оно выглядит для пользователя.;)

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

Никакая информация не укладываетСЯ в древовидную структуру. Ее туда укладывает человек (или программа, созданная человеком). И если человек создал бардак (да, в первую очередь бардак у него в голове - смиритесь, это естественное состояние человечека - ну или можете жаловаться) - его надо как-то разгребать. Или дать тулзы, которые хоть как-то изначально упорядочивают. Да, в каком-то смысле ограничить свободу (мягко, с возможностью преодоления при некотором минимальном уровне IQ).

> то более мощные средствами они создадут только еще большую помойку.

Человек, создающий бардак (и имеющий в голове бардак) и человек, создающий эти средства (которому действительно надо быть без бардака, очень бы хотелось) - это РАЗНЫЕ люди. И второй должен позаботиться о первом. Первых - подавляющее большинство.

> Что?! Речь -- вполне себе древовидная структура, тем не менее все, о чем только может подумать человек, в нее укладывается.

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

> Тогда ему сюда: http://antigreen.org/bioreactor

В пустыне не боитесь оказаться?

> А Вы думаете, что если заменить файл (директория -- тоже файл) на какое-то другое, смысл поменяется? Как было дерево -- так и осталось...

1. На уровне файловой системы файлы нетипизированы. Зачем пользователю эта деталь реализации? Видимые объекты должны обладать типом, определяющим паттерны использования.

2. Да, дерево можно оставить. Но совсем не то, которое реально существует (и, возможно, даже не одно)! В видимом дереве не должно быть служебных каталогов (/dev /proc), возможно, вообще не должно быть доступа к каталогам с ПО (как это сделано в сматфонах - там каталог system по умолчанию не виден). Должны быть отдельно указаны и доступны каталоги для самых частых типов пользовательских объектов (не файлов) - картинок, музыки, документов...

В результате - пользователь видит картинку, которая довольно сильно отличается от реально существующей файловой системы. Как по структуре, так и по семантике объектов. Например, где на уровне файловой системы ОС определяется сортировка каталога /home/user/MyMusic при отображении? А десктоп обязан это помнить - отдельно для каждой папки, если понадобится.

> http://antigreen.org/bioreactor

Дешевый плагиат. Оригинал - здесь:

http://www.lleo.aha.ru/na/

>>> ФС есть сетевая БД

>> Древовидная

> Эээ... hardlinks?

Вот сейчас все брошу, начну хардлинки вязать

>> А с точки зрения человека... Информация несколько не укладывается в древовидную структуру.

> Что?! Речь -- вполне себе древовидная структура, тем не менее все, о чем только может подумать человек, в нее укладывается.

Попрошу минутку внимания.

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

Итак:

Недавно я прикупил фотик. Дешевая цифромыльница. И начали собираться фотографии. Естественно я их начал сортировать. И естественно начал раскладывать по папочкам! Сделал папочки "Вася Пупкин", и "Маша Васина". Потом еще много других, и рассортировал. Но тут мне встретилась первая жопа. На некоторых фотографиях Вася был вместе с Машей, и я не знал в чью из них папочку класть (int19h, я думал о хардлинках, но очень недолго). Но это - вообще пустяк, по сравнению с тем что началось дальше! А дальше - у меня ведь амбиции - огого... Дальше - пошли пейзажики... Вот только на некоторых фотоработах с пейзажами присутствовал и Вася Пупким (черт бы его брал). Но это - опять не все. Пейзажиков-то много, и их я тоже начал сортировать. Например - с рекой, или с лесом. Или, например - на дневные и вечерние. Стоп, эта дрянь опять пересекается... (и Вася с Машей все под ногами путаются, это уже даже не таблица а сеть выходит (Begemot...)).

Но самая (да... самая полная) ЖОПА приходит тогда, когда я их начинаю сортировать по настроению, состоянию и освещению.

Так что вы хотели сказать про деревья? Да, деревья я тоже фотографировал.

И это мы только сортировали сырой материал, не занимаясь анализом содержания.

>> Две двери. Одна обычная, одна железная. ;)

> всего одна дверь в доме.

Что-то мне подсказывает, что вы живете в разных районах ;)

> Что-то мне подсказывает, что вы живете в разных районах ;)

Какие районы?? Все есть файл! Мы в разных каталогах!:)

В Вашем каталоге хакают _значительно_ реже? :)

Не знаю. Мне так кажется, но, возможно, это стереотип. Просто не принято тут как-то у среднего класса жить за двумя дверями...

Привычки к простым дверям, и привычки к железным на пустом месте не появляются, верно? :)

>> Древовидная

>Эээ... hardlinks?

Тогда "графо-подобная", хотя слово "древовидная" прозносится проще :)

Кстати, недавно узнал, что NTFS поддерживает и hardlinks, и softlinks. Короче, самый настоящий граф, но выглядит в Explorer как самое обычное дерево.

Когда как. С одной стороны, всякая паранойя - болезнь в себе. С другой - у нее всегда есть причины. И иногда она только выглядит как паранойя - а на самом деле все так и надо:)

>В реальном интерфейсе (человек - человек)

80% информации мы воспринимаем глазами. Более того, общаясь, ты подсознательно воспринимаем движения собеседника, ловишь его эмоции и т.п.

>если категории не только тематические, но и по году публиции и журналу и т.д.

Задай себе вопрос, буду ли я прописывать данные?

>И это мы только сортировали сырой материал, не занимаясь анализом содержания.

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

Люди, пользующие itunes и пр. - давно привыкли к обязательному заполнению тэгов. Да и проги есть удобные - конвертирующие имена файлов в теги и наоборот (даже в CDDB лазить умеют).

>> В реальном интерфейсе (человек - человек)

> 80% информации мы воспринимаем глазами. Более того, ...

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

Хотя эмоциональная обвязка - несомненно важная составляющая.

>> И это мы только сортировали сырой материал, не занимаясь анализом содержания.

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

Безусловно. Данный спич был о недостаточности дерева, и _только_.

2svu:

NB: он говорит "Хорошо, если в них название песни и исполнитель прописаны...". Вспомним про эмоциональную составляющую? Или - про Чехова и "лошадиную фамилию"? :)

В идеале, мне кажется, информация, в системе для обработки оной, должна хранится в "мета" виде. Оперировать необходимо содержанием. Другой вопрос - возможность сего. И вот когда мы сможем интерпретировать изображение заката, разложив его на узловые точки с определенными эмоциональными значениями, и описав переходы и балансы в этих системах координат, то тогда и можно будет говорить о обработке информации.

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

Эк Вас в максимализм хватило:) Ну, закат давайте остави в покое, все ж таки:) "Мета" информация очень рулит. Да, можно на нижнем уровне хранить дерево - и располагать метаинфу внутри содержимого. Нет проблем. Но ведь правда же - совсем не обязательно это именно так показывать пользователю? Прекрасный пример - itunes - там вообще нет ничего про файлы (точнее, их можно добавить в коллекцию - после чего они перестают быть файлами, становятся просто кусками музыки). А тем не менее, песню найти не очень сложно - если знаете о ней хоть что-нибудь. И если, конечно, тэги у вас в коллекции нормально расставлены.

> Эк Вас в максимализм хватило:)

*расшаркиваюсь* :)

> Ну, закат давайте остави в покое, все ж таки:)

Это - пример "крайнего" случая. Когда "технические" аргументы очевидно не проканают. Эта составляющая присутствует в любом тексте ("текстовом", графическом, звуковом (подозреваю, в технические описания тоже может забредать:))

> Да, можно на нижнем уровне хранить дерево - и располагать метаинфу внутри содержимого.

ДА! Но возможно это будет не раньше, чем...

> песню найти не очень сложно - если знаете о ней хоть что-нибудь.

"Лошадиная фамилия" ;) В свое время, еще до компьютеров (в обозримых окрестностях, конечно они уже где-то были:) я думал о том, что хорошо-бы хороший поиск по текстам, с запросом типа Чеховского...

> И если, конечно, тэги у вас в коллекции нормально расставлены.

И это - тоже. "Тэги" будут в порядке _только_ тогда, когда это будет делать машина. Простейший пример - мои рассуждения о фотографиях. Я втыкаю фотик, дергаю скрипт, и они сливаются в каталог с датой. После чего я _в_лучшем_случае_ рассортирую их по _дереву_. И никогда я не займусь тем, что-бы тратить свое время на более тонкую сортировку (а приведенные рассуждения показывают _необходимость_ оной).

> Безусловно. Данный спич был о недостаточности дерева, и _только_.

О недостаточности дерева с _однотипными элементами_. А не дерева вообще.

> Никто не будет этим заниматься. Вон сколько существуют тэги у mp3 и что?

Пока для их редактирования нужна какая-то хреновина, кроме текстового
редактора -- никто. То же самое касается любого рода meta-data, для
работы с которыми нужно осваивать специальную софтину.

> Это - пример "крайнего" случая. Когда "технические" аргументы очевидно не проканают

Ну да, чего уж. Такие случаи неизбежны. Тут можно только как Ливанов-Холмс махнуть рукой с многозначительным видом:)

> "Лошадиная фамилия" ;) В свое время, еще до компьютеров (в обозримых окрестностях, конечно они уже где-то были:) я думал о том, что хорошо-бы хороший поиск по текстам, с запросом типа Чеховского...

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

> "Тэги" будут в порядке _только_ тогда, когда это будет делать машина. Простейший пример - мои рассуждения о фотографиях. Я втыкаю фотик, дергаю скрипт, и они сливаются в каталог с датой.

Значит так. Играем по-гамбугскому счету, ага?:) Значит, дата у нас в мета-инфе фотографии есть уже сегодня. Теперь про Васю Пупкина. Очевидно, единственный способ автоматически расставлять подобные тэги - научиться распознавать образы. Чем лучше распознавалка, тем качественнее раставятся тэги. Закат и всякую абстрактщину, увы, распознать сложно. Чего уж.

Про музыку несколько проще - в огромном кол-ве случаев спасает элементарное использование CDDB в момент перегонки в мп3.

Мой опыт говорит, что очень часто удобный и продуманный пользовательский интерфейс делает ввод мета-инфы естественным, нераздражающим, почти прозрачным. "Но это ж не квантовая электродинамика, это думать надо" (с)...

> Кстати, я так и не понял: чем тебя, собственно, не устраивает модный
> сейчас подход с прописыванием файлам метаданных, и дальнейшей их выборкой
> по произвольному критерию (SQL там или что-то свое - неважно)?

В топку это Windows registry everywhere!

Тем, что я не могу редактировать meta-data своим $EDITOR. Тем, что не
могу grep'ом по ним полазить. Тем, что нужно RTF[SM] про кучу одних и тех
же вещей, которые _по сути_ не чем не отличаются от POSIX
open/read/write/mmap.



> Очевидно, что древовидная структура сводится к этому делу элементарно
> , но гибкость больше.

Ничем она не выше. Поглядите для начала, что _можно_ уложить в
древовидную структуру: http://www.8ung.at/shell/trans.html 
И после скажите, а что еще нужно?

> > Тогда ему сюда: http://antigreen.org/bioreactor
         
> В пустыне не боитесь оказаться?

А я и так в пустыне. Живых людей немного, одни ходячие трупы,
приводимые в движение каким-то бредовым алгоритмом. Они вполне
пройдут анти-тест Тьюринга. 

They are not dead, they never existed (C) Mayhem.

От того, что они в один прекрасный момент они исчезнут, хуже не станет...

> 1. На уровне файловой системы файлы нетипизированы.

Еще как типизированы. Чем Вам транслятор (Hurd), plugin id (Reiser4)
не тип?

> Например, где на уровне файловой системы ОС определяется сортировка
> каталога /home/user/MyMusic при отображении?

Напр., транслятором, который отображает 'обычную' директорию с файлами
в какое-нибудь дерево, построенное на основе юзерского (программерского)
критерия (по id3 tags, по дате, по еще чему-нибудь). 

> Например, где на уровне файловой системы ОС

Видит он дерево, которое получилось в результате преобразования 
какого-то другого дерева _и_ данных, которые извлечены из 'листьев'.

> В результате - пользователь видит картинку, которая довольно сильно
> отличается от реально существующей файловой системы.

Транслированная ФС ничуть не хуже 'настоящей', ни одна из них
не является более реальной, чем другая. UNIX-аналогия: чем 
loopback mount хуже 'настоящей' ФС?

>> Безусловно. Данный спич был о недостаточности дерева, и _только_.

> О недостаточности дерева с _однотипными элементами_. А не дерева вообще.

Перечисляем: 1 - жанр (портрет, пейзаж, натюрморт, и т.д.) 2 - содержание (имя_портретируемого, река/лес, и т.д.) 3 - эмоциональное содержание (веселое, грустное, элегическое, и т.д.) 4 - хронология 5 - территориальные привязки 6 - техническая сортировка. 7 - если мало - сейчас еще придумаю.

NB: (это важно) Все это может взаимопересекаться как между разделами, так и внутри раздела.

Как все это уложить в одно дерево? И если это дерево будет многократно внутри себя пересекаться - то чем оно будет отличаться от сети?

>> Никто не будет этим заниматься. Вон сколько существуют тэги у mp3 и что?

> Пока для их редактирования нужна какая-то хреновина, кроме текстового редактора -- никто.

Как я уже сказал, "никогда я не займусь тем, что-бы тратить свое время на более тонкую сортировку". Если теги к компакт диску скачаются с тырнета - замечательно, но сам я забивал теги последний раз года три назад. Максимум - название/автор. А если возвращаться к предыдущему примеру с свежеснятыми фотографиями, к которым в тырнете тегов по любому нет, и которых _достаточно_ много, что-бы даже сортировать было сложно. Или, скажем, поиск по lib.ru (да, я все про Чехова (кстати у него тоже, заведомо упрощенный, иллюстративный, пример))

> А я и так в пустыне. Живых людей немного, одни ходячие трупы, приводимые в движение каким-то бредовым алгоритмом. Они вполне пройдут анти-тест Тьюринга.

Дальше только йаду...:)

> Еще как типизированы. Чем Вам транслятор (Hurd), plugin id (Reiser4) не тип?

При чем тут это? Я говорю о типах, видимых пользователю десктопа. Как plugin id у jpeg будет отличаться от plugin id у gif? Простите, иконку для типа откуда взять - и список приложений, которые могут с этим типом работать?

> Напр., транслятором, который отображает 'обычную' директорию с файлами в какое-нибудь дерево, построенное на основе юзерского (программерского) критерия (по id3 tags, по дате, по еще чему-нибудь).

А как насчет сохранения моды отображения (list, detailed, icons, music album, photoalbum)? Это в какой транслятор? И - главное - не все ли пользователю равно? Пусть на уровне ОС это будут трансляторы - пользователю на это дело начхать и растереть.

> Видит он дерево, которое получилось в результате преобразования какого-то другого дерева _и_ данных, которые извлечены из 'листьев'.

Ну да. Только с поправкой - видит он, в общем случае, несколько деревьев. Но это не важно. Только при чем тут файлы? Это все видимые объекты на десктопе - папки, документы, картинки. Да, Вы можете порадовать пользователя, что "вот это все внутри компутера называется файлом". Что ему даст эта информация?

> Транслированная ФС ничуть не хуже 'настоящей', ни одна из них не является более реальной, чем другая. UNIX-аналогия: чем loopback mount хуже 'настоящей' ФС?

loopback - не хуже. В ней те же файлы, что и в настоящей ФС. Дело не в транслированной ФС. А в том, что видимые пользователем десктопа деревья отличаются от "настоящего" дерева смыслом. Набором операций. Смыслом объектов. С т.зр. файловой системы разницы между /usr/bin/evolution и /home/user/report.pdf нет никакой - особенно если битики прав подкорректировать. С т.зр. десктопа разница между ними принципиальна - разные операции можно над ними делать (да, есть общее подмножество операций, у файла и каталога тоже).

В общем - думаю этот спор бесплоден.

Это - спор по поводу интерфейса. Но интерфейс - вторичен. По определению.

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

Пока информация обрабатывается в человеке, и хранится в storage в сыром виде - необходимость файловой системы, понимания что это такое, и умения с ней работать - не подлежит сомнению. И спорю с Вами, Dselect, я только по причине агрессивности (думаю - обоюдной:).

>> Это - пример "крайнего" случая. Когда "технические" аргументы очевидно не проканают

> Ну да, чего уж. Такие случаи неизбежны. Тут можно только как Ливанов-Холмс махнуть рукой с многозначительным видом:)

Я не совсем об этом.

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

Я приводил это не как пример того, что мы не сможем интерпретировать, а как пример того, что _в_данный_момент_ сдерживает. В чем именно заключается сейчас проблема.

> В топку это Windows registry everywhere!

С какого бока тут registry?

> Тем, что я не могу редактировать meta-data своим $EDITOR.

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

> Тем, что не могу grep'ом по ним полазить.

Аналогично. Причем тут даже ничего прикручивать не надо - SELECT и grep по результатам.

> Ничем она не выше. Поглядите для начала, что _можно_ уложить в древовидную структуру: http://www.8ung.at/shell/trans.html. И после скажите, а что еще нужно?

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

> Кстати, недавно узнал, что NTFS поддерживает и hardlinks, и softlinks.

Вот про симлинки там не слышал. Кстати, а разве их поддержка реализуется не уровнем выше ФС?