Nautilus Snapshot

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

...ну и наверно тормозит соответственно?

Ага... Нравится? Вижу что нравится...:) Тормозит? Тормозит... А что делать? Использовать многопоточные FS! ;)

Да, тормозит (даже если каталог не содержит никаких файлов с назначенными индивидуально им иконками) - вход в любой каталог даже с 4-мя файлами занимает примерно треть секунды и задержка практически не зависит от числа файлов в каталоге (3 или 200) (это на машине со 128 мб ram и PIII-800). Хочется надеяться, что его еще по скорости не оптимизировали. Да и я гуевыми ФМ особо не пользуюсь - но что в Nau понравилось - так это то что он под иконкой пишет размер файла и сразу показывает (посредством пометок на самой иконке) права файлов, показывает явно history, и также некоторые другие вещи (возможность аннотации каталогов например). Архитектура у него конечно правильная и богатая. Немного напильника к нему (дней 5) - и будет очень круто.

2Irsi: я сильно сомневаюсь, что > 5% времени при загрузке каталога им тратиться на угадывание типа файла (для этого можно было бы использовать многопоточность ФС, если бы она была). Как-нить проведу эксперимент (войду им в каталог с нечитабельными файлами - чтобы он не смог их тип с помощью 'file'-alike lib определить) и сравню со временем загрузки того же каталога с читабельными файлами. Мне кажется рендеринг у него не оптимизирован.

2hvv: ну иконки и т.д. тоже в потоке хранить надо...:) Поверь - быстрей и существенно...
К слову - многопоточность полезна не только для гуя - для БД она тоже полезна... Хранить каждую таблицу в отдельном потоке очень удобно, да и скорости это прибавляет тоже... А такая идея как хранить текст в одном потоке, а все его форматирование - в другом это вообще рулез! :) Если хоть раз вытягивал позарез нужный текст из файла экзотического тестового процессора, то ты меня поймешь...:)

Бред.

2irsi: ты как всегда поришь фигню.

hvv: Для каждого каталога позволяет указать комментарий, фоновый цвет/картинку/градиент, может запоминать положение иконок в каждом каталоге (то есть их можно выстроить любым образом и он это запомнит), позволяет указать для данного файла набор "пометок" (на файле 'core' в верхнем окне - 'secret' и 'new'), растянуть иконку у любого отдельно взятого файла (иконка каталога Evolution растянута), указать у отдельно взятого файла иконку (не у файлов данного типа - а именно у данного файла - см. каталоги Mail и GNUStep). ------------------------- Все это конечно красиво и замечательно. Но вот только не понятно зачем это надо.

Вот как раз для этого: чтобы было всё красиво и замечательно ;0)

Не вполне понятно зачем многопоточные ФС для тех фич, которые ты описал, всё это давно решено стандартными средствами. Одно из двух: или ты не понял чего написал (Новый год? ;)), или я не понял, в последнем случае просьба пояснить.

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

2rabbit: многопоточные FS позволяют сделать все это проще, надежней, быстрей... Не более того... :) А в нынешнем виде все это напоминает DeskViewX (многозадачность + иксы для ДОСа, если кто не помнит) и эту... как ее... что POSIX проги позволяло для DOS компилять и запускать...:)

to Irsi: объясни один раз в двух словах, что такое многопоточность на уровне файловой системы, и пример таковой системы

многопоточность на уровне ОС или драйвера файловой системы мне понятна, но на уровне самой файловой системы - ??

2crazyalex: очень просто - когда запись в каталоге может содержать более одной ссылки на i-node. Вообщем реализация многопоточного варианта ext2fs это небольшая модификация формата записи каталога... А дальше ты прав - придется очень сильно перелопачивать драйвер fs... и не только его...

Или я что-то не понял, но по-моему любой файл в фс уже создает свою ссылку на inode. Если не так -- поправте.

Вот наш с Irsi диалог о многопоточных FS (в частности что это такое): http://www.linux.org.ru:8100/view-message.jsp?msgid=44314&scroll=section&...

