Plasma 5.5 je zabugovaná jak prase

23.1.2016 10:02 | Přečteno: 2296× | Co se týká počítačů | poslední úprava: 23.1.2016 10:02

Tak si tak dneska ráno zapnu pc, nic zlýho netuše a uvítá mě tento krásný efekt (následuje screen v 1920x1080)... Pomohlo až úplný vypnutí kompozitoru, sice to vypadá hnusně protože nefunguje průhlednost, ale dá se to aspoň používat. Zajímavý že s předchozí verzí to tak neblblo, dokonce to neblblo ani s tou 5.5 hned po upgradu. To až teď. Jinak starej bug s tim že když se zavře okno konsole křížkem tak tam ten proces zůstane viset a žere 100% cpu tam je furt. A prej to dělá jen na nvidii s binárnim driverem (z toho mam neblahý tušení že lidi od kde/plasmy se na to vyserou jelikož u nich to rozbitý neni). Což je přesně to co mám...

Některý bugy kompozitoru kvůli kterym padal kwin nebo celá plasma v předchozí verzi už sem zmiňoval v diskuzi pod svym současnym desktopem.

       

Obrázky

Komentáře

[kotyz]

No zprvu sem měl nahnáno že odešla grafika a budu muset koupit novou, ale tý nic neni. Všechny aktuální i starší screeny relevantní k bugům plasmy na který sem narazil jsou zde.

Kdyby byl někdo zvědavej na další podrobnosti, ať se zeptá v diskuzi. Během tejdne chci nainstalovat ještě Arch a uvidim jestli to v něm bude bugovat stejně jako v Kubuntu...

[kralyk z abclinuxu]

Tyhle chyby je obecně občas hroznej problém dohledat, Plasma vůbec nemusí nakonec být na vině. Tipoval bych bugu v driverech grafiky. Onehdá jsem měl podobný problém a mohl za to nějaký deadlock v nvidia driveru. Mrkni se, jestli máš ten nejaktuálnější.

Podobnej problém (rozpadlost GUI Qt aplikací) mi taky nedávno způsobila - dosti nepochopitelně - Java. Viz vlákno.

[kotyz]

s nouveau to nebuguje a to ani když nastavim kompozitor na opengl (předtim s blobem sem to měl nastavený na xrender aby to nepadalo a nakonec sem ho musel vypnout úplně). ale ideální to taky neni, zase nefungujou jiný věci, asi kvůli slabý 3d akceleraci, ikdyž na nv50 už je prej hotová...

[mimi.vx]

Vyvojari Plamsy uz celkem dávno prohlásili že serou dělat workaroundy na bugy v driverech ... A mají pravdu že toto je práce nekoho jineho.

Ono udrzovat v kodu kvanta workaroundu jen kvuli tomu ze nekdo jiny neodvede dobre svou praci je cesta do pekel

[kyknos]

vysledkem je, ze to uzivateli nefunguje, skvela strategie

zlaty xfce, nedaji se na to balit tepli geekove, ale funguje to :)

[xkucf03]

-1

Chyby se mají opravovat tam, kde se nacházejí – ne zasírat jiné programy kódem, který ty cizí chyby obchází.

[kyknos]

jako uzivatele me zajima jen jedina vec - zda software dobre a spolehlive funguje

[kralyk z abclinuxu]

To, že nefunguje dobře a spolehlivě, bylo řečeno už v zápisku, takže úplně nevim, co řešíš, pro tebe to je tím pádem vyřízený a nemusíš už zasahovat do diskuse. Zbytek můžeš nechat nám, co řešíme, kde ta chyba nastala...

[kyknos]

nemusim, ale muzu, ze ano?

[tydýt]

nemusíš mi ho strkat do prdele, ale já chci!

[Agent]

Nepovídej. To by nikdo nečekal. Tak hlavně, že to víme. Ještě něco, co bychom měli vědět? Ne, dělám si prdel. Nic ve zlým.

[nyan]

vysledkem je, ze to uzivateli nefunguje, skvela strategie

Zato tvoje strategie, koupit si nvidii, pak nacpat do kernelu multimega binarni driver, a pak si stezovat na Plasmu na chyby v te binarni sr*cce, je bez chyby.

Koupil sis nvidii, na kterou furt vsichni spilaji jakej ma uzasni bezchybni driver, tak si to ted hezky vyzer... pripadne muzes nahlasit buga nvidii, mozna ti ho opravi :))))

Priste si kup hardware kde vyrobce dela/podporuje FOSS drivery, a nebudes muset omlouvat vlastni blbost trapnymi blogy.

[Fluttershy, yay!]

To asi neměla být tak docela reakce zrovna na kyknose…?

[kyknos]

ja jsem si koupil nvidii? :D

[xkucf03]

To nevím, ale doporučuješ opravovat (resp. obcházet) chyby někde jinde, než vznikají, a fixovat ten špatný stav.

[kyknos]

doporucuji vyvojarum dodavat funkcni produkt a nevymlouvat se, ze za nefunkcnost muze nekdo jinej, taky doporucuju nevydavat nove verze s brutalnimi regresemi, jak je bohuzel v KDE, GNOME aj. bezne

no a uzivatelum doporucuji nepouzivat KDE ani GNOME

[xkucf03]

doporucuji vyvojarum dodavat funkcni produkt a nevymlouvat se, ze za nefunkcnost muze nekdo jinej

Takže když budou vadné RAM moduly, má si aplikace řešit opravy chyb sama a nevymlouvat se? Nebo když je vadný disk či implementace FS a po uložení půlka souborů zmizí – tak si to má aplikace uložit dvakrát a doufat, že tam správná část souborů zůstane, a nevymlouvat se?

BTW: o regresích se často nedá mluvit – když jde o software, který je prakticky napsaný znova – některé funkce chybí, protože je ještě nikdo nenapsal (ne proto, že je někdo odstranil/rozbil) a jiné se chovají jinak/špatně, protože při přepisu byly napsané jinak. Vydávání nedokončeného/neodladěného softwaru se mi taky nelíbí, na tom se shodneme. Ale to je úplně jiná otázka než to, zda budeš nebo nebudeš obcházet chyby, které udělal někdo jiný.

[kyknos]

ano, pokud bude pulka vyrobcu prodavat vadne moduly a budou se bezne pouzivat, musi to slusna aplikace osetrit napriklad pres nejake kontrolni soucty atd.

uzivatele nezajimaji vyvojarske problemy

[MadCatX]

Tenhle přístup, kdy se chyby nebudou opravovat, ale vzájemně ohackovávat nakonec vyústí v pekelný domeček z karet, který nepůjde smysluplně dál rozvíjet, protože každý bude mít strach na to sáhnout. Problémy se musí řešit tam, kde vznikly, jiný přístup je dlouhodobě neudržitelný.

[kyknos]

uzivatele nezajima dlouhodoba udrzitelnost, ale zda sw funguje tady a ted

[MadCatX]

Vývoj složitějšího softwaru trvá několik let, třeba od prvního do posledního vydání KDE 4 uběhlo 7 let. Dlouhodobě spravovatelná codebase je esencální, pokud se má software vůbec někdy dostat do stavu, kdy použitelný bude. Že zákazník chce modré z nebe teď a tady je pravda univerzální téměř ve všech odvětvích. Praxe ukazuje, že technicky nesprávná řešení vývojáře nakonec potopí, čímž bude ve výsledku trpět i uživatel.

[pavlix]

Problém je v tom, že u některých projektů se o tom budoucím stavu, kdy bude software použitelný, jenom mluví. Klidně i roky.

[kyknos]

a u nekterych, jako je KDE nebo GNOME, se na nej vzpomina :)

[pavlix]

Taky pravda. Vzpomínám na verze, co mi vyhovovaly, u obou.

[kotyz]

problém je, že v tomhle stavu se to používat nedá vůbec. prostě to nejde, přes ten černej bordel neni nic vidět. jediný štěstí že se to dá obejít buď vypnutim kompozitoru nebo odinstalovánim binárního driveru. sou to sice suboptimální řešení, ale aspoň fungujou, aspoň do doby než se najde lepší řešení na tom můžu přežívat...

[xkucf03]

Na co potřebuješ binární ovladače? Já jsem používal nouveau, když jsem ještě měl nvidii, a chodilo to celkem dobře, i nějaké hry.

[kotyz]

když pominu 3d aplikace a hry, tak to chodí dobře (framebuffer dokonce líp, ale ten zase tak moc nevyužiju). ale je tam to ale. přestal chodit steam, google earth, v open areně přestalo fungovat nastavení jasu, secondlife má ještě míň fps než měl předtim...

[kotyz]

tak steam opraven, problém byl že je bundlovanej s nějakou starou knihovnou kolidující s mesou a open driverama, closed drivery problém nemají. tohle snad opraví časem valve, tak uvidíme...

[MadCatX]

To samozřejmě problém je, ale toho binárního blobu. Zkoušel's třeba nainstalovat starší verzi? V Archu se dají nalézt ve "/var/cache/pacman/pkg", pokud jsi to ručně nepromazal. Jak přesně jsi ověřil, že ta GK nemá třeba vadnou paměť? Nouveaou tu VRAM nemusí umět spustit na vyšších frekvencích a bez kompozitoru se zase nevyužívá 3D akcelerace, takže se případný HW problém nemusí projevit.

[kotyz]

karta vadná s největší pravděpodobností neni, 3d akcelerace funguje, jen pod nouveau je slabší výkon a pod binárnim driverem se musí vypnout kompozitor aby to nebugovalo (ikdyž předtim to nebugovalo ani s nim, leda s opengl backendem byly nějaký potíže, ale ne takovýhle). já bych spíš řek že nouveau to bude honit pořád na plnejch frekvencích, protože tam neni hotovej power management. v archu sem zatim binární nezkoušel, je to čerstvá instalace a není ještě hotová, bude se toho muset ještě dost doinstalovat a dokonfigurovat a do toho se mi teď moc nechce...

[MadCatX]

Nouveau právě neumí na moderních kartách reclocking, takže ty karty jsou zaseklé ve výchozích taktech, které jsou právě ty nejpomalejší. Pokud byly problémy s OpenGL backendem, je to další indikace, že je něco špatně buď s ovladači, nebo přímo s hardwarem. Pokud je to možné, zkusil bych tu kartu nějak jinak a jinde. Buď udělat nějaký zátěžový test s binárním blobem a nějakou náročnou 3D aplikaci nebo tu kartu dát do jiného stroje, ideálně s Windows.

[MadCatX]

Což IMHO není žádný argument pro to psát software prasácky...

[pavlix]

Ani IMHO.

[xkucf03]

Tohle je velice krátkozraké uvažování a takhle se software vyvíjet nedá. Nakonec se to zbortí, musí se to celé přepsat, vývoj se zastaví, nebo je tak drahý, že to nikdo platit nechce (ať už penězi, vlastním časem nebo čímkoli jiným).

Tímhle způsobem můžeš dělat leda tak jednorázové projekty, třeba podpůrný web k nějaké marketingové akci, který se po pár měsících zahodí a nikoho už nezajímá. Ale ne software, který má sloužit roky a má se dál rozvíjet klidně i desítky let.

[kyknos]

zajimave je, ze windows gui, osx gui, xfce a rada dalsich linuxovych rozhrani normalne funguji a neni s nimi problem :D problem je z nejakeho duvodu jen s GNOME a KDE :D

[xkucf03]

Windows GUI a OS X GUI běží na úplně jiných OS s úplně jinými ovladači, takže to není relevantní. A xfce a různé další WM/DE běží jen ve 2D ne?

[kyknos]

a 2D je malo? popravde receno nechapu, proc do gui nejake 3D cpou... asi by nicemu nevadilo, kdyby fungovalo a neprinaselo problemy...

[xkucf03]

Jestli má smysl 3D desktop je zase na jinou diskusi… ale chtěl jsem tím říct, že když někdo dělá 2D desktop, tak to neznamená, že by byl lepší programátor nebo dělal líp svoji práci, když nemá tyhle problémy – prostě se jen nedostal do situace, aby narazil na problémy způsobené autorem proprietárních ovladačů grafiky. Je to asi jako kdybys celý život žil v lese a připadal si jako velký borec, že tě nikdy nezajelo auto, zatímco ti „blbci ve městech“ s tím mají občas problém (nezbytná analogie s auty).

Jinak OpenGL se dneska používá na kde co, ani to na první pohled není vidět (nevypadá to jako 3D), třeba prohlížení obrázků, protože je to rychlejší. Je efektivnější, když tu práci může udělat optimalizovaný čip na grafice a nemusí ji dělat CPU.

[Grunt]

