LINUX.ORG.RU

Вы всё ещё не пользуетесь семантическим десктопом?

 ,


2

1

Разработчики KDE начали глубокую оптимизацию и без того реактивного (с версии 4.10) Nepomuk. Дело в том, что сейчас связь приложений и Virtuoso осуществляется посредством локальных сокетов, но в KDE 4.11 она будет реализована напрямую через драйвер ODBC, что, по предварительным оценкам, увеличит скорость работы Nepomuk от 30% до 6-7 раз. Например, время вывода 50 тысяч результатов сократится с ~20 секунд до 2,5 секунд. Также эти меры позволят снизить загрузку процессора базой Nepomuk. Это ли не epic win?

Кстати, в более отдалённых версиях KDE (возможно, 4.12) в Nepomuk будет интегрирован модуль Webminer, позволяющий автоматически или вручную выкачивать с определённых сайтов для фильмов, сериалов, документов, музыки такие метаданные, как жанры, режиссёры, актёры, даты выхода, синопсисы, рецензии и так далее. Пока что этот модуль доступен лишь в виде сторонней припарки, впрочем, работает он прекрасно, вот пример.



Последнее исправление: cetjs2 (всего исправлений: 1)
Ответ на: комментарий от feofan

Например?

Kdepim и всё, что с ним связано.

Фрагментация сообщества — это не очень хорошо

Знаешь, меня всегда удивляли подобные заявления. Сообщество - это не куча подневольных менеджерам программистов. И когда кто-то заявляет, что он будет пилить форк/особую сборку/дистрибутив - это не значит, что злые менеджеры перекинули часть кодеров с основного проекта на форк/особую сборку/дистрибутив. Это значит лишь, что этим кодерам интересно заняться форком/особой сборкой/дистрибутивом, а основным проектом им заниматься неинтересно. Или форком/особой сборкой/дистрибутивом будут заниматься совершенно другие люди. Ну в самом деле, количество участников сообщества - величина не константная же. Люди приходят, люди уходят. А если все убежали с основного проекта - значит, этот основной проект так горячо нужен людям :) К счастью, KDE таких проблем не имеет.

Короче, брюзжание на тему «какими глупостями занимаются люди, лучше бы занимались тем-то и тем-то» - это совковый рак мозга, и от него нужно избавляться. Пусть люди занимаются тем, что им приятно, оставьте их в покое :)

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

В целом согласен. Только вот от этого часто бывает, что не допилено ни то, ни другое. Хотя, если бы пилили вместе, можно было бы реализовать обе идеи в рамках одного проекта, с опциями. Хотя тогда может получиться комбайн. Но тут должна быть хорошо продумана архитектура. Если будет возможность обмениваться модулями между KDE и KlyDE, то это прекрасно.

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

По фильмам webminer может выкачивать данные с двух сайтов: imdb и the movie database. Правда, с imdb, сколько я ни пытался, ничего получить не удалось, поэтому я пользуюсь вторым.

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

Вроде нет. Автор сказал, что он не успевает отполировать своё детище до заморозки KDE 4.11

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

Сам поиск есть и в find. А кому надо быстрый контекстный поиск, для тех есть recoll. От фигни типа непомука ожидаешь тесную интеграцию это самого поиска с приложениями, а также приложений между собой, и вообще ОС давно нуждаются в стандартизации данных и возможности интеграции приложений.

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

От фигни типа непомука ожидаешь тесную интеграцию это самого поиска с приложениями

Она уже есть, через KIO.

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

Да? И если я начну вводить адрес в kmail они в автокомплите покажет адрес из текста письма из громоптицы? Или хотя бы из ее адресной книги? Я могу ожидать что если в поиске в kate не найдется вхождений на страницы то оно мне покажет результаты поиска по файлам в папке файл из которой у меня открыт в kate?

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

И если я начну вводить адрес в kmail они в автокомплите покажет адрес из текста письма из громоптицы?

А причём тут какая-то громоптица? Это кде-приложение?

Я могу ожидать что если в поиске в kate не найдется вхождений на страницы то оно мне покажет результаты поиска по файлам в папке файл из которой у меня открыт в kate?

Абсолютно нелогичное поведение.

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

Ну тут какой кейс. Просто он сильно расширяет возможности поиска, чем и упрощает жизнь в некоторых случаях. Да и мгновенный поиск это очень приятно. Кстати, какую версию KDE используешь?

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

По PDF-кам умеет искать Okular.

У меня не стояла задача искать по куче PDF'ок, а лишь по одиночным файлам. Иначе я бы искал другие инструменты.

Chaser_Andrey ★★★★★
()

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

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

А причём тут какая-то громоптица? Это кде-приложение?

Ну тогда давайте не будем называть KDE-поиск семантическим десктопом? Все-таки от «десктопа» ожидаешь работы со всеми десктопными приложениями, или хотя бы с большинством распространенных.

Абсолютно нелогичное поведение.

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

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

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

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

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

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

Переход на личности осуществил ты сам, сказав, что тебе это не нужно, тогда как обсуждается вича кед. Так что типичный ЛОРовец здесь скорее ты.

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

сволочи! пришло время переходить на LXDE. или twm :)

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

Еще раз - в смысле интеграцию всего и вся.

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

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

Если я ищи какую нибудь хрень в браузере, почему бы непомуку не заглянуть в индекс локальных документов?

Должен быть глобальный семантический и объектный контекст системы адаптирующийся под ситуацию и время.

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

Ну тогда давайте не будем называть KDE-поиск семантическим десктопом?

