Масштабируемый репозиторий букмарков...

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

Ну, сами, это не интересно.

а вот еще идея, чтобы оно периодически отслеживало эти букмарки на предмет изменения и актуальности:)

а у меня всё само индексируется поэтому мне такая программка не нужна

У меня дежавю? Недавно то же самое проходило в новостях, и там уже
популярно было объяснено, почему такими вещами нельзя увлекаться и
чем они вредны.

чем они вредны и почему низя ?

>Ну, сами, это не интересно.
как раз это мне надо было.
поиск в бэкграунде предоставляют и десктоп гугл и яху и grep/awk/sed.
Надо только то что хотите _вы_.

>а вот еще идея, чтобы оно периодически отслеживало эти букмарки на предмет изменения и актуальности:)
лучше не уборщик мусора, наверное (иначе превратиться в pump), а тут-же на изменение, удаление. Пока мне надо добавлять, но конечно и delete надо будет сделать

> а у меня всё само индексируется поэтому мне такая программка не нужна

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

>У меня дежавю? Недавно то же самое проходило в новостях, и там уже
популярно было объяснено, почему такими вещами нельзя увлекаться и
чем они вредны.

а можно ссылку?

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

Да, так как главная задача, которая ставится - это масштабируемость (чтобы я мог и в 2030 году что-то найти в петабайтной уже наверное файлопомойке). Поэтому за функциональность не пиннайте - есть только основа: сохранить - достать. Но и парсинг запросов пропишется когда-нить, и другие фичи, возвращающие сейчас на Гуе - 404 (в первой версии - это только dummy виджеты)

насчёт масштабируемости.
Загружал 6.5млн записей, 80 unicode chars каждая строка, 100-200 строк под каждым ключом, (63 тыс. файлов ~5 уровней в среднем) что взяло 0.55G дискового пространства.
На моём рабочем компьютере P4 1.8G, 512M, с медленным диском (4200), reiserFS, дефолтовой VM (16M мах?), client VM, blackdown 1.4.2 - я не получал более _450мс_ на любой за запрос.
Надо попробовать на XFS, mysql и gdbm и сравнить (mysql плагин пока недоделан). И, конечно, на оффтопике. Может ужо.
Но масштабируемость уже радует, даже с плоскими файлами.

> а можно ссылку?

А сам не вспомнишь то, что постил? Я имел в виду этот поиск по своим
ключам. Не тратьте зря время. Идея гнилая в долгосрочном плане. Просто
немного раскиньте мозгами, и поймёте в чём засада.

дык в чём-же? Убедите меня, докажите.

потом со мной согласен парень делавший доклад на конференции British CS - как раз по поводу life-time archives (мы с ним сговорились;). Скоро будет на ихнем сайте кстати. Такая проблема - не только у меня стоит ;)

я эту проблему лайвбукмарков решаю просто:

cp 23-02-04-2345.jpg ~/store/foto/cell/face

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

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

2vm
>cp 23-02-04-2345.jpg ~/store/foto/cell/face
1. так все делают и я так делал пока не получил такую файлопомойку, что ничего не найти. К примеру, один капкан - это когда в вашем примере будет много имиджей в той директории - "face", а файлосистема - не масштабируема линейно, то есть при тысячах-миллионах файлов - FS (ту что вы используете) начнёт сильно тормозить. Да, именно вы, vm, возможно взгромоздите и настроите XFS, а что делать простому юзеру? Как балансировать то дерево и знать что-где. Но не это таже проблема.
2. Архивы уже есть, на старых рейдах, и никто не захочет покупать - переписывать на новые диски. Тем более переписывание всё дороже и дороже со временем (1T, подумаем о петабайтах и реальной скорости ATA + сети). То-есть старые файлопомойки забиты, вы добавляете дополнительный винт - и у вас уже образуются 2 пути 'face' итд. Где что искать. Это растёт чень быстро.
3. Директории - иерархические, а нужен граф. Если интересно - посмотрите тред запосченный неделю назад
http://www.linux.org.ru/profile/Anode/view-message.jsp?msgid=775270

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

