RAID is dead...

> Правило такое в IT: обычно корпоративные дорогие решения приходят в быт. Так было с компьютером, потом - с сетями, сейчас - с RAID хранилищами.

READ под архивы _сейчас_ никто уже не использует!!! Только под оперативные небольшие хранилища первого уровня с ограниченной доступностью. :->

под одним ключом - лист, список

значит диры - это ключи, а симлинки в них - это пойнтеры на ресурсы?
(о хардлинках не говорим ;)

-- не подходит из-за нарушения порядка. Я хочу поменять приоритет в списке результатов.

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

Поэтому скрипты расширяют дерево автоматически по-надобности, имея определённый максимум для количества файлов.

> Я что-то усомнился в альтруизме нашего друга, пишущего архив почты для себя. :->

а я усомнился в независимости ваших суждений, как-то они напоминают рекламму одного продукта ;)

про требование - впервые слышу. Бред какой-то.

2Anode: что ты будешь делать в случае сбоя в файловой системе? Если у тебя структура архива фактически является его описанием и средсвом поика и навигации, то если где-то что-то гавкнется, то все пропало. Потом, а что ты будешь делать при изменении структуры связей - ну изменилось у тебя представление о ценности информации или ассоциативная модель претерпела коррекцию. Что тогда будешь делать? А если ты решишь еще одно поле в карточку атрибутов захочешь вставить в уже существующий тип?

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

агент - это уже же по Вашей части ;)

> READ под архивы _сейчас_ никто уже не использует!!! Только под оперативные небольшие хранилища первого уровня с ограниченной доступностью. :->

???

>> Я что-то усомнился в альтруизме нашего друга, пишущего архив почты для себя. :->

> а я усомнился в независимости ваших суждений, как-то они напоминают рекламму одного продукта ;)

Это не реклама продукта, а ЕСМ-парадигма (не EMC!!!) - основа для понимания того как управлять неструктурированным содержанием. Если вы взялись за такую задачу (просто вы еще не знаете, что держитесь за ниточку, которая намотана на огромный клубок!!!).

> про требование - впервые слышу. Бред какой-то

Ну, батенька, жизнь сурова у вас на континенте. Энроны всякие случаются. Вот и решили, что нефиг и теперь ВСЯ входящая и исходящая почта в любой компании в обязательном порядке архивируется! А вот как это делается - это вопрос денег. У кого на что хватает. :-)

> > READ под архивы _сейчас_ никто уже не использует!!! Только под оперативные небольшие хранилища первого уровня с ограниченной доступностью. :->

> ???

Какой термин вызывает затруднения?

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

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

> во вторых - не так масштабируемо в случае немасштабируемых FS. Ну, с XFS или JFS - я положу тучу файлов в директорию, а что делать под виндой?

знаете как в солярисе почта в /var/spool/mail хранится? пользовательские файлы складываются не в одной плоской директории, а разбиты на подгруппы, которые обозначаются двумя буквами, а буквы вычисляются по имени аккаунта. точно так же организованы варезные и mp3-архивы в районных сетках, и сделано это именно для виндовых клиентов.

хотя я не очень понимаю с чего это всплыли винды в ответ на замечание о юниксовых ФС. на всякий случай поясню: я не пытаюсь доказать что ваше дело бессмысленно потому что все это можно сделать с помощью ln, ls, find и grep.

а у вас за счёт чего persistence?
Субд что - не от мира сего? Мой индекс как раз не бинарный и подлежит восстановлению, если какие-то сектора "гавкнулись", как вы выразились.
А вы оракл предлагаете для дома покупать?

Честно говоря, не очень-то и хочется продолжать с вами беседу после некоторых недавних постов. Ладно, пусть для вас я преследую сугубо корыстные цели - если так легче.

> А не проще на каждый объект имет запись со всеми атрибутами в СУБД и искать там, где это _нужно_ делать?

иногда полезно обращать внимание на контекст.

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

> а у вас за счёт чего persistence? Субд что - не от мира сего? Мой индекс как раз не бинарный и подлежит восстановлению, если какие-то сектора "гавкнулись", как вы выразились. А вы оракл предлагаете для дома покупать?

