John Carmack má zájem o Wayland (diskuse)

[Honz]

Pokud to má být signál "dejte dokupy ten Wayland a pak pro to budeme dělat hry", tak je to dost dobrý...

[vain]

Id Software jak id Software, zrovna u nich mě to nepřekvapuje, ale aby takový názor měli i ostatní.

[mikirc]

nojo, ale pak prijdou vyrobci grafickych karet a reknou my vam drivery delat nebudeme a je vymalovano

[R]

Myslis jedneho konkretneho vyrobcu?

[Jardík]

Ve zprávičkách už je zmíňka o nvidii.

[Xerces]

Ty se nebudou ani namáhat, aby kamkoliv chodili a cokoliv řikali. Prostě se na to, ...

[Zdenek]

No pravda, moc daleko nesli, ale rekli to jasne.

[finn]

„Nemáme žádné plány ohledně podpory Waylandu“ neznamená „Wayland nikdy za žádných okolností nebudeme podporovat“.

[Xerces]

Přesně tak. To není odpor k Waylandu. To je daleko horší, to je absolutní nezájem.

[Bedňa]

Nie som nejaký borec cez HW >> drajvre, ale nieje to náhodou tak že časť medzi Xami a drajvrom je open source API? Možno sa mýlim, ale zdalo sa mi že som na také niečo natrafil pri vŕtaní sa v jadre.

[Pavel Beníšek]

Pri cteni Vaseho prispevku me napadlo jestli by nesel udelat nejaky wrapper xorg driveru pro Wayland. Neco podobneho jako je pro Windows-only Wifi karty. Tim by se podstatne ulehcil prechod a po par letech kdo vi .. treba nvidia povoli.

[xm]

Vzhledem k tomu, že proprietární NVIDIA ovladače v sobě implementují/nahrazují pomalu celý X server, tak by to asi nebyla sranda Ten binární humus si skoro vše dělá po svém a na standardizované věci kašle. To už by bylo možná jednodušší provozovat Wayland nad X serverem (jako X klient - něco jako Xnest/Xephyr).

Mnohem lepší je vynaložené úsilí vložit do reverzního inženýrství blobu, vylepšování opensource ovladačů Nouveau. Ať si NVIDIA se svým hnusným blobem nase*e!

Ale uplně nejlepší je nepodporovat NVIDIU nákupem jejích produktů, dokud nezmění svojí politiku a nezačnou podporovat vývoj opensource ovladačů podobně jako Intel nebo AMD/ATI. Já to tak dělám už léta a NVIDIA mi nijak nechybí.

[Salamek]

a co za GPU by jsi doporucil ? ATI-ze strany sw vetsi sranec nez nvidia (beru momentalni celkovou funkcnost,nepocitam provedeni) Intel- obcas si chci i neco zahrat

[xm]

Já s ATI pod Linuxem nemám na svých 3 počítačích (z toho 1 notebook) žádný problém, jsem navýsost spokojen (opensource ovladače).

2D, 3D, Xv, vsync, powermanagent, přepínání výstupů přes xrandr... vše funguje jak má. A co se týče 3D výkonu, tak mně postačuje (nicméně pokud někdo chce hrát nějaké náročné extra moderní 3D hry, s opensource ovladači to má zatím blbé - ovšem výkon se neustále zlepšuje).

[Bilbo]

Hmm ... jak jsou na tom vlastně momentálně opensource ovladače s podporou GPU výpočtů? (např. OpenCL, CUDA, ATI Stream ... funguje tam něco z toho s rozumným výkonem?)

[Jardík]

Ten byl dobrej

[majlo202]

mam za to ze powermanagement, respektive podtaktovavani ATI karet opensource ovladace zatim stale neumi.

[xm]

Samozřejmě že umí (podpora je dokonce díky KMS přímo v kernelu), zaspal jste dobu.

[trekker.dk]

2D, 3D, Xv, vsync, powermanagent, přepínání výstupů přes xrandr... vše funguje jak má.

Co takhle dual-head a software suspend?

[xm]

Dual head? Tím "přepínání výstupů přes xrandr" samozřejmě myslím i rožšíření plochy nebo clone mód, to je u xrandr standard. Funguje naprosto bezproblémově.

Tím "software suspend" myslíte co? Uspání do RAM nebo na disk? Taktéž naprosto bez problémů, probudí se vždy (odzkoušeno to mám však jen na notebooku, desktopy nevypínám ani neuspávám, ty mi běží pořád).

[trekker.dk]

Dual head? Tím "přepínání výstupů přes xrandr" samozřejmě myslím i rožšíření plochy nebo clone mód, to je u xrandr standard. Funguje naprosto bezproblémově.

Fajn. Co takhle "separate X screen"? Tedy dva nezávislé servery, na každém monitoru jeden - myš se může přesunovat mezi monitory, programy ne. (Možná někomu přijde tohle nastavení divné, ale mě to vyhovuje a u nouveau jsem právě zjistil, že tohle nastavení interpretuje jako clone mód.)

Tím "software suspend" myslíte co?

Myslím jaderný software suspend, tedy uspání na disk. Na desktopu.

Ale ok, ten ovladač podle všeho umí dost na to, aby byl použitelný. Až na to, že - alespoň podle wiki - když si koupím něco aktuálního, řekněme HD 5xxx, tak mám s opensource ovladačem smůlu, protože není.

Čímž se ovšem dostáváme do situace, kdy si buď mám koupit něco míň výkonného (mám i Windows), aby mi to chodilo i pod Linuxem, nebo použít binární blob a koupit nVidii.

[wertweqrtweqrt]

Nejsi jediný, "separate X screen" používám taky.

[Andy]

me prave to separate taky nefungovalo, proto jsem zpet u ati-drivers, jinak sem byl ale spokojen

[Grunt]

Já dva separátní X servery používal na hry. Na jednom serveru mi běží klasické GNOME a na druhém ve fullscreen módu hra. Běželo to perfektně a zprovoznit něco takového je jen o přidání pár parametrů do spouštěče dané hry. Něco takového myslím není možné ani ve slavných oknech. Tam vždycky grabne pointer hra a je domalováno (zvláště peprné to umělo být v kombinaci s net sendem). Právě z toho důvodu stěžování si herní komunity na nemožnost pouštět si své obíbené hry ve full-screen módu v composite nad Xkama chápu nejmíň.

[imploder]

Ve slavných oknech se dá z fullscreenu jednoduše dostat Alt+Tab. Je pravda, že ve starších verzích to někdy (u některých her) blblo, ale ve Windows 7 jsem se s tím zatím nesetkal - funguje to jak má. Zatímco ve slavných Xech to skoro u žádné hry nejde.

