LXQt 0.11.0

Po téměř 11 měsících vývoje od verze 0.10.0 (zprávička) byla vydána verze 0.11.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment) vzniklého sloučením projektů Razor-qt a LXDE (zprávička). Z novinek lze zmínit například pavucontrol-qt, Qt port audio mixéru pavucontrol z projektu PulseAudio. V lxqt-config přibyla možnost nastavování jasu. Vylepšena byla podpora více monitorů.

26.9.2016 12:43 | Ladislav Hagara | Nová verze

Komentáře

[mirec]

K vydaniu sa trochu rozpísal aj jeden z hlavných vývojárov LXQt Jerome Leclanche.

[Pavel Půlpán]

Depresivní...

[chrono]

Čo presne? To, že iní ľudia robia vlastné DE namiesto toho, aby prispeli do nejakého existujúceho a tým trieštia DE pod Linuxom? (presne tak, ako to urobili aj tvorcovia LXDE, LXQt, Razor-Qt)

[Pepan]

Také to na mě tak působí. Linuxový desktop se podle mě ubírá pořád horším směrem. Nevím jestli je tlačen uživateli kteří sledují hlavně vzhled. Navíc co nejpodobnější MS. LXQt se mi moc líbí, ale když čtu názory některých uživatelů, kteří pro to nic neudělali a stěžují si že to vypadá jako Win98, nebo Win3.11 je mi na zvracení. Osobně k životu nepotřebuji nesmyslné efekty a další vylepšování hovadin pro oči. Systém potřebuju k práci a vzhled je až na úplně posledním místě.

[little.owl]

Systém potřebuju k práci a ...

Ted se jeste shodnout na tom, jak ma takovy "system k praci" vypadat.

[k3dAR]

jako Xfce ;)

[ikar]

jako dwm ;)

[Pavel Čejka]

Jako KDE 4.11 (bez Nepomuku, Akonadi a jiných nesmyslů), nebo LXDE

[koroptev]

Jako android na cinskym smartfounu za 2000,-

[Pavel Píša]

KDE 3.5 a dnes Trinity 14

[R]

To je dodnes, zial, asi jedine pouzitelne desktopove prostredie pre Linux. A napriek nedostatku ludi vyvojari opravuju bugy.

[Prohnutá nudle]

+1

[mica]

Co to je "clusterfuck"?

[chrono]

clusterfuck
(a čo mu vadí na KDE napísal nižšie, stačí si prečítať jeho príspevky)

Urban Dictionary: clusterfuck

Náš administrátor shledal tento komentář závadným.

ad hominem

Zobrazit komentář

[PetrHL]

Mám úplně stejné pocity už delší dobu. Myslím, že je to vidět i zde na abclinuxu. My "starší" máme už většinou děti, případně trochu jiné zájmy a není tu nikdo, kdo by to po nás převzal. Už nemáme tolik času a energije jako dříve.

Přijde mi, že nastupující generace už nemá o Linux zájem a svoboda, kterou poskytuje, je jim někde u zadnice. Většinou se věnují vývoji v šíleném javascriptu na macbooku a ostatní je nezajímá, nebo zajímá jen okrajově.

U desktopových prostředí často jde jen o to, aby se pořád něco měnilo. Nechápu proč, raději bych byl, kdyby opravovali chyby, optimalizovali kód a snažili se o nějakou stabilitu. Mi třeba v takovém Gnome 2 nic nechybělo. Proč se přešlo na Gnome 3 a neustálé změny API nikdy nepochopím. Asi jsem moc starý. Jsem dalece jim nařizovat aby dělali něco, co mi bude vyhovovat. Jen těm změnám pro změny prostě nerozumím.

[Rezza]

