На Пальме хаоса мало из-за небольшого количества записей с небольшим объемом. А что будет с производительностью в современных системах с их количеством файлов? Тупиковая ветвь. Надстройка с атрибутами должна быть "над ФС", чтобы сохранить и скорость традиционной ФС когда не надо искать файл по признакам и гибкость при индексации документов. Хотя я всегда вырубаю индексорование в NTFS и "быстрый" поиск средствами MSO. Ну а на ext3(2) такого и нет, вроде.

Re:

> Может есть какие идеи по уменьшению вселенского хаоса каким стали
> многие FS на HDD?

Хороший вопрос...

Конкретно мне, если честно, пофиг всё что находится за пределами домашней директории.
То есть я конечно хорошо умею разгребать помойку "/windows", немного хуже умею разгребать помойку "/etc", "/usr" и иже с ними - но никогда этим не занимаюсь. Ну помойка и помойка, она кому мешает что ли? ;)
А в домашней директории у меня только то, что используется в настоящий момент. _Всё_ остальное лежит в репозитории и вытаскивается при необходимости.

Вот такая вот конфигурация приводит к тому, что вроде как мусора и нету. То есть где-то там, куда мне лазить не хочется и не приходится.

Так что проблема имхо не в наличии новых ФС, а в навыках работы с информацией у юзеров вообще.

Думаете при желании не замусорить "Storage" этот? Лехко! :-)

Re:

2anonymous (*) (2003-09-09 10:59:09.357189):

Со всем согласен.

Интересно было бы попробовать сформулировать правила
по которым например какой нибудь скриптик будет
прибираться в домашнем каталоге.
Например все папки и файлы что не трогали неделю
перекладывать в архив что то сжимать чтоб место не
занимало etc.
А насчет /etc и /usr полностью согласен
незачем их трогать есть и есть не мешает совершенно.

> Например все папки и файлы что не трогали неделю
> перекладывать в архив что то сжимать чтоб место не
> занимало etc.

По-моему, лучше никуда не перекладывать, а просто не показывать. Наример в оболочке сделать view наподобие как могут не показываться в клиенте прочитанные ньюсы. Плюс здесь в том, что время на "восстановление" файла минимально - нажатие клавиши для переключения текущего view.
( И всё-таки считаю, что разруха в головах. Если у кого-то бардак в /home, может быть просто стоит следить за своей информацией? Дополнительный инструмент не помешает, но не как самоцель.)

По теме. Вот подумалось, что если Storage будет просто индексировать свойства - это неинтересно. Что ни говори, а нормальный поиск - это только полнотекстовый поиск. А где полнотекстовый - там должна быть возможность подключения разных индексаторов. Условно говоря, в русскоязычном дистрибутиве - Yandex.Disk в качестве индексатора :-)

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

Ооо нет, опять пришло это чмо Irsi ...

2Dimentiy>
Ну новую оболочку делать долго а вот на скрипте
идеи проверить можно быстро.
Ok пускай он не удаляет файлы а делает их hidden.
Бардак не бардак в home а что-то там прибрать автоматом
можно было-бы.

2Irsi
Ой. Провокатор :)
Опять работу отдельного человека размазываем на всех пользователей/программистов Linux? И не надоело высасывать из пальца аргументы?

Я тоже планирую написать нечно подобное, но в другом направлении. И что, из-за моей "поделки" все линуксоиды будут уродами потому что такие вещи делают на Java? Ась?

А планирую делать распред. базу знаний. Не файлов с атрибутами, а знаний среди которых могут быть и файлы, конечно. Но до первого релиза еще ой как далеко! Сижу читаю умных людей, Prolog изучаю (tuprolog для Java тот же). В общем без базовых знаний не охота браться.

Re:

Irsi, зря ты в разговор влез.
Кстати "несколько лет назад" ты говорил, что без multiple streams жить нельзя на десктопе никак, а тебя посылали. Жизнь показывает, что фича эта и на NTFS-то не больно используется.

2 Troll:
> Бардак не бардак в home а что-то там прибрать автоматом
> можно было-бы.

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