Оракл сейчас $149 на пользователя стоит в поставке стандарт - а уж как он пашет, тут никому объяснять не надо, я надеюсь.

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

Я посмотрел скриншоты... ТМ и (с) присутствуют однака. :-> Не очень это похоже на решение только для себя и just for fun. Хотя я не претендую, просто высказал свое мнение. Я же не обижаюсь, что вы меня в менеджеры по продажам записали. :->

> Ладно, пусть для вас я преследую сугубо корыстные цели - если так легче.

Кому легче? :->

> В Штатах (и в Канаде, _кстати_, тоже!) сейчас треба ВСЮ почту хранить в архивах - чтоб те, кому надо, всегда могли проверить все, что надо.

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

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

я это самое и делаю в скриптовой версии. Только не по два, а по одному символу. Можно поменять на два, я хотел вначале как в соляре, но по одной букве было быстрее написать (не надо mod проверять ;)

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

> Как мне кажется, для интерфейса идеально надо написАть плагин в мозиллу и в эксплорер. Для первого - изменить диаложку "Save as..", добавив строку "Keywords",

"для народа" и "keywords" не вяжется никак абсолютно. "народ" ни в жисть не будет на каждый скачиваемый файлик придумывать keywords.

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

> Но тогда не такое уж и большое различие между нашими с вами реализациями ;)

различие большое -- я на реализацию своей реализации времени не тратил вовсе

забавный вопрос: является ли поисковый запрос (+результаты) объектом для поиска?

> > Как мне кажется, для интерфейса идеально надо написАть плагин в мозиллу и в эксплорер. Для первого - изменить диаложку "Save as..", добавив строку "Keywords",

> "для народа" и "keywords" не вяжется никак абсолютно. "народ" ни в жисть не будет на каждый скачиваемый файлик придумывать keywords.

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

Не знаю как для народа, но вообще смысл есть и немалый. Надо вым нарыть информации по Юкосу, например. И роете вы во всех направлениях. И находите всякого хлама огромные горы. При этом, что очень важно, текст может быть не связан напрямую с темой!!!! Как вы тогда потом найдете нужный вам документ если в момент сохранения не указали в атрибуте "Тема" или "По проекту" что данный текст отностится к проекту "Дело Юкоса"?

> ТМ и (с) присутствуют однака. :->
это - наследие прошлого. Можно и убрать.
Потом - как-бы стандарт: если кому-то действительно интересно - из дядек которые просто сразу же спрашивают "А запатентовано ли", ищут меню "Who we are" и прочие признаки как бы приличия для них или стандартов (увы) - ну не изменить же этих дядек/тёток - они так устроены и другого не понимают. Для них это - привычный язык, иначе будешь как alian и тебя будут просто шарахаться. Я не буду сильно возражать если кто-то сочтёт подобную аппликацию для себя нужной и донейтит на проект. Просто будет больше и лучше сделано. Здесь криминала не вижу.
Но не это цель как я уже сказал, а отсутствие подходящего тула, аппликации в принципе (imho), потому буду делать для себя, как я это понимаю.

>забавный вопрос: является ли поисковый запрос (+результаты) объектом для поиска?

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

> Здесь криминала не вижу.

Я тоже не вижу. Даже еслиб это была полностью проприоритарная система. Все равно интересно же обсудить подходы к реализации. :)

У меня еще пара вопросов: как в этой реализации можно будет сделать следующее:

1. Вместо указания кейворда явно задать связь с другим документом и потом если находить оин документ, то сразу иметь доступ к связанному?

2. Версионность.

3. Возможность реализации преднастроенных (сохраненных) запросов.

Можно рассматривать это как план на будущее. :)))

> Как вы тогда потом найдете нужный вам документ если в момент сохранения не указали в атрибуте "Тема" или "По проекту" что данный текст отностится к проекту "Дело Юкоса"?

не знаю, с этим вопросом лучше в прокуроратуру.

>"для народа" и "keywords" не вяжется никак абсолютно. "народ" ни в жисть не будет на каждый скачиваемый файлик придумывать keywords.