Ja bych zase rekl, ze lidi berou ten spodek, ten system, jako hotovy. A ted delaji veci nad nim (i kdyz casto nad Macem, protoze je ten hotovy spodek nezajima, je to jen prostredek, ne cil). Proto jsme i zmenili LinuxAlt na OpenAlt. Samotny system resi uz malokdo, ale co nad nim delat skoro kazdy (a nastesti to nejsou jen JS sracky .

[koroptev]

Prumerna linuxova distribuce ve svym repozitari obsahuje objemove 1% nutnejch veci any to bezelo 5% uzitecnejch veci aby se s tim neco dalo delat 5% veci ktery jsou multiplatformni a vsude a zbylejch 89% je totalni shitozni balast od konstantnich betaverzi ruznejch utopii po marginalni knihovnicky jednoho cloveka redici pomilionty stejnej problem (ale jinak a lepe)

[Pavel Píša]

Přesně moje pocity. Bohužel spíš bude hůře, protože odpor mezi studenty Počítačového a Softwarového inženýrství vědět alespoň základy toho, jak počítače fungují, jak je nad možnostmi HW postavený operační systém a jak ho použít efektivně případně dokázat ohodnotit, které frameworky to dělají dobře a které vybrat, je neměřitelně veliký.

Těch výjimek, se kterými lze na projektech spolupracovat je málo. Přitom nám společnosti jako EATON, Volkswagen Research Service, Porsche, Honeywell a mnoho dalších a další nám trhají ruce a nadávají, že si studenty držíme třeba půl roku až tři roky u nás na projektech, protože nemohou použitelné lidi na procesorově a softwarově orientovaný vývoj na libovolné z vrstev sehnat.

Teď si studenti anketou vyžádali zrušení předmětu, který byl orientovaný na open-source a zopakování si základních znalostí jako je pro příklad select, poll, epoll s porovnání s Win a JAVA světem (WaitForMultipleObjects, java.nio.channels.) atd. Je to podle nich low level HW Linux only nesmysl, který je obírá o čas v jejich programátorském rozletu. Přitom značná část z nich, když dostane možnost přispět do jimi vybraného open-source projektu, tak má snahu utéct k lokalizaci pár řádek nebo jinak se skutečnému přemýšlení a programování vyhnout.

Na druhou stranu jsou výjimky a jediný důvod, proč se ještě v této oblasti snažím, je těch tak 20 opravdu schopných odborníků a 30 lidí, co se dokázali přiblížit k hranici jejich schopností, k jejichž posunu vpřed jsem mohl za těch 20 let na škole přispět.

Co se týče přemýšlení nad efektivitou, tak i framework jako Qt teprve tento měsíc přešel z 20-let historického selectu (1983) na poll (1986). Přitom existenci epoll, kevent nebo I/O Completion Ports (Win) velké a rozšířené frameworky jako Qt i Glib (GTK/GNome) ignorují.Často však i ti programátoři, kteří ještě nepovažuji C a C++ za sprostá slova podřadné magie, používají Qt i Glib v systémových službách a i nevizuálních aplikacích, kde o výkon opravdu jde a vůbec nemají představu třena o libevent2 nebo podobných řešeních.

Dnes ale zajímá většinu lidí tak plynulost animací na obrazovce, přenos piexel exact designu GUI od firemních kreativců na mobilní display za jakoukoliv cenu a utrácení výkonu a peněz v cloudu pouštěním různých monster.

[Saljack]

Ja jsem Vas predmet open-source absolvoval (povine na OI) a vubec se nedivim, ze si studenti v ankete vyzadali jeho zruseni. Jedine co mi na nem prislo open-source byla semestralni prace, kde se melo do nejakeho open-source projektu prispet. Uz jenom to, ze na prednasky chodilo minimum lidi by melo byt znakem, ze je neco spatne. Zde ani nebyl problem s prednasejicim (jako v jinych otresnych pripadech), ale se skladbou predmetu. Do dnes nechapu co ma select/poll/epoll spolecneho s open-source. A mam stejny nazor, jako ostatni, ze uz predmet byl za hranou low level.

Přitom značná část z nich, když dostane možnost přispět do jimi vybraného open-source projektu, tak má snahu utéct k lokalizaci pár řádek nebo jinak se skutečnému přemýšlení a programování vyhnout.

Tak proc se tohle na zacatku nezakazalo? Prislo mi to opravdu smesne (no spis trapne), kdyz tohle dela clovek na magistru v oboru softwarove inzenyrstvi.

[little.owl]

Trochu jako variace, na to co se ma na univerzite ucit - computer science versus code monkey.

Prislo mi to opravdu smesne (no spis trapne), kdyz tohle dela clovek na magistru v oboru softwarove inzenyrstvi.

Cesta nejmensiho odporu k zapoctu, kdo to nekdy nedelal? Plno studentu o obor co studuji vlastne ani nema zajem.

[koroptev]

Na te konkretni skole treba ti, co chteji studovat computer science a ne "co je zrovna popularni mezi opicema v r 2016"

[Pavel Píša]

Co se týče lokalizací, tak byly ponechané (nebyly přímo zakázané) jako záchytná šance pro ty, kdo opravdu mají problém něco naprogramovat. Také bylo na začátku vysvětlené, že si mnohem více vážíme i opravy jen jedné řádky kódu ve větším dobře vedeném projektu, než lokalizací (za ty bylo i omezené maximum možných bodů) a případně tvorby vlastních projektů typu hra ve Flash.

Co se týče obsahu předmětu OSP, tak studentům základní znalosti z oblasti operačních systémů i po povinném kurzu v bakaláři chybí. Z pohledu OI to bylo i při koncepci programu jasné, že vybrané obory by měly dovést studenta i k tomu, že bude pro oblast skutečného počítačového inženýrství, návrhu embedded platformem atd. použitelný. Takže byla původně zadaná příprava předmětu Open-Source operační systémy. Bohužel již v době přípravy nechuť k tomu znát základy a i oprávněný požadavek, že studentům chybí schopnost projekty vést a zdrojové kódy spravovat, vedla k tomu, že se předmět přejmenoval a výuka se rozčlenila přibližně na třetiny

1) open-soure jako příklad, projekty, historie, licence, filozofie i pragmatický přístup

2) správa kódů a seznamů chyb, a předávání úprav/komunikace

3) původní záměr zlepšit znalosti programování

Úvodní diskuze k předmětu zde

https://forum.fel.cvut.cz/post/26424/#p26424

Od původní představy, že by se studenti opravdu naplno učili na velkém projektu Linuxového jádra jsme přešli k spíše motivačním a snadným úlohám v userspace.

Myslím si, že ti kdo opovrhují alespoň letmým seznámením se s úspěšným (možná i na světě největším) softwarovým projektem (15 M řádek, v roce 2015 téměř 10,000 vývojářů z 1,000 firem) a mechanizmy, které umožňují to, že se projekt pod svojí vlastní vahou nezhroutí, tak nemají k programátorskému řemeslu a umění žádný vztah.

Přitom v dnešní době, kdy je Linuxové jádro extrémně rozšířené, Microsoft přichází na open-source, protože v rámci uzavřeného modelu již vypotřebovali vstupní vklad z VMS, BSD a dalších firem, které napsaly velkou část subsystémů Windows pro to, aby prodaly svůj HW a nic jiného než open-source spolupráce je asi dál nemůže posunout, tak v takové době se studenti o tyto technologie nechtějí zajímat trochu vážněji.

Sám si nemyslím, že je Linux všeho spásou a velmi aktivně přispívám i k alternativám. Například systém RTEMS, se který jsem si portoval na své desky během studia ve věku našich studentů. Leto3n9 commity zde. Přitom i pro tuto práci jsem Linux používal, protože příprava křížových překladačů na Windows, kterou jsem i pro některé firmy a kolegy podstoupil, je nepopsatelná ztráta času a nervů. Pro práci na Rsapberry Pi jsem používal Linuxové jádro, jako zdroj dokumentace, protože k mnoha čipům prostě dokumentace není, a nezbývá, než informace o HW získat z často nehezkých kusy kódu připravené přímo firmami pro Linux.