аппликация для поддержания life-time архивов

или второй пункт из:
http://www.infoworld.com/article/05/01/25/HNfuturechallenges_1.html?source=NL...

(можно ещё добавить отвязанное от бизнес-логики хранения архивов, возможное отдельное применение - как масштабируемая персистент хэш с доступом через веб)

я думаю на сайтах проекта определено исчерпывающе. Или посоветуйте как назвать более понятно (реальную цель аппликации вы наверное уже схватили ).

2vm

кста, я думал и о питоне.
вопрос наверное к вам: можно ли (я просто не знаю) зашить питон внутрь аппликации (не устанавливая cygwin), чтобы распаковав несколько-мегабайтный zip или "cvs co ais" или "rsync ..." или же просто копированием из самбы - мы могли бы получить рабочую аппликацию везде - и под оффтопиком и маком и юнихами. Ведь не все будут громоздить линукс как сервер во внутренней сетке. Я и mysql дефолтно отключил - для освобождения юзера от необходимости его ставить (технарь сам пропертю поменяет если нужно и будет использовать любой бекэнд, хоть оракле)

А че масштабируемый, а не скалабле?

>А че масштабируемый, а не скалабле?
потому что боюсь что найду не самое удачное слово - то что применяется в современном русском ИТ языке.
Это как знаете, в переводах классики немецкой философии (например Кант, Гегель, ФН серия) - около ключевых для понимания переведённых терминов ставился немецкий вариант (почти на каждой странице - сноски), так как только он (оригинал) мог перенести изначальную семантику автора. Все переводы - это приближения. Я и беру наиболее точные формулировки, используемые на англоязычных докладах. Ясно? ;)

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

это только сейчас - по одному ключу. Потом можно сделать и гугль (почему гугль, кстати, помню ещё яху не было - альтавистой пользовались. Потом появилось яху;).
Какова бы ни была сила того навешенного наверх ключей языка
(для простейшего первого случая мы его сможем представить как норм. форма: из операций "или"+"не" или же "и"+"не", но будем это делать "от существующего софта, fs, железа", чтобы работало быстро на больших объёмах уже сейчас).
Или введём потом сложную, "левую" эвристику (из нашего чел-го опыта) - как и что искать. Да хоть и язык навесить наверх. Но суть не в этом. Если хорошо подумать (и это не только моя идея но и кажется витает, да и хранение кастомеров в gdb/берклидб - это что?), то самая частая исполняемая операция такого гугля - будет хэш. Быстрая экстракция любой записи когда этих записей очень много. В случае с архивами мы быстро получаем урл или путь на ресурс, что с тем ресурсом делать - уже частный вопрос. В случае букмарков - посмотреть. Архивов - тоже, но уже - локальный файл или всю диру. Можете положить справа записи, поведение и линк на другие ключи - получим граф с любым поведением. В будущем напишем "умную" машину-агента, лопатящую данные и представляющие это для юзера. The sky is the limit. Главное на мой взгляд иметь _самую_быструю_ и плоть до бесконечности большую персистент хэш.
веб - у вас дома, вне зависимости от интернета. И вы сами его строите поверх данных которые _значимы_для_вас_, не впечатляет? построение своей семантической сети?

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

Такие вот мысли.

ещё представьте, что вы говорите ребёнку - по телефону - как запустить игрушку. Я говорю: "пиши: emerge tuxracer; tuxracer".

А теперь я хочу чтобы тот-же ребёнок вытащил старые фото с архивов. Сейчас - я этого ему не позволю (вдруг случайно получатся rm -rf), да и не скоммуницировать нам с ним - что там "grep -r ..." выдаст, да и не знаю я на что искать, пока сам не увижу вывода и самой помойки.
А с ключами - у меня простая дисциплина. все фото - вносим под "images" категорию, все туторы - под "books" && "tutorials" итд.
потом ребёнок не лазит по иконкам, (которые кстати воспринимаются неоднозначно) а просто однозначно пишет фиксированный string который я ему могу проспеллить в конце концов - и он получит то что надо (ну, надо поддержать ещё как делать подзапрос естессно).
Я думаю зачатки такой классификационной дисциплины у народа есть всегда (имена директорий дома). Надо научить большему. В конце-концов про деревья директорий можно будет забыть.