Tak, tak. Problém není fakt že se používá GPU samo o sobě. Problém je pouze styl jakým je GPU (a příslušný software) vyvíjen, což souvisí s nedostatkem konkurence na trhu (nVidia vs ATi/AMD, teď už spíš pouze nVidia) což zase souvisí s kapitalismem. Představte si že by od začátku podobným stylem vyvíjely a programovaly třeba procesory od Intelu (ten na tuhle dráhu úspěšně nastupuje – polofunkční APCI, to bylo pouze zahřívací kolo). Na tom by GNU/Linux nefungoval pořádně do dnešního dne.

[pavlix]

A které WM/DE běží ve 3D a je to na něm nějak vidět? Jako jo, párkrát jsem si hrál s kostičkou, co měla na každé straně plochu, ale na práci je to k ničemu a existují mnohem lepší 3D hry.

[MadCatX]

Kompizitní desktop má i několik praktických výhod. Mně třeba vyhovují realtime náhledy oken, nedochází k "brázdovému efektu" po zviditelnění části okna aplikace, která se třeba krátkodobě zasekla, v principu může být méně náročný na CPU, protože se více práce offloaduje na GPU. Pracovat se dá i v TWM ve výchozím nastavení, ale ne každý to bude považovat za pohodlné.

[pavlix]

Kompizitní desktop má i několik praktických výhod.

Ptal jsem se na 3D. Myslel jsem, že je význam té zkratky všeobecně známý, ale zjevně tomu tak není. Ta zkratka znamená trojrozměrný prostor. Navíc jsem se speciálně ptal, kde je ta trojrozměrnost k vidění (mimo zmíněnou otáčecí kostku), ne kde se z nějakého důvodu používají 3D rutiny pro dosažení 2D výsledku.

Neptal jsem se na kompozitní desktop, ten se mi líbí i po estetické stránce, už jen kvůli vsync a nepotřebě věčného překreslováné ze strany aplikace.

[Josef Kufner]

To zvládne i kompozitor používající XRender, tedy 2D akceleraci.

[MadCatX]

OS X je doopravdy nešikovný příklad. Apple totiž kašle na zpětnou kompatibilitu a podporuje vždy tak poslední dvě tři verze, ať už jde o Mac OS X či iOS. Pokud si mohou vývojáři dovolit myslet jen v horizontu pár verzí, je situace samozřejmě výrazně snazší.

XFCE je prastará architektura vycházející ještě z CDE. Mám je na jednom notebooku a žádná hitparáda to není. Indikátor baterie ukazuje obráceně stav adaptéru, applet hlasitosti je podivně zmatený... vzpomněl bych si určitě na pár dalších drobností, kdybych to nějak vice používal. XFCE je navíc postavené na GTK2, takže pro nativní podporu Waylandu se bude muset kompletně přeportovat, jako se do toho pustil MATE. Navíc porovnávat ostrouhané prostředí jako XFCE s komplexitou Plasmy 5 nebo Gnome Shellu není zrovna na místě.

Windows fungují různě, ale určitě ne bez problému. MS nacpal do udržování zpětné kompatibility spoustu prostředků a stejně se to nedaří - třeba updater Win 10 má speciální nástroj, který uživateli vypíše všechen software, co po updatu nemusí fungovat. Kdyby to měl MS se zpětnou kompatibilitou tak vychytané, jak tvrdí, žádný podobný nástroj by nebyl potřeba. Dál je třeba si uvědomit, že ve Windowsí desktop představuje neporovnatelně větší byznys než Linuxový, takže hloupá technická podstata řešení se vykompenzuje tím, že se na jejich realizaci nalije více peněz.

[kyknos]

podle toho co jsem zatim slisel o waylandu, bude i wayland sam obrovska regrese (ssh -X, prostredni tlacitko mysi...), ale snad to byly jen famy...

[pavlix]

Obávám se, že ne, už jen proto, že vývoj waylandu asi nebude hlavním koníčkem lidí, co chtějí pořádně využívat vlastnosti X a SSH. A dost se obávám, že se nepořeší ani ta myš, protože normální uživatel™ používá počítač tak, jak rozhodl jeho výrobce, ne tak, aby se mu dobře používal.

[kyknos]

slysel sakra, virtualni klavesnice je zlo

[MadCatX]

Dvě chybějící vlastnosti znamená "obrovská regrese"?

X11kovou primary selection považuji to poměrně chorý nápad. Automatické zkopírování označeného bloku do sdíleného clipboardu? WTF? Nicméně extenstion pro Wayland je v plánu. Jen doufám, že to půjde vypnout: http://lists.freedesktop.org/archives/wayland-devel/2015-December/026083.html

ssh -X asi někomu chybět bude. Na druhou stranu když jsem to zkoušel používat já, bylo to tak nechutně pomalé, že jsem se radši naučil vše potřebné provádět z konzole:)

[pavlix]

Dvě chybějící vlastnosti znamená "obrovská regrese"?

Záleží především jaké to jsou, ne kolik jich je.

Automatické zkopírování označeného bloku do sdíleného clipboardu?

Používám denně a ještě v kombinaci s příkazem xsel, kterým data dostávám do různých dalších programů včetně vimu, ale třeba i wgetpaste. Xorg mi tady oproti Waylandu šetří spoustu času.

ssh -X asi někomu chybět bude.

Používám o něco méně, ale stále ještě prakticky denně. Považuju to za jednu z klíčových výhod Xorg proti alternativám.

[Václav "Darm" Novák]

Co jsem tak četl, nějaké to posílání okna po síti se v kompozitorech plánuje. Každopádně ani dneska už -X nefunguje dávno tak jak bylo zamýšleno, stejně to posílá bitmapy jako VNC.

[pavlix]

Tak já to nepoužívám kvůli implementačním detailům, ale kvůli účelu. Namísto shellu nebo konzolové appky vzdáleně poustím GUI appku, jejíž okenní vstup a výstup mám nadelegovaný k sobě. Nic víc, nic míň.

[Václav "Darm" Novák]

Koukám že Weston už umí RDP, další kompozitory se podle mě brzy připojí :)

[pavlix]

Znám RDP pouze na vzdálený desktop, ne na vzdálené aplikace.

[Václav "Darm" Novák]

Pod Windows tohle přes RDP funguje, tak snad taková funkcionalita nebude problém :)

[Václav "Darm" Novák]

Teď mě napadá… Jaký je problém používat k tomuhle XOrg dál? XServer běžící skutečně jen jako server bez zobrazování oken na lokálním stroji jde celkem hezky osekat, přes XWayland se k němu připojit dá a to že se jen tak přestane vyvíjet nebo že ho toolkity přestanou podporovat celkem pochybuju.

[Grunt]

I kdyby se vyvíjet přestal, XWayland z repositářů těžko někdo smaže (i když je to o pověstné levé ruce a pravé nosní dírce).

[pavlix]

Není potřeba smazat, stačí aby z důvodu změn v jiných komponentách přestal fungovat.

[Grunt]

O jakých kompnentech je řeč? Myslíš jako změny v X protokolu?

[pavlix]

To je sice taky možnost, ale co změny ve Waylandu a kompozitoru nebo změny v čemkoli jiném, s čím musí XWayland interagovat?

[Grunt]

A s čím musí XWayland interagovat? V podstatě je to obyčejný Xorg akorát nemá jako výstup nějaký grafický driver, ale dostane přidělený kus plochy (buffer) v kompozitoru. Na tom se snad ani nemá co rozbít. Na nějaké pokročilejší interakce rovnou zapomeň. Trošku je to jako Xvfb nebo xf86-video-nested.

[xkucf03]

XWayland je v roli Wayland klienta, ne? V tom případě by zřejmě rozbili i ostatní Wayland klienty a přestalo by toho fungovat mnohem víc, ne?

[Václav "Darm" Novák]

Fakt pochybuju že k likvidaci podpory Xserveru v toolkitech v nejbližších letech dojde. A ostatně, stačí vyřešit posílání single okna v RDP a bude to fungovat stejně jako teď v XOrg (kde se stejně většinou posílá celá bitmapa okna).

Celkem mě zaujal jeden nápad, zabudovat do stávajících GUI frameworků možnost posílat rozvržení GUI aplikace po síti (s tím že třeba u Qt by to údajně ani neměl být takový problém). Nevýhoda je vazba jen na aplikace co používají framweworky které to podporují a to že u klienta by musel být nainstalován stejný framework, výhoda pak že by aplikace měla stejný skin jaký má nainstalovaný klient a samozřejmě rychlost.

[Grunt]

Ono by dost bohatě stačilo kdy by se po síti posílaly vektory v binární podobě a glyfy namísto bůh ví čeho. Ani by nebylo potřeba přímo příkazy GUI frameworků.

[Bedňa]

Posielať obdĺžnik namiesto x[0-9]*x[0-9]*x[0-9]*x[0-9]* ako bitmapu o Xkilobajtoch pokladám za najhošie riešenie rovnako ako posielať text ako bitmapu, je to dostatočne markeťácke ako je to jednoduché, no ako to prepchať to posieti už nikto nerieši.

Keby takto rozmýšľaii aj tvorcovia hier tak by onlajnovky roky neexistovali. Keď si zoberieš koľko terminálov posiela len text, tak to tvoje riešenie prehráva niekoľko násobne.

[Grunt]

Jakou zase bitmapu?

[Bedňa]

Ta som toto

posílaly vektory v binární podobě

binární, bitmapové, zle pochopil

[mirec]

Niečo ako Display PostScript, alebo NeWS?

Mimochodom Qt3 aplikácie mi bežia cez ssh -X ako keby boli lokálne aj pri pripojení cez pomalé DSL. Qt4 už ide katastrofálne pomaly a okno reaguje na pohyb kurzoru cca 5s (teda 0.2fps).

[Grunt]

Tak PostScript je všechno jen ne binární, ale jinak jo. Něco takového.

[pavlix]

Fakt pochybuju že k likvidaci podpory Xserveru v toolkitech v nejbližších letech dojde.

Já jsem o tom naopak přesvědčen, že v nejbližších několika letech bude existovat alespoň jeden toolkit se zmršenou podporou X11 nebo úplně bez podpory. Ale spíše si myslím, že jich bude více.

A ostatně, stačí vyřešit posílání single okna v RDP a bude to fungovat stejně jako teď v XOrg (kde se stejně většinou posílá celá bitmapa okna).

Já se nebavím o tom, co by stačilo, ale o z mého pohledu významné regresi. Je to jedna z nejčastěji citovaných regresí při přechodu z X11 na Wayland, takže pokud by to bylo triviální, bylo by to nejspíše dávno vyřešeno a otestováno už jenom proto, aby se tím kritikům zalepila huba. Pokud se o něčem neustále jen mluví, že by to nějak šlo, většinou to ukazuje na problém.

Celkem mě zaujal jeden nápad, zabudovat do stávajících GUI frameworků možnost posílat rozvržení GUI aplikace po síti

To bych viděl jako nouzový workaround. Problém vidím v tom, že to bude fungovat jenom v některém frameworku, v dalším to bude zabugované a v dalším nepodporované. Stávající řešení fungovalo univerzálně.

[Josef Kufner]

Celkem mě zaujal jeden nápad, zabudovat do stávajících GUI frameworků možnost posílat rozvržení GUI aplikace po síti (s tím že třeba u Qt by to údajně ani neměl být takový problém). [...]

Tohle už existuje. Jmenuje se to HTML5.

[xkucf03]

A že už je to let… QWebClient

[pavlix]

Nevím, co máš namysli, já osobně používám Xserver ke zobrazování oken. Pokud správně chápu, tak XWayland slouží k tomu, abych mohl spustit legacy aplikace, které na Waylandu neběží. V tuhle chvíli můžu spustit libovolnou GUI aplikaci, která je na vzdáleném serveru instalovaná, protože všechny GUI aplikace X11 podporují a bývají v distribucích s jeho podporou kompilované.

To, co navrhuješ, vyžaduje mít Wayland, mít mezivrstvu, která umí přes Wayland spustit X11 aplikaci, použít ssh -X, popřípadě dneska už většinou musíš ssh -Y, na vzdáleném stroji mít opačnou mezivrstvu, která umí pustit Wayland aplikaci přes X11, a pak teprve můžeš používat aplikace tak jak stojí a běží. Ale se dvěma mezivrstvami, které budou mít svá vlastní omezení a své vlastní chyby!

V tomhle smyslu mi zavádění Waylandu trochu připomíná zavádění systemd. Sice to vůbec neumí všechno, co stávající systém, přináší to mnoho komplikací, nepřináší to žádnou zásadní výhodu, ale je to hrozně free, cool a in, a všichni to budete používat se všemi omezeními, chybami a nedodělky, i kdybyste se z toho měli... A to musím říct, že u systemd jsem schopný alespoň jmenovat konkrétní výhody, které mi nějakým způsobem pomáhají.

[Václav "Darm" Novák]

