Vlákno názorů k článku
KDE pomalu končí s X11, Plasma 6.8 bude už jen na Waylandu od tom111 - To je trochu nešťastné hlavne v dobe, keď...

Jo, tohle je dobrá poznámka.

Ještě tam je bolest vzdálený přístup (VNC/RDP - každý kompozitor si řeší po svém a jak se připojit třeba na "gdm" a přihlásit se, to nikdo neví) a "xdootol" pro hýbání myší a psaní na klávesnici bylo taky v nějakém nic moc stavu. A možná něco dalšího na co bych přišel kdybych to používal :)

Zásadní otázka, proč bych využíval RDP nebo VNC, které poskytuje víc jak strašný zážitek a sežere hromadu síťového provozu, když můžeme nahodit Sunshine a Moonlight?

Dneska 1 jádro z vCPU zvládne tu h264 úplně v pohodě a mně alespoň nebudou bolet oči z toho, že když se pokusím pohnout kurzorem, tak mě ze skákajícího se sekajícího se okna.

A to nejlepší? Moonlight a Sunshine pod X a Wayland fungují skvěle, pod Wayland spíš lépe...

@Vilda
Ten kodek nebo odezva je pro tohle použití (vzdálená pracovní plocha pro aplikace) ten nejmenší problém. A jinak kurzor se v případě VNC i RDP vykresluje lokálně. Podobně se přenáší jen ta část obrazu, co se mění. RDP je relativně velice úsporné a dá se s ním dělat i na relativně špatných spojeních.
U VNC hodně záleží na variantě, komerční RealVNC (nechodí s Waylandem) s jejich rozšířenými, proprietárními verzemi protokolu má vemi slušnou odezvu, umí přenášet audio, používat UDP.

Existují určitě řešení na sdílení jednoho sezení.. Typově: nechám si spuštěný, přihlášený počítač, který bude vzdáleně dostupný. Nebo sedím u počítače, spustím ad-hoc nějaký soft, aby se ke mě mohl připojit někdo další (přítel na telefonu). To se plus mínus už dá.

Spíš je to taková kombinace vlastností, co mi chybí. Už jsem to tu xkrát zmiňoval.. rozumná podpora nativního přihlašování (buď přenos screenu z GDM, SDDM nebo ještě líp ověření a inicializace přihlášení přes nativní dialog z klienta), sice už je takové částečné řešení v aktuálních verzích GNOME, ale je to peklo používat a není to moc spolehlivé.
Rozumné systémové ověřování uživatelů (PAM), ne ad-hoc hesla pro každého uživatele zvlášť. Možnost globálního nastavení vzdáleného přístupu správcem, ne že si to každý uživatel rozhasí (a ideálně si ještě si pod sebou uřízne větev).
Bezproblémová podpora Češtiny (jak psaní, tak synchronizace schránky) a posílání zkratek na vzdáleného hosta. atd.

Jinak je tam ještě i ten problém, o kterém mluví Jenda. Tzn. každý kompozitor si to řeší po svém.
Určitě by se našla nějaká firma, kde by si sepsali funkce existujících, používaných řešení a dotáhli komerční produkt (co bych si pro firemní nasazení za nějakých slušných podmínek milerád koupil). Akorát, jak to teď chápu, je tam v porovnání se světem X11 mnoho různých překážek (a názorů jak je systémově řešit, jestli vůbec ;) ).

PAM je dalsie klbko hadov, so svojimi vlastnymi problemami.

Ano, ja by som tiez chcel normalne riesenie pre overenie pouzivatelov. Ale nie nutne meno/heslo, co je limit PAM. Aj pri mene/hesle moze byt poziadavka na 2fa a tu uz PAM konci. Mozno ma pouzivatel smartcard alebo yubikey a ma pouzit ten. Alebo Kerberos (FreeIPA, Active Directory; takze pouzivatel netuka ziadne meno a heslo, len si klient vypyta ticket pre rdp servis a posle ten), tam uz PAM skoncil. Alebo nebodaj OIDC autentifikacia a Oauth2 token.

Takze rozumnemu rieseniu autentifikacie ano, ci toho bude PAM schopny, to je otazka.

PAM je určitě klubko hadů, ale přijde mi to v tuhle chvíli nejpřímočařejší, odkud bych měl ověřovat uživatele. Snadno se dá udělat restrikce třeba na skupiny uživatelů, co se můžou přihlásit.
Ano dokážu si představit scénáře, co zmiňujete, kdy to není ideální.
Ale v podstatě u těch volně dostupných řešení je to teď něco jako vncpasswd nebo per-user GNOME keychain.. PAM by byl super pokrok.. :)
Jinak všechny tokeny, 2FA atp. se typicky používají při vzdáleném přístupu na nějakých VPN bránách. Na spousty použití je úplně v pohodě nejdřív otevřít cestu do nějakého perimetru a pak zadat normální přihlášení s údaji třeba z AD/LDAPu. Pořád to bude výrazně lepší než, co je tam teď.

