KDE 4.6.0 Beta 1 (diskuse)

[Jardík]

Takže už můžu vyhodil HAL a používat v KDE automount? Dodnes jsem kvůli tomu musel spouštět pcmanfm, protože KDE bez spuštěného HALu ani nedokázal ukázat seznam mechanik.

[Jardík]

BTW znamená to, že i v k3b bude fungovat bez HALu, nebo to si to řeší po svém?

[marvn]

nevim jestli k3b pouziva solid, ale predpokladam ze jo...takze jo

ja jsem zkousel jenom udisks a v delfinu pak mountovani funguje. akorat kdyz ma clovek jeste k tomu zaply hal, tak tam vidi kazdy zarizeni 2x, takze jsem udisks zas vyhodil a zatim zustavam u halu

jinak zatimco hal (aspon na archu) mountuje do /media/disk-$n, tak udisks mountuji do /media/$uuid

[Michal Kubeček]

Když je to bez HALu takové terno, jde nějak snadno zařídit, aby se mi konkrétní disk mountoval na mnou zvolený mounting point a pokud možno s mnou zvolenými mount options? S HALem to šlo…

[Jardík]

Udisks dává jen notifikaci o vložení a umožňuje médium připojit na žádost klienta (např. správce souborů). Volby připojení předává klient (takže ano, ty nastavit jdou, pokud to umožňuje změnit klient). Výstupním parametrem je cesta, kam se připojilo, takže jestli jde změnit ta, nevím.

[Michal Kubeček]

Kámen úrazu je v tom, že dokud se to řešilo pomocí HAL, bylo možné pomocí jeho definičních souborů oboje ovlivnit. Současná implementace je sice strašně super v tom, že nepoužívá HAL (i když pořád nechápu, co je na tom vlastně tak strašně super), ale ať se snažím, jak se snažím, pořád nemůžu najít žádnou použitelnou dokumentaci, kde by bylo popsáno, jak ovlivnit mounting point (pojmenování mounting pointu podle labelu sice asi někomu z vývojářů připadalo jako super nápad, ale mně to neskutečně leze na nervy) nebo mount options (automatické mountování se sync resp. flush je sice bezpečnější, ale dost to zpomaluje zápis). A bohužel ani na fórech k tomu nenacházím o nic víc.

[Jardík]

Na udisks není nic dobrého, HAL mi připadal v mnoha případech lepší (např. informování o stisku eject tlačítka na mechanice), udisks je někde horší (o eject tlačítku neinformuje a místo toho narvali do kernelu fíčuru, že se mechanika při mountu nezamkne, aby se mohla dát vysunout a násilně se odpojí (což v případě DVD-RAM může mít kritický dopad na filesystém)), ale jakmile nastala situace, že půlka aplikací používá HAL, druhá různé u-věci, tak je problém, že se to vzájemně mlátí a podle mě to není dobré a něco se s tím udělat muselo. Hold to vyhrál udisks. Bohužel teď je tu další věc, pokud KDE potřebuje udisk, má nepřímou závislost na glib a je dementní, že když už tu glib mít musíte, tak si KDE svoje věci řeší přes Qt, takže máte opět 2 stejné věci v systému zbytečně. A díky čemu? Díky mizernému API linuxového kernelu, který se o mechaniky není schopen postarat sám. Proč to alespoň nenarvali přímo do udevu?

[Laco]

Pocitam ze niekde okolo Kubuntu 12.04 LTS by mohlo byt KDE vo verzii 4.8.2 uz celkom vymakane. Ale to je este daleko a vtedy bude na spadnutie aj Windows 8...

[Honz]

A proč zrovna Osmička? Uindouz jsou přece na spadnutí od začátku...

[Laco]

Ano pada, ale iba pri HW problemoch. V linuxe pada furt volaco..

[Jarda]

No jasně je to v HW. Koukni se po Linux ready HW a nebude ti to padat ani v linuxu. Hlavně nezapomeň vyměnit Vista ready monitor, to bývá největší kámen úrazu.

[sparrowhawk]

+111

o tom monitoru, to bych mohl povidat. v praci mame ERP system, ve kterem se po maximalizaci okna ztratilo levych nekolik pixelu. cimz ovsem mizely i nektere dulezite informace a bohuzel se s tim nedalo nic udelat, jedine nemaximalizovat. a na noteboocich to bylo jeste horsi

[sparrowhawk]

tak to byla kravina

[Marián Kyral]

Tak jsem nové KDE nainstaloval a musím říct, že na první pohled žádná změna, od 4.5 nelze rozeznat. Na druhý pohled potěší menší vytěžování cpu, což se projeví na teplotě cpu v klidu. Ta je teď o cca 4° nižší. Uvidím, jestli se to nějak projeví na výdrži běhu na baterie.