Ty osobně, ale pokud vím (v životě jsem to nezkoušel), Xserver umí běžet i čistě jako server bez toho aby vykresloval okna, pouze za účelem remote přístupu. Takže pokud opravdu požaduji možnost mít nějaké aplikace remote, prostě si vedle Waylandu nahodím Xserver a z jiného PC se připojím přes XWayland. To že bude svět brzy plný čistě wayland aplikací celkem pochybuju, všechny toolkity co implemetují wayland fungujou duálně, takže „Opačná mezivrstva“ by byla poměrně zbytečná.

[Grunt]

Xvfb se to jmenuje. Ale nevím co to tady konstruuješ. K tomu aby si spustil nějakou X aplikaci nepotřebuješ na stroji na kterém ji spouštíš žádný Xserver.

[pavlix]

K tomu aby si spustil nějakou X aplikaci nepotřebuješ na stroji na kterém ji spouštíš žádný Xserver.

+1

[pavlix]

Ty osobně, ale pokud vím (v životě jsem to nezkoušel), Xserver umí běžet i čistě jako server bez toho aby vykresloval okna, pouze za účelem remote přístupu.

V podstatě bude muset někdo udržovat minimálně další dva projekty se dvěma mezivrstvami, což mi přijde i do budoucna méně robustní než současné řešení, kdy jde prakticky každá aplikace pustit vzdáleně.

To že bude svět brzy plný čistě wayland aplikací celkem pochybuju,

Stačí jedna, pokud to bude zrovna ta, kterou chci spustit.

všechny toolkity co implemetují wayland fungujou duálně, takže „Opačná mezivrstva“ by byla poměrně zbytečná.

Stačí aby podporu vyhodili, nebyla zakompilovaná nebo byla pokažena zdánlivě nesouvisejícími změnami. Takové věci se v projektech, které sleduju, dějí dnes a denně, takže chlácholení, že tentokrát se to výjimečně nestane, na mě neplatí.

[Grunt]

V podstatě bude muset někdo udržovat minimálně další dva projekty se dvěma mezivrstvami, což mi přijde i do budoucna méně robustní než současné řešení, kdy jde prakticky každá aplikace pustit vzdáleně.

Nic se udržovat neplánuje. XWayland je takové legacy řešení, které bude fungovat tak dlouho dokud bude fungovat. S X11 se v budoucnu nepočítá.

že tentokrát se to výjimečně nestane

Chlácholit tě nikdo nebude. Ujišťuju tě že tohle jednoho slunečného jarního rána opravdu nastane.

[pavlix]

To už zní trochu reálněji.

[Grunt]

No tak jestli hledáš oponenta, tak na mě se nedívej. Já víceméně souhlasím s tebou. Ne ani tak kvůli síťové transparentnosti, ale prostě se mi líbí jak byl X11 protokol navrhnutej a jaké možnosti XServer nabízel. Je ho škoda. Ale co, aspoň nebude nuda. Zas dostaneme do rukou další nefunkční krám k rozjíždění

[pavlix]

Tak až to přijde, tak aspoň zajdem na panáka na žal, ne?

[Grunt]

Piju čaj, ale jak chceš, no.

[xkucf03]

nepřináší to žádnou zásadní výhodu

A co to oddělení aplikací?

a všichni to budete používat se všemi omezeními, chybami a nedodělky, i kdybyste se z toho měli...

Mně spíš přijde, že se to pořád odkládá – už roky se mluví o tom, jak se v příští verzi konečně přejde na Wayland, a pořád nic. Xka se pořád drží resp. lidé je používají dál.

[pavlix]

A co to oddělení aplikací?

V daném kontextu, kdy na sebe aplikace vidí i jinak, to žádné oddělení aplikací nenabízí.

Mně spíš přijde, že se to pořád odkládá – už roky se mluví o tom, jak se v příští verzi konečně přejde na Wayland, a pořád nic.

Protože to naštěstí dosud pořádně nefungovalo.

Xka se pořád drží resp. lidé je používají dál.

Protože to dosud v podstatě nešlo jinak.

[Grunt]

Mně spíš přijde, že se to pořád odkládá – už roky se mluví o tom, jak se v příští verzi konečně přejde na Wayland, a pořád nic.

Říkal si něco?

[xkucf03]

Fedora 24 teprve vyjde (skoro až za půl roku), ale o nasazení Waylandu se mluví mnohem mnohem déle. Tak snad už to konečně přijde

Jinak s tou schránkou souhlasím, přijde mi to jako vážný problém. Stejně tak síťová transparentnost a možnost pouštět aplikace po síti, to je důležité a určitě by to tam být mělo. Ale na druhou stranu: zase tak často to nepoužívám, tak bych dokázat tuhle funkci dočasně (!) oželet a v případě nutnosti si pustím Xka vedle.

[Grunt]

No jestli to přijde tak jsem si zcela jistý co to udělá tak na 50% strojů na kterých se to nějaký nešťastník pokusí spustit

[little.owl]

To je dusledek toho, ze se nezaclo pracovat X12, ktere by opravily stavajici chyby v designu, castecne kvuli konzervativnosti nekterych skupin a tak cast vyvojaru zacala pracovat na Wayland. Chybejici network tranparency je nekere problem, ale dat dohromady protokol, ktery neprenasi bitmapy neni az tak slozite; me se treba libi Verse. Wayland by mel neco takoveho specifikovat, i kdyz mam pochybnosti, ze k tomu bude motivace.

[Rezza]

No ono je to takove ode zdi ke zdi - Xka umela vsechno, ale vlastne nic. Wayland samotny neumi nic, ale chce se po nem vsechno :). Xka byl obri zamek s milionem komnat a sklepy, kde se clovek obcas ztratil a zemrel. Wayland je cihla. A nejak me prijde, ze jedine co vlastne chceme je obycejny dum :D.

[Josef Kufner]

Ono spíš to je tak, že Wayland umí tak akorát to málo, co je po něm potřeba. Teda až na tu síťovou transparentnost.

[Rezza]

Wayland neumi vubec nic. Vsechno je pak na toolkitech a desktopech si napsat to, co potrebuji ke sve spokojenosti. Takze se klidne muze stat, ze treba sitovou transparentnost si bude kazdy desktop, ci dokonce na urovni toolkitu, resit po svem.

[Václav "Darm" Novák]

Pokud se kompozitory na implementaci shodnou, bude to v pohodě. Bohatě by stačilo to RDP s možností posílat okna.

[pavlix]

Máš namysli RDP, který nebude RDP? :D

[Rezza]

Njn, ale kdyz si jedno z prostredi mysli, ze ma byt to jedine prave, tak se tezko shodnou :). Proste neni dobry napad rikat Linux, ale proste specificky distribuce a jeste s prostredim a ty mezi sebou budou vic a vic nekompatibilni, az se dostaneme do stavu Windows a Androidu, kde i aplikace od samotnych tvurcu kazda vypada a ovlada se jinak.

[pavlix]

Takze se klidne muze stat, ze treba sitovou transparentnost si bude kazdy desktop, ci dokonce na urovni toolkitu, resit po svem.

Tak na tu dobu se vůbec netěším.

[omldfre]

linux je prostě za zenitem, přijde lepší a mladší sekáč

[pavlix]

Links or didn't happen. :)

[xkucf03]

Mladší ne, Hurd

[Josef Kufner]

A co by ještě měl umět? Aplikaci to má poskytnout okýnko, kam může kreslit, zobrazit ho na obrazovce a od uživatele předávat vstup tomu správnému okýnku. Pak tam má být window manager, který říká, kde které okýnko bude a kam zrovna uživatel píše. To splňuje jak Xorg, tak Wayland. I když každý po svém.

Když se podívám, co Xorg umí, a co z toho se opravdu reálně používá, tak je tam neskutečně moc balastu. Například XResources. Na jednu stranu celkem hezký způsob, jak donutit aplikace z různých strojů, aby na jednom X serveru vypadaly stejně, ale žádný aktuální toolkit to nepoužívá. To samé s fonty. To samé s kreslením.

Na Waylandu chybí jen ta síťová transparentnost. Ale jak už bylo řečeno, tam se musí dohodnout standard, jak přenášet okýnka po síti. Co jsem se díval na architekturu Waylandu, je to úloha pro kompozitor, aby ten buffer přeposlal jinam, než na obrazovku. Pokud by se to ale udělalo na úrovni frameworku, mohlo by to být mnohem efektivnější, s nároky na linku na úrovni Midnight Commanderu přes SSH (pokud by tam zrovna nebyly obrázky). A někde v této diskuzi jsem zahlíd protokol na efektivní přenos OpenGL. Tady to vidím tak, že je potřeba, aby si aplikace mohla zvolit, na které úrovni ten síťový přenos bude (s fallbackem na přenos obrazu okýnka).

[Hans1024]

Co jsem se díval na architekturu Waylandu, je to úloha pro kompozitor, aby ten buffer přeposlal jinam, než na obrazovku.

Takze kazdy kompozitor si to implementuje po svem a kazdy pak aspon bude mit jine zajimave bugy . Mozna, az lidi budou prilis frustrovani, tak se prosadi jeden spolecne udrzovany kompozitor, ktery bude umet i to oblibene kopirovani mysi. A pak uz jen zbyva ho prejmenovat na X.

A někde v této diskuzi jsem zahlíd protokol na efektivní přenos OpenGL.

Takze AIGLX byl vlastne spravna cesta

[Josef Kufner]

Spíš se prosadí jedna knihovna, která ten přenos bude implementovat a všechny kompozitory ji použijí.

[xkucf03]

Když se podívám, co Xorg umí, a co z toho se opravdu reálně používá, tak je tam neskutečně moc balastu.

A co nějaká třetí cesta? Osekat XOrg resp vybrat z nich podmnožinu, tu znovu a čistě implementovat a lehce doladit toolkity (což by nemělo být skoro potřeba, protože ta podmnožina by se vybrala tak, aby v ní bylo to, co se běžně používá).

Tady to vidím tak, že je potřeba, aby si aplikace mohla zvolit, na které úrovni ten síťový přenos bude (s fallbackem na přenos obrazu okýnka).

To bych bral.

[pavlix]

A co by ještě měl umět?

Tady někdo neměl čas číst diskuzi. Ale zjevně i jen tady v diskuzi se najde hned několik lidí, kteří současný Wayland/Weston nevidí jako plnohodnotnou náhradu současných X11/Xorg.

Na Waylandu chybí jen ta síťová transparentnost.

A pár dalších věcí, o kterých se tu psalo. A spousta dalších věcí, na které lidi přijdou až teprve když to zkusí aktivně používat. Ať je Wayland mladý nebo starý, nese si typické výhody i nevýhody mladých projektů, tedy na jednu stranu podstatně méně balastu, na druhou stranu feature set odvozený od toho, na co mysleli tvůrci, ne od toho, co vypadlo z roků praxe.

Co jsem se díval na architekturu Waylandu, je to úloha pro kompozitor, aby ten buffer přeposlal jinam, než na obrazovku.

Výhoda X11/Xorg byla v tom, že tyhle věci byly implementovány jednou komponentou, která fungovala se všemi možnými desktopy a window managery. Není trochu škoda, že tomu tak není i v případě Waylandu?

Pokud by se to ale udělalo na úrovni frameworku, mohlo by to být mnohem efektivnější, s nároky na linku na úrovni Midnight Commanderu přes SSH (pokud by tam zrovna nebyly obrázky). A někde v této diskuzi jsem zahlíd protokol na efektivní přenos OpenGL. Tady to vidím tak, že je potřeba, aby si aplikace mohla zvolit, na které úrovni ten síťový přenos bude (s fallbackem na přenos obrazu okýnka).

Dívám se na stejnou věc přesně opačně. Pro mě je základem mít univerzální metodu, která je funkční vždy a všude a k ní případné optimalizace/akcelerace, které poskytnou bez újmy na použitelnost lepší výkon pro jednotlivé toolkity. Základem tedy nazývám to, co ty nazýváš fallbackem a to, co je pro tebe základ je pro mě optimalizace.

[Grunt]

Ale zjevně i jen tady v diskuzi se najde hned několik lidí, kteří současný Wayland/Weston nevidí jako plnohodnotnou náhradu současných X11/Xorg.

Ať to teda napíšu: Není to pouze o síťové transparentnosti. Ta už je pouze jako bonus díky tomu že se používá nějaký standardizovaný a stremovatelný protokol namísto třeba systémových volání. Je to především o tom že X-ka jsou Display Server. Jedna komponenta, nezávislá plocha na kterou můžou aplikace posílat své grafické výstupy. Nezapomeňte na to že XServer není pouze Linuxová komponenta, ale funguje i ve Windowsech. Teoreticky by neměl být problém na jednom desktopu mixovat výstup z Windowsích aplikací společně s různými otevřenými toolkity a aplikací z Mac OS k tomu. Nebo třeba mixovat aplikace z různých souběžně běžících platforem. Teda aspoň tolik teorie. Představa že se budu muset hlásit do KDE či GNOME podle toho jakou aplikaci napsanou v tom či onom toolkitu mě opravdu docela straší. Wayland je něco mezi co mi vyloženě nevadí. Beru ho jako odlehčenou verzi. Pochybuju však že v něm kupř. zmixuju obraz z dvou různých platforem najednou. A jeden příklad jak to opravdu nedělat: GDI+.

