Soprano 2.8.0

Ура! Жаль, не пользуюсь поиском, у меня все по каталогам разложено нормально.

Я этот виртуозосопрано старался всячески выпилить, не понимаю кому оно нужно. К счастью майнтейнеры дебиана заменили сопрану на более легкий sqlite.

Ненужно

у меня тоже проги в /usr/bin, но поиск из юнити всё равно удобнее, чем запуск из меню или консоли.

Так что база (sqlite?) с поиском по метаданным нужна.

но поиск из юнити всё равно удобнее, чем запуск из меню или консоли

При чем тут бинарники? Я и сам могу krunner'ом запустить, но документы, фильмы или файлы я не ищу, потому что войти в нужный каталог быстрее.

Бинарники ничем не хуже фильмов, им тоже нужен поиск и метаданные (название и описание). Krunner создаёт собственную базу?

Базу чего? Имени файла? Смотрит в /bin наверное каждый раз.

Krunner создаёт собственную базу?

Нет, он использует существующие: nepomuk, akonadi, и много чего другого.

Ты не прочитал мой коммен? Название и описание, я же написал.

nepomuk и akonadi не нужны для поиска приложений

Нет, он использует существующие: nepomuk, akonadi, и много чего другого.

У меня ни nepomuk ни akonadi не установлены а krunner работает. ЧЯДНТ?

поддержка чистых SQL запросов для Virtuoso

А вот это офигенно. Именно этого в Непомуке и не хватало. Надеюсь, Непомук соответствующе модифицируют.

Название и описания берутся из desktop-файла, и никакая база тут не нужна. Семантический поиск предназначен для сбора тегов и индексации содержания файлов.

Надеюсь, Непомук соответствующе модифицируют.

Soprano и Nepomuk разрабатывают одни и те же люди, так что всё сделают.

А я бы очень хотел выпилить вот это всё: Soprano, Virtuoso, Nepomuk, Akonadi и оставить голый и быстрый KDE (включая KMail). Но кажется разработчики KDE не оставили ни одного шанса на такое выпиливание. Официальный ответ - используйте старые версии KDE. Возможно это в скором времени подтолкнет меня и других пользователей в сторону другого DE, где плюшки для поиска не мешают нормально работать.

где плюшки для поиска не мешают нормально работать.

Чем они мешают работать?

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

Детские проблемы роста, которые в вебе исчезли за 10 лет (потому что нужно обслуживать миллионы пользователей), на десктопе, рассчитанном на одного юзера, существуют лет 20 и ещё столько же могут просуществовать. Жаль.

Базу нужно обновлять. Я вот раз в месяц пользуюсь этим несчастным krunner'ом, зачем мне обновляться?

К счастью майнтейнеры дебиана заменили сопрану на более легкий sqlite.

Странно, есть же более легкий Java Apache Lucene. Хотя наверное из-за того что тянет за собой Java.

не понимаю кому оно нужно

Не понимаю, что тут такого сложного в том, чтобы понять кому оно нужно.

А я бы очень хотел выпилить вот это всё: Soprano, Virtuoso, Nepomuk, Akonadi и оставить голый и быстрый KDE

Выпиливай, кто мешает?

Возможно это в скором времени подтолкнет меня и других пользователей в сторону другого DE, где плюшки для поиска не мешают нормально работать

Bye-bye.

Какая разница? Пусть обновляет по триггеру от менеджера пакетов, к примеру. Не в ручную же?

sqlite
Странно, есть же более легкий Java Apache Lucene

А форд фокус легче, чем эсминец. То, что это разные вещи, мы ведь в рассчёт не берём, правда?

Да пофиг как. Мне эта база не нужна, а я трачу процессорное время на ее обновление. Зачем?

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

Твой комп миллионы вещей делает, которые тебе может быть не нужны.

Не делает, ненужный функционал я либо не ставил, либо выпилил.

Мейнстрим в любом случае нужно затачивать на скорость.

1. Кто это решает?

2. Не нужно жертвовать временем обновления базы ради прироста скорости в поиске, если им пользуется 3,5 человека.

Не нужно жертвовать временем обновления базы ради прироста скорости в поиске, если им пользуется 3,5 человека.

Откуда такая уверенность в количестве пользователей?

Видимо слишком тонко получилось :)

Каков вопрос таков ответ. Человек написал, что сопрано sqlite-ом заменили, я решил продолжить эту линию замен теплого мягким.

Оттуда же, откуда и твоя с ускорением поиска.