народ надо воспитать. Сказать что архиважно, показать на примере. Потом народ потянется :)

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

keywords рулят имхо.

Малыша можно научить писать слово в консоли (точно то что ему нужно), а вот объяснить где что лежит - труднее.

садись, два.

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

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

>забавный вопрос: является ли поисковый запрос (+результаты) объектом для поиска?

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

> народ надо воспитать. Сказать что архиважно, показать на примере. Потом народ потянется :)

увы, но пока что народ воспитывать удается только microsoft. ну и еще немножечко apple и производители игр и железа для игровых компов. и воспитание идет все больше по градиенту скорости сруба бабла.

> садись, два.

А вот не надо со мной в таком тоне.

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

Я с этим и не спорю! Но только это просто "сохраненный запрос" и не более. Ответ на него можно "заморозить" если требуется "снэпшот".

> к тому же результаты запросов могут со временем меняться

Естественно! Сегодня одни документы, завтра появляются другие, а старые теряют силу. Обычное дело. Вопрос только в том, что ты хочешь - получить акуальный ответ или ретроспективный срез.

Мой ответ был более общим: если результат запроса _легко_ повторяем, то нет смысла хранить результат. Хранение же запросов (формальных!!!)штука тревиальная...

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

Не припомню ни одного случая, чтоб к американскому президенту применялась такая мера песечения.... Если ты про Б.Клинтона, то к нему она тоже не применялась.

1. Вместо указания кейворда явно задать связь с другим документом и потом если находить оин документ, то сразу иметь доступ к связанному?

надо придумать ещё обозначение как например:
id id1 id2 id3

где id - ресурс на который показывает ключ, а лист за ним - это ассоциированные ресурсы (их PK)

2. Версионность.

versioning?
а оно надо? повторять cvs? кому надо - они и так знают какие проекты они хранили в CVS и можно хранить весь CVSROOT как один ресурс. Для остального - что есть версии и есть ли версии для народа?
Нет, народу не нужны версии

3. Возможность реализации преднастроенных (сохраненных) запросов.

что-что, а это проще всего.

а анонимус крут однако - последние предыдущие несколько постов - анонимус раскрыл так сказать проблему понятно и доступно

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

готов подписаться под сия мудрым замечанием

Нет, в конце прошлого года на многих новостных сайтах была новость об аресте Буша канадскими властями за военные преступления в Ираке. Новость распространилась через Google news куда автоматом засосало сатирическую заметку. Естественно через несколько часов конда это поправили тот же поиск уже давал другой результат.

нефиг! там уже подписано анонимусом.

>>1. Вместо указания кейворда явно задать связь с другим документом и потом если находить оин документ, то сразу иметь доступ к связанному?

> надо придумать ещё обозначение как например: id id1 id2 id3 где id - ресурс на который показывает ключ, а лист за ним - это ассоциированные ресурсы (их PK)

А в обратную сторону работать это будет? Т.е. если документ А связан с Б, то и документ Б связан с А. А будет лди это масштабируема? Если на один и тот же документ указывает 1000 связанных? А если 10000?

>> 2. Версионность.

> versioning? >а оно надо? повторять cvs? кому надо - они и так знают какие проекты они хранили в CVS и можно хранить весь CVSROOT как один ресурс. Для остального - что есть версии и есть ли версии для народа? Нет, народу не нужны версии

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

>> 3. Возможность реализации преднастроенных (сохраненных) запросов.

> что-что, а это проще всего.

Ну, когда будет сделано, тогда и будет видно - просто это или нет. :)

>и воспитание идет все больше по градиенту скорости сруба бабла.
ничто не вечно под луной

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

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

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

Ага, скажет народ спасибо! Искал про сабаку, а нашел "Способы уничтожения жучка долгоностика", "Методы обнаружения жучка в закрытых помещениях"... :->

> запросил "жучку" - получай. > да народ только спасибо скажет, что не надо напрягаться!

во-первых, попрошу собак заживо не хоронить.