2anonymous: создает. на одну... а в многопоточных - на _несколько_...:)

2 hvv - Бред. Где тут MacOS??? "Фенечки" и на винде были.

Над интерфейсом Nau действительно работают дизайнеры интерфейса MacOS (по-моему это Darin Adler и может еще кто). И в Nau фенечки уж намного более смелые чем в винде (наверно просто потому что core Explorer'а проектировали лет 7 назад).

Ребята, я прочитал всю дискуссию о многопоточных FS (по
ссылке hvv).
Созрел один вопрос. А что, директории в ext2 не являются
многопоточным файлом? Просто в нулевом потоке ничего нет -
так может и не нужно?
Создаете директорию с именем файла, в ней сам файл с тем же именем.
Затем в директории будут файлы-метки (можно их названия
стандартизовать для определенного класса программ) для иконок
и т.п.
Так нафига козе баян?

2Papa: без помощи ядра или glibc все равно не обойтись - ведь надо чтобы ВСЕ программы работающие с файлами понимали многопоточность - чтобы например, когда удаляешь файл утилитой 'rm', удаляться должны все потоки, то же когда переименовываешь, когда создаешь новый и пр. А из-за того, что некоторые программы статически линкуются с libc, поддержка должна быть именно в ядре. Короче, большие проблемы ради неизвестно чего.

Извини, но аргументация хромает. Поддержка директорий идет на уровне ядра.
Иначе говоря, достаточно создать новую утилиту "rm" где будет
реализована еще и rmdir.
Мне кажется, что тут есть недопонимание,
ведь потоки в данном случае - файлы в директории.
Возможно, нужны некие соглашения, чтобы отличать обычные директории
от директорий-потоков.
Наличие старых программ ничему не мешает. Наоборот, делает доступным
содержимое директории-потока для модификаций напрямую.

Конечно, несколько неудобно. Напоминает обьектно-ориентированное
программирование на чистом С. Типа: можно, работает, но не слишком удобно.
Никто не мешает создать свои утилиты работы с ext2, которые
создадут интерфейс многопоточности.

Весь вопрос в том - есть ли что-нибудь в идее многопоточности fs,
чего нельзя сделать через директории. И что это конкретно?

Мне кажется уж лучше реализовать многопоточность в ядре напрямую, а не делать ее в user space посредством эмуляции с помощью каталогов - тогда не надо будет переписывать все программы (ведь как я понимаю, весь смысл реализации потоков в ядре - чтобы при копировании файла любой программой копировались и все его потоки, с удалением - аналогично) и можно будет отслеживать семантику потоков. Но я вообще не вижу смысла в многопоточности как таковой. Единственное разумное применение - resource fork как в МакОС (один поток, указывающий на программу, создавшую файл). ВСЕ. Если нужны составные документы (как потоки в OLE) - лучше использовать user-space библиотеки (иначе при изменении интерфейса или логики поддержки многопоточности нужно будет менять ядро или его модули поддерживающие многопоточность). И такие библиотеки давно есть - что-то там для gnome's bonobo. Даже в спецификации Corba описаны составные документы как я слышал - может там есть и API для поддержки многопоточности тоже...

По моему БД гораздо лучший выход чем каталоги. В этом случае не нужно даже переписывать все утилиты, достаточно скриптов-врапперов вокруг стандартных утилит. Более того решение с БД имеет некоторые приимущества над простым использованием многопоточной фс. 1. Позволяет нескольким пользователям совместно использовать файлы и при этом каждый из них может назначить свою им аттрибутику. 2. Позволяет избежать дублирования информации (в случае с иконками это конечно не суть важно, но что если мне захочится прицепить к паре десятков файлов один и тот же видеоролик ?). 3. Не требует прав доступа к файлу для назначения его аттрибутов. Это может показаться не особо важным если пользователь работает только со своими файлами. Но в распределенной сетевой среде это превращается в БОЛЬШОЕ приимущество. 4. Позволяет очень легко сохранять "снимки" файловой системы, что очень полезно при восстановлении фс.