Én próbáltam kb 1 hete Pi4-en. A hardveresen gyorsított videolejátszás nem működött vele, visszaváltottam x11-re, újra működött. Nem álltam neki komolyabban nyomozni, hogy mit kéne máshogy csinálni.
A régin meg a hardveresen gyorsított kijelzőre rajzolás nem ment :D
Dekódolta a videót, de pixelenként rajzolgatta ki procierőből. Ha waylanddel megy, akkor végre tényleg lehet majd átlagos használatnál is egy gyenge pécé szintjét hozni vele. Persze minimum 8GB ram akkor is kell.
Waylanddal elvileg jobban kéne menjen, kisebb procierővel a weblapok megjelenítése is.
Ja mondjuk pi5ön meg eleve nincs h265-ön kívül más video codec hw dekódolás, szóval ehh. Ha pi4en emiatt nem csinálják meg, akkor szopacs neked.
A tapasztalatom, hogy valójában még a Pi4 CPU is bőven elég erős 1080p60-ban akár még AV1-et is dekódoljon, legalábbis tipikus youtube-os bitrátán. mplayer -vo null -lavdoptions threads=4 (lehet, hogy a pontos commandline-ra rosszul emlékszem) simán bírja, ki se maxolja a 4 magot. Amint valami ténylegesen megjelenítő video output ki van jelölve, máris kevés lesz a CPU.
Sajnos a wayland sem volt jobb ebből a szempontból.
Minden uj technologia az elodje alol indul, de ott az igeret, hogy fole fog kerekedni. A legtobb gond egyebkent abbol adodik, hogy megprobalnak eszetlenul minden regi featuret ujrairni, mert "hozni kell a regi funkcionalitast".
Mondjuk, aki raer RPi-vel jatszani, az erjen ra az ilyenekre is :)
Minden uj technologia az elodje alol indul, de ott az igeret, hogy fole fog kerekedni.
Ami ígéretet csak akkor van esélye a készítőknek betartani, ha nem erőltetik defaultnak, mielőtt betartják.
A Wayland 15 év alatt képtelen volt olyan szintre fejlődni, hogy mindenben helyettesítse az X11-et és mindenben kompatíbilis vele. Máskülönben már mindenki átállt volna rá. Mivel nagy beégés lenne multiéknak (Red Hat = IBM) ezt beismerni, így elkezdték erőltetni, az X ellen FUD kampányt indítottak valamennyi influenszerükkel, az általuk uralt (sajnos túl sok) desktop környezet és alkalmazást elkezdték visszafordíthatatlanul átírni, dependáltatni rá.
Mivel korporatokrata erővel van lenyomva a Linux-világ torkán, így valószínűleg a büdös életben nem fog az X fölé kerekedni. Ha képesek lettek volna erre, már a fejlesztés első 1-2 évében megtörtént volna a felülkerekedés.
Mondjuk, aki raer RPi-vel jatszani, az erjen ra az ilyenekre is :)
A Raspberry PI lehetne egy tök jó vékonykliens, megfelelő szoftverekkel, de nincsenek rá megfelelő szoftverek, mert a desktop alkalmazásokat 13. generációs, 8 magos, 64 GB RAM-os, 1 TB SSD-s babzsákfejlesztők írják.
Kicsit +1, de azért a fejlesztőknek csak vannak nagyobb ssd-jeik is... Egyébként notin és asztali gépen átálva is jelentősen gördülékenyebb a wayland, mint az X volt. Valószínűleg pont nem használok olyan feature-t, ami ne menne.
A Wayland 15 év alatt képtelen volt olyan szintre fejlődni, hogy mindenben helyettesítse az X11-et és mindenben kompatíbilis vele.
Nem akarja mindenben helyettesíteni, vannak dolgok, amikre sokkal jobbak a különálló alkalmazások. Főleg nem akar kompatibilis lenni vele.
A Raspberry PI lehetne egy tök jó vékonykliens, megfelelő szoftverekkel, de nincsenek rá megfelelő szoftverek, mert a desktop alkalmazásokat 13. generációs, 8 magos, 64 GB RAM-os, 1 TB SSD-s babzsákfejlesztők írják.
Számomra már bőven tudja hozni azt, amit az elődje.
Több, mint egy fél éve áttértem rá, ez az elsődleges desktop rendszerem.
Hirtelen nem is tudok olyan programot mondani, amit használok és kellene hozzá az xwayland. Na jó, egyedül a Gimp, de annak a következő stabil verziója is már tudni fogja a wayland-et natívan.
Akkor hülyék a programozók akik azzal szopatják magukat, hogy újraírnak egy meglévő funkciót? Használsz több monitort?
chatgpt:
Wayland fejlesztését az X11 protokoll bizonyos korlátai és elavultsága indokolta. Az X11 az 1980-as években készült, és azóta számos funkciót és biztonsági javítást kapott, de alapvető felépítése miatt egyre nehezebb volt modern elvárásokhoz igazítani. Wayland célja, hogy letisztultabb és hatékonyabb architektúrát biztosítson, ami jobban illeszkedik a mai hardver- és szoftverkörnyezethez.
Íme a főbb különbségek és előnyök:
Letisztultabb architektúra: Wayland egyszerűbb, és közvetlenebb kapcsolatot biztosít a kliens programok és a megjelenítő között. Az X11 számos funkciót bonyolultabban old meg, míg Wayland minimalizálja a külön rétegeket, ami gyorsabb és kevesebb hibalehetőséggel járó megoldást eredményez.
Jobb teljesítmény és reszponzivitás: Wayland úgy tervezték, hogy elkerülje az X11 esetében megszokott körülményes ablakfrissítést és más, az X Serverhez kapcsolódó késleltetéseket. Így gördülékenyebb animációk és alacsonyabb késleltetés érhető el a felhasználói felület megjelenítésekor.
Biztonságosabb dizájn: Az X11-ben a kliensprogramok több olyan jogosultsághoz is hozzáférhetnek, amelyek biztonsági kockázatot jelentenek (pl. egymás képernyőtartalmához). A Wayland szigorúbban szabályozza a hozzáféréseket, ezért nehezebb kompromittálni.
Több monitor és frissítési frekvencia támogatása: Wayland jobban kezeli a több monitoros környezetet, és támogatja az eltérő frissítési frekvenciákat is, ami az X11-ben nehezebb volt. Ez különösen előnyös a modern nagy felbontású és magas frissítési sebességű kijelzőknél.
Energihatékonyság: Az egyszerűbb kommunikáció miatt Wayland kisebb energiafelhasználást eredményezhet, különösen laptopokon és mobileszközökön.
Mindezek ellenére nem minden program kompatibilis még teljesen Waylanddal, és bizonyos esetekben továbbra is az X11-emulációra (XWayland) van szükség. A Wayland hosszú távú előnyei azonban egyértelműek, ezért folyamatosan növekszik a támogatása a különféle Linux disztribúciókban.
Gyönyörűszépen felmondtattad a Red Hat által összeinfluenszerkedett marketing bullshit-et a ChatGPT-vel.
Wayland úgy tervezték, hogy elkerülje az X11 esetében megszokott körülményes ablakfrissítést és más, az X Serverhez kapcsolódó késleltetéseket. Így gördülékenyebb animációk és alacsonyabb késleltetés érhető el a felhasználói felület megjelenítésekor.
Ahol pedig van kompozitor, ott lesz input lag. Nem az 1980-as évek miatt, hanem a mindenféle OpenGL-es mágiák, copyzások, és a teljes képernyőre erőltetett vsync miat,t ami ablakozásnál totálisan felesleges és amit X11-en az Intel TearFree drivere amúgy lag nélkül hoz.
Az X11-ben a kliensprogramok több olyan jogosultsághoz is hozzáférhetnek, amelyek biztonsági kockázatot jelentenek (pl. egymás képernyőtartalmához). A Wayland szigorúbban szabályozza a hozzáféréseket, ezért nehezebb kompromittálni.
Köszönjük szépen a global hotkey-ek ellehetetlenítését. Bizonyára sok haladó felhasználónak erre™ volt™ szüksége™.
Wayland jobban kezeli a több monitoros környezetet, és támogatja az eltérő frissítési frekvenciákat is, ami az X11-ben nehezebb volt. Ez különösen előnyös a modern nagy felbontású és magas frissítési sebességű kijelzőknél.
Amik totálisan feleslegesek egy fejlesztői gépen, elvégre 60 Hz-et mindegyik tudja alapból és egy átlagos fejlesztési workflow úgy 10-15 FPS képtartalom-változást jelent. Persze, tudjuk, a sokmillió™ kreatív ember, aki csak és kizárólag Linux-on vág videót, a még™ több™ gamer, aki Linuxon játszik és 400 FPS-t akar, meg még sorolhatnám a kizárólag a Red Hat álomvilágában létező entitásokat, akikre hivatkozva tönkre kell tenni sok tízmillió létező entitás munkáját.
Az egyszerűbb kommunikáció miatt Wayland kisebb energiafelhasználást eredményezhet, különösen laptopokon és mobileszközökön.
Erre kíváncsi leszek. Főleg a szarul-húgyul implementált bétaállapotú wayland-driverekkel.
A Wayland hosszú távú előnyei azonban egyértelműek, ezért folyamatosan növekszik a támogatása a különféle Linux disztribúciókban.
A Wayland hosszú távú előnyei ezzel a 15 év munkával és Isten tudja hány csilliárd fejlesztői munkaórával mind megvalósíthatóak lettek volna X11-ben. Ja csak az nem lett volna újrafeltalált kerék, meg nem adott volna akkora hegemóniát a Red Hat kezébe, mint a Wayland, ami jelen állás szerint csak azzal fog teljesértékűen működni, amit a Red Hat tálcán ad mellé (GNOME). Semmi mással.
Ja igen, tényleg, most jönnek az X11 alatt használhatatlan™ Kiosk terminálok, amik miatt az X11-gyel Wayland-nál használhatóbb PC-sek Linux-világát muszáj felforgatni. 🤡 Ugye véletlenül sem azt kell megoldani, hogy a nem-PC eszköz jól működjön X11-gyel, ha az a cél, hogy grafikus környezet legyen rajta.
Melyik Linuxos mobil terjedt el, amin PC-s desktop környezet fut? Semelyik. Androidot ne keverd ide, annak semmi közze se az X11-hez, se a Wayland-hoz.
A többség játékra használja a Linuxot? Nem. Elenyésző kisebbség.
Tehát, továbbra sem világos, hogy mi indokolja a többség Linux-os PC-inek felforgatását, Red Hat tömlőcbe zárását, a felhasználói szabadság lábbal tiprását.
"dorsyka" a "te ervelesi hibad" hogy tenyekkel dobalozol, faszsagok helyett amik csak a fejedben leteznek es kozben meg nem is dobalod a hajtuidet...szar a musor :D
a korlátozott ismereteim alapján, szerintem az egyik legnagyobb gond az X11-gyel, hogy minden gpu-hoz meg kell írni x11 modult. Na ez nem történik meg, ezért olyan vacak például az arm-os grafikai képesség és teljesítmény, mert gpu specifikus megvalósítás helyett univerzális framebuffer kezelőt kell használni, amiben a cpu számol és csinál szinte mindent, a gpu csak buta 2d megjelenítő. Mintha s3triót tennél egy mai pécébe és windows alatt csak a generic képernyő drivert lehetne használni, ami nem nagy élmény.
Nagyrészt azért is, mert opensource drivereket a gpu gyártók nem nagyon adnak ki, mert ipari titkokat kéne felfedniük. Így korlátozott képességűek a nyílt megoldások. Plusz rengeteg munka minden gpu-hoz ablakkezelőt írni. Helyett értelmesebb az, hogy képes legyen a gyártó zárt 3d driverét használva futnia egy ablakkezelőnek. Hogy ne az ablakkezelőből legyen gpu specifikus változat, hanem szabványos apin a gyártói gpu driveren át tudja ellátni azokat a funkciókat.
Na ez nem történik meg, ezért olyan vacak például az arm-os grafikai képesség és teljesítmény, mert gpu specifikus megvalósítás helyett univerzális framebuffer kezelőt kell használni, amiben a cpu számol és csinál szinte mindent, a gpu csak buta 2d megjelenítő.
Tehát akkor azért, mert egy tök másik architektúrán babzsákfejlesztőék lusták voltak normális drivert összehozni, szívassuk meg azokat, akiknek 10+ éve kifogástalanul megy mondjuk az Intel driver a PC-jükön.
Nagyrészt azért is, mert opensource drivereket a gpu gyártók nem nagyon adnak ki, mert ipari titkokat kéne felfedniük.
Azért nem adnak ki, mert akkor támogatni is kéne, azt meg nem akarják. Az üzleti titkos érvelés nevetséges.
Plusz rengeteg munka minden gpu-hoz ablakkezelőt írni.
Miért kéne mindegyikhez új ablakkezelőt írni? Ezt melyik wayland bullshit oldalon olvastad? X11-hez kell ablakkezelőt írni, a protokoll szerint.
Helyett értelmesebb az, hogy képes legyen a gyártó zárt 3d driverét használva futnia egy ablakkezelőnek. Hogy ne az ablakkezelőből legyen gpu specifikus változat, hanem szabványos apin a gyártói gpu driveren át tudja ellátni azokat a funkciókat.
Ezzel annyit mondál, hogy Windows-osítsuk el a Linuxot, és majd a multik (Red Hat, NVidia, AMD stb.) megmondják nekünk, hogy használhatják a gépünket. De minek, ha már van egy Windows, ahol ez adott?
Saját fejlesztésű webes ERP fut benne, aminek van MRP része is. :) Ez annyit jelent, hogy a termelés, csomagolás, komisszió ami a felületen direktben történik munkavállalók által. Emellett több folyamatot implikál ezen tranzakciók. pl.: lecsomagol 10 db valamit, akkor az +10 db bevétel az adott termékből, és -10 db n számú csomagolóanyag (flakon, címke, kupak, etc ...) emiatt ahogyan a termelés átvisz egy raklapnyi terméket a raktárba kvázi realtime látjuk az adatokat és látják valós időben a webes vásárlók is. Amit nem látnak a vevők (csak többen tudják), hogy bármilyen hiány esetén 24 órán belül legyártjuk azt, mert sok gépünk van és a termelést is tudjuk megkezdésig/foglaltságig átütemezni mindkét dimenzióban (hol /n számú keverő/, mikor).
A monitor HDMI + USB AM-BM kábellel csatlakozik az RPi5-höz, amiben Firefox fut.
Az RPI elfér a monitor hátán, sima TV fali állvánnyal van rögzítve a falhoz. Mivel nincsenek gőzök vagy por, így nincs plusz védelem. Ha ilyen helyre tenném, akkor nem használnék érintőképernyőt, hanem beraknám egy fém szekrénybe aminek az elejét kivágnám és raknék bele üveget, fóliázva. Majd az input eszközöket kivezetném és gyakran cserélném.
A PI - viszonylag - szűk erőforrásokkal bír, erőforrással a wayland jobban gazdálkodik. Ez nem az X11 ellen szól, hanem a RPI jellemzőiről, hogy ezen a platformon a wayland-nek van keresnivalója, nem öncél a használata.
X11, úgyérted Xorg? A wayland jobban gazdálkodik az erőforrásokkal? Annó az xfree86 működött a 386-osomon, egy tseng et4000-essel, és 8MB rammal.
Mondjuk onnantól kezdve, hogy még ezer és egy alkalmazáshoz kell az xwayland, addig nálam felejtős, mert persze szép, hogy a wayland kevesebbet tud és így elméletben gyorsabb, de mit kezdjek vele az xterminálommal?:)
Akkor már dobhatnánk az egész kliens-szerver modellt és a userspace-t, bedobhatnánk a kernelbe a grafikát, ablakkzelővel együtt, ahogy azt MS-ék kezdték... csak arra utalok, hogy nem minden a teljesítmény... még ha igaz is lenne.
Szerintem félreértjük egymást, amiket felsorolsz terminál emulátorok, nekem meg envizex-em van, az hardveres xterminál. Még saját ablakkezelőt is tud futtatni, ha szeretném pl. CDE-vel dekorálni a mai alkalmazásokat,de szerintem waylandet azt nem tud :D
De még így is elbasztad, mert a Fedora a Red Hat gondozásában álló projekt. 🤡
A nagy multik: Red Hat = IBM, Canonical, SuSE
Ezek közül, aki erőlteti: Red Hat
Az átlalad felsoroltak átveszik, mert nincs annyi fejlesztői kapacitásuk, hogy elforkolja a GNOME-ot, meg a fél Linux desktopot. Az alulról építkező, nem multis hátszéllel dolgozó készítők és közösségek közül egyedül a Debiannak lett volna, és meg is tudták volna állítani a Red Hat ámokfutását még a systemd-s viták idejében, de valószínűleg túl sok Red Hat influenszer épült be a köreikbe.
Ne legyél már meglepődve. Van kialakult véleménye, és az természetesen "sokkal közelebb van az igazsághoz" mint bárki másé. Aki ennek ellentmond az hülye. Ennyi. Én már csak vigyorgok mint a tejbetök mikor meglátom, hogy valamihez hozzászól.
A tiédet még nem láttuk! Lehet az még közelebb van az igazsághoz? Nem csak vigyorogsz, hanem megint kötözködni jöttél és hogy elmondhasd, hogy Hajbazer mennyire hülye.
De ha most ettől eltekintünk. Mivel lett jobb a Wayland, mintha az X-et kalapálták volna ki? Ami egy sok évtizede működő, sokak által látott és javított kódbázis. Nem. Inkább írjuk újra, mert attól jobb lesz? Mikor? Mert még nem annyira látni, hogy jobb lenne.
"Mivel lett jobb a Wayland, mintha az X-et kalapálták volna ki?"
Az X11-et úgy 30-40 éve "kalapálják ki". Gyakorlatilag extension hátán extension. Egy borzasztó agyonbonyolított tákolmány lett belőle. Az extension-ök fele kb azzal foglalkozik, hogy kerülőutakat biztosítson a normál socket-alapú (lokálisan futó grafikához elég nagy overheadet okozó) X11 protokol helyett. Ráadásul a kliensnek mindenre IS fel kell készülnie, bármelyik extension hiányozhat (vagy éppen azért nem elérhető, mert remote session van), mindenre kell fallback.
Nyilván a widget frameworkök evolúciósan vele együtt fejlődtek, ezért hozzá vannak kupálva. De a kódbázison belül ezek a fallbackek is már archeológiai rétegeket képeznek.
Szóval a waylandnek volna létjogosultsága. Hogy mi ment félre, amiért 15 év alatt nem tudott 1-ről 2-re jutni az egy másik (amúgy önmagában érdekes) kérdés.
Van létjogosultsága bárminek, ami minden szempontból jobb az X11-nél. A Wayland nem ilyen, tehát nincs neki. Ezért fogják erővel lenyomni a Linux-világ torkán. Már rég adoptálta volna minden disztró, ha minden szempontból jobb lenne.
"Szóval a waylandnek volna létjogosultsága. Hogy mi ment félre, amiért 15 év alatt nem tudott 1-ről 2-re jutni az egy másik (amúgy önmagában érdekes) kérdés."
Mondjuk az eleg szorakoztato, hogy Ubuntu 22.04 default lett, aztan olyan teljesen marginalis feature-k nem mukodtek, mint screen sharing....
Az én szubjektív meglátásom az, hogy nagyon-nagyon el akarták kerülni, hogy Waylanddel ugyanaz történjen, mint az X11-el - vagyis idővel szét kelljen patchelni mindenféle extensionökkel, amivel az alapfunkcionalitást lényegében teljesen átalakítják/megkerülik. Ezért a Wayland API-t szándékosan nagyon minimálisra tervezték és kb mindent kiszerveztek a compositorba. Ezzel architekturálisan nem lenne baj.
A baj azzal van, hogy egy "szabvány" compositor API nem lett specifikálva (ami nincs specifikálva az nem avul el, ugye...), és most van vagy 15-féle compositor Wayland-re, egymással inkompatibilis programozási felülettel. A nagyon egyszerű alkalmazásoknak ez nyilván mindegy, azoknak elég, hogy wayland kliensek, a compositor meg a fejük felett teszi a dolgát. De ha kicsit is bonyolultabb dolgot akar valamelyik alkalmazás (fullscreen, window dekorációk eljrejtése / saját window dekoráció, screenshot / screen capture), akkor máris a compositor-specifikus API-khoz kell fordulni.
Vagyis az egyik probléma helyett csináltak egy másikat. Most már az alkalmazások nagy részét nem wayland-re, hanem az egyes wayland compositorokra kell portolni. Szerintem itt csesződött el az egész.
Lényegében csináltak egy szétgányolt X11 architektúrát, amit ugyanúgy kell körbehákolni a compositorokkal, mint kellett az X11-et az extensionökkel. Csakhogy utóbbi valahogy működik, stabilan, kiszámíthatóan, évtizedek óta és nem kell a fél desktop világot újraírni hozzá.
Szerintem te kevered az eszközt a céllal. Az újraírás egy eszköz arra, hogy a felette lévő milliónyi alkalmazás elkészítése és futtathatósága a jövőben egyszerűbb legyen, ami maga a cél.
Ezért a Wayland API-t szándékosan nagyon minimálisra tervezték és kb mindent kiszerveztek a compositorba.
A Wayland az egy protocol, amit a compositor (és a kliens) implementál. Nincs compositor specifikus API, csak Wayland API van.
Mivel könnyű implementálni a Wayland protocolt, emiatt van sok compositor, de a kliensek ugyanúgy fordulnak a compositorhoz, mindegy melyik az.
Őszinte leszek, amikor utánaástam a válasznak, kissé meglepett, amit találtam. Azt hittem, hogy ennél több közös lesz a megoldásokban, de ez heterogénebb, mint gondoltam.
A KWin-ben screenshotot egy org.kde.KWin.Screenshot2 nevű másik API-n keresztül tudsz csinálni. Ez egy "out-of-band" API, a wayland protokol teljes megkerülésével, d-bus-on megy.
A gnome-shell esetéről annyi derült ki, hogy Shift-PrintScrn, Ctrl-PrintScrn billentyűkre csinál screenshotot (tehát magán a compositoron belül dolgozza fel a keyboard event-et, és belül intézi el a screenshot készítést). API-ról nem találtam semmi használhatót (gyanítják, hogy d-bus-on keresztül ki van vezetve, de nem találtam meg pontosan milyen néven).
Hogy csinálja a Weston: van egy weston-output-capture nevezetű saját protocolja. Lényegében olyan, mint a wlroots megoldása, de azzal nem kompatibilis saját extension.
Most erre mit mondjak... :/ (nem, nem akarok hajbinak igazat adni...)
Igen, ebben igazad van, nem volt elég jól megcsinálva a screen capture rész. A wlroots kidolgozott egy elég jó megoldást, ami két hónapja be is került a hivatalos Wayland protocolba.
Sajnos egy kicsit eső után köpönyeg állapotot érzek, de talán még van esély rá, hogy a többi megoldás átáll rá.
Nézegettem mik vannak még a wlroots unstable repoban. Hát elég alap javaslatok döglenek ott 4+ éve. Pl notification kezelés az output device változásokról: https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/blob/master/unstable/wlr-output-management-unstable-v1.xml?ref_type=heads - oké, ez sok idő volt, mire Xorg-ban és a linux DE-kben végre normálisan támogatva lett, de ma már elég alap, hogy notebookra rádugom a dokkolót - 2 képernyő, lehúzom - 1 képernyő. Vagy VM-nek átméretezem az ablakát, és a guest desktop mérete automatikusan igazodik hozzá. Power management dettó ugyanez. Input inhibitor - lock screenhez elég elengedhetetlennek tűnik. Gondolom a népszerűbb compositorok (muszájból) ezekre is megcsinálták a maguk kis kerülő-megoldásaikat.
A wayland nagyon óvatos abban, hogy mit fogad el stable protokollnak, hogy ne legyen bloat amit nehéz implementálni. Illetve gyakran merül fel a kérdés, hogy egy dolog a wayland része legyen-e vagy csak XDG által szabányosított D-Bus API. Eleve nem is lehet stable egy wayland protokoll addig, amíg 3 compositor nem implementálja azt. Teljesen normális ügymenet az, hogy a compositorok előállnak egy problémával, implementálnak egy saját megoldást, aztán elkeződik a párbeszéd, hogy kinek a megoldását vegye át a többi ami után szabványosítva lesz a protokoll. Legalábbis nekem eddig ez jött át.
Van létjogosultsága bárminek, ami minden szempontból jobb az X11-nél. A Wayland nem ilyen, tehát nincs neki.
Ez egyébként így nem igaz. Nem kell neki minden szempontból jobbnak lenni, elég szempontból kell jobbnak lenni, hogy jobb kompromisszum legyen. Semmi komplexet a világtörténelemben még nem sikerült úgy megjavítani, hogy minden tekintetben jobb legyen, szükségszerűen az szokott lenni, hogy az eredeti struktúrán valamit változtatni/cserélni kell, mert gátja valaminek, aztán ettől persze az eredeti sturktúra pozitívumaiból is fogsz veszteni, mert egy a való életben egy csomó minden tengelyek mentén mozog.
Mostanában csináltam egy VNC-szerű szervert X-re. Semmi mást nem vár el az X-től, minthogy egy bufferbe tudjak screenshotokat csinálni, és be tudjak injektálni egér és billentyűzet eseményeket. Ahhoz, hogy ezt megcsináljam egy rakás alig dokumentált extensiönt kellett használni és csak úgy tudtam rájönni, hogy mit kell csinálni, hogy az egyik XVNC-ből néztem ki a lényeget. Ha megnézed egy XVNC kódját, a képernyő változásainak követésére van kb 10 féle megoldás, és mindegyik extensiönön keresztül érhető el. A kódját nézegetve megállapítottam, hogy csoda, hogy ez a kupac egyáltalán működik.
Ez se rossz. Nekem a kedvenc példám egy antialiasolt bezier-görbe (vagy ha valakinek az jobban tetszik, b-spline) rajzolás X11-en. Gyakorlatilag megoldhatatlan X11-es rajzoló primitívekkel. Lehet különféle extension-ökkel (pl xrender) feltételesen kb-működő megoldásokat összerakni, még az is számít, hogy a képernyő 32 bites üzemmódban van-e, (24 vagy 16 bitesben nem működik, mert támaszkodik a framebufferben lévő alpha channelre, ami vagy megvan vagy nincs) stb. Lesz vagy 5-6-féle code path-od a különböző alesetekre. Szomorú, de végül kb a legjobb megoldás, hogy teljesen kliens oldalon fenntartasz egy canvas-t, teljesen kliens oldalon, CPU-ból megrajzolod, és PutImage()-el az egész bitmap-et átküldöd az X szervernek. Ígyis-úgyis le kell ezt implementálnod végső fallbacknek. És meglepő módon remote X sessionben még ez a leggyorsabb, mert ugyan sok adat mozog, de kevésszámú szinkron hívás miatt ez a legkevésbé latency-érzékeny.
Annó volt a Mir, és ők azt állították, hogy vannak automa tesztjeik. Ha van mindenre automata teszt, és emellé a feature-ök minimálisan vannak tartva, nincsenek különbségek, hogy mi mit implementál, akkor el lehetne érni azt az ideális állapotot, hogy ha van egy GUI program, és elindítjuk, akkor az működni fog és kész.
Állítólag (talán ebben a topikban írta valaki) a Wayland ugyanolyan lett mint az X, hogy extensionöket kell használni: ez teljesen aláássa a stabilitás esélyét, és az egésznek az értelmét SZVSZ.
na megjott hajbi felszopofiuja azonnal ugrik megvedeni :D
Hajbi megint ossze-vissza ir baromsagokat, de azert te csak csodald ot ragyogo manga szemekkel. Remelem azert fizet a szopasert, mert ezt igy ingyen ezer' bevallalni eleg kemeny :D
"megint kötözködni jöttél és hogy elmondhasd, hogy Hajbazer mennyire hülye." - ebbol probaltam nem azt kihamozni hogy azonnal ugrottal a kiscicadat megvedeni, de nem talaltam benne semmi mast :D
Utana jott egy kerdes, ami nem mondando: "Mivel lett jobb a Wayland, mintha az X-et kalapálták volna ki?" - ami azt mutatja hogy meg nem neztel bele az X libjeibe milyen konnyen gyorsan es faszan lehet programozni benne. Segitek: nem ( de ezt le is irtak utana jo hosszan paran) valamint hibasan feltetelezed, hogy a wayland ugyanaz mint az X, illetve hat elfogadtad hajbi faszsagat hogy a villamos osszehasonlithato a krokodillal, mert hoszzabb, mint zold :D
Utana megallapitod (ez lenne a mondanivalod???), hogy nem lett jobb ugy an-block mint az X, pedig de szamos dolgoban jobbak a wayland protokollra epulo implementaciok. Eleg ha egy DE-ben osszahasonlitod ha X11-el vagy Wayland-al (ami nem a wayland, hanem annak egy DE specifikus implementacioja) inditod. Tehat amit mondtal az maximum egy hajbi faszsag visszabofogese. Persze gyakran elofordul, hogy ha valaki szerelmes akkor a velemenyet is megvaltoztatja a csodalata targyanak megfeleloen :D
Eljutottam a vegere az "onallo" velemenyednek :D (nevezhetjuk mondandonak persze)
De még így is elbasztad, mert a Fedora a Red Hat gondozásában álló projekt. 🤡
Szerintem nem basztam el, a Red Hat támogatja, de egy független, közösségi szervezet készíti. Ha viszont szerinted nem fér bele, akkor csak nézd a többit.
Az átlalad felsoroltak átveszik, mert nincs annyi fejlesztői kapacitásuk, hogy elforkolja a GNOME-ot, meg a fél Linux desktopot.
Miért kéne elforkolni "a GNOME-ot, meg a fél Linux desktopot"? Futnak X-en, tudnák használni továbbra is az X-et alapértelmezetten. Segítek: az, hogy ezeken alapértelmezett a Wayland, az nem azt jelenti, hogy nem használható az X!
Egyébként még mindig nem értelek. Ez egy kisebb, kevésbé bloat, kevesebb erőforrást igénylő, biztonságosabb rendszer. Az összes hátránya, amit rá lehet mondani az, hogy újabb. Azt hittem a bloat ellen vagy, nem az újdonságok ellen.
Szerintem nem basztam el, a Red Hat támogatja, de egy független, közösségi szervezet készíti.
A CentOS is ilyen volt, amíg a Red Hat úgy nem döntött, hogy kiáll mögüle. Aztán meg a forkokat is megpróbálták ellehetetleníteni. Sőt, elkezdtek influenszerkedni, hogy ingyenélőnek (freeloader) állítsák be azokat, akik a forkokkal foglalkoznak. Talán elfelejtetted?
Futnak X-en, tudnák használni továbbra is az X-et alapértelmezetten.
Egészen addig, amíg a Red Hat, a nagy™ fejlődésre™ hivatkozva ki nem patcheli belőle az X11-et. Meg úgy a fél desktop világból, ami az ő kezében összpontosul. Innentől kezdve bizony el kell forkolni a GNOME-ot, meg a fél Linux desktopot. Lásd, systemd-mentes disztrók esete.
Segítek: az, hogy ezeken alapértelmezett a Wayland, az nem azt jelenti, hogy nem használható az X!
Idő kérdése és ezt jelenti, ha a Red Hat-on múlik. Lásd, systemd, pulseaudio, gtk3-4, pipewire stb.
Ez egy kisebb, kevésbé bloat, kevesebb erőforrást igénylő, biztonságosabb rendszer.
Fejlesztői erőforrást is kevesebbet igényel, hogy fusson rajta valami ugyanúgy, ahogy X11-en? Lófaszt. Többet igényel.
Az összes hátránya, amit rá lehet mondani az, hogy újabb.
Az újabbat árnyalja az, hogy már 15 éves és 15 év alatt nem volt képes felülmúlni az X11-et. Emellett számos hátránya van. Mindenki a biztonsággal™, a HiDPI-vel, meg egyéb senkinek se kellő, megfoghatatlan buzzwordökkel nyomul a kommentszekciókban, miközben alapdolgok nem működnek normálisan Wayland-on. Szarul-húgyul implementált libinput (pl. csapnivaló, lebutított, természetellenesen mozgó touchpad driver, ami alig kompatíbilis valamivel), instabil, kiforratlan, bétaverziós GFX driverek, global hotkey-ek ellehetetlenítése, instabil szar semmivel sem kompatíbilis xwayland.
Nem beszélve a Red Hat developerek arroganciájáról, akik Pötteringtől tanultak, és a Microsoft-ot is felülmúlják. Nem, a Linux desktop világ nem való multikézbe.
This post could summerized to "I cannot run software designed to work on X on Wayland".
A cikkben szereplő dolgok egy része még igaz is lehetett, de az a cikk 4 éves! Ám már akkor is a nagy része nem állta meg a helyét: We Don't Need to Boycott Wayland
Mindenki a biztonsággal™, a HiDPI-vel, meg egyéb senkinek se kellő, megfoghatatlan buzzwordökkel nyomul a kommentszekciókban, miközben alapdolgok nem működnek normálisan Wayland-on.
Igen, a biztonság például fontos. Nekem pl. ne keyloggoljon semmiféle app, ha én nem akarom, ez pedig X11-gyel sajnos nem kivitelezhető.
A HiDPI is fontos 2024-ben, bocsánat. Lehet, hogy te még 800x600-as felbontást használsz, de én nem.
Szarul-húgyul implementált libinput (pl. csapnivaló, lebutított, természetellenesen mozgó touchpad driver, ami alig kompatíbilis valamivel), instabil, kiforratlan, bétaverziós GFX driverek, global hotkey-ek ellehetetlenítése, instabil szar semmivel sem kompatíbilis xwayland.
Még mindig nem értem, hogy konkrétan milyen alapdolgokra gondolsz, amik nem mennek.
A GFX driver az meg kernelben van, pont, hogy userspace-ben csak valami generic dolgok vannak, like mesa, opengl, vulkan, pont, hogy az X11 az, aminek még van egy rakás userspace drivere.
Napi tizenórát használom, sosem volt bajom a touchpaddel, ha megnyomom a stop-ot a zene megáll. Miről beszélünk?
Nem beszélve a Red Hat developerek arroganciájáról, akik Pötteringtől tanultak, és a Microsoft-ot is felülmúlják. Nem, a Linux desktop világ nem való multikézbe.
Ize, ne keverjuk. A QT egy tookit a Gnome egy DE. Azt akartad mondani hogy a QT es a GTK? Vagy azt hogy a KDE es Gnome?
De amugy is a WM-ekrol (display server, compositor) kell beszelnunk ebben az esetben nem a toolkitekrol es a DE-krol, tehat KWin es Mutter(???, nem tudom nem vagyok gnome-os)
Senki sem eroltetei a waylandet. Lehetoseged van hasznalni az X11-et es a waylandet amikor akarod. Te dontod el.
Az azonban erdekes hogy vajon a fejlesztok miert inkabb a wayland protocol szerint programozzak le a dolgokat (esetleg favorizaljak) az X11 helyett, amiben mar 20+ eves tapasztalatuk van, ugy hogy a tobbseguk nem kap penzt azert hogy ezt tegye.
Ugyanez a kerdes merulhetett fel azokban a fejlesztokben, akik az assembley helyett aztan a C-t valasztottak 40+ evvel ezelott.
Vagy hajbinak van igaza, es a RedHat minden DE es WM fejlesztohoz kikuld egy fekete autot ket tagbaszakadt redhat-ossal balonkabatban, hogy hatracsavarjak az egyik kezet, a masikkal meg wayland-ot kell imlementalnia :D
Igen, de nem biztos hogy pont a KDE fejleszteseert kapja a penzt, lehet tok mast csinal, de engedik neki hogy ezzel is foglalkozzon. Ahogy engem is engednek a szabadidomben oktatasi anayagokat kesziteni, vagy projekteteket inditani amibol aztan kinohet valami :D
Személy szerint jó ötletnek tartom, talán az rpi mögött húzódó hype hullám ad egy kis löketet a wayland fejlődésnek.
Más kérdés hogy szerintem a desktop linux halott dolog, már úgy vagyok vele hogy bottal se piszkálnám a desktop témát, ráadásul rpi-n desktopozni meg egy vicc kategória. De ez persze az én saját véleményem majd a linugz pisták jól megmondják :D
Desktop linux: Szerintem a desktop linuxra mindig is azt mondták, hogy halott, és az igazság az, hogy mára már tökéletesen működik, főleg a hétköznapi user számára. - illetve olyan helyen lehet max probléma, ahol valami licensz kérdés van, mint pl az nvidia driver. De ott sem technikai a probléma gyökere.
Hozzászólások
Na ezt jó tudni, kipróbálom.
...vagy ahogy itt olvasom másokat, inkább mégsem :)
Én próbáltam kb 1 hete Pi4-en. A hardveresen gyorsított videolejátszás nem működött vele, visszaváltottam x11-re, újra működött. Nem álltam neki komolyabban nyomozni, hogy mit kéne máshogy csinálni.
Régóta vágyok én, az androidok mezonkincsére már!
A régin meg a hardveresen gyorsított kijelzőre rajzolás nem ment :D
Dekódolta a videót, de pixelenként rajzolgatta ki procierőből. Ha waylanddel megy, akkor végre tényleg lehet majd átlagos használatnál is egy gyenge pécé szintjét hozni vele. Persze minimum 8GB ram akkor is kell.
Waylanddal elvileg jobban kéne menjen, kisebb procierővel a weblapok megjelenítése is.
Ja mondjuk pi5ön meg eleve nincs h265-ön kívül más video codec hw dekódolás, szóval ehh. Ha pi4en emiatt nem csinálják meg, akkor szopacs neked.
A tapasztalatom, hogy valójában még a Pi4 CPU is bőven elég erős 1080p60-ban akár még AV1-et is dekódoljon, legalábbis tipikus youtube-os bitrátán. mplayer -vo null -lavdoptions threads=4 (lehet, hogy a pontos commandline-ra rosszul emlékszem) simán bírja, ki se maxolja a 4 magot. Amint valami ténylegesen megjelenítő video output ki van jelölve, máris kevés lesz a CPU.
Sajnos a wayland sem volt jobb ebből a szempontból.
Régóta vágyok én, az androidok mezonkincsére már!
Minek kell erőltetni az ilyet, ha nem tudja hozni azt a szintet, amit az elődje?!
Minden uj technologia az elodje alol indul, de ott az igeret, hogy fole fog kerekedni. A legtobb gond egyebkent abbol adodik, hogy megprobalnak eszetlenul minden regi featuret ujrairni, mert "hozni kell a regi funkcionalitast".
Mondjuk, aki raer RPi-vel jatszani, az erjen ra az ilyenekre is :)
Nade a wayland miatt pont azért megy a nyígás, mert nem csinálnak neg minden szart az Xből, amit meg igen, az nem jó, mert nem kompatibilis...
Ami ígéretet csak akkor van esélye a készítőknek betartani, ha nem erőltetik defaultnak, mielőtt betartják.
A Wayland 15 év alatt képtelen volt olyan szintre fejlődni, hogy mindenben helyettesítse az X11-et és mindenben kompatíbilis vele. Máskülönben már mindenki átállt volna rá. Mivel nagy beégés lenne multiéknak (Red Hat = IBM) ezt beismerni, így elkezdték erőltetni, az X ellen FUD kampányt indítottak valamennyi influenszerükkel, az általuk uralt (sajnos túl sok) desktop környezet és alkalmazást elkezdték visszafordíthatatlanul átírni, dependáltatni rá.
Mivel korporatokrata erővel van lenyomva a Linux-világ torkán, így valószínűleg a büdös életben nem fog az X fölé kerekedni. Ha képesek lettek volna erre, már a fejlesztés első 1-2 évében megtörtént volna a felülkerekedés.
A Raspberry PI lehetne egy tök jó vékonykliens, megfelelő szoftverekkel, de nincsenek rá megfelelő szoftverek, mert a desktop alkalmazásokat 13. generációs, 8 magos, 64 GB RAM-os, 1 TB SSD-s babzsákfejlesztők írják.
Kicsit +1, de azért a fejlesztőknek csak vannak nagyobb ssd-jeik is... Egyébként notin és asztali gépen átálva is jelentősen gördülékenyebb a wayland, mint az X volt. Valószínűleg pont nem használok olyan feature-t, ami ne menne.
Nem akarja mindenben helyettesíteni, vannak dolgok, amikre sokkal jobbak a különálló alkalmazások. Főleg nem akar kompatibilis lenni vele.
Nem csak lehetne, hanem az is. A bloat desktop alkalmazások, akadás mentesen, gyönyörűen futnak rajta. Ráadásul ez egy bloat Ubuntu, lehet találni erőforrás barátabb disztrót is. ;-)
Számomra már bőven tudja hozni azt, amit az elődje.
Több, mint egy fél éve áttértem rá, ez az elsődleges desktop rendszerem.
Hirtelen nem is tudok olyan programot mondani, amit használok és kellene hozzá az xwayland. Na jó, egyedül a Gimp, de annak a következő stabil verziója is már tudni fogja a wayland-et natívan.
Ilyenek mennek pl.: Brave, Gnome alkalmazások (pl. Nautilus, Calculator, Fonts), KeypassXC, OBS Studio, Teams, LibreOffice, Terminal (pl. Foot, Alacritty, Kitty, WezTerm), Megasync, Remmina (RDP kliens), Login manager (pl. SDDM, greetd, GDM, KDM), Calibre, Ebook reader, Ebook writer, VLC
Kurvajó, egy estét szoptam vele, mire rájöttem, hogyan kell az érintőkijelzőt kalibrálni: egy udev szabályban kell egy 3x3-as mátrix 6 elemét átadni.
X11: kalibráló progi kiköpi a kalibrációs fájlt és cső.
Csak a szokásos szigorúan szakmai™ és jól™ megalapozott™ indokok az X11 ellen.
Meg compositor és touchscreen, mint a világ legszükségesebb™ dolgai Raspberry PI-re.
Nálunk az üzemben rpi5 + 32" touchscreen-ek vannak a termelésben.
Ezért aztán erőltessük rá a másik 100-ból 99-re is a waylandot. :)
Engem nem zavar a fejlődés. Nem gondolom róla, hogy mind felesleges. Abban egyetértek, hogy lesznek zsákutcák és elhaló technológiák.
A wayland minden, csak nem fejlődés.
Az a touchpad támogatás egy X11 input driver is lehetett volna és pont ugyanúgy elláthatná a feladatát.
Akkor hülyék a programozók akik azzal szopatják magukat, hogy újraírnak egy meglévő funkciót? Használsz több monitort?
chatgpt:
Wayland fejlesztését az X11 protokoll bizonyos korlátai és elavultsága indokolta. Az X11 az 1980-as években készült, és azóta számos funkciót és biztonsági javítást kapott, de alapvető felépítése miatt egyre nehezebb volt modern elvárásokhoz igazítani. Wayland célja, hogy letisztultabb és hatékonyabb architektúrát biztosítson, ami jobban illeszkedik a mai hardver- és szoftverkörnyezethez.
Íme a főbb különbségek és előnyök:
Letisztultabb architektúra: Wayland egyszerűbb, és közvetlenebb kapcsolatot biztosít a kliens programok és a megjelenítő között. Az X11 számos funkciót bonyolultabban old meg, míg Wayland minimalizálja a külön rétegeket, ami gyorsabb és kevesebb hibalehetőséggel járó megoldást eredményez.
Jobb teljesítmény és reszponzivitás: Wayland úgy tervezték, hogy elkerülje az X11 esetében megszokott körülményes ablakfrissítést és más, az X Serverhez kapcsolódó késleltetéseket. Így gördülékenyebb animációk és alacsonyabb késleltetés érhető el a felhasználói felület megjelenítésekor.
Biztonságosabb dizájn: Az X11-ben a kliensprogramok több olyan jogosultsághoz is hozzáférhetnek, amelyek biztonsági kockázatot jelentenek (pl. egymás képernyőtartalmához). A Wayland szigorúbban szabályozza a hozzáféréseket, ezért nehezebb kompromittálni.
Több monitor és frissítési frekvencia támogatása: Wayland jobban kezeli a több monitoros környezetet, és támogatja az eltérő frissítési frekvenciákat is, ami az X11-ben nehezebb volt. Ez különösen előnyös a modern nagy felbontású és magas frissítési sebességű kijelzőknél.
Energihatékonyság: Az egyszerűbb kommunikáció miatt Wayland kisebb energiafelhasználást eredményezhet, különösen laptopokon és mobileszközökön.
Mindezek ellenére nem minden program kompatibilis még teljesen Waylanddal, és bizonyos esetekben továbbra is az X11-emulációra (XWayland) van szükség. A Wayland hosszú távú előnyei azonban egyértelműek, ezért folyamatosan növekszik a támogatása a különféle Linux disztribúciókban.
Gyönyörűszépen felmondtattad a Red Hat által összeinfluenszerkedett marketing bullshit-et a ChatGPT-vel.
Ahol pedig van kompozitor, ott lesz input lag. Nem az 1980-as évek miatt, hanem a mindenféle OpenGL-es mágiák, copyzások, és a teljes képernyőre erőltetett vsync miat,t ami ablakozásnál totálisan felesleges és amit X11-en az Intel TearFree drivere amúgy lag nélkül hoz.
Köszönjük szépen a global hotkey-ek ellehetetlenítését. Bizonyára sok haladó felhasználónak erre™ volt™ szüksége™.
Amik totálisan feleslegesek egy fejlesztői gépen, elvégre 60 Hz-et mindegyik tudja alapból és egy átlagos fejlesztési workflow úgy 10-15 FPS képtartalom-változást jelent. Persze, tudjuk, a sokmillió™ kreatív ember, aki csak és kizárólag Linux-on vág videót, a még™ több™ gamer, aki Linuxon játszik és 400 FPS-t akar, meg még sorolhatnám a kizárólag a Red Hat álomvilágában létező entitásokat, akikre hivatkozva tönkre kell tenni sok tízmillió létező entitás munkáját.
Erre kíváncsi leszek. Főleg a szarul-húgyul implementált bétaállapotú wayland-driverekkel.
A Wayland hosszú távú előnyei ezzel a 15 év munkával és Isten tudja hány csilliárd fejlesztői munkaórával mind megvalósíthatóak lettek volna X11-ben. Ja csak az nem lett volna újrafeltalált kerék, meg nem adott volna akkora hegemóniát a Red Hat kezébe, mint a Wayland, ami jelen állás szerint csak azzal fog teljesértékűen működni, amit a Red Hat tálcán ad mellé (GNOME). Semmi mással.
Nem csak desktop linux van.
Ja igen, tényleg, most jönnek az X11 alatt használhatatlan™ Kiosk terminálok, amik miatt az X11-gyel Wayland-nál használhatóbb PC-sek Linux-világát muszáj felforgatni. 🤡 Ugye véletlenül sem azt kell megoldani, hogy a nem-PC eszköz jól működjön X11-gyel, ha az a cél, hogy grafikus környezet legyen rajta.
igen, pl kiosk, meg: játék? mobil?
Melyik Linuxos mobil terjedt el, amin PC-s desktop környezet fut? Semelyik. Androidot ne keverd ide, annak semmi közze se az X11-hez, se a Wayland-hoz.
A többség játékra használja a Linuxot? Nem. Elenyésző kisebbség.
Tehát, továbbra sem világos, hogy mi indokolja a többség Linux-os PC-inek felforgatását, Red Hat tömlőcbe zárását, a felhasználói szabadság lábbal tiprását.
hint: steam deck. linuxos is, mobil is, desktop is, jatek is.
"As Valve designers Lawrence Yang and Pierre-Loup Griffais told The Verge, sales of Steam Deck have already reached “multiple millions.”"
mindezt 1 ev alatt (azota meg eltelt meg1). :) szoval igeny, fizetokepes kereslet, az van ra!
es itt az implementacio, ha erdekel egyaltalan es nemcsak a sajat mantrad megy a fejedben :)
"dorsyka" a "te ervelesi hibad" hogy tenyekkel dobalozol, faszsagok helyett amik csak a fejedben leteznek es kozben meg nem is dobalod a hajtuidet...szar a musor :D
a korlátozott ismereteim alapján, szerintem az egyik legnagyobb gond az X11-gyel, hogy minden gpu-hoz meg kell írni x11 modult. Na ez nem történik meg, ezért olyan vacak például az arm-os grafikai képesség és teljesítmény, mert gpu specifikus megvalósítás helyett univerzális framebuffer kezelőt kell használni, amiben a cpu számol és csinál szinte mindent, a gpu csak buta 2d megjelenítő. Mintha s3triót tennél egy mai pécébe és windows alatt csak a generic képernyő drivert lehetne használni, ami nem nagy élmény.
Nagyrészt azért is, mert opensource drivereket a gpu gyártók nem nagyon adnak ki, mert ipari titkokat kéne felfedniük. Így korlátozott képességűek a nyílt megoldások. Plusz rengeteg munka minden gpu-hoz ablakkezelőt írni. Helyett értelmesebb az, hogy képes legyen a gyártó zárt 3d driverét használva futnia egy ablakkezelőnek. Hogy ne az ablakkezelőből legyen gpu specifikus változat, hanem szabványos apin a gyártói gpu driveren át tudja ellátni azokat a funkciókat.
Tehát akkor azért, mert egy tök másik architektúrán babzsákfejlesztőék lusták voltak normális drivert összehozni, szívassuk meg azokat, akiknek 10+ éve kifogástalanul megy mondjuk az Intel driver a PC-jükön.
Azért nem adnak ki, mert akkor támogatni is kéne, azt meg nem akarják. Az üzleti titkos érvelés nevetséges.
Miért kéne mindegyikhez új ablakkezelőt írni? Ezt melyik wayland bullshit oldalon olvastad? X11-hez kell ablakkezelőt írni, a protokoll szerint.
Ezzel annyit mondál, hogy Windows-osítsuk el a Linuxot, és majd a multik (Red Hat, NVidia, AMD stb.) megmondják nekünk, hogy használhatják a gépünket. De minek, ha már van egy Windows, ahol ez adott?
Ha majd nem lenne titok, egy ilyen üzemi felhasználású málna körítéséről (táp, burkolat, kijelző) szívesen olvasnék egy blogbejegyzést.
Saját fejlesztésű webes ERP fut benne, aminek van MRP része is. :) Ez annyit jelent, hogy a termelés, csomagolás, komisszió ami a felületen direktben történik munkavállalók által. Emellett több folyamatot implikál ezen tranzakciók. pl.: lecsomagol 10 db valamit, akkor az +10 db bevétel az adott termékből, és -10 db n számú csomagolóanyag (flakon, címke, kupak, etc ...) emiatt ahogyan a termelés átvisz egy raklapnyi terméket a raktárba kvázi realtime látjuk az adatokat és látják valós időben a webes vásárlók is. Amit nem látnak a vevők (csak többen tudják), hogy bármilyen hiány esetén 24 órán belül legyártjuk azt, mert sok gépünk van és a termelést is tudjuk megkezdésig/foglaltságig átütemezni mindkét dimenzióban (hol /n számú keverő/, mikor).
Ilyet használok:
https://aqua.hu/monitorok/32-iiyama-prolite-tf3237msc-b3ag-erintokepern…
A monitor HDMI + USB AM-BM kábellel csatlakozik az RPi5-höz, amiben Firefox fut.
Az RPI elfér a monitor hátán, sima TV fali állvánnyal van rögzítve a falhoz. Mivel nincsenek gőzök vagy por, így nincs plusz védelem. Ha ilyen helyre tenném, akkor nem használnék érintőképernyőt, hanem beraknám egy fém szekrénybe aminek az elejét kivágnám és raknék bele üveget, fóliázva. Majd az input eszközöket kivezetném és gyakran cserélném.
A PI - viszonylag - szűk erőforrásokkal bír, erőforrással a wayland jobban gazdálkodik. Ez nem az X11 ellen szól, hanem a RPI jellemzőiről, hogy ezen a platformon a wayland-nek van keresnivalója, nem öncél a használata.
X11, úgyérted Xorg? A wayland jobban gazdálkodik az erőforrásokkal? Annó az xfree86 működött a 386-osomon, egy tseng et4000-essel, és 8MB rammal.
Mondjuk onnantól kezdve, hogy még ezer és egy alkalmazáshoz kell az xwayland, addig nálam felejtős, mert persze szép, hogy a wayland kevesebbet tud és így elméletben gyorsabb, de mit kezdjek vele az xterminálommal?:)
Akkor már dobhatnánk az egész kliens-szerver modellt és a userspace-t, bedobhatnánk a kernelbe a grafikát, ablakkzelővel együtt, ahogy azt MS-ék kezdték... csak arra utalok, hogy nem minden a teljesítmény... még ha igaz is lenne.
Egyre fogy azok száma, amihez kell, a legtöbbnek már van waylandes változata.
Használj waylandes terminált, általában még jobbak is (wezterm, kitty, alacritty, foot, ...) ;-)
Szerintem félreértjük egymást, amiket felsorolsz terminál emulátorok, nekem meg envizex-em van, az hardveres xterminál. Még saját ablakkezelőt is tud futtatni, ha szeretném pl. CDE-vel dekorálni a mai alkalmazásokat,de szerintem waylandet azt nem tud :D
386-oson nincs a mai értelemben vett GPU. Manapság prociból renderelni bármit teljesen idejétmúlt. És jóval több energiát használ.
A klasszikus PC platformokon viszont nincs keresnivalója, multiék mégis erőltetik, torkokon akarják lenyomni.
Ja, a nagy multik, mint a
disztribuciókat készítők. ;-)
https://a.te.ervelesi.hibad.hu/mazsolazgatas
De még így is elbasztad, mert a Fedora a Red Hat gondozásában álló projekt. 🤡
A nagy multik: Red Hat = IBM, Canonical, SuSE
Ezek közül, aki erőlteti: Red Hat
Az átlalad felsoroltak átveszik, mert nincs annyi fejlesztői kapacitásuk, hogy elforkolja a GNOME-ot, meg a fél Linux desktopot. Az alulról építkező, nem multis hátszéllel dolgozó készítők és közösségek közül egyedül a Debiannak lett volna, és meg is tudták volna állítani a Red Hat ámokfutását még a systemd-s viták idejében, de valószínűleg túl sok Red Hat influenszer épült be a köreikbe.
Vagy csak a többség egyetért ezzel? Hm? Ez fel sem merült?
Ne legyél már meglepődve. Van kialakult véleménye, és az természetesen "sokkal közelebb van az igazsághoz" mint bárki másé. Aki ennek ellentmond az hülye. Ennyi. Én már csak vigyorgok mint a tejbetök mikor meglátom, hogy valamihez hozzászól.
A tiédet még nem láttuk! Lehet az még közelebb van az igazsághoz? Nem csak vigyorogsz, hanem megint kötözködni jöttél és hogy elmondhasd, hogy Hajbazer mennyire hülye.
De ha most ettől eltekintünk. Mivel lett jobb a Wayland, mintha az X-et kalapálták volna ki? Ami egy sok évtizede működő, sokak által látott és javított kódbázis. Nem. Inkább írjuk újra, mert attól jobb lesz? Mikor? Mert még nem annyira látni, hogy jobb lenne.
"Mivel lett jobb a Wayland, mintha az X-et kalapálták volna ki?"
Az X11-et úgy 30-40 éve "kalapálják ki". Gyakorlatilag extension hátán extension. Egy borzasztó agyonbonyolított tákolmány lett belőle. Az extension-ök fele kb azzal foglalkozik, hogy kerülőutakat biztosítson a normál socket-alapú (lokálisan futó grafikához elég nagy overheadet okozó) X11 protokol helyett. Ráadásul a kliensnek mindenre IS fel kell készülnie, bármelyik extension hiányozhat (vagy éppen azért nem elérhető, mert remote session van), mindenre kell fallback.
Nyilván a widget frameworkök evolúciósan vele együtt fejlődtek, ezért hozzá vannak kupálva. De a kódbázison belül ezek a fallbackek is már archeológiai rétegeket képeznek.
Szóval a waylandnek volna létjogosultsága. Hogy mi ment félre, amiért 15 év alatt nem tudott 1-ről 2-re jutni az egy másik (amúgy önmagában érdekes) kérdés.
Régóta vágyok én, az androidok mezonkincsére már!
Van létjogosultsága bárminek, ami minden szempontból jobb az X11-nél. A Wayland nem ilyen, tehát nincs neki. Ezért fogják erővel lenyomni a Linux-világ torkán. Már rég adoptálta volna minden disztró, ha minden szempontból jobb lenne.
"Szóval a waylandnek volna létjogosultsága. Hogy mi ment félre, amiért 15 év alatt nem tudott 1-ről 2-re jutni az egy másik (amúgy önmagában érdekes) kérdés."
Mondjuk az eleg szorakoztato, hogy Ubuntu 22.04 default lett, aztan olyan teljesen marginalis feature-k nem mukodtek, mint screen sharing....
Az én szubjektív meglátásom az, hogy nagyon-nagyon el akarták kerülni, hogy Waylanddel ugyanaz történjen, mint az X11-el - vagyis idővel szét kelljen patchelni mindenféle extensionökkel, amivel az alapfunkcionalitást lényegében teljesen átalakítják/megkerülik. Ezért a Wayland API-t szándékosan nagyon minimálisra tervezték és kb mindent kiszerveztek a compositorba. Ezzel architekturálisan nem lenne baj.
A baj azzal van, hogy egy "szabvány" compositor API nem lett specifikálva (ami nincs specifikálva az nem avul el, ugye...), és most van vagy 15-féle compositor Wayland-re, egymással inkompatibilis programozási felülettel. A nagyon egyszerű alkalmazásoknak ez nyilván mindegy, azoknak elég, hogy wayland kliensek, a compositor meg a fejük felett teszi a dolgát. De ha kicsit is bonyolultabb dolgot akar valamelyik alkalmazás (fullscreen, window dekorációk eljrejtése / saját window dekoráció, screenshot / screen capture), akkor máris a compositor-specifikus API-khoz kell fordulni.
Vagyis az egyik probléma helyett csináltak egy másikat. Most már az alkalmazások nagy részét nem wayland-re, hanem az egyes wayland compositorokra kell portolni. Szerintem itt csesződött el az egész.
Régóta vágyok én, az androidok mezonkincsére már!
Lényegében csináltak egy szétgányolt X11 architektúrát, amit ugyanúgy kell körbehákolni a compositorokkal, mint kellett az X11-et az extensionökkel. Csakhogy utóbbi valahogy működik, stabilan, kiszámíthatóan, évtizedek óta és nem kell a fél desktop világot újraírni hozzá.
Szerintem te kevered az eszközt a céllal. Az újraírás egy eszköz arra, hogy a felette lévő milliónyi alkalmazás elkészítése és futtathatósága a jövőben egyszerűbb legyen, ami maga a cél.
A Wayland az egy protocol, amit a compositor (és a kliens) implementál. Nincs compositor specifikus API, csak Wayland API van.
Mivel könnyű implementálni a Wayland protocolt, emiatt van sok compositor, de a kliensek ugyanúgy fordulnak a compositorhoz, mindegy melyik az.
Őszinte leszek, amikor utánaástam a válasznak, kissé meglepett, amit találtam. Azt hittem, hogy ennél több közös lesz a megoldásokban, de ez heterogénebb, mint gondoltam.
Mondjuk, hogy API-nak a wayland specfikált objektumait és műveleteit tekintjük.
Nézzük a screenshot készítést, mint sokat emlegetett problémát:
A wlroots alapú compositorokban van a vlr-screecopy-unstable-v1 protocol. Ami kb egy ... csúnyát fogok mondani ... extension a wayland protocolhoz. Van egy csomó belőle, ami nem a hivatalos "wayland protocol", de mégis compositor specifikus API-t képez: https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/tree/master/unstable?ref_type=heads De legalább ez a wayland-be koncepcionálisan illeszkedő megoldás.
A KWin-ben screenshotot egy org.kde.KWin.Screenshot2 nevű másik API-n keresztül tudsz csinálni. Ez egy "out-of-band" API, a wayland protokol teljes megkerülésével, d-bus-on megy.
A gnome-shell esetéről annyi derült ki, hogy Shift-PrintScrn, Ctrl-PrintScrn billentyűkre csinál screenshotot (tehát magán a compositoron belül dolgozza fel a keyboard event-et, és belül intézi el a screenshot készítést). API-ról nem találtam semmi használhatót (gyanítják, hogy d-bus-on keresztül ki van vezetve, de nem találtam meg pontosan milyen néven).
Hogy csinálja a Weston: van egy weston-output-capture nevezetű saját protocolja. Lényegében olyan, mint a wlroots megoldása, de azzal nem kompatibilis saját extension.
Most erre mit mondjak... :/ (nem, nem akarok hajbinak igazat adni...)
Régóta vágyok én, az androidok mezonkincsére már!
Igen, ebben igazad van, nem volt elég jól megcsinálva a screen capture rész. A wlroots kidolgozott egy elég jó megoldást, ami két hónapja be is került a hivatalos Wayland protocolba.
Sajnos egy kicsit eső után köpönyeg állapotot érzek, de talán még van esély rá, hogy a többi megoldás átáll rá.
Nézegettem mik vannak még a wlroots unstable repoban. Hát elég alap javaslatok döglenek ott 4+ éve. Pl notification kezelés az output device változásokról: https://gitlab.freedesktop.org/wlroots/wlr-protocols/-/blob/master/unstable/wlr-output-management-unstable-v1.xml?ref_type=heads - oké, ez sok idő volt, mire Xorg-ban és a linux DE-kben végre normálisan támogatva lett, de ma már elég alap, hogy notebookra rádugom a dokkolót - 2 képernyő, lehúzom - 1 képernyő. Vagy VM-nek átméretezem az ablakát, és a guest desktop mérete automatikusan igazodik hozzá. Power management dettó ugyanez. Input inhibitor - lock screenhez elég elengedhetetlennek tűnik. Gondolom a népszerűbb compositorok (muszájból) ezekre is megcsinálták a maguk kis kerülő-megoldásaikat.
Régóta vágyok én, az androidok mezonkincsére már!
A wayland nagyon óvatos abban, hogy mit fogad el stable protokollnak, hogy ne legyen bloat amit nehéz implementálni. Illetve gyakran merül fel a kérdés, hogy egy dolog a wayland része legyen-e vagy csak XDG által szabányosított D-Bus API. Eleve nem is lehet stable egy wayland protokoll addig, amíg 3 compositor nem implementálja azt. Teljesen normális ügymenet az, hogy a compositorok előállnak egy problémával, implementálnak egy saját megoldást, aztán elkeződik a párbeszéd, hogy kinek a megoldását vegye át a többi ami után szabványosítva lesz a protokoll. Legalábbis nekem eddig ez jött át.
Hogy kezdődik minden Wayland-influenszer monológja: Wayland is just a protocol.
Ez egyébként így nem igaz. Nem kell neki minden szempontból jobbnak lenni, elég szempontból kell jobbnak lenni, hogy jobb kompromisszum legyen. Semmi komplexet a világtörténelemben még nem sikerült úgy megjavítani, hogy minden tekintetben jobb legyen, szükségszerűen az szokott lenni, hogy az eredeti struktúrán valamit változtatni/cserélni kell, mert gátja valaminek, aztán ettől persze az eredeti sturktúra pozitívumaiból is fogsz veszteni, mert egy a való életben egy csomó minden tengelyek mentén mozog.
Mostanában csináltam egy VNC-szerű szervert X-re. Semmi mást nem vár el az X-től, minthogy egy bufferbe tudjak screenshotokat csinálni, és be tudjak injektálni egér és billentyűzet eseményeket. Ahhoz, hogy ezt megcsináljam egy rakás alig dokumentált extensiönt kellett használni és csak úgy tudtam rájönni, hogy mit kell csinálni, hogy az egyik XVNC-ből néztem ki a lényeget. Ha megnézed egy XVNC kódját, a képernyő változásainak követésére van kb 10 féle megoldás, és mindegyik extensiönön keresztül érhető el. A kódját nézegetve megállapítottam, hogy csoda, hogy ez a kupac egyáltalán működik.
Ez se rossz. Nekem a kedvenc példám egy antialiasolt bezier-görbe (vagy ha valakinek az jobban tetszik, b-spline) rajzolás X11-en. Gyakorlatilag megoldhatatlan X11-es rajzoló primitívekkel. Lehet különféle extension-ökkel (pl xrender) feltételesen kb-működő megoldásokat összerakni, még az is számít, hogy a képernyő 32 bites üzemmódban van-e, (24 vagy 16 bitesben nem működik, mert támaszkodik a framebufferben lévő alpha channelre, ami vagy megvan vagy nincs) stb. Lesz vagy 5-6-féle code path-od a különböző alesetekre. Szomorú, de végül kb a legjobb megoldás, hogy teljesen kliens oldalon fenntartasz egy canvas-t, teljesen kliens oldalon, CPU-ból megrajzolod, és PutImage()-el az egész bitmap-et átküldöd az X szervernek. Ígyis-úgyis le kell ezt implementálnod végső fallbacknek. És meglepő módon remote X sessionben még ez a leggyorsabb, mert ugyan sok adat mozog, de kevésszámú szinkron hívás miatt ez a legkevésbé latency-érzékeny.
Régóta vágyok én, az androidok mezonkincsére már!
Annó volt a Mir, és ők azt állították, hogy vannak automa tesztjeik. Ha van mindenre automata teszt, és emellé a feature-ök minimálisan vannak tartva, nincsenek különbségek, hogy mi mit implementál, akkor el lehetne érni azt az ideális állapotot, hogy ha van egy GUI program, és elindítjuk, akkor az működni fog és kész.
Állítólag (talán ebben a topikban írta valaki) a Wayland ugyanolyan lett mint az X, hogy extensionöket kell használni: ez teljesen aláássa a stabilitás esélyét, és az egésznek az értelmét SZVSZ.
na megjott hajbi felszopofiuja azonnal ugrik megvedeni :D
Hajbi megint ossze-vissza ir baromsagokat, de azert te csak csodald ot ragyogo manga szemekkel. Remelem azert fizet a szopasert, mert ezt igy ingyen ezer' bevallalni eleg kemeny :D
Van esetleg valami értelmes mondanivalód is? Nekem volt. De úgy látom megint csak az első sorig jutottál.
"megint kötözködni jöttél és hogy elmondhasd, hogy Hajbazer mennyire hülye." - ebbol probaltam nem azt kihamozni hogy azonnal ugrottal a kiscicadat megvedeni, de nem talaltam benne semmi mast :D
Utana jott egy kerdes, ami nem mondando: "Mivel lett jobb a Wayland, mintha az X-et kalapálták volna ki?" - ami azt mutatja hogy meg nem neztel bele az X libjeibe milyen konnyen gyorsan es faszan lehet programozni benne. Segitek: nem ( de ezt le is irtak utana jo hosszan paran) valamint hibasan feltetelezed, hogy a wayland ugyanaz mint az X, illetve hat elfogadtad hajbi faszsagat hogy a villamos osszehasonlithato a krokodillal, mert hoszzabb, mint zold :D
Utana megallapitod (ez lenne a mondanivalod???), hogy nem lett jobb ugy an-block mint az X, pedig de szamos dolgoban jobbak a wayland protokollra epulo implementaciok. Eleg ha egy DE-ben osszahasonlitod ha X11-el vagy Wayland-al (ami nem a wayland, hanem annak egy DE specifikus implementacioja) inditod. Tehat amit mondtal az maximum egy hajbi faszsag visszabofogese. Persze gyakran elofordul, hogy ha valaki szerelmes akkor a velemenyet is megvaltoztatja a csodalata targyanak megfeleloen :D
Eljutottam a vegere az "onallo" velemenyednek :D (nevezhetjuk mondandonak persze)
Nem gondolom, hogy te eldöntheted én miről írok. De, egy olyan szálat kommenteltem ami nem a technológiáról szól sem pedig az aktuális topicról. JFYI.
Nem gondolom, hogy te azt gondolod, hogy én eldönthetem te miről írsz. JFYI.
Hát ez mondjuk egy szánalmas bejegyzés :) ( a miértet megtalálod 5 éves gyerekek kommunikációjában )
Szerintem nem basztam el, a Red Hat támogatja, de egy független, közösségi szervezet készíti. Ha viszont szerinted nem fér bele, akkor csak nézd a többit.
Miért kéne elforkolni "a GNOME-ot, meg a fél Linux desktopot"? Futnak X-en, tudnák használni továbbra is az X-et alapértelmezetten. Segítek: az, hogy ezeken alapértelmezett a Wayland, az nem azt jelenti, hogy nem használható az X!
Egyébként még mindig nem értelek. Ez egy kisebb, kevésbé bloat, kevesebb erőforrást igénylő, biztonságosabb rendszer. Az összes hátránya, amit rá lehet mondani az, hogy újabb. Azt hittem a bloat ellen vagy, nem az újdonságok ellen.
A CentOS is ilyen volt, amíg a Red Hat úgy nem döntött, hogy kiáll mögüle. Aztán meg a forkokat is megpróbálták ellehetetleníteni. Sőt, elkezdtek influenszerkedni, hogy ingyenélőnek (freeloader) állítsák be azokat, akik a forkokkal foglalkoznak. Talán elfelejtetted?
Egészen addig, amíg a Red Hat, a nagy™ fejlődésre™ hivatkozva ki nem patcheli belőle az X11-et. Meg úgy a fél desktop világból, ami az ő kezében összpontosul. Innentől kezdve bizony el kell forkolni a GNOME-ot, meg a fél Linux desktopot. Lásd, systemd-mentes disztrók esete.
Idő kérdése és ezt jelenti, ha a Red Hat-on múlik. Lásd, systemd, pulseaudio, gtk3-4, pipewire stb.
Fejlesztői erőforrást is kevesebbet igényel, hogy fusson rajta valami ugyanúgy, ahogy X11-en? Lófaszt. Többet igényel.
Az újabbat árnyalja az, hogy már 15 éves és 15 év alatt nem volt képes felülmúlni az X11-et. Emellett számos hátránya van. Mindenki a biztonsággal™, a HiDPI-vel, meg egyéb senkinek se kellő, megfoghatatlan buzzwordökkel nyomul a kommentszekciókban, miközben alapdolgok nem működnek normálisan Wayland-on. Szarul-húgyul implementált libinput (pl. csapnivaló, lebutított, természetellenesen mozgó touchpad driver, ami alig kompatíbilis valamivel), instabil, kiforratlan, bétaverziós GFX driverek, global hotkey-ek ellehetetlenítése, instabil szar semmivel sem kompatíbilis xwayland.
Vedd le a szemellenződ és olvasd végig: https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
Nem beszélve a Red Hat developerek arroganciájáról, akik Pötteringtől tanultak, és a Microsoft-ot is felülmúlják. Nem, a Linux desktop világ nem való multikézbe.
Kb. bennem is ezt az érzést keltette:
A cikkben szereplő dolgok egy része még igaz is lehetett, de az a cikk 4 éves! Ám már akkor is a nagy része nem állta meg a helyét: We Don't Need to Boycott Wayland
Értem, tehát érdemi válasz helyett a cikket minősítgeted. Megoldott minden a felsorolásból, vagy csak betriggerelődött az elavultság™-detektorod?
Próbáld végig olvasni, amit írok! ;-)
Ott a válasz cikk, már 4 éve meg volt oldva minden azok közül.
Igen, a biztonság például fontos. Nekem pl. ne keyloggoljon semmiféle app, ha én nem akarom, ez pedig X11-gyel sajnos nem kivitelezhető.
A HiDPI is fontos 2024-ben, bocsánat. Lehet, hogy te még 800x600-as felbontást használsz, de én nem.
Még mindig nem értem, hogy konkrétan milyen alapdolgokra gondolsz, amik nem mennek.
A GFX driver az meg kernelben van, pont, hogy userspace-ben csak valami generic dolgok vannak, like mesa, opengl, vulkan, pont, hogy az X11 az, aminek még van egy rakás userspace drivere.
Napi tizenórát használom, sosem volt bajom a touchpaddel, ha megnyomom a stop-ot a zene megáll. Miről beszélünk?
nekem meg ez a nyáltépés tűnik arrogánsnak.
ejj ejj, most beleszaladtal abba, hogy hajbi veled verette ki maganak :D
Ot nem erdeklik holmi tenyek es a valoasg, csak az hogy magat simogassa :D
vannak itt még olyanok, nem ő az egyetlen... ;)
Az Arch, Debian, Slackware nem erőlteti a Waylandet. Erről a Rebecca-izéről még nem hallottam.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Előbb utóbb majd fogják, hiszen a Qt és Gnome a továbbiakban nem fogja támogatni az X-et. Qt és Gnome programok nélkül meg elég szűkös lesz a kínálat.
Ize, ne keverjuk. A QT egy tookit a Gnome egy DE. Azt akartad mondani hogy a QT es a GTK? Vagy azt hogy a KDE es Gnome?
De amugy is a WM-ekrol (display server, compositor) kell beszelnunk ebben az esetben nem a toolkitekrol es a DE-krol, tehat KWin es Mutter(???, nem tudom nem vagyok gnome-os)
Igazad van: Qt, GTK-ra gondoltam.
Senki sem eroltetei a waylandet. Lehetoseged van hasznalni az X11-et es a waylandet amikor akarod. Te dontod el.
Az azonban erdekes hogy vajon a fejlesztok miert inkabb a wayland protocol szerint programozzak le a dolgokat (esetleg favorizaljak) az X11 helyett, amiben mar 20+ eves tapasztalatuk van, ugy hogy a tobbseguk nem kap penzt azert hogy ezt tegye.
Ugyanez a kerdes merulhetett fel azokban a fejlesztokben, akik az assembley helyett aztan a C-t valasztottak 40+ evvel ezelott.
Vagy hajbinak van igaza, es a RedHat minden DE es WM fejlesztohoz kikuld egy fekete autot ket tagbaszakadt redhat-ossal balonkabatban, hogy hatracsavarjak az egyik kezet, a masikkal meg wayland-ot kell imlementalnia :D
"tobbseguk nem kap penzt azert hogy ezt tegye" A többségük cégeknek dolgozó fejlesztő, senki sem szeretet szolgálat.
Igen, de nem biztos hogy pont a KDE fejleszteseert kapja a penzt, lehet tok mast csinal, de engedik neki hogy ezzel is foglalkozzon. Ahogy engem is engednek a szabadidomben oktatasi anayagokat kesziteni, vagy projekteteket inditani amibol aztan kinohet valami :D
Személy szerint jó ötletnek tartom, talán az rpi mögött húzódó hype hullám ad egy kis löketet a wayland fejlődésnek.
Más kérdés hogy szerintem a desktop linux halott dolog, már úgy vagyok vele hogy bottal se piszkálnám a desktop témát, ráadásul rpi-n desktopozni meg egy vicc kategória. De ez persze az én saját véleményem majd a linugz pisták jól megmondják :D
Desktop linux: Szerintem a desktop linuxra mindig is azt mondták, hogy halott, és az igazság az, hogy mára már tökéletesen működik, főleg a hétköznapi user számára. - illetve olyan helyen lehet max probléma, ahol valami licensz kérdés van, mint pl az nvidia driver. De ott sem technikai a probléma gyökere.
ezt azért sokan megmosolyogják...
Azért amikor bedugot az X11-el a fullHD laptopot, a sima 24"-os fullHD monitorba és nincs scaling így 2024-ben az elég gáz.
Ezt a wayland amúgy megoldja?