Ezen a héten történt a KDE táján (2009. február 8.)

KDE

Az Amarok 2 kezd felnőni az Amarok 1.4 képességeihez; el is készült egy lejátszólista kinézet szerkesztő, illetve nagyon sok dolgot fejlesztettek rajta. A Phonon C# kötést kapott. A KDevelop 4.0-ra egy működő hibakeresőt szeretnének összerakni. A kio_svn írási támogatást kapott (így lehetőség van a „kate svn+ssh://user@host/home/user/myrepos/myfile.txt” parancs kiadására és mentéskor automatikusan beküldi a változtatásokat).

A Kamala Kross szkriptelési lehetőséggel és Postgres támogatással gyarapodott. A Marble néhány része már képes kezelni a D-Bus hívásokat. A KHotKeyst és a LionMailt is javították. A Translatoid plasmoid beszédfelolvasóval bővült, illetve megjelent egy új kisalkalmazás is: a Fortunoid (szerencsesütis idézetekkel kápráztat el minket). A Sonnet és a KWin is fejlődött. A NEPOMUK Virtuoso backendet kap. SVG támogatás érkezik a Karbonba. Tovább folytatják a KControl és a Konversation KDE 4-re való áttételét. Újdonságként érkezik a „Peg-E” játék, egy Google adatokat kezelő Akonadi erőforrás, az SLP KIO-szolga és a Filelight KDE 4-es verziója, illetve a plasma2jolie. A Nuvola ikonkészlet most már nem a kdeartworkben található, mivel nem karbantartott státuszt kapott.

Gyorsan tekintsük át, hogy melyik program mire is jó:

  • Kamala: l. a korábbi cikket;
  • Kross: a KDE 4 alapértelmezett szkripmotorja. Támogatja a Python, Ruby, JavaScript és Falcon nyelveket;
  • Marble: a KDE 4 térképszoftvere, egyre bővülő tudással;
  • Sonnet: l. a korábbi cikket;
  • Virtuoso: egy nagy teljesítményű objektum-relációs SQL/RDF adatbázis, tranzakciókezeléssel, tárolt eljárások-, illetve Java és .Net szervertámogatással, hot backuppal és SQL 99 megfelelőséggel; ODBC, JDBC, ADO.net és OLE/DB eléréssel;
  • Karbon: a KOffice részeként egy vektorgrafikus rajzoló szoftver;
  • KControl: a KDE 3 vezérlőpultjaként ismerhette meg a nagyérdemű;
  • Filelight: grafikus lemezterület analizátor, ami tortadiagramként mutatja a különböző mappákat.

Michael Pyne mesél egy nemrégi lehetséges KDE-s biztonsági hibáról, és az ellene tett lépésekről:

Először is, mielőtt elmondanám, hogyan javítom a hibákat, be kell határolnunk a problémát.

Nemrég, egy magát „foobar”-nak nevezett blogger egy cikket publikált, „hogyan írjunk vírust Linuxra 5 könnyű lépésben” (HUP hír róla), amiben a .desktop fájlok kezelésében rejlő hibákat használja ki. Ezeket a fájlokat a KDE, GNOME és egyéb olyan környezetek használják, amik megfelelnek a freedesktop.org megfelelő (ún. Desktop Entry) specifikációjának. Sokféle feladatot el tudnak látni ezek a fájlok, mint például alkalmazásindítás, KDE-s internetprotokoll kezelés, asztali és tálcaikonok megjelenítése, sőt még pluginok is lehetnek. Más fájlokkal kapcsolatban mutatnak információkat. Például a KDE-s végrehajtható fájlok nem tartalmaznak beágyazott ikonokat, így ezeket a megfelelő .desktop fájlokból olvassa ki.

Sok dologra használják őket, de egyre különösen gyakran: alkalmazásindításra. De mi történik, ha egy ismert ikont beállítva egy veszélyes programot indít el valaki és eközben egy játéknak adja ki magát? Véletlenül elindítanád? Egy kezdő Linux felhasználó véletlenül elindítaná?

