LINUX.ORG.RU

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


0

0

- это самое простое использование программы которая пишется для поддержания огромных life-time архивов и быстрого нахождения по ключам, которые вы вводите _сами_ (вручную или скриптом) - а не кто-то за вас индексирует всё и вся.
Скриншоты здесь:
http://sourceforge.net/project/screen...
только конструктивно пожалуйста...

>>> а проект конечно на сорсфорже



Проверено: Demetrio ()

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

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

anonymous
()

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

silver
()

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

annonymous ★★
()
Ответ на: комментарий от anonymous

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

Anode
() автор топика
Ответ на: комментарий от silver

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

Anode
() автор топика
Ответ на: комментарий от vm

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

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

Anode
() автор топика
Ответ на: комментарий от annonymous

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

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

Anode
() автор топика

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

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

Anode
() автор топика

насчёт масштабируемости.
Загружал 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 плагин пока недоделан). И, конечно, на оффтопике. Может ужо.
Но масштабируемость уже радует, даже с плоскими файлами.

Anode
() автор топика
Ответ на: комментарий от Anode

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

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

annonymous ★★
()
Ответ на: комментарий от annonymous

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

Anode
() автор топика
Ответ на: комментарий от annonymous

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

Anode
() автор топика
Ответ на: комментарий от Anode

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

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

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

vm ★★
()
Ответ на: комментарий от Anode

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

vm ★★
()
Ответ на: комментарий от vm

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

Anode
() автор топика
Ответ на: комментарий от vm

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

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

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

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

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

Anode
() автор топика
Ответ на: комментарий от vm

2vm

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

Anode
() автор топика
Ответ на: комментарий от anonymous

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

Anode
() автор топика

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

anonymous
()
Ответ на: комментарий от anonymous

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

Anode
() автор топика
Ответ на: комментарий от Anode

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

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

Anode
() автор топика

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

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

Anode
() автор топика

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

Anode
() автор топика
Ответ на: комментарий от Anode

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

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

annonymous ★★
()
Ответ на: комментарий от annonymous

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

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

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

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

Anode
() автор топика
Ответ на: комментарий от Anode

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

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

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

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

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

annonymous ★★
()
Ответ на: комментарий от Anode

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

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

annonymous ★★
()
Ответ на: комментарий от annonymous

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

Anode
() автор топика
Ответ на: комментарий от annonymous

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

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

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

Anode
() автор топика
Ответ на: комментарий от Anode

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

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

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

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

annonymous ★★
()
Ответ на: комментарий от Anode

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

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

annonymous ★★
()
Ответ на: комментарий от Anode

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

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

annonymous ★★
()
Ответ на: комментарий от annonymous

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

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

Anode
() автор топика
Ответ на: комментарий от annonymous

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

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

Anode
() автор топика
Ответ на: комментарий от dddwd

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

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

Anode
() автор топика
Ответ на: комментарий от annonymous

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

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

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

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

Anode
() автор топика

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

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

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

Anode
() автор топика
Ответ на: комментарий от MiracleMan

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

Anode
() автор топика
Ответ на: комментарий от MiracleMan

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

Anode
() автор топика
Ответ на: комментарий от Anode

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

MiracleMan ★★★★★
()
Ответ на: комментарий от timon

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

Anode
() автор топика
Ответ на: комментарий от Anode

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

MiracleMan ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.