Например проблема - как отличить файл, с которым работают ручками, от файла настроек, очень нужного какой-нибудь приблуде. В общем, пустое всё.
Да и на самом деле это уже оффтопик ;)

Да в общем насчет разрухи в головах согласен на 100% Но вот я работаю в организации. В данный момент я даже делая Backup не могу решить следующие проблемы. 1) Обеспечить сохранность данных (открыл, поломал, сохранил - тут надо историю вести как в CVS, а вот обучить CVS это уже тяжко). 2) Совместную работу - Пишет 1 читают все... 3) Быстрый поиск по заданным метаданным... Может тогда кто подскажет решение? Засрать можно все, но за это уже будут по другому говорить, премию снимать и т.п. А вот при обычных FS правила (сделать резервную копию файла с именени *.version 1 и т.п. не катят - слишком сложно)

2Korwin вот на FramerD и посмотри. Она именно распределенная...

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

Ну вот - как проблема мало мальски нетривиальная так сразу
"Автоматике такие вещи доверять нельзя"
То что прямо сразу решения в голову не приходит
это не значит что его нет =)

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

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

> 1) Обеспечить сохранность данных (открыл, поломал, сохранил - тут
> надо историю вести как в CVS, а вот обучить CVS это уже тяжко).

Это конечно смотря по ситуации. У меня лично даже заметочки нотепадные в репозитории лежат - но я программер всё-таки, мозги набекрень :) Допускаю, что людям будет нелегко к управлению версиями привыкать.
Но зато при этом решается

> 2) Совместную работу - Пишет 1 читают все...

Вот эта (2) проблема.

Кстати я использую в качестве системы управления версиями не CVS, а Subversion. Работает поверх WebDAV, соответственно можно на чтение просто людям примонтировать репозиторий в "Web Folders" (если брать win32). Выглядит натурально как диск ;)
Под Linux не знаю как точно, но уж типа WebDavFS-то точно что-то есть, и скорее всего штук десять ;)

> 3) Быстрый поиск по заданным метаданным...

Но тут уж смотря что за данные и что за метаданные.

Re:

2Troll (*) (2003-09-09 15:30:07.842282):

> Про auto indent в текстовом редакторе тоже
> можно скзать что только человек знает куда он
> хочет поставить курсор

Есть большое отличие - автоиндент ничего не удаляет ;-)

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

Сугубое имхо.

>2Korwin вот на FramerD и посмотри. Она именно распределенная... Отличная штука. Действительно занятная. Изучаю. Спасибо за инфо!

Совсем пидарас... Одноуровневое тхранилишще в PalmOS есть ааакой гимор... Сделано было изначально как кастрированное хранилище инфы, потому как памяти недоставало, соотвественно, иждея состояла в том, чтобы не таскать инфу в буфер из файлов, в типа "редактировать-по-месту". На сегодня выродилось в нечто совсем несооьбражное, и с ограничением по 64 К на запись...

Save As там сделай, умник 8)

2Korwin: добавь в свой список кроме пролога еще и CODASIL, если не добавил еще разумеется. :)

2Dimentiy: во-первых пользуются. во-вторых пользуются мало по причине необходимости сохранять полную обратную совместимость с FAT. В третих - с каких это пор для линуксоидов мелкософт во всем стало примером - ведь все вы уверены что "мелкософт все делают через ж.."? :) В четвертых - кто сказал что у мелкософта очень хороший десктоп? Он максимум на 4- тянет... А то что гном с кде даже на 3+ не тянут, так это совсем другой вопрос...:)

>Есть большое отличие - автоиндент ничего не удаляет ;-) Бывает еще такая опция "remove tryling spaces" она удаляет но от этого только польза.

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

Ты не дочитал. Я же говорю все кроме выделенных папок. Конечно есть вещи которые должны оставаться на месте папка Desktop от KDE например. И скрипт не удаляет а переносит в архив.

Irsi:

> во-первых пользуются. во-вторых пользуются мало по причине
> необходимости сохранять полную обратную совместимость с FAT. В
> третих - с каких это пор для линуксоидов мелкософт во всем стало
> примером - ведь все вы уверены что "мелкософт все делают через
> ж.."? :) В четвертых - кто сказал что у мелкософта очень хороший
> десктоп? Он максимум на 4- тянет... А то что гном с кде даже на 3+
> не тянут, так это совсем другой вопрос...:)

