LINUX.ORG.RU
ФорумTalks

KDE4: праведное негодование. Кому не безразлична судьба проекта - прочтите, пожалуйста.


0

0

//К чему этот длинный топик - читайте в конце.

После долгого использования KDE сначала хочется поблагодарить человеков, участвующих в создании такого большого проекта и прилагающих немалые усилия для его развития. Всё-таки их детище KDE3 было потрясающее, и, надеюсь, у него появится достойный преемник. Именно появится, потому что, как бы мне не нравился проект KDE4 с его довольно интересными находками, всё же он в развитии ушёл не в ту степь. Для кого в первую очередь разрабатывается DE? Надеюсь, для пользователей. Постараюсь выразить своё недовольство некоторыми моментами с точки зрения обычного пользователя.

1. Первое и самое главное - тупые зависимости (может кто-то обрадует, что это всего лишь вина мейнтейнеров Debian?)

* Я хочу установить лишь KWin, KDM, Plasma и, соответственно, KDELibs. Возникает пару насущных вопросов: зачем мне в обязательном порядке ksysguard, и страшно сказать, Akonadi и MySQL?!

* Если я использую лишь KMail или KAddessbook - зачем зависимость от nepomuk, который работает с монструозным virtuoso?

* Зачем akonadi в обязательно порядке mysql, если данных совсем немного, и их кеширование в mysql будет сродни стрельбы по воробьям из ПВО?

* Также излишеством считаю зависимость от mysql-client в amarok. Да, там можно хранить коллекции в БД, но во-первых, не всем нужны коллекции, часто достаточно одного плейлиста, во-вторых, раньше SQLite вполне себе справлялась с заданием при относительно небольших размерах коллекций, а теперь внезапно перестала? В случае чего можно предусмотреть миграцию между БД, если производительность SQLite уже не удовлетворяет в связи с увеличением данных, это относительно легко.

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

В связи с увеличением обязательных зависимостей сама DE и сопутствующие проекты становится тяжелыми и прожорливыми, что заставляет отказываться от них на устройствах с ограниченными ресурсами (офисные компьютеры, терминалы, недостаточно мощные машины относительно последних продуктов на рынке (не все следуют тенденциям моды покупать самое новое железо, разве P4/512-768 MB RAM уже не достаточно для кодинга/сёрфинга/мультимедиа/офисной работы???), ноутбуки/нетбуки). И внедрение гибкой системы зависимостей и модульности позволят настроить систему более адекватно, убрать лишнее и заставить «летать» там, где раньше она «ползала». Ведь достаточно вынести некоторые ключевые моменты в модули - и всё, можно без проблем использовать более легкое, без лишней функциональности ПО.

В дополнение к вышесказанному хочу добавить, что «ну зачем» подразумевает не «не нужно!» а «дайте возможность самому выбирать, использовать ли мне это или нет».

=====================================

В общем-то, сообщество - сила, если её направить в правильное русло. Предложение - выделить основные проблемы, создать петицию или открытое письмо, где каждый желающий сможет подписаться. Этим может заняться любой желающий или в худшем случае я (просто первый раз подобное делаю, опыта нет, как правильно всё оформлять). Учитывая, что KDE разрабатывают в большей части свободные программисты (или я слоупок?), то, на мой взгляд, шансы того, что они внемлют просьбам пользователей их же труда, довольно велики, гораздо больше, чем если бы разработкой руководила коммерческая закрытая организация.

А теперь вопросы и просьбы сообществу:

* Кто чем недоволен в KDE4 - напишите и поясните.

* В чем я неправ - поправьте.

* Ваши вопросы/предложения.

Ответ на: комментарий от stevejobs

xml в неопределенное количество раз тормознее реляционной бд. XML нужно парсить.

Сюрпрайз, sql тоже нужно парсить!

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

>в массивах, списках, хэшах

а разве это не вырожденный вариант таблицы? ;)

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

На самом деле всё просто, выше уже давали ссылку, почему для akonadi не подходит sqlite.
http://knotes.ru/2010/02/sqlite-akonadi-drama/

Именно по этому есть 3 варианта:
mysql и postgresql для тех, кому не хочется проблем и sqlite для любителей извращений.

CyberTribe ★★
()

> KDE4: праведное негодование. Кому не безразлична судьба проекта - прочтите, пожалуйста.
Не безразлична.
Прочитал.
Теперь мне безразлична судьба проекта Debian.

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

Отучи в Генту минимальную установку KDE от akonadi, akonadi от nepomuk и mysql. Если знаешь как - поделись секретом.

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