типа: "Вначале было слово..."
-- это к предыдущему моему посту про большую лёгкость консоли :)

> потом со мной согласен парень делавший доклад на конференции British CS - как раз по поводу life-time archives

Ну, он тоже молодой и горячий ещё. Вы с ним сможете ответить на простой
вопрос: есть ли строгие критерии создания ключей и поддаются ли они
вообще описанию? Что случится, если со времением один ключ раздваивается
на два-три направления в связи с изменением описываемой им области? А
что случится, если два-три ключа наоборот со временем придётся воссоединить в один? Каждый раз править руками? Дык вот, к концу жизни
ваш life-time archive станет почти бесполезной грудой информации.
А всё потому, что в данной системе всё основано на субъективном
восприятии и человеческрм факторе.

http://zope.org/Documentation/Books/ZopeBook/2_6Edition/SearchingZCatalog.stx

Дык вот, к концу жизни
ваш life-time archive станет почти бесполезной грудой информации.

дык непомерно дорогой (к тому времени) find/grep/awk/sed остаётся. запустит дедуля на выходные, а как приедет от внучат - найдёт свои очки/мемуары или пошлые стишки что бабке писАл когда генту ещё пользовал;)

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

всё - человеческий фактор. Всё недетерминистично. Вы уверены что завтра вы от гугля получите то же что и сегодня? Когда вы делаете в него запрос - так ли важна _строгость_ наличия и отсутствия _всех_ ключей в вашем сложнейшем запросе?
Большинство делает запрос из одного, ну двух ключей, а потом рефайнит этот запрос подзапросами. Это надо всё обкатывать на практике, обсуждать (и с вами и со всеми) и функция "правильности такой аппликации" будет "сходиться" - возможно, даже к глобальному минимуму (введём шум ;)
возможно к чему-то другому, отличному немного. Будут пользовать, помогать дописывать - _будет_ "сходиться".

> А с ключами - у меня простая дисциплина. все фото - вносим под "images" категорию, все туторы - под "books" && "tutorials" итд.

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

> Я думаю зачатки такой классификационной дисциплины у народа есть всегда (имена директорий дома)

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

Главная проблема этих классификаций - невозможность чёткого их
обоснования. Это раз. Далее, может кто-то не знает, но один и тот же
человек сегодня и через десять лет - это два разных человека на самом
деле ;) То, что хорошо ему сегодня, завтра может быть совсем не нужно
или нужно, но не в таком виде. Так что как ни крути, а данный подход
неразумен даже в рамках одного индифидуума. Впрочем, вам просто нужно
накопить достаточный отрицательный опыт, чтобы до конца понять
несовершенства данного подхода. На пальцах я объяснил как мог.
Вы никогда не сможете тягаться в качестве с индексацией в стиле
google, ибо подход гугла имеет чёткие критерии и отлично описывается
языком, понятным для машины. Вы никогда не сможете побить руками
производительность машины, а чтобы побить её головой, нужно как
минимум иметь чёткую стройную теорию, которой у вас нет.

>http://zope.org/Documentation/Books/ZopeBook/2_6Edition/SearchingZCatalog.stx
спасибо, курим...

> Вы уверены что завтра вы от гугля получите то же что и сегодня?

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

почему, насчёт теорий тоже идеи имеются. Статфизику учили, шеннон, больцман рулят итд ;)
Дело в том, что ценность инфы не хочется фиксить по одному алгоритму. А их - много разных можно применить.
Пока я опираюсь (может и зря, не знаю, только пару лет пользуюсь) на то, что да, я могу забыть какой-то ключ, но я _не_хочу_ словаря, который не прошёл через меня. И этот словарь будет _гораздо_ меньше, чем логарифм энтропии ;) всего документа (а иначе, алгоритмически - вы всё равно что-то упустите;) И я хочу делать поиски над тем словарём. Как правило - пока нахожу. Но можно и показывать ведь - ограниченные дампы (не cat всего, правда?)
Теории есть. Они плохи пока имхо. Надо идти и от человека.

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

