Názory k článku XLibre jako další bouře ve sklenici vody, nebo spása pro X.Org?
-
Za sebe jsem rád, že jsem se na všech počítačích toho molochu X11 zbavil. A to tak daleko, že není nainstalovaný ani balíček xorg-server. Jasně občas v některé plamenné diskuzi zatlačím nostalgickou slzu, pamatuji na vlastní kůži ještě XFree86, ale stýskat se mi nebude. Wayland prostě jede a ani KDE jsem za poslední rok nenarazil na nějaký problém. Zpětná kompatibilita přes XWayland prostě funguje, rozjede se i prehistorický Unreal Tournament z roku 1999 (uznávám, je to nějaká opatchovaná binárka, ale určitě jí bude víc než 20 let).
Vývoj jde dál a ono všechno tohle utichne, stejně jako všichni kvičeli když nás postupně opouštěli a potlesk pro ně: OpenSoundSystem, DevFS (vzpomene si ještě někdo?), SysV init, ReiserFS, HAL, lilo a další.
Jo tohle všechno staří harcovníci (i já) zažili, ale selektivní paměť nám povětšinou zanechala jen ty hezké vzpomínky. A přiznejme si nebylo to hezké, hromada probdělých nocích s manuálovými stránkami a vytáčeným spojením do Internetu a občas prostě bez úspěchu. V tomhle světle je současný Linux se současnými technologiemi růžovou zahradou. Ano, sem tam se píchneme o trn, ale jinak je to nádhera.
-
Za sebe jsem rád, že to nemusím řešit a chci jen, aby to tak zůstalo. Co bude ta okna kreslit je mi úplně jedno, jen by to prostě mělo fungovat samo. Audio systém je přesně stejný případ. To je pohled normálního uživatele. (A můj taky.) A mimochodem, zrovna RaiserFS byl alespoň u mě bezproblémový a kupodivu je použitelný je i dnes i když už k tomu samozřejmě není žádný důvod. Což je vcelku pozoruhodné.
-
DannyStříbrný podporovatelVsak vetsina distribuci to za vas proste vyresi. Normalni uzivatel ten podvozek vubec resit nemusi. Samo to obvykle funguje minimalne do chvile, nez do toho zacne ten uzivatel proaktivne vrtat :-)
-
No nevím, co si pamatuju, tak v dobách těsně po roce 2001, kdy jsem zápasil s Mandrage 8.něco zrovna všechno nebylo krásné a funkční. Taková zvuková karta dokázala potrápit, nebo rozběhnout 3D akceleraci, to byl občas zážitek. A člověk nemusel mít ani kdo ví jaký exotický hardware. Já tehdy měl nějaký AMD Duron na asi 800 MHz, GeForce2 a Sound Blaster Live, a že by to všechno fungovalo nějak pořádně out of the box, to si tak nějak nepamatuju...
Ano díky novým technologiím je nyní Linux po čerstvé instalaci plně funkční a proto nemá cenu brečet nad ničím starým, co pořádně nefungovalo.
-
DannyStříbrný podporovatel
V roce 2001... bylo hodne veci jinak. Neni dobre byt otrokem minulosti, mame rok 2025 ;-)
-
PulseAudio kladlo dost vysoke poziadavky na kvalitu ovladacov. V tej dobe ovladace mali kopu bugov, s ktorymi to drhlo. PA sa zlepsilo, ako sa popracovalo na oprave ovladacov.
A nielen ovladace, aj hardver mal kopec problemov. Mal som pocitac s audio kodekom (Nvidia ION 2), ktory tvrdil, ze zvlada 44,1 kHz, ale mal nejaky problem s timerom, takze z casu na cas sa ozvalo lupnutie, ked timer oddriftoval prilis daleko od realneho streamu. Po nanuteni 48 kHz v PA a softveroveho prevzorkovania tento problem zmizol.
-
Je "vrtání se", když chci, aby se mi po přihlášení do KDE otevřela okna alplikací, které chci, na těch místech a obrazovkách, kde je chci, podle toho, jak jsem si to uložil? Pro mne je to nesmírně užitečná funkce, která bez problémů fungovala přinejmenším od dob KDE3, ale pokud KDE běží nad waylandem, tak mám prostě smůlu - a není vůbec jasné, kdy a jestli vůbec to tam fungovat bude.
-
Zkusím se podívat, jestli by to šlo nějak využít v kombinaci s automatickým spouštěním po přihlášení. Můj hlavní problém je, že mám oblíbený layout s 12 okny konsole rozházenými určitým způsobem po čtyřech virtuálních plochách, každá přes dva monitory. Okna navíc nejsou stejně velká (někde chci šířku 80 znaků, někde víc). Takže bych musel při spouštění dát nějakou identifikaci, aby pravidlo dokázalo poznat, kam které okno patří. Ale to snad půjde zajistit nějakým parametrem.
Session save/restore navíc umí i to, že se v každém okně otevře "správný" počet tabů a v tabech se obnoví i pracovní adresáře, jak byly.
-
-
x11 je dosiroka otvorene.
Pri procesoch mame ochranu pamate, aby jeden nesahal druhemu do jeho zalezitosti, a ked uz chce, tak musi pouzit nejaku formu zdielanej pamate.
Pri suboroch mame pristupove prava a kontajnery. Ked uz nejaky proces chce sahat, tam, kam by nemal, tak sa mu to nie celkom podari.
No a x11 nic take nema. Kazdy proces si moze sahat kam len chce, aj ked to nie je jeho biznis. Niektore hracky vznikli len pre srandu (xeyes), niektore su uzitocne (screeshoty a streamovanie), no a pri takom malware a keygrabberoch, jeden nikdy nevie. Pamatame si na XP? No, tak nechceme, aby linuxovy desktop dopadol podobne. Ziaden tradicny uzivatel si ho nechce spustit, a tu sme, takyto sw existuje.
Takze wayland by default neumoznuje sahat kazdemu, kam si zmysli. Samozrejme, pre niektore veci treba vytvorit diery. Pre uzitocne veci ako screenshoty a stremovanie vzniklo api[1]. Niektore diskutabilne veci - ano, globalne shortcuty su diskutabilne[2] - sa holt budu robit inak. A niektore veci (globalne suradnice na monitore) holt nebudu. Napriklad aj preto, ze monitor nemusi byt obdlznik, ako sme zvyknuti. Moze mat konvexne a konkavne kraje (pristrojovka v aute, displej na macbook pro s vyrezom pre kameru), moze mat "diery" (bezny dnesny telefon s dierou na fotak), alebo len okruhle okraje (niektore displeje frame.work) Alebo moze byt "nekonecny" a nema [0,0] v globalnej sustave. Kompozitor na to pamata, nahodny klient nie.
A to sme sa este nedostali k hackom. Viacero displejov s rozlicnymi dpi? V X11 vec neriesitelna (xinerama je jeden velky displej s dierami; z definicie musi mat rovnake dpi a rovnaku farebnu hlbku na vsetkych obrazovkach). HiDPI? Ziaden X klient neoznamuje serveru, s akym DPI pocita. Ma potom server menit fyzicku velkost surface alebo nie? Niektori klienti vedia korekne pracovat s DPI, tym by nemal, niektori nevedia, tym by mal, ale kedze server nevie ktory je ktory, musi si tipnut a potom radsej kazdemu povie nizsie DPI a zvacsuje/rozmaze vsetko. Vo waylande, surface ma vlastnost, v akej mierke je a kompozitor sa zariadi.
No a takto by sme vedeli pokracovat donekonecna. Takze nie, pouzivatel si nechce len spustit browser. Chce si ho spustit na projektore. Alebo na HDR monitore. A potom chce vidiet HDR obrazky. A nechce, aby mu nahodny javascript v inom okne browsera graboval heslo do internet bankingu. Takychto poziadaviek je tam nakoniec docela hodne.
[1] a niekedy aj efektivnejsie ako v x11. V x11 "streamovenie" bolo kontinualne grabovanie screenshotov a prenos kazdeho z x11 serveru do pamate procesu (v pripade lokalneho minimalne z videoram do system ram). Wayland kompozitoru sa da povedat, ze chcem video stream, ci ho chcem uz komprimovany vybranym hw kodekom na gpu a nech mi ho necha v dmabuf bufferi na video karte.
[2] pretoze nechceme, aby si nahodna aplikacia zaregistrovala nahodny shortcut. Ina vec je, ked si zaregistruje akciu, pouzivatel jej priradi shortcut a pri tom priradovani sa da zariadit, aby neboli ziadne kolizie.
-
Problém je, že za nebezpečné se považuje i umístit okno na konkrétní pozici (např. víceoknové aplikace). Alespoň že sami po letech uznali, že přesunout kurzor myši je potřeba (např. first person hry). A různé DPI na displejích? Já to měl už před 15 lety v majoritním distru jménem Ubuntu, by default. Implementováno sice oklikou v desktopovém prostředí (nad X11), ale ve Waylandu se to řeší taky tak.
-
> umístit okno na konkrétní pozici
Časem to snad bude, viz: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/264
-
Fungovalo to na stejném principu, jako skriptování X11. Akorát že ten skript byl předinstalován distribucí. Dávno jste si mohl všimnout, že Gtk a Qt aplikace mění GUI dynamicky po změně DPI. Takže stačilo jen říct aplikaci nové DPI po přesunu na jiný monitor. Jsou tam nedostatky, když je okno na půl cesty, ale stejné problémy jsou i ve Windows. Pro Firefox Canonical napsal patch, protože ten není ani Gtk, ani Qt (kreslí GUI prvky přes Gtk, ale okno je vlastní kód).
-
DPI v x11 je vlastnost displeja, nie screenu, ani toplevel okna, alebo ineho objektu. Hovorime o x11, nie o tom, co by teoreticky zvladlo Gtk a Qt.
Ano, je mozne vymysliet dalsi protokol typu ICCCM, kde by sa nastavil specificky atom na okno; len problem s takymto postupom je, ze to dana aplikacia musi podporovat a ze ho do starsich aplikacii retrofitovat nikto nebude; takze vznikde dalsi protokol, ktory funguje len s niektorymi aplikaciami a zvysok je rozbity.
Zatial co postup, ktory zvolil (x)wayland, funguje aj s 30 rocnou binarkou wordperfectu.
-
Samotný integer scaling funguje jen pro násobky sta procent. macOS to pro mezihodnoty řeší tak, že vykreslí 200% integer scaling, a pak to zmenší (nevím, jaký přesně filtr, stačil by i bilineární). Jenže na to je třeba vysoký rasterizační výkon GPU, to by půlka PC nedala. Apple si dělá vlastní GPU (i ta nejslabší je dostatečně výkonná) a předtím od Intelu bral procesory s dvojnásobným výkonem iGPU, než dostala většina PC.
Pro zajímavost, s příchodem 5K displeje Apple Cinema tehdejší Intel iGPU nestačilo, tak využil toho, že ten MacBook Air již měl první generaci Thunderbolt. Takže v případě toho notebooku se ve skutečnosti použila o generaci lepší Intel iGPU uvnitř monitoru (Thunderbolt je externí PCIe sběrnice). -
Lenze macOS to v GPU vobec nerobi (inak by to bolo primitivne zmensenie jednej textury, s cim nema ziadna GPU problem). Rovnaky postup pouziva aj na Intel Macoch, ktore maju GPU od Intelu a AMD. A ako to robi? Scalerom v output enkoderi (ekvivalent `xrandr --scale`). Intel to ma pekne popisane v ich dokumentacii k GPU.
Ked prisiel Apple s 5K displejmi, bolo nutne pouzit oba MST kanaly v displayporte uz na zobrazenie 4k@60. Pri jednom kanale, alebo pri hdmi 1.4 sa dalo zobrazovat iba 4k@30. Ak sa pouzivalo este dvi, tak bolo treba pouzit dva kable a monitor to musel vediet zlucit. To bolo obmedzenie portov, nemali dostatocny bandwidth, preto to Apple tuneloval cez thunderbolt, ktory bandwidth mal. V 2015 intel haswell igpu na to bohato stacilo.
-
Ano, mělo by to fungovat samo, ale mělo by to taky jít změnit, když to náhodou nefunguje. Třeba já provozoval starý monitor, u kterého, nevím proč, Linux nedokázal získat nebo přečíst EDID, nevím. Windows se s tím nějak popasoval a to rozlišení tam bylo, ale Linux prostě řekl ne, a tím to haslo. Na Xorg bylo řešení prosté - ve Windowsu vyexportovat EDID a Xorg ho nacpat ručně v .conf souboru. Ve Waylandu takové řešení buď neexistuje, nebo jsem na něj nepřišel.
-
Starsie monitory EDID neoznamovali.
Windows (resp. ovladace pre windows) si jednoducho tipli rozlisenie/nechali pouzivatela nastavit rozlisenie a timing vypocitali podla VESA GTF. Kedze VESA s publikovanim GTF svojho casu dost blbla, tak to XFree nevedel a pouzivatel si musel vypocitat modeline ako len chcel.
-
Mi X.org vyhovuje, byl to velky posun proti Xfree86 ;-) ... chapu ze se planuje vymenit - prozatim je to ale tak, ze je Waykland horsi a pomalejsi - a mel byt lepsi a hlavne rychlejsi ... ale koncepcne je asi lepsi a vse se vyresi - nakonec na nej prejdou vsichcni, nekteri az se odladi ;-)
kdyz mi tam bude fungovat NVIDA prtes uzavreny driver - noveou nechci ani videt, ten si strcte vi tam, 20x nizsi vykon ;-) a 80% nefunguje ... takze chci CUDA nebot na ni pocitam ;-) a samnozrejme Vulkan a VDPAU
-
Wayland ma tak isto chyby, ktore teda nikto riesit nechce. Mozno by sa mal tiez forknut. Konkretne ja som nasiel 2 problemy:
Drag&drop URL napr. z Firefoxu do terminalu sice funguje, ale nie na 100%. Prvy presun skoro stale zlyha, nic sa nepresunie. Druhy vacsinou funguje, nasledne funguju OK, ale po par minutach prace to opat nejak nefunguje. Nehladal som aktualne na webe, ci sa to riesi, ale nechce sa mi verit, ze o tomto nikto nevie, ze nerobi drag&drop.
Pri jednej starsej hre pustanej cez wine je to na Waylande dost problematicke, pretoze zrejme nevie triple-buffering a ani to nikto nechce riesit. Tym padom sice hra funguje, ale obcas sa obraz dost divne seka. Casto je to dost nehratelne. Toto sa mi zda uz sa nejak vyriesilo, ale tiez to dlho trvalo, kym sa to vyriesilo.
Neviem, ci sa vieme zbavit aj Xwaylandu, ten sa asi bude musiet udrziavat dlhsie, pretoze by sa zrejme niektore aplikacie uplne rozbili.
Ja uz sice niekolko rokov pouzivam wayland na PC aj notebooku, ale spokojny nie som. Xorg proste fungoval, tuna sa denne stretavam s problemom, ze nefunguje drag&drop a musim operaciu opakovat, co je zbytocne zabity cas. Tento clanok ma inspiroval v tom, ze som opat docasne zapol Xorg a skusil to a naozaj to funguje bez problemov. Uz dlho uvazujem, ze prejdem opat na Xorg, ale Red Hat/Fedora to chcu odstranit, tak asi sa radsej budem trapit x Waylandom.
Nepaci sa mi ani to, ze bezne tunelovanie X aplikacii cez ssh funguje na Xorg vpohode. Pri waylande na to treba vselijake hacky, napr. pouzit waypipe. Ale zas na toto sa aspon da nejak zvyknut a pripravit si na to skripty.
-
Nevidim nic zle, ked sa zide zopar nadsencov a udrziavaju si predmet svojho hobby.
Ved aj tu na roote sa objavuju clanky na temu Amiga alebo Atari ST. Podobne existuju nadsenci, ktori dodnes vyvijaju pre MS-DOS. No a takto to ide postupne dalej s kazdou opustenou technologiou, mame tu distribucie, ktore sa vyhybaju systemd, ako napr. Devuan.
Preto aj ocakavam, ze sa niekto bude venovat X11; bola to kus technologie, co historicky dosiahol urcitu popularitu a vyvolal nejaky sentinent. Navyse je open-source, tak to ani nie je legalna seda zona, ako to je s proprietarnymi starymi technologiami. Ti ludia maju plne pravo dalej sa hrat s X.org (ktory je fork XFree86, ktory je fork MIT X11R6), a ked maju cas, vsak nech sa tomu venuju. Podobne, ako ini sa venuju devuanu, ms-dosu, amigam...
Naopak vnimam dost negativne, ked niekto dopredu vykonava kroky, ako im to zmarit. Naco? Ved ked to nechcu pouzivat, nech to nepouzivaju. Distribucie, ktore to nechcu zaradit, tak to nezaradia. Kde je problem? Nie je nutne preventivne projekt potapat, lebo ludia za nim mozu dokazat ho pohnut niekam, co povodni maintaneri nechceli.
-
Však "nadšenci" majú ten XLibre. Ak sa nepožerú navzájom, môžu na ňom pracovať. Majú už dopredu vytvorený politický manifest, tak si spolahlivo odfiltrujú ľudí. To je win-win situácia, nie?
Ja som sa rozhýbal vďaka tomu a konečne som na waylande. Labwc je ešte nedokončený, ale používam ho bez utrpenia. Práve som milo prekvapený, aké je to svižné.
-
Tiež som nedávno prešiel na wayland na novom notebooku. Notebook má obmedzenie detekcie externého monitoru a tak SDDM ide cez wayland.
Zatiaľ som nastavil na nenatívne rozlíšenie pretože Jdowloader nevie škálovať. Trošku som musel bojovať s gtk aplikáciami a vynútil beh cez xwayland. Ale som spokojný.
A k tomu hoby projektu. Môže sa stať že v budúcnosti to prestane byť hoby projektom.
-
X je moloch, pretoze robi vela veci a historicky sa musel prisposobovat a menit, takze ani Theo by vela vody nenamutil v tych spagetkach. Boom vyvoja v 2000s bol zrejme kvoli grafickym kartam - najuzitocnejsie optimalizovane video vykreslovanie a compositor. Dalsie posuny sa nerobia kvoli tomu, ze vela ludi uz proste odrastlo z dobrovolnickej fazy, klucovi ludia sa vrhli do Waylandu a do buducnosti to bude este horsie, nie len pre tieto projekty.
7. 7. 2025, 09:51 editováno autorem komentáře
-
> Kdokoli může převzít financování vývoje projektu X.Org a vyšperkovat jej tak, že Wayland zašlape v prach.
To, žiaľ, nie je celkom pravda. Pokiaľ budú vo vedení X.Org a Freedesktop ideologicky posadnutí ľudia presvedčení o tom, že poznajú jedinú správnu cestu, žiadne množstvo financovania projekt nezachráni.
Práve preto je riešením fork.
> když poté Enrico stvořil fork X.Org Serveru, který hostoval přímo na GitLabu freedesktop.org s ne úplně sluníčkově-korektními komentáři na adresu lidí kolem X.Org Serveru, porušil nepsané pravidlo kdo chce s vlky býti, musí s nimi výti. Byl mu odebrán účet na GitLabu, což spustilo zmíněnou vlnu revertů jím zaslaných změn.
Ani toto nie je tak úplne pravda. Jediné ne-sluníčkové, čo pôvodný repozitár obsahoval bolo odstránenie CoC, text vysvetľujúci, čo sa udialo, pribudol do README až po presune na Github. Fork existoval nejakú dobu, než došlo k vyhosteniu Enrica z gitlabu po tom, ako sa o ňom začalo hovoriť na odborných stránkach a sociálnych sieťach.
-
Iniciativě držím palce. Wayland z mého pohledu nesmyslně zařízl některé funkce pro automatické ovládání desktopu. To bylo před několika lety, možná už je to jinak. Ale tehdy mi nějaký vývojář napsal, že to tak prostě je kvůli bezpečnosti. To na 1 stranu chápu, na 2. stranu vzít lidem možnost i si to nastavit je zbytečné omezení.
-
To není nějaké uznávání chyby. To je prostě standardní vývoj nové generace řešení. Návrh Xorgu vznikl v 80. letech, kdy počítače vypadaly úplně jinak, a táhne si za sebou 40 let vývoje. Kdyby nové řešení reimplementovali 1:1, tak dostanou řešení se stejnými problémy jako Xorg. Proto je Wayland základní protokol, který víceméně řeší jen základní komunikaci mezi kompozitorem a klienty. A na zbytek jsou tu rozšiřující protokoly Waylandu a portály xdg. Tam si vývojáři nikdy žádné principiální hranice nedávali. Prostě když je po něčem dostatečná poptávka, tak se na to implementuje řešení. Jen to chvíli trvá, protože jsou to otevřené protokoly, na kterých se musí shodnout většina komunity, takže diskuse je občas zdlouhavá, a požaduje se po tom, aby to nebylo ve stylu Xorgu "všichni mají přístup ke všemu", ale aby to bylo v bezpečnostním standardu, který si komunita kolem Waylandu stanovila.
-
S lidmi z Valve jsme HDR řešili. Já jejich přístup naprosto chápu: oni mají roadmapu vydávání hardwaru a podle toho deadliny na implementaci. Oni si nemůžou dovolit čekat, až se komunita dohodne na podobě protokolu apod. Udělat si návrh a implementaci in house bude vždy rychlejší, než se domlouvat na otevřeném protokolu pro všechny. Na toto ta tvorba otevřených řešení nebude nikdy dost rychlá. A možná to je tak dobře, protože ty diskuse se táhnou, ale zpravidla přinesou dlouhodobě nejlepší řešení pro všechny strany. Asi by taky nebylo úplně ideální, když by podobu podpory HDR v Linuxu na dalších 20 let definovalo to, co parta pár vývojářů ve Valve dala dohromady v časovém presu bez ohledu na potřeby ostatních.
-
Steam Deck/HDR je trochu jina situace ktera ovsem vyborne ilustruje zasadni rozdily mezi FOSS a komercnim software.
Steam Deck/HDR je komercni produkt ktery Valve vydela penize takze do toho radi neco investuji. Steam Desk pohani cipy od AMD, AMD dodalo pro Steam Desk closed-source drivery a take podporu pro X11 (HDR delalo AMD, ne Valve).
Takze na Steam Decku bezi neco jineho nez na beznem desktopu, stejne jako Android je i neni Linux.
Pokud mate zakazniky, vizi a cil pak neni problem udelat cokoliv. Za soucastny Linuxovy otevreny desktop ale nikdo neni ochotny zaplatit ani korunu, tak se nedivte ze vypada jak vypada (nerikam ze to je nutne spatne).
EDIT: Ovsem AMD se take vyrazne angazuje v opensource HDR implementaci - napr. v cervenci budou poradat treti kolo HDR hackfestu.
24. 6. 2025, 07:54 editováno autorem komentáře
-
Ked som pred par rokmi po tom patral, tak som nasiel, ze boli uz minimalne 2 pokusy ako nejaky subset tych funkcii spravit cez protokol. A tie neboli akceptovane. Nesledujem to aktivne, ale vnimal som to ako aktivne odmietanie alebo prinajmensom ignoraciu.
Clovek, ktory chce nejaky protokol, si musi ten protokol napisat, implementovat a nakoniec udrzovat vo vlastnom forku wlroots, ktory nema sancu rozsirit sa ani odovzdat do udrzby upstreamu.
7. 7. 2025, 09:57 editováno autorem komentáře
-
V tom case neexistoval zvoleny X11 server. Boli rozlicne xservery, od Xsun po Xming. A nielen softverove, ale aj hardverove - slzu zatlacam pri spomienke na DEC VXT200. Pre linux existovalo niekolko implementacii, vratane proprietarnych -- ktorych biznis case bol, ze podporovali graficke karty, co XFree86 nepodporoval. A kazdy z nich mal ine rozsirenia.
Vo window manageroch bol tiez dobry bordel, kazdy si implementoval co chcel a aplikacie nevedeli, s cim mozu pocitat alebo nie. Samozrejme, aj ked na na niecom dohodlo - napriklad na ICCCM v jeho jednotlivych verziach - kazdy z nich mal iny nazor, ako standard interpretovat a implementovat, cim sa chaos este prenasobil.
Protokoly sa neimplementuju v samotnych DE, ale v kompozitore (teda napriklad v Gnome: v mutteri, nie v gnome-shell. V KDE v kwin, nie v plasmashell). Doslo k zluceniu toho, co bol kedysi X server a window manager (ale window manager; nie shell! A teda, ciastocne... cast sa presunula opacnym smerom do jadra, dnes uz X server neriesi ovladace, ked ma KMS a /dev/input) a dovod je... zjednodusenie. Ono synchronizovat kompozitor s displej serverom, ked bezia v dvoch rozlicnych procesoch nie je jednoduche, nebodaj po tom chciet este aj frame perfect vysledok; tak wayland to ma in-process a problem je vyrieseny.
-
Nemusí, může použít např. wlroots. Dokonce bych řekl, že ta situace může být dlouhodobě jednodušší než u X11, protože rozhraní mezi WM a implementací společných věcí ve Waylandu se může rozvíjet nezávisle na Waylandu. Klidně zítra může někdo udělat fork wlroots, rozbít půlku zpětné kompatibility, a pokud se tím něco zásadně zlepší, některé WM na to přejdou. Kompatibilita s aplikacemi na Waylandu ale zůstane.
-
Vůbec nechápu která bije. Nechce mi to někdo vysvětlit? O čem se to tady pořád mluví? Jaký hrůzostrašný X.org vs Wayland? Jaké hrůzostrašné chyby X serveru, jaké hromady chybějících funkcí waylandu?
Já prostě otevírám a zavírám okna, přepínám jedno za druhým a až s tím skončím tak to celé vypnu...
Nějak nechápu kde mám hledat ty chyby a chybějící funkce? Jak ve starém tak v novém řešení? To jakože to neumí superskvěle setřídit 40 oken do jednoho sloupce vedle sebe? Nebo že se někomu kreslí obsah okna mimo rámeček? Nebo co si jako mám představit? Nějak mě toho moc nenapadá.
Max nějaký tenký klient, který kreslí okna rendrovaná na vzdáleném serveru?
-
Co se divíte? Jste na Rootu. Tady se bude polovina hádat o podobné věci a ta druhá vám zuřivě vysvětlovat, jak to musíte řešit protože to přece potřebujete i když o tom vůbec nevíte (protože oni to ví lépe co potřebujete). A z obou těch polovin si polovina nedovede představit, že existují lidé, kterým je to naprosto jedno a jediné co chtějí je, aby to fungovalo. Že je jich dokonce převážná většina, to ani nemá cenu zmiňovat.
-
A z obou těch polovin si polovina nedovede představit, že existují lidé, kterým je to naprosto jedno a jediné co chtějí je, aby to fungovalo. Že je jich dokonce převážná většina, to ani nemá cenu zmiňovat.
Což o to, já si to představit dokážu. Problém je ale v tom, že většina funkcí, kromě těch naprosto základních, většinu lidí nezajímá; to ale neznamená, že nejsou potřeba. Kdyby se neimplementovala žádná funkce, kterou nepotřebuje většina, bude ten software nakonec nevyhovující nebo omezeně použitelný pro skoro všechny.
Když si vezmu třeba GIMP, tak můžu s jistotou říct, že velkou většinu funkcí, které tam jsou, jsem nikdy nepoužil, a je velmi pravděpodobné, že většinu z nich nepoužiju nikdy. Ale nebudu kvůli tomu vykřikovat, že tam nemají být nebo že nejsou potřeba. I funkce, kterou využije jen pět procent uživatelů, je užitečná, přestože by se zbylých 95 procent bez ní pohodlně obešlo a možná by si ani nevšimli, že tam není.
protože oni to ví lépe co potřebujete
Ne, oni pouze vědí, že to oni potřebují.
-
Mno vetsina (naprosto drtiva) lidi naprosto nechape, proc maji vymenovat neco co mozna nefunguje optimalne, za neco co zcela jiste funguje uplne blbe.
A je jim uplne jedno jestli se to nejakymu patlalovi kodu libi nebo ne.
Protoze jak tu zaznelo, v Xkach sice taky ledacos nefunguje, ale da se to ruzne ohnout. Zatimco v weilandu toho nefunguje o 3 rady vic, a jako bonus se s tim neda delat nic.
Jo ja vim, henta beeezpecnost ... jako ze si root muze cist data roota ...
-
Xnest; X server beziaci pod inym X serverom. Teoreticky sa tym dokazala dosiahnut izolacia podobna Waylandu, ale so vsetkymi nevyhodami co sa vycitaju Waylandu (screenshoty, capture, globalne shortcuts) a so zachovanim vsetkych problemov X11 (mixed dpi displeje, ziadne hdr, sialena neefektivita).
Teoreticky bolo mozne pre kazdeho klienta (alebo skupinu klientov), ale nikto to nerobil. Qubes OS sice izoloval jednotlive aplikacie do jednotlivych pseudo-vm, ale vsetko bezalo na jednom X serveri, akurat odlisene farbickami, ktore okno patri do ktorej domeny.
-
Pěkně jste vyjmenoval přesně to, co nejen já ale spolu se mnou velmi mnoho uživatelů potřebujeme (screenshoty, capture, globální shortcuts) a co zase až tak podstatne není (řešení DPI, nějaké HDR, "neefektivita"). To první jsou vyjmenované nevýhody Waylandu, to druhé "problémy" X11. Přesně tohle je důvod, proč se tolik lidí proti Waylandu staví. Hezky shrnuto.
Wayland se naštěstí zlepšuje; to, co před dvěma lety byl problém už dnes až takový problém není a to ani z toho vyjmenovaného. Ale těžko se pak můžete uživatelům divit.
24. 6. 2025, 20:42 editováno autorem komentáře
-
No, skoro bych řekl, že když se teď půjdu zeptat stovky lidí v mém okolí, co je "HDR" bude vědět tak pět lidí ze sta. A jsem si celkem jist, že když se půjdu zeptat všech vývojářů v mém okolí za posledních pět let, 90 % z nich bude řešit prostě to, aby měli dva displeje zobrazující v jejich nativním rozlišení a DPI natož nějaké HDR je nebude zajímat vůbec.
A ne, nepotřebují X11. Oni totiž nepotřebují ani Wayland. Je jim to totiž úplně jedno. To je přesně to, o čem jsem psal. Děkuji za názornou ilustraci.
-
A potom ich postavite pred dva pocitace, jeden ma nejake technicke vymyslenosti typu hidpi, hdr a display p3 a druhy nie, a nechate pouzivatela si vybrat, ktory sa mu viac paci ako zobrazuje napriklad ich fotky.
S vynimkou tych, co prevadzkuju elektrosrot, je velmi lahke predpovedat ich vyber.
Pouzivatelia netusia, ako sa dana feature nazyva. Vedia ale povedat, ktory z celkovych dojmov uprednostnuju.
-
"prekvapeni, ale riesenie dpi, hdr"
Ne, nechce, naprosto je to nezajima. Takovej uzivatel vubec neexistuje. Schvalne ju? Zeptam se dneska kazdyho koho potkam jestli vi co toho dpi neho hdr ... odpoved bude vyplaseny vykuleny pohled.
Zato co je to screenshot bude vedet kazdy jeden.
Kdyz sem ja osobne chtel onedha otestovat hdr, musel sem stravit nekolik hodin hledanim neceho, na cem bych to vubec vyzkousel ... a tim taky veskery pouzivani tyhle pseudovymozenosti skoncilo.
-
Tak im to ukazte, nepytajte sa na technicky nazov.
Ukazte im foto z ich mobilu, ako vyzera na HDR a ako na SDR. A ktory z tych monitorov by chceli.
Ono je dovod, preco Apple predaval naposledy SDR displeje v lowend modeli z roku 2020.
Podobne, pouzivatel by netusil o com hovorite, ked sa ho spytate na TN alebo IPS. Ked mu to ukazete, vyberie si IPS, bez toho, aby tusil, co to IPS je. Doprdele, mal som osemdesiatnika so sedym zakalom, ktory chcel "ten jasnejsi".
-
Zeptam se dneska kazdyho koho potkam jestli vi co toho dpi neho hdr
Samozřejmě, že když se jich zeptáte na ty zkratky, tak to nikomu z nich nic neřekne. Spíš se jich zeptejte, jestli chtějí, aby když připojí notebook do libovolného externího monitoru nebo projektoru v kanclu, měli vše na všech monitorech ve správné velikosti. Nebo když si pustí na notebooku Netflix, jestli by chtěli, aby to mělo plnější a zářivější barvy. To první běžní uživatelé minimálně v práci řeší dnes a denně. To druhé je určitě víc nice to have, ale něco, co běžní lidi na televizích a mobilech řeší taky.
-
"Nebo když si pustí na notebooku Netflix, jestli by chtěli, aby to mělo plnější a zářivější barvy."
Tyz necet co sem psal, a netflix si nikdy nevidel. 99% toho co tam je zadny hdr neumi. Takze se zadny zarivejsi bravy jednoduse nekonaji. Je to presne naopak, vsechno je vyblitejsi, a jen to specielne vecer ma zcela nesmyslnej jas.
Proto se na to vymejslej takovy veci jako (typicky prozmenu ve dne nefunkcni) samoregulace jasu, pripadne kvuli tomu nocnimu pozorovani sviceni kolem zobrazovadla ...
-
Přesně tohle je důvod, proč se tolik lidí proti Waylandu staví.
To usuzujete na základě čeho? Na jednu stranu tady ostatním vyčítáte, že se utápí v diskusi o technických margináliích, zatímco většinu uživatelů to úplně míjí, na druhou stranu to zároveň používáte jako argument proti Waylandu. Nemluvím na základě dojmů, ale zkušeností, které máme z distribucí, které používají miliony uživatelů, na základě toho můžu prohlásit, že drtivá většina uživatelů žádný přechod na Wayland neřeší. Když jsme třeba ve Fedoře přecházeli na Wayland jako výchozí, což už bylo před hodně lety, podle diskusí jako tato to vypadalo, že to bude konec světa. Realita byla taková, že ten přechod většina uživatelů ani nezaznamenala, negativní zpětná vazba byla minimální.
Pokud si dnes většinový uživatel na Waylandu nad něčím posteskne, tak nad tím, že mu v nějaké aplikaci, která jede na prastaré verzi Electron, nejede sdílení obrazovky, ale to není chyba Waylandu, protože to API pro to existuje už roky. No a to je tak zhruba vše. Věci jako X forwarding řešíte vy a tak jeden další uživatel ze sta. To jen, abychom vyjasnili, jak na tom většinoví uživatelé jsou, když už jste s tím začal.
-
> Qubes OS sice izoloval jednotlive aplikacie do jednotlivych pseudo-vm, ale vsetko bezalo na jednom X serveri, akurat odlisene farbickami, ktore okno patri do ktorej domeny
Každá doména má svůj X11 (případně jiné řešení, ale v praxi stále X11). A odtud obsah oken přebírá GUId v domě, který to nechává kreslit s rámečky (a případně názvy domén v titulku).
-
A stejně jste dnes jeden ze sta, protože tak složitý layout oken lidi obvykle nepoužívají.
A za druhé obvykle lidi jen zaklapnou víko notebooku a uspí ho. Obnovení sezení přes restart je krásná funkce, ale neviděl jsem ji prakticky použit ani u jednoho člena (širší) rodiny. Naopak, obvykle před restartem okna ještě uklidí.