во-вторых, мне очень хорошо известно какие у народа возникают сложности с выбором имени в компьютере для чего-нибудь. сколько всяких хитросокращенных ООО ЗАО и ПБОЮЛ в разной записи приходится склеивать в конце каждого месяца. а еще с орфографией у многих совсем плохо, а некоторые вообще на sms навострились писать

сорри за оффтопик,

кто-нибудь может дать ссылку или сюда запостить хороший рецепт ПЕЛЬМЕНЕЙ?

очень что-то пельменей захотелось.

> А в обратную сторону работать это будет?
роазницы нет, конечно будет

А если 10000?
ну я же говорил про разумные ограничения. Ну, конечно, в предельном случае я могу положить все ресурсы в одну группу "ресурсы", но зачем усложнять жизнь? RDB сделает то же самое: будет пробегать все записи.

>Нет, так не пойдет. Я сохранил одну версию документа. Потом появилась другая, которая по смыслу отличается. И может быть те документы, которые были связаны с предыдущей, перестали быть связаны с новой версией.

это задача versioning system, а не хеша. Можно объединить, как это делает, как я понял - вышеупомянутый продукт, а зачем?
я предлагаю сделать _одну_ задачу хорошо и эта задача - удобный, сохраняемый и сколь угодно большой хэш. Что вы в нём храните - ваше дело: cvs, svn или clearcase.

>Методы обнаружения жучка в закрытых помещениях

таких коллизий будет мало
(из практики)

hint: ну сколько можно насохранять за короткую жизнь. Уже подсчитано что все разговоры всей жизни одного чела уместятся на сегодяшнем диске.
Акт сохранения будет производиться _значительно_ реже.

ну отметём мы долгоносика и увидим в следующей строке - Жучку.

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

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

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

Берешь барана, корову, свинью, лук-репку, соль-перец-приправу косточки для бульона, муку, яйца, соль-сахар, доску, скалку, кастрюлю, ложку, шумовку, перец горошком, лавровый листик, корешок петрушки, и главное, побольше воды!

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

Есть (не такая!) коммерческая реализация, называется громко Brain (или The). Помню со времен 95-х. Ее можно смотреть-гонять на предмет идей/реализаций (что как сделано и чем достигается). Почему-то никто не вспомнил, я и решил напомнить.

Ключевая идея была именно имплементировать ассоциативные связи. Не знаю, жив сейчас проект, или мертв. Есть люди, держащие в линуксе варьку только из-за брэйна :))

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

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

http://filine.home.cern.ch/filine/CRAB/doc/Contents.html - содержание http://filine.home.cern.ch/filine/CRAB/doc/MetainfoSearch.html - топик

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

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

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

2anonymous (*)
интересно и большая работа. Но имхо больше специализированв на корпоративные бэкапы.
Однако для персонального архива (по крайней мере - для себя) я ни за что не буду жать архивы или даже тарить. Наоборот - может раскрывать автоматически то что сдаунложено и нераскрыто автоматически.
Несколько причин:
1) диски дешевы и сжатие экономит копейки, но приносит слишком много проблем (ниже). Помните кагда-то делали компрессированный диск - для экономии времени и сколько было головной боли? Стоит ли?
2) тектовые файлы или бинарники можно всегда посмотреть оригинальным вьюером без потери времени - прямо из архива - за секунду. А фильмы?
А потом vm напишет агента - агент будет трудиться в бэкграунде ;) Иначе всё процессорное время будет на переархивирование. Ведь прцессорные циклы уже не по Муру развиваются. Я думаю - будут экономить процессорное время так как компьютер отдельно-взятого человека будет стремится к какому-то пределу MIPS в будущем и снова оптимизации и эффективные коды будут в почёте.
3) надёжность после сбоя отдельных секторов диска. Текст без кусков - будет бызусловно не потерян (а по оставшемуся огромному стрингу - можно будет детерминистически, простым маченьем найти тот-же документ (если он где-либо существует) - если очень риспичит. Это если дизастер и в атаклизме накроются сразу несколько дисков, а также удалённый диск. Так спать спокойнее. Инфа - это всё.

я к примеру всё время лажу в подмаунченный (весь, огромный) volume, по той или иной причине. И от болванок давно отказался. Выигрыша по цене - почти нет (сегодняшние диски - меньше доллара за гигабайт).

>"Проблема файлопомойки" будет только хуже со временем у всех

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

>Интересно посмотреть на индексатор, который будет достаточно мощным, чтобы позволять такие запросы: найди по звуковому фону все звонки сделанные с мобилы в машине, ну прямо технологии цру на мирной службе ;).