Když je to potřeba, tak jsem napsal i drivery pro Windows a další operační systémy. Vedl jsem i projekty v Qt, Delphi i jiné, které jsou na vyšších příčkách OS. Nakonec jsme pro medicínské aplikace i přes odpor k vlastnímu NIH GUI vedl vývoj takového Widget setu, který bylo možné na tvrdě svalovaný přístroj opět s RTEMSsem a ne Linuxem dostat.

Takže myslím, že mám o něco širší přehled. Ale Linux je často pro zkoumání nejjednodušší a pro studenty nejlehčí. Ovšem studenti, kteří nechtějí mít žádné hlubší znalosti OS budou argumentovat tím, že předmět je jen o Linuxu. Ono velká část řeší jen zkoušku s minimem energie, takže ti nejhorší opisují taháky od těch nejhorších z minulých let a vlastní závity vůbec nezapojí. tento předmět jsem bral spíš jako oddechový, v jiném se snažíme, aby takoví neprošli.

Jinak v současné době jsem zavalený požadavky na konzultace různých embedded projektů od firem, protože často z důvodu ceny platformy a vývojových nákladů volí Linux, často i tam, kde bych já i uvažoval, jestli není alternativa. V podstatě každá televize dnes používá boot systému, který jsme studentům ukazovali, jak si poskládat. Linuxové jádro (a nešťastně založený BIONIC based userspace) je na 70 až 80% "chytrých" telefonů. Opět 90% studentů nechce vědět, co se v té krabičce děje.

Hezky problémy kolem našeho předmětu zhodnotil kolega, který by sice byl lepším učitelem než já, ale raději z vědecké sféry odešel do vývoje ve firmách. ten řekl, vždyť předmět má v názvu PROGRAMOVÁNÍ, tak by o programování měl také být. Jinak je to člověk, ketrý pracuje především na vyšších úrovních (Qt) a tak, ale popis toho, jak systém chodí v nižších vrstvách si ode mě v populární podobě poslechne extrémně rád.

[koroptev]

Hm, a clovek by rekl, ze z pohledu budoucich mozku je na "open source programovani" zajimavy jediny - novy modely toho, jak ve svete, kde neco jako fenomen OS existuje, jeho prostrednictvim vydelat penize (tozn. dat tomu jinej nez charitativni smysl); treba tim, ze se to bude studovat na jiz uspesnejch fungujicich projektech; a ty si tu stezujez, zes jim cpal nejaky picoviny o hw a pollingu a ze se to nelibilo.. jak to proboha s OS souvisi?

[Pavel Píša]

Jestli to není míněno jako ironie, tak Linux je jeden z nejúspěšnějších/nejrozšířenějších OS, RedHat také není v červených číslech a polling, nebo spíš epoll je jedna část řešení základních problémů aplikací, cloudu a vůbec všech, kde jde o výkon. Další je paralelizmus, RCU a dobré datové struktury, koplátor a schopnost využít specializované architektury, viz pokusy s PostgreSQL v kombinaci s akcelerací zpracování na GPU. Jinak FPGA, u grafiky již o nutnosti GPU a paralelizmu nepochybuje nikdo. Ti co pak vymýšlí tyto technologie, kompilátory atd. posunují svět dopředu.

[koroptev]

Takze linux je jeden z uspesnych os projektu a protoze je hned nad hw tak je logicke ze predmet ktery se zove os programovani bude o z tveho pohledu tom skutecnem programovani cili nejaky low level picoviny. Jsi schopen vnimat ze nekdo muze videt mezi nazvem toho predmetu a tim co tlacis znacny nesoulad? To nemusi byt nutne tsk ze vsichni okolo jsou uplne blbi a proto te nechapou.

[nyan]

jeho prostrednictvim vydelat penize

Uhhh... OS neni o charite, a neni ani o vydelavani penez (i kdyz tohle me u pubertaku neprekvapuje, taky sem v 15ti hledal vsude rychly prachy..). OS je hlavne o spolupraci (se zakazniky i konkurenci) a dlouhodobem setreni $$$ a problemu. Jestli chcete rychly prachy, zkuste treba loterii... mozna by tohle nekdo tem budoucim mozkum mohl vysvetlit.

na jiz uspesnejch fungujicich projektech

Uspesnejch v jakem smyslu ? kernel je "uspesny", ale ze by byl Linus miliardar, tak o tom sem neslysel.. jak rikam, jestli chcete rychle a pohodlne zbohatnout, tak programovani asi neni pro vas...

jak to proboha s OS souvisi

Jak souvisi hw a polling s OS... asi nijak. Teda krom toho ze je snazsi to ukazovat na OS. Jestli se ptate proc je treba vedet low-level veci, tak treba proto ze pokud chcete psat opravdu efektivni programy, musite dobre znat minimalne o vrstvu niz nez v ktere delate, plus neco o hardwaru. Samozrejme, asi spousta lidi nechce psat efektivni programy - v tom pripade samozrejme muzete byt programatorsky McDonald a smazit hranolceky v php / javascriptu do konce zivota. Jak je libo..

Kazdopadne, byt ja ucitelem, tak svym studentum asi rychle vytriskam z hlavy tu blbost ze s OS lze zbohatnout. Jo, podarilo se to asi trem lidem na cele planete, coz je statisticky mnohem horsi nez loterie

[koroptev]

Proc 1.) davas rovnitko mezi vydelat penize a rychly prachy? 2.) vnimas uspech pejorativne jako rychly napakovani? 3.) davas mi do huby neco co jsrm nerekl- (ona veta s jestli a proc) a vubec ti nevadi tvoje "nijak" kterym reagujed na muj podiv..

Fyi - z urciteho pohledu nejsou penize nic jineho nez explicitni vyjadreni zajmu, ten tvuj pohled je takovy ten mix detske naivity a dogmatismu volicu svobodnych

