Re: [room] безумные (банальные?) идеи

Re: [room] безумные (банальные?) идеи

[Denis Medvedev]

http://www.libferris.com/
Правда собрать это чудо - немалых сил требует. У меня не получилось...


Mon, 14 Feb 2011 20:50:05 +0300 письмо от Алексей Синицын <asinitsinster@gmail.com>:

>  Доброго времени суток.
> 
> Случилось мне тут заглянуть и увидеть это занимательное обсуждение
> файлов с десктопами, отчего почесался немного и начал писать то, что
> уж давно собирался спросить.
> 
> Недавно сравнительно, захотелось мне разобраться что в системе
> ненужного есть. Стояла система уж лет как с восемь, да
> эксплуатировалась нещадно, отчего где только огрызки конфигурационных
> файлов не валялись. Да недолго и думать, вот тут как раз стоит
> KleanSweep, ну так пусть поработает немножко, не зря я его лет пять
> назад поставил. Поработал он, поработал, потом я решил что двое суток
> для него лишнего работать, тем более что неизвестно сколько он ещё
> протрудился-бы на благо хозяина-пользователя, хотя хозяин и
> предусмотрительно отрезал ему все пути на помойки.
> 
> Остановил я его, а тут кстати подвернулся свободный накопитель на
> который поставил кентавра, сначала сравнить, а теперь с него верхом и
> пишу, как оказалось не настолько сильна моя сентиментальность. Да
> тут-же и вспомнил занятную историю, как случилось парсить файлы:
> парсер на bash/sed/awk трудился весь рабочий день, а потом sql втянул
> эти файлы и на один запрос за секунды ответ выдал. Может и здесь можно
> применить этот чудо метод, завести базу в sql, и в неё засыпать данные
> о системных файлах, пусть один раз проиндексирует, а затем только
> актуальность поддерживает, в конце концов от updatedb машина ещё ни
> разу не переломилась. А там - можно будет хоть файлы
> незарегистрированные в базе rpm (или deb, по желанию) находить, хоть
> пакеты которые не нужны никому другому (хотя у нормального apt и так
> есть команда autoremove), хоть ещё какие выкрутасы вытворять.
> 
> Слово за слово, тут вспомнилось мне как недавно познакомился я с
> такой чудесной вещью как социальная сеть музыкантов - jamendo. И так
> она мне понравилась, а кроме того что там свободная культура, о
> которой писал Лессиг, да живая музыка - там на каждую дорожку
> проставлено больше одного тега. И уж как это хорошо, посмотрел я на
> каких плеерах это реализовано, нигде так хорошо как на сайте нет. Даже
> затеял было свой веб интерфейс написать к mpd, с маджонгом и
> поэтессами, да за отсутствием практического опыта в программировании
> так на стадии затевания и остановился. А ведь если переписать и учесть
> не только системные, но все файлы, то тут сразу и база для музыки,
> только знай сортируй. При сканировании-то можно и file выполнить, а
> если file подскажет то и теги втянуть какие есть, благо полное
> сканирование одно, а потом только разницу находить. Да там уж и модули
> для облегчения расстановки тегов налепить недолго. Конечно, здесь и
> учитывать можно кому принадлежит файл, на всякий случай, при запросе
> что бы поправляться. А уж если у нас и музыка пошла, то отчего заодно
> и изображения не облагородить. Кстати, тут у меня и текстовые файлы
> завалялись.
> 
> С другой стороны, я понимаю конечно что уже есть у каждой программы
> своя маленькая база данных, и у музыки, и у картинок, и даже все кто
> поумнее уже и на sql и такой экзотический велосипед только смешным
> может показаться. Но кажется мне, всё же, что у одной, общей, единой
> базы определённо есть свои достоинства. Ну там, музыка от фильма,
> кадры из него-же, а фильм наоборот по книге, а книга по историческим
> событиям, ой, понесло уже... ладно.
> 
> В общем, мне кажется, что использование базы данных для связывания
> сырого информационного материала может позволить избавить пользователя
> от необходимости знать про такие несуразные вещи как файлы. Впрочем,
> что кажется, именно это и происходит: в f-spot'ах, digikam'ах,
> менеджерах музыкальных коллекций. Остаётся только делать следующий
> шаг, сменить зоопарк баз одной, One world, One Web, One Program! (а
> что там в оригинале, кстати, было, не помню).
> 
> Конечно, для полноценной работы с информацией необходимо то, что мы
> называем "пониманием" текста. Но когда этого можно будет ожидать -
> неизвестно, а с другой стороны такое структурирование информации по
> моему может быть до какой то степени и катализирует процесс.
> 
> Да, в целом за бортом остались, видимо, служебные записки да прочая
> бюрократия, но когда с объектами культуры получится управиться -
> глядишь и на них какая управа найдётся.
> 
> Ой, как собирался, да так ничего и не спросил. Ну в общем, хотя бы
> безумная это идея или банальная? Пусть так, что ли, будет. И это,
> может быть действительно, имеет смысл сделать sql базу хотя бы по
> системным файлам?
> _______________________________________________
> smoke-room mailing list
> smoke-room@lists.altlinux.org
> https://lists.altlinux.org/mailman/listinfo/smoke-room

