Vývojáři Gnome - zlepšení vztahů s komunitou

Allan Day, jeden z hlavních UX návrhářů GNOME, napsal na svém blogu, že má zájem zlepšit vztahy s komunitou, zvláště řešit staré nahlášené chyby, které se neřeší tak rychle jak by měly. To odrazuje pak některé přispěvatele z komunity. Také chce zlepšit zpětnou vazbu od začínajících uživatelů. Mohli by se častěji zapojovat do projektu a hlavně by měli vědět, s čím mohou pomoci.

11.4.2014 09:14 | jadd | Zajímavý článek

Komentáře

[Jiří Mádl]

Chápu to tak, že potřebují dělníky, kteří budou implementovat ty jejich hovadiny? Docela by stačilo, aby přestali kvůli Gnome kurvit GTK.

[host]

++1

[jiný host]

Proč chceš inkrementovat konstantu?

[Zase jiný]

Prakticky ji predekementoval, což pokud by stihl zapsat a provést zároveň, tak vlastně psal nulu :)

[martin.k]

prakticky napsal 2

[Bedňa]

To tu bude nablito a že tá moja neprešla ^_^

[Lol Phirae]

Trhněte si ploutví. Když jsem soudruhům UI-idiotům napsal feedback k jejich brainfartu s GTK+ 3.12, tak to druhý den smazali a "Comments closed".

[Tomáš Bžatek]

Necetl jsem tvuj komentar, ale feedback uzivatelu vetsinou nikoho nezajima. Bohuzel. Tim spis, pokud byl tvuj komentar nekonstruktivni nebo utocny,

[Federer]

To byla určitě kvalitka, zřejmě něco jako Jardíkovo "Hot people"

[Lol Phirae]

Jen jsem jim tam napsal, jestli by nebylo lepší místo nucení uživatelů lovit dialogy na naprosto nesmyslných místech se věnovat třeba tomu, aby po dvaceti nebo kolika letech vyplodili použitelný file selector, nebo aby přestali při každé aktualizaci totálně rozbíjet témata. Jinak neuvěřitelné plýtvání místem je naprosto validní připomínka, co se GTK+ týče.

[pavlix]

Počkej, ty sis dovolil naznačit, že něco dělají špatně? Tak to se pak nediv, takové věci se v Gnome nedějí.

[Lol Phirae]

Vidím. Rovněž pod stávajícím blogem: "Your comment is awaiting moderation" - asi už jsem na blacklistu.

[pavlix]

Nebo už je prostě ten uživatelský feedback nebaví a nejsi na whitelistu ;).

[Lol Phirae]

No v tom případě by stačilo ty komentáře úplně vypnout.

[rbc]

Počkej, ty sis dovolil naznačit, že něco dělají špatně? Tak to se pak nediv, takové věci se v Gnome nedějí.

Hergot, co mi to pripomina ? Reakce Sewerse a Harryho L. Potteringa na buglistu systemd ? No jo, RedHeat, banda sr*cu pro kterou jsou komunitni vyvoj a ohleduplnost k jinym jako nejaky sci-fi.

[pavlix]

Zkus udělat pár kroků, nejspíš si stojíš na vedení.

[Honza Jaroš]

Znáte slovo "ironie"?

[Federer]

Hrozně konstruktivní, připsal jsi tam, že jim děláš do jejich matek?

[Lol Phirae]

Ne, myslíš že by to pomohlo? Protože nevidím nikoho, kdo by volal po tlačítkách rozházených na nesmyslných místech a dalších píčovinách, narozdíl od těch problémů, co jsem zmínil.

[Federer]

Jiný přístup by pomohl, čtu blogy na planet.gnome.org a kritika v komentářích rozhodně nechybí (zrovna tu diskuzi ohledě dialogů si pamatuji), jenže tam nikdo nepsal o píčovinách a podobně, víme?

[Lol Phirae]

Já ti rozumím, práce se soubory je píčovina, prioritou je hrát si chaoticky s vomalovánkama a odstraňovat featury.

[Federer]

Tak to oprav, zmrde.

[Lol Phirae]

Hmmmm, tomu říkám zlepšování vztahů na úrovni!

[Federer]

To se právě snažím říct, takhle jednáš ty a sám si přeber, kam to vede. Můj předchozí komentář bude dost dobře moderován, to abych šel brečet, jak jsou tu nespravedliví :'-(