[little.owl]

jako záchytná šance pro ty, kdo opravdu mají problém něco naprogramovat.

To uz je to ted tak spatne, ze neni mozne takoveho studenta z ruznych duvodu jednoduse nenechat projit?

[petr]

Problém je, že školy dostávají peníze za studenta, takže na některých školách (i technických, nebudu jmenovat, ale na jedné z takových vedu cvičení, takže vidím tu úroveň) je snaha jich mít co nejvíce i za cenu toho, že se za poslední roky značně snížily nároky, a tedy i průměrné znalosti absolventů. Bohužel tím trpí zejména ti dobří studenti, kterým se nemůžeme dostatečně věnovat, protože se musí brát ohled i na ty horší.

[Pavel Píša]

Řekl bych, že ani peníze minimálně z pohledu naší katedry nejsou tím důvodem, proč se nenechá ze studentů dostudovat jen těch (60% nebo při trochu přísnějším pohledu 20%) skutečně pro programování nebo jinou počítačově orientovanou odbornou činnost vhodných studentů.

Na naší katedře představoval podíl z výuky na celkovém příjmu za rok 2015 16%, v minulých letech to bylo podobné, dlouhodobě podíl klesá. Co se týče času spotřebovaného na výuku, tak zadání vedení je spíše ho v předmětech omezovat a soustředit se na zapojení schopných studentů do projektů. Přesto jsem přesvědčený, že množství času investovaného do výuky je u nás výrazně vyšší než odpovídá financování, protože máme zájem studentům znalosti předat. Takže výuka je u nás zásadním způsobem dotovaná z projektů (grantů, spolupráce s firmami jak v oblasti výzkumu, tak řešení konkrétních zakázek, oboje často s požadavkem zadavatelů na použití Linuxu).

Problém tedy je, že je spíš opravdu schopných lidí nedostatek, pokud pak má takový student zvládnout i teoretické předměty (např. matematika, optimalizace, teorie řízení atd. a sám považuji jak znalosti, tak schopnost v teoretických oblastech myslet a cvičit si mozek za určitě důležitější než jen čisté programování), tak studentů, kteří by dobře obstáli ve všech těchto oblastech zbude málo. Takže za sebe chci, aby se udržela laťka během bakalářského studia (i to je v oblasti počítačových znalostí hodnocené velkým odporem) a v magisterském studiu jsem spíš pro to zlepšit často na tristním stavu, co se dá. O to jsme se v předmětu snažili.

Jinak hlad po absolventech je velký a mnohokrát jsem vedl závěrečné práce studentů, kteří naráželi na strop svých schopností. Ale ke mě se hlásili lidi, co měli zájem a za této podmínky se dokázali vypracovat. Občas sice po letech lamentujeme, když po nich musíme nějaký kód, který má jít do průmyslu, přepsat, ale celkově nám pomohli, přispěli nenahraditelnou měrou k tomu, že se projekty podařilo zvládnout.

Většina těch, co s námi na projektech pracovala (ať byli již špičkoví, nebo se museli hodně snažit) si pak ve firmách, kam nastoupí získá pozici špičkových expertů a nebo nakonec vede vývoj, protože lidí se znalostmi je nedostatek.

[nyan]

predmet byl za hranou low level.

epoll je za hranou low level ? a co je pak kernel ? podzemni level ?

Clovece ti dnesni hipsteri...

[R]

CoreBoot na nich!

[Jardík]