Re: [room] безумные (банальные?) идеи

[Алексей Синицын]

15 февраля 2011 г. 12:24 пользователь Denis  Medvedev <a_mdl@mail.ru> написал:

> http://www.libferris.com/
> Правда собрать это чудо - немалых сил требует. У меня не получилось...

 Если я правильно понял, это что то типа файловой системы внутри базы данных?

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

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

 Если что и имеет смысл, то отдельное хранение метаданных. Что уже
сейчас довольно распространено. Просто может быть имеет смысл вести
одну, большую базу по всем файлам в системе (да, сменные и сетевые ФС
это отдельный вопрос). И с ней смогут поиметь дело все кому нужно,
думаю некоторый потенциал у такого явления есть.

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

Re: [room] безумные (банальные?) идеи

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 2113 bytes --]

On Tue, Feb 15, 2011 at 08:12:48PM +0300, Алексей Синицын wrote:

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

Это понятно. Однако иерархическая структура хранения информации в
сколь-нибудь сложных случаях просто не работает.

Вот самый простой пример -- у нас есть коллекция mp3. Как их раскладывать
по каталогам? Стиль, темп музыки, автор, альбом, название песни,
исполнители, год издания...

Ну и как это структурировать? Потому все навороченные плееры строят свою
_БД_ по этим mp3, с поиском по ней.

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

Да. Но неудобная для поиска, увы.

Поэтому в любом случае создается БД с какой-либо доп. информацией. locate,
recoll -- это все костыли (ибо обновление происходит периодически, а не в
момент обновления данных).

>  Если что и имеет смысл, то отдельное хранение метаданных. Что уже
> сейчас довольно распространено. Просто может быть имеет смысл вести
> одну, большую базу по всем файлам в системе (да, сменные и сетевые ФС
> это отдельный вопрос). И с ней смогут поиметь дело все кому нужно,
> думаю некоторый потенциал у такого явления есть.
>  А уж если немного помечтать, то было бы занятно увидеть на
> персоналках аппаратные ускорители БД, подобно существующим ускорителям
> графики.

БД на многих задачах и так сильно быстрее чем обычные FS. Кроме того в БД
есть фишки недоступные в FS, например транзакции.

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

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [room] безумные (банальные?) идеи

[Алексей Синицын]

15 февраля 2011 г. 22:30 пользователь Денис Смирнов
<mithraen@freesource.info> написал:

>>  Файлы это не более и не менее чем контейнеры для сырых данных. Если
>> не ошибаюсь, определение файла - это "именованная область данных".
>> Данные на накопителях в любом случае надо как то располагать, вот уже
>> готовая хорошая технология.
>
> Да. Но неудобная для поиска, увы.
>
> Поэтому в любом случае создается БД с какой-либо доп. информацией. locate,
> recoll -- это все костыли (ибо обновление происходит периодически, а не в
> момент обновления данных).
>

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

>>  Если что и имеет смысл, то отдельное хранение метаданных. Что уже
>> сейчас довольно распространено. Просто может быть имеет смысл вести
>> одну, большую базу по всем файлам в системе (да, сменные и сетевые ФС
>> это отдельный вопрос). И с ней смогут поиметь дело все кому нужно,
>> думаю некоторый потенциал у такого явления есть.
>>  А уж если немного помечтать, то было бы занятно увидеть на
>> персоналках аппаратные ускорители БД, подобно существующим ускорителям
>> графики.
>
> БД на многих задачах и так сильно быстрее чем обычные FS. Кроме того в БД
> есть фишки недоступные в FS, например транзакции.
>
> Программисты уже потихоньку понимают что использовать БД удобнее чем plain
> files, и в эту сторону начинается активное движение.

 Всю систему в базу неверно не загонишь, да и едва ли это нужно. А
началась история с программы kleansweep, и это тоже пример
использования.

 Данные загнать можно наверно все. Но у меня один вопрос. В случае
разрушения базы данные будет легко восстановить? А не у меня наверно и
другие вопросы могут появиться.

 Мне кажется, что, по аналогии с многоуровневой моделью OSI, файлы
останутся существовать одним из слоёв. Хотя бы для удобства
транспортировки. Вот мне, например, пакеты TCP жить совершенно не
мешают. Ну и во всяком случае, прилепить базу к всей файловой системе
это не так радикально как все данные туда, в эту базу, загнать. В
конце концов, можно прилепить базу для обкатки модели запихивания
данных туда внутрь, как временный компромисс :)

Re: [room] безумные (банальные?) идеи

[Денис Черносов]

2011/2/15 Алексей Синицын <asinitsinster@gmail.com>:
>> Программисты уже потихоньку понимают что использовать БД удобнее чем plain
>> files, и в эту сторону начинается активное движение.

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

См. http://ru.wikipedia.org/wiki/Контекст и особо обратите внимание на строчку:

"Любое событие происходящие в жизни субъекта интерпретируется исходя
из контекста ситуации отраженной в *памяти* субъекта"

Любые наши понятия, любые наши действия и особенно ВЗАИМОдействия -
модельны и контекстны. Память и время на обработку - ограничены. А мир
- бесконечен.

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

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

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

Формат и объем метаданных - это отражение модели и контекста.
Индексирование метаданных = выделение контекста. Контекст выделяется
для облегчения работы с данными, но когда индексы становятся
сравнимыми по объему с исходными данными - нафиг они не нужны! В
какой-то момент нужно останавливаться и доставать таблетки от
жадности.

В народ идут только достаточно простые НЕуниверсальные контексты,
привязанные к конкретным задачам.

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

Видеохостинг развивается достаточно независимо от календаря. И т.д. и
т.п. Специализация оказывается дешевле универсализации.


Впрочем, повторно вспоминаю akonadi + strigi. Поставьте в индексацию
системные файлы и они будут ими индексироваться. Вот только "зачем"?
Что вы надеетесь чудесным образом наковырять в служебных файлах?  Если
у вас есть ответ на этот вопрос - автоматизация уже не проблема... а
задача. Причём, типовая.

-- 
С уважением,
Черносов Денис

Re: [room] безумные (банальные?) идеи

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 3215 bytes --]

On Wed, Feb 16, 2011 at 12:21:21AM +0300, Денис Черносов wrote:

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

ППКС.

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

google -> GTD.

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

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

> Формат и объем метаданных - это отражение модели и контекста.
> Индексирование метаданных = выделение контекста. Контекст выделяется
> для облегчения работы с данными, но когда индексы становятся
> сравнимыми по объему с исходными данными - нафиг они не нужны! В
> какой-то момент нужно останавливаться и доставать таблетки от
> жадности.