это опять - запрос. Если предусмотрел такую потребность в будущем - нет проблем: делаем автоматический if(такой_тон())"put -k машинная мобила -v sound" а такой_тон() функция - это натреннированная на паттерны определённого шума нейросеть ;)

последние 2 поста - мои

> оммерческая реализация, называется громко Brain (или The). Помню со времен 95-х. Ее можно смотреть-гонять на предмет идей/реализаций (что как сделано и чем достигается). Почему-то никто не вспомнил, я и решил напомнить.

а ссылку на описание, сайт можно? Или рассказать поподробней? Где ее можно раскопать/ пощупать?

> интересно и большая работа. Но имхо больше специализированв на корпоративные бэкапы. > Однако для персонального архива (по крайней мере - для себя) я ни за что не буду жать архивы или даже тарить. Наоборот - может раскрывать автоматически то что сдаунложено и нераскрыто автоматически. > Несколько причин: > 1) диски дешевы и сжатие экономит копейки, но приносит слишком много проблем (ниже). Помните кагда-то делали компрессированный диск - для экономии времени и сколько было головной боли? Стоит ли?

неотлаженная технология всегда приносит головную боль, это всего лишь вопрос времени, компрессия среди файловых аттрибутов ext2 почему-то есть (man chattr(1)):

A file with the ‘c’ attribute set is automatically compressed on the disk by the kernel. A read from this file returns uncompressed data. A write to this file compresses data before storing them on the disk.

более того, появляются экспериментальные патчи:

The ’X’ attribute is used by the experimental compression patches to indicate that a raw contents of a compressed file can be accessed directly. It currently may not be set or reset using chattr(1), although it can be displayed by lsattr(1).

видимо у разработчиков ext2 поехала крыша...

> 2) тектовые файлы или бинарники можно всегда посмотреть оригинальным вьюером без потери времени - прямо из архива - за секунду. А фильмы? > А потом vm напишет агента - агент будет трудиться в бэкграунде ;)Иначе всё процессорное время будет на переархивирование. Ведь прцессорные циклы уже не по Муру развиваются. Я думаю - будут экономить процессорное время так как компьютер отдельно-взятого человека будет стремится к какому-то пределу MIPS в будущем и снова оптимизации и эффективные коды будут в почёте.

да хрен с ними с циклами, дыухядерные цпу уже в роадмапах AMD и Intel и это только начало, как вам цпу с 96 ядрами? а ведь есть уже и такие http://www.clearspeed.com/. Кто-то не может писать приложение хорошо масштабирующееся на сотню ядер? это его проблемы, пусть идёт торговать диванами, его место займут те, кто может.

Не ЦПУ и не размер памяти, шины - основная проблема и она будет лишь усугубляться.

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

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

> я к примеру всё время лажу в подмаунченный (весь, огромный) volume, по той или иной причине. И от болванок давно отказался. Выигрыша по цене - почти нет (сегодняшние диски - меньше доллара за гигабайт).

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

может лучше вместо спора чего-нибудь полезное сделаем совместно? :)

мыло выше - предлагайте что ;)

я вот думаю локальный описковик может завершить.
потом посмотреть на него и ещё подумать.

А архиватор можно как бек-энд - при желании

предлагайте - что считаете будет полезно удобно и используемо _реально_ вами_ (я делаю тул для себя и требования весьма высокие)

Anode

Похожий стандарт, одобренный W3C, RDF: - http://www.w3.org/RDF/ - http://www.xml.com/lpt/a/2001/01/24/rdf.html -- краткое его описание.

Кстати, ссыл http://srcportal.net/isdemo.html не работает. А демонстрацию хотелось бы посмотреть. Буду признателен.