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

>> Он вроде понятно объяснил, что его раздражает зависимость kmail от mysql

я бы вообще все табличные данные в системе хранил в mysql. Это самый лучший, быстрый и стабильный storage.


Это ты сейчас с чем сравнивал?

пока только _одной_ программе нужен mysql - это может выглядеть странно. Но как я понял, создатели KDE тоже хотят перетащить хранение данных в нормальные БД.

нормальные БД.


нормальные БД.


нормальные БД.



При чём тут mysql?

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

> Это ты сейчас с чем сравнивал?

с файлами разными, например.

При чём тут mysql?


если сравнивать с другими SQL-серверами...

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

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

> При чём тут mysql?

выбор не велик либо sqlite либо мускул или вам нужен интерпрайз для жалкой сотни контактов?

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

Berkley DB и другие не-sql'ные базы

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

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

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

На кой на машине с одним человекопользователем сетевая РСУБД для хранения адресной книжки?

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

На кой на машине с одним человекопользователем сетевая РСУБД для хранения адресной книжки?

если _все_ приложения начнут ее использовать как основное хранилище, в т.ч. для хранения настроек, будет торт.

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

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

>да. но, внезапно, зачем для ДЕ децентрализация и сетевой доступ к базе?

Хотя бы для создания единой инфраструктуры из нескольких машин с кедами. Мускуль поднимается на выделенном сервере, юзвери радуются.

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

если _все_ приложения начнут ее использовать как основное хранилище, в т.ч. для хранения настроек, будет торт.

man трёхзвенная архитектура.

В кедах, кстати, она и есть. Только в качестве сториджа глупость используют.

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

man ldap.

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

> man трёхзвенная архитектура.

В кедах, кстати, она и есть. Только


а я о чем говорю? Вот и радуюсь, что в кедах она и есть. И что менять это не надо. Разве что БД помощнее держать.

man ldap.


и чем это противоречит mysql/postgres?

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

а я о чем говорю? Вот и радуюсь, что в кедах она и есть. И что менять это не надо.

Ну и на кой хрен в кедах мыскл?

Разве что БД помощнее держать.

Что значит «помощнее» и для чего нужно «помощнее»?

и чем это противоречит mysql/postgres?

Тем, что вы путаете frontend и backend.

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

Ну и на кой хрен в кедах мыскл?\

сам же только что говорил «аконади - глупость». Почему не мыскл?

Что значит «помощнее» и для чего нужно «помощнее»?

бОльшие объемы данных, больше функционала по обработке. Кому-то от стораджа потребуется три поля хранить для адресной книги, а кому-то понадобится немыслимый поиск навертеть. Чем круче будет изначальная база данных, тем дальше отодвинется тот момент, когда на форумах начнут вопить: «а для моего xyz возможностей sqlite не хватает, давайте впихнем сервер получше.»

Тем, что вы путаете frontend и backend.

где именно, цитатко? давай по MVC - все данные в бд (скажем постгрес), вся логика в либах или серверах, представление - гуи на соответствующих тулкитах или там в командной строке. Например, есть адресная книжка, у нее гуй на куте, логика - сервер addressbookd, данные хранятся в мускуле. Если мне надо получить данные моей домашней адресной книжки с работы, я могу просто по сети соединиться с ломашним мускулем и работать напрямую с ним. А могу соединиться и скопировать данные на локальный мускуль и работать уже с локальным.

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

сам же только что говорил «аконади - глупость». Почему не мыскл?

Потому что мыскл для такой задачи - из «Тунгуски» по комарам.

бОльшие объемы данных,

Сколько терабайт занимает твоя адресная книга? Или хотя бы гигабайт?

больше функционала по обработке.

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

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

Хорошее, годное предложение. Но при чём здесь sql?

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

В общем, я очень-очень солидарен с идеями Chrome OS, и не знаю как лучше выразить мысль кроме как дать ссылку на ChromeOS =)