On zas ten epoll (hlavně ten) a kevent není takový zázrak. Pokud není deskriptorů mnoho. Třeba případ GUI aplikace v Qt/GTK, co se nepřipojuje nikam do těch internetů, tak je potřeba 1 X11 socket, pak řekněme 1 eventfd či roura jako nějaký wakeup event pro nějakou frontu s eventy, pak možná ještě jeden na filesystem notifikace a když to používá šmejďárnu dbus, tak na dbus. To jsou 4 deskriptory a je mnohem lepší na ně použít poll(), než se starat o epoll, kevent a hlavně při odebírání a přidávání deskriptorů nebudete mít víceméně žádné race condition (např. při odebrání deskroptoru z epollu musíte v O(n), kde n je počet "ready" deskriptorů, projít seznam a vyhodit deskriptor, nebo se uchýlit k plácání paměti a udržovat nějaké pole na O(1) přístup (některé ty libevent knihovny to tak dělají, tj pro deskriptor 0 a 1_256_254 potřebuje 10 MB paměti jen na pointery, z nichž je většina 0). Obyčejný poll() se tak hodí pro případy malého množství deskriptorů a případy, kdy se často daný set mění. A vždycky jde pak epoll deskriptor kydnout do pollu do seznamu, když potřebuju integrovat něco super síťařsky náročného s miliónem připojení.

Co se týče animací, nesnáším je. Taky nesnáším ten moderný "flat" styl všude. Já se pak v ničem nevyznám. Dodnes se mi nejvíce líbí ten Win2k-like styl GUI, který je rychlý, je to všechno přehledně oddělené, a žádný debilní animace. Jediné, co mě neuráží je nějaký stín pod oknem, to je užiteční pro přehlednost, alespoň pro mě.

[Pavel Píša]

Epoll si umožňuje do jádra uložit pointer, takže vyhledání datové struktury k danému přenosu je O1. Jinak epoll různé chyby má, je třeba potřeba hlídat, že se do jednoho epollu nezařadí jeden deskriptor dvakrát, takže je potřeba mít seznam deskriptorů. Sám jsem si knihovnu pro různé event mechanismy v době, kdy libevent pořádně napsaná pro více pollů ve více vláknech nebyla, a nikde pole neudržuji.

Jen pro možnost nezávislé registrace na jeden FD (např. RD a WR) tam mám AVL podle deskriptorů. Ale to se řeší jen při zakládání a rušení eventů. Nikoliv při jejich používání.

API je pak udělané tak, že umožnuje různé mechanismy zanořovat do sebe. Třeba dole z nutnosti mít GLIB main, jako jednu jeho položku zaregistrovat epoll a pod ním mít velké množtví událostí.

Jinak souhlasím s tím, že pro GUI je poll OK. Select je problematičtější, může sejít v aplikaci s jiným vláknem, které zpracovává tisíce událostí, a pak je problém.

Zajímavé ale je, že pro případy, kdy jsou události aktivované téměř všechny naráz, tak naopak select na Linuxu vychází překvapivě dobře. Jinak FD_SETSIZE je jen konstrukce userspace, jádro zvládá přes select pracovat i s 10000 spojeními. Opět řešení bez omezení jsem otestoval v knihovně uLevPoll

https://sourceforge.net/p/ulan/ulevpoll/ci/master/tree/

Koncepce řetězení a integrace do GLIB a libevent1/2 je na ní celkem unikátní, kdyby její API měla GLIB, tak by jedno ošklivé omezení odpadlo. Ale v dnešní době je libevent2 daleko dále, nabízí koncept streamů, SSL atd.

Můj pokus byl spíš pro malé embedded věci s tím, aby na velkých systémech šlo bez změn kódu použít právě i libevent nebo něco lepšího.

[Jardík]

Do epoll struktury sice pointer uložíte, takže při procházení ready eventů je opravdu přístup O(1), ale bohužel při odstraňování z epollu musíte tento seznam projít lineárně a odstranit položku z těch ready eventů, jinak vám tam bude váznout. Pokud to bude chtít v O(1), budete muset přidat další pointer indirekci (české slovo) a "plácat pamětí", dokud nenarazíte na takto za smazaný poznačený objekt a pak ho odstranit. Nikdy totiž nevíte index v tomto seznamu. Naopak při použití poll() vždy víte přesný index, na druhou stranu lineárně procházíte po pollu všechny, i nepřeipravené, položky. S desítkami položek je to však úplně zanedbatelné, více méně u obou případů. Problém je to ale s hodně deskriptory. Nevím přesně, jak je to s libevent2, nejsem si jistý u které knihovny jsem to viděl (libev, libuv), ale prakticky udržovali mapu deskriptor->data, kde deskriptor byl index do toho pole, takže to bylo O(1), a dokonce tam byl i nějaký fixní limit na maximální hodnotu deskriptoru (která může být po použití pár systémových volání o hodně větší, než jejich předpoklad). Dá se to nazvat plácáním pamětí, ale to dnes dělá skoro každý program, bohužel. A hájí se výmluvou "paměti je dost".

[Pavel Píša]

Zkuste se podívat, jak jsem specializaci svého obecného API pro epoll() napsal při svém pokusu:

https://sourceforge.net/p/ulan/ulevpoll/ci/master/tree/ulevpoll/ul_evp_lnxepoll.c

https://sourceforge.net/p/ulan/ulevpoll/ci/master/tree/ulevpoll/ul_evp_lnxepoll.h

Pokud si vzpomínám, tak jsem tam žádný problém, který popisujete neměl. Indirekce tam je ale vícenásobná. jako eventy se registrují specializované struktury ul_evptrig_lnxepoll_t. Vytváří se při volání API fukce ul_evptrig_init() pro danou bázi (pokud byla báze založená pro mechanizmus epoll). Tato data se přímo do epollu neregistrují, protože epoll by neumožnil nezávisle registrovat samostatné události pro read a write na jedno FD. Proto se registrují až objekty ul_evplnxepoll_fdnode_t. Ty jsou setříděné v AVL stromu, takže při registraci eventu dojde k vyhlednání nodu v AVL podle FD. Pokud se nenajde, tak se nód založí. Z nodu jsou pak event struktury při příchodu události dostupné v doble-linked listu. Při rušení, příchodu události atd. se již vždy jde přímo podle ukazatelů, znova se nehledá. Pouze při rušení se vyhazuje z AVL stromu a rebalancuje se. I když můj generalizovaný AVL strom umožňuje i balancování při rušení nedělat za cenu degradace AVL s tím že během dalších insertů se to strochu dorovná. Ale to dobře chodí jen pro odsekávání prvního nebo posledního prvku, kdy to v reálných případech může vést jen k zvýšení počtu úrovní o jedno.

Jestli máte čas, tak zkuste můj kód projít, jestli tam opravdu náhodou problém není, případně zkuste výkonnost, když si nějakou Vaší aplikace na toto API přepíšete.

Myslím ale, že libevent2 na tom bude lépe. Co jsem jí zkoumal, tak také žádné rozsáhlé pole k epoll neudržuje a je v pořádku.

Můj kód má celkem zásadní omezení, že je postavený jako náhrada pro klasické použití pollu, z toho důvodu při setrvání události v aktivním stavu stále dokola vyvolává odpovídající trigger/handler. Pokud se posune řešení na vyšší úroveň streamů (libevent2 tuto alternativu obsahuje), tak lze epoll použít v režimu edge triggered událostí, kdy bude overhead menší. Bohužel pro obecné použití bych ve svém kódu musel vždy po návratu handleru kontrolovat třeba pollem, jestli handler obsloužil/vyčetl všechna data a pokud ne, tak si poznačit, že událost se má v příštím cyklu znova vyvolat, přesto, že z epollu hlášená není. Další určitá chyba je, že nemám zatím implementované priority. Počítám spíš s tím, že pro každou prioritu bude založená jiná smyčka v samostatném vlákně. V oblasti RT je to stejně nejlepší cesta, jak umožnit plánovači do zátěže a jejích potřeb vidět. Ale moje řešení nemusí být ani spravedlivé při více klientech obsluhovaných v jedné smyčce.

Dokumentace k mému neumělému pokusu je zde http://ulan.sourceforge.net/pdf/ulevpoll.pdf. Je v ní moc překlepů, měl bych si udělat čas, a vyčistit to. Patche proti DocBook zdrojovému textu v GITu vítané. No možná se na to podívám i dnes, když vidím, jak to roky dělá ostudu.

[Jardík]

Určitě se na to podívám. Já neměl potřebu registrovat zvlášť read a write, takže mé řešení bylo velmi jednoduché. Prostě jsem měl malou strukturu, kde byl fd, callback a userdata předávaná callbacku. Pointer se uložil do epoll_event při registraci, po epoll_wait se prostě volaly jednotlivé callbacky. Při mazání se fd nastavil na -1, pole pro userdata se využilo jako link do seznamu odebraných položek. Když se při procházení ready eventů narazila na ten s fd -1, tak se přeskočil. Až se došlo na konec, tak se prošel seznam odebraných položek a teprve poté se volal free(), popř. další verze, kde se recyklovaly pro další použití. To je to "plácán pamětí", o kterém jsem mluvil. Položku prostě nelze uvolnit, když stále procházíte seznam ready položek, kde by mohla být a nechcete ho procházet v O(n). Při použití poll() jsem mohl mít dvě pole, jedno bylo pollfd struktur, v druhém byl callback pro danou položku. Odebrání i přidání bylo O(1), pollování pak ale samozřejmě náročnější na zdroje. Hlavně ale byla jistota, že struktura už není dále použitá a její vlastnictví tak může být ponecháno uživateli knihovny. Kdežto v případě epollu() musí vlastnictví udržovat knihovna, kvůli tomu, že i po odebrání může být do struktury přistupováno. Mým původním záměrem totiž bylo, že knihovna nic alokovat nebude, popř. jen minimum, a všechny předávané objekty vlastní uživatel a on si musí zajistit správnou životnost. Knihovna ho neměla omezovat v tom, jestli bude alokace na heapu, nebo na stacku.

[tacoberu]

Mi třeba v takovém Gnome 2 nic nechybělo. Proč se přešlo na Gnome 3 a neustálé změny API nikdy nepochopím. Asi jsem moc starý. Jsem dalece jim nařizovat aby dělali něco, co mi bude vyhovovat. Jen těm změnám pro změny prostě nerozumím.

Pro mě byl přechod z Gnome2 na Gnome3 (GnomeShell) absolutní wow, a subjektivně mi to zpohodlnělo práci aspoň o řád.

A to se, obávám, řadím do té skupiny seniorů, nehračiček. Začínal jsem na RH2.6.

[little.owl]

Podobne, Linux od 1995. Prosel jsem od twm, fvwm, WindowMaker pres prvni vyvojove verze Gnome ci KDE, a dale.
Prechod z Gnome 2 na Gnome 3 byl pro me pozitivni krok vpred, jak z hlediska ergonomie, tak z hlediska moznosti rozsireni. Ted kdyz zkusim treba soucasne MATE, nechapu jak jsem v tom mohl vydrzet.

[Václav "Darm" Novák]

Pro mě byl tohle i přechod z KDE 3.5 na KDE 4 (po odladění chyb) a Plasma 5. Ale teď jsem přešel na GNOME shell a nějak se mi to zalíbilo.

[Bedňa]

Gnome3 má jeden problém a to že téma nevydrží viac ako pár mesiacov a potom ju niečo rozbije aj v stotinkovej verzií a ako sa nechali Gnomáci počuť, im to proste nevadí. Oni nemajú záujem aby si niekto tvoril svoje témy. Tam už medzi slobodným kódom a uzavretou šmejďárnou rozdieľ nevidím.

[Jardík]

Já Gnome 3 a ani dnes GTK 3 aplikacím nemohu přijít na chuť. Hlavně těma tlačítkama v titulku mě nutí pořád jezdit myší všude. Jsem zvyklý dělat od shora dolů a když pak mám dialog potvrdit nahoře, vadí mi to. A pak zprznění některých dialogů. Dnes je font dialog z GTK nepoužitelný nepřehledný pomalý bastl, naštěstí he nemusím používat často. Color dialog taky nepoužitelný. Pro rychlou práci potřebuji taskbar. Nesnáším miniatury okýnek. S taskbarem můžu koukat na porno a až někdo přijde, hodim to dolů a nemusím se bát, že když se budu potřebovat přepnout do jiné aplikace, tak někdo uvidí, na co čučim.

[Bedňa]

A keby si používal nejaký alternatívny EWMH WM, tak ti ešte prebijú jeho nastavenia, to je fakt hnus velebnosti, kurwa na čo sa robia tie štandarty?

Náš administrátor shledal tento komentář závadným.

ad hominem

Zobrazit komentář

[Jardík]

LXDE bývalo/je slušné prostředí. Bohužel o LXQt se to říci nedá. Hlavně kvůli nabalení tuny závislostí na KDE knihovnách. File manager v Qt si tahá závislost na glib.

[chrono]

File manager v Qt si tahá závislost na glib.

Pravdepodobne kvôli DBus.

[Pavel Píša]

Ne, Qt na Linuxu kvůli integraci služeb nad Glib do hlavní smyčky musí používat parodii na event driven zpracování událostí, kterou nabízí Glib. Qt je alespoň napsané tak, že jeho abstrakce lze napasovat nad různá řešení.

Glib má API natolik špatné a vystavující interní implementaci ven, že s ničím jiným než voláním poll() v podstatě nejde kompatibilitu zajistit.

Takže o něco lepší Qt se přizpůsobuje nejhoršímu společnému jmenovateli, návrhu API.

[Jardík]

Glib integrace bývávala volitelná, už je tam na pevno? Jinak problém s tím filemanagerem je jiný, a to ten, že všechny operace nad soubory používaly (a asi pořád používají) GIO.

[Pavel Píša]

V Qt je to určitě volitelné, ale myslím, že si to žádná distribuce nedovolí vypnout. Ale zase takový přehled mezi všemi distribucemi nemám, takže je to možné. Ale pak nepůjde integrovat knihovny dohromady.

[Rezza]

A zrovna ty KDE Frameworks si v tom bashing clanku a komentarich strasne pochvaluje. A nebo by si meli radsi napsat dalsi novy toolkit a zacit uplne od nuly?

[koroptev]

Nemel, je fajn, kdyz se deti zabavej a nefetujou.

[Jardík]

Otázkou je, proč ten KDE frameworks používat. K čemu ho potřebují? Když dám instalovat lxqt a vyskočí na mě 200 závislostí z KDE, chce se mi brečet.

[Rezza]

Takze kdyby ten kod vzali a udelali copy/paste do jejich kodu, tak by to uz bylo ok? Proc to potrebuji? Protoze to neco dela, co autori povazuji za featuru jejich desktopu hodnou. A maji na vyber - bud pouzit hotovou knihovnu nebo si to napsat sami.

[little.owl]

Jde o to, ze to do znacne miry popira puvodni zamer LXDE - ono 'Lightweight', LXQT bych v soucasnosti uz za lightweight nepovazoval - minimalozvane KDE bude asi srovnatelne.

[Rezza]

Me to prave prijde jako celkem minimalisticke, prave az moc. Jen nechapu, ze pro nekoho minimalisticke znamena mit vsechno nejlepe staticky slinkovane v jedne binarce :).