[Grunt]

Není tak úplně pravda. Např. pamatuju, že Call of Duty krom toho ještě umělo sebrat focus a ještě si nastavilo něco jako stay-on-top. S Alt+TABem se okno přeplo, ale zůstalo pod vykreslovací vrstvou, takže když jsem chtěl odepsat, tak pěkně poslepu. A některé hry to měly dotažené tak daleko, že ani ten focus darovat nechtěly (mám pocit, že zrovna něco jako Quake 3), takže jedinou možností bylo ALT+ENTER (a čekat než se celá mapa znova načte a po přepnutí do full-screenu rovněž) a nebo prostě hru vypnout. Ano, Xka se chovají podobně a nebo úplně stejně a proto zásadně spouštím hry na jiném Xserveru (CTRL+ALT+FX nebo chvt funguje vždy, nehledě na takové drobnosti jako je rozházení ikon na ploše kvůli změně rozlišení).

[imploder]

Mohl bys prozradit těch "pár parametrů", co dáváš do spouštěče? Já jsem to zatím zkoušel tímhle způsobem:

1. přepnu se do jiného VT (Ctrl+Alt+FX)
2. přihlásím se tam jako root a dám startx
3. přihlásím se do GNOME jako uživatel a to nastartuje (vyskočí nějaká varovná hláška, protože 2x GNOME pod stejným uživatelem si navzájem leze do konfiugurace)
4. spustím hru

S tímhle mi přepínání přes Ctrl+Alt+FX fungovalo, i když u Heroes 3 po přepnutí zůstával černý X-kurzor nalepený uprostřed obrazovky, protože hra používá softwarový kurzor (hardwarový asi při startu skryje a Xka ho po přepnutí automaticky zobrazí, ale hra o tom neví).

Nějak si nedokážu představit, jak se tohle udělá přidáním nějakých parametrů do spouštěče.

[Grunt]

Mohl bys prozradit těch "pár parametrů", co dáváš do spouštěče?

Jsem kvůli tomu musel vyhrabat a rozjet notebook:

startx /usr/bin/nexuiz -- :12 -br

Má to tu výhodu, že když aplikace skončí, terminál se sám přepne. Já si to nacpal nejprve do spouštěče na plochu, pak do spouštěče v nabídce a když jsem zjistil, že spouštěč v distribuci není nic jiného než shellový skript, tak nakonee i do něj.

[imploder]

Příloha:

• OsmosDemo-vlastni-x-server.txt (4370 bytů)

Díky moc. Funguje to, nový X-server se spustí, po skončení hry se zase ukončí.

Bodužel u mě teď při spuštění přes startx nejde 3D akcelerace (viz příloha). Nebo tuxracer:

Your system currently is not capable of hardware accelerated 3D. Therefore etracer cannot run.

Samozřejmě ovladače nainstalované mám (mesa).

Mám Fedoru, takže /etc/X11/xorg.conf je prázdný, všechno se dělá automaticky a nějak to funguje (jak přesně se X-server normálně spouští jsem nenašel, nikde v /etc/rc.d to zdá se není). Takže musím ještě zjistit, jak se ve Fedoře spouští Xka a proč normálně HW akcelerace funguje, ale při spuštění přes startx ne.

V každém případě dík za tip.

[imploder]

A jak se teda pak dostanu z jednoho serveru do druhého - je na to nějaká klávesová zkratka?

[trekker.dk]

Přejedeš myší a klikneš. Klávesová zkratka AFAIK není, ale viděl jsem (vygooglil jsem) na to krátký prográmek (musíš nicméně nějak zařídit jeho spouštění po stisknutí té zkratky a ne úplně vždycky funguje)

Když si vzpomenu, můžu ho sem v pondělí dát.

[imploder]

No, mně šlo spíš o to, jak se to přepíná na jednom monitoru. Ale to jde přes VT, jak napsal Grunt.

[Rovano]

Co máte za generaci GPU?

[xm]

Notebook r500, desktopy r600.

[Jiří J.]

Intel GMA4500 series - Mafia 1 přes wine jede okolo 35-40FPS

[belisarivs]

To je uspech. 7, nebo kolik, let stara hra na 35-40 FPS

[trekker.dk]

Mnohem lepší je vynaložené úsilí vložit do reverzního inženýrství blobu, vylepšování opensource ovladačů Nouveau.

Hm, to jsem zrovna včera zkusil. Nevím, jestli to bylo upgradem x.org nebo přímo Nouveau, ale přestalo mi fungovat rozdělení na samostatné monitory (místo toho jsem měl jednu velkou plochu, což nechci) Jediná změna xorg.conf přitom byla Driver "nvidia" na Driver "nouveau".

Takže návrat k původní verzi a blobu.

(Poznámka: pozor, Linux klidně vytvoří softwarový raid 1 ze dvou disků, na kterých nejsou stejná data, aniž by následně udělal resync.)

[Jiří J.]

(Poznámka: pozor, Linux klidně vytvoří softwarový raid 1 ze dvou disků, na kterých nejsou stejná data, aniž by následně udělal resync.)

Nevím, jestli se to mělo nějak vztahovat k textu nad tím, třeba jako součást metaforické konstrukce, ale pokud ne - mdadm automaticky pouští při vytvoření resync, při důkladném zkoumání manpage lze přijít na nějaký switch, který to (jak je tam zdůrazněno - pro testovací účely) může potlačit, ale defaultně to rozhodně není.

[trekker.dk]

Žádná metaforická konstrukce, to se mi opravdu stalo. A jo, taky jsem si myslel, že mdadm po sestavení pole udělá resync. Není to vždy pravda.

Měl jsem MD zařízení složené z oddílů A a B, následoval (zjednodušeně) tento postup:

mdadm --fail MD B # B bude záloha a na A něco zkusím
mdadm --remove MD B

- následovalo testování a rozhodnutí, že obnovím zálohu, reboot, boot live CD

mdadm --assemble MD --run B # bez --run se nespustí, protože chybí zrcadlo
mount MD někam # ok, je tam to, co tam chci
umount někam
mdadm --stop MD
mdadm --assemble MD --run B
mdadm --add MD A

A tady jsem čekal, že začne resync B na A, protože A není oproti B aktuální. Místo toho se nestalo nic, takže po

mount MD někam

jsem v někam našel akorát poškozený souborový systém. Odnesla to databáze balíčků (naštěstí dpkg dělá zálohy) a možná ještě něco, na co jsem zatím nepřišel.