Иногда индексы нужны даже если их объем существенно превышает объем
данных.

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

> В народ идут только достаточно простые НЕуниверсальные контексты,
> привязанные к конкретным задачам.

См. GTD.

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

Google waves не пошел потому что неочевиден. Гугль не смогли создать
простые и эффективные usecases.

А мегамогучая фиговина нужна только IT'шникам, чтобы было с чем поиграть.

> Видеохостинг развивается достаточно независимо от календаря. И т.д. и
> т.п. Специализация оказывается дешевле универсализации.

А в ходе это специализации рождаются универсальные технологии (memcached в
web -- самый известный пример). Ну или тот же nginx :)

> Впрочем, повторно вспоминаю akonadi + strigi. Поставьте в индексацию
> системные файлы и они будут ими индексироваться. Вот только "зачем"?
> Что вы надеетесь чудесным образом наковырять в служебных файлах?  Если
> у вас есть ответ на этот вопрос - автоматизация уже не проблема... а
> задача. Причём, типовая.

Вот формулирование нужных процессов, а также удобный инструмент
автоматизации их (на уровне "пользователь может сконфигурять сам без
команды крутых спецов с суммарной з/п >50k$/месяц") и есть проблема.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [room] безумные (банальные?) идеи

[Алексей Синицын]

16 февраля 2011 г. 3:05 пользователь Денис Смирнов
<mithraen@freesource.info> написал:
> On Wed, Feb 16, 2011 at 12:21:21AM +0300, Денис Черносов wrote:
>
>> Истина где-то между, но тысячелетия практики обработки данных
>> показывают, что везде, где это возможно - лучше идти по пути
>> максимального упрощения модели, требующей соотв. минимального
>> контекста. И формализации бизнес-процессов. Плюс механизм расширения
>> функционала под каждую конкретную задачу.
>
> ППКС.
>

 Простота и пустота не одно и то же.

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

>> Формат и объем метаданных - это отражение модели и контекста.
>> Индексирование метаданных = выделение контекста. Контекст выделяется
>> для облегчения работы с данными, но когда индексы становятся
>> сравнимыми по объему с исходными данными - нафиг они не нужны! В
>> какой-то момент нужно останавливаться и доставать таблетки от
>> жадности.
>
> Иногда индексы нужны даже если их объем существенно превышает объем
> данных.
>
> Суть индекса в получении _быстрого_ ответа. И потому требования к нему
> зависят исключительно от используемых процессов, и могут быть никак не
> связаны с размером данных.
>

 Индексы нужны хотя бы потому, что это, как верно замечено выше,
метаинформация.

 То есть, модель более общего характера, что очевидно более ценно. И с
чем манипуляции будут происходить более эффективно.

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

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

>> Видеохостинг развивается достаточно независимо от календаря. И т.д. и
>> т.п. Специализация оказывается дешевле универсализации.
>
> А в ходе это специализации рождаются универсальные технологии (memcached в
> web -- самый известный пример). Ну или тот же nginx :)
>

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

 Говорите такое уже есть? А я могу к этому аконади или к стриги, к
биглю, если он ещё живой, как к бэкенду, подключить проигрыватель
музыки, прсмотрщик изборажений? А что, в случае нескольких
пользователей это опять куча баз у кучи СУБД?