[little.owl]

To nemeni nic na faktu, ze polovina lidi. kteri X11 rozumela a byla ochotna se jim venovat je pod drnem, a podstatna mladsi cast druhe poloviny uz proste nema motivaci se tim zabyvat, a firmy z X11 konzorcia to platit. XWayland tu jeste nejakou dobu bude a ja stale doufam, ze se dohodnou na nejake verzi protokolu pro sitovou transparency, protoze bez toho zkoncime u RDP.

[xkucf03]

Takze se klidne muze stat, ze treba sitovou transparentnost si bude kazdy desktop, ci dokonce na urovni toolkitu, resit po svem.

Což je právě dost padlé na hlavu. Každá vrstva by si měla řešit to svoje – a síťová transparentnost je o vrstvu resp. o dvě níž než toolkity a desktopy.

[pavlix]

+1

Architektura Waylandu se tak zdá býti poněkud nešťastnou.

[Grunt]

Jakožto odlehčenou verzi a obdobu SurfaceFlingeru z Androidu? Proč ne?

[little.owl]

Architektura Waylandu je OK, co si to dalo za cil dela vicemene dobre.

[pavlix]

Aha, takže nahradit X11 mezi cíle nepatří. To se mi ulevilo. Oh wait...

[Rezza]

:).

[little.owl]

Jen castecne, neni to X12. Je to trochu pristup vysekame vse co neni podstatne pro 95% lidi. Mne to take vadi, pouzivam X11 podobne jako ty, ale na stranu druhou je chapu, jiz nejsme v 80. letech minuleho stoleti a vzdalene aplikace se resi pres web.

[pavlix]

Je to trochu pristup vysekame vse co neni podstatne pro 95% lidi.

Vysekáním každé vlastnosti, která je pro menší část uživatelů vznikaní velmi průměrné komoditní produkty, které dobře neslouží skoro nikomu.

[little.owl]

Wayland je standardizovany protokol popisujici jak klient komunikuje s kompozitorem. Na jedne strane tedy komoditizuje souvisejici domenu, na strane druhe prinasi interoperatibilitu a moznost vice hracu a od toho standardy jsou. O prumernosti ci excelenci bude predevsim rozhodovat kvalita implementace kompozitoru, a tech veci co se tam da podelat ci udelat dobre je plno.

[Rezza]

Ano, Wayland spoustu veci prenesl na kompozitory a tam at uz si to kazdy ukuchti jak chce. To je to moje prirovnani k cihle :). Nekdo z toho treba ten dum postavit zvladne, nekomu to spadne. Proto jak ted nekdo od Waylandu blogoval neni otazka, jestli je Wayland ready, ale jednotlive kompozitory. Je to jen nezajimavy spodek, kteremu porad neco chybi, ale hlavni prace bude o level vys. V necem je to dobre, v necem to bude zbytecna duplicita kodu, v necem to bude nekompatibilni.

[Grunt]

vzdalene aplikace se resi pres web

Však fujtajcl zelený taky.

[kralyk z abclinuxu]

Což je právě dost padlé na hlavu. Každá vrstva by si měla řešit to svoje – a síťová transparentnost je o vrstvu resp. o dvě níž než toolkity a desktopy.

To není pravda, protože toolkity renderují.

[pavlix]

Non sequitur, spíše naopak, ne?

[kralyk z abclinuxu]

Nevim, co se snažíš říct. Že toolkity nemají renderovat?

[pavlix]

Říkám, že jsi vůbec nevyvrátil, co jsi chtěl vyvracet, a to zcela bez ohledu na to, zda toolkity rendrují nebo ne. Podle mě jsi zpochybnil komentář předřečníka bez smysluplného zdůvodnění.

[little.owl]

Ne, ma pravdu. To ze toolkity renderuji do framebufferu, ktery je primo zpracovavan HW, vcetne uziti HW akcelerace, znamena, ze jsou velmi nizko, v podstate nize nez vetsina sitovych protokolu na nichz by se dala stavet sitova transparence. V praxi to znamena, ze pro podporu sitove transparence budou toolkity but podporovat dva backendy parallelne nebo se budou bud posilat off-screen renderovane bitmapy. Cpat mezivrstvu mezi toolkit a HW by byl krok zpet, doslova proti vsemu co se na grafickem stacku za poslednich deset let udelalo a proti zajmu vetsiny uzivatelu. Jedine rozumne reseni je dohoda na sitove transparentnim protokolu a jeho parallelni podpora v toolkitech.

[pavlix]

Jinak já osobně s posíláním bitmap nemám problém. Pro moje účely to bohatě stačí. Nějaké akcelerace/optimalizace by samozřejmě byla super. Ale pro začátek snad stačí, když nebudou toolkity, aplikace a síťová mezivrstva úplně debilní a nebudou posílat pro uživatele bezvýznamné změny jako je překreslení nebo vymazání s následným překreslením. Co mě může na počítačování nejvíc nasrat je, když se v aplikaci z uživatelského pohledu vůbec nic neděje, ale stejně generuje load a výrazný síťový traffic.

[kralyk z abclinuxu]

Nevim, jestli ti rozumim, šlo mi o to, že síťová transparentnost imho není o vrstvu nebo víc pod toolkitama, vzhledem k tomu, jakým způsobem se toolkity podílejí na vykreslování GUI. Síťovej přenos řešenej "o vrstvu nebo dvě" pod toolkitama celkem nemá jinou možnost než přenášet bitmapy, a pak je otázka, jestli má vůbec smysl, aby display server / kompozitor síťovej přenos řešil - pak je skoro lepší to nechat na externích nástrojích a necpat to do display serveru.

[xkucf03]

Toolkit je hlavně hromada ovládacích prvků, API směrem k aplikaci, kód pro obsluhu událostí atd. Resp. v tom se od sebe hlavně liší. Že se to někam vykresluje, je zřejmé, ale Qt komponenty i GTK komponenty (a další) se můžou klidně vykreslovat do stejné vrstvy – a tahle vrstva to buď pošle na obrazovku nebo třeba někam po síti… nebo třeba na virtuální obrazovku, ze které si to přečte jiný program (třeba pro automatické testy).

[pavlix]

Toolkit je hlavně hromada ovládacích prvků, API směrem k aplikaci, kód pro obsluhu událostí atd. Resp. v tom se od sebe hlavně liší.

+1

Že se to někam vykresluje, je zřejmé

Ani nemusí. Co vím, tak třeba EFL toolkit a rendering odděluje a jsem přesvědčený, že to nebude jediný takový projekt. Toolkit sice definuje vzhled, ale to ještě neznamená, že se o vykreslení nemůže postarat jiná komponenta.

Nakonec je to i jedna z věcí, co se tu diskutuje, jestli se pošle po síti již vykreslená bitmapa nebo jen data postačující k vykreslení.

[kralyk z abclinuxu]

Že se to někam vykresluje, je zřejmé, ale Qt komponenty i GTK komponenty (a další) se můžou klidně vykreslovat do stejné vrstvy – a tahle vrstva to buď pošle na obrazovku nebo třeba někam po síti… nebo třeba na virtuální obrazovku, ze které si to přečte jiný program (třeba pro automatické testy).

Tak jednoduché to není, protože aplikace v Qt, GTK nebo něčem jiným často chtějí používat OpenGL nebo třeba vykreslování videa. Software renderer prostě ne vždy stačí. To je přesně to, co píše vejš little.owl.

Tebou navrhovaný přístup by např. imho nebyl použitelný pro browser, protože browser potřebuje jak video tak i HW akceleraci vykreslování.

[pavlix]

Asi jsem něco nepochopil, ale co přesně navrhuje oproti současnému stavu s X11?

[xkucf03]

Tebou navrhovaný přístup by např. imho nebyl použitelný pro browser, protože browser potřebuje jak video tak i HW akceleraci vykreslování.

Schválně jsem si teď zkusil zahrát Nexuiz (OpenGL 3D hra) přes SSH a videa jsem si přes SSH pouštěl už dávno (1,2). Považuji to tedy za jasný důkaz toho, že to proveditelné a použitelné je.

Pokud to nějaká technologie neumí, bude problém v ní – nikoli v tom, že by to obecně nešlo.

Připadá mi to jako příklad toho hloupého módního přístupu „pojďme to dělat jednoduše“, který je ve výsledku složitější a horší.

Waylandu celkem fandím, ale dokud to nebude umět některé věci, tak je to prostě jen nedodělek a prototyp, ne důstojný nástupce stávající technologie. Netrpím zbytečnou nostalgií k X a nemám problém s jejich opuštěním, ale jejich nástupce musí být lepší.

[kralyk z abclinuxu]

Schválně jsem si teď zkusil zahrát Nexuiz (OpenGL 3D hra) přes SSH a videa jsem si přes SSH pouštěl už dávno (1,2). Považuji to tedy za jasný důkaz toho, že to proveditelné a použitelné je.

Věřím, že po FireWire ano Jinak ale i tam platí, že ta hra je napojená přímo na kartu (pokud to teda nerenderuje softwarově, o čemž silně pochybuju) a teprve zpětně se to kopíruje pro ssh -X, takže tam se opět o nějaké mezivrstvě nedá moc mluvit.

Jinak já popravdě těmhle diskusím dost přestávám rozumět. Imho všechny tyhle diskuse ve skutečnosti nemají vůbec nic společného s unixovou filosofií nebo s úvahami o dobrém designu, ale jsou prostě jenom o tom, že lidi chtějí zachovat status quo - nechtějí technologie, které fungují jinak než jak byli doposavaď zvyklí.

Ta procedura s tím, že se pustí video ve VLC a pošle se to přes ssh -X společně se zvukem přes PA, jsem vůbec nepochopil, k čemu je dobré. Vždyť to přece umí samotné VLC jednodušeji a efektivněji, dokonce přesně na tohle je VLC původně určené! Navíc to umí nezávisle na tom, jestli běží nad X11 nebo nad něčim úplně jiným. Bude to fungovat úplně stejně na jiném OS.

Suma sumárum: Síťová transparence ve Waylandu je imho nesmysl. (Jako nějaké rozšíření nebo nadstavba - třeba s použitím externí knihovny/programu - klidně, to není špatný nápad. Ale stejným stylem jako X11 - opravdu nevidim smysl...)

[Grunt]

Jinak já popravdě těmhle diskusím dost přestávám rozumět. Imho všechny tyhle diskuse ve skutečnosti nemají vůbec nic společného s unixovou filosofií nebo s úvahami o dobrém designu, ale jsou prostě jenom o tom, že lidi chtějí zachovat status quo - nechtějí technologie, které fungují jinak než jak byli doposavaď zvyklí.

Spíš jde o to že asi nastal čas aby si kupa chytrých hlav z akademického prostředí sedla kolem kulatého stolu a vymyslela další překomplikovaný protokol fungující na nějakém serveru a přes sokety a se síťovou transparetností jako bonusem. Waylandem žádného nerdíka neuchlácholíš

[xkucf03]

Věřím, že po FireWire ano

U toho FireWire jsem tehdy zjistil, že je tam nějaká chyba a nejde to o moc rychleji než 100 Mb/s ethernet (a i ten na to stačí s přehledem).

Jinak já popravdě těmhle diskusím dost přestávám rozumět. Imho všechny tyhle diskuse ve skutečnosti nemají vůbec nic společného s unixovou filosofií nebo s úvahami o dobrém designu

Unixová je na tom právě ta dělba práce – že jedna vrstva řeší vykreslování na grafiku nebo posílání po síti a jiná vrstva řeší tlačítka, formuláře a obsluhu událostí. Jednotlivé vrstvy můžeš zaměňovat, a tak je jedno, jestli je aplikace psaná v Qt, GTK nebo třeba v Javě – můžeš ji vykreslovat po síti nebo na libovolné grafické kartě. Stejně tak když někdo napíše nějaký testovací nástroj nebo třeba adaptér pro nějaký jiný protokol (VNC, Spice, RDP…), tak ho napíše jen jednou, napojí na jedno rozhraní – a ne že bude psát specifický kód pro každý toolkit zvlášť (a na některé zapomene, na některé se vykašle, v některých to nebude otestované/odladěné a nakonec to bude fungovat jen s jedním).

Ta procedura s tím, že se pustí video ve VLC a pošle se to přes ssh -X společně se zvukem přes PA, jsem vůbec nepochopil, k čemu je dobré.