A ne, nějaký switch jsem opravdu nepoužíval.

[Jiří J.]

Ten switch je --assume-clean a je jen pro vytvoření array.

Pokud ten postup byl proveden tak, jak popisujete, pak se mdadm zachoval správně! Hned první příkaz označuje B za "faulty", tedy něco, s čím se už nemůže počítat jako s validní nohou mirroru. To, že je něco označeno jako faulty a odstraněno (--remove) neznamená, že se z toho smažou metadata. Ta tam zůstávají, protože jsou i admini, kteří místo --re-add používají --add, čímž by se snadno daly vyměnit minimálně indexová čísla disků v poli.

Pokud se nepletu, tak "mdadm --assemble MD --run B" není validní syntaxe, disk "B" byl odstraněn z pole, navíc --run nemá žádný argument. Stejně tak nelze přidat "A", protože už v poli je.

Proto používám 0.90 metadata na RAID1 - pokud chci něco zkusit, dám mdadm --set-faulty MD A, odstraním A a můžu na něm vesele testovat, jakoby to byl normální disk (až na posledních pár bajtů), přitom RAID jede vesele dál. Pak stačí jen --re-add a resync se pustí automaticky.

[Jiří J.]

Tedy chci říct, že v takové situaci by měl obsah A přepsat disk B (protože právě B byl označen za faulty). Pokud se nestalo nic (žádný resync), pak je to opravdu chyba mdadm nebo linux MD.

[trekker.dk]

Tedy chci říct, že v takové situaci by měl obsah A přepsat disk B (protože právě B byl označen za faulty).

Jenomže to, že byl označen za faulty, se na něj nezapsalo, ne? A i kdyby jo, tak následné vytvoření pole s B by ten příznak zase mělo smazat. Logicky, pole přece nemůže fungovat jenom s jedním faulty diskem.

Takže po mdadm --stop MD by "Update Time" na oddílu B měl být novější, než na oddílu A, logicky by tedy měl začít resync z B na A.

Každopádně se nestalo nic.

[Jiří J.]

Jenomže to, že byl označen za faulty, se na něj nezapsalo, ne? A i kdyby jo, tak následné vytvoření pole s B by ten příznak zase mělo smazat. Logicky, pole přece nemůže fungovat jenom s jedním faulty diskem.

Správně, protože je disk faulty, nelze spoléhat ani na to, že update metadat proběhne v pořádku, proto se metadata na faulty disku nemění, ale všechny ostatní disky v poli dostanou záznam, že onen disk s takovým a makovým UUID je faulty (v mdadm -E je místo "active sync" stav "removed") a tak to zůstane až do ručního odebrání disku (minimálně).

Co se týče zbytku příkazů - netušil jsem o možnosti ručně sestavovat RAID1 po jednotlivých zařízeních, proto mě trochu zarazilo to --add MD A, určitě pro to není jiný příkaz? Vždyť v momentě odebrání "faulty" disku B byl pořád A součástí pole, disk B měl záznam o dalším disku A v poli a v momentě aktivace pole jen s diskem B by měl být stav [_U], tedy přidávat (--add) znova disk A do pole nemá smysl, protože už tam je, jen není aktivovaný. To možná napadlo i mdadm a disk prostě aktivoval a resync nespustil (protože A nikdy nebyl faulty, ani v metadatech na disku B), zatímco disk B faulty byl (v metadatech disku A), ale po --remove se ten stav pravděpodobně smazal (a nahradil něčím jako "missing"). Proto podle mdadm nebyl resync nutný.

[trekker.dk]

Co se týče zbytku příkazů - netušil jsem o možnosti ručně sestavovat RAID1 po jednotlivých zařízeních

V podstatě je to totéž jako vytvořit pole v degradovaném režimu.

proto mě trochu zarazilo to --add MD A, určitě pro to není jiný příkaz?

Pravděpodobně --re-add, ale protože na A jsou taky metadata, --add se automaticky chová jako --re-add (alespoň jestli jsem správně pochopil dokumentaci)

Vždyť v momentě odebrání "faulty" disku B byl pořád A součástí pole, disk B měl záznam o dalším disku A v poli a v momentě aktivace pole jen s diskem B by měl být stav [_U], tedy přidávat (--add) znova disk A do pole nemá smysl, protože už tam je, jen není aktivovaný.

Možná z pohledu disku B. Jenže pole sestavuje kernel a ten snadno pozná, že tvrzení "A je už v poli" je blbost, protože ho tam nedal.

To možná napadlo i mdadm a disk prostě aktivoval

Ne, disk jsem musel aktivovat já ručně.

(protože A nikdy nebyl faulty, ani v metadatech na disku B), zatímco disk B faulty byl (v metadatech disku A), ale po --remove se ten stav pravděpodobně smazal (a nahradil něčím jako "missing"). Proto podle mdadm nebyl resync nutný.

Je to možné, ale je to špatně. Relevantní údaj je logicky čas "update time"; když není stejný na obou zrcadlech, nelze bezpečně předpokládat, že jsou na nich stejná data.

Teď jsem to zkusil na novějším jádře a zdá se, že tady už to opravili. Při stejném postupu se synchronizace spustila.

[trekker.dk]

To, že je něco označeno jako faulty a odstraněno (--remove) neznamená, že se z toho smažou metadata.

Jo, s tím jsem počítal. Proto to pole šlo nahodit jenom s B. (Ono --fail dost pravděpodobně znamená, že disk je vadný a nedá se s ním pracovat. Pokoušet se na něm něco měnit by bylo možná docela hloupé.)

Pokud se nepletu, tak "mdadm --assemble MD --run B" není validní syntaxe, disk "B" byl odstraněn z pole

Vzhledem k tomu, že se nesmazala metadata, je IMO ta syntaxe validní, protože podle těch metadat je B prostě jeden mirror pole.

navíc --run nemá žádný argument.

SYNOPSIS: mdadm [mode] <raiddevice> [options] <component-devices>

--run je jedna z options a je tedy na správném místě. B není její argument, ale component-device

Stejně tak nelze přidat "A", protože už v poli je.

Ne, není. Podívej se pořádně, po rebootu do LiveCD není pole s A sestaveno.

[BlackShark]

O kolik si myslíte, že jim klesne prodej a jaké to budou pro NVIDI ztráty, když každý, kdo používá Linux a nemá Windows v dualbootu kvůli hrám, si tu NVIDI nekoupí? O 0,00nic? To v NVIDIi ani nepoznají, že si ti 3 lidé koupili ATI.