>> Впрочем, повторно вспоминаю akonadi + strigi. Поставьте в индексацию
>> системные файлы и они будут ими индексироваться. Вот только "зачем"?
>> Что вы надеетесь чудесным образом наковырять в служебных файлах?  Если
>> у вас есть ответ на этот вопрос - автоматизация уже не проблема... а
>> задача. Причём, типовая.
>
> Вот формулирование нужных процессов, а также удобный инструмент
> автоматизации их (на уровне "пользователь может сконфигурять сам без
> команды крутых спецов с суммарной з/п >50k$/месяц") и есть проблема.
>

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

Re: [room] безумные (банальные?) идеи

[Денис Черносов]

2011/2/16 Алексей Синицын <asinitsinster@gmail.com>:
>  Говорите такое уже есть? А я могу к этому аконади или к стриги, к
> биглю, если он ещё живой, как к бэкенду, подключить проигрыватель
> музыки, прсмотрщик изборажений? А что, в случае нескольких
> пользователей это опять куча баз у кучи СУБД?

Аконади - это API для высокоуровневого доступа к БД, в которой можно
сохранять всякие письма, контакты, календари, тэги и т.п. В качестве
хранилища рекомендуют MySQL, возможно ещё какие-то движки
поддерживаются - давно не интересовался.

Strigi - это локальный поиск и индексация.

Есть ещё Nepomuk - API для использования готовых и составления своих
схем метаданных. В Dolphin позволяет проставлять всякие метки и
рейтинги на файлы.

Совместное использование аконади точно возможно, про остальное врать
не буду - не знаю.

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

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


Однако вопросы всё равно будут. Как объяснить пользователю, что этот
календарь лежит на его локальной машине, а тот в локальной сети, а вот
этот - в интернете? Соотв., одни записи можно увидеть везде, другие
только на работе, третьи - только при доступе в инет. Причём, ладно
чтение - как его научить сохранять свои записи туда, куда надо?

Как объяснить ему, что скажем Strigi нашёл ему вчера файлы с внешнего
винта, а сегодня их уже там нет по причине того, что винт отключили?

Всё становится более зыбким и менее предсказуемым... Поиск
превращается в увлекательное приключение... Впрочем, может быть я
сгущаю краски :)


Гугл и прочие поисковики хороши тем, что связывают то, что существует
и развивается независимо. А на своей машине и даже в своей сети лучше
создавать и поддерживать связи более-менее осмысленно.  По крайней
мере те связи, которые критически важны. Это создаёт порядок в головах
и предотвращает "разруху в клозетах" (с) "Собачье сердце". ИМХО.

-- 
С уважением,
Черносов Денис

Re: [room] безумные (банальные?) идеи

[Денис Черносов]

16 февраля 2011 г. 3:05 пользователь Денис Смирнов
<mithraen@freesource.info> написал:

> google -> GTD.

Спасибо! Очень заинтересовало.

-- 
С уважением,
Черносов Денис

Re: [room] безумные (банальные?) идеи

[Алексей Синицын]

16 февраля 2011 г. 0:21 пользователь Денис Черносов
<denis0.ru@gmail.com> написал:
> 2011/2/15 Алексей Синицын <asinitsinster@gmail.com>:
>>> Программисты уже потихоньку понимают что использовать БД удобнее чем plain
>>> files, и в эту сторону начинается активное движение.
>
> Я много на эту тему размышлял и пришёл к "своему" базовому понятийному
> кирпичику, от которого вытанцовываются все остальные выводы. Имя ему -
> "контекст".
>
> См. http://ru.wikipedia.org/wiki/Контекст и особо обратите внимание на строчку:
>
> "Любое событие происходящие в жизни субъекта интерпретируется исходя
> из контекста ситуации отраженной в *памяти* субъекта"
>

 Контекст это хорошо. Но если мы потянем за эту ниточку, то можем
утянуть далеко. Если мы начнём выяснять что такое контекст, то найдём
что это текст, просто относящийся к текущему как внешний. Естественно
попытаться уточнить что такое текст, и тут мы найдём что текст это
дамп информации, которая, в свою очередь является моделью. Модель,
которую строит ЦНС живого организма, то есть, вне нас информации не
существует вообще. А обмен информацией это синхронизация моделей
отдельных людей.

> Любые наши понятия, любые наши действия и особенно ВЗАИМОдействия -
> модельны и контекстны. Память и время на обработку - ограничены. А мир
> - бесконечен.
>

