Az X úgy épül fel, hogy van külön a server és a window manager. Ehhez a tandemhez csatlakoznak az alkalmazások. Az X window managerét le lehet cserélni és akkor a saját window managerhez és az xserverhez csatlakoznak az alkalmazások. Van még a compositor, ami nem része az X-nek, de vagy külön (pl. compton), vagy a window managerhez szorosan integrálva (pl. kwin) meg lehet valósítani. Opcionális, X-nél elhagyható a compositor ami teljesítmény előnyt jelent, mert anélkül a window manager (az X, vagy a 3rd party) közvetlenül rajzol a képernyőre, míg a bonyolultabb compositor előbb memóriában összerakja a képet csicsásra, majd azt másolja a képernyőre.
A wayland úgy épül fel, hogy nincs külön szerver része. Helyette van a wayland protocol, a többi pedig a wayland compositor, ami az X-es analógia szerint tartalmazza a compositor, a window manager és a server funkcionalitásának részeit is. A wayland compositorhoz csatlakoznak az alkalmazások.
Ami probléma szerinte, és szerintem is elgondolkodtató: X esetén a 3rd party wm és dm készítőknek elég volt implementálni a window manager részt, és ha akarták opcionálisan a compositort (lehet abból is 3rd party-t használni), ezzel szemben wayland-nél minden 3rd partynak meg kell valósítania a kötelező compositort, mert waylandon az nem opcionális, a window manager részt és a server funkcionalitásokat amik kompatibilisek a wayland protocollal.
Ez azt eredményezi, hogy sokkal több munka egy wayland wm/dm elkészítése, a kötelező compositing miatt teljesítményben elmarad az X lehetőségeitől (nyilván, ha ott nem használsz compositort), kevésbé szabványos az X-hez viszonyítva, mert sokkal nagyobb részét magadnak kell megírni és hiába a wayland protocol, ki így, ki úgy valósítja meg.
Kb. ennek a problémának a megoldására született a wlroots és más kisebb wayland lib is, ami azt hivatott elkerülni, hogy mindent is mindenkinek külön le kelljen fejleszteni. Szerinte viszont minőségben a wlroots nem veszi fel a versenyt az xserverrel és mivel az a legelterjedtebb, a wlroots kvázi standarddá válik. Ebben sem látom mi a probléma egyébként, úgy gondolom az élet utat tör magának :)
Mond még ilyeneket, hogy a wlroots bloat, mert 100K soros a kódja, míg az egész X 300K soros, de a wlroots sokkal gyorsabban hízik. Hasonlítgatja, hogy a wayland esetén ha összeadjuk a wlroots+wayland compositor+wayland protocolt az milyen nagy, míg X esetén sokkal kevesebb, mert csak a wm-et kell lecserélni. Nem említi, hogy akkor ott bele kell számolni az xservert is a wm mellé és ha használsz compositort, azt is. Lehet amúgy, hogy úgy is nagyobb lenne a waylandes kódbázis, passz. Mondjuk i3-sway vonatkozásában lehetne ezt összehasonlítani, de nem tudom van-e értelme. Engem ez a kódsorok mérete teljesen hidegen hagy.
Wayland ellenében hozza még fel az OOP-t is a bloat mentén, nem értek hozzá. Szerinte az X a C mit is jobb.
Amivel egyetértek, hogy a kötelező compositor miatt lépéshátrányból indul a wayland az X-el szemben (bár én X-en mindig használok compositort). Egyetértek azzal is, hogy nem biztos hogy jól találták ki a wayland struktúráját, túl sok minden hárul a wm készítőkre. Mondjuk erre születnek a különböző wayland lib-ek, és ezek közül terjedt el a legjobban a wlroots, amit viszont egy korrekciónak tartok a hibás struktúra javítására a közösség részéről. Ő egy bloatnak.
XLibre kapcsán elmondja, hogy az X környékén az a helyzet, hogy a fejlesztők jelentős része Red Hat alkalmazott, akik már nem akarnak új release-t kiadni, főleg csak bug és sec fixeket engednek, a fejlesztés főleg az Xwayland-ba megy, ami egy vicc amúgy is. Xwayland-ról mondja, hogy már csak amiatt sem lehet jobb egy wayland-es rendszer teljesítménye, mert sok alkalmazás még nem wayland kompatibilis és emiatt a wayland behúzza az Xwayland-ot, ami a wayland felett emulál egy xservert ezeknek az alkalmazásoknak. Ebben is igaza van, bár ez idővel változni fog, de jelenleg igaz.
Szóval X-nél volt ez a nem Red Hat-es ember, aki tolta be a sok commitot, (a videó szerint az utóbbi időszakban ilyen 63 %-át a commitoknak ő produkálta) és akart volna több feature-t is hozzáadni az X-hez, valamint egy új release-t is. A RH fejlesztők mondták, hogy nincs már új release az X-hez, erre a faszi mondta hogy akkor csinál ő nélkülük és forkolta az X-et XLibre néven. Erre bannolták, majd elkezdték innen onnan törölgetni a hozzászólásait és cuccait, elkezdték kiragadni a commitjait és tolni hogy csak ilyen kozmetikai cuccokkal járult hozzá stb. Ez a része elég gusztustalannak hangzik, bár én magam nem jártam utána, nem túrtam commitokat, meg az archive-org-ot.
Elmondja még, hogy eléggé felkapták a forkot meg ezt a faszit bizonyos oldalról, hogy itt politikai téma van, meg non DEI meg ilyenek, de nem erről van szó. Ez az egész egy technikai jellegű vitából indult, majd a faszi a fork promózásakor elmondja, hogy bárki segítségére számít, legyen az bárki, nem érdekli a politikai, faji, vallási, etnikai hovatartozás stb. Lehet tündérkirálylány is az illető őt nem érdekli. Ebből lett kidomborítva, hogy politikai meg COC meg DEI faszságok miatt van az egész. A videó szerint nem, technikai jellegű a történet. Más kérdés viszont, hogy az ellen között COC bajnok is van, de az egész vita az X vegetálása-sorvasztása vs. fejlesztése miatt indult.
(Több részletben néztem meg, kicsit összehánytam ezt az összefoglalót, lehet van pár tévedés, vagy félreértelmezés is, kimaradt jelentősebb részlet. Szóval #FIXME. Javarészt egyetértek a videókészítő véleményével, bár van néhány rész, ahol azért maradtak bennem kérdések)