Потому что мыскл для такой задачи - из «Тунгуски» по комара

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

Но при чём здесь sql?

ок, тогда причем здесь BDB/sqlite? Их вообще централизовывать ХЗ как. И дыхоты с помощью ормов писать еще больше.

какие вообще сейчас есть хорошие no-sql базы данных?

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

>А вот как захотят люди хранить в БД всякую музыку да двдрипы, да обрабатывать данные хранимыми процедурами с кучей под десять гигабайт?

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

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

>А вот как захотят люди хранить в БД всякую музыку да двдрипы

… так сразу и расстреливать.

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

Пока задача всего одна, адресная книга, можно и в файлике хранить.

Ты действительно не понимаешь, чем фронтенд от бэкенда отличается?

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

Не захотят. БД для музыки с двдрипами называется файловая система. Хранимые процедуры называются программами.

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

Для хранения фильмов уже есть одна стандартная БД — файловая система.

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

>почему?

потому что это не лечится //К.О.

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

ок, тогда причем здесь BDB/sqlite?

Тем, что это не сетевые РСУБД. Для хранения данных на локальной системе сетевой РСУБД не нужно.

Их вообще централизовывать ХЗ как.

Что централизовать? Персональную адресную книгу? Персональный плейлист?

В любом случае, РСУБД не предназачены для выполнения задач за пределами, собственно, РСУБД. Они используются в качестве хранилища данных, а вся высокоуровневая логика делается отдельно (привет, Аконади!). Вся кдешная хренотень, которой нужно что-то там хранить, работает с хранилищем через промежуточное звено. И это не мыскл.

И дыхоты с помощью ормов писать еще больше.

Иди, попиши ещё сайтов.

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

>Что централизовать? Персональную адресную книгу? Персональный плейлист?

имхо, такие данные проще пересылать по сети в виде xml, чем в виде бэкапов базы

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

> ты действительно не понимаешь, чем фронтенд от бэкенда отличается?

пока ты не объяснишь что ты имеешь в виду под этим вопросом, я не могу ответить. Можешь переформулировать?

Не захотят. БД для музыки с двдрипами называется файловая система. Хранимые процедуры называются программами.


да пофиг как оно там реализовано на совсем-совсем нижнем уровне. Хоть на паровых машинах. Главное, чтобы был интерфейс для удобного и единообразного использования этих ресурсов. Я хочу написать в программе «дай мне все фильмы из таблицы Фильмы и отфильтруй по ключу жанр, на выход хочу массив объектов типа DVDRip». А как уж он будет этот приказ исполнять - дело конкретной реализации БД.

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

> имхо, такие данные проще пересылать по сети в виде xml,

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

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

т.е. на Gnome за виндовый реестр бочку катить прекратили, завели его в KDE?

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

пока ты не объяснишь что ты имеешь в виду под этим вопросом, я не могу ответить. Можешь переформулировать?

Бэкенд - непосредственно хранилище, в котором лежат данные. Фронтенд - движок, умеющий эти данные в хранилище ложить и извлекать обратно.

У фронтенда sql проблема в том, что он заточен на табличную организацию данных. А в реальной программе данные хранятся в массивах, списках, хэшах, деревьях. Соответственно, если в этой самой реальной программе использовать sql, то невольно придётся логику работы закручивать около неродного представления данных.

Задачка для затравки: есть список с объектами произвольного типа. Нужно сохранить список во внешнем хранилизе и потом его считать. Сколько геморра появится при использовании sql, представляешь?

Я хочу написать в программе «дай мне все фильмы из таблицы Фильмы и отфильтруй по ключу жанр, на выход хочу массив объектов типа DVDRip».

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

я говорю про Единый Реестр Всея ОС. Там по определению не будет мало данных.

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

я говорю про Единый Реестр Всея ОС. Там по определению не будет мало данных.

Вы про /etc?

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