[Lol Phirae]

Z toho asi neusnu...

P.S. Jinak nevím, co bych asi tak měl opravovat. Ten fileselector je dokurvený by design a ta banda pošuků neustále trvá na tom, jak je geniální. O themes a nekompatibilitě darmo mluvit. A největší pokoukání je, když si člověk nějakou tu GTK-based aplikaci pustí z konzole a zahltí ho ty nekonečné záplavy varování a chyb. Fakt paráda. Prostě jsou to borci!

[tacoberu]

Když pomineme FileDialog z GTK verze 1; Jaký file dialog by jsi uvedl za vzor? QT? Nebo snad dokonce Windows? Já si na Gtk nemohu stěžovat, a naopak si stěžuju, když musím otevírat něco v QT (Windows jsem se zbavil už před lety).

[Marián Kyral]

Ideálně KDE file selector.

[rbc]

File dialogu z Qt3 prakticky nic nechybelo. I ten z explorerovsky z Win2k - Win7 je porad praktictejsi.
Proc musi od GNOME/Gtk+ vyvojaru porad resit ze neco nejde, nebo ze neco slo a v novy verzi uz to nejde ? To si dal nekdo za cil regresi misto progrese ? Je to projev absolutni nechopnosti resit fundamentalni problemy a zastirat to takovym trapnym zpusobem ? Nebo se musej vsichni povinne zhulit nez zacnou neco navrhovat nebo nedej boze kodit ?

[Jardík]

Ty voe, BurnApp ... kde je tomu konec, už asi nemám ani nikde zdrojáky.

[Grunt]

WTF? Co to psalo za pako? Co je blbě na růžové? Kdyby bylo Ubuntu růžové a ne tak přitepleně oranžové, mám distribuci hned vybranou.

[Lol Phirae]

Co je blbě na růžové? Kdyby bylo Ubuntu růžové a ne tak přitepleně oranžové, mám distribuci hned vybranou.

Božííínku

[kavol]

... hlavně by měli vědět, s čím mohou pomoci.

jo, tak ... já už jsem se lekl, že by náhodou chtěli zlepšit vztahy komunitou tak, že by ji přestali nasírat odebíráním featur a podobně

[Tomáš Bžatek]

Ne, jen potrebuji nabrat bug triagery.

[Ivan]

Myslim, ze si za to muzou sami. SW ktery produkuji tak prekomplikovanej(ne-unixovej), ze se v tom nahodny kolemjdouci nedodaze zorientovat. Uz jsem fixnul par chyb v ruznymch open-source programech (tzn nejen reportoval chybu) ale veci, ktery souvisi v Gnome fakt nedavam. At si ten hnuj kyda nekdo jinej.

[little.owl]

Tak koncepce interoperatibilniho GObject modelu neni vubec spatna, i jejich snaha psat objektove v C, jen je to relativne slozite a je tam plno boilerplate kodu.

Vala .... nevim ... radsi bych mel poradne dotazene gtkmm a C++ ...

[pavlix]

Na boilerplate se dá vcelku rychle zvyknout. Na druhou stranu objektový model mi připadá podstatně lepší než ten z C++, takže bych to neviděl zase tak kriticky.

[little.owl]

Na druhou stranu objektový model mi připadá podstatně lepší než ten z C++,

S tim bych souhlasil, ja jsem to vztahoval spise k Vala.

[Jardík]

Na Valu pozor. Díky tomu, že indexuje pole intama, že jeho velikost je v intech, tak může nasekat spoustu bezpečnostních děr ve vašem programu (a i když použijete jakési CCode atributy a řeknete jí, že tam je size_t, tak sice napíše size_t, ale vnitřně stejně počítá s intama). Když jsem to hlásil a navrhoval změnit v počátečních verzích Vali, tak hrabal bagr a nic se nedělo. Vala je tedy rozbitý jazyk. Rozbitý je každý kód, který do proměnné typu int přiřazuje hodnotu operátoru sizeof.

[pavlix]

tak může nasekat spoustu bezpečnostních děr ve vašem programu

Pokud pár těch chyb objevíš, tak máš velkou šanci na úspěch.

[kralyk z abclinuxu]

Na druhou stranu objektový model mi připadá podstatně lepší než ten z C++, takže bych to neviděl zase tak kriticky.

Flamebait alert!

[pavlix]

Tady není o čem diskutovat. Ale pravda je, že jsem mohl napsat schopnější.

