From: "Алексей Синицын" <asinitsinster@gmail.com> To: "Культурный офтопик" <smoke-room@lists.altlinux.org> Subject: Re: [room] безумные (банальные?) идеи Date: Wed, 16 Feb 2011 22:35:01 +0300 Message-ID: <AANLkTinF4tc8FQmG4Urvxc9CDNRDpm20L=Q_LtpWZ0rq@mail.gmail.com> (raw) In-Reply-To: <20110216000501.GD27193@mw.mithraen.ru> 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$/месяц") и есть проблема. > Такие универсальные вещи можно конфигурять и спецами. Чем универсальнее, тем шире применение. Ядро под себя уже далеко не каждый пересобирает, а патчат и того меньше.
next prev parent reply other threads:[~2011-02-16 19:35 UTC|newest] Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-02-15 9:24 ` Denis Medvedev 2011-02-15 17:12 ` Алексей Синицын 2011-02-15 19:30 ` Денис Смирнов 2011-02-15 20:39 ` Алексей Синицын 2011-02-15 21:21 ` Денис Черносов 2011-02-16 0:05 ` Денис Смирнов 2011-02-16 19:35 ` Алексей Синицын [this message] 2011-02-17 7:49 ` Денис Черносов 2011-02-17 7:50 ` Денис Черносов 2011-02-16 17:27 ` Алексей Синицын 2011-02-15 23:57 ` Денис Смирнов 2011-02-16 17:45 ` Алексей Синицын 2011-02-16 19:03 ` Денис Смирнов 2011-02-16 19:43 ` Rinat Bikov 2011-02-16 21:45 ` Денис Смирнов
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='AANLkTinF4tc8FQmG4Urvxc9CDNRDpm20L=Q_LtpWZ0rq@mail.gmail.com' \ --to=asinitsinster@gmail.com \ --cc=smoke-room@lists.altlinux.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Культурный офтопик This inbox may be cloned and mirrored by anyone: git clone --mirror http://lore.altlinux.org/smoke-room/0 smoke-room/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 smoke-room smoke-room/ http://lore.altlinux.org/smoke-room \ smoke-room@lists.altlinux.org smoke-room@lists.altlinux.ru smoke-room@lists.altlinux.com smoke-room@altlinux.ru smoke-room@altlinux.org smoke-room@altlinux.com public-inbox-index smoke-room Example config snippet for mirrors. Newsgroup available over NNTP: nntp://lore.altlinux.org/org.altlinux.lists.smoke-room AGPL code for this site: git clone https://public-inbox.org/public-inbox.git