A POSIX rendszereken a hagyományos védelem ez ellen a „végrehajtható” bit beállítása a futtatás előtt. A .desktop fájlok sosem használták ezt a védelmet és az asztali környezetek, többek között a KDE és a GNOME sem kényszerítette ezen szabály betartatását. Tulajdonképpen erről még 2006-ban is esett szó a közös listán, de nem történ semmi azóta. Most úgy éreztem, ideje ezen változtatni.

Az ötlet az, hogy hozzuk fel a .desktop fájlok biztonságát a POSIX végrehajthatók szintjére.
Persze ez sem véd meg minket az önjelölt kamikazéktól, akik hűen követik a „hogyan törjük fel saját gépünket 5 perc alatt” leírást, mint ahogyan a végrehajtható bitek sem védenek az ártalmas Perl vagy Python scriptek ellen.

Sok területen akadt munkám:

  1. Meg kell követelni, hogy a .desktop fájlok végrehajthatóak legyenek programindítás előtt;
  2. A KDE „új link készítése” funkció javítása ennek megfelelően;
  3. Ötletek felvetése, hogy a jelenlegi KDE felhasználók biztonságosan frissíthessenek;
  4. Ötletek felvetése, hogy a jelenlegi fájlokat hogyan javítsuk.

Az első és a második elég könnyű volt. A nehezebb része annak kitalálása volt, hogyan oldjuk meg a biztonságot, hogy működőképesek maradjanak a jelenlegi rendszerek is. Az eredmény az lett, hogy sok kivételt adtunk hozzá a védelemhez:

  • ha a tulajdonos a root, akkor engedélyezzük a végrehajtást. Ez lefedi a legtöbb asztali környezet fájlját (mivel egy KDE a /usr-be települ), és egy mezei felhasználó nem képes írni az /usr-be rendszergazdaként (emlékezz, mi csak a „kattintgatós” mókát próbáljuk kivédeni).
  • ha a .desktop fájl az alapértelmezett KDE helyre települ, engedélyezünk. Ez ahhoz szükséges, hogy a felhasználók a KDE-t a saját könyvtárukba telepíthessék rendszergazdai jogosultságok nélkül. Ez azért megengedhető, mert bár el lehet magyarázni valakinek, hogy menjen ide meg ide és mentse el a fájlt, a ~/-ban KDE-t futtatók közül azért a legtöbben már talpraesettebbek. Azok, akik nem a saját KDE-jüket futtatják, nem képesek a telepítési könyvtárba menteni plusz műveletek nélkül.

    • [/]
    Az „alapértelmezett KDE hely” egy finomhangoltabb kivétel volt, ami védte az alapértelmezett KDE-s alkalmazásokat és szolgáltatáskönyvtárakat és ezen felül az XDG [X Desktop Group, a freedesktop.org korábbi neve] alkalmazástárolót is. A kezdeti megvalósítás viszont kihagyott egy kivételt, ami szükséges az automatikusan induló szolgáltatásokhoz, így a második kivételt kiterjesztettük a KDE-hez telepített .desktop fájlokara is.

    Viszont még mindig ott a probléma, hogy mi legyen a már létrehozott saját indítókkal. A biztonság engedélyezése után nincs egyértelmű megoldás arra, hogy megkülönböztessük a felhasználó által létrehozott gyorsindítókat a letöltött trójaiaktól. Ezért úgy döntöttünk, hogy beviszünk a rendszerbe egy olyan eljárást, ami elmagyarázza, hogy mi is folyik itt és ha kell, automatikusan megjavítja a parancsikont. (A másik módszer az lenne, hogy az összes .desktop fájlra alkalmazni kéne a +x-et (végrehajtható bit bit beállítása), de ez sokáig tartana, mivel a /-ből és nem a $HOME-ból kellene kezdeni a keresést a pontosság miatt. Ráadásul ez a lehetséges kártevőket is végrehajthatóvá tenné.)

    Néhány verziót a figyelmeztető ablak is megért:


    De beláttuk, hogy ez nem igazán célravezető. A szöveg annyira hosszú volt, hogy a t. felhasználó inkább inkább a „Folytatásra” kattintana és ezzel elintézettnek tudná be a feladatot. Végül egy kis beszélgetés után Celeste Lyn Paul és Tom Albers megtalálták a probléma gyökerét: tudja a felhasználó, hogy programot akar futtatni? Ez pedig elvezetett minket a következőhöz:


    Remélhetőleg ez tájékoztatja őt anélkül is, hogy ellenállhatatlan vágyat érezne a „Folytatás” gombra kattintáshoz olvasás nélkül, és még a létező parancsikonok is működni fognak. Elfogadáskor pedig a fájl indíthatóvá válik, így ezt az ablakot többször nem fogja látni.
    Persze több minden van még hátra. Alexander Larsson a GNOME-nál dolgozik ezen probléma megoldásán. Egy olyan kódot implementált, ami egy általános ikont és a .desktop fájl jelenlegi fájlnevét mutatja, ha egy ilyen nem futtatható a Nautilusban; valószínű, hogy a KDE-ben is hasonló megoldás lesz, hogy megelőzzük, hogy a megtévesztő .desktop fájlok kárt tegyenek. Ezen kívül tesztelésre is szükség van, hogy biztosak legyünk abban, hogy semmi sem ment tönkre emiatt.

    Statisztikák:

    Beküldések: 3554 db történt 288 fejlesztőtől, 8411 sor módosításával és 2711 új fájl hozzáadásával.
    Nyitott hibák: 16875
    Nyitott kérések: 14940
    Megnyitott hibák: 806 az utóbbi 7 napban.
    Bezárt hibák: 612 az elmúlt 7 napban.

    Összegzés

    Beküldési statisztikák:

    /trunk/l10n-kde4 - 746
    /trunk/KDE - 745
    /branches/stable - 418
    /trunk/extragear - 342
    /trunk/playground - 323
    /branches/work - 305
    /branches/KDE - 160
    /trunk/l10n-support - 120
    /trunk/koffice - 91
    /trunk/kdesupport - 89

    Nyelvi statisztikák (KDE 4.2):

    1. Ukrán: 100%
    2. Svéd: 99%
    3. Portugál: 99%
    ...
    27. Magyar: 73% (60.233 sor lefordított szöveg (-923))

    További információk és rengeteg statisztika megtekinthető az e heti KDE Commit Digest weblapján.

    E heti tipp:

    Az Amarok tálcaikonja sok mindenre használható, többek között:

    • görgetés: hangerő szabályozása;
    • Shift+görgetés: navigálás a zenében;
    • középső kattintás: lejátszás szüneteltetése;
    • az 1.4-es sorozatban pedig még jelölte azt is, hogy hol tart a lejátszás.

    E heti érdekesebb hírek, tippek a KDE és a Qt világából:

    • Megjelent a Qt animációs keretrendszer API második verziója [1];
    • Elérhetőek a linux.conf.au rendezvény OpenChange/Akonadi előadások videói [2];
    • Leírás az UPNP támogatás megvalósításáról az Amarokban és a KDE-ben [3];
    • Az Amarok már támogatja a gyűjtemény beolvasását a GUI nélkül is (scriptelve) [4].

    ( honorshark | 2009. 03. 01., v – 21:26 )

    KControl.. w00t.. :) (Olvastam kde.org -on is hogy mik tortentek, orulok hogy ismet lesz kcontrol..)

    ( szkaresz v | 2009. 03. 01., v – 23:07 )

    Aki KDE 3.5.x verziót használ(-t) állítom az "Ezen a héten történt a KDE táján" cikksorozatot árgus szemekkel figyeli és remél, remél, hogy egyenesbe jönnek a dolgok, hiszen disztribúciók zöme KDE4.x verzióval számolnak a következő kiadásaikban.
    Ha ezt olvasom:

    "KControl: a KDE 3 vezérlőpultjaként ismerhette meg a nagyérdemű"

    vagy

    "Az Amarok 2 kezd felnőni az Amarok 1.4 képességeihez"

    megkérdezem, miért kellet ennyire össze vagy szét (nézőpont kérdése) dönteni a KDE4 verziót.
    Biztosan valami egészen új alapokra akarják építeni, de azért az, hogy az Amarok2 lassan felnő az előd, 1.4 verzióhoztöbb mint megrázó, a többiről nem is beszélve :(
    De én (is) kitartok.... tényleg.

    --
    Karesz
    www.kareszka.hu

    Ha jól tudom, kb az alapoktól újra lett írva a KDE, nagyon sok olyan ötlet van benne, ami előremutató, csak a szolgáltatások még nincsenek lekódolva.

    Nem értek hozzá, csak user vagyok, szóval ha tévednék, fixme.

    Csak pár példa:

    Akonadi: egy adatbázisban tárol minden user információt és a programok ezen keresztül érhetnek el minden szükséges dolgot, nincs az, hogy "ezt itt tárolom, azt ott tárolom".

    Áttértek dbus-ra, emiatt, mivel nincs még KDE4-es K3B, AmaroK playlistből nem tudok behúzni egyelőre zenét írásra (van már / lesz plugin AmaroKhoz közvetlen playlist CD-re íráshoz).

    Plasma: szinte bármilyen információt megjeleníthet, lásd egységes Notification. Az integrált online installal együtt nagyon komoly dolgokra lehet képes majd.

    És igen, 4.0.0 óta használom, elején szitkozódva, de már nagyon sokat fejlődött. Nyáron jön a 4.3, 10-11 hónap múlva 4.4, Win7 megjelenése környékén. Egy DE-t nem szabad összehasonlítani egy oprendszerrel, de egy DE-t egy másik oprendszer DE-jével szabad, és a KDE 4.3, KDE 4.4 fényévekkel lefogja körözni megintcsak a MS féle megoldást.

    Nem mondom, hogy nincs vele még probléma, de szépen becsurognak azok a featureok is amiket a KDE 3.5-ben megszoktunk, sőt, annál még tovább is mutat ez az alap.

    A KDE fő konkurense szerintem a Gnome meg az XFCE. Így nincs sok értelme Win/Mac DE-hez hasonlítgatni. Ezeken a rendszereken (Win/MacOS) amúgy se cserélnél DE-t másra nagy valószínűséggel, lévén hogy nem igazán lehet. (A Wines KDE sose lesz jó szerintem.)

    Egyébként nagyon szurkolok a KDE-nek, én 1 hónap 4.0-zás után KDE 3.5.10-re tértem vissza. Kivárok...

    Teljesen szubkektív, de én azért választottam a kde-t, mert olyan innovációkat találtam benne, már a 3-asban is, amilyeneket semelyik másik DE nem produkál, és vonatkozik ez a 4-esre is (talán az os-x sorozatban vannak még hasonló ötletes elgondolások). A többi linux-on elérhető DE-be nem látom a fantáziát. Megcsinálják amire kérem őket, de használat közben olyan butának és esetlennek érzem.

    ( ssa2 v | 2009. 03. 01., v – 23:47 )

    Részben ennek a cikksorozatnak a hatására tegnap felraktam a kde 4.2-est. Nem kellett volna...
    Kb fél évvel ezelőtt a 4.0.1 vagy valami ilyesmi számú felért egy katasztrófával. A mostani sokat fejlődött azóta. Ez már csak szánalmas. Le is töröltem a francba az egészet...
    Továbbra is az a véleményem, hogy kb a 4.5-ös verzió környékére lesz belőle valami használható. De valószínűleg még akkorra sem fogja elérni a 3.5-ös szolgáltatási színvonalát.

    Hevi, itt megint ket dologrol beszelunk. Egyfelol vannak bizonyos standardok es iranyzatok (semantic desktop, standard dolgok elonyben reszesitese a sajat megoldasok helyett - lasd s/dcop/dbus/g), es vannak azok a kepessegek amiket az emberek a regi KDE alatt megszoktak.
    Nem tudom, de ha valaki megszamolna, peldaul CD-t sokkal tobben irnak mint ahanyan fajlokat taggelnek. Levelet is tobben olvasnak, mint akik kommenteket fuznek a fajljaikhoz.

    Szaz szonak is egy a vege: bizonyos szempontbol esszeru es jogos elvaras az, hogy ha valami benyel kozel ketto gigabajt merevlemezt a gepembol, akkor legalabb tudjam a napi szintu igenyeimet kielegiteni vele (levelezes, bongeszes, konzol hasznalat, esetleg fejlesztes), es ne kelljen lepten-nyomon korlatokba, hianyzo kodokba utkozni egy "kiadott" termeknel.

    Masfelol azonban a KDE fejlesztoi soha, sehol nem mondtak, hogy a KDE4 fejlesztese kesz van, a KDE4 vegleges verzioja ki van adva. Olyan gozgep zaj van a forumokon/IRC csatikon, hogy sokszor meg lehet suketulni. A kulonbozo kiadasok egyfajta merfoldkovek, amikor a fejlesztok elforditjak a fejuket a teteles feature lista bamulasarol, es elkezdik a bugok teteles listajat bamulni, es az alapjan menni. Ez alapvetoen a felhasznalok erdeke, hiszen igy egy - bar szerenyebb tudasu, de - bugmentesebb KDE-t kapunk. Tudom, most jonnek kommentbe, hogy "de hat ez van vele, meg az elcrashel, meg amaz segfaultol" - higyjetek el, a SVN trunk sokkal-sokkal borzasztobb. A hajatokat tepnetek, ha azt kellene hasznalnotok, ez biztos. De hat ezert SVN trunk.
    Persze azt is tudom, hogy ez baromira nem megnyugtato annak, akinek a KMail levelezes helyett crashelget, csak arra probalok ravilagitani, hogy egyelore tul sok kod van mozgasban, tul sok feature implementalodik nap nap utan ahhoz, hogysem ertelme lenne azon tanakodni, hogy a KDE kodminosege elindult-e lefele a lejton, avagy sem.
    A hegyet sem a csucsatol megmaszni muveszet, hanem az aljatol. A KDE mar egy jo darab utat megtett felfele, de a csucs meg nincs tul kozel - tovabbra is kuzdeni kell erte.
    -- 

    
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

    Szerintem, aki akarja használja továbbra is a 3-as szériát, igazából mindent tud, amit tudnia kell, és semmi nem indokolja, hogya 4-eset használja valaki. Emlékezzünk vissza hány év kellett ahhoz, hogya 3-as széria relativ hibák nélkül fusson, hogy ilyen nagy funkcionalitás legyen benne. Nem várható el, hogy egy sokkal fiatalabb project, hipphopp beérje elődjét, de ahogy haladnak a dolgok annak is eljön az ideje. Cégnél 3-asat itthon 4-eset használok teljes megelégedettséggel.

    Bizonyos szempontbol igazad van, de azert ez eleg konzervativ hozzaallas, hogy 'itt a 3-as, tok jo, minek mast hasznalni'. Ennyi erovel ott a Windows, tok jo, minek mast hasznalni? Nyilvan, mert vannak dolgok, amiben esetleg jobb.
    En nem mondtam senkinek sem, hogy 'marpedig most azonnal terjen at, kulonben...', csak azt mondom, hogy sokan annak figyelembevetele nelkul fikazzak az uj KDE-t, hogy ez a KDE csapat uj termeke, nem pedig a meglevo KDE egy ujabb verzioja. A ket felfogas kozott elvi kulonbsegek vannak.
    Ezen felul az viszi elore a projektet, ha minel tobben hasznaljak, es jelentik a hibakat. Ugy nagyon nehez egy ilyen szabasu projektet fejleszteni, hogy hasznalja kabe 5-8 ember, aztan mikor kidobjak a kozosseg ele, akkor jonnek a hoborgesek, hogy ez milyen pocsek, tele van buggal. Minel tobb ember hasznalja, annal tobbfele use-case jon elo, ami lehet, hogy kis szamu tesztelo mellett fel sem merulne.
    -- 

    
()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

    Egy kicsit lehet félreértettél. Én csak a 4-es védelmében írtam, hogy nem várható el, hogy pikkpakk olyan legyen mint egy évek óta kiforrott termék. És egyetértek abban, hogy annál jobb minél többen használják, a notimon is az van, de a cégnél ahol dolgozok vele egy kiforrott dologra van szükségem.