[kralyk z abclinuxu]

Stále mi to přijde jako flamebait. C++ v zásadě nemá Jeden Správný™ obj. model, podobně jako v C je možné používat různé postupy a nebyl by problém v celku jakoukoli feature gobjectu realizovat v C++...

[pavlix]

C++ v zásadě nemá Jeden Správný™ obj. model

Mám za to, že C++ má vestavěný a standardizovaný objektový model, ale rád se nechám vyvést z omylu. Tím samozřejmě neříkám, že ho nejde obcházet a používat cokoliv jiného jako v C včetně GObject a ekvivalentu.

[kralyk z abclinuxu]

Mám za to, že C++ má vestavěný a standardizovaný objektový model, ale rád se nechám vyvést z omylu.

Ano, ale je natolik obecný (a různé featury a gotchas obsahující), že konkrétní použití se od sebe mohou výrazně lišit (viz také moji tl;dr odpověď Bedňovi níže).

Tím samozřejmě neříkám, že ho nejde obcházet a používat cokoliv jiného jako v C včetně GObject a ekvivalentu.

Ani ho obcházet nemusíš, je možné různé věci doplnit. Něco jako gtype různé frameworky dělají (třeba variant v boostu, QMetaObject a QVariant v Qt, wxObject ve wxWidgets atd.).

Nebo si měl na mysli nějakou jinou feature GObjectu?

[pavlix]

Ano, ale je natolik obecný

Nicméně dle mého skromného názoru pořád ne tak obecný jako Python nebo GObject.

[kralyk z abclinuxu]

Protože...?

[pavlix]

Můžem si na to někdy sednout. Vezmem si k ruce dokumentaci všech tří a probrat to.

[zxtlpn]

GLib + GObject + GIO jsou skutečně báječný. Vůbec GNOME knihovny jsou všeobecně na dost dobrý úrovni. Ještě by to mohlo bejt pod MIT/BSD licencí, ale co člověk nadělá.

Vala má nevýhodu toho, že je to metacompiler + horší podpora u vývojovejch nástrojů + relativně špatná dokumentace (možná se to od tý doby, co jsem v tom zkoušel vyvíjet posledně, nějak změnilo k lepšímu, ale moc se mi tomu nechce věřit).

C++ má nevýhodu toho, že to je C++. :> Odpadne nějakej ten boilerplate, ale přidaj se další potíže.

Každopádně dnes GNOME projekt za definitivní odpověď na jazykovou otázku valí Javascript, jak jsem nedávno kdesi vynašel.

[pavlix]

GLib + GObject + GIO jsou skutečně báječný.

Až tam nebudou nesmysly jako spojáky s API pole, tak se o tom můžeme bavit. Já vím že u seznamů síťových rozhraní na desktopu to nehraje příliš roli, ale to nic nemění na tom, že je to debilita.

[Tomáš Bžatek]

Javascript by se mel pouzivat jen na frontend, veci za tim ani v JS rozumne nenapises, tam zustava C.

[R]

V Javascripte sa GUI (niekomu) asi lahko zbastli. Ale bolo by vhodne, keby sa zamysleli aj nad pouzivatelmi, co ten grc potom musia pouzivat. Vlastne nemusia, mozu prejst na KDE. Alebo na Windows.

[little.owl]

Myslite nove KDE postavene na Qt Quick a QML, tedy take Javascriptu? A myslite, ze MS to bude tlacit jinam?

[Jardík]

Ono to s GObject tak růžový neni. Nemůžete "vyhodit výjimku", nebo nahlásit chybu při konstrukci objektu, musíte to řešit hackem typu G(Async)Initable. GIO streamy (jejich hiearchie) jsou tak trochu mizerně navržený. GObjectClass a virtuální metody, rozbije se ABI při přidání metody, takže všude přidávaj jakési void (*reservedXXX)(). Takže v podstatě stejný hack, jaký byste použili v C++, hodíte tam reserved virtuální metody. Zároveň spoléháte na to, že velikost pointeru na fci nezávisí na jejím typu. U "zlých" kompilátorů se to rozbije. GObject je v podstatě jakýsi hack, jako ve Windows Interfaci, jako IUnknown a spol, prostě hack kolem C.