Во-первых я не "линуксоид". Во-вторых, про NTFS можешь мне не рассказывать. В-третьих пользуются мало потому, что не нужно (потому как если бы было нужно, обратная совместимость пошла бы лесом моментально). В-четвёртых, мне параллельно сколько баллов ты дашь программе explorer.exe, бо повода поднимать флейм про MacOSX я тебе давать не хочу. В-пятых, в августе видел KDE 3.1 и не заметил там особых отличий в юзабилити от эксплорера, причём возможно KDE лучше. В-шестых, почему "мелкософт во всем стало примером"(сам-то понял что написал?)? В-седьмых, почему ты считаешь что я уверен в истинности фразы "мелкософт все делают через ж..", ты что знаешь меня?

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

2Dimentiy: разумеется тему про MacOS X никому поднимать неохота, ибо если видели ее, то понимают - всем остальным до нее в плане usability, как до Луны пешком...:) А теперь посмотри кто занимается сабжевым проектом :)
Вообщем-то хорошо и правильно что в GNOME Team озадачились подобными вопросами, плохо только то что из непонятно каких соображений они орентируются не на самые лучшие решения в этой области.

2Irsi:

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

Никто тебя не заставляет Storage использовать.
Люди ставят эксперимент на себе, это хорошо. Можно посмотреть что получится ;)

Что же до usability, MacOSX и т.д. - то на текущем этапе _все_ среды можно эффективно использовать _для_работы_ , и разница не столько велика.

2Dimentiy: блин, ну ведь понятно что реляционные БД в качестве FS, а если быть точнее - хранилища объектов это очень неэффективное решение, что подтверждено неоднократно... Так зачем?!
Угу, все можно использовать, не спорю. Вопрос в другом - насколько эффективно? (Прошу заметить - системы, которым больше чем 2+ дать нельзя я вообще не упоминал).

2Irsi:

> блин, ну ведь понятно что реляционные БД в качестве FS, а если быть
> точнее - хранилища объектов это очень неэффективное решение, что
> подтверждено неоднократно... Так зачем?!

Оладушек, ну ведь написано:

> Storage представляет из себя систему для хранения _документов_,
> базирующуюся на PostgreSQL

Где ты видишь "объекты"?

Я например храню документы в репозитории, под которым лежит BerkeleyDB, вполне себе реляционнаф БД - ну давай, расскажи мне что это "неэффективное решение".

> Угу, все можно использовать, не спорю. Вопрос в другом - насколько
> эффективно?

Достаточно эффективно. Поскольку работает человек головой, а не постреляционными БД или чем-то ещё.

2Dimentiy: ай, на сарае х... написано, а там дрова лежат. :) В данном контексте документ, файл, объект это почти одно и тоже, вопрос в основном в терминологии...:)

Re:

Эк ты ловко :0)
Ну ничё, чай не гордые. Повторюсь:

> Я например храню документы в репозитории, под которым лежит
> BerkeleyDB, вполне себе реляционнаф БД - ну давай, расскажи мне что
> это "неэффективное решение".

Внимательно слушаю.

Irsi:
>разумеется тему про MacOS X никому поднимать неохота, ибо если видели
>ее, то понимают - всем остальным до нее в плане usability, как до Луны
>пешком...:)
Я конечно понимаю, что гордость от недавно купленного Mac (кстати какого?) распирает, но не надо ляля!

Не только видели "десятку", но и используем. И могу сказать, что по многим вещам _для_меня_ юзабилити мною настроенного Линукс выше чем в OS X.

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

По поводу того же KDE... Наболевшая тема, но по юзабилити он мало чем отстает от лидеров, а в некоторых вещах и превосходит. За примером далеко ходить не надо - Konqueror. Пробовал ли бы его применять для одновременной работы с: локальными папками, WWW страницами и парой FTP сессий и все в одном окне. Удобнее расположения еще не встречал, а как все легко управляется - песня.