2. Нужно. Кому не нужен поиск - не будут его ставить вообще, соответственно пакета, обновляющего базу не будет. А кто поставил - у того поиск должен работать быстро. Медленный софт вообще не нужен (кроме исключительных случаев).

1. Решают разработчики и мантейнеры этого мейнстрима. И сейчас они решают затачивать всё на свистелки и перделки. Мне лично грустно от этого, т.к. на скорость наплевать всем.

2. Мне нужен krunner. Если к нему прикрутят БД вместо обычного парсинга, будет печаль.

Мне лично грустно от этого, т.к. на скорость наплевать всем.

Ну в тех же кедах скорость субъективно не падает. Даже на самой старой моей машине все летает. Да и свистелок там не делают, в основном фиксы.

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

Парсинг файлов - это медленно и ресурсоёмко.

Да. Но он не требует БД, поэтому при редком использовании его можно использовать.

Там, скорее всего, кеш в памяти. memory based key-value storage :). А сравнивать субьективные впечатления от скорости - это к маркетологам. Да и десктопные прогеры, видимо, делают именно так - ага, вроде не тормозит, нормально. Под веб считают секунды, проценты от CPU, памяти, замеряют максимальное количество конкурирующих запросов. Потому что железо своё. А на десктопе - халявное, за него юзер платит.

По твоему утверждению выходит, что БД - сложнее. Если что-то делается редко - давайте по-проще, на файлах.

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

Но кажется разработчики KDE не оставили ни одного шанса на такое выпиливание. Официальный ответ - используйте старые версии KDE.

Вы врете прямо как политик. Это чужь потому как снятием галочек с помощью мышки все это отключается.

А я бы очень хотел выпилить вот это всё: Soprano, Virtuoso, Nepomuk, Akonadi и оставить голый и быстрый KDE (включая KMail).

Немного теории: виртуозо это хранилище данных (база данных). База данных пилится одной компанией программистамы в полный рабочий день и непосредственно данный проект к KDE отношения не имеет. Сопрано по функционалу то же самое, но уже относится к KDE (оно использует Virtuoso, хотя может использовать другие хранилища в качестве backend-ов). Фактически это такая обстактная прослойка, но легко используемая в Qt/KDE (и с рядом функций более высокого уровне чем у Virtuoso).

Там еще есть strigi который занимается индексаций файлов. Nepomuk позволяет к файлам добавлять метаданные и использует strigi для индексации файлов (тоже фактически прослойка с функциями еще более высокого уровня чем в Soprano, эту всю уровневость можно представить аналогично как есть X server используеммый GTK+, GTK+ используется конечным приложением, которое напряму с X сервером не работает). Strigi можно отключить, индексация работать не будет и это уменьшит основное потребление ресурсов, которое можно уменьшить. Можна отключить весь Nepomuk тогда работать с метаданными тоже будет не возможно. Соответсвенно для этого в KDE предусмотренно две галочки. Akonadi тут вообще не при делах.

Akonadi это сервер занимающийся синхронизацией почты/календаря и т.п. Смысла его выпилывать вообще то нет, если Вы хотите использовать kmail (хотя делается это галочкой <сарказм>очень сложно, прям официальные источныки говорят, галочку не снимайте, лучше переходити на другие DE/Старые версии</сарказм>). Akonadi на самом деле уменшает сумарное потребление ресурсов, если Вам нужно что-бы информация о приходе писем/или о необходимости выполнения задачи из Goolge календаря приходила Вам на рабочий стол, так как в памяти не весит весь клиент, а только его часть отвечающая за проверку писем, и например маленький плазмоет с одной функцией показать, что пришло письмо. Назван Akonadi сервером, потому как если из другого приложения будет отправлено письмо, оно сразу же появится среди отправленных например в kmail. Потребление ресурсов сервером Akonadi довольно не значительно, но если Вы снимети соответсвующию галочку для экономии нескольки Мб оперативной памяти, то Akonadi запустится автоматом вместе с kmail2, ну будет у нас запущенно два процесса вместо одного, но потребление памяти будет почти таким же как и в старом kmail, просто часть функций kmail перенесена в другое место. Собственно сами GUI отделены, от синхронизации. Вы можете закрыть kmail, о большое письмо отправится в фоне. Вот не знаю, умеет ли Akonadi автоматом останавливатся, если он никем не используется, если не ошибаюсь умеет. У меня он весит в фоне все время, кушает пару Мб, но информация что пришло письмо появляется в системном трее. Thunderbird такое тоже умее, но весит около 100 Мб, фольза от Akonadi очевидна.