<cite> Сначала он находил это забавным. Он изобрел закон, который с
юмором, подобным закону Паркинсона, утверждал, что "количество
рациональных гипотез, способных объяснить любое данное явление,
бесконечно". Ему нравилось никогда не испытывать недостатка в
гипотезах. Даже когда все его возможные методы экспериментальной
работы, казалось, заводили в тупик, он знал, что если просто сядет и
повозится с работой достаточно долго, то, конечно же, появится еще
одна гипотеза. И она всегда появлялась. И только месяцы спустя после
того, как он придумал этот закон, начали возникать кое-какие сомнения
по поводу его юмора или полезности. </cite>

Роберт М. Пирсиг

> Чем более громоздок и универсален контекст - тем более дороги его
> освоение, поддержка и использование.  Слишком примитивный контекст не
> позволяет реализовать адекватную модель. Бесконечный контекст -
> потребует бесконечной памяти и сведёт на нет все плюсы от его
> использования.
>
> Истина где-то между, но тысячелетия практики обработки данных
> показывают, что везде, где это возможно - лучше идти по пути
> максимального упрощения модели, требующей соотв. минимального
> контекста. И формализации бизнес-процессов. Плюс механизм расширения
> функционала под каждую конкретную задачу.
>

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

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

 Нуу.., кроме бизнес-процессов. Про это ничего не могу сказать :)
Возможно всё то же самое.

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

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

> Формат и объем метаданных - это отражение модели и контекста.
> Индексирование метаданных = выделение контекста. Контекст выделяется
> для облегчения работы с данными, но когда индексы становятся
> сравнимыми по объему с исходными данными - нафиг они не нужны! В
> какой-то момент нужно останавливаться и доставать таблетки от
> жадности.
>

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

> В народ идут только достаточно простые НЕуниверсальные контексты,
> привязанные к конкретным задачам.
>
> Google waves в народ не пошёл, хотя мегамогучая фиговина, стирающая
> грани между большинством протоколов и хранилищ. А электронная почта
> никак не убивается, несмотря на все её очевидные недостатки.
>

 Ой, видел я эти волны. Может и мощно, но ничего не понятно и всё тормозит.

> Видеохостинг развивается достаточно независимо от календаря. И т.д. и
> т.п. Специализация оказывается дешевле универсализации.
>

 А потом приходит общая теория, которая включает в себя все предыдущие
как частные случаи :)

> Впрочем, повторно вспоминаю akonadi + strigi. Поставьте в индексацию
> системные файлы и они будут ими индексироваться. Вот только "зачем"?
> Что вы надеетесь чудесным образом наковырять в служебных файлах?  Если
> у вас есть ответ на этот вопрос - автоматизация уже не проблема... а
> задача. Причём, типовая.
>

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

Re: [room] безумные (банальные?) идеи

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1680 bytes --]

On Tue, Feb 15, 2011 at 11:39:11PM +0300, Алексей Синицын wrote:

>  Обновление с опозданием это действительно проблема. Но думаю что не
> самая страшная. Можно придумать изящный костыль! В конце концов, как
> известно весь линукс это система костылей и подпорок, но очень
> красивая система костылей и подпорок :)

Это UNIX стройная система костылей и подпорок. Нынешний Linux с всякими
Gnome и KDE -- это каша из дерьмового кода с редкими плавающими в ней
жемчужинами :)

>  Всю систему в базу неверно не загонишь, да и едва ли это нужно. А
> началась история с программы kleansweep, и это тоже пример
> использования.

Не надо загонять систему куда бы то ни было. Вопрос о пользовательском
интерфейсе и пользовательских данных.

>  Данные загнать можно наверно все. Но у меня один вопрос. В случае
> разрушения базы данные будет легко восстановить? А не у меня наверно и
> другие вопросы могут появиться.

В случае разрушения FS данные очень нелегко восстановить. 