V mém případě to byl spíš experiment, ale dovedu si představit i praktické využití. Např. někde ve firmě nebo organizaci, kde lidé přechází mezi různými počítači a chtějí pouštět různé aplikace bez ohledu na to, kde zrovna jsou, a využít třeba plný výpočetní výkon silného serveru, nebo si poskládat na jedné obrazovce terminálu (tenkého klienta) aplikace běžící na několika různých strojích a vidět je pěkně pohromadě a moci to řídit z jednoho místa.

Je to vlastně aplikace sunovského hesla „The Network Is The Computer“ – je jedno, kde se fyzicky nachází data, protože je máš připojená po síti a pracuješ s nimi, jako by byla na tvém disku… a je jedno, kde běží aplikace, protože s ní pracuješ, jako by běžela na tvém terminálu.

Co Xkám chybí, je možnost odpojit klienta a server a pak připojit jiný server a pokračovat v rozdělané práci. Je potřeba to řešit externími nástroji a ne úplně systémově (nicméně jde to). Od nástupce X bych např. čekal, že tohle v sobě bude mít zabudované – a ne že nebude mít ani ty základní funkce.

Vždyť to přece umí samotné VLC jednodušeji a efektivněji, dokonce přesně na tohle je VLC původně určené!

Umí to jen proto, že to do něj někdo naprogramoval, což muselo dát jistě dost práce. A tuhle práci bys musel dělat v každé aplikaci znova a znova. Kdežto když si systém správně navrhneš, uděláš tu práci jen jednou a všechny aplikace to můžou využívat, aniž by bylo potřeba je upravovat.

[kralyk z abclinuxu]

U toho FireWire jsem tehdy zjistil, že je tam nějaká chyba a nejde to o moc rychleji než 100 Mb/s ethernet (a i ten na to stačí s přehledem).

100 Mb/s ethernet je luxus.

Unixová je na tom právě ta dělba práce – že jedna vrstva řeší vykreslování na grafiku nebo posílání po síti a jiná vrstva řeší tlačítka, formuláře a obsluhu událostí. Jednotlivé vrstvy můžeš zaměňovat, a tak je jedno, jestli je aplikace psaná v Qt, GTK nebo třeba v Javě – můžeš ji vykreslovat po síti nebo na libovolné grafické kartě.

Absolutně nevěřim, že by bylo možné tuhle vrstvu navrhnout tak, aby skutečně plně vyhovovala na jedné straně všem druhům aplikací (obyč GUI aplikace, mediální a 3D aplikace vyžadující přístup k HW, ...) a na straně druhé šla napasovat na všechny backendy, včetně všech druhů HW akcelerace, ovladačů grafických karet, protokolu, atd. Musel bys v podstatě i abstrahovat třeba OpenGL... Imho by z toho byla God-vrstva. Unixového mi na tom nepřijde vůbec nic.

Umí to jen proto, že to do něj někdo naprogramoval, což muselo dát jistě dost práce. A tuhle práci bys musel dělat v každé aplikaci znova a znova.

Knihovny nic? libvlc nic?

[Josef Kufner]

U toho FireWire jsem tehdy zjistil, že je tam nějaká chyba a nejde to o moc rychleji než 100 Mb/s ethernet (a i ten na to stačí s přehledem).

100 Mb/s ethernet je luxus.

Jak se to veme. Dnešní WiFi je 8x rychlejší. Připojení k Internetu v podobných rychlostech už není nijak vzácné.

[Josef Kufner]

Unixová je na tom právě ta dělba práce – že jedna vrstva řeší vykreslování na grafiku nebo posílání po síti a jiná vrstva řeší tlačítka, formuláře a obsluhu událostí. Jednotlivé vrstvy můžeš zaměňovat, a tak je jedno, jestli je aplikace psaná v Qt, GTK nebo třeba v Javě – můžeš ji vykreslovat po síti nebo na libovolné grafické kartě.

Absolutně nevěřim, že by bylo možné tuhle vrstvu navrhnout tak, aby skutečně plně vyhovovala na jedné straně všem druhům aplikací (obyč GUI aplikace, mediální a 3D aplikace vyžadující přístup k HW, ...) a na straně druhé šla napasovat na všechny backendy, včetně všech druhů HW akcelerace, ovladačů grafických karet, protokolu, atd. Musel bys v podstatě i abstrahovat třeba OpenGL... Imho by z toho byla God-vrstva. Unixového mi na tom nepřijde vůbec nic.

Ta vrstva musí být protokol, který propojí backend a frontend nezávisle na konkrétní podobě obou. Samozřejmě pak je potřeba mít na obou stranách kompatibilní věci, ale přenosová vrstva může být celkem snadno naprosto nezávislá. Pak je potřeba definovat dostupné frontendy, aby backend mohl říct, co chce použít jako GUI. Mohl by pak existovat X11 frontend, který by byl v podstatě xwayland, ale také by mohl existovat Qt frontend, který by dostával vysokoúrovňový popis GUI a posílal zpět jen napojené signály od jednotlivých widgetů, například že uživatel změnil obsah políčka namísto posílání jednotlivých stisků kláves. Ten protokol by tedy řešil propojení a inicializaci, nikoliv samotnou komunikaci.

[kralyk z abclinuxu]

Ta vrstva musí být protokol, který propojí backend a frontend nezávisle na konkrétní podobě obou.

Jakože třeba mezi hru a grafickou kartu vložíš mezivrstvu? A k čemu to bude dobré? Vždyť ta mezivrstva stejně z těch OpenGL instrukcí nebude schopna zkonstruovat obraz, jediný, co by ta vrstva dělala, by bylo, že by ty instrukce přeposlala ovladači grafárny a pak přečetla vykreslený výsledek coby bitmapu a s tím teprve mohla něco dělat - což je přesně to, co dělají VNC a podobné a úplně staví na hlavu smysl mezivrstvy.

A nemusí se nutně jednat o hry, třeba QML aplikace taky vykreslují přes OpenGL...

[xkucf03]

Když např. nemáš 3D kartu, můžeš použít softwarovou emulaci OpenGL a všechno ti funguje (byť pomalu). Aplikaci není potřeba nijak měnit. Další věc je virtualizace – hypervizor může zprostředkovat 3D grafiku a aplikace ve virtuálu ve výsledku vykresluje na grafickou kartu (přes nějakou mezivrstvu). Jestli to jde skrz hypervizor nebo přes síť (nebo oboje) je celkem jedno. Stejně tak protokol SPICE, tam je podpora 3D ve vývoji.

Na těch příkladech (když ti nestačí X) je vidět, že to jde, je to proveditelné a používá se to v praxi. Nevidím moc smysl v opakování, že to nejde. Jak se říká, kdo chce, hledá způsoby, kdo nechce, hledá důvody…

[kralyk z abclinuxu]

Na těch příkladech (když ti nestačí X) je vidět, že to jde, je to proveditelné a používá se to v praxi.

Na těch příkladech není vidět vůbec nic krom toho, že vezmeš bitmapy a posíláš je po síti. A to jsem nikdy netvrdil, že nejde, jasně, že to jde. Jde to relativně snadno a není na to vůbec potřeba žádná mezivrstva.

[petr_p]

Žádná? Já zapomněl že všechny grafické režimy používají stejnou reprezentaci pixelu. Že všechny stroje mají stejnou endianitu.

[Josef Kufner]

Pointa je, že ta mezivrstva vůbec kreslit nebude. Bude jen obousměrně přenášet data mezi frontendem a backendem. Hlavně to nebude mezivrstva, ale protokol, takže ji půjde omezit na nulovou tloušťku v případě lokálního kreslení (pořeší si to knihovna), nebo může mít podobu proxy, která bude přenášet události, vykreslování nebo cokoliv jiného na vzdálený stroj.

Jde o to mít abstrakci, která umožní sestavit obousměrnou pipeline dle aktuálních požadavků. Může to prostě přímo kreslit pomocí OpenGL na lokální okno ve Waylandu s nulovou režií navíc, nebo to může posílat OpenGL instrukce po síti a tam teprve kreslit, nebo to může přeposílat Qt signály po síti mezi dvěma částmi jednoho programu, přičemž každá běží úplně jinde a z pohledu uživatele to je stejně interaktivní, jako lokální aplikace.

[pavlix]

Asi tak nějak. To platí pro tvůj i Frantův komentář. Když někdo argumentuje OpenGL a bojuje proti mezivrstvám, je to k smíchu.

[kralyk z abclinuxu]

Jde o to mít abstrakci, která umožní sestavit obousměrnou pipeline dle aktuálních požadavků.

Ahá, no tak to je v tom případě úplně v pohodě.

Stačí podporovat různé verze OpenGL, včetně třeba takových věcí jako přenášení textur do paměti grafiky nebo třeba shadery. Vytvořit proxy, která tohle umí, včetně poslání po síti, jistě nebude problém.

Pak je potřeba podporovat VDPAU nebo VA-API API nebo podobné.

Dále Qt QPainter API, opět nic, co by byl nějaký problém, prostě bude kompozitor podporovat QPainter backend. To samé pro GDK/Cairo. Taky by to ještě taky mělo podporovat nějakou vektorovou grafiku, ideálně i s animacema a takovejma věcma...

Jo a kromě toho by to ještě mělo být schopno routovat uživatelský vstup, pochopitelně. To jen taková třešnička na dortu.

Opravdu nechápu, že tohle ve Waylandu už dávno neudělali, vždyť to je na pár člověkoroků

[pavlix]

Třeba lidé jenom nechtějí trávit čas a energii přechodem na něco, co z jejich pohledu ani zdaleka nedosahuje kvalit stávajícího řešení.

[kralyk z abclinuxu]

Takze se klidne muze stat, ze treba sitovou transparentnost si bude kazdy desktop, ci dokonce na urovni toolkitu, resit po svem.

Jako kdyby síťová transparentnost u X11 fungovala nějak smysluplně... Např. VNC přenáší bitmapy, to není ono, potřebujeme X11, které bitmapy jistě nepřenáší. Oh wait...

[Václav "Darm" Novák]

Proto nechápu co maj lidi za problém s RDP, který přenáší bitmapy :D

[pavlix]

V obou případech straw man?

[kyknos]

kdyz nahodou sedim u windows a rikam si, ono to jde docela pouzivat, obvykle prvni vec, ktera me behem maximalne par desitek minut vrati do reality, je chybejici primary selection

pro me zcela zasadni vec

[xkucf03]

X11kovou primary selection

Já to dost používám a když jsem občas u někoho na OS, tak mi to dost chybí. Uvítal bych, kdyby to naopak ve výchozím nastavení bylo zapnuté (a šlo případně vypnout).

ssh -X asi někomu chybět bude. Na druhou stranu když jsem to zkoušel používat já, bylo to tak nechutně pomalé, že jsem se radši naučil vše potřebné provádět z konzole:)

Na LAN je to dobře použitelné, dají se přes to hrát i 3D hry. Na WAN to chce trochu trpělivosti (i když při dnešních rychlostech… dlouho jsem to nezkoušel).

Osobně považuji za lepší návrh, když spolu části aplikace komunikují nějakým protokolem (na to stačí STDIO protunelované skrz SSH) a klientská část běží běží čistě na straně uživatele (což je lepší i v případech, kdy chci spustit nějaký správcovský program pod rootem – stačí, aby pod ním, třeba přes sudo, běžela jen malá část aplikace a ne celé GUI).

Ale i tak považuji za velmi užitečné, aby šla GUI aplikace spustit distribuovaně na více počítačích (nebo pod více uživateli na témže počítači) a nebylo ji vždy nutné přepisovat a rozdělovat na dvě části. Rád bych tedy, aby tato možnost zůstala zachována.

Co mě na Waylandu hlavně zajímá je větší oddělení aplikací a tím větší bezpečnost.

[Václav "Darm" Novák]

Není právě primary selection jeden z nechtěných důsledků toho oddělení aplikací?

[Václav "Darm" Novák]

Jeho nefunkčnost, myslím :) Jinak ano, to je jedna zvlastností kvůli kterým rád přejdu hned jak to bude možné (Plasma 5.6, snad)

[pavlix]

To chceš říct, že nebude fungovat ani klasická schránka? Poslední systém bez schránky, co jsem používal, byl MS-DOS. Selekce myší se liší jenom v tom, že se ukládá poslední označený text narozdíl od posledního textu, který uživatel explicitně zvolil k uložení. Nehledě na to, že bez dalších opatření to nemá žádné výhody ani v oblasti bezpečnosti.

[Václav "Darm" Novák]

Aha, teď koukám že je to ne vinou oddělení, ale jeden z důvodů proč má zatím Wayland jen jeden buffer pro schránku byla ta bezpečnost. Jako trochu lehčí důvod uvádí ukliknutí se a poslání citlivé informace třeba do chatu, jako horší to, že má v případě Primary Select každá aplikace v podstatě možnost mrknout se co bylo naposled označeno. Právě na tom aby aplikace měla přístup ke schránce jen v případě middle click eventu zdá se momentálně pracujou.

[pavlix]