GIO datové struktury mají problém s tím, že v C nejsou šablony. A když to obalí ve Vale a uroběj šablony, tak je sprzněj tím, že do nich cpou stejně např. pointer na strukturu a né její hodnotu. Takže kvůli struktuře s dvěma intama máte třeba List<MojeStruktura>: List *next, List *prev, MojeStruktura *value, místo vhodnějšího List<MojeStruktura>: List *next, List *prev, MojeStruktura value, kdy máte jednu dynamickou alokaci vs dvě. Je to tedy nevhodné tam, kde je potřeba rychlost a mnoho dat.

[zxtlpn]

GIO jsem příliš do hloubky nezkoumal, ale jinak máš pravdu.

Narozdíl od C++ je v C/GObject silně preferovanej PImpl idiom a jeho použití nezpůsobuje tolik bolesti.

Ten problém s genericitou GList se trochu zmenšuje tím, že má GLib zvláštní alokátor na objekty statický velikosti (SLAB alokátor se tomu říká?). Pořád je ale snížená lokalita dat (i když se zas teoreticky může optimalizovat procházení, když si ty list nodes předalokuješ dopředu). Podle mě to v praxi nestojí za řeč a bottlenecks budeš mít jinde.

[kralyk z abclinuxu]

V čem ti Pimpl v C++ připadá bolestivý?

[zxtlpn]

Hlavně kvůli privátním metodám; ty nemaj co dělat v hlavičkovym souboru. Psát forwarder metody pro všechno public, nebo je v tom .h souboru nechávat... nebo nějaká magie, která mi uniká, abych zas nevytvářel falešný dilema... V C neni ani důvod to řešit.

[kralyk z abclinuxu]

Hlavně kvůli privátním metodám; ty nemaj co dělat v hlavičkovym souboru.

No tak od toho právě ten pimpl je, aby tomuto zabránil, ne snad?

[Jardík]

Mně právě pimpl vadí, protože to vyžaduje alokaci na heapu (pokud vynechám nějaké vlastní alokátory). Ono sice u nějakýho GUI prográmku, kde mám ~100 widgetů a pár dalších objektů, co něco dělaj, moc nevadí, ale někdy se to i nasčítá. On je někdy ten rozdíl i vidět. Když mám udělat new Window(), kde je extra každý new WidgetXX(), nebo když mám utvořit Window na zásobníku, kde je každý widget přímo součástí objektu a jen se tedy volají konstruktory ... Sice pimpl má výhodu zachování ABI, ale u nějakého GUI toolkitu by to mělo být jedno, většina může být inline a "neinline" jenom nějaké "věci" jejichž kód je náročnější, hrozí nějaké rozbití a je dobré kód sdílet (řekněme implementace síťového protokolu, šifrování, databáze). Okýnka klidně můžou být inline, nebo staticky linkované.

[Bedňa]

Trochu od veci, ale keď vidím new a delete vybavia sa mi technológie minulého storočia ako na to chceš napísať GC? To je od základu zle :) Chlapi vzdelávajte sa a už zahoďte technológie kde neriešiš cieľ projektu, ale bíkoviny.

[kralyk z abclinuxu]

Pokud vím, nikdo nic o nějakém delete nepsal...

[Bedňa]

Ale napísal new a už to je zle :)

[kralyk z abclinuxu]

A to proč? new je dokonce i třeba v JavaScriptu...

[Bedňa]

Len ďalšia propagácia U++

[kralyk z abclinuxu]

Mrkni se, jak spravují paměť jinde. Možná zjistíš, že ani jinde nejsou tak úplně blbí, případně že to mají promakanější než u++...

[Bedňa]

Je to podobné C# a Java + prehľadnejší kód kvôli eliminácií ukazateľov. C++ (vrátane QT) je taký praso pes, systémový ako C a vysokoúrovňový ako Python, len všetko robí zle

[kralyk z abclinuxu]

Je to podobné C# a Java + prehľadnejší kód kvôli eliminácií ukazateľov.

C# nebo Javě to moc podobné není, sice se snaží nepoužívat pointery, ale Java a .NET mají garbage collector, kdežto U++ GC nemá a místo toho používa stack-based memory management. Pokusím se to trochu rozebrat:

Podle toho, co jsem se probíral dokumentací a příklady, U++ se v zásadě drží několika jednoduchých pravidel:

1. Co můžou alokovat na stacku, alokují na stacku.
2. Třídy, které někdo vlastní, se vloží přímo do nadřazené třídy.
3. Objekt má jednoho svého vlastníka, sdílení považují za bad practice, používají místo toho move semantics.