>  Мне кажется, что, по аналогии с многоуровневой моделью OSI, файлы
> останутся существовать одним из слоёв. Хотя бы для удобства
> транспортировки. Вот мне, например, пакеты TCP жить совершенно не
> мешают. Ну и во всяком случае, прилепить базу к всей файловой системе
> это не так радикально как все данные туда, в эту базу, загнать. В
> конце концов, можно прилепить базу для обкатки модели запихивания
> данных туда внутрь, как временный компромисс :)

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

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [room] безумные (банальные?) идеи

[Алексей Синицын]

16 февраля 2011 г. 2:57 пользователь Денис Смирнов
<mithraen@freesource.info> написал:

>> известно весь линукс это система костылей и подпорок, но очень
>> красивая система костылей и подпорок :)
>
> Это UNIX стройная система костылей и подпорок. Нынешний Linux с всякими
> Gnome и KDE -- это каша из дерьмового кода с редкими плавающими в ней
> жемчужинами :)
>

 Наследничек.. :) Времена меняются, какие времена, такие и наследники :)

>>  Данные загнать можно наверно все. Но у меня один вопрос. В случае
>> разрушения базы данные будет легко восстановить? А не у меня наверно и
>> другие вопросы могут появиться.
>
> В случае разрушения FS данные очень нелегко восстановить.
>

 Наверно тогда лучше так. Мне говорили что база SQL это один файл. Это
не соответствует? И если сответствует, то что произойдёт если во время
записи пропадёт питание? Да, мы вроде про домашние устройства, где
возможно отсутствие ИБП. ФС убиваются в хлам, насколько мне известно,
не так часто. Чаще теряется часть файлов. Большее количество файлов
может дать большую устойчивость.

 Да, наверно можно базу и на сыром разделе держать, но тогда СУБД так
или иначе всё равно вынуждена будет выполнять функции ФС. Возможно
дешевле оставить ФС как носитель.

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

 Ой. Посмотрел было, а оно не заработало у меня :) И понял я что не судьба :)

Re: [room] безумные (банальные?) идеи

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1098 bytes --]

On Wed, Feb 16, 2011 at 08:45:57PM +0300, Алексей Синицын wrote:

>  Наверно тогда лучше так. Мне говорили что база SQL это один файл. Это
> не соответствует? И если сответствует, то что произойдёт если во время
> записи пропадёт питание? Да, мы вроде про домашние устройства, где
> возможно отсутствие ИБП. ФС убиваются в хлам, насколько мне известно,
> не так часто. Чаще теряется часть файлов. Большее количество файлов
> может дать большую устойчивость.

БД бывают разные. Некоторые в одном файле (как sqlite), некоторые в группе
файлов (как постгрес или mysql), некоторые умеют работать на raw disk (как
оракл).

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

>  Да, наверно можно базу и на сыром разделе держать, но тогда СУБД так
> или иначе всё равно вынуждена будет выполнять функции ФС. Возможно
> дешевле оставить ФС как носитель.

Для БД которые в одном файле, например, не придется. Потому что им от ФС
нужно очень-очень мало.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [room] безумные (банальные?) идеи

[Rinat Bikov]

15 февраля 2011 г. 22:30 Денис Смирнов написал:
> БД на многих задачах и так сильно быстрее чем обычные FS. Кроме того в БД
> есть фишки недоступные в FS, например транзакции.
ZFS? С точками восстановления и откатами?
Вроде бы те же самые транзакции :).

-- 
С уважением, Ринат Биков.

Re: [room] безумные (банальные?) идеи

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 412 bytes --]

On Wed, Feb 16, 2011 at 10:43:52PM +0300, Rinat Bikov wrote:

RB> ZFS? С точками восстановления и откатами?
RB> Вроде бы те же самые транзакции :).

Ну ZFS это уже несколько... э... необычная FS. С учетом того что у нее и
LVM свой, и вообще она разве что кофе варить не умеет.

-- 
С уважением, Денис

http://mithraen.ru/
----------------------------------------------------------------------------

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]