Aha, teď koukám že je to ne vinou oddělení, ale jeden z důvodů proč má zatím Wayland jen jeden buffer pro schránku byla ta bezpečnost.

Bezpečnost ovšem zatím jen teoretická, pokud se bude Wayland v distribuci používat stejným způsobem jako se teď používá X11, tedy pro uživatelské programy, které na sebe navzájem vidí jinou cestou. Navíc bezpečnost se musí vždycky balancovat s funkčností, jinak bychom mohli bezpečnost zajišťovat tak, že prostě všechny stroje vypneme a zlikvidujeme.

Jako trochu lehčí důvod uvádí ukliknutí se a poslání citlivé informace třeba do chatu,

To se může stát a mohl by to být dostatečný důvod pro opt-in, ale určitě ne pro nezačlenění.

jako horší to, že má v případě Primary Select každá aplikace v podstatě možnost mrknout se co bylo naposled označeno.

Stejně jako má možnost se podívat, co bylo naposledy ve schránce. Na běžné linuxové distribuci, jak už jsem uvedl výše, má přístup k citlivým datům každá aplikace, a tudíž se jedá o buzeraci, nikoliv zabezpečení.

Právě na tom aby aplikace měla přístup ke schránce jen v případě middle click eventu zdá se momentálně pracujou.

To je ovšem úroveň zabezpečení, která je zajímavá jen na systémech, kde jsou procesy bezpečně oddělené, což v běžných distribucích neplatí. Nevidím důvod obětovat funkcionalitu za zabezpečení, které nefunguje. Rád bych, aby alespoň vybrané aplikace fungovali na takové úrovni přístupu, aby všechnych měl všechny tyto funkce k dispozici.

Ovšem ještě lepší by pro moji každodenní práci bylo, kdyby Wayland vůbec neexistoval. :D

[Václav "Darm" Novák]

Momentální bezpečnostní problém XOrg je AFAIK ten, že i když aplikace oddělím v rámci OS do kontejnerů, okna na sebe vidí. Což ve Waylandu padá.

>důvod pro opt-in

Ano, proto jsem napsal že je to lehčí z argumentů :)

To že se mají aplikace možnost podívat co je ve schránce je pravda, ale ve schránce mám vždy jen to co kopírovat chci. To u Primary Select často neplatí.

Každopádně, zjevně se na Primary Select pracuje, takže bych se nebál (taky by mi chyběl)

[pavlix]

Momentální bezpečnostní problém XOrg je AFAIK ten, že i když aplikace oddělím v rámci OS do kontejnerů, okna na sebe vidí. Což ve Waylandu padá.

Bohužel zároveň bez ohledu na přání administrátora a uživatele padá i několik z mého pohledu klíčových funkcí, které byly doposud samozřejmostí.

To že se mají aplikace možnost podívat co je ve schránce je pravda, ale ve schránce mám vždy jen to co kopírovat chci. To u Primary Select často neplatí.

To je sice argument, ale dost slabý, vzhledem k tomu, že jednou z nejtypičtějších entit ke kopírování jsou přístupová hesla.

Každopádně, zjevně se na Primary Select pracuje, takže bych se nebál (taky by mi chyběl)

Pak nevím, o čem se tu bavíme, když i pro tebe je to významná funkce.

[xkucf03]

To je ovšem úroveň zabezpečení, která je zajímavá jen na systémech, kde jsou procesy bezpečně oddělené, což v běžných distribucích neplatí. Nevidím důvod obětovat funkcionalitu za zabezpečení, které nefunguje.

Tohle je trochu problém slepice-vejce – dokud na sebe aplikace vidí přes Xka, tak nemá moc velký smysl je oddělovat přes AppArmor, SELinux nebo podobný bezpečnostní modul. Dělá se to u některých serverových (jenže tam to taky nemá až takový efekt, protože ty zase běží pod různými uživateli), ale u desktopových moc často ne. Aneb může tvůj WWW prohlížeč nebo e-mailový klient číst tvoje SSH/GPG/X.509 klíče nebo soubory s uloženými hesly jiných aplikací? Nebo může hudební přehrávač číst tvoje fotky? Má tvoje kalkulačka přístup na Internet? Má přístup na Internet i nástroj na generování náhodných hesel?

Ovšem ještě lepší by pro moji každodenní práci bylo, kdyby Wayland vůbec neexistoval. :D

Víceméně jediné, co mne na Xkách trápí je to nedostatečné oddělení aplikací. Kdyby se to podařilo vyřešit v rámci X, tak bych byl asi radši, než přecházet na novou technologii. X Access Control Extension Specification?

[pavlix]

Jaký problém vejce-slepice? Wayland zjevně oddělení aplikací nabídne. Bavíme se o tom, zda budu moci alespoň mnou vybrané aplikace provozovat se sdílenou schránkou, případně textovou selekcí, případně dalšími funkcemi, u kterých jsem si třeba ani neuvědomil, že by mohly zmizet.

[xkucf03]

Jaký problém vejce-slepice?

Tak znovu, psal jsi:

To je ovšem úroveň zabezpečení, která je zajímavá jen na systémech, kde jsou procesy bezpečně oddělené, což v běžných distribucích neplatí.

Což neplatí mj. proto, že na sebe aplikace vidí přes Xka, a tudíž to oddělení AppArmorem/SELinuxem/… nemá až takový smysl jaký by jinak mělo. A na základě toho, že se aplikace v dnešních distribucích běžně neoddělují, ty zpochybňuješ tuhle výhodu Waylandu, jako nezajímavou.

Někdo prostě musí udělat ten první krok – a pak najednou bude mít smysl udělat ten krok i na druhé straně (distribuce vs. Xka/Wayland). Jedno bez druhého se může zdát, že je k ničemu.

[pavlix]

případně dalšími funkcemi, u kterých jsem si třeba ani neuvědomil, že by mohly zmizet.

Zrovna jsem si vzpomněl na Compose Key.

[kralyk z abclinuxu]

zajimave je, ze windows gui, osx gui

Protože MS a Apple vyvíjí na Nvidi tlak, aby si ty svoje zabugovaný drivery opravovali. Přesně stejný tlak musí vyvinout i Linuxová komunita a Linus už k tomu naštěstí řekl svoje v tom známém videu...

xfce a rada dalsich linuxovych rozhrani normalne funguji

Protože XFCE toho umí asi tak 0.1% co KDE. To je přístup typu "Kdo nic nedělá, nic nezkazí".

problem je z nejakeho duvodu jen s GNOME a KDE :D

KDE s aktualizovanými drivery taky nemá problém.

Jinak to, co tady říkáš o tom, že by si to měli opravit v Plasmě, je dost bullshit, protože i když bude existovat workaround v Plasmě, tak na to narazí nějaká jiná aplikace, třeba nějaká hra nebo něco jiného.

Tvoje komentáře jsou jak z marketingového oddělení.

[kyknos]

Protože XFCE toho umí asi tak 0.1% co KDE. To je přístup typu "Kdo nic nedělá, nic nezkazí".

ale umi vse co potrebuji, a umi to dobre, zatimco v KDE to nefunguje vubec nebo blbe

[kralyk z abclinuxu]

Čistě ze srandy: Co ti nefunguje v KDE5?

[kyknos]

nic :)

respektive predevsim user experience, malem jsem se poblil a odinstaloval jsem to (problemy s vykreslovanim, pomalost, nesly nastavit veci, ktere me sraly...)

[pavlix]

Protože XFCE toho umí asi tak 0.1% co KDE.

To nemusí být nutně špatně.

[kotyz]

mohla by tam aspoň bejt detekce problémovejch verzí ovladačů která by automaticky vypla kompozitor a zobrazila varování že s timhle driverem to nemusí fungovat a zapnutí je na vlastní nebezpečí. už teď je tam v tom konfiguračnim dialogu řada varování že ta a ta volba nemusí fungovat nebo že to bude pomalý...

[Hans1024]

Me se zda, ze podstatna cast aktivne vyvijeneho svobodneho SW ma presne opacny problem. Vetsinu vyvojaru zajima jenom to, jak to cele popadesate prekopou, samozrejme ve jmenu zarive a dokonale budoucnosti a vubec je nezajima, v jakem stavu je stabilni verze, na ktere prave ted jede cely svet. Stabilni verze je pro ne jenom snapshotem nejakeho jejich rozpracovaneho prekopavani z davne minulosti, misto toho, aby byla cilem jejich cinnosti.

[Václav "Darm" Novák]

A to jen do chvíle kdy to udržovat dále nejde a je potřeba „funkcni a spolehlivy produkt nahradili nedodelanym nefunkcnim zmrdkem“… Což bych o Plasmě 5 rozhodně netvrdil, ale což. Právě díky čistotě návrhu a modularitě se udržitelnost nového KDE dá očekávat.

[kyknos]

zajimave je, ze prinejmensim v pripade toho gnome, se forky stareho dobreho gnome normalne dal udrzuji a funguji :)

[pavlix]

Z mého pohledu má Gnome jednu obrovskou výhodu v rámci linuxového ekosystému, že je napsaný v céčku. Sice glib nemá kdovíjak zázračné API a GTK si tak úplně netroufám hodnotit, ale přijde mi, že C++ přináší hodně komplikací a nepřinese za to odpovídající výhody. To je dobře vidět i na jiných než GUI projektech, třeba na Squidu. Ale je mi jasné, že se mnou nebude zdaleka každý souhlasit.

[kyknos]

navic mluvit ze strany KDE vyvojaru o dlouhodobe udrzitelnosti, kdyz funkcni a spolehlivy produkt nahradili nedodelanym nefunkcnim zmrdkem, to je opravdu chucpe :D

[Agent]

Mám trošku pocit, že mícháš hrušky a jabka. A co si představuješ pod pojmem dlouhodobá udržitelnost? KDE 4 je na světě nějakých cca 8 let, což mi (v IT) nepříde jako krátká doba. Jinak ano, minimálně zpočátku bylo jeho nasazování kapku uspěchané, mělo se tak rok počkat. Ale pak už to bylo v pohodě.

[kyknos]

nepripada mi v pohode, radsi widle nez KDE4/5

[xkucf03]

+1

[LukynZ]

Na xfce se nenabali ani stare babiny. Budme radi za KDE, to alespon drzi hrdost linuxove desktopu v nejake vysi. Zbytek je tragedie z minuleho stoleti (ci tisicileti?)

[pavlix]

Na balení je Apple, Linux je na práci.

[LukynZ]

Opet plati vyse napsane...budme radi za KDE

[kyknos]

v KDE pracovat? :D

[Václav "Darm" Novák]

Tak mi vysvětli proč v KDE pracovat nemůžu, třeba mě přesvědčíš a nechám toho :P

[LukynZ]

Protoze to je KDE, to da rozum. Umi to sice vsechno, co umi jakykoli ostatni DE a spoustu navic, ale je to KDE, takze ne, na tom se nepracuje. Pracuje se zasadne na social desktopu z 90. let. To bys mel vedet!!!!111 :D

[kyknos]

tobe to nezakazuju, pokud jsi nenarocny, a nevadi ti ruzne bugy, viz tento blogpost, tak jiste muzes... ja mam ale radsi efektivni prostredi, ktere mi neprekazi, neni rozbite a nezere pulku vykonu pocitace

[kotyz]

kde má pár vychytávek usnadňujících práci a tý paměti a procesoru taky moc nežere, za to můžou hlavně ty indexovací démoni který by mělo jít odinstalovat nebo aspoň vypnout kdyby je některá aplikace měla jako závislost. jo, ty bugy, to už je horší, sice za většinu asi fakt můžou ty grafický ovladače, ale tam neni imho moc naděje že by to v dohledný době někdo opravil a když to nějak neošéfujou v kde, bude to rozbitý pořád... možná to nakonec dospěje k tomu že budu používat kde aplikace pod lxde/lxqt...

[Josef Kufner]

Náhodou už to v KDE pořešili. Co jsem si teďka po update všimnul, tak se plasma i kwin celkem svižně restarují po té, co padnou na hubu. Byly doby, kdy to chcíplo a zůstalo chcíplé.

[=^..^= AmigaPower®]

Nj Ale o jakym HW se bavíme?

Já tady mam Centrino (sing) Mobile s 512MB RAM, sice se mi každá flashovatější pornostránka otvírá 2-3 minuty, ale přece to nevyhodim, když to funguje, mam k tomu dvě 2,5h držící baterky a na ty vymrdávky který na tom dělám to bohatě stačí...

[kotyz]

plasma se zrestartuje sama, ale kwin sem musel vždycky znova spustit ručně. i ve verzi 5.5.3. a tohle bych zrovna jako řešení neoznačil

[Václav "Darm" Novák]

No, já to právě používám proto že jsem celkem náročný a chci efektivní prostředí které nepřekáží :) Works for me, takže rozbité taky neplatí. Žere to o trošku víc než xfce i s indexací. (a podstatně míň než Windows + AVG).