Pravidelne zkousim, kdyz delam me zkousky pouzitelnosti jinych desktopu (a vetsinou jsem do hodiny zpet na Plasme, at me stve, jak me stve .

[Dirka]

Ono je to ale spis o te ktere distribuci, ne?

emerge -pv lxqt-panel lxqt-session lxqt-runner lxqt-common

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  NS    ] dev-qt/qtscript-5.6.1:5/5.6::gentoo [4.8.6-r2:4::gentoo] USE="-debug jit -scripttools {-test}" 2,528 KiB
[ebuild  N     ] virtual/eject-0::gentoo  0 KiB
[ebuild  N     ] dev-libs/libgudev-230::gentoo  USE="-debug -introspection -static-libs" 252 KiB
[ebuild  N     ] dev-libs/libatasmart-0.19-r1::gentoo  USE="-static-libs" 252 KiB
[ebuild  N     ] virtual/libgudev-230::gentoo  USE="-introspection -static-libs" 0 KiB
[ebuild  N     ] sys-fs/udisks-2.1.7:2::gentoo  USE="acl -cryptsetup -debug -gptfdisk introspection (-selinux) -systemd" 899 KiB
[ebuild  N     ] kde-frameworks/kf-env-3:5::gentoo  0 KiB
[ebuild  N     ] kde-frameworks/extra-cmake-modules-5.23.0:5/5.23::gentoo  USE="-doc {-test}" 279 KiB
[ebuild  N     ] dev-qt/qtx11extras-5.6.1:5/5.6::gentoo  USE="-debug {-test}" 33 KiB
[ebuild  N     ] kde-frameworks/kwindowsystem-5.23.0:5/5.23::gentoo  USE="X -debug nls {-test}" 161 KiB
[ebuild  NS    ] dev-qt/qtsvg-5.6.1:5/5.6::gentoo [4.8.6-r1:4::gentoo] USE="-debug {-test}" 1,683 KiB
[ebuild  N     ] kde-frameworks/kguiaddons-5.23.0:5/5.23::gentoo  USE="-debug {-test}" 39 KiB
[ebuild  N    ~] dev-libs/libqtxdg-2.0.0::gentoo  USE="{-test}" 61 KiB
[ebuild  N     ] kde-frameworks/solid-5.23.0:5/5.23::gentoo  USE="-debug nls {-test}" 262 KiB
[ebuild  N    ~] lxqt-base/liblxqt-0.10.0::gentoo  76 KiB
[ebuild  N    ~] lxqt-base/lxqt-globalkeys-0.10.0::gentoo  51 KiB
[ebuild  N    ~] lxqt-base/lxqt-panel-0.10.0-r1::gentoo  USE="alsa clock -colorpicker -cpuload desktopswitch -dom kbindicator mainmenu mount -networkmonitor -pulseaudio quicklaunch -screensaver -sensors showdesktop -statusnotifier -sysstat taskbar tray volume -worldclock" 323 KiB
[ebuild  N    ~] lxqt-base/lxqt-runner-0.10.0::gentoo  189 KiB
[ebuild  N    ~] lxqt-base/lxqt-common-0.10.0::gentoo  3,893 KiB
[ebuild  N    ~] lxqt-base/lxqt-session-0.10.0::gentoo  64 KiB