[Rezza]

Nebyl by spatny v PS4

[mirec]

Len tak pre zaujímavosť by som chcel vedieť v čom má byť Wayland lepší pre vývoj aplikácií? Vyvíjam bežne desktopové aplikácie, embedded aplikácie pre zariadenia s dotykovými LCD, OpenGL aplikácie a fakt ma nenapadá čo by mohol Wayland pri vývoji zlepšiť.

PS: o také vylepšenia ako klientské dekorácie okien nestojím (ak by niekto mal chuť toto použiť ako výhodu).

[ghngds]

hmm vzhledem k vašemu zaměření by právě Vás Wayland měl velmi zajímat.

[Rezza]

Idealne se s Waylandem vubec nemusis potkat - proste pouzivas svuj oblibeny toolkit a ten nekde kresli, pripadne OpenGL, cokoliv. A vlastne se nic nedeje. Jen po tebou se cely system vyrazne brutalne zjednodusi -> teoreticky vetsi rychlost, min problemu. OpenGL posila prikazy primo skrze Wayland, pres veci ala DRI2, pametove manazery do grafiky, ve dnesnim ne-fixed pipeline stylu, Wayland Compositor pak opet uplne stejne umi ta okna poskladat, s moznosti vyuziti HW transformaci/shaderu atd. Dokonce i v Qt se ted dela na Qt scene graph - kdy i samotne prvky rozhrani pujdou pres OpenGL primo (a opet pak plati to same, transformace/shadery). Kdyz se clovek rozhodne to delat vzdalene, tak se da trebas naroubovat SPICE ci neco podobneho/noveho a jedeme... Kdyz si to clovek vezme, tak spousta veci, ktere driv byly v Xkach natvrdo zadratovane jsou dnes v kernelu (mode settings, input, graf. manazer) - takze nad tim staci neco "jednodussiho".

[mirec]

teoreticky vetsi rychlost, min problemu

To slovíčko teoreticky sa mi tam až moc nepáči. Žiaľ nevidel som žiadne benchmarky nevidel.

Problémov by mohlo na embedded byť o niečo menej. Na desktope ale fakt neviem, strašne sa mi páči súčasna koncepcia oddeleného windowmanagera a obsahu okna.

Nechcem wayland zavrhovať, ale ... keď spustím nejakú gtk1 aplikáciu na desktope tak celková rýchlosť je brutálna. Ak spustím niečo s "moderným" toolkitom tak sa rýchlosť ani nepribližuje. Či je to problém pomalých X, alebo toolkitu si nedovolím hodnotiť, možno je to len tým, že nové toolkity používaju niečo, čo je v X pomalé.

[xm]

Ano, moderní toolkity mají poněkud jiný přístup než jejich prehistorické verze. To je vývoj, X za tím vývojem bohužel zaostává (a zjevně už z principu jeho fungování zaostávat musí, alespoň některé články od Jamese Goslinga a Keitha Packarda tomu nasvědčují) a z toho pak plyne výsledná pomalost.

[xm]

Ještě přikládám odkaz na onen článek: LPC: Life after X. Podotýkám, že Keith Packard je jeden z nejvýznamnějších vývojářů X. Na X pracuje už od 80. let a stojí mimo jiné za rozšířeními XRender, XFixes, XDamage, XComposite a XRandR.

Odkaz na paper Jamese Goslinga z roku 2002 jsem dával už v dřívějších diskuzích, ale pro jistotu ještě jednou: Window System Design: If I had it to do over again in 2002

[mirec]

Veľmi zaujímavé čítanie na cestu vlakom, dík za linky. Z textu vypichnem zopár drobností, ktoré sa mi akosi nezdajú.

We have graphical toolkits which can implement dynamic themes, so it is no longer necessary to run a separate window manager to impose a theme on the system.

Neviem, či som sám, ale nikdy som si nemyslel, že windowmanager je o téme. Podľa mňa je skôr pre jednotné správanie okien a je jedným z najúžasnejších konceptov na X. Dokonca by som ho rád rozšíril aj do aplikácií s MDI rozhraním. S client side dekoráciami som mal nespočetne veľa problémov vo Windowse a MacOS, nechcem ich zažívať aj na Linuxe.

Je tam zopár viet o asynchrónnosti. Neviem čím to je, ale môj WM je krásne rýchly. Nedávno som odišiel od KDE práve k WM, ktorý používa xcb a je asynchrónny. Celé to beží nádherne rýchlo, keď sedím za win 7 pripadám si ako v spomalenom filme. Prirodzene vidieť, že wm a okno nie sú synchrónne, ale práve tak sa mi to páči.