> Nepomuk глобально опционален.

akonadi требует neppomuk для корректной работы.

Akonadi нужен для PIM приложений

Однако, это не должно соответствовать обратному. Если я хочу всего лишь KMail, зачем мне akonadi, да ещё и с кешированием?

Akonadi нужен mysql. он может работать с sqlite, но значительно медленнее, в виду однопоточности работы с sqlite-овой базой.

В ряде ситуаций akonadi БД вообще не нужна по логике.

Если вас так парят лишние зависимости - используйте Gentoo

здесь и гента бессильна.

В заключение - я не говорю, что это _плохие_ плюшки, просто они должны быть опциональны.

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

В общем-то это все старая песня. В GNOME возможностей не хватает, но стабильно, а в KDE - избыток и глюкодром. Дальше мое мнение на этот счет. Open source - система с крайне слабой кооперацией разработчиков. DE - крупный проект, требующей хорошей кооперации разработчиков. Вся так называемая интеграция в большинстве случаев не стоит и гроша, а отнимает около 90% времени разработчиков. В общем, господа, забейте на эти всякие DE и пилите отдельные проекты. В конце концов это куда более UNIX way.

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

> Прикинь, как здорово было бы, если в твоём похапе можно было сделать ФИЛЬМЫ[«УЖАСЫ»] и получить то же самое, только без знаний о таблицах, ключах, типах и т.п. И эти ФИЛЬМЫ[«УЖАСЫ»] можно было бы обрабатывать стандартными похапешными конструкциями, без сочинятельств sql-запросов.

у меня Java+Oracle и соответственно Hibernate. Было бы круто, но это ведь фантастика...

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

> Сюрпрайз, sql тоже нужно парсить!

давай проведем мысленный эксперимент. Возьмем БД гигабайт на десять и выведем все ее содержимое куда-нибудь (чуть не сказал «на экран» :) Кто быстрее завершит обход - XML-парсер(выбери самый быстрый на твой взгляд) или Postgres? На каких данных XML-парсер начнет «рвать» Postgres?

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

> Да, так и есть.

Не всегда. Иногда это довольный как слон пользователь гнома ;-)

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

Разве после выхода SQLite 3.7 с поддержкой WAL ситуация не улучшилась? ИМХО, для домашней однопользовательской системы оно вполне нормально подходит.

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

ЗАЧЕМ ВСЁ ЭТО НА ДЕСКТОПЕ И МОБИЛЬНЫХ ПЛАТФОРМАХ? О_О

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

>> В общем, господа, забейте на эти всякие DE и пилите отдельные проекты. В конце концов это куда более UNIX way.

+1. Хотя надо отдать должное кдешникам - кде местами разбирается и может быть использовано в виде отдельных программ.

им осталось выкинуть общие релизы и выпускать пакеты независимо (сейчас такой только kdepim)

sergej ★★★★★
()

Плакать здесь:
коммерциализация, жестокая и беспощадная.


Модель аналог?
CDE!!! Пойдет на Пне3, но все прибито жесткими гвоздями стандартов.

Deleted
()

прокомментирую только это:

Также излишеством считаю зависимость от mysql-client в amarok. Да, там можно хранить коллекции в БД, но во-первых, не всем нужны коллекции, часто достаточно одного плейлиста, во-вторых, раньше SQLite вполне себе справлялась с заданием при относительно небольших размерах коллекций, а теперь внезапно перестала? В случае чего можно предусмотреть миграцию между БД, если производительность SQLite уже не удовлетворяет в связи с увеличением данных, это относительно легко.

Если вам не нужны коллекции, используйте дефолтный кде-шный Juk. Если вам нужны коллекции - используйте Amarok. sqlite на коллекциях больше 30 гигов начинал уже заметно подтормаживать. dixi

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

Убивать надо за конфиги в xml (превед, Гномэ!), остальное приемлемо. Постгресс вон бекапы и уплотнение делает в полностью автоматическом режиме

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

В амарок1.4 можно было выбирать БД. Почему бы не сделать такой выбор и во второй версии? В мастере для новичков сделать пункт, где поясннить, что при большой коллекции стоит поставить mysql выбрать его, иначе sqlite будет достаточно. В особо запущенных случаях сделать вопрос - «у вас музыка занимает больше 20 Гб?», при положительном ответе заюзать mysql-embedded, иначе sqlite. А знающие люди смогут сами выбрать себе бэкенд.

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