P.S. Респект мне за детальные пояснения, это для Вас :)

И он ищет?

А у них есть планы добавить хэширование файлов и синхронизацию тегов/комментариев через Сеть с другими компьютерами?

Эсли парсить только текстовые файлы, то малых количествах файлов это еще будет работать, но оно ж емеет парсить много форматов, например PDF, ODT. Парсинг с разбором форматов для поиска файлов задачка очень уж жирная.

Об этом наверно лучше спросить Себастьяна (Sebastian Trüg, trueg at kde dot org). Заодно и нам расскажешь.

О чем спор? Не нужно же.
Я завидую гентушникам, которые могут выпилить насмерть этот непомук.

У меня nepomuk постоянно парсит многогиговые mkv файлы, что он хочет в них найти для меня непонятно.

А в настройках убрать парсинг таких файлов религия не позволяет.

Есть только один нюанс у этой благостной картины - оно не работает. То есть, разрисовано, конечно, красиво, архитекторы в восторге, но работать не работает.

На плохих и /странных/ каналах оно на IMAP'е просто ломалось. И если раньше достаточно было просто закрыть/открыть KMail и принудительно запустить переиндексацию, то теперь оно уже так не лечилось (по состоянию на 4.8.2).

По этой же или по какой другой причине отвалились фильтры на IMAP'е. То есть, они, конечно, есть, и иногда даже срабатывают, особенно, при ручном запуске, но это же не тот уровень надёжности, который ожидаешь от повседневного рабочего инструмента, правда?

Ну а качество поиска того же непомнюка меня просто не удовлетворили. Несмотря на всю его восхитительную архитектуру. И жрёт вся эта индексация дохренища моих не самых слабых процов. А мне иногда и рабочие проекты компилять надо...

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

ПыСы: баги, есичо, в KDE'шной багзилле.

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

По чём я знаю почему он включён по-умолчанию я не знаю. Но раз вы знаете, что индексирует гиговые mkv файлы и знаете, что это вам не нужно, то почему вы не настроите?

а им пользуется не 3,5 человека...

Индексация файлов(strigi) ставит на колени Core i5 2500K (компьютер жил своей жизнью в течении 30 минут, сделать было ничего нельзя, только наблюдать).
Хоть как-то работающие бекэнды для akonadi это mysql и postgresql. Теперь расскажите пользователю нетбука, зачем ему ставить что-то, что жрет процессор, 200 мегов оперативки и занимает кучу места на 64Гиговом SSD, лишь для того, чтобы он смог проверить почту через kmail? А еще расскажите ему, как при установке системы ему надо руками создавать пользователя в базе для себя и таблицы для работы akonadi.
Если сравнивать с thunderbird, то он даже меньше ресурсов жрет, чем kmail+akonadi+mysql.
Человек, который до этого додумался, по всей видимости, был душевнобольным. Да даже в OS X себе такого не позволяют.
Я тоже завидую гентушникам, которые могут выпилить все эти akonadi, strigi, nepomuk и сделать систему вменяемой, без всего этого хлама.

где плюшки для поиска не мешают нормально работать.

Чем они мешают работать?

Итак: 1. Akonadi Иногда после обновлений в официальной OpenSuSE оно не запускается, надо искать рецепты в сети. Из-за этого не работает почта KMail, хотя (мегалол!) KMail успешно забирает почту и даже рисует сколько непрочитанных, только показать её не может.

Диагностика проблем в этом всём виртуозно-сопраново-непомукнотом хламе вообще нулевая. Сначала надо остановить какие то недозапущенные процессы, название которых нигде не описано, потом нелепые akonadictl в консоли и долгий скроллинг в консоли с высматриванием в многостраничных логах единственного сообщения об ошибке, причем сообщения в заведомо неизвестном формате, а GUI диагностика с галочками бесполезная в принципе.

Те же X-ы в своем логе ошибки и предупреждения обозначают (EE) и (WW) соответственно, а ошибки отдельного демона в syslog можно найти по его названию (grep sshd). В Akonadi же надо смотреть глазами длинные простыни какого то бреда про то, что что то успешно запустилось, открыло какую то базу, запустило какой то субдемон, и.т.д., и.т.п. Unix подразумевает отсутствие записей в журнале об успешном выполнении команд, они просто выполняются молча. Демоны - да, могут написать одну запись о запуске, но не простыню про всю историю запуска, в которой непосвященный ничего не поймет.