Ďalšie výhrady mám ku KMS. Drivery grafiky som nikdy nemal stabilné. Mám SiS, Ati, Nvidiu a Intel. Jedna väčšia katastrofa ako druhá. Bez KMS človek má aspoň akú takú nádej, že sa mu kernel po páde grafiky pozbiera. Pri KMS jednoducho koniec. Za bežných okolností by mi to nevadilo, lenže kernel le monolit, každá drobnosť ho dokáže položiť. S tým ale X nič nenarobí :(

Bojím sa, že chystané zmeny budú zmeny k horšiemu :(

[xm]

Neviem, či som sám, ale nikdy som si nemyslel, že windowmanager je o téme. Podľa mňa je skôr pre jednotné správanie okien a je jedným z najúžasnejších konceptov na X. Dokonca by som ho rád rozšíril aj do aplikácií s MDI rozhraním. S client side dekoráciami som mal nespočetne veľa problémov vo Windowse a MacOS, nechcem ich zažívať aj na Linuxe.

Podle mě to bylo myšleno tak, že na dekorace oken není windowmanager potřeba - jednotné dekorace mohou být řešeny na úrovni toolkitu. Jedinou nevýhodu vidím v tom když se nějaká aplikace zasekne, mohl by být problém jí jednoduše (rozuměj "kliknutím na křížek") sestřelit. Ale někde jsem četl, že tohle se dá ve Waylandu řešit jinak (už si ale nevzpomínám jak přesně to bylo).

[Rezza]

Protoze lidi chteji krasne barvicky, prechody, obrazky - tak se vsechno kresli do nejakych pixmap, samozrejme to musi byt animovane, pruhledne atd. a jsme tam, kde jsme - presne tohle kompletni prechod na Wayland a napr. Qt Scene Graph (a predpokladam veci ala Clutter) resi - jeste na urovni toolkitu a jednotlivych prvku. A vynecha se cele nejake posilani po Xkach, mezi toolkitem, grafikou, pres nejruznejsi rozsireni, ktere jednou funguji, jednou ne a kdyz jo, tak obcas se to projde celym systemem :D

PS: takhle tomu rozumim ja :D a doufam tedy, ze moc nepletu...

[Bedňa]

Tak to sme dvaja.

[Michal Fecko]

wayland vs xorg je klasickym, priam az ucebnicovym prikladom neduhu ktory suzuje Linux (a ludi okolo neho) ktory ja sam volam "leknovy tanec". Skaceme z lekna na lekno, menia sa bezhlavo verzie, koncepty, standardy, fukncie.. akonahle uvidime nieco nove, okamzite opustime dlho vyuzivane a hura systemom utekame na to nove, tam trosku ostaneme, zase zahliadneme nieco nove a hura na dalsie... a takto dookola. ono by to ani tak nevadilo keby to boli zmeny len k lepsiemu - poviem si cert to ber, ale ono su to casto zmeny k horsiemu, k pomalsiemu, k nestabilnejsiemu a co ma najviac trapi k neprehladnejsiemu. Prilis vela moznosti - ako ked mate 500 kanalov v TV a neviete si vybrat ktori budete pozerat.

[Zdenek]

Ano je to hruza, neumet si vybrat.

[Michal Fecko]

Ja si vybrat viem,problem je ze vyvojari nie...

[balki]

Vyvojari si vyberu toolkit, o samotne x-win sa starat nemusia. Ja pisem aplikacie v jave vo swingu. Viem, ako pracuju x-win ? Neviem.

[Karry]

Linux je tvořen převážně programátory kteří na něm pracují ve volném čase... Většinu lidí (z mého pohledu) nebaví trávit svůj volný čas prací na něčem co má jasně dané a ustálené koncepty, lidi baví pracovat na nových věcech na kterých mohou realizovat své nápady...

[Michal Fecko]

bez jasne danych a ustalenych konceptov ostane linux max iba na routroch a serveroch...

[xxxxxxxxxxx]

a bez pořádného 3D parametrického CAD systému taky. ))

[Lord Vetinari]

lol

[Espinosa]

To uz davno neni pravda. Hlavni casti linuxu - Kernel, OOo, Qt, Mozilla Firefox jsou vyvyjeny prevazne placenymi aktivnimi vyvojari (kernel asi 3/4, byl nedavno publikovan rozbor, OOo pres 95%), vetsinou se jedna o velke IT firmy, pak neco malo "distribuce" (hlavne Novell a RedHat); silne zastoupeni i v KDE (Nokia) a tusim i v Gtk/Gnome. Mozilla ma sice fond, ale toci v nem pekne penize (reklamni dealy s Googlem :)

Ano, je stale velmi mnoho aplikaci vyvijenych vyhradne dobrovolniky - hlavne desktopove aplikace pro koncove uzivatele - a to je presne kde se linuxu a potazmo OSS moc nedari :(

[Bedňa]

Súhlas, len pri tom jadre, pokiaľ si dobre pamätám to bolo z 2/3 komerčné firmy, ale to už platiť nemusí, môže to byť viac :)

[Pev]

Odborník znalý věci promluvil . Mluvíte ale o době víc jak 10 let zpět .

[Luboš Doležel (Doli)]

Jako by to takhle na Windows taky nebylo. Tam taky neustále vznikají nová API... ale stejně jako na Windows, tak ani na Linuxu to uživatele trápit nemusí. A vývojáře taky až tolik ne. Jestli to správně chápu, bude hlavním krokem zařadit podporu do GTK+, Qt apod. a bude hotovo.

[Espinosa]

> Jako by to takhle na Windows taky nebylo

I kdyby bylo, mohou sit to dovolit, pocty vyvojaru, projetku, firem jsou uplne o jinych cislech.

> Tam taky neustále vznikají nová API.

WinAPI ma zaklad nekdy od Windows 3.0 ne? Mozna i drive (viz clanek na rootu). Od te doby se jen pridava. To trumfne i Javu. O takove stabilite si muze OSS leda zdat. Aplikace vetsinou mezi win verzemi netreba portovat, nebo je to relativne jednoduche. Zato prechod mezi KDE3 -> KDE4 znamenalo u nekterych aplikaci skoro prepis (Kdenlive, Kaffeine,..) tedy alespon UI casti. Jestli se pamatuji dobre tak u Gtk/Gnome 1 -> 2 bylo to same, jen apliakci bylo min a jednodussi.

[Luboš Doležel (Doli)]

I kdyby bylo, mohou sit to dovolit, pocty vyvojaru, projetku, firem jsou uplne o jinych cislech.

A na Linuxu snad ne? Nevidím žádný problém.

Zato prechod mezi KDE3 -> KDE4 znamenalo u nekterych aplikaci skoro prepis (Kdenlive, Kaffeine,..) tedy alespon UI casti.

Tak zle bych to neviděl, záleží to hlavně na tom, jak byla aplikace napsaná. Navíc tu jsou třídy pomáhající s přechodem na Qt4. Další věc je, že do Qt4 přepisovat nemusíte, stejně jako nemusíte přecházet na .NET Framework 4.0.

Zato se setkávám s tím, že aplikace psané pro WinXP se pod Win7 musí spouštět v režimu kompatibility.

[belisarivs]

Zato se setkávám s tím, že aplikace psané pro WinXP se pod Win7 musí spouštět v režimu kompatibility.

A casto ani to nepomuze

[Jardík]

To ale nenítím, že by API nebylo kompatibilní. To je tím, že používají volání, která nejsou dokumentovány/určeny k použití aplikacemi, nebo je používají špatně a pak to někde nefunguje (něco jako dnešní problémy memcpy v glibc).

[balki]

a?

[deda.jabko]

WinAPI ma zaklad nekdy od Windows 3.0 ne

taky to podle toho vypada. jedno z nejprisernejsich rozhrani, co jsem kdy videl. vedle toho i standardni knihovna PHP vypada jako nadherny kus softwaru. :-]]

[Espinosa]

> wayland vs xorg

Placete pekne, ale nad spatnym hrobem. Normalne bych vam dal zapravdu, ale zrovna Xka jsou oblast kde by trochu konkurence a cerstveho vzduchu neuskodilo.

[Rezza]

Jen Linuxoveho? Vem si, jak se za tech poslednich 20 let zmenily grafiky - dnesni koncepty, standardy, funkce jsou uplne jinde. Takze logicky se tomu prizpusobuje i vrstva nad tim - software. Vsichni se tomu museli prizpusobit, urcite to nebylo bezbolestne a nikdy nebude.

