KLyDE: minimalistická konfigurace KDE (diskuse)

[Kaacz]

Hmm .. některé (dle mne zbytečné) činnosti nechápu. Když potřebuji štíhlejší desktop, tak holt použiju nějaký jiný. Tohle je jak vzít baworáka a očesat ho na pažout206 .. :) Ale když má času nazbyt, tak ať si hraje ..

[Michal Kubeček]

Já to naopak považuji za jeden z nejsmysluplnějších letošních projektů. Jsou uživatelé (třeba já), kterým na jedné straně vyhovují základní komponenty a aplikace KDE jak z hlediska ovládání, tak po vizuální stránce, ale na druhé nestojí o nenasytné a překážející hračky typu sémantický (nebo dokonce sociální) desktop, Nepomuk, Strigi, Akonadi, …

Jen mne trochu znepokojily ty plány zadrátovat do toho ještě víc závislosti na systemd - ale snad se bude držet požadavku modularity, který si stanovil na začátku, a půjde to i bez něj.

[xkucf03]

Mně se naopak sémantický desktop líbí a fandím tomu. Jen mi vadí výchozí nastavení – ono totiž když se během kompilace jádra začnou indexovat právě vytvářené soubory, tak je to dost pakárna. Obecně mám spousty souborů, které si indexaci nezaslouží. Uvítal bych, kdyby se indexovaly jen třeba dokumenty, hudba a fotky a ostatní složky si uživatel přidal podle potřeby sám – tzn. neindexoval by se celý domovský adresář.

[Jarda]

To samozřejmě jde. Jednak určit které adresáře ano a které ne, stejně tak lze určit které typy souborů se indexovat budou a které ne. Nastavení systému --> Vyhledávací služby --> karta Indexování --> tlačítko Pokročilé (výběr typů souborů) a Uzpůsobit složky (výběr složek).

[xkucf03]

Já vím, že to jde, ale píšu, že mi vadí to výchozí nastavení.

[Vladimír Čunát]

To je ale otázka na distribuci, ne na DE. A popravdě, mě osobně výchozí nastavení zajímá jen jednou, pak už prostě používám to svoje

[kavol]

To je ale otázka na distribuci, ne na DE.

a takhle na hlavičku jsi neupad?

výchozí nastavení určuje autor, pokud jej kdokoli další, tedy i distributor, změní, tak už jaksi není "výchozí"

[mrv]

a jak bys toho chtel dosahnout? ptze me nenapada zadny zpusob, jak dopredu vedet, kde budes kompilovat jadro...

[Kaacz]

No tak pokud jde pouze o to co píšete .. že to sedí na disku je dnes nezajímavé. A vše jsem prostě vypnul, takže to neběží. To si může udělat každý a nemusí používat extra repos.

Z popisu jsem počítal s hlubší očistou .. :)

[Fluttershy, yay!]

Když potřebuji štíhlejší desktop, tak holt použiju nějaký jiný.

To je asi tak retardovaný přístup, jako když tady někdo nedávno prohlásil, že webové prohlížeče můžou používat libovolné vykreslovací jádro, pokud to bude WebKit.

[Bedňa]

Jéj :D Nebol by na to link?

[Fluttershy, yay!]

Hledej, šmudlo, hledej. Četl jsem to v autobuse na telefonu, takže odkaz při ruce nemám a pamatuju si to jen matně. Ačkoliv je možné, že to bylo na jiném fóru. Určitě to bylo v kontextu toho, jak se podle některých WebKit stává novým MSIE6.

[Bedňa]

Hľadať hocičo v kontexte s WebKit je problematické, ale rozhodne pobavilo.

[Prcek]

Myslím, že dost podobnou práci už udělal Tomáš Matějíček na Slaxu. Možná by to ti dva mohli dát dohromady a spojit síly.

[dumblob]

+1

Take me to hned po precteni titulku napadlo.

[Bedňa]

+1

[Pali]

Nech vyhodi srackonadi, to vyriesi vela problemov s tym ze CPU ide vkuse na 100% alebo, ze aplikacie co pouzivaju srackonadi prestanu fungovat.

[mrv]

tvy problemy vyresi pouze navsteva lekare ;)

[Rovano]

To je opravdu velký problém jej deaktivovat....

[Fluttershy, yay!]

Upřímně řečeno, úplně jednoduché to není, resp. když jsem to zkoušel naposledy, musely se vypnout všechny služby, které ho využívají (i drobnosti jako svátky ve widgetu kalendáře), a editovat konfigurák. Ne, že bych to nějak moc řešil.

