Desktop sa da krasne zdielat cez RDP, napriklad takto: https://www.server-world.info/en/note?os=CentOS_Stream_10&p=desktop&f=3
Len ak to niekto nutne potrebuje cez SSH, musi si tunelovat port 3389. No a to je vsetko.
Jako jo, ale stávající GNOME implementace je taková nedopečená, pokud nemáš fakt jen to nejjednodušší použití.
V situaci, kdy tam nebude přihlášený tvůj user (systém bude v greeteru GDM), pak musí být povolený ještě ještě druhý speciální RDP server jen pro přihlašovací obrazovku (záložka Remote login).
Ten poběží na portu 3389 a posune server na sdílení plochy na 3390 (neměnitelné).
Když se přihlásíš nejdřív přes tenhle RDP server, napíšeš svoje uživatelské údaje, a už tam bude rozjetá stávající session, tak by ji to násilně ukončilo (i se všemi spuštěnými programy).
Další radost je třeba v tom, že přihlašovací údaje od RDP serveru se ukládájí do keyringu (nebere si to ověření ze systému např. přes PAM). Takže když je tam třeba v GDM autologin (jednoúčelový počítač, pořád připravený na vzdálené připojení, abys obešel tenhle problém s přihlašováním), tak se login keyring neotevře a server jen tiše nefunguje. Tzn. login keyring musí být bez hesla.
Což neříkám, že je tohle konec světa a nikdy to nedozná vylepšení, ale zatím je to fakt docela problémové.
Ano, bolo by fajn, keby to fungovalo ako windows server a snad jedneho dna bude. Beriem to tak, ze v linuxe je vsetko jemne nefunkncne, akurat pri starom rieseni bolo treba prehliadat ine boliestky ako v novom.
A co sa tyka implementacie v gnome-remote-desktop, ono je to este horsie:
1) neda sa pripojit nicim inym, ako remmina a mstsc. Mstsc sa popri tom este postazuje, ze spojenie je nezabezpecene, remmina ako spravny partizan mlci. Remote Desktop for Mac / Windows App for Mac sa nepripoji vobec (lebo nezabezpeceny transport). Remote Desktop z MS App Store sa tiez nepripoji.
2) Napriek tomu z nejakeho dovodu saha na TPM. Ako vlastnik dosky AMD s fTPM mam s tym dost problem, pretoze kvoli istemu popularnemu quirku ("tpm_crb MSFT0101:00: [Firmware Bug]: ACPI region does not cover the entire command/response buffer.") toto TPM funguje len pod Windows, v Linuxe nie.
Dík za tu poznámku s RDP klienty na macOS, to budu muset ještě vyzkoušet, jestli se to nedá nějak obejít. Zatím jsem to používal a zkoušel jen s Remmina/FreeRDP a mstsc z Windows.
Plánoval jsem někde nasazení na sdílenou plochu přes gnome-remote-desktop, a tohle by byla určitě potíž, protože někteří uživatelé mají jen macOS.
Obecně jeden z nejblbějších aspektů je, že to sdílení plochy je specifické pro každý DE (kompozitor/session-manager..). Vůbec nevím, jestli je za stávající situace možné reálně udělat software třetí strany (ať už open-source, nebo třeba komerční jako RealVNC, které funguje relativně uspokojivě na X11 session a má spousty zmíněných věcí dotažených) mimo tahle vestavěná sdílení.
Protože s tím inkrementálním vylepšováním, které bude zarovnané s major verzemi DE (GNOME 47, 48) a určitým cyklem vydávání LTS distribucí (kam nebudou tyhle novější DE nikdy zpětně zařazené), tak si netroufám ani odhadovat, kdy to potká a bude v nějakém rozumně funkčním stavu pro firemní použití. Možná se dřív dostaví ty nové bloky JE Dukovany :)
Heh, ten bol dobry...
Prave naopak, drzia stare bugy dlhe roky, lebo LTS. Pouzivatelia sa potom stazuju na problemy, ktore su rok-dva vyriesene.
A nikto nesposobil vacsie zdrzanie waylandu ako Canonical. Najprv blbli s mir-om, potom zubami-nechtami nechceli povolit wayland session a odkladali to na dalsi LTS. Skody sposobuju hlavne tym, ze ISV cielia na Ubuntu LTS a ked to funguje tam, preco by riesili nefunkcnost na inych (novsich) distribuciach. To je napr. dovod, preco kopec kecalkov (zoom, discord, webex) dlho nevedeli/niektore stale nevedia zdielanie obrazovky pod Waylandom: ved na Ubuntu LTS s X11 to ide, tak neriesime.
Pri Waypipe sú vyriešené problémi s prihlasovaním iného uživateľa?
Na novom laptope mám wayland (aj SDDM ide na waylande) a problémy nevidím (okrem Jdowloadera - čo je asi problém jávy a štýlu naprogramovania )
Asi si ešte počkáme kým ľudia nahlásia všetky chyby a požadované vlastnosti a programátori to do programujú.
https://www.kicad.org/blog/2025/06/KiCad-and-Wayland-Support/
For now, if you need to use KiCad on Linux, use X11.
KiCAD je v tomhle dost nefér. Oni vůbec nevydávají Wayland nativní build, u kterého jsou reporty, že funguje výrazně lépe než ta X11 verze na XWaylandu (až na docking).
Oni odladili super ovládání na X11, jenže ty X11 funkce (a prakticky všechny dnešní frameworky) jsou skoro bez výjimky taky hacky původního protokolu (nativní Motif fakt nikdo nepoužívá).
Pokud někdo potřebuje srovnat dva monitory s různým rozlišením, tak se už bez fractional scaling těžko obejde. Wayland postupně dokončuje protokoly, které lidem chybí (a které oficiálně X11 nikdy nemělo, nepočítáme-li hacky.. třeba HDR a správa barev).
Hlavní problémy KiCADu jsou ovládání globální pozice okna a myši. Jenže to je dnes považováno za nebezpečnou funkci...
V X11 bylo všechno jako rozšíření. Ale Wayland se mohl kouknout, jaká rozšíření se používají a implementovat to už před 16 lety. Místo toho je jako Apple, kde iPhone dlouho neuměl schránku a uživatelé sami byli tak vymletí, že to obhajovali (taky asi považováno za nebezpečnou funkci).
12. 6. 2025, 15:01 editováno autorem komentáře
X11 mělo neoficiální rozšíření a různé hacky. Už tak základní věci jako podpora dvou a více monitorů byla hodně vachrlatá (xrandr, Xinerama). Celá 3D akcelerace byla hack.
Wayland asi těžko mohl všechno implementovat před 16 lety, když právě vznikl. X11 je z roku 1984 nebo 87 podle toho jak to berete. Takže ten vývoj taky chvíli trval.
Wayland narozdíl od X11 odděluje prostor jednotlivých aplikací, což ten vývoj komplikuje. X11 totiž dává každé aplikaci právo číst globální schránku, klávesnici a hýbat myší (což právě chybí tomu KiCADu). A na bezpečnost a sandboxing aplikací se dnes hraje mnohem více než dříve.
Takže ano, Wayland neumí všechno oficiálně (existují draft verze protokolů), ale spoustu věcí už dnes umí lépe a bezpečněji, než to kdy uměl X.org.