[=^..^= AmigaPower®]

Hele Darme, Ty prej máš žábry?

[Václav "Darm" Novák]

Maximálně tak kopyta :)

[kotyz]

já mam zas chlupy, pruhy a vocas. a zatahovací drápky

[kyknos]

vocas mam taky

[xkucf03]

Plasma 5.5 je zabugovaná jak prase … To až teď. Jinak starej bug s tim že když se zavře okno konsole křížkem tak tam ten proces zůstane viset a žere 100% cpu tam je furt. A prej to dělá jen na nvidii s binárnim driverem (z toho mam neblahý tušení že lidi od kde/plasmy se na to vyserou jelikož u nich to rozbitý neni). Což je přesně to co mám...

Což je přesně to, o čem jsem psal v téhle diskuse.

[Jardík]

Kdysi dávno jsem nemohl příjít na chuť KDE4. Bylo to pomalý a sekalo se to, s opensourcce radeon driverem (int grafika v A10-7850) ... pak jsem přišel na to, že když zapnu composite přes xrender, tak to běhá nádherně rychle, neseká se to a poruchy obrazu už nejsou. Pak přišlo KDE5 a vše od znova. Pomalé, seká se to, občas artefakty. Hledám hledám nastavovátko v compositoru na xrender ... a nenacházím. Je to teď moc chytré a detekuje si to samo, co je dobré. Nakonec jsem našel nějaký konfigurák (jehož cestu se teď nepamatuju), kde se to dá růčo vepsat a změnit na xrender. Provedl jsem změnu a .... pro můj údiv, je to ještě pomalejší než před tím. KDE5 je tedy oproti KDE4 velký pokrok, běhá pomaleji. Navíc to nové ošklivé do očí pálící téma.

[Blaazen]

Nastavení sytému -> Obrazovka a monitor -> (nalevo) Kompozitor a tam je kombo: Vykreslovací podpůrná vrstva, na výběr s OpenGL a XRenderu.

Já mám ATI Radeon 4670 + xf86-video-ati a přijde mi to stejně rychlý jako KDE4. Spíš mi chybí featury.

[Jardík]

Dobře, mně se to posledně najít nepodařilo, v KDE4 to bylo někde v nastavení efektů.

[Bedňa]

Vykreslovanie cez Xrenderer je lepšie pri slabších kartách, hlavne Intel, toto platí všeobecne, ale určite sa nájde aj výnimka. Na lepších kartách zas lepšie funguje vykreslovanie cez OpenGL, hlavne u NVidii. Ono to je aj kombinácia karta a ovládač, tu som o tom písal, osobne používam kompozitor Compton.

[Josef Kufner]

Spíš bych řekl, že záleží na aktuální náladě ovladačů a stavu jednotlivých bugů. Pokud 2D funguje zrovna dobře, tak Xrender je dobrá volba. Celkem nedávno mi Intel grafika fungovala lépe, když se jelo přes GLX.

[Bedňa]

Je to tak nejak a keď sa k tomu pripojí rozbitý kompozitor z KDE, tak to je len bonus. Pokiaľ tvorcovia KDE chcú hodiť ukončovanie aplikácií na NVidiu, tak nepochopili pointu Window Managera.

Celkem nedávno mi Intel grafika fungovala lépe, když se jelo přes GLX.

Ak to bola novšia Intel grafika, tak tam už je situácia úplne iná.

[kotyz]

já to s opengl používat nemoh, kvůli glitchům a pádům. s xrender to bylo spolehlivější, až do dneška. dneska už to bylo nepoužitelný.teď to mam s nouveau ovladačem a funguje to hezky, ale zase nefungujou jiný věci (steam se nespustí, google earth padá, v openareně je moc tmavej obraz a nejde přidat jas, secondlife se seká ještě o něco víc než předtim). zkusim jak to bude chodit v archu, tam by měly bejt o kapku novejší verze od všeho...

[Bedňa]

v openareně je moc tmavej obraz a nejde přidat jas

Nechápem, že sa autori ovládačov nezhodnú ani na takej maličkosti ako je ovládanie jasu a podobne.

Je to zas rozdielne karta a ovládač, treba vyskúšať:

xrandr --output DVI-D-1 --crtc 0 --gamma 2:2:2

xrandr --output DVI-D-1 --crtc 0 --brightness 2

nvidia-settings --assign RedGamma=2.3 --assign BlueGamma=2.3 --assign GreenGamma=2.3

xgamma -gamma 2

Takže hru spúšťaš scriptom kde sa najprv nastaví gamma, potom sa spustí hra a na záver to vrátiš na jednotku, napr:

xgamma -gamma 1

Výstup si samozrejme zistíš cez xrandr. Môj výstup:

Screen 0: minimum 8 x 8, current 1600 x 1200, maximum 8192 x 8192
Unknown-0 disconnected primary (normal left inverted right x axis y axis)
Unknown-1 disconnected (normal left inverted right x axis y axis)
TV-0 disconnected (normal left inverted right x axis y axis)
DVI-D-0 disconnected (normal left inverted right x axis y axis)
DVI-D-1 connected 1600x1200+0+0 (normal left inverted right x axis y axis) 400mm x 300mm
   1600x1200     60.00*+
   1280x1024     85.02    75.02    70.00    60.02  
   1024x768      85.00    75.03    70.07    60.00  
   800x600       85.06    75.00    72.19    60.32    56.25  
   640x480       85.01    75.00    72.81    65.99    59.94

U mňa je aktívny výstup DVI-D-1 podľa DVI-D-1 connected.

[kotyz]

to se mi moc nelíbí. tam přímo ve hře je pod settings - display nastavení jasu. s nvidia driverem to šlapalo, s nouveau to nedělá nic...

a steam zas padne na nějakym X erroru:

Running Steam on ubuntu 15.10 64-bit
STEAM_RUNTIME is enabled automatically
[2016-01-23 22:22:47] Startup - updater built Dec 14 2015 11:15:53
SteamUpdateUI: An X Error occurred
X Error of failed request:  BadValue (integer parameter out of range for operation)

[Bedňa]

to se mi moc nelíbí

Prečo je to easy.

Inak si nezahráš, tvorcovia hry a ovládačov budú tvrdiť že to má rozbité Mesa a nič sa opravovať nebude, toto je obohratá pesníčka.

[kotyz]

tak já jí stejně nehraju, mam jí tam spíš kvůli tomu abych ověřil funkčnost 3d akcelerace (ještě by se hodilo počítadlo fps v levym hornim rohu) jen mě decínko sere že něco co vždycky fungovalo najednou nefunguje...

[=^..^= AmigaPower®]

jen mě decínko sere že něco co vždycky fungovalo najednou nefunguje...

...jo tywoe, tak to se těš až ti potáhne na 40

[kotyz]

jako že přijde plešatost a problémy s erekcí? to první už přichází a toho druhýho se ještě pěknejch pár let nebudu snad muset bát...

[=^..^= AmigaPower®]

...pár, hmmm, to jsou dva

[Fluttershy, yay!]

přijde plešatost (…) to první už přichází

O potenciálně vyšším riziku rakoviny prostaty jsi slyšel?

[kotyz]

ne, díky za připomenutí že ještě čekaj pěkný věci... :-/

[kyknos]

a pritom je to jen kod, kterej se da opravovat stejne jako ten v pocitaci :)

[Václav "Darm" Novák]

Příloha:

• Screenshot_20160123_171050.png (44190 bytů)

Možná jenom špatně hledáš :) Téma je otázka vkusu, osobně jsem si breeze zamiloval na první pohled.

[xkucf03]

Zrovna na tom obrázku, co jsi přiložil, vypadá dost hnusně (minimálně ty přetékající šipky u nápovědy a combo boxů).

Když odhlídnu od takových chyb, tak celkově mi to na první pohled přišlo spíš odpudivé, i když časem se na to zvyknout dá.

[Blaazen]

Přepnout Breeze zpátky na QtCurve bylo to první, co jsem v Plasmě 5 udělal. Jenže v KDE4 bylo QtCurve krásně konfigurovatelné, byly tam styly (Silk, Flat, Human atd.). To už v Plasmě nejde. Mně se vlastně moc nelíbil ani Oxygen.

[kotyz]

jo, qtcurve/plastik je nejlepší. breeze se mi nelíbí, hlavně ty černobílý flat ikonky. teď tam mam oxygen, neni to nic moc, ale lepší než default. až budu mít čas a náladu řešit pičovinky tak nějaký další témata vyzkoušim, ale silně pochybuju že existuje nějaký dokonalý a univerzální (aby vypadalo všude stejně a fungovalo na gtk2, gtk3, qt4, qt4, plasma).

[Václav "Darm" Novák]

Hm, pravda. Dneska jsem si hrál s tématy, je možné že jsem si to rozbil sám.

[kralyk z abclinuxu]

Příloha:

• Screenshot_20160123_195615.png (145419 bytů)

Asi jo, u mě na Breeze vypadaj ty šipky celkem normálně...

[Thyrst']

To samé mi kdysi dělal Linux Mint. Na vině jsou IMHO hlavně dojebané ovladače od nvidie, až si budu příště kupovat noťas, nejspíš dám přednost AMD Radeonu.

[kotyz]

nvidia se vždycky doporučovala jako lepší volba pro linux. žeby se časy změnily?

[mimi.vx]

ony se zmenili celkem dost davno. Jen zvyk stale vede rikat k tomu ze ma NV good ovladace.

 

binarni se ceklem dajíi ,ale dovnitr nikdo nevidi a pokud je tam bug co nv netrapi  nebude opraven nikdy. + ma celkem nV rozporuplne kroky okolo oss ovladacu

 

U AMD se u novych karet musi pocitat s tim ze se pouzije Catalyst/fglrx ale dost brzo se dostane slusna podpora ze strany OSS ovladacu ( ktere jedou dobre na vsem krome nejnovejsi GCN) a ve vyhledu to diky AMDGPU vypada dost dobre jak pro nejnovejsi tak starsi karty AMD

[Václav "Darm" Novák]

Člověče, taky jsem dlouho preferoval Nvidii, ale teď mám ve služebním notebooku přepínatelný radeon a po vyzkoušení – přepínání grafiky přes DRI_PRIME funguje naprosto skvěle, OSS drivery jsou překvapivě výkonné… Nouveau je proti tomu bída. V desktopu asi bude má příští volba AMD.

[peter]

Po dvoch rokoch cakania na ovladace od AMD, ktore by zvladli kombinaciu Intel/Radeon HD 8750M (skusal som asi kazdu verziu co vysla) som radsej isiel do Nvidie. Propietarne Nvidia ovladace su zatial fajn, hry funguju, karta sa neprehrieva. OSS drivers pre radeon sice isli, aj DRI_PRIME bolo super, ale napr. v Civ V, XCOM a Tomb Raider (wine) sa pravidelne vyskytol pripad, ked sa zasekli a musel prist restart.

[MadCatX]

Tohle je na 99 % problém s ovladači grafiky. Jestli máš nějakou starší nVidii s binárním blobem, vsadil bych na to i poslední hrnek kafe. Na starém notebooku jsem Plasmu 5 s GF9800 provozoval a pády a záseky KWinu byly na denním pořádku. V novějším stroji s Intelkou jsem neměl s KWinem zatím jediný problém, dokonce i VSync docela funguje. Další hodně pozivitní zkušenosti mám s Radeonem s FOSS ovladači na Gnome Shellu. Grafiky od nVidie se obecně považovaly na Linuxu za jediné použitelné, protože ovladače k čemukoliv jinému buď v podstatě neexistovaly (různé vylomeniny jako SiS), byly enormně rozbité (fglrx, který tak vydržel dodnes) nebo přímo sama grafika stála za roztrhanou bačkoru (staré Intelky). Linuxové FOSS ovladače jsou hezká demonstrace toho, jak to jde, když se chce a nVidií způsob vývoje začína ukazovat nevýhody uzavřeného softwaru.

[Fluttershy, yay!]

Mně teda vadí jiné věci, ale to bude tím, že nepoužívám blob.

V kubuntu-backports byla aktualizace na 5.5 blbě zabalená, takže jsem končil na černé obrazovce, dokud jsem nezopakoval aktualizaci z terminálu. Teď už mě jenom prudí, že nemůžu najít nastavení zámku obrazovky (v Chování desktopu záhadně chybí) a pár maličkostí. Ačkoliv Breeze je furt odporné.

[Václav "Darm" Novák]

Jestli to nemáš v Desktop Behavior, mají to rozbité v Ubuntu :)

[Fluttershy, yay!]

Ehm, nemají to rozbité, akorát se ten KCM přesunul do samostatného balíčku (kde-config-screenlocker), který je leda tak doporučený, ale určitě není v povinný závislostech.

[Václav "Darm" Novák]