2. Nepomuk В последних двух обновлениях OpenSuSE вылетает Nepomuk по segfault, после этого не запускается штатная KDE-вая смотрелка картинок Gwenview. Gwenview - это простая смотрелка картинок с возможностью просмотра тэгов EXIF и увеличения/уменьшения, больше она ничего не умеет без плагинов. Ну и в каком месте ей обязательно индексация от Nepomuk нужна и почему она не может показать ни одной картинки после сбоя Nepomuk? Пусть бы без нее запустилась и предупредила, что какие то функции будут недоступны или будут работать медленно, так нет, висит и в консоли только ругань про то, что в DBus-е не нашли Nepomuk.

3. Virtuoso Это приложение периодически доводить компьютер до воя всех кулеров, т.к. какой то virtuoso-t жрет весь проц. После убиения отваливается Nepomuk, после перезагрузки все работает.

Ну вот и зачем мне все вышеперечисленное в «стабильных» версиях KDE?

Я уже молчу про то, что всё это требует кучи процессов. Akonadi - 4 процесса (демон, какой то лаунчер, MySQL и что то еще), Nepomuk примерно также (демон, какой то промежуточный и virtuoso).

Итог: то почта, то Gwenview не работает. Кстати, когда не работал Gwenview не работало и все остальное, что так или иначе требует показа директорий, даже диалог открытия/сохранения файла.

Но кажется разработчики KDE не оставили ни одного шанса на такое выпиливание. Официальный ответ - используйте старые версии KDE.

Вы врете прямо как политик.

Я не вру, это вы говорите, как политик, наслушавшийся советников: https://bugs.kde.org/show_bug.cgi?id=285729

Это чужь потому как снятием галочек с помощью мышки все это отключается.

Ой, научите как нажатием галочки выпилить Akonadi из последней версии KDE, чтобы при этом работал KMail и была хоть какая то адресная книга с ним? А еще хорошо бы выкинуть Nepomuk и заиметь старый добрый долгий поиск по письмам (сейчас ищет только по заголовкам при вырубленном Nepomuk).

Akonadi это сервер занимающийся синхронизацией почты/календаря и т.п. Смысла его выпилывать вообще то нет, если Вы хотите использовать kmail (хотя делается это галочкой <сарказм>очень сложно, прям официальные источныки говорят, галочку не снимайте, лучше переходити на другие DE/Старые версии</сарказм>). Akonadi на самом деле уменшает сумарное потребление ресурсов, если Вам нужно что-бы информация о приходе писем/или о необходимости выполнения задачи из Goolge календаря приходила Вам на рабочий стол, так как в памяти не весит весь клиент, а только его часть отвечающая за проверку писем, и например маленький плазмоет с одной функцией показать, что пришло письмо. Назван Akonadi сервером, потому как если из другого приложения будет отправлено письмо, оно сразу же появится среди отправленных например в kmail. Потребление ресурсов сервером Akonadi довольно не значительно, но если Вы снимети соответсвующию галочку для экономии нескольки Мб оперативной памяти, то Akonadi запустится автоматом вместе с kmail2, ну будет у нас запущенно два процесса вместо одного, но потребление памяти будет почти таким же как и в старом kmail, просто часть функций kmail перенесена в другое место. Собственно сами GUI отделены, от синхронизации. Вы можете закрыть kmail, о большое письмо отправится в фоне. Вот не знаю, умеет ли Akonadi автоматом останавливатся, если он никем не используется, если не ошибаюсь умеет. У меня он весит в фоне все время, кушает пару Мб, но информация что пришло письмо появляется в системном трее. Thunderbird такое тоже умее, но весит около 100 Мб, фольза от Akonadi очевидна.

Спасибо, объяснения правда подробные. Про поисковики (Nepomuk, Strigi, Soprano, Virtuoso) - вам не кажется перебором наличие такого количества слоев абстракций? Мне кажется, что даже ну очень жирные объектно-ориентированные массовые программы такого не имеют.

Akonadi хочет MySQL, итого два процесса. Причем СУБД почему то надо обязательно отдельную запускать, системную никак нельзя использовать. И потом, вот вы сами посчитайте, что больше памяти ест: новый Kmail+Akonadi+MySQL или старый добрый Kmail, который дружил с KAddressBook? У меня почта все время в трее сидит, а скорость Internet канала позволяет скачать/отправить письмо любого разумного размера (до 15Мб фотки слал). Кроме того, если так нужна память, то можно выйти из Kmail, а потом его запустить и он запустится быстрее, чем новая связка с Akonadi и MySQL.