LINUX.ORG.RU

Soprano 2.8.0

 , , , soprano


0

2

Вышла новая версия программного продукта для хранения и синтаксического анализа метаданных (RDF) в Qt — Soprano 2.8.0. Она будет использоваться в KDE 4.9 и содержит следующие изменения:

  • исправлен запрос NRLModel;
  • поддержка чистых SQL запросов для Virtuoso (необходимы исправления в Nepomuk);
  • добавлен новый флаг запроса QueryLanguageSparqlNoInference;
  • преобразование значений Virtuoso IRI_ID в символьные строки;
  • новая опция «noStatementSignals» для Virtuoso запрещает Model::statementsAdded();
  • исправлена передача данных через локальные сокеты при использовании архитектуры клиент-сервер.

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: maxcom (всего исправлений: 4)

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

leg0las ★★★★★
()

Ненужно

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

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

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

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

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

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

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

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

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

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

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

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

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

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

bsdfun ★★★★★
()

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

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

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

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

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

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

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

dinn ★★★★★
() автор топика

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

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

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

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

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

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

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

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

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

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

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

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

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

Bye-bye.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Но кажется разработчики 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. Респект мне за детальные пояснения, это для Вас :)

anonymous
()

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

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

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

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

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

dinn ★★★★★
() автор топика

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

pekmop1024 ★★★★★
()

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Итак: 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 не работало и все остальное, что так или иначе требует показа директорий, даже диалог открытия/сохранения файла.

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

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

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

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

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

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

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

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.

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