В общем надо добавить сугубое ИМХО ко всему сказанному, впрочем, как и тебе :)

2Dimentiy: да ты и сам знаешь что для определенного класса задачь и соотвественно дукументов реляционная модель подходит хорошо, для других - хуже, для третих - хреново. У тебя есть конкретная задача, для конкретных документов и вполне возможно для тебя реляционная БД эффективна. Но они-то разрабатывают _общещее_ решение, а вообщем случае реляционная БД для этого класса задачь не лучший выбор. :)

2Korwin: да старье я себе купил, старье, но для моих задачь хватает. :)
На счет юзабилити - ключевые слова "юзабилити мною настроенного"... Если надо настраивать, то это уже минус, и чем больше надо настраивать, тем больше минус. :) Идеальный десктоп вообще не должен нуждаться в настройке. ;)

"За примером далеко ходить не надо - Konqueror. Пробовал ли бы его применять для одновременной работы с: локальными папками, WWW страницами и парой FTP сессий и все в одном окне."
Ээээ... IE с этой оболочкой... как ее... забыл, ибо не пользую... та, которая к нему табы прикручивает (ведь ты их имел ввиду?). Чесно скажу - тестировал, особой разницы не заметил, ибо и то и то одинаково неудобно имхо...

Irsi:

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

Ты даже не понял сказанного. Говорилось, что не имеет значение, что там используется в качестве underlying database. Потому что пользователь этого не видит. Модель данных конкретно репозитория svn - множество деревьев. У других средств (сабжевой например) могут быть другие модели - а где оно всё хранит свои данные - интимное дело этого средства, лишь бы бэкапить удобно было.

> У тебя есть конкретная задача, для конкретных документов

У меня есть задача создать иметь устойчивое хранилище для документов любого рода. Репозиторий, работающий поверх реляционной BDB, успешно решает эту задачу.

>2Korwin: да старье я себе купил, старье, но для моих задачь хватает. :)
:)

>На счет юзабилити - ключевые слова "юзабилити мною настроенного"...
>Если надо настраивать, то это уже минус, и чем больше надо настраивать,
> тем больше минус. :) Идеальный десктоп вообще не должен нуждаться в
>настройке. ;)
Ты идеалист? Нет, скорее утопист. А людей с ограниченными возможностями не забыл? В страшном сне может только быть десктоп который всех удовлетворяет по юзабилити без доп. настроек.
Далее. Факт, что чем больше количество возможных изменений/настроек тем хуже десктоп неверно. Впрочем и обратное тоже. Здесь должна быть разумная середина. В Mac OS X многое что мне не нравится и я не могу это изменить. В Линукс же десктоп после юзания и после того как определишься что _тебе_ нужно и как _тебе_ удобней - это и реализуешь настройками, выбором WM, подбором skins и т.д. В результате получаешь десктоп который полностью удовлетворяет твоим желаниям. Приэтом, что примечательно, при смене дистрибутива настройки сохраняются без проблем.

>"За примером далеко ходить не надо - Konqueror. Пробовал ли бы его
>...
>Ээээ... IE с этой оболочкой... как ее... забыл, ибо не пользую... та,
> которая к нему табы прикручивает (ведь ты их имел ввиду?). Чесно
>скажу - тестировал, особой разницы не заметил, ибо и то и то
>одинаково неудобно имхо...
Aventa кажется так? Дык я не про то говорю. В общем если не попробуешь - не объяснишь. Тут даже screenshot мало помогут - надо динамику прочувствовать.

В OS X можно исп. оболочку аналог NeXT вот это удобно! Ребятки из AfterStep подобный сбацали уже давно - красота :)

И, пожалуйста, не возводи до непреличия собственные вкусы. У других они тоже бывают, и не факт, что хуже.

> реляционные БД в качестве FS, а если быть точнее - хранилища объектов это очень неэффективное решение, что подтверждено неоднократно.

а какие из ныне существующих FS представляют собой эффективные хранилища объектов? ;)

- Я изобрел автомат для бритья. Клиент вставляет лицо в отверствие, бросает монетку в щель, ...
- Но ведь у каждого своя форма лица.
- Ну... До первого раза да...