Total: 20 packages (18 new, 2 in new slots), Size of downloads: 11,039 KiB

VS

emerge -pv lxqt-meta

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild  N     ] dev-libs/wayland-1.11.0::gentoo  USE="-doc -static-libs" 366 KiB
[ebuild  NS    ] dev-qt/qtscript-5.6.1:5/5.6::gentoo [4.8.6-r2:4::gentoo] USE="-debug jit -scripttools {-test}" 2,528 KiB
[ebuild  N     ] virtual/eject-0::gentoo  0 KiB
[ebuild  N     ] dev-libs/libgudev-230::gentoo  USE="-debug -introspection -static-libs" 252 KiB
[ebuild  N     ] dev-libs/libatasmart-0.19-r1::gentoo  USE="-static-libs" 252 KiB
[ebuild  N     ] virtual/libgudev-230::gentoo  USE="-introspection -static-libs" 0 KiB
[ebuild  N     ] sys-fs/udisks-2.1.7:2::gentoo  USE="acl -cryptsetup -debug -gptfdisk introspection (-selinux) -systemd" 899 KiB
[ebuild  N     ] kde-frameworks/kf-env-3:5::gentoo  0 KiB
[ebuild  N     ] kde-frameworks/extra-cmake-modules-5.23.0:5/5.23::gentoo  USE="-doc {-test}" 279 KiB
[ebuild  N     ] kde-frameworks/oxygen-icons-5.23.0:5/5.23::gentoo  USE="{-test}" 227,826 KiB
[ebuild  N     ] dev-qt/qtx11extras-5.6.1:5/5.6::gentoo  USE="-debug {-test}" 33 KiB
[ebuild  N     ] kde-frameworks/kwayland-5.23.0:5/5.23::gentoo  USE="-debug {-test}" 205 KiB
[ebuild  N     ] kde-frameworks/kwindowsystem-5.23.0:5/5.23::gentoo  USE="X -debug nls {-test}" 161 KiB
[ebuild  NS    ] dev-qt/qtsvg-5.6.1:5/5.6::gentoo [4.8.6-r1:4::gentoo] USE="-debug {-test}" 1,683 KiB
[ebuild  N    ~] x11-misc/obconf-qt-0.9.0_p20150729::gentoo  95 KiB
[ebuild  N     ] kde-frameworks/kguiaddons-5.23.0:5/5.23::gentoo  USE="-debug {-test}" 39 KiB
[ebuild   R    ] dev-libs/libdbusmenu-qt-0.9.3_pre20140619-r1::gentoo  USE="-debug -doc qt4 qt5* {-test}" 46 KiB
[ebuild  N     ] kde-plasma/libkscreen-5.6.5-r1:5/7::gentoo  USE="X -debug {-test}" 82 KiB
[ebuild  N     ] sys-auth/polkit-qt-0.112.0-r1::gentoo  USE="-debug -examples qt4 qt5" 67 KiB
[ebuild  N    ~] dev-libs/libqtxdg-2.0.0::gentoo  USE="{-test}" 61 KiB
[ebuild  N     ] kde-frameworks/solid-5.23.0:5/5.23::gentoo  USE="-debug nls {-test}" 262 KiB
[ebuild  N    ~] lxqt-base/liblxqt-0.10.0::gentoo  76 KiB
[ebuild  N    ~] lxqt-base/lxqt-globalkeys-0.10.0::gentoo  51 KiB
[ebuild  N    ~] lxqt-base/lxqt-policykit-0.10.0::gentoo  15 KiB
[ebuild  N    ~] lxqt-base/lxqt-config-0.10.0::gentoo  151 KiB
[ebuild  N    ~] lxqt-base/lxqt-qtplugin-0.10.0::gentoo  21 KiB
[ebuild  N    ~] lxqt-base/lxqt-about-0.10.0::gentoo  30 KiB
[ebuild  N    ~] x11-misc/pcmanfm-qt-0.10.0::gentoo  224 KiB
[ebuild  N    ~] lxqt-base/lxqt-panel-0.10.0-r1::gentoo  USE="alsa clock -colorpicker -cpuload desktopswitch -dom kbindicator mainmenu mount -networkmonitor -pulseaudio quicklaunch -screensaver -sensors showdesktop -statusnotifier -sysstat taskbar tray volume -worldclock" 323 KiB
[ebuild  N    ~] lxqt-base/lxqt-runner-0.10.0::gentoo  189 KiB
[ebuild  N    ~] lxqt-base/lxqt-common-0.10.0::gentoo  3,893 KiB
[ebuild  N    ~] lxqt-base/lxqt-session-0.10.0::gentoo  64 KiB
[ebuild  N    ~] lxqt-base/lxqt-notificationd-0.10.0::gentoo  31 KiB
[ebuild  N    ~] lxqt-base/lxqt-meta-0.10.0::gentoo  USE="about -admin filemanager icons -lightdm -lximage -minimal oxygen policykit -powermanagement -sddm -ssh-askpass -sudo" 0 KiB