Tohle řešení má výhody i nevýhody, výhoda je, že se nemusí tolik zabývat alokací na heapu (a s tím související režií/riziky) a to, že na stacku se všechno pěkně "samo" odalokuje. Když už alokují na heapu, zapouzdří to do objektů jako Buffer, Image a podobně. Nevýhoda je, že aplikace pak zabere víc místa na stacku a struktury můžou narůst do velkých velikostí. Další věc je, že někdy může být sdílení objektů nejvhodnější řešení. Např. v Javě/.NETu je sdílení na dením pořádku.

C++ (vrátane QT) je taký praso pes, systémový ako C a vysokoúrovňový ako Python, len všetko robí zle

Ale nerobí všetko zle, vůbec ne.

Qt, například, používá svůj QObject model, kde jsou objekty členy hierarchie, ve kterých nadřazený objekt dealokuje všechny objekty sobě podřazené. Čili to "vlastnictví" objektů je podobné jako v U++, akorát mechanismus de/alokace je jiný a je to dynamičtější. Další podobnost je v objektech jako Buffer a Image (v případě Qt QBuffer a QImage), které alokují na heapu a alokaci následně spravují, v podstatě v obou toolkitech stejně. V Qt ale tyto objekty navíc implementují QSharedData, což umožňuje sdílení pomocí reference countingu a mělkých kopií. Tuto feature U++ zřejmě vůbec neposkytuje, místo toho prosazuje move semantics.

No a nakonec, za "správný" model správy paměti se v C++ (zejémna v C++11) často považuje RAII, kde se klade důraz na smart pointery a exception safety. V RAII se v podstatě holým pointerům vyhneš víc než v U++. Jedním z hodně používaných smart pointerů je "scoped pointer" nebo "unique pointer", což je objekt alokovaný stejně jako objekty v U++ (tedy na stacku nebo jako součást struktury), který manažuje paměť na heapu, což spojuje výhody obou. Sdílení objektů se ralizuje pomocí "shared pointerů", které typicky používají reference counting. Nevýhodou RAII/stack based memory managementu je (a toto platí i pro U++), že je potřeba dopředu dobře rozmyslet, který objekt/objekty má vlastnit/spravovat který/které.

Abych to shrnul, o žádném z těchto modelů se nedá říct, že by byl jednoznačně vždy lepší, každý má svoje pro a proti - a to včetně U++.

P.S. Osobně považuju RAII za dobré řešení, ale to není nějaké objektivní hodnocení.

[Bedňa]

Dík za naozaj poučný komentár (myslím to bez sarkazmu).

Jasne že C++ nieje zlé, len tie prístupy sa mi zdajú archaické, ale je to len vec názoru a nechcem tvrdiť bezhlavo že toto je lepšie keď máš klasické C++ rád a vyhovuje ti.

So long.

[zxtlpn]

Jsem se nějak dočista zamotal. Takhle:

Pak můžeš v tom .cpp souboru vytvořit další objekt s metodami, kde opět musíš do jeho definice napsat deklarace těch privátních metod (to jsem tím nejspíš myslel), a nebo všechno nainlinovat a nejspíš (podle vkusu a žaludku) se smířit s jednou úrovní odsazení navíc. Třetí možnost, která mě teď napadá, je udělat Impl jako struct a psát to v ukecaném C stylu.

Bolest v podobě forwardu public metod setrvává. Tu má u virtuálních metod má i GObject.

[kralyk z abclinuxu]

Možná si nerozumíme, v C++ obvykle pimpl vypadá nějak takhle:

class Foo
{
private:
	class Private;
	unique_ptr<Private> p;
public:
	//...
};

V zásadě na tom žádné moc velké bolení hlavy nevidím... Pro veřejná API knihoven se to určitě vyplatí.

[zxtlpn]

Mimochodem mít prostory, tak už ti dávno nabídnu zaměstnání na černo za splnění základních životních potřeb, nebo co to vlastně chceš. Hodil by ses mi, potřeboval bych toho fůru naprgat do *nixu, většinou GUI aplikace. :)

[Jardík]

Já jsem takovej "chytrej" programátor, co rád kecá, jak je všechno špatně, proč to je nemožné správně udělat, ve všem vidí chyby, ale sám nic napsat pořádně nedokáže Najdi jedinou věc, co jsem kdy dodělal do konce.