Nehadam sa, tiez ma zaskocilo, preco to po mne chce nastavit nejake heslo. Nakoniec pre vzdialene prihlasenie (nie pre zdielanie obrazovky!) je to heslo na pristupovanie ku GDM a az tam sa clovek prihlasi s realnym pouzivatelom.

Okrem toho to ma problem s handoff medzi gdm a session; Remote Desktop pre Mac to nerozchodi s default nastaveniami, treba manualne modifikovat rdp subor.

> Jinak všechny tokeny, 2FA atp. se typicky používají při vzdáleném přístupu na nějakých VPN bránách.

Tak vas urcite potesi, ze Microsoft vymysla s tym, ze bude bezat lokalny (na klientovi) Kerberos TGT, aby robil bridge medzi domenovym Kerberom a Oauth2. Tiez maju problem, ako sa prihlasit do pocitaca (a ako pripojit pocitac do domeny) cisto s Oath2 (kvoli Entra ID).

A samozrejme, na prihlasenie do pocitaca treba respektovat politiku vyzadovania 2fa, tokenov apod.

Takze na obzore je aj riesenie takychto chutoviek na Linuxe. Vsetko samozrejme kolidujuce s PAM.

ACK!

https://www.jwz.org/blog/2025/12/xscreensaver-and-pam/

SoongVilda:

> Zásadní otázka, proč bych využíval RDP nebo VNC, které poskytuje víc jak strašný zážitek a sežere hromadu síťového provozu, když můžeme nahodit Sunshine a Moonlight?

Jasně, myslel jsem to jako příklady, klidně jiný a lepší protokol. Zásadní je schopnost připojit se k existující session na lokálním počítači (případně se do ní přihlásit), když se na počítač naSSHčkuju. To v Xkách dělám tak, že si v prostředí aktuálně běžícího X serveru najdu proměnné DISPLAY a XAUTHORITY a spustím s nimi x11vnc (a po SSH si protuneluju port 5900). Když jsem se naposledy díval, jak tohoto docílit na Waylandu, bylo to komplikované až nemožné a hlavně si to každý kompozitor řešil po svém (to je asi to poučení se z bordelu v Xkách - do protokolu nedáme skoro nic a každý kompozitor/WM/DE si to musí implementovat po svém).

27. 11. 2025, 03:20 editováno autorem komentáře

Když hledám něco o Sunshine a Moonlite vypadá to, že je to pro hráče a žádný návod, který by vysvětloval použítí jako třeba NoMashine jsem nenašel.

Přesně tohle je pro mě pořád největší bolest. Až do té míry, že v určitých situacích třeba do určitých situací volím Windows, přestože bych tam z mnoha jiných důvodů chtěl nějakou linuxovou (i komerční) distribuci.

> Až do té míry, že v určitých situacích třeba do určitých situací volím Windows

Tomu nerozumím. Já stále Wayland nepoužívám (vždy Xka s Xfce) a zatím jsem nenarazil na problémy. Jaké problémy s takovým řešením vidíte vy?

Tomu nerozumím. Já stále Wayland nepoužívám (vždy Xka s Xfce) a zatím jsem nenarazil na problémy. Jaké problémy s takovým řešením vidíte vy?

S těmi Windows jsem zmiňoval jednu letošní situaci/konkrétní projekt.. kde se po letech na Windows 10 a jejich EOL, víceméně dalo přejít jak se stávajícím, tak s novým HW rovnou na Linux. Potřebné aplikace, i včetně proprietárních, došly do multiplatformní fáze nebo se používají webové rozhraní, lecos se dalo přiohnout, zjednodušilo by to řadu věcí.
Akorát ta snaha v daném kontextu prostě vykysla na vzdáleném ovládání (jak jsem psal předtím, je to trochu mix více věcí). Ano byla tam možnost pořídit třeba RealVNC Enterprise, který toho spousty víceméně řeší, ale pouze s Xorg sessiony. Nicméně do toho pak vstoupilo poměrně očekávané - RHEL, SLES i příští Ubuntu LTS.. a obě hlavní DE s Xorg sessiony fakticky končí. Takže se tam řešily různé varianty použít stávající verze s Xorg, doplinit to tím předplatným RealVNC, počkat jak se to vyvrbí s Waylandem, no nebo zůstat na Windows.