Почему никто больше не описывает всех бед в KDE? Ваши ответы будут полезны для создания весомого и обоснованного открытого письма.

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

Описание БЕД КДЕ - задача исключительно QA Team, пусть страдают.

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

К тому же в мускуле хранит свои данные скажем mythtv, если перевести большую часть софта на хранение данных в бд можно получить нехилый прирост производительности а также облегчение бекапа пользовательских настроек. Для любителей текстовых конфигов можно сделать псевдофайловую систему типа /proc

DNA_Seq ★★☆☆☆
()
Ответ на: комментарий от anonymous-kun

>Почему? Конфиги в xml - удобно и ынтерпрайзно.

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

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

>Почему бы не сделать такой выбор и во второй версии?

Там есть выбор.

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

Я как-то с Tomcat, который хранит конфиги в xml, таких проблем не почувствовал.

anonymous-kun
()

насчет пима — поддерживаю \=
а зависимости - умвн[ормально]

[koot@gdetotut ~]$ pacman -Si amarok | grep Зависит\ от
Зависит от : kdebase-runtime mysql qtscriptgenerator taglib-extras liblastfm
[koot@gdetotut ~]$ pacman -Si kdelibs | grep Зависит\ от
Зависит от : shared-mime-info hal xz enchant jasper openexr giflib strigi libxtst soprano ca-certificates xdg-utils qca polkit-qt libxss phonon shared-desktop-ontologies attica libxcursor libdbusmenu-qt hicolor-icon-theme

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

> давай проведем мысленный эксперимент. Возьмем БД гигабайт на десять и выведем все ее содержимое куда-нибудь (чуть не сказал «на экран» :) Кто быстрее завершит обход - XML-парсер(выбери самый быстрый на твой взгляд) или Postgres? На каких данных XML-парсер начнет «рвать» Postgres?

Очевидно что xml парсер будет быстрее, он будет выполнять только два действия: чтение файла, реакция на ключевые слова (SAX). В то время как postrges'у придётся сериализовать/десериализовать данные для передачи между бинарным представлением файла СУБД на диске и выводом клиенту + конкретно для postrgesql — ему ещё придётся пропускать в файле СУБД на диске не нужные для данной выборки версии записей.

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

>xml в неопределенное количество раз тормознее реляционной бд.

при малом объеме даных (плейлист) xml гораздо эффективнее

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

>бед в KDE

хм, вышеперечисленное может относится к недостаткам, но не бедам

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

Я не утверждаю что xml сложен для понимания, я утверждаю что он нечитабелен из-за обилия синтаксического мусора. Хотя кому-то подобные помойки нравятся, да. НО у меня они вызывают чисто эстетическое отторжение

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

>>тормозно

4.2


Текстовые данные обрабатываются медленнее бинарных по-определению, а в случае xml самого текста еще раз в 20 больше чем в plain text

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

>Текстовые данные обрабатываются медленнее бинарных по-определению

есть бинарный xml

в случае xml самого текста еще раз в 20 больше чем в plain text

да ладно

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

>есть бинарный xml

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

да ладно


Думаешь я xml-документов не видел? На одну полезную строчку до 20 тегов

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

>Думаешь я xml-документов не видел?

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

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

еще xml можно парсить на ходу, пока он загружается из сети

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

>в зависимости от задачи документ можно построить по-разному.

а как же унификация? Если писать кто в лес кто по-дрова то с этим великолепно справляется и plain text

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

В XML нет синтаксического мусора. То, что у гнома в реестре XML похож на гумно это проблемы того, кто это составлял, но никак не XML.

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

>Если писать кто в лес кто по-дрова

Но-но! унификация == xml schema. у каждого своя.

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

> В амарок1.4 можно было выбирать БД. Почему бы не сделать такой выбор и во второй версии?

потому что тогда придется ограничиться только тем функционалом, что совместим одновременно и с sqlite и с mysql? --К.О.

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

Если вам не нужны коллекции, используйте дефолтный кде-шный Juk. Если вам нужны коллекции - используйте Amarok. sqlite на коллекциях больше 30 гигов начинал уже заметно подтормаживать. dixi

Так это от того, что кдешный софт - говно. mpc на коллекции больше 30 гб даже не думает тормозить. И управлялка на лиспе тоже (stumpwm/contrib/mpd.lisp).

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

>В XML нет синтаксического мусора

немножко-таки есть: угловые скобки, кавычки. Но в-основном мусор вносят разработчики

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

>Так это от того, что кдешный софт - говно

Не надо обобщать

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