С чего бы это? KDE - K Desktop Environment. Так что Nepomuk самый что ни на есть семантический десктоп.

Все-таки от «десктопа» ожидаешь работы со всеми десктопными приложениями, или хотя бы с большинством распространенных.

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

Если я ищу что-то в коде, то с большой долей вероятности если этого нет в открытом файле, то где-то рядом это есть

В Kate ты работаешь с конкретным файлом. Если ты чего-то не нашёл в этом файле - пожалуйста жми Alt+F2 и ищи через KRunner, благо Nepomuk интегрирован и туда.

Если приложение предпочитает работать логично для себя в ущерб удобству пользователя, то пусть оно работает где-нибудь в раю для приложений для исключительно своего удовлетворения.

В том-то и дело, что «логично» - это и есть «удобно». Впрочем, это для нормальных людей так, как там для ГСМ я не в курсе.

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

Реколл ищет быстрее

Пруф?

индексация во время индексирования не отвлекается на захавывание всех доступных ресурсов

А Nepomuk тоже не хавает все ресурсы и индексирует очень быстро.

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

Я хочу

Я хочу

Должен быть

Это всё круто, но ты поди объясни авторам сторонних поделок, что пора бы начать поддерживать уже работающее решение (Nepomuk), а не городить свои костыли или даже просто игнорировать его.

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

Пруф?

Не мерял. Просто по ощущениям. Когда пробовал последний раз мне показалось что 1-2 секунды это несколько быстрее чем никогда. Хотя возможно только показалось.

А Nepomuk тоже не хавает все ресурсы и индексирует очень быстро.

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

Впрочем убедил - потрогаю еще раз.

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

Если ты в прошлый раз ещё застал Strigi, то твой опыт уже нерелевантен, т.к. в KDE 4.10 Strigi был выпилен в пользу самописного индексатора, который не глючит и работает реактивно.

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

Это всё круто, но ты поди объясни авторам сторонних поделок, что пора бы начать поддерживать уже работающее решение (Nepomuk), а не городить свои костыли или даже просто игнорировать его.

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

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

Если ты в прошлый раз ещё застал Strigi, то твой опыт уже нерелевантен, т.к. в KDE 4.10 Strigi был выпилен в пользу самописного индексатора, который не глючит и работает реактивно.

О как. Это годное известие. А чего xapian не взяли? На момент когда я выбирал контекстный поисковик он был единственным вменяемым. Там и делов-то было что форкнуть и переименовать в Ksapian ;)

Suntechnic ★★★★★
()
Последнее исправление: Suntechnic (всего исправлений: 1)
Ответ на: комментарий от X10Dead

Новым витком тут и не пахнет. Только ОС морфнутая в БД, даст гибкость, надежность и уверенность в том что все на месте, все соберется, все найдется. А пока, это костыль.

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

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

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

Гномовский и Юнитовский Zeitgeist, кстати, следует стандартам Nepomuk.

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

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

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

Агрессивный какой попался. Даже по LOR'овским меркам агрессии многовато. Впрочем, спишем это на весну, пубертатный период и гормоны.

carasin ★★★★★
()

Давно пользуюсь.

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

Где хранятся теги? В каждом каталоге или база в одном месте?

База в ~/.kde4/share/apps/nepomuk/repository/main/data/virtuosobackend/

У меня она, кстати, уже 1,7 Гб весит (всего 55 тысяч файлов в индексе, представляю каких размеров она будет при хотя бы миллионе файлов) :)

Что, если я захочу перенести файлы на другой комп?

Это интересный вопрос.

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

Угу угу, то-то фс обрастают индексами, а под ОС пишут ПО (велосипеды) пытающиеся повторить запросы БД. И что-то как-то не тормозит. Если непонятен концепт моего высказывания, то я уже ничем не помогу.

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

К пути, судя по всему. Да, это хреново, но если сделать по хэшу, то индексация будет адски тормозить на больших файлах. Тем более, даже в этом случае непонятно как отслеживать перемещения файлов - не будешь же пересканировать все ФС на каждый чих?

Короче, нужна поддержка со стороны самой ФС, иначе никак, как мне кажется.

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

Концепт-то понятен, но ты представляешь насколько доступ к БД медленнее чем к файлам? А ведь основная задача файлов хранить данные, а не искаться.

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

ты представляешь насколько доступ к БД медленнее чем к файлам?

Насколько?

А ведь основная задача файлов хранить данные, а не искаться.

Как раз в настоящее время проблема эффективного поиска информации вышла на первое место.

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

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

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

К пути, судя по всему. Да, это хреново, но если сделать по хэшу, то индексация будет адски тормозить на больших файлах. Тем более, даже в этом случае непонятно как отслеживать перемещения файлов - не будешь же пересканировать все ФС на каждый чих?

Тормозить? Никто тебе не запрещает хранить для больших файлов дополнительно еще «упрощенный» хэш по, скажем 1кб составленному из начала, середины и конца файла.

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

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

Насколько?

От нескольких раз до нескольких сотен раз. Померяй. Даже между nosql вытащеными в раму и просто файлами разница в 10 раз при повторном доступе. При холодном сопоставимо, но nosql то целиком в раме...

Как раз в настоящее время проблема эффективного поиска информации вышла на первое место.

Ну нашел ты кинушку, предположим. Тебе легче стало? Посмотреть-то ты ее все равно не сможешь...

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

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

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

Дык никто не говорит, что ФС нужно полностью заменить мусклом. Нужно интегрировать БД в ФС в качестве надстройки.

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