Недетерминистически живёте - прямо на рандомальном генераторе. Не трясёт? :) ведь никакой предсказуемости, опоры. Всегда находили снова ту инфу которая встречалась вам раньше?

я уже писал в предыдущем треде про то что иногда тырнета:) нету.

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

И это главная проблема данного подхода. Боюсь, что нерешаемая...

Сделаем банальный разбор существующих ситуаций (case study) на примере
разбития репозитария пакетов дистрибутивов по каталогам.
Slackware: где искать пакет abiword? xap или gnome? Дык вот, он одно
время был в первом, а потом перебрался во второй. В Debian есть политика
разбивки пакетов free/non-free. По этому критерию mysql должна была
находиться в non-free до смены лицензии на GPL, а затем перекочевать
в другое место, так как условие его размещения было изменено со временем.

Примеры простые, а смысл - всё меняется, и нельзя войти в одну и ту же
информационную реку дважды ;)

> Не трясёт? :) ведь никакой предсказуемости, опоры.

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

> я уже писал в предыдущем треде про то что иногда тырнета:) нету.

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

2Anode Если еще не видел, может будет полезна идея с автодополнением от google. http://www.google.com/webhp?complete=1 В браузере предпочитаемый язык должен быть английский.

>Сделаем банальный разбор существующих ситуаций (case study) на примере
разбития репозитария пакетов дистрибутивов по каталогам.

меня всегда бесило это разделение по одному признаку. Особенно бесит - зачем рассовали софт в Генту _так_.
Зато в нём есть один "emerge один_значимый_ключ" который рулит. Вот куда пойдёт человечество из лесов и деревьев :)

забыл дописать, что найдя то что нужно - вы можете запросить это на метадату (free или non-free итд). Но изначально вам пришло в голову (либо кто-то сказал) - одно слово. Как в генту да и везде (apt-get, rpm) - тоже ведь один ключ. Это уже хорошо: чтобы найти любую прогу - знать всего один ключ. А потом можно добавить и другие группы. Как минимум не хуже существующих группировок но - больше.

Если что-то поменялось - и вы об этом не узнали - то для вас это на старом месте. Если узнали что - о, теперь mysql там - то тут-же не отходя от кассы киньте и во вторую группу линк на него. У вас обе групы будут содержать одно и то-же и вероятность найти - больше. Мне кажется нгадо mv и delete запрятать подальше чтобы воспитывать в себе "только add". Диски дешевле вашего жизненного времени на переработку и сортировку:)

>Если еще не видел, может будет полезна идея с автодополнением от google. http://www.google.com/webhp?complete=1 В браузере предпочитаемый язык должен быть английский.

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

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

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

Лучше наверное отделить понятие "ключей" от "категорий хранения" - для ясности - я пробовал на это напирать.

Самый хороший пример наверное: мейлы, логи и то что идёт постоянно.
Так как копирование - это тупик, то вы хотите год от года только добавлять диски в strip array или какой-нибудь lvm. Но иметь доступ (и видеть в одном-двух экранах) - ко всем сразу. И выбрать то что нужно или сделать направленный grep. Но не grep всего архива.

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

вопрос всем кто будет это читать:

КАК ВЫ ХРАНИТЕ БУКМАРКИ когда их много, за много лет, для многих браузеров? (в том числе и для офтопика). Может я чего-то действительно не знаю универсального - из последних достижений свободного софтостроительства (ткните плиз).

позвольте спросить.. это ваш проэкт?

мой, на досуге в основном (последние несколько дней выдались - пописАть, что-то оформить)

http://del.icio.us

Есть extension для Firefox.

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

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

спасибо за линк - будем курить - что это такое, масштабируемость и прочее.

да нет, ничего.. просто уточнил для ясности,.. в общем-то я так и понял.. сам иногда подобным страдаю.. ;-)