[R]

Pruser je v tom, ze koncept X je zastarany nielen dnes, ono to tak uz je aspon 15 rokov. Vtedy vysli Windows 95, ktore naplno vyuzivali graficke akceleratory. Preto nebol problem na 486ke s ISA grafikou ATI mach32 posuvat okna po obrazovke plynulo. V Xoch je to problem dodnes...

[Grunt]

Pruser je v tom, ze koncept X je zastarany

V čem?

[m;)]

+1 (Y)

[imploder]

Tak to mě těší a doufám, že Wayland bude oproti X.org výrazné zlepšení. Problémy s fullscreenem - přesně, tohle v Xkách není v pořádku. Že nejde žádnou normální cestou taková základní věc - přepnout se z fullscreenu - to je IMHO ostuda Linuxu. Jednodušší a rychlejší - už se těším. Nebude snad problém provozovat X-server jako klienta Waylandu (je i zmíněno v sekci "architecture" na jejich stránkách), takže se budou dát dál provozovat X.org programy. X-server existuje i pro Windows (Xming).

Zajímavou otázkou je taky bezpečnost, především ochrana proti keyloggerům a podobné havěti. Jakákoliv aplikace může v Xkách odposlouchávat nebo dokonce ovládat jinou aplikaci, i když třeba jedna běží jako root a druhá ne - to dělá z používání různých uživatelských účtů věc tak trochu na baterky (musím já jako uživatel zadávat heslo, ale zlý vir to nezastaví). Tyhle věci zdá se Wayland řešit nebude.

[pavel]

Vypadá to, že KDE3 už je stabilní. Výborně! Zrušíme ho a vyrobíme KDE4!

Vypadá to, že Gnome2 už je stabilní. Výborně! Zrušíme ho a vyrobíme Gnome3!

Vypadá to, že Xorg už je stabilní. Výborně! Zrušíme ho a vyrobíme Waylend!

[loisa]

vypadá to, že už nám ta škoda 120 po otočení klíčkem startuje. výborně! budeme ji vyrábět až do skonání světa! :)))

[Rezza]

Dobre!

[biolog]

+1

[kavol]

vypadá to, že nám prototyp Favorita po otočení klíčkem nastartoval - výborně, okamžitě nahrazujeme výrobu Š120 a náhradních dílů na Š120 (co na tom, že bysme ještě potřebovali tak dva roky na tom Favoritu pracovat, aby nám startoval i za jiného počasí, atd., nás nezajímá, že se zákazníci chtějí dostat do práce/na dovolenou/kamkoliv alespoň stejně spolehlivě jako s tou Š120, kterou už ovšem moc používat nemůžou, protože nejsou náhradní díly ... atd.)

(pamětníci první generace Favoritů jistě vědí o této analogii své ...)

ale to nemá cenu takováto diskuse - neznám nikoho, co by tvrdil, že nějaký software je dokonalý a již nemá smysl ho vylepšovat ("... až do skonání světa"), takže tu argumentuješ proti něčemu, co nikdo neprosazuje

[Neel]

Píšeš nesmysly (tak to většinou bývá, když se někdo snaží vymyslet analogii tak, aby mu vyhovovala).

ale to nemá cenu takováto diskuse - neznám nikoho, co by tvrdil, že nějaký software je dokonalý a již nemá smysl ho vylepšovat ("... až do skonání světa"), takže tu argumentuješ proti něčemu, co nikdo neprosazuje

X.Org není dokonalý a výhledově ho nelze dokonalým udělat. X.Org prostě zatím tak nějak funguje.

Nikdo tady netvrdí, že Wayland musí kompletně nahradit X.Org už příští Neděli nebo následující rok. Všichni si přejí postupný přechod, kdy se Wayland dostane do distribucí a bude testován a vyvíjen.

Podle mě je naprostá blbost navždy setrvávat na nějakém starém „výrobku“, ve kterém jsou „workaroundy nepsaným standartem“, pokud je i jiná možnost.

[kavol]

Píšeš nesmysly (tak to většinou bývá, když se někdo snaží vymyslet analogii tak, aby mu vyhovovala).

a to prosím jaké, můžeš to nějak odargumentovat, nebo sis prostě jen potřeboval kopnout, onálepkovat protinázor, dostat čtenáři do podvědomí negativní konotaci, a usínat s dobrým pocitem jakej seš king a jak jsi mi to nandal?

X.Org není dokonalý a výhledově ho nelze dokonalým udělat.

a Wayland snad ano?

Podle mě je naprostá blbost navždy setrvávat na nějakém starém „výrobku“, ve kterém jsou „workaroundy nepsaným standartem“, pokud je i jiná možnost.

no a podle mě je naprostá blbost zahodit ten "starý výrobek" jen proto, že "je i jiná možnost" - pokud ta "jiná možnost" přiměřeně nenahrazuje funkcionalitu "starého výrobku", nevím, proč bych se o tuto měl připravit tím, že ho zahodím ve prospěch "jiné možnosti" (když tato nepřináší nic navíc, co by mi to ztracené vyvážilo nebo ještě lépe zcela vynahradilo)

což, jak jsem pochopil, Wayland (některou) funkcionalitu X nenahrazuje a ani to nemá v plánu

[Neel]

Podle mě je naprostá blbost navždy setrvávat na nějakém starém „výrobku“, ve kterém jsou „workaroundy nepsaným standartem“, pokud je i jiná možnost.

no a podle mě je naprostá blbost zahodit ten "starý výrobek" jen proto, že "je i jiná možnost" - pokud ta "jiná možnost" přiměřeně nenahrazuje funkcionalitu "starého výrobku", nevím, proč bych se o tuto měl připravit tím, že ho zahodím ve prospěch "jiné možnosti" (když tato nepřináší nic navíc, co by mi to ztracené vyvážilo nebo ještě lépe zcela vynahradilo) což, jak jsem pochopil, Wayland (některou) funkcionalitu X nenahrazuje a ani to nemá v plánu

Proto X.Org nikdo nezahazuje. Může běže bez problému uvnitř Waylandu, pokud bude potřeba.

[trekker.dk]

když tato nepřináší nic navíc, co by mi to ztracené vyvážilo nebo ještě lépe zcela vynahradilo