Jinak na jiných místech používám léta taky Xorg sessiony s TigerVNC, ale je to praktické jen na strojích s autologinem a nějakou sdílenou plochou (typ. ovládací počítač s nějakou jednou běžící aplikací). Většinou tam mám systemd službu pro usera, co spouští x0vncserver, a je tam někde předgenerovaný soubor s heslem.
V případě potřeby přístupu na greeter např. adminem na GDM je pak potřeba spustit další instanci a předat mu cestu na magic cookie.
Ještě předtím jsem používal i modul pro Xorg server, ale to trochu koliduje s některými display managery, co si pouští víc instancí Xorg na různých VT. Navíc tam bylo pár bugů, kdy to za určitých konstelací sundalo Xorg server. Ta systemd služba bokem pod userem je bezpečnější, navíc se dá jednoduše nastavit auto restart.
Jinak se v tomhle režimu (autologin/před­generované příst. heslo) samozřejmě dá používat i vestavěný remote desktop v GNOME i s Waylandem, akorát pak závisí na verzi a distribuci, jestli jde ještě VNC, oboje nebo jen RDP server.
Jen zrovna s tím jsem si v určitých kombinacích vyžral spoustu bugů.. btw. náhodně se přemázlo heslo v keychainu novým náhodným (což je výchozí, když se to zapne), pády při připojení (pravděpodobně kvůli race condition).

Ale abych nakonec přidal něco pozitivního.. při pročítání diskuse tu Petr Soukup zmínil NoMachine, který jsem před časem také testoval, v té době se moc s Waylandem nekamarádil. Teď jsem to zpoakoval, rychlý pokus s aktuální verzí vypadá velmi dobře.. odezva velmi dobrá, připojil se i na greeter, graf. přihlašování bez výpadku vzd. spojení.
Na doma zadarmo, pro firmy 50USD/rok/seat. Pokud nevadí tohle předplatné a deployment dalšího klienta (mimo RDP/VNC) lidem, co se připojují, tak by to mohlo být nadějné. Ale musím to ještě pořádně prozkoumat.

Mozete este pozriet RustDesk, dnes uz vraj zvlada Wayland.

Děkuju. Rustdesk znám z MacOS primárně, kde jsem s ním někde řešil alternativu k ARD.
Testoval jsem jej i na Linuxu, ale je to takové, jak to říct.. not great, not terrible.
Wayland funguje klasicky přes PipeWire (chce to autorizovat minimálně na poprvé), GDM - ani náhodou. Tím, že to kóduje do VP8/9 normálně celý screen, odezva je poměrně dost závislá na HW a není to ani moc efektivní.. i naprázdno bez jakáhokoliv změny screenu to klidně žere docela dost CPU.
Ale spíš bych to v tuhle chvíli bral jako variantu na osobní sdílení desktopu, vzdálenou pomoc (jako AnyDesk, TeamViewer.. atp). Tomu odpovídají i ty ostatní vlastnosti, co to má (hole-punching, relay server, jednorázová hesla a kódy atp.). Pro většinu mých použití je tohle úplně k ničemu, chci unattended přístup nastavený adminem. Zabezpečení toho kanálu řeším o vrstvu níž.

Vážně si zkuste ten NoMachine i jen ze zajímavosti.. capture probíhá na úrovni EGL nebo DRM pod kompozitorem, PipeWire je pak fallback, když se to nepovede. U mých testů pak násobně efektivnější (šířka pásma, latence, využití CPU).
Ještě to musím důkladně otestovat, ale zatím vcelku nadšení ;)

Ten X11 forwarding již dlouhá léta příliš nefunguje (přenáší se celá bitmapa, nefungují novější X extensions, je to extrémně pomalé a často docela rozbité). Opravdu fungoval snad jen s Motif/CDE před 30 lety.

RDP jsem příliš nemusel, nyní však myslím, že je to momentálně asi nejrozumnější moderní náhrada. Škoda jen, že žádná implementace RDP serveru na Linuxu nemá dosud podporu pro přenos samostatných oken namísto celého desktopu.

RDP je v skutocnosti framework, ktory umoznuje obom stranam sa dohodnut na mnohych veciach: na transportnej vrstve (lokalny socket, hyperv socket, tcp, udp, mTLS, TLS, NAT traversal, priame spojenie alebo cez gateway, konkretny pocitac alebo vybrany node v clusteri), na pouzitych kodekoch (od raw a rle v rozlicnych bitovych hlbkach po h264), na prenasanych ficurach (ci len obraz, alebo aj tlaciaren, redirektor na lokalny disk, smartcard citacka, apod) a ano, aj ci prenasat celu session alebo len aplikaciu.

Btw, aplikacia, ktora vie RemoteApp (prenos samostatnych okien) na linuxe existuje. Vola sa weston a je to fork, ktory distribuuje Microsoft ako sucast WSLg. Ako backend pouziva FreeRDP. Inymi slovami, FreeRDP ovlada RemoteApp tiez, len to na linuxe nic (okrem tohto forku westonu) nepouziva.