No, pokud není součástí metabalíčku kompletního KDE desktopu, považoval bych to za chybu :) Zvlášť u Ubuntu, kde se přeci jen předpokladá že člověk nebude lovit součásti desktopu po balíčkách.

[Fluttershy, yay!]

Mám vypnutou automatickou instalaci doporučených balíčků jako závislostí. To s tím může souviset. Ale nedělal bych předčasné závěry, tohle jsou balíčky z backports a příslušné vydání je zatím v alfě.

[=^..^= AmigaPower®]

Kurva to už je KDE5.5? :O Co bylo špatně na 3.5.7?

[Fluttershy, yay!]

Co bylo špatně na 3.5.7?

Dávno nepodporovaná verze Qt a nabobtnalý nekoncepční bordel. Kdo si vzpomene na zvěrstva jako aRts? Nebo nabobtnalé, nepřehledné konfigurační dialogy?

[=^..^= AmigaPower®]

3.5.7 fungovalo výborně.

[kyknos]

+1

od te doby same regrese

[=^..^= AmigaPower®]

KDE4 už pro mně bylo nepoužitelný, vždycky jsem měl za to, že mi výkon žere CF, tak jsem ho odinstaloval, jaký to pak bylo překvapení, když se nic nezměnilo? Od tý doby LXDE s, nebo bez CF, podle RAMky, Teď píšu z Centrina Mobile s 512MB, takže bez.

[MadCatX]

Až na aRts, co klidně zbaštil 30 % CPU, i když se nic nedělo. Nebo IPC přes DCOP, protože tehdá nebyl DBus. Správa hardwaru přes ultimátní moloch HAL působí v porovnání s udisks2 nebo upower jako fosílie z prekambria. Tohle nostalgizování nad dobou, kdy Linuxový desktop byl v podstatě fór, co držela pohromadě lepicí páska a tuny hacků tak úplně nechápu. Tenkrát byl problém přehrát MP3ku, když se Pidgin rozhodl obsadit zvukovku přehráním nějakého notifikačního písknutí. Kombinace kompozitoru a HW akcelerovaného výstupu či videa na Xv overlayi se korektně vykreslovala jen pár šťastlivcům. USB flasky se připojovaly ručně z konzole. Rozjet OpenGL na čemkoliv jiném než kartě od nVidie bylo skoro nepředstavitelné. KDE 3.5 možná fungovalo spolehlivěji než první verze KDE 4, ale také toho moc neumělo. KDE 4 přišlo s několika zajímavými nápady, které mi jinde dost chybí, zejména na Widlích.

[Václav "Darm" Novák]

Jo, tahle nostalgie… Teď nedávno jsem zkusil KDE 3.5 znova zapnout a asi bych se nevracel :)

[kyknos]

nemel jsme tehdy zadne problemy s prehravanim mp3... a s linuxovym desktopem jsem byl mnohem spokojenejsi nez dnes

[=^..^= AmigaPower®]

+1

90% těch zkratek se kterejma bych měl mít problém ani neznám Možná jsem o nich neslyšel proto, že všechno fungovalo jak mělo a tak jsem necejtil potřebu se v tom hrabat

[Hans1024]

Jestli bylo KDE3 naboptnale a aRts zverstvo, tak je KDE5 explodujici slunce a pulseaudio genocida.

[kotyz]

třeba takový akonadi, který sežere snad víc ramky než samotný kde a přitom nedělá nic užitečnýho...

[MadCatX]

Akonadi samotné moc paměti nezbaští, něco spolkne akorát MySQL backend. Třeba na indexování mailů je Akonadí náhodou docela užitečné. V situaci, kdy má člověk několik mailových schránek, ve kterých se občas musí hrabat je předpřipravená databáze šikovná.

[Fluttershy, yay!]

KDE3 nabobtnale (…) KDE5 explodujici slunce

FTFY Ano, to uživatelské rozhraní bylo naprosto katastrofální (dialog pro konfiguraci panelu byl typický příklad). Ale jsem smířen s tím, že psát to tobě je hra squashe hrachem. Zrovna Plasma 5 je v tomhle směru dramatickým zlepšením (třeba organizace Nastavení systému konečně dává smysl).

aRts zverstvo (…) pulseaudio genocida

Minimálně je tu zásadní rozdíl v NIH. Ostatně, v kontextu aRts je kritický hlavně Phonon.

[R]

Kolkokrat denne konfigurujes panel alebo ine veci?

[Fluttershy, yay!]

Pokud to UI stojí za prd, tak nikdy (a budu používat něco jiného, nebo budu frustrovaný stávajícím chováním), nebo déle, než by bylo žádoucí.

Kouzelné to bylo navíc toho času na netbooku, kde se některé ty konfigurační dialogy ani nevešly na obrazovku a navigace v nich byla za trest.

BTW zmínka o explozi je u „KDE5“ překvapivě trefná, vzhledem k modularitě (na rozdíl od dřívější kdelibs apod. mimo KDEmod).

[R]

Ano, niektore sa mi na netbooku na obrazovku pri 800x480 skutocne nevojdu. Staci ich posunut cez alt+mys. Teraz mame v GNOME takmer prazdne dialogy, ktore sa nevojdu na obrazovku ani pri full HD a presunut ich nie je mozne.

[kyknos]

:D

progres

[Fluttershy, yay!]

Staci ich posunut cez alt+mys.

Přesně to je znakem selhání.

Teraz mame v GNOME takmer prazdne dialogy

Což je rovněž selhání.

pri full HD

To považuji za další selhání.

[pavlix]

+3

[kotyz]

gnome's hell je jedno velký selhání

[Hans1024]

Ty jses takovy UI fasoun, ze se divim ze nepouzivas Gnome

[kyknos]

lol

[Fluttershy, yay!]

To je „argument“ asi tak na úrovni právě designérů GNOME.

[mirec]

Asi tá rýchlosť sa im nepáčila. Včera som skúšal KDE 4. Kompletný boot systému (od kernelu po awesome) mi na mojom thinkpade trvá 2s. S KDE4 je to 20s (druhý štart, prvý bol katastrofálne pomalý).

[xxxs]

4 a 5? alebo 3 a 4?

[mirec]

Kedysi som používal 3, pred vydaním 4 som skúšal 4, páčil sa mi smer akým to ide ... lenže sa to posralo. Štvorku som včera inštaloval na nový stroj zo zvedavosti, na 5 sa nechystá kým nebude stable v gentoo.

[Grunt]

Necpe se ti tam náhodou Wayland? Podobného efektu jsem dosáhl když jsem ho kdysi testoval.

[Václav "Darm" Novák]

Nemyslím si, zvlášť když jede na proprietárních driverech. Tam by mu nenastartovalo nic.

[_]

GNOME for win !

[Frank]

+1

[pavlix]

Gnome ftw? Nebo Gnome for Microsoft™ Windows™?

[kotyz]

gnome's hell na widlích? jakoby windowsáci už netrpěli dost...

[Rezza]

Brzy by mel byt open source SW rasterizer pro Qt Quick. Sice to asi nepujde jen tak nahradit skrze shadery, ale mohla by to byt nadeje jak se vyhnout OpenGL (bez llvmpipe). Protoze ta vec nikdy nebude fungovat s kvalitou ovladacu a nejak ani Valve a Steam v tom moc nepomaha...

[lobotron]

To jsem jako jedinej, komu plasma normálně funguje?

[kotyz]

ne, už ste tři

[MadCatX]

Určitě ne, schválně jsem dnes nahnal Plasmu do trochu nebezbečnějších vod více monitorů:) Na to, že to běží na Xkách, kde je víceminitorový setup odjakživa zlo non plus ultra to docela jde. KScreen funguje dobře a rozložení displejů nastaví správně. Je trochu překvapující, že Plasma si pamatuje i věci jako nastavení widgetů pro každý displej zvlášť, takže pokud chci mít jako primární displej velké LCDčko místo displeje na laptopu, musím tam ručně přidat hlavní panel atp. Zezačátku trochu matoucí, ale na druhou stranu si umím představit, že to může být velmi užitečné.

Trochu hůř jsou na tom samotná Qtčka. Plasma sebou občas třískne při připojování či odpojování externího displeje, ale podle backtracu to spíš vypadá na bug v XCB QPA. QtQuick má s multimonitorovou konfigurací taky trochu problémy, třeba comboboxy se vždy vykreslí na tom displeji, kde se widget původně objevil i pokud jej přetáhnu na jiný monitor, což je doopravdy hloupé. Opět ale jde nejspíš o bug v XCB pluginu Qtček.

[Rezza]

Pokud chces mit primarni velke LCD, tak nastavis, ze ma byt primarni a Plasma tam (obcas) spravne presune panel. Bohuzel vice monitoru je opravdu porad pruser... V Qt uz se to opravuje pres nekolik verzi, ve Fedore uz by to nemelo padat, protoze je tam kupa patchu. Dokonce prvni kopani do toho XCB zacalo ve Fedore :).

[MadCatX]

Pokud chces mit primarni velke LCD, tak nastavis, ze ma byt primarni a Plasma tam (obcas) spravne presune panel.

Přesně tohle se právě nestalo, musel jsem si ho přidat ručně. Na druhou stranu si to nastavení Plasma zapamatovala i přes restart, což je daleko zásadnější. Na notebooku mám Arch, tak nevím, ale zas tak hrůzostrašná zkušenost to zatím není. Přímo při práci to ještě nespadlo:) Každopádně do XCB pluginu mlaťte dál, je to na dobré cestě;)

[LukynZ]

Tak uz je nacase to konecne prejmenovat na: Ovladace jsou zabugovane jak prase, ne? :)

[kotyz]

ona plasma/kwin dokáže spadnout i na nouveau, jen to nebejvá často. a bez "speciálních efektů" jako ten nahoře...

[LukynZ]

Ono nouveau nejsou taky zadna vyhra...bohuzel. S mou GTX650Ti proste nahodne tuhne cely pocitac. Blob to nedala, ale ma jine mouchy. Taky to zacinam videt opet na ATi(AMD)

[kotyz]

aby to nebylo z deště pod okap...

[LukynZ]

Na jejich OSS drivery ctu jen samou chvalu, tak si rikam, ze to za ten pokus mozna stat bude

[Václav "Darm" Novák]

K chvále se i jako bývalý fanoušek closed source Nvidie rád připojím. Výkon je pochopitelně o něco málo nižší než by být mohl, ale vše ostatní v pohodě, včetně Power managementu (dokonce i přepínání grafiky u laptopu funguje skvěle, zvlášť když se zapne DRI3)

[Dreit]

Mám APU od AMD, nějakej Richland to je...a s tím "radeon" driverem to jede jako po másle. Stejně tak předchozí karta co teď používá brácha v Mintu (tam už nově s fglrx). A třeba TeamFortress2 si tam zahraješ taky

Nvidia byla dobrá dřív. Vzpomínám když mi blob od nvidie fungoval skvěle a fglrx svoji instalací po*ebal co šlo, Xka už jsem potom ani nenahodil. Už tehdy driver "radeon" běhal perfektně a "fglrx" jsem chtěl jen v touze po hraní her. Asi před rokem jsem ze zvědavosti zkusil nVidii G210 z šuplíku. Nouveau katastrofa, proti radeonu to bylo takový celý pomalý, divný. Pak jsem zkusil binární blob a ten mi vynadal, že mám moc novej Xorg (podporuje něco co starší verze neuměla, dokonce to vypsalo jakou funkci) a že jako máš smolíka a kup si novou kartu, nebo downgraduj všechen soft kolem Xorgu. Ono u blobu je sranda už jen s verzí gcc kterou vyžaduje - novější to někdy sežere, někdy odmítne, v nejnovější kterou blob zná to zase někdy nedoběhne do konce...tak šla nVidia z domu

[Grunt]

/usr/lib/xorg/modules/extensions/libglx.so: undefined symbol: LoadExtension

Pěkně mě tím nasrali

[kotyz]

dvěstědesítku mam taky. řikal sem si že bych jí beztak vyměnil za něco lepšího, ale aby to bylo pasivně chlazený a bez potřeby přídavnýho napájení. co teda vzít? radeony prej víc žerou a topí proti nvidiím...

[kotyz]

jo a taky aby to moc nestálo, to je taky důležitej parametr. radši dam 6 tisíc za česfur než 3 tisíce za grafiku

[Fluttershy, yay!]

Záleží, co přesně chceš. Mě třeba od integrovaného intelu v dohledné době dostane leda zapojení třetího monitoru – v úvahu přichází jen a pouze Sapphire Flex (HD 6450, resp. R5 230).

[kotyz]

sice mam desku pro amd apu, má to výstup vga i hdmi, ale mam nějakej nižší model athlona x4 bez grafiky, takže jedině klasickou do pci-e. zase ne nějakej uplnej lowend když už se do toho budou muset nacpat prachy. akorát se už hodně dlouho nevyznam v tom co se prodává...

[Dreit]

Od toho mám Zaatharena