Asi ti to pořád nedochází, ale lidí, co ještě využívají X po síti (a další funkcionalitu X, bez které se neobejdeš), je dneska zatraceně málo. V porovnání s celkovým počtem uživatelů Linuxu a grafického prostředí nad ním rozhodně; drtivá většina potřebuje, aby se jim na obrazovce vykreslovala okýnka.

Pokud ti vadí, že distributoři chtějí nahradit X server něčím jiným, můžeš klidně přiložit ruku k dílu a zapracovat na tom, abys mohl dál využívat X server. Nebo aby X server byl lepší než to něco jiného. Nebo někomu zaplatit, aby to udělal. Očekávat, že se kvůli tobě někdo přetrhne, je přinejmenším naivní.

[kavol]

Asi ti to pořád nedochází, ale lidí, co ještě využívají X po síti (a další funkcionalitu X, bez které se neobejdeš), je dneska zatraceně málo.

neřekl bych, že jich je méně než dřív, spíš:

V porovnání s celkovým počtem uživatelů Linuxu a grafického prostředí nad ním rozhodně;

- o tom to bude ...

Pokud ti vadí, že distributoři chtějí nahradit X server něčím jiným, můžeš klidně přiložit ruku k dílu a zapracovat na tom, abys mohl dál využívat X server. Nebo aby X server byl lepší než to něco jiného. Nebo někomu zaplatit, aby to udělal.

ano, jistě, a pokud mi vadí něco na politice, ta můžu jít do politiky, abych to změnil, a pokud mi vadí, že cesta u nás před barákem je rozbitá, tak ji můžu odkoupit a nechat opravit, atd., že, prostě mít stovky životů času na to řešit různé nešvary a několik ropných polí k tomu

Očekávat, že se kvůli tobě někdo přetrhne, je přinejmenším naivní.

neočekávám, že by se kvůli nám někdo přetrhnul

nicméně doposud jsem naivně věřil na nějakou elementární slušnost a zodpovědnost vůči uživatelům; KDE4 a Neo Freerunner mě z toho dost vyléčili, ale ještě si zachovávám poslední zbytky optimismu - když je někdo schopen dělat software třebas pro slepé, proč by se někdo nenašel, kdo bude řešit tu síťovou dostupnost

koneckonců, překlady, co dělám, taky nepotřebuju zrovna pro sebe ...

[trekker.dk]

prostě mít stovky životů času na to řešit různé nešvary a několik ropných polí k tomu

Njn, co naděláš...

Ještě máš jednu možnost - když ti nevyhovuje, co v distru uchystali, neaktualizovat. Takhle to dělám já, prostě jsem si nechal KDE3 a celé KDE3 verze 4.x mi může vlézt na záda.

když je někdo schopen dělat software třebas pro slepé, proč by se někdo nenašel, kdo bude řešit tu síťovou dostupnost

Pokud vím, tak X server lze provozovat i pod Waylandem (a obráceně), takže otázkou je jenom to, co bude v distru a kolik práce budeš ochoten vynaložit, když to tam nebude.

nicméně doposud jsem naivně věřil na nějakou elementární slušnost a zodpovědnost vůči uživatelům

Mám takové tušení, že ta změna bude mít nějaký rozumný důvod, který vyhoví víc uživatelům, než kolika bude vadit. I pro vývojáře je to práce navíc, takže bezdůvodně by to nedělali.

A vzhledem k tomu, že jeden z hlavních vývojářů X.org tvrdí, že spousta funkcionality X se přežila, tak bych jim v tom docela věřil.

[kavol]

Ještě máš jednu možnost - když ti nevyhovuje, co v distru uchystali, neaktualizovat.

mnoho let starý systém má zas jiné nevýhody ...

nicméně doposud jsem naivně věřil na nějakou elementární slušnost a zodpovědnost vůči uživatelům

Mám takové tušení, že ta změna bude mít nějaký rozumný důvod, který vyhoví víc uživatelům, než kolika bude vadit.

jenže takhle by to fungovat nemělo - změna by ideálně neměla vadit nikomu ... tedy objektivně vadit, nutnost změnit návyky apod. nepočítám

(jinak, nedalo by se obdobně obhajovat třebas znárodňování? - pověsíme pár továrníků, majetek rozdělíme davům dělníků, není to rozumné, víc lidí bude mít užitek než škodu?)

A vzhledem k tomu, že jeden z hlavních vývojářů X.org tvrdí, že spousta funkcionality X se přežila, tak bych jim v tom docela věřil.

ještě jsem ovšem ze všech těch diskusí okolo nepochopil, co brání udělat X12, proč je nutné zahazovat celé X včetně funkcionality doposud užitečné

rozuměj, chápu, že v životě prakticky každého déletrvajícího projektu přijde chvíle, kdy by již bylo výhodnější zahodit vše krom zkušeností a začít znovu, ale ... myslímže tohle má do té situace dost daleko

[trekker.dk]

jenže takhle by to fungovat nemělo - změna by ideálně neměla vadit nikomu

Tak mě třeba objektivně vadilo, když jsem na svém Athlonu XP 1700+ nemohl spustit MS-DOS a v něm Tyriana. Myslíš, že by bylo rozumné, aby se někdo v rámci "změna by neměla vadit nikomu" zabýval tím, jestli na novém hardware půjdou spustit prastaré programy?

jinak, nedalo by se obdobně obhajovat třebas znárodňování? - pověsíme pár továrníků, majetek rozdělíme davům dělníků, není to rozumné, víc lidí bude mít užitek než škodu?

Tak tady je docela rozdíl, ne? Když znárodňuješ, někdo něco vlastní a ty mu to sebereš. Co se dister a softwaru týče, distributoři a vývojáři ti nic neberou; co máš teď, můžeš v klidu mít dál, ať už sis to koupil nebo stáhl zadarmo.

Že se rozhodli danou věc přestat vyvíjet, to je jejich právo. Nikdo ti nikdy neslíbil, že bude X podporovat na věky.

ještě jsem ovšem ze všech těch diskusí okolo nepochopil, co brání udělat X12, proč je nutné zahazovat celé X včetně funkcionality doposud užitečné

Pravděpodobně není dost lidí, kteří by měli pocit, že by takový cíl stál za tu práci. Pokud máš jiný názor, vracíme se k tomu, že se musíš snažit sám.

rozuměj, chápu, že v životě prakticky každého déletrvajícího projektu přijde chvíle, kdy by již bylo výhodnější zahodit vše krom zkušeností a začít znovu, ale ... myslímže tohle má do té situace dost daleko