[zxtlpn]

To je jedno, přinejmenšim seš dobrej analytik.

[Luboš Doležel (Doli)]

Někdy si říkám, že by používání ObjC nebylo tak špatný (až na tu trochu nezvyklou syntaxi). Mimochodem netrpí ani problémem s rozbíjením ABI (při kompilaci pro non-fragile ABI).

[pavlix]

Ona by především neškodila osvěta ohledně stability interface napříč nástroji a vytvoření nějakých podrobných best practice s konkrétními příklady, co se stane při nedodržení té které z nich. Osobně mám pocit, že problémy se stabilitou interface se objevují ve všech technologiích od čistého C až po plně dynamické a introspectable (doporuč český název) technologie jako je D-Bus.

Rovněž stojí za to se podívat, které projekty a v kterých technologiích používají nějaké nástroje na kontrolu stability interface i kdyby to mělo být jen ve formě zápisu, kdy vývojář, reviewer a maintainer na první pohled podle názvu změněného souboru ví, že se jedná o zásah do stability interface.

Souhlasím s tím, že některé programovací techniky a nástroje nabízejí v oblasti zachování stability větší pohodlí, ale subjektivně vnímám mnohem větší problém na straně maintainerů a to žádné objective C nezachrání.

[Ivan]

Nejde ani tak o ten GObject ale spis o to, ze se vsechno resi preposilanim zprav.
Napriklad. V korporaci kde jsem drive pracoval meli nejak zvlastne zabezpecenou wifi. Ackoliv iwconfig zobrazoval normalni seznam siti, tak gnome panel z NetworkManageru mi prekryl celou obrazovku tunama binarnich sr*cek pokazdy kdyz jsem si chtel vybrat sit ke ktery se pripojim. Takova chyba je jen velice tezko reprodukovatelna a tezko se i reportuje. V "normalnim" open-source by ji opravil ten, kdo ji objevil. A tak jsem se o to pokusil, stahnout jsem si vsechny zdrojaky vsech baliku, zkompiloval to s debug symbolama, pozabijel jsem NetworkManager i ten applet. Hrozne dlouho jsem lovil nejaky sileny uid-cka, ktery se musi tem programum predat, aby to vsechno pospojovalo a fungovalo. No a pak jsem degugoval ty procesy najednou a hledal jsem kde, kdo, komu a jak predava seznam wifi a kde se to parsuje. A neprisel jsem na nic - nakonec jsem to vzdal.
Podobnej problem jsem mel s Evolution a GnomePassword managerem. Nase firemni AD zablokovalo ucet na nekolik minut po trech neuspesnych pokusech. GnomePassword manager obcas "zapomel" moje heslo a Evolution se pokusil autentizovat nejakym nahodnym textem. Otevrel 2000 TCP spojeni na Exchange server a pak umrel na ulimit. Ani u tohodle problemu se mi nepodarilo na nic prijit a bugreport lezi v bugille 5 let, bez toho aby to to nekdo sahnul. SW ktery Gnome je prilis komplikovany na to aby nejaky uzivatel mohl poslat patch bez toho aby se v tom vrtal dele tyden. A ani kdyz nekdo k butgreportu prilozi core-dump, vystup z strace a lsof, tak to nemusi stacit k tomu aby nekdo mohl chybu fixnout.

[pavlix]

Ty problémy jsou způsobené náboženstvím jménem dbus jehož vrcholem je používání aktivace služeb pomocí dbusu. Než jsem to začal debugovat, taky jsem si myslel, že je to skvělý nápad. Už si to nemyslím.

[host]

++1

[Federer]

error: lvalue required as increment operand

[Andrej]

Zpětná vazba od začínajících uživatelů se nedostaví, obávám se. Uživatelé jiných desktopových prostředí zkrátka nezačnou dobrovolně používat Gnome. Pokud jde o uživatele začínající s Linuxem, jejich setkání s Gnome obvykle skončí rychlým návratem k Windows nebo OS X, takže ani tady se zpětná vazba očekávat nedá.

[Jakurta]

Aha, tak odtud vitr fouka

[JZD]

Zprávička.

[jadd]

A jak to s tím souvisí? oni nežádali příspěvek. Když se podívám na komentáře, převládají ty s kopancem do čehokoliv.

[chrono]

Bolo by zvláštne, ak by žiadali príspevky od ľudí, ktorých tak vytrvale ignorujú.