Total: 34 packages (31 new, 2 in new slots, 1 reinstall), Size of downloads: 240,192 KiB

Nicmene koukam, ze 227 MB v tom meta jsou temata/ikony heh ... jinak zadny KDE knihovny v systemu nemam, Qt 5.6 naky jo ... i tak doufam, ze nadosmrti zustanu u lxde :)

[koroptev]

Jj, linuxovy tema c.1 je stale stejny a nemenny: Stopadesata prvni ta zarucene nejlepsi verze grafickyho rozhrani ktera uz konecne zpusobi ten velkej desktopovej tresk..

[smutik]

No a stale nic, skoda. To neustale vyrabanie noveho kolesa je len zbytocne plytvanie silami na hovadiny.

[skywaker]

súhlasim s vyšie nazorom. stále dookola. linux je fajn nahodíš si to na Raspberry s autoštart do Kodi a máš chytrú telku, nahodíš to na NAS a máš nazdielane dáta ale u desktopu aby si človek ktorý chce stabilitu uhladal to tak ze radsej nahodi LTS verziu distribucie koli stabilite updatov a s vedomim ze to LXDE vydrzi do 2019 :D :D :D

svojho času som poškuľoval po HAIKU, aaa musim povedat aj ReactOSu sa moj disk dotkol a nie len jeho bolo tu aj eComstation sosnuté odniekial z webu rozdiel oproti Linuxu je ten ze u Linuxu sa vsetko meni z roka na rok... ci este skor? nazvyme to generacia distribucii. pekne to vydiet u debiana ten ked vyjde tak ma vzdy novsie KDE v danej dobe :D postupom casu som dosiel k pochopeniu ludi ktory pouzivaju DWM,i3,flux (sam ho mam v oblube)preco tak spravili !

[maja]

Lubuntu lxqt opet odklada... LXQt images are postponed until 17.04.

[little.owl]

Zadny div, kdyz jim to ted pres zavislosti natahne pul KDE, vcetne Plasmy ... .

[Rezza]

A proc by to melo tahat Plasmu?

[little.owl]

Hadam, ze nevyresene zavislosti, maji to jako znamy bug.