To je zjevně věc názoru a v tomhle případě platí, že nejsilnější skupina s daným názorem vyhrává. Prachy i vliv jdou zjevně na stranu nastrkat řízení grafiky do jádra (kam IMO patří stejně jako všechen ostatní hardware) a ostatní - X server, Wayland apod. - nechť jsou pouhé aplikace. Takže i když si myslíš, že do situace "všechno zahodit" je ještě dost daleko, víc lidí (víc vlivnějších lidí) si to nemyslí a máš smolíka, i kdybys měl pravdu.

[kavol]

Myslíš, že by bylo rozumné, aby se někdo v rámci "změna by neměla vadit nikomu" zabýval tím, jestli na novém hardware půjdou spustit prastaré programy?

tož, třebas Red Hat se tím reálně zabývá - sice ne zrovna tvým Tyrianem, nicméně jeden z cílů vývoje virtualizačních řešení byl umožnit migraci starých systémů na nové železo

jinak, nedalo by se obdobně obhajovat třebas znárodňování? - pověsíme pár továrníků, majetek rozdělíme davům dělníků, není to rozumné, víc lidí bude mít užitek než škodu?

Tak tady je docela rozdíl, ne? Když znárodňuješ, někdo něco vlastní a ty mu to sebereš. Co se dister a softwaru týče, distributoři a vývojáři ti nic neberou; co máš teď, můžeš v klidu mít dál, ať už sis to koupil nebo stáhl zadarmo.

ale berou, berou - nebavíme se přeci jenom o hroudě zlata pod polštářem, kterou jde vzít fyzicky, ale o nějaké funkcionalitě, kterou ten software zajišťuje ... a tu mi tímto berou, nechám-li si nainstalovanou starou verzi distra, přijdu o podporu - nemůžu "v klidu mít dál" plně aktualizovaný systém, například

nicméně pointa byla v tom, že nelze obecně argumentovat pro "útisk" menšiny prospěchem většiny

Že se rozhodli danou věc přestat vyvíjet, to je jejich právo. Nikdo ti nikdy neslíbil, že bude X podporovat na věky.

a tvrdím snad opak? - já pouze říkám, že takovéto rozhodnutí od nich není vůči uživatelům slušné

ještě jsem ovšem ze všech těch diskusí okolo nepochopil, co brání udělat X12, proč je nutné zahazovat celé X včetně funkcionality doposud užitečné

Pravděpodobně není dost lidí, kteří by měli pocit, že by takový cíl stál za tu práci. Pokud máš jiný názor, vracíme se k tomu, že se musíš snažit sám.

dobře, jinak - co objektivně brání udělat "X12"?

chápu, že někteří mají pocit, že vše staré je špatné, a že oni na to teď naběhnou úplně jinak a napíšou něco cool, takže pracovat na přepisu starého se jim nechce, nestojí jim "takový cíl za tu práci" - ale není takhle té práce naopak víc?

rozuměj, chápu, že v životě prakticky každého déletrvajícího projektu přijde chvíle, kdy by již bylo výhodnější zahodit vše krom zkušeností a začít znovu, ale ... myslímže tohle má do té situace dost daleko

To je zjevně věc názoru a v tomhle případě platí, že nejsilnější skupina s daným názorem vyhrává. Prachy i vliv jdou zjevně na stranu nastrkat řízení grafiky do jádra (kam IMO patří stejně jako všechen ostatní hardware) a ostatní - X server, Wayland apod. - nechť jsou pouhé aplikace.

nejsem si jist, co si představuješ pod "řízením grafiky" ... komunikace s hardware? - ano, to i dle mého názoru do jádra patří; koneconců měl jsem zato, že i Xorg tímto směrem postupuje (byť pomalu)

Takže i když si myslíš, že do situace "všechno zahodit" je ještě dost daleko, víc lidí (víc vlivnějších lidí) si to nemyslí a máš smolíka, i kdybys měl pravdu.

nejsem si jist, jestli si rozumíme - já si nemyslím, že by X11 do této situace ještě nedospělo, ani že by tam již dospělo, prostě na to nemám názor, protože do vnitřností nevidím; tím "tohle má do té situace dost daleko" jsem myslel, že způsob, jakým má asi dojít k "zahození" X se tady tomu, té neustále historicky se opakující situaci "nutno přepsat", příliš nepodobá, a tudíž to nepovažuju za šťastné

... protože Historia magistra vitae, anebo taky "Those who cannot remember the past are condemned to repeat it.", takových situací, kdy někdo jen tak přišel s tím "děláte to všechno špatně, teď to uděláme líp", už tady bylo přehršle, a troufám si tvrdit, že jen málokdy z toho vylezlo něco kloudného

[Grunt]

X.Org není dokonalý a výhledově ho nelze dokonalým udělat. X.Org prostě zatím tak nějak funguje.

Něco jako důkaz? (A osobní pocity založené na tom, že nadávat na Xka jako na příčinu všech problémů za zemi je momentálně cool moc neberu) X.org není jediná implementace X protokolu. Už teď se rozjelo pár nových. Xka potřebují pořádnou revizi jak X.org, tak samotného X11 protokolu. Nic víc (a rozhodně ne takové kraviny jako Wayland).

[mirec]

Nič okrem Hello world sa dokonalým nedá spraviť. Nehovoriac o tom, že neexistuje jediné univerzálne riešenie všetkých problémov, na mobiloch sa môže hodiť niečo iné než na desktope.

Inak s komentárom plne súhlasím. X nie sú dokonalé ani nikdy nebudú, ale po poriadnej revízii ako samotného serveru tak aj protokolu by nemusel byť žiaden dôvod na vznik wayland-u.

Nebol by som ani proti niečomu úplne novému, lenže ako tak čítam prečo vznikol wayland a čo má obsahovať tak mi akurát tak chodí mráz po chrbte. Koncepcia, kde sa jeden proces stará o všetky okná sa mi zdá omnoho progresívnejšia než toto, čo sa snažia teraz odkukať z Windowsu a Mac OS.

[Grunt]

na mobiloch sa môže hodiť niečo iné než na desktope.

Na mobilní zařízení s OpenGLES se třeba Wayland může hodit. Dříve byl docela oblíbený DirectFB. To šlo téměř vše přes volání a aplikace jen dostane pointer na místo někde ve framebufferu (pokud to teda není akcelerované) a nech už si s ním dělá co chce. Osobně jsem si to zkoušel a není to zas tak o mnoho Wow abych kvůli tomu vyhazoval Xka. Ale pokud se někomu nelíbí lokální socket, tak nech si to klidně zkusí sám.

[R]

A tu reviziu X urobi kto? Obavam sa, ze nikto...