[gtz]

Tak nějak. Pokud někdo používá KDEPIM tak to vypnout moc nejde.

[Rovano]

To sice máte pravdu, ale jeho vytížení na 100% je způsobeno tím, co lze v klidu vypnout.

[Fluttershy, yay!]

Což nesouvisí s deaktivací Akonadi...

[Rovano]

Pravda

[Chytrex]

No, já si myslím že akonadi je hodně problem.. nedávno jsem instaloval na notebook wheezyho s KDE (ano vím není to nejčerstvější verze) a hodně mě štval fakt že je v závislostech i mysql server. A pokud se nepletu záviselo na něm právě akonadi.. takže s původním "ať vyhodí akonadi" souhlasím.

Tak nějak nepochopím proč není default volba sqlite... (backend na to je)

[xkucf03]

Ale on ti tam nepoběží trvale MySQL server – pouze se pustí proces pod tvým uživatelem při startu KDE. Je to podobné, jako použít knihovnu (např. sqlite).

[kavol]

nepoběží trvale .... pouze se pustí při startu KDE.

takže z hlediska času, kdy počítač využívám, je to "trvale"

Je to podobné, jako použít knihovnu (např. sqlite).

to teda sakra není, jak můžeš srovnávat prosté volání knihovny čas od času s procesem, který tam sedí furt a žere prostředky, a žere jich čím dál víc?

[xkucf03]

jak můžeš srovnávat prosté volání knihovny čas od času s procesem, který tam sedí furt

A skutečně se ta knihovna používá, jen když je potřeba? Nebo se spíš zavolá v rámci jiného procesu funkce pro otevření databáze a ta se drží otevřená celou dobu + se průběžně volají dotazy? Pokud by se to volalo jen podle potřeby, tak se bude pořád otvírat a zavírat soubor, kontrolovat jeho integrita, načítat do paměti… je to neefektivní – tipuji, že takhle¹ to implementované není.

Takže jde vlastně o to, zda to budou procesy dva (komunikující přes unixový soket) nebo proces jeden, který ale musí alokovat stejné prostředky. Ano, dva procesy jsou víc než jeden a komunikace přes soket má taky nějakou režii, ale přijde mi to v tomto kontextu zanedbatelné.

_{[1] možná by šlo udělat nějaký „connection pooling“ a po určité době tu databázi zavřít a otevřít zase až když je potřeba – ale stejně tak je možné v případě nevyužití odswapovat proces}

[kavol]

no, to je právě celá ta zrůdnost Akonadi, jestliže to běží furt ...

ad "pořád otvírat a zavírat soubor, kontrolovat jeho integrita, načítat do paměti" - pokud člověk zrovna nemá zabugovaný kernel, tak otevření souboru je velice levné (srovnej s režijí na otevření socketu), proč by se měla pokaždé kontrolovat integrita netuším (ostatně s integritou dat Akonadi to není nijak slavné ani s tím MySQL), a co se týče načítání do paměti, sám sis vpodstatě odpověděl s tím swapováním, přičemž AFAIK držet alokovanou paměť je o mnoho dražší než kešovat nějaká data z disku (což je zcela zásadní rozdíl v chování systému, je-li kód v paměti a jen čeká na i/o, anebo jestli to, co visí na tom i/o, je ten kód, co se má dostat do paměti)

[xkucf03]

BTW: MySQL proces na mém počítači zabírá 27 268 KiB zatímco Thunderbird 296 632 KiB, Firefox 470 732 KiB, Psi 89 936 KiB atd. Takže jeden běžící mysqld mi fakt žíly netrhá.

[chrono]

27MiB kvôli hodinám v paneli je dosť veľa.

[xkucf03]

Vtip je v tom, že to nejsou jenom hodiny… A nic nebrání tomu, mít plasmoid, který zobrazuje pouze čas a nemá další závislosti.

[gtz]

Jenže pokud má jeden plasmoid jen 25MB, co se potom bude dít, když tam budou/jsou události řekněme z dalších 2 let nazpět? Pokud člověk používá KDEPIM tak ta celá zrůdnost roste a bobtná. Nedávno jsem na 4.8.X omylem přidal starší pracovní kalendář (2007-2011) a co se stalo? Ta zrůda rostla snad geometrickou řadou a na T8100 s 4GB to celé bylo málem tuhé.

[xkucf03]

Tak to musela být nějaká chyba implementace/konfigurace – ne návrhu – MySQL přece nedrží všechna data v paměti, ale ukládá je na disk.

[gtz]

No tehdy jsem to jen zkoušel a tehdy jsem normálně udělal import z Evolutionu a mašina se z toho byla totálně štolverk. No když jsem na té stejné konfiguraci přidal druhý podobný kalendář z googlu tak se celý systém nedal používat. Bylo to na produkční verzi KDE (Suse 12.2). Nyní jsem zkoušel přidat na Suse 12.3 stejný kalendář a proběhlo to celkem rychle a v pohodě (4.10.00).

[kavol]

mno, já jsem teď zálohoval komplet ~ neb se jdu přesunout na jiný disk, vyloučil jsem blbiny jako mptrosky, které mám v kopii jinde, promazal jsem virtuální mašiny, a zbylo mi nějakých 22 GB ... což mi bylo dosti divné, neb krom jedné zůstavší virtuální mašiny o velikosti přes 12 GB jsem tam neměl nic, vpodstatě jen pár texťáků a pdf, spolu se zdrojáky qmmp, nečekal bych, že to vezme víc než gigo-dvě ... pak jsem přišel na to, že asi 8 GB má virtuoso.db, OMFG, no tak to se nedivím, že když si na to hrábne, tak mi na tom postarším stroji nestačí 4 GiB RAM a může se uswapovat ...

btw, virtuoso? - tak doprdele nemůže to aspoň to dementní akonadi využívat taky, musí mít závislost na mysql, aby projistotu byly v systému hned dvě běžící databáze a ne jen jedna?

[Chytrex]

btw, virtuoso? - tak doprdele nemůže to aspoň to dementní akonadi využívat taky, musí mít závislost na mysql, aby projistotu byly v systému hned dvě běžící databáze a ne jen jedna?

+1 a klidně naopak, když už do háje se mi cpe DB server do systému, nemůže to už aspoň používat celé KDE ten jeden?

[stativ]

btw, virtuoso? - tak doprdele nemůže to aspoň to dementní akonadi využívat taky, musí mít závislost na mysql, aby projistotu byly v systému hned dvě běžící databáze a ne jen jedna?

Až na to, že virtuoso je RDF databáze, kdežto mysql je relační. Ne, že by nešlo virtuoso použít jako relační databázi, ale vypadá to jako docela pěkný voser. Nehledě na to, že SQL zná kde kdo, kdežto RDF moc lidí nezná.

[kavol]

Až na to, že virtuoso je RDF databáze, kdežto mysql je relační. Ne, že by nešlo virtuoso použít jako relační databázi, ale vypadá to jako docela pěkný voser.

ehm, nevím, proč bych na této úrovni abstrakce (= výsledek pro uživatele) měl řešit jestli RDF převádět na relační či naopak - tady mě zajímá tak nanejvýše to, že Nepomuk ukládá podobná data jako Akonadi, čili když může pro Nepomuk fungovat RDF, tak může fungovat i pro Akonadi, et vice versa, když pro Akonadi funguje relační, tak může fungovat i pro Nepomuk ... tj. neřeším převod z jednoho na druhé, nýbrž už od základu použití buď jednoho nebo druhého

Nehledě na to, že SQL zná kde kdo, kdežto RDF moc lidí nezná.

a?

- doprdele tak si měli líp rozmyslet, do čeho těch 17 M€ vrazí ...

[Bedňa]

Prepáč, ale už samotné spustenie MySQL v kontexte používania desktopu znie dosť hrozivo Poznám lepšie riešenia, len niesu moc populárne.

[Fluttershy, yay!]

Poznám lepšie riešenia, len niesu moc populárne.

Židi do plynu?

[Bedňa]

S tým by som si dovolil nesúhlasiť, bolo to zle indexované. ďaleko lepšie sa to dá riešiť pomocou ReiserFS, ale autor zabil manželku, tak neviem čo je lepšie.

[JoHnY2]

Neni to zadna knihovna. Normalne se pousti mysqld proces se spesl konfiguraci. Dokonce tedka koukam, ze se snad pousti separatni instance mysqld pro kazdyho usera co pusti KDE. Spolecnou databazi si clovek musi nakonfigurovat sam.

SQLite se nehodi, protoze Akonadi generuje hodne soubeznejch pristupu do databaze.

[pavlix]

Nechci mluvit konkrétně k MySQL. Ani ke konkrétním argumentům, které mi přišly kolikrát dost mimo, i když se dotyční snažili doargumentovat ke stejnému výsledku jako já :)…

Nechápu, proč všichni tak strašně démonizují :) běžící démony. Režie spojená s dlouhodobým během procesu je naprosto minimální. Kernel je připravený udržovat procesy, které čekají pomocí poll() a příbuzných. V rámci běžného stroje, ať už desktopu nebo serveru nepředstavuje démon ani promili jakéhokoli typu zátěže.

Tudíž veškerá zátěž a neefektivita je dána tím, jak je ten démon napsaný, popřípadě jak je ta knihovna napsaná. Chápu, že je jednodušší udržet paměť na uzdě s krátkodobě spuštěným kódem než z dlouhodobě spuštěným kódem. Jenže v případě dlouho běžících desktopových aplikací je dlouhodobě spuštěný jak kód démona, tak i kód knihovny.

Technická rozhodnutí by se měla řídit především technickými důvody, ne nějakým abstraktním náboženstvím a vyháněním démonů ze systému ;).

[xkucf03]

+1 (tohle jsem se snažil říct, když jsem psal, že je jedno, jestli je to knihovna nebo démon)

[pavlix]

SQLite se nehodi, protoze Akonadi generuje hodne soubeznejch pristupu do databaze.

To věřím. Otázka je, jestli se z toho dá vyvodit, že je nevhodné SQLite nebo že je nevhodné Akonadi.

[xkucf03]

Vhodně poskládat souběžně přicházející požadavky je úloha DBMS.

[pavlix]

Prázdná věta. Pokud ji budeš brát jako zákon, tak tě to často donutí zvolit horší řešení.

[Josef Kufner]

Kdysi dávno jsem řešil, jak udělat pořádně PIM, aby to vypadalo k světu a bylo to použitelné. Když jsem o pár měsíců později viděl první představení Akonadi, byl jsem překvapen, jak podobné si ty obrázky byly. Rozhodně to byl krok správným směrem.

Potíž je, že vývoj jde docela pomalu a celé KDE PIM potřebuje ještě opravdu hodně dozrát. A než dozraje, moc použitelné to nebude.

[B.E.]

chlapi maj pravdu: KDE je opravdu nenasytnej RAMkosaurus obkliceny zbytecnymi daemony, ktere se nedaji ani normalne vypnout. Na klasickem HDD se snad neda ani pouzit - nabehem totiz pripominaji Windows.

PowerOn - postavit na kafe - prihlaseni v KDM - jit ho zalejt.

Po 5ti letech jsem presel na SSD a Lubuntu - mel jsem to udelat driv. Ted zas pro zmenu nestiham to kafe ani zapnout.

Takze KLyDE je pro me zajimava nabidka.

[xkucf03]

Mám KDE minimálně na jednom¹ počítači s točivým diskem a nemůžu si stěžovat. S Windows se to nedá srovnávat – když je občas u někoho vidím nabíhat, tak je mi těch lidí fakt líto. A není úplně fér srovnávat Lubuntu na SSD s KDE na HDD.

_{[1] na druhém mám hybrid a na třetím SSD}

[kuba77]

Taky mi KDE přijde pomalé, mám Chakru s KDE 4.10.2 na HDD a po koupi SSD jsem ten systém překopíroval na SSD a je samozřejmě rychlejší než na HDD ale pořád to není úplně ono, hlavně rychlost spuštění systému a start některých programů, třeba Dolphin. Možná to je trochu tím, že je to SSD omezené mojí základní deskou se SATA 3 Gb/s, takže se jeho rychlost nevyužívá naplno. Začal jsem používat Razor qt s KWin místo KDE a hned je nabíhání systému rychlejší.

[Rovano]

CO je pomalé spouštění Dolphinu? U mě se spustí do 1vteřiny.

[kuba77]

U mě tak 3-5 vteřin.

[Rovano]

Takhle dlouho se mi spouští jedině, když chce roztočit médium v mechanice.

[B.E.]

A není úplně fér srovnávat Lubuntu na SSD s KDE na HDD.

Omlouvám se, myslel jsem to tak, jak už někdo podemnou reagoval... Nepomohlo ani SSD, takže bylo na čase udělat KDE pápá...

[Fluttershy, yay!]

Takže ses zbavil návyku na kafe?

[B.E.]

Nemám návyk (jenom mi vadí, když